commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject [logging] commons-logging and j2ee
Date Sun, 20 Mar 2005 00:12:19 GMT
Some significant discussion re logging in j2ee/servlet-engine
environments is occurring in tomcat and log4j at the moment.

I thought I'd just provide references to some of these for people
interested in following this issue:

There's also an email exchange going on on the tomcat-dev list, with
subject "Web apps vs. Logging vs. Tomcat" though I can't find it in the
email archives.


The page has
some interesting links. 

In particular, here's a link to how log4j provides separate
configuration for each webapp:

Option 1: deploy log4j.jar at the WEB-INF/lib level, and ensure that
child-first classloading is selected. This results in a completely
separate copy of log4j being loaded per webapp, hence complete logging
isolation per webapp.

Option 2: have log4j.jar loaded via a "shared" classloader, and have the
container set up a ContextualRepositorySelector.

log4j's ContextualRepositorySelector class keeps a Map keyed by
context-classloader, just like JCL's LogFactory (v1.0.4) does, and hence
has the same limitation: a memory leak on undeploy unless the component
or the container explicitly "clears" the configuration when it is
undeployed. The log4j team get around this issue by *assuming* that the
container will explicitly implement log4j-awareness. In other words, a
webapp that uses log4j will not properly integrate with its container
unless the container is explicitly written to use log4j.

This issue is exactly the one that JCL 1.0.5 attempts to resolve using
weak references; log4j just don't bother.

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

View raw message