tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: Web apps vs. Logging vs. Tomcat
Date Sat, 19 Mar 2005 18:03:50 GMT
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

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:
For additional commands, e-mail:

View raw message