|
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
|