Details
Major Description
When an enhanced Class is loaded by a ClassLoader, its static initializer registers it with metadata in a map in the PCRegistry. Every MetaDataRepository that registers as a listener with the PCRegistry will receive each class, regardless of whichever ClassLoader it is associated with. In a JEE environment, this means all Classes from all Applications (including stopped Applications whose ClassLoaders have not yet been Garbage Collected) are received by each MDR instance in the MDR.processRegisteredClasses() method.
It has been found that there is a problem in the MDR.processRegisteredClasses() method. While processing each registrant, one of the first things it attempts to do is instantiate the class to determine whether the version level of the enhancer that enhanced the class is compatible with the runtime. If the class constructor contains application logic that addresses static (session-context sensitive) data and does not gracefully capture the resulting RuntimeException, it can cause the JPA operation responsible for triggering the MDR.pRC() operation to fail.
As a Compatibility option, I propose enabling a filter that eliminates classes that are not loadable through the envLoader (or Thread Context ClassLoader when envLoader is null). This will eliminate instantiating Classes from other applications (thus eliminating the execution of potential application custom logic embedded in the constructors) inappropriately.