tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Web apps vs. Logging vs. Tomcat
Date Sat, 19 Mar 2005 01:57:23 GMT
Jess Holle wrote:

> Remy Maucherat wrote:
>
>>>> 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.
>
> Considering the classes containing these loggers are not per web app 
> as best I can tell I don't believe the loggers are, but I guess more 
> thorough debugging on my part is in order.  Perhaps I am mistaken and 
> these are Tomcat loggers, but are specific to my web app.

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.

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.

--
Jess Holle


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