BeanELResolver cache causes Class Loader leaks in app servers

[lprimak]

Currently, BeanELResolver caches Class elements in its SoftReference maps.
This causes it's ClassLoader to be referenced in the cache.
BeanELResolver internal SoftReference map only gets cleaned up via cleanup() method,
which doesn't necessarily get called often enough to prevent Out-Of-Memory errors.
The other issue is that, even when cleanup() is called enough to prevent OOMs,
the 'danglng' ClassLoaders cause VM to run at it's max memory capacity,
causing unnecessary GC and memory allocation thrashing.

clearProperties() method is needed to clear the cache from the ClassLoaders and thus prevent the leak

[lprimak]

There is no way that I can think of to provide "automatic" scoping / cache invalidation.
Either SoftReference will use maximum amount of VM memory causing memory and GC thrashing,
or WeakReference will clear the cache with every GC.

My conclusion is to keep SoftReference and add clearProperties() method as in #215

[lprimak]

@arjantijms My assumption is that this is an issue in GlassFish as well?
@starksm64 @bstansberry I see that IBM / RH use a fork of EL because of this issue?

I am sure that you guys would like to see a fix so you can start using "stock" version of EL at some point instead of needing to fork?

Thank you

[bstansberry]

@lprimak WildFly and JBoss EAP have long used our own variant of the EL API. We could likely stop doing that if our bean properties and factory finder caching use cases discussed in #218 were both handled in this project.

That said, it sounds like the need for the bean properties pieces is because Faces is holding a static ref to a BeanELResolver.

The WildFly project and the downstream Red Hat JBoss EAP product are produced independently of other EE implementations from IBM. So my comment here should not be interpreted as saying anything about IBM or any of its EE impls like Websphere, Liberty etc.

[lprimak]

Thanks, Brian,

It sounds like BeanPropertiesCache is a non-starter because of java.beans dependency. However, once clearProperties() is added (#215 is merged) that should solve the BeanPropertiesCache case.

Also sounds like FactoryFinderCache can be merged into EL as is.

Am I understanding things correctly?