On 01/09/2012 09:28, Mark Thomas wrote: > 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.
Clearly this is not correct. The JSP TCL failures I am seeing in EL appear to be related to this. I'm digging further. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
