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 Fri, 18 Mar 2005 02:38:04 GMT
Remy Maucherat wrote:

> Jess Holle wrote:
>> Why out of curiosity?  I don't have a pro-UGLI ax to grind here, but 
>> Commons-Logging's behavior in Tomcat is really undesirable as is.
> It would be the same anyway: the loading configuration and the logger 
> instances will be tied to the webapp classloader. It has to work this 
> way. As I understand it, the thing that does not work for you right 
> now is that Tomcat uses your webapp's logger namespace before your 
> callbacks are called.

Yes.  The issue is really that Tomcat uses log4j out of my web app for 
loggers that are to be used outside my web app.  Not only is the library 
used out of my web app but so is the configuration -- meaning web app A 
gets core Tomcat log output from web apps B and C...

Yoav confirmed that the solution is to move log4j and a default 
configuration higher in the stack so that everything uses it.  This 
together with a per-web-app ClassLoader (but not contextual 
classloader!) based LoggerRepository will ensure each web app gets its 
own loggers and configuration files and Tomcat core gets its own.

>> Now if you're inside JBoss and it has pre-established log4j and 
>> configured it prior to Tomcat loading, then I don't see a problem 
>> with Commons Logging.  Standalone Tomcat's Commons Logging behavior 
>> vis-a-vis log4j would seem to be an issue, though.  The issues are 
>> especially bad and bizarre when log4j is used in a web app but Tomcat 
>> itself does not have log4j installed, but this is only part of the 
>> issue.
> I don't see any real difference. There should be plenty of container 
> listeners and stuff available to configure this.
> (I see Bill just mentioned conf/tomcat5-mbeans.xml but I have no clue 
> what it is)

The nice thing about this as I understand it is that it would allow me 
to set up my own MBeans for a Tomcat-level / app-wide log4j 

You're right, though, as far as per-web-app MBeans and 
LoggerRepository's -- there are more than enough servlet listeners, etc, 
in the servlet spec to handle this.

> BTW, JBoss (supposedly, I didn't check personally) uses 
> commons-logging everywhere, and the logging implementation used is log4j.

That works since *everything* uses log4j.  The issue is with Tomcat is 
really one of *not* having log4j at the Tomcat level but having it in 
your web app.  This leads to:

    * whole crop of loggers using java.util.logging (fine, to be
      expected, and there are Java 5 MBeans -- albeit limited -- to
      interact with these)
    * a few core Tomcat loggers that are *not* by nature per web app
      loggers using the log4j jar and configuration of the first web app
      that uses the class enclosing them (e.g. the first web app to get
      a request!)
    * the web app's own classes using whatever you specify

It is the 2nd of these 3 bullet that is so disturbing to me.  I'd like 
to see these either have separate loggers for each web app, or behave 
like the rest the Tomcat loggers and cause a leak of data and references 
between web apps.  This -- and a reasonable set of MBeans to 
control/expose loggers seems quite doable with the approach Yoav and 
Bill laid out.  It's just unfortunate that the out-of-the-box behavior 
with web apps using log4j is so onerous.

Jess Holle

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message