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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
