Remy Maucherat wrote:
Jess Holle wrote:
Jess Holle wrote:
Okay, I did a bit more digging.
*If*:
* Your web app contains log4j.jar *and* commons-logging.jar. * You do not have log4j installed in any of Tomcat's own lib directories. * You use a JNDI or other contextual classloader based LogRepositorySelector.
*Then*:
* The first Tomcat web application will "steal" loggers from the Tomcat base, i.e. any that happen to be obtained while the first web app's contextual classloader is active. o In a brief, simple test, whichever web app receives the first JSP page request will "steal" the following Tomcat loggers: + org.apache.jasper.compiler.Compiler + org.apache.jasper.compiler.JspReader + org.apache.jasper.runtime.PageContextImpl + org.apache.jasper.servlet.JspServletWrapper + org.apache.jasper.xmlparser.ParserUtils * By "steal", I mean that these loggers end up in the LoggerRepository of the given web app. Their configuration is thus controlled by it. Also, they use the log4j library from the given web app.
There's nothing unexpected here: Jasper is a regular servlet, and thus all of its classes will be loaded with the webapp's classloader. It's basically like if you had the Jasper JARs inside /WEB-INF/lib. The problem then is that Jasper uses static logger instances, while it should either log to the servlet context or have per instance loggers, as it resides in a classloader shared across webapps. Regardless of what happens, we will need to cleanup Jasper's logging behavior.
What's unexpected here is as you say that these loggers are static -- or in any event not per-web-app. Otherwise, this behavior would be fine and good!
Another completely different strategy for acquiring loggers is to use the CL which loaded the class (ie, to use straight delegation). There's the problem that it could cause classcast exceptions, however, and it's more annoying to configure.
Both solutions behave differently, but they have their own merits. I happen to prefer the context classloader oriented one in a J2EE environment (so it was used for the java.util.logging implementation I added recently based on some user submitted code that I heavily modfied - see http://issues.apache.org/bugzilla/show_bug.cgi?id=33143).
Yes, I now have both approaches coded and as you say both have their merits. If the instances wherein Tomcat loggers configured/obtained from one web app are used across web apps are eliminated in Tomcat 5.5.x, then I could happily use the JNDI/J2EE approach and all Tomcat's own loggers for each web app would use that web app's configuration. Otherwise I really have to go with the straight delegation approach to prevent cross-web-app logger effects.
-- Jess Holle
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
