commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <>
Subject [jira] Commented: (LOGGING-108) Classloader reference leak on Tomcat 5.5.17 with log4j in webapp
Date Fri, 21 Jul 2006 01:38:17 GMT
    [ ] 
Simon Kitching commented on LOGGING-108:

Thanks for reporting this. Your analyis is excellent, thanks.

however I think this is really the responsibility of the tomcat/jasper team to fix, though.
As you say, jasper classes present in the container classpath contain static references to
Log objects, and this is just plain wrong:

Any sane logging library is going to have problems if this is done. The fix is probably to
make that Log member non-static.

One solution is to remove all commons-logging libs from the webapp completely (and ensure
log4j is deployed at the container level). In this setup, the only log4j adapter class (Log4JLogger)
is the one loaded by the container classloader so its existence won't lock the webapp classloader.
However that does mean you lose the ability to configure your logging per-webapp.

Actually, log4j does have its own approach to providing per-webapp configurability, even when
only one instance of log4j is in the classpath. See:
Here's another example using log4j's hierachy stuff:

In both cases, the code doesn't look quite right to me; It holds a HashMap keyed by context
classloader, so that will effectively lock the webapp classloader :-). A weak hashmap should
do the trick though, in most cases. Or a ContextListener in your webapp that calls a method
on the selector class to clear out the entry for the webapp classloader.

> Classloader reference leak on Tomcat 5.5.17 with log4j in webapp
> ----------------------------------------------------------------
>                 Key: LOGGING-108
>                 URL:
>             Project: Commons Logging
>          Issue Type: Bug
>    Affects 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
> 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