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 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 specifyIt 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
