On 01/09/2012 01:55, Konstantin Kolinko wrote: > 2012/9/1 Mark Thomas <ma...@apache.org>: >> On 31/08/2012 12:37, Konstantin Kolinko wrote: >>> 2012/8/30 <ma...@apache.org>: >>>> Author: markt >>>> Date: Thu Aug 30 19:44:46 2012 >>>> New Revision: 1379091 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1379091&view=rev >>>> Log: >>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53792 >>>> Support method expressions that include a method call that is not at the >>>> end of the expression >>>> >>>> Modified: >>>> tomcat/tc7.0.x/trunk/ (props changed) >>>> tomcat/tc7.0.x/trunk/java/org/apache/el/parser/AstValue.java >>>> tomcat/tc7.0.x/trunk/test/org/apache/el/TestMethodExpressionImpl.java >>>> >>>> --- tomcat/tc7.0.x/trunk/java/org/apache/el/parser/AstValue.java (original) >>>> +++ tomcat/tc7.0.x/trunk/java/org/apache/el/parser/AstValue.java Thu Aug >>>> 30 >>> ctx.setPropertyResolved(false); >>> >>> The above was previously called before calling resolver.getValue(), >>> but now it is not called neither before resolver.invoke(), nor before >>> resolver.getValue(). >> >> The calls are unnecessary. The CompositeELResolver sets the property to >> false at the start of both of those methods and the Resolver >> implementations are responsible for setting it if they find a match. > > This relies on the fact that ELContext.getResolver() is an instance of > CompositeELResolver. Other resolvers do not set this flag to false. > > The API itself (ELContext, ELContextImpl(ELResolver)) allows any resolver > type. > > Though it would seem strange if one uses a non-CompositeELResolver > here, as this would omit some features of the EL language.
The flag is only read by the CompositeELResolver so that shouldn't matter. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
