[logback-user] [SPAM] - Re: - Context selectors useful? - Email found insubject - Email found in subject

[Lucas, Casey]

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

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 at qos.ch
http://qos.ch/mailman/listinfo/logback-user