On 10/03/2016 10:19, Mark Thomas wrote:
> On 10/03/2016 08:12, jimi.hulleg...@svensktnaringsliv.se wrote:
<snip/>
>> 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.
Having reviewed this, here is some useful background.
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.
If ScopedAttributeELResolver is asked to resolve "foo" it can't
differentiate between ${ foo } which doesn't require a class lookup and
${ foo.bar } which does require a class lookup. Therefore
ScopedAttributeELResolver will always do a class lookup if it didn't
find an a matching attribute.
These lookups pass through various standard APIs (EL and JSP specs) so
we can't simply add a flag to the method to indicate if a class lookup
is required or not.
We can't use ThreadLocals because either:
- the ThreadLocal would need to be defined in a specification class
which isn't allowed because we can't change the public API; or
- the ThreadLocal would need to be defined in Tomcat and referenced in
a spec class which isn't allowed because the spec JARs have to be
independent.
However, all is not lost. I think I have a solution based on ELContext
getContext()/putContext(). Keep an eye on
https://bz.apache.org/bugzilla/show_bug.cgi?id=57583 for progress reports.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
