FULL PRODUCT VERSION :
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Version = GlassFish Server Open Source Edition 184.108.40.206 (build 5)
Command version executed successfully.
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
Using the javax security from an EAR inside an application server results into having a strong reference to the EAR's class loader.
Undeploying the EAR will leave the EAR in memory due to the strong reference to the EAR's class loader.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Start clean and empty glassfish
2. Take any EAR which uses javax. security, deploy it and invoke a method which really touches javax.security
3. Undeploy the EAR
Inspect the memory (e.g. using VisualVM): The contextClassloader refers to the EAR's class loader.
Classes are not freed.
EXPECTED VERSUS ACTUAL BEHAVIOR :
javax security should not have any reference to an EAR class loader
javax security has reference to an EAR class loader
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
3 levels to workaround:
1. restart the application server every time (costs valuable time)
2. use a context listener and implement contextDestroyed(..):
- poke javax.security.auth.login.Configuration.contextClassLoader to null (using introspection)
3. patch the rt.jar:
- remove the contextClassLoader member
- use Thread.currentThread().getContextClassLoader() instead of the member