tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Web apps vs. Logging vs. Tomcat
Date Sat, 19 Mar 2005 16:06:49 GMT
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.

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

> I could always be mistaken, but my examination of the LoggerRepository's 
> involved seems pretty conclusive.
> If one has to have log4j and commons-logging in one's web app, then the 
> only solution appears to be to put log4j in Tomcat and use a 
> non-contextual classloader based LogRepositorySelector.  Avoiding the 
> contextual classloader based LogRepositorySelector only keeps Tomcats 
> loggers from sharing the web app's intended LoggerRepository -- they 
> still use the web app's log4j and its default LoggerRepository.


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

View raw message