On Wednesday, March 9, 2016 8:22 PM, ma...@apache.org wrote:
> It is a known 'feature' of the new EL requirements added in 3.0. The EL 
> parser can't differentiate 
> between an attribute without a scope and a reference to an static field.
> See https://bz.apache.org/bugzilla/show_bug.cgi?id=57583

Interesting. I can see how that in a way could explain the the performance 
regression. But what I don't understand is:

1. Why would this cause a ClassNotFoundException? What class exactly is it 
trying to load?
2. Why is this happening seemingly intermittently, with different EL variables 
each time?
3. Why is the problem not limited to the first request for a jsp page? We see 
this problem even days after a restart, for jsp-pages that definitely have been 
used multiple times already, with the same state for it's variables.
4. Why isn't the ClassNotFoundException logged by the ImportHandler?
5. Why would this change between Tomcat 7 and Tomcat 8, with the exact same 
webapp war with the exact same web.xml?
6. In our web.xml we specify version="2.5". Wouldn't that mean EL version 2.1? 

> The way to avoid it is to always add an explicit scope (page, request, 
> application, session) to your attributes.

Is this an official recommendation, stemming from the EL 3.0 specifications? If 
so, can you point me to that paragraph in the specification document, or some 
other paper of similar nature? Because when I look at the 3.0 specification 
document, all I see is examples without scope.

Or is this just a pragmatic response to the Tomcat/Jasper implementation of the 

The reason I ask is that a simple search in our code base show that we have 
about 10.000 potential candidates for the change you are suggesting, spread out 
in hundreds of jsp files in our project. And on top of that, the CMS that we 
use have their own jsp files, and a quick check indicates thousands of 
potential candidates for the change there as well. So not only would we have to 
perform a monumental task in our own code (because we would need to determine 
the scope manually, for each and every variable), we also would need to ask the 
CMS company to perform the same task.

> Suggestions for improvements to the default ImportHandler implementation to 
> make this faster are welcome.

Well, I am quite pragmatic in my thinking. Is this EL implementation the only 
implementation with this problem? Then surely one can look at the other 
implementations, and what they did to avoid this problem. But one thing off the 
top of my head would be to atleast avoid doing that class lookup in cases where 
it couldn't be a static field reference (like ${name}, since there is no dot 
after "name", there is no reason to check if "name" is a class reference, 

Otherwise, if more or less all implementations suffer from this problem, then 
maybe it is the specification that is to blame. Maybe, when introducing the new 
concept of EL references to static fields, they could use a special prefix, 
like ${static.Boolean.True}, or they could have had this feature turned off by 
default, with the possibility to turn it on either per jsp page (using some 
page directive like <%@ page staticElReferences="true" %>) or webapp-globally 
in the web.xml. Or, they could simply include the requirement that the class 
name must start with a capital letter, thus only causing problems for people 
who break the coding standard (ie either having a class name starting with a 
lower case letter, or having a variable name starting with an upper case 


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to