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? (http://tomcat.apache.org/whichversion.html) > 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 specifications? 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, right?). 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 letter). /Jimi --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
