commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taras Tielkes (JIRA)" <>
Subject [jira] Created: (LOGGING-108) Classloader reference leak on Tomcat 5.5.17 with log4j in webapp
Date Tue, 27 Jun 2006 18:48:29 GMT
Classloader reference leak on Tomcat 5.5.17 with log4j in webapp

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

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:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message