[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 --- Comment #7 from Arthur Fiedler artfied...@gmail.com --- Just to throw my two cents in, I think the future JSP spec should be to modify the ScopedAttributeELResolver so it only sets the propertyResolved when it is in fact found, and add two additional standard ELResolvers following ScopedAttributeELResolver. The first one being ImportELResolver, which resolves classes via the import handler. The second one being always the last NotFoundELResolver, which returns null and sets the propertyResolved for all that reach it. This way future resolvers can be defined in the spec before NotFoundELResolver and the resolvers can be more clean cut for reuse/extending -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141
--- Comment #6 from Konstantin Kolinko knst.koli...@gmail.com ---
Ah, I think that I see now. The problem is that ScopedAttributeELResolver calls
context.setPropertyResolved(base, property) regardless of whether the property
actually exists.
I think that one reason for that behaviour is to avoid an error to be thrown by
EL for such expressions as ${undefinedFoo}. So a possible theoretical
alternative fix could be the following two changes:
1. Change ScopedAttributeELResolver to do not set propertyResolved flag if
the property does not exist, I mean if pageContext.findAttribute(key) returned
null.
2. Change EL to treat unresolved identifier as having the value of null instead
of raising an error.
Given that both this theoretical fix and the actual fix in r1636063 are
changing the implementation of ScopedAttributeELResolver, I think the actual
fix in r1636063 wins as being less intrusive. It does not need change at EL
side.
So Ack for the current fiz.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED OS||All --- Comment #1 from Mark Thomas ma...@apache.org --- Thanks for the report. This has been fixed in 8.0.x for 8.0.15 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com --- Re: r1636063 I think it is wrong to change ScopedAttributeELResolver to implement this fix. Thus I am REOPENING this. The ScopedAttributeELResolver is defined by JSP specification (see JSP.2.9 Resolution of Variables and their Properties) and by its javadoc [1]. Those describe exactly what it does. It should not resolve imported classes - those are EL implementation responsibility, not JSP one. The EL3.0 specification says in several places that ELResolver is responsible for resolving model objects. An imported class is not a model object. In EL3.0 specification there is chapter 1.5 Resolution of Model Objects and their Properties or Methods. [quote] 1.5.3 Evaluating objects with properties The steps for evaluating an expression with [] or . operators (property reference and method call) are described in Section 1.6, “Operators [] and .”. However, the syntax for . operator is also used to reference a static field, or to invoke a static method. Therefore if the expression with a . operator is not resolved by the ELResolvers, and if the identifier for the base object is the name of an imported class, the expression becomes a reference to a static field, or an invocation of a static method, of the imported class. [/quote] Note Therefore if the expression with a . operator is not resolved by the ELResolvers phrase. It is not ELResolver's responsibility to perform a resolution here. [1] http://docs.oracle.com/javaee/7/api/javax/servlet/jsp/el/ScopedAttributeELResolver.html -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Thomas ma...@apache.org --- Yes, the JSP spec as currently written means that EL imports of static fields simply can't work in EL. That was not the intention of the spec writers but an oversight in the updates that were made in the JSP 2.3 maintenance release to handle the changes required for EL 3.0 support. See https://java.net/jira/browse/GLASSFISH-20778 (linked from the SO question above) The same solution was implemented in the EL and JSP reference implementation. That approach was recommended by Kin-man Chung, the spec lead for EL 3.0 and (I believe) the maintenance lead for JSP 2.3. Given his domain knowledge and position within the various EG's, I am more than happy to follow his advice on the correct behaviour in this case. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 --- Comment #4 from Konstantin Kolinko knst.koli...@gmail.com --- One part of what I am saying is that it is odd that a fundamental feature of EL language (el-api.jar) depends on internal implementation of a class that belongs to JSP API (jsp-api.jar). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 --- Comment #5 from Mark Thomas ma...@apache.org --- That is not the case. Standalone EL works. The problem is that the documented behaviour of one of the JSP EL resolvers breaks an EL feature so that resolver has to include a work-around. Not ideal but not unexpected given the number of the new features (and associated syntax) added in EL 3.0. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57141] JSP 2.3 EL 3.0 Spec conflict w/Static Fields, Methods, etc.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57141 Arthur Fiedler artfied...@gmail.com changed: What|Removed |Added Blocks||57142 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
