On 10/03/2016 08:12, jimi.hulleg...@svensktnaringsliv.se wrote: > 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?
For each imported package, it is trying to load package.attributeName > 2. Why is this happening seemingly intermittently, with different EL > variables each time? It isn't. It is happening every time. You are just observing it intermittently. Probably because class loading is serial by default and how observable this is depends on how many threads are trying to load classes in parallel. Note that 9.0.x will use ParallelWebappClassLoader by default from the next release and you can always switch to that class loader in 8.0.x > 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. Because EL imports may be dynamic so the EL has to be evaluated on execution. > 4. Why isn't the ClassNotFoundException logged by the ImportHandler? Because it is expected and logging it provides no value to the user. > 5. Why would this change between Tomcat 7 and Tomcat 8, with the exact same > webapp war with the exact same web.xml? Because imports and statics were added in EL 3.0 which was first implemented in Tomcat 8. > 6. In our web.xml we specify version="2.5". Wouldn't that mean EL version > 2.1? (http://tomcat.apache.org/whichversion.html) No. The version you specify in web.xml only determines the rules that Tomcat uses to validate the web.xml. It has zero impact on the behaviour of the container. The overall JavaEE EG made it very clear that this is how they expected implementations to behave. >> 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? It is the best recommendation I have right now based on what I know about the EL spec and Tomcat's implementation of it. > 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. You aren't the only one in that position. >> 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? I don't know. There aren't that many JSP implementations out there. The end result should be the same with all of them but how they get there may vary. > 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 at least > 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?). It has been a while since I looked at this. I need to remind myself why I thought it needed to be implemented this way. I recall looking at this at least once before but another look wouldn't hurt. > 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). The spec process could be better. I was on the EL EG but as far as I am aware none of the implementations received any significant use before the spec was finalized so I'm not surprised that issues like this appeared as adoption grew. The JavaEE specs are very big on backwards compatibility. Therefore, the chances of changing the spec syntax to fix this are zero. I should be able to look at this later today. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
