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: http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 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 http://logging.apache.org/log4j/docs/documentation.html has some interesting links. In particular, here's a link to how log4j provides separate configuration for each webapp: http://www.qos.ch/logging/sc.jsp 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
