On Thursday, March 10, 2016 11:20 AM, ma...@apache.org wrote:
> > 3. Why is the problem not limited to the first request for a jsp page? 
> Because EL imports may be dynamic so the EL has to be evaluated on execution.

I'm not really sure I follow you now. Can you explain what you mean with 
dynamic imports in this regard? I can't see any mentioning of it in the specs 

Can you give a concrete example, where an EL expression element would need to 
be evaluated as a potential class, again and again for each request?

Because the way I see it, "foo" in ${foo.bar} in some jsp page only needs to be 
evaluated once. If "foo" corresponded to a class, matching one of the imports 
in the jsp, then this lookup will not change unless the jsp code changes. And 
the same is true if the lookup failes with a ClassNotFoundException. What am I 

> > 4. Why isn't the ClassNotFoundException logged by the ImportHandler?
> Because it is expected and logging it provides no value to the user.

Well, I happen to disagree. :)
In our case, if we could see all these stacktraces in the log, by enabling 
DEBUG/TRACE log level on the ImportHandler class for example, then we would 
quickly see just how big this problem is (ie how often this happens), on what 
jsp pages it happens, and what EL expressions cause it.

On my local machine, I was able to "catch" the ClassNotFoundException using a 
debug breakpoint in my IDE, and using the breakpoint hit count I could see that 
this exception is thrown and handled (ie ignored) by the ImportHandler 2700 
times for a single request to the start page. 

> The JavaEE specs are very big on backwards compatibility. 
> Therefore, the chances of changing the spec syntax to fix this are zero.

OK. Fair enough. I agree with you that backwards compatibility is important. 
But there are ways to fix this while still keeping the backwards compatibility. 
For example by making it possible to turn off this feature (globally, per 
webapp, or per jsp), where the default is "on". Wouldn't you agree that such a 
change would be 100% backwards compatible? And at the same time it would more 
or less solve this problem completely. Because people who experience the 
mentioned problems could turn of this setting globally, and then only enable it 
for those specific jsp pages where it is needed (and these pages would then be 
cleaned up, so that no EL-references exist without specific scope unless they 
are known to never be null. Tada, problem solved! =)

Actually... this wouldn't even need to be in the specifications... I can't see 
any harm in a EL implementation introducing such settings on its own, before 
the specifications can "catch up". That way you could basically introduce this 
fix in trunk right now, and have it tested and out in a stable release in no 
time =)

On Thursday, March 10, 2016 1:24 PM, ma...@apache.org wrote:
> The issue is in ScopedAttributeELResolver.
> ScopedAttributeELResolver checks the page/request/session/application context
> first and only if it doesn't find the attribute there does it try loading the 
> class.

When debugging this in my IDE, I could see this in action. I also noticed that 
the ImportHandler that performs the class lookup is fetched from the ELContext 
object. So if I could wrap that object, I could simply return null in the 
method getImportHandler(), thus disabling this functionallity and therefore 
solving the performance problem for us. But I couldn't find any way to wrap the 
ELContext, for some reason. Can it be done, using standard code or config? Or 
can this "import logic" be disabled some other way?

There really should be a way for users to disable this, if the functionallity 
is not used and it just is causing problems. And, like I said above, that could 
be done without breaking the specs. And an alternative way to the way above, 
could be like I mentioned before, to add a configuration option that forces the 
class name to begin with a capital letter. That way ${Boolean.TRUE}, 
${Integer.MAX_VALUE} and ${MyClass.myStaticField} would still work, while 
${foo.bar} etc would simply be ignored. As long as the configuration option 
would default to false (ie lower case first letter is allowed, as per the 
specification) it wouldn't break the specification unless the user deliberately 
told it to (which is fine, right?).

It would be really nice to get your input on these suggestions. And if you 
don't like them, could you explain why? If your opinion is "We need to stick 
100% to the specification, and never ever give even the expert user any way to 
override this, ever", then I would say that such a view causes more harm than 
good. :)


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

Reply via email to