JDK-7199818 : javax.security.auth.login.Configuration hard refs a class loader
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2012-09-20
  • Updated: 2013-06-13
  • Resolved: 2013-06-13
Description
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 3.1.2.2 (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 :
EXPECTED -
javax security should not have any reference to an EAR class loader
ACTUAL -
javax security has reference to an EAR class loader

REPRODUCIBILITY :
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