https://issues.apache.org/bugzilla/show_bug.cgi?id=56580
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #7 from Mark Thomas <ma...@apache.org> ---
Hmm. The specification is completely silent on this. There is the odd hint that
caching may take place within the EL implementation but no details are provided
as to what might be cached or how and, importantly, no API is provided to clear
any cache that may exist.
The Glassfish solution was to use SoftReferences for the cache entries. That
only sort of fixes the problem in that the web app class loader could remain in
memory until long after the web application is reloaded. We have seen cases in
the past where this behavior causes problems for some libraries (and is why we
added closeMethod support to resources).
If the cache was static then we could add a method to clear the cache for a
given class loader and call that via reflection when the web application stops.
However, making the cache static is going to have all sorts of side-effects -
some of which may well be unpleasant. The most obvious of these is a guaranteed
memory leak unless you call the clear cache method which most clients won't do.
The other pure Tomcat solutions are don't cache or to place the Mojarra JARs in
the web application rather than $CATALINA_BASE/lib.
Mojarra could use per web application instances of BeanELResolver rather than a
single static instance. Mojarra should also have the necessary hooks to remove
those instances when the web application stops (e.g. ServletContextListener).
In short, I don't see a way to fix this safely in Tomcat. I think it could be
fixed in Mojarra but I don't know that code base so I might be completely
wrong. There are a couple of work-arounds: disable the cache, move the Mojarra
JARs to WEB=INF/lib.
I agree that there is a problem here and I'd like to fix it in Tomcat if I
could but I don't see a way to do that. Given that there are workarounds
available I am going to resolve this as WONTFIX.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
