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.
-- Jess Holle
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
