tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Web apps vs. Logging vs. Tomcat
Date Fri, 18 Mar 2005 12:39:53 GMT
Jess Holle wrote:
> 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.

Yes, the logging namespaces need to be separate. I was faced with the 
issue very recently when writing a log manager for java.util.logging 
which would have a separate logger namespace for each classloader.

>>> 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 
> LoggerRepository.
> 
> 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.

The core loggers you talk about are probably the ones used for reporting 
your servlets/filters/etc loading errors. This seems webapp related to me.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message