[logback-user] [SPAM] - Re: - Context selectors useful? - Email found insubject - Email found in subject
clucas at e-miles.com
Mon Dec 1 18:04:32 CET 2008
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.
From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at 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
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
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
> 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
Logback: The reliable, generic, fast and flexible logging framework for Java.
Logback-user mailing list
Logback-user at qos.ch
More information about the Logback-user