Menu
▾
▴
springframework-developer
|
From: Rob H. <ro...@ca...> - 2004-11-05 20:43:13
|
All, Has anyone started work on the OGNL support yet. I have no plans for the weekend and I need to do something other than JMX :) Rob |
|
From: Colin S. <col...@ex...> - 2004-11-05 21:47:02
|
Rob, No Spring committer has done any work that I know of. However, if you look at the thread with the subject "PropertyPathFactoryBean", on Oct. 6th Guillaume Poirier posted some OGNL patches. You might want to read his email, and take a look at my reply too. Using a new element (<ognl> was Guillaume's suggestion) would work in a completely backwards compatible fashion. I am somewhat more attracted to the idea of using a prefix on the value inside the <value> tag. My other concern is with the speed of OGNL. OGNL is quite nice, it's heavily used in Tapestry and I found it a lot better than say the JSTL's expression language. However, v2.x anyways, is not a speed demon. I'd like to also compare it to something like Janino: http://www.janino.net/ in terms of best fit for Spring... Colin Rob Harrop wrote: > All, > > Has anyone started work on the OGNL support yet. I have no plans for > the weekend and I need to do something other than JMX :) > > Rob |
|
From: Guillaume P. <gpo...@gl...> - 2004-11-05 23:24:25
|
> I am somewhat more attracted to the idea of using a prefix on the value > inside the <value> tag. While I admit that it would be unlikely to cause problem, using a prefix in a value tag is not 100% backward compatible. Someone could be using such prefix currently for a String that should be analysed by once injected, rather than by Spring. And I personally find an <ognl> tag more intuitive for the user. It's also somewhat easier to implement, not that it really matters much I guess. > My other concern is with the speed of OGNL. Adding OGNL support doesn't prevent from adding supports for other expression languages. :-) Guillaume ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Friday, November 05, 2004 4:46 PM Subject: Re: [Springframework-developer] OGNL > Rob, > > No Spring committer has done any work that I know of. However, if you look > at the thread with the subject "PropertyPathFactoryBean", on Oct. 6th > Guillaume Poirier posted some OGNL patches. You might want to read his > email, and take a look at my reply too. Using a new element (<ognl> was > Guillaume's suggestion) would work in a completely backwards compatible > fashion. I am somewhat more attracted to the idea of using a prefix on the > value inside the <value> tag. My other concern is with the speed of OGNL. > OGNL is quite nice, it's heavily used in Tapestry and I found it a lot > better than say the JSTL's expression language. However, v2.x anyways, is > not a speed demon. I'd like to also compare it to something like Janino: > http://www.janino.net/ > in terms of best fit for Spring... > > Colin > > > Rob Harrop wrote: > >> All, >> >> Has anyone started work on the OGNL support yet. I have no plans for the >> weekend and I need to do something other than JMX :) >> >> Rob > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dion A. <di...@al...> - 2004-11-06 04:48:34
|
I kinda like a prefix, as it could allow: groovy:... bsh:... javascript:... (rhino) ognl:... Etc etc. However, I do understand the backwards compatibile need. Personally, I would love to be able to use prefixes and even set a "Default" so I can set-default="groovy" ;) D -----Original Message----- From: Guillaume Poirier [mailto:gpo...@gl...] Sent: Friday, November 05, 2004 5:25 PM To: spr...@li... Subject: Re: [Springframework-developer] OGNL > I am somewhat more attracted to the idea of using a prefix on the > value inside the <value> tag. While I admit that it would be unlikely to cause problem, using a prefix in a value tag is not 100% backward compatible. Someone could be using such prefix currently for a String that should be analysed by once injected, rather than by Spring. And I personally find an <ognl> tag more intuitive for the user. It's also somewhat easier to implement, not that it really matters much I guess. > My other concern is with the speed of OGNL. Adding OGNL support doesn't prevent from adding supports for other expression languages. :-) Guillaume ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Friday, November 05, 2004 4:46 PM Subject: Re: [Springframework-developer] OGNL > Rob, > > No Spring committer has done any work that I know of. However, if you look > at the thread with the subject "PropertyPathFactoryBean", on Oct. 6th > Guillaume Poirier posted some OGNL patches. You might want to read his > email, and take a look at my reply too. Using a new element (<ognl> was > Guillaume's suggestion) would work in a completely backwards compatible > fashion. I am somewhat more attracted to the idea of using a prefix on the > value inside the <value> tag. My other concern is with the speed of OGNL. > OGNL is quite nice, it's heavily used in Tapestry and I found it a lot > better than say the JSTL's expression language. However, v2.x anyways, is > not a speed demon. I'd like to also compare it to something like Janino: > http://www.janino.net/ > in terms of best fit for Spring... > > Colin > > > Rob Harrop wrote: > >> All, >> >> Has anyone started work on the OGNL support yet. I have no plans for the >> weekend and I need to do something other than JMX :) >> >> Rob > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Guillaume P. <gpo...@gl...> - 2004-11-06 06:18:30
|
Well, using a tags would still allow to add <groovy>, <bsh>, <javascript>, <ognl>. Or if adding tags cause problems (not sure why it would though), then may be an either a new <expr>, or attribute to value. e.g. <expr type="ognl">@java.sql.Types@INTEGER</expr> or <value expr="ognl">@java.sql.Types@INTEGER</value> Guillaume ----- Original Message ----- From: "Dion Almaer" <di...@al...> To: <spr...@li...> Sent: Friday, November 05, 2004 7:47 PM Subject: RE: [Springframework-developer] OGNL >I kinda like a prefix, as it could allow: > > groovy:... > bsh:... > javascript:... (rhino) > ognl:... > > Etc etc. > > However, I do understand the backwards compatibile need. Personally, I > would > love to be able to use prefixes and even set a "Default" so I can > set-default="groovy" ;) > > D > > -----Original Message----- > From: Guillaume Poirier [mailto:gpo...@gl...] > Sent: Friday, November 05, 2004 5:25 PM > To: spr...@li... > Subject: Re: [Springframework-developer] OGNL > >> I am somewhat more attracted to the idea of using a prefix on the >> value inside the <value> tag. > > While I admit that it would be unlikely to cause problem, using a prefix > in > a value tag is not 100% backward compatible. Someone could be using such > prefix currently for a String that should be analysed by once injected, > rather than by Spring. And I personally find an <ognl> tag more intuitive > for the user. It's also somewhat easier to implement, not that it really > matters much I guess. > >> My other concern is with the speed of OGNL. > Adding OGNL support doesn't prevent from adding supports for other > expression languages. :-) > > Guillaume > > ----- Original Message ----- > From: "Colin Sampaleanu" <col...@ex...> > To: <spr...@li...> > Sent: Friday, November 05, 2004 4:46 PM > Subject: Re: [Springframework-developer] OGNL > > >> Rob, >> >> No Spring committer has done any work that I know of. However, if you >> look > >> at the thread with the subject "PropertyPathFactoryBean", on Oct. 6th >> Guillaume Poirier posted some OGNL patches. You might want to read his >> email, and take a look at my reply too. Using a new element (<ognl> was >> Guillaume's suggestion) would work in a completely backwards compatible >> fashion. I am somewhat more attracted to the idea of using a prefix on >> the > >> value inside the <value> tag. My other concern is with the speed of OGNL. >> OGNL is quite nice, it's heavily used in Tapestry and I found it a lot >> better than say the JSTL's expression language. However, v2.x anyways, is >> not a speed demon. I'd like to also compare it to something like Janino: >> http://www.janino.net/ >> in terms of best fit for Spring... >> >> Colin >> >> >> Rob Harrop wrote: >> >>> All, >>> >>> Has anyone started work on the OGNL support yet. I have no plans for the >>> weekend and I need to do something other than JMX :) >>> >>> Rob >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Sybase ASE Linux Express Edition - download now for FREE >> LinuxWorld Reader's Choice Award Winner for best database on Linux. >> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Pieter C. <pie...@on...> - 2004-11-06 08:47:22
|
And if we combine your post with the one from Dion (defaults), we get: // Default, may be left out: <beans expr="string"> <value expr="string"> // Use this as the default for the whole xml file <beans expr="ognl"> // Use this if you don't want to use ognl in this property <value expr="string"> Pieter Guillaume Poirier wrote: > Well, using a tags would still allow to add <groovy>, <bsh>, > <javascript>, <ognl>. Or if adding tags cause problems (not sure why > it would though), then may be an either a new <expr>, or attribute to > value. > > e.g. <expr type="ognl">@java.sql.Types@INTEGER</expr> > or <value expr="ognl">@java.sql.Types@INTEGER</value> > > Guillaume > > ----- Original Message ----- From: "Dion Almaer" <di...@al...> > To: <spr...@li...> > Sent: Friday, November 05, 2004 7:47 PM > Subject: RE: [Springframework-developer] OGNL > > >> I kinda like a prefix, as it could allow: >> >> groovy:... >> bsh:... >> javascript:... (rhino) >> ognl:... >> >> Etc etc. >> >> However, I do understand the backwards compatibile need. Personally, >> I would >> love to be able to use prefixes and even set a "Default" so I can >> set-default="groovy" ;) >> >> D >> >> -----Original Message----- >> From: Guillaume Poirier [mailto:gpo...@gl...] >> Sent: Friday, November 05, 2004 5:25 PM >> To: spr...@li... >> Subject: Re: [Springframework-developer] OGNL >> >>> I am somewhat more attracted to the idea of using a prefix on the >>> value inside the <value> tag. >> >> >> While I admit that it would be unlikely to cause problem, using a >> prefix in >> a value tag is not 100% backward compatible. Someone could be using >> such >> prefix currently for a String that should be analysed by once injected, >> rather than by Spring. And I personally find an <ognl> tag more >> intuitive >> for the user. It's also somewhat easier to implement, not that it >> really >> matters much I guess. >> >>> My other concern is with the speed of OGNL. >> >> Adding OGNL support doesn't prevent from adding supports for other >> expression languages. :-) >> >> Guillaume >> >> ----- Original Message ----- >> From: "Colin Sampaleanu" <col...@ex...> >> To: <spr...@li...> >> Sent: Friday, November 05, 2004 4:46 PM >> Subject: Re: [Springframework-developer] OGNL >> >> >>> Rob, >>> >>> No Spring committer has done any work that I know of. However, if >>> you look >> >> >>> at the thread with the subject "PropertyPathFactoryBean", on Oct. 6th >>> Guillaume Poirier posted some OGNL patches. You might want to read his >>> email, and take a look at my reply too. Using a new element (<ognl> was >>> Guillaume's suggestion) would work in a completely backwards compatible >>> fashion. I am somewhat more attracted to the idea of using a prefix >>> on the >> >> >>> value inside the <value> tag. My other concern is with the speed of >>> OGNL. >>> OGNL is quite nice, it's heavily used in Tapestry and I found it a lot >>> better than say the JSTL's expression language. However, v2.x >>> anyways, is >>> not a speed demon. I'd like to also compare it to something like >>> Janino: >>> http://www.janino.net/ >>> in terms of best fit for Spring... >>> >>> Colin >>> >>> >>> Rob Harrop wrote: >>> >>>> All, >>>> >>>> Has anyone started work on the OGNL support yet. I have no plans >>>> for the >>>> weekend and I need to do something other than JMX :) >>>> >>>> Rob >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: >>> Sybase ASE Linux Express Edition - download now for FREE >>> LinuxWorld Reader's Choice Award Winner for best database on Linux. >>> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Sybase ASE Linux Express Edition - download now for FREE >> LinuxWorld Reader's Choice Award Winner for best database on Linux. >> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Sybase ASE Linux Express Edition - download now for FREE >> LinuxWorld Reader's Choice Award Winner for best database on Linux. >> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <ro...@in...> - 2004-11-06 08:57:12
|
<script lang="ognl"> perhaps I think it would be good for the mechanism to be extensible. Guillaume Poirier wrote: >> I am somewhat more attracted to the idea of using a prefix on the >> value inside the <value> tag. > > > While I admit that it would be unlikely to cause problem, using a prefix > in a value tag is not 100% backward compatible. Someone could be using > such prefix currently for a String that should be analysed by once > injected, rather than by Spring. And I personally find an <ognl> tag > more intuitive for the user. It's also somewhat easier to implement, > not that it really matters much I guess. > >> My other concern is with the speed of OGNL. > > Adding OGNL support doesn't prevent from adding supports for other > expression languages. :-) > > Guillaume > > ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> > To: <spr...@li...> > Sent: Friday, November 05, 2004 4:46 PM > Subject: Re: [Springframework-developer] OGNL > > >> Rob, >> >> No Spring committer has done any work that I know of. However, if you >> look at the thread with the subject "PropertyPathFactoryBean", on Oct. >> 6th Guillaume Poirier posted some OGNL patches. You might want to read >> his email, and take a look at my reply too. Using a new element >> (<ognl> was Guillaume's suggestion) would work in a completely >> backwards compatible fashion. I am somewhat more attracted to the idea >> of using a prefix on the value inside the <value> tag. My other >> concern is with the speed of OGNL. OGNL is quite nice, it's heavily >> used in Tapestry and I found it a lot better than say the JSTL's >> expression language. However, v2.x anyways, is not a speed demon. I'd >> like to also compare it to something like Janino: >> http://www.janino.net/ >> in terms of best fit for Spring... >> >> Colin >> >> >> Rob Harrop wrote: >> >>> All, >>> >>> Has anyone started work on the OGNL support yet. I have no plans for >>> the weekend and I need to do something other than JMX :) >>> >>> Rob >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Sybase ASE Linux Express Edition - download now for FREE >> LinuxWorld Reader's Choice Award Winner for best database on Linux. >> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- ____________________________________________________ Rod Johnson Interface21 - Spring Services from the Source http://www.springframework.com Founder, Spring Framework: http://www.springframework.org Author, "Expert One-on-One J2EE Development Without EJB" (May 2004, with Juergen Hoeller). http://www.amazon.com/exec/obidos/ASIN/0764558315/ Author, "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |
|
From: Rob H. <ro...@ca...> - 2004-11-06 15:38:59
|
I like the idea of having am <expr> tag for something like <expr
type="ognl">. In the code we could have something like:
public interface ExpressionEvaluator {
String[] getDependencies(String expr);
Object evaluate(String expr);
}
Then we could have multiple implementations for the ExpressionEvaluator
interface for OGNL, Groovy etc.
Rob
Rod Johnson writes:
> <script lang="ognl"> perhaps
>
> I think it would be good for the mechanism to be extensible.
>
> Guillaume Poirier wrote:
>>> I am somewhat more attracted to the idea of using a prefix on the value
>>> inside the <value> tag.
>>
>>
>> While I admit that it would be unlikely to cause problem, using a prefix
>> in a value tag is not 100% backward compatible. Someone could be using
>> such prefix currently for a String that should be analysed by once
>> injected, rather than by Spring. And I personally find an <ognl> tag
>> more intuitive for the user. It's also somewhat easier to implement, not
>> that it really matters much I guess.
>>
>>> My other concern is with the speed of OGNL.
>>
>> Adding OGNL support doesn't prevent from adding supports for other
>> expression languages. :-)
>>
>> Guillaume
>>
>> ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...>
>> To: <spr...@li...>
>> Sent: Friday, November 05, 2004 4:46 PM
>> Subject: Re: [Springframework-developer] OGNL
>>
>>
>>> Rob,
>>>
>>> No Spring committer has done any work that I know of. However, if you
>>> look at the thread with the subject "PropertyPathFactoryBean", on Oct.
>>> 6th Guillaume Poirier posted some OGNL patches. You might want to read
>>> his email, and take a look at my reply too. Using a new element (<ognl>
>>> was Guillaume's suggestion) would work in a completely backwards
>>> compatible fashion. I am somewhat more attracted to the idea of using a
>>> prefix on the value inside the <value> tag. My other concern is with the
>>> speed of OGNL. OGNL is quite nice, it's heavily used in Tapestry and I
>>> found it a lot better than say the JSTL's expression language. However,
>>> v2.x anyways, is not a speed demon. I'd like to also compare it to
>>> something like Janino:
>>> http://www.janino.net/
>>> in terms of best fit for Spring...
>>>
>>> Colin
>>>
>>>
>>> Rob Harrop wrote:
>>>
>>>> All,
>>>>
>>>> Has anyone started work on the OGNL support yet. I have no plans for
>>>> the weekend and I need to do something other than JMX :)
>>>>
>>>> Rob
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Sybase ASE Linux Express Edition - download now for FREE
>>> LinuxWorld Reader's Choice Award Winner for best database on Linux.
>>> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Sybase ASE Linux Express Edition - download now for FREE
>> LinuxWorld Reader's Choice Award Winner for best database on Linux.
>> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
> --
>
> ____________________________________________________
> Rod Johnson
> Interface21 - Spring Services from the Source
> http://www.springframework.com
>
> Founder, Spring Framework:
> http://www.springframework.org
>
> Author, "Expert One-on-One J2EE Development Without EJB"
> (May 2004, with Juergen Hoeller).
> http://www.amazon.com/exec/obidos/ASIN/0764558315/
>
> Author, "Expert One-on-One J2EE Design and Development"
> (October 2002).
> http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/
>
>
> ____________________________________________________
> Interface21 Limited
> Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1
> 2JY
> Registered in England and Wales No. 5187766
> ____________________________________________________
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Guillaume P. <gpo...@gl...> - 2004-11-06 17:19:34
Attachments:
src-patch.txt
test-patch.txt
|
In the prototype I sent to this list, I did something similar, except that I
assumed that we would want the expression compiled once when reading the XML
file, and then evaluated multiple times if needed. However, in your
example, you would need to give a context to the expression evaluator. And
I'm not sure what's the purpose of the getDependencies() method, and how
would you implement that with OGNL?
My prototype has an Expression interface as shown below, where the
expression is expected to be compiled in the constructor, and then evaluated
when a specific context is provided in the resolve method.
public interface Expression {
public Object resolve(ListableBeanFactory factory);
}
The OGNL implementation looks like this:
public class OgnlExpression implements Expression {
private Object expr;
public OgnlExpression(String value) {
try {
expr = Ognl.parseExpression(value);
} catch (OgnlException e) {
throw new BeanCreationException("Failled to parse OGNL expression",
e);
}
}
public Object resolve(ListableBeanFactory factory) {
try {
Map ctx = new OgnlExpressionContext(factory);
return Ognl.getValue(expr, ctx, (Object) null);
} catch (OgnlException e) {
throw new BeanCreationException("Failled to resolve OGNL expression",
e);
}
}
}
The class OgnlExpressionContext extends OgnlContext which extends a map, it
exposes the beans in the ListableBeanFactory to the OGNL engine.
The original post was at :
http://article.gmane.org/gmane.comp.java.springframework.devel/6076, and I
attached the prototype to this email, since gmane doesn't seem to keep the
attachements. The patch was made on a Spring's CVS of a month ago though,
but it still seems to work with an up to date CVS.
Guillaume
----- Original Message -----
From: "Rob Harrop" <ro...@ca...>
To: <spr...@li...>
Sent: Saturday, November 06, 2004 10:38 AM
Subject: [Springframework-developer] Re: OGNL
>I like the idea of having am <expr> tag for something like <expr
>type="ognl">. In the code we could have something like:
>
> public interface ExpressionEvaluator {
> String[] getDependencies(String expr);
> Object evaluate(String expr);
> }
> Then we could have multiple implementations for the ExpressionEvaluator
> interface for OGNL, Groovy etc.
> Rob
> Rod Johnson writes:
>> <script lang="ognl"> perhaps I think it would be good for the mechanism
>> to be extensible. Guillaume Poirier wrote:
>>>> I am somewhat more attracted to the idea of using a prefix on the
>>>> value inside the <value> tag.
>>> While I admit that it would be unlikely to cause problem, using a
>>> prefix in a value tag is not 100% backward compatible. Someone could be
>>> using such prefix currently for a String that should be analysed by once
>>> injected, rather than by Spring. And I personally find an <ognl> tag
>>> more intuitive for the user. It's also somewhat easier to implement,
>>> not that it really matters much I guess.
>>>> My other concern is with the speed of OGNL.
>>>
>>> Adding OGNL support doesn't prevent from adding supports for other
>>> expression languages. :-) Guillaume ----- Original Message ----- From:
>>> "Colin Sampaleanu" <col...@ex...>
>>> To: <spr...@li...>
>>> Sent: Friday, November 05, 2004 4:46 PM
>>> Subject: Re: [Springframework-developer] OGNL
>>>> Rob, No Spring committer has done any work that I know of. However, if
>>>> you look at the thread with the subject "PropertyPathFactoryBean", on
>>>> Oct. 6th Guillaume Poirier posted some OGNL patches. You might want to
>>>> read his email, and take a look at my reply too. Using a new element
>>>> (<ognl> was Guillaume's suggestion) would work in a completely
>>>> backwards compatible fashion. I am somewhat more attracted to the idea
>>>> of using a prefix on the value inside the <value> tag. My other concern
>>>> is with the speed of OGNL. OGNL is quite nice, it's heavily used in
>>>> Tapestry and I found it a lot better than say the JSTL's expression
>>>> language. However, v2.x anyways, is not a speed demon. I'd like to also
>>>> compare it to something like Janino:
>>>> http://www.janino.net/
>>>> in terms of best fit for Spring... Colin Rob Harrop wrote:
>>>>> All, Has anyone started work on the OGNL support yet. I have no plans
>>>>> for the weekend and I need to do something other than JMX :) Rob
|
|
From: Rob H. <ro...@ca...> - 2004-11-06 18:29:56
|
Guillaume,
How does this work when the expression references a bean that has not yet
been assembled by Spring - that is how does this example handle bean
interdependencies. It is possible that an expression will change the beans a
bean depends on and this would not be handled by the standard dependency
resoution algorithm. That was the purpose behind my getDependencies() method
so that the expression could add to the dep tree.
Rob
Guillaume Poirier writes:
> In the prototype I sent to this list, I did something similar, except that
> I assumed that we would want the expression compiled once when reading the
> XML file, and then evaluated multiple times if needed. However, in your
> example, you would need to give a context to the expression evaluator.
> And I'm not sure what's the purpose of the getDependencies() method, and
> how would you implement that with OGNL?
>
> My prototype has an Expression interface as shown below, where the
> expression is expected to be compiled in the constructor, and then
> evaluated when a specific context is provided in the resolve method.
>
> public interface Expression {
> public Object resolve(ListableBeanFactory factory);
> }
>
> The OGNL implementation looks like this:
>
> public class OgnlExpression implements Expression {
> private Object expr;
> public OgnlExpression(String value) {
> try {
> expr = Ognl.parseExpression(value);
> } catch (OgnlException e) {
> throw new BeanCreationException("Failled to parse OGNL expression",
> e);
> }
> }
> public Object resolve(ListableBeanFactory factory) {
> try {
> Map ctx = new OgnlExpressionContext(factory);
> return Ognl.getValue(expr, ctx, (Object) null);
> } catch (OgnlException e) {
> throw new BeanCreationException("Failled to resolve OGNL expression",
> e);
> }
> }
> }
>
> The class OgnlExpressionContext extends OgnlContext which extends a map,
> it exposes the beans in the ListableBeanFactory to the OGNL engine.
>
> The original post was at :
> http://article.gmane.org/gmane.comp.java.springframework.devel/6076, and I
> attached the prototype to this email, since gmane doesn't seem to keep the
> attachements. The patch was made on a Spring's CVS of a month ago though,
> but it still seems to work with an up to date CVS.
>
> Guillaume
>
> ----- Original Message ----- From: "Rob Harrop" <ro...@ca...>
> To: <spr...@li...>
> Sent: Saturday, November 06, 2004 10:38 AM
> Subject: [Springframework-developer] Re: OGNL
>
>
>> I like the idea of having am <expr> tag for something like <expr
>> type="ognl">. In the code we could have something like:
>>
>> public interface ExpressionEvaluator {
>> String[] getDependencies(String expr);
>> Object evaluate(String expr);
>> }
>> Then we could have multiple implementations for the ExpressionEvaluator
>> interface for OGNL, Groovy etc.
>> Rob
>> Rod Johnson writes:
>>> <script lang="ognl"> perhaps I think it would be good for the mechanism
>>> to be extensible. Guillaume Poirier wrote:
>>>>> I am somewhat more attracted to the idea of using a prefix on the
>>>>> value inside the <value> tag.
>>>> While I admit that it would be unlikely to cause problem, using a
>>>> prefix in a value tag is not 100% backward compatible. Someone could
>>>> be using such prefix currently for a String that should be analysed by
>>>> once injected, rather than by Spring. And I personally find an <ognl>
>>>> tag more intuitive for the user. It's also somewhat easier to
>>>> implement, not that it really matters much I guess.
>>>>> My other concern is with the speed of OGNL.
>>>>
>>>> Adding OGNL support doesn't prevent from adding supports for other
>>>> expression languages. :-) Guillaume ----- Original Message ----- From:
>>>> "Colin Sampaleanu" <col...@ex...>
>>>> To: <spr...@li...>
>>>> Sent: Friday, November 05, 2004 4:46 PM
>>>> Subject: Re: [Springframework-developer] OGNL
>>>>> Rob, No Spring committer has done any work that I know of. However, if
>>>>> you look at the thread with the subject "PropertyPathFactoryBean", on
>>>>> Oct. 6th Guillaume Poirier posted some OGNL patches. You might want to
>>>>> read his email, and take a look at my reply too. Using a new element
>>>>> (<ognl> was Guillaume's suggestion) would work in a completely
>>>>> backwards compatible fashion. I am somewhat more attracted to the idea
>>>>> of using a prefix on the value inside the <value> tag. My other
>>>>> concern is with the speed of OGNL. OGNL is quite nice, it's heavily
>>>>> used in Tapestry and I found it a lot better than say the JSTL's
>>>>> expression language. However, v2.x anyways, is not a speed demon. I'd
>>>>> like to also compare it to something like Janino:
>>>>> http://www.janino.net/
>>>>> in terms of best fit for Spring... Colin Rob Harrop wrote:
>>>>>> All, Has anyone started work on the OGNL support yet. I have no plans
>>>>>> for the weekend and I need to do something other than JMX :) Rob
|
|
From: Guillaume P. <gpo...@gl...> - 2004-11-06 21:43:44
|
OGNL doesn't really expose the dependencies. It might be possible to have
some kind of hack to get them, but I don't really see an easy way for that.
Also, the OGNL expressions are allowed to use the ? operator for conditional
expressions, which means the actual dependencies would depend on the
context. Also, knowning the dependencies in advance is not necessarly
helpful if there is circular dependencies.
In my opinion, the best way to handle dependencies would be the same way
Spring does for the <bean> tags. Which is a depends-on attribute for
explicit dependencies, otherwise creating the beans as needed. Someone that
knows more than me about the internal of the beans package could confirm,
but it seems that when a property is <bean ref="name"/> tag
(RuntimeReference), Spring pretty much handles the dependency by calling
getBean(name) on the factory to have the bean created. Which is what my
implemenation of OgnlExpressionContext does, and it seems to work fine
handling dependencies.
Guillaume
----- Original Message -----
From: "Rob Harrop" <ro...@ca...>
To: <spr...@li...>
Sent: Saturday, November 06, 2004 1:29 PM
Subject: [Springframework-developer] Re: OGNL
> Guillaume,
>
> How does this work when the expression references a bean that has not yet
> been assembled by Spring - that is how does this example handle bean
> interdependencies. It is possible that an expression will change the beans
> a bean depends on and this would not be handled by the standard dependency
> resoution algorithm. That was the purpose behind my getDependencies()
> method so that the expression could add to the dep tree.
> Rob
> Guillaume Poirier writes:
>> In the prototype I sent to this list, I did something similar, except
>> that I assumed that we would want the expression compiled once when
>> reading the XML file, and then evaluated multiple times if needed.
>> However, in your example, you would need to give a context to the
>> expression evaluator. And I'm not sure what's the purpose of the
>> getDependencies() method, and how would you implement that with OGNL? My
>> prototype has an Expression interface as shown below, where the
>> expression is expected to be compiled in the constructor, and then
>> evaluated when a specific context is provided in the resolve method.
>> public interface Expression {
>> public Object resolve(ListableBeanFactory factory);
>> } The OGNL implementation looks like this: public class OgnlExpression
>> implements Expression {
>> private Object expr;
>> public OgnlExpression(String value) {
>> try {
>> expr = Ognl.parseExpression(value);
>> } catch (OgnlException e) {
>> throw new BeanCreationException("Failled to parse OGNL expression",
>> e);
>> }
>> }
>> public Object resolve(ListableBeanFactory factory) {
>> try {
>> Map ctx = new OgnlExpressionContext(factory);
>> return Ognl.getValue(expr, ctx, (Object) null);
>> } catch (OgnlException e) {
>> throw new BeanCreationException("Failled to resolve OGNL expression",
>> e);
>> }
>> }
>> } The class OgnlExpressionContext extends OgnlContext which extends a
>> map, it exposes the beans in the ListableBeanFactory to the OGNL engine.
>> The original post was at :
>> http://article.gmane.org/gmane.comp.java.springframework.devel/6076, and
>> I attached the prototype to this email, since gmane doesn't seem to keep
>> the attachements. The patch was made on a Spring's CVS of a month ago
>> though, but it still seems to work with an up to date CVS.
>> Guillaume ----- Original Message ----- From: "Rob Harrop"
>> <ro...@ca...>
>> To: <spr...@li...>
>> Sent: Saturday, November 06, 2004 10:38 AM
>> Subject: [Springframework-developer] Re: OGNL
>>> I like the idea of having am <expr> tag for something like <expr
>>> type="ognl">. In the code we could have something like: public
>>> interface ExpressionEvaluator {
>>> String[] getDependencies(String expr);
>>> Object evaluate(String expr);
>>> }
>>> Then we could have multiple implementations for the ExpressionEvaluator
>>> interface for OGNL, Groovy etc.
>>> Rob
>>> Rod Johnson writes:
>>>> <script lang="ognl"> perhaps I think it would be good for the mechanism
>>>> to be extensible. Guillaume Poirier wrote:
>>>>>> I am somewhat more attracted to the idea of using a prefix on the
>>>>>> value inside the <value> tag.
>>>>> While I admit that it would be unlikely to cause problem, using a
>>>>> prefix in a value tag is not 100% backward compatible. Someone could
>>>>> be using such prefix currently for a String that should be analysed by
>>>>> once injected, rather than by Spring. And I personally find an <ognl>
>>>>> tag more intuitive for the user. It's also somewhat easier to
>>>>> implement, not that it really matters much I guess.
>>>>>> My other concern is with the speed of OGNL.
>>>>>
>>>>> Adding OGNL support doesn't prevent from adding supports for other
>>>>> expression languages. :-) Guillaume ----- Original Message ----- From:
>>>>> "Colin Sampaleanu" <col...@ex...>
>>>>> To: <spr...@li...>
>>>>> Sent: Friday, November 05, 2004 4:46 PM
>>>>> Subject: Re: [Springframework-developer] OGNL
>>>>>> Rob, No Spring committer has done any work that I know of. However,
>>>>>> if you look at the thread with the subject "PropertyPathFactoryBean",
>>>>>> on Oct. 6th Guillaume Poirier posted some OGNL patches. You might
>>>>>> want to read his email, and take a look at my reply too. Using a new
>>>>>> element (<ognl> was Guillaume's suggestion) would work in a
>>>>>> completely backwards compatible fashion. I am somewhat more attracted
>>>>>> to the idea of using a prefix on the value inside the <value> tag. My
>>>>>> other concern is with the speed of OGNL. OGNL is quite nice, it's
>>>>>> heavily used in Tapestry and I found it a lot better than say the
>>>>>> JSTL's expression language. However, v2.x anyways, is not a speed
>>>>>> demon. I'd like to also compare it to something like Janino:
>>>>>> http://www.janino.net/
>>>>>> in terms of best fit for Spring... Colin Rob Harrop wrote:
>>>>>>> All, Has anyone started work on the OGNL support yet. I have no
>>>>>>> plans for the weekend and I need to do something other than JMX :)
>>>>>>> Rob
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
