https://issues.apache.org/bugzilla/show_bug.cgi?id=56580
--- Comment #5 from Konstantin Kolinko <knst.koli...@gmail.com> ---
My look at javax.el.BeanELResolver#cache is that a BeanELResolver that it would
be bad to share such cache between web applications.
The cache keys BeanProperties instances by class name, and not by {class name,
class loader}. This creates an ambiguity that is resolved by comparing class
references in BeanELResolver#property(...)
> if (props == null || type != props.getType()) {
Sharing the same BeanELResolver among applications also means that its cache is
also shared, so you cache only 1000 classes globally, instead of 1000 per each.
I may suggest you to apply either one the following work-arounds:
a) Put mojarra into your own WEB-INF/lib directory, instead of sharing those
libs among web applications. This should provide you with better performance,
as your static copy of BeanELReolver will have cache scoped to your web
application.
Generally it is a bad idea to share libraries between web applications. (You
are tied to a specific version of the library. You are more likely to see
memory leak issues, such as this one.)
b) Set system property "org.apache.el.BeanELResolver.CACHE_SIZE" to the value
of "0". I think that would disable the cache.
----------------
Regarding a possible way to improve Tomcat's BeanELResolver, to both avoid a
leak and to reduce clash of same class name between class loaders:
- Use 2-level cache, with first level being WeakHashMap<ClassLoader, Cache>.
That is if you want to cache 1000 classes per class loader as opposed to 1000
classes globally.
I can say that it would have some negative effect on performance.
Is it a valid use case to share EL classes such as BeanELResolver between web
applications?
--
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
