We haven't looked into j.u.l over logback, but once we upgrade to tomcat 6 we'll likely want tomcat logging controlled by logback. I assume we may have similar initialization concerns once we upgrade to tomcat 6. casey -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Ceki Gulcu Sent: Thursday, November 27, 2008 3:56 AM To: logback users list Subject: [SPAM] - Re: [logback-user] - Context selectors useful? - Email found insubject - Email found in subject Hello Lucas, Thank you for your detailed and helpful response. Web-applications can accomplish logging isolation by simply embarking their own copy of slf4j-api.jar and logback-*jar under WEB-INF/lib. As for Tomcat's own logging, Tomcat 6 no longer uses commons-logging, they use the j.u.l. instead. This circumvents a major problem occurring in the Tomcat 5.x series which leaked commons-logging loggers into the web-applications it hosted, preventing their proper garbage collection. Anyway, assuming you can upgrade to Tomcat 6 and can live with jul logging for Tomcat, logging separation for web-applications can be accomplished by embarking slf4j and logback in each of your web-apps. Do you think the above would work for you? Lucas, Casey wrote:
For our web applications deployed within tomcat 5.x we use a custom context selector to allow use of multiple independent logback configurations and implementations. We use logback for tomcat internal logging (via commons logging over slf4j) and application level logging. Each web application and tomcat has it's own logback configuration file, own set of logback related jars and is separately controllable via JMX. We did not put any logback, slf4j, etc. related jars into TOMCAT_HOME/common/lib - instead they are in TOMCAT_HOME/server/lib.
The high level of isolation simplifies our development and deployment practices. In general, we did not want any logging related jar or configuration dependencies between tomcat and the multiple web applications. We accomplished our isolation goals by developing a custom ContextSelector, however if there were different or better options for isolation we would look at those. In other words, we're not set on using a ContextSelector implementation - we just want strict isolation.
I should mention that we potentially don't use ContextSelector in its originally intended manner. We tried the JNDI based ContextSelector that ships with logback, but JNDI is not available when tomcat starts doing internal logging so we had trouble separating tomcat logging from application level logging when using the JNDI ContextSelector. Anyway, our ContextSelector implementation boils down to using a classpath-based resource for logging configuration. We don't really do any dynamic context selection like that of ch.qos.logback...LoggerContextFilter.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user