Bug 50282 - Reference from javax.security.auth.login.LoginContext.contextClassLoader initalized in static code block prevents an undeployed Web application from being garbage collected (similar to #49669)
Summary: Reference from javax.security.auth.login.LoginContext.contextClassLoader init...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.4
Hardware: Macintosh All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-16 20:14 UTC by Justin Almquist
Modified: 2011-01-08 14:24 UTC (History)
0 users



Attachments
patch for tc 7 (3.34 KB, patch)
2010-11-18 16:53 UTC, Sylvain Laurent
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Almquist 2010-11-16 20:14:17 UTC
The class javax.security.auth.login.LoginContext has a "contextClassLoader" field that I believe is causing a similar problem as identified in bug #49669, which is related to the class not being garbage collected even though the application has been undeployed.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49669

I was able to notice this by deploying a very simple spring-based webapp that utilizes javax.security for authentication in which the LoginContext class is used.

I then used YourKit profiler as specified in this writeup to find any lingering classes without instances:

http://www.yourkit.com/docs/kb/class_loaders.jsp

The following class had the most instances (inside of a WebappClassLoader):
"contextClassLoader of javax.security.auth.login.Configuration [Class]"

This looks almost identical to bug #49669 with the only difference being that the contextClassLoader field isn't static, however it is initialized in a static code block.  Thus, it looks like the solution for bug #49669 would solve this problem as well.
Comment 1 Justin Almquist 2010-11-17 13:47:15 UTC
I think I confused myself a little while researching this and somehow referenced javax.security.auth.login.LoginContext when in fact I *meant* javax.security.auth.login.Configuration.  The LoginContext may be a problem as well, however the Configuration class is what is being listed in YourKit as the offending class causing the WebappClassloader to stick around.  Once again, here's the output of YourKit:

"contextClassLoader of javax.security.auth.login.Configuration [Class]"


Then, looking at the code for Configuration (http://kickjava.com/src/javax/security/auth/login/Configuration.java.htm), the following line of code is similar to the problem fixed by bug #49669 (https://issues.apache.org/bugzilla/show_bug.cgi?id=49669)

"private static ClassLoader  JavaDoc contextClassLoader;"


Sorry for any confusion...
Comment 2 Sylvain Laurent 2010-11-18 16:53:47 UTC
Created attachment 26309 [details]
patch for tc 7

Here is a patch for tc 7. It just loads the faulty class in the JreMemoryLeakPreventionListener:
Class.forName("javax.security.auth.login.Configuration", true, ClassLoader.getSystemClassLoader());
Comment 3 Konstantin Kolinko 2010-11-18 19:49:56 UTC
Is there any recipe how to reproduce this issue? (A sample webapp, and/or configuration)?
Comment 4 Justin Almquist 2010-11-19 16:19:34 UTC
I don't have a sample webapp, however this article describes exactly how we setup our authentication mechanism using JAAS:

http://download.oracle.com/javase/1.4.2/docs/guide/security/jgss/tutorials/AcnOnly.html
Comment 5 Sylvain Laurent 2010-12-03 17:21:17 UTC
patch applied on trunk, will be available for tomcat 7.0.6
Backport to tomcat 6 proposed.
Comment 6 Mark Thomas 2011-01-08 14:24:12 UTC
Applied to 6.0.x and will be included in 6.0.30 onwards.