[
http://issues.apache.org/jira/browse/LOGGING-108?page=comments#action_12418592
]
Taras Tielkes commented on LOGGING-108:
---------------------------------------
Here's some proof this is happening.
Change the following code (package org.apache.jasper.runtime):
----------------------
// Logger
private static Log log = LogFactory.getLog(PageContextImpl.class);
----------------------
to this:
----------------------
// Logger
private static Log log;
static {
System.err.println(">> CCL loader: " +
Thread.currentThread().getContextClassLoader().getClass().getCanonicalName());
System.err.println(">> our loader: " +
PageContextImpl.class.getClassLoader().getClass().getCanonicalName());
log = LogFactory.getLog(PageContextImpl.class);
System.err.println(">> log loader: " +
log.getClass().getClassLoader().getClass().getCanonicalName());
}
----------------------
You'll see the following output (on the console) the first time a JSP page is
rendered:
----------------------
...
>> CCL loader: org.apache.catalina.loader.WebappClassLoader
>> our loader: org.apache.catalina.loader.StandardClassLoader
>> log loader: org.apache.catalina.loader.WebappClassLoader
...
----------------------
You can see that the current class (PageContextImpl) was loaded by a container
classloader (above the webapp CL).
You also see that commons-logging 1.1 used the context classloader to find an
implementation of Log.
Since the PageContextImpl class will never be unloaded while Tomcat runs, a
WebappClassLoader leak is the result.
> Classloader reference leak on Tomcat 5.5.17 with log4j in webapp
> ----------------------------------------------------------------
>
> Key: LOGGING-108
> URL: http://issues.apache.org/jira/browse/LOGGING-108
> Project: Commons Logging
> Type: Bug
> Versions: 1.1 Final
> Environment: JDK 1.5.0_07, Tomcat 5.5.17
> commons-logging-api-1.1.jar is configured for the Tomcat bootstrap
> commons-logging-adapters-1.1.jar is deployed with a webapp
> log4j-1.2.11 is deployed with webapp
> This is the configuration specifically described in the release notes for 1.1:
> " New jar file commons-logging-adapters-xxx.jar is now provided. This can be
> used to resolve class cast conflicts where parts of commons-logging are
> deployed via different classloaders. It is not expected to be frequently
> used; it is only necessary in situations where a container has deployed
> commons-logging-api.jar and a webapp wants to bind to a third-party
> logging implementation such as log4j. In this case, the webapp can
> experience problems if it deploys commons-logging.jar as this causes
> duplicates of the core commons-logging classes, but commons-logging-adapters
> can be safely used."
> Reporter: Taras Tielkes
> Attachments: path.gif
>
> Some Tomcat Jasper implementation classes are initialized (that mean static
> fields and static initializer) when the current thread has the webapp
> classloader set as the context classloader.
> An example of this is org.apache.jasper.runtime.PageContextImpl
> If the first JSP page rendered on a freshly started Tomcat 5.5.17 is for a
> webapp that contains the configuration described in the "Environment" section
> above, a leak will occur:
> The class PageContextImpl (loader by CL above Webapp classloader in
> delegation chain) stays loaded for the duration of the JVM
> The "log" field in this class refers to a class loaded from a
> WebappClassloader.
> This produces a classloader reference leak to the webapp, even after
> undeployment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
