[logback-user] separate configs for each web app and tomcat
clucas at e-miles.com
Tue Jul 15 15:47:44 CEST 2008
Since there has been some recent discussion of tomcat, slf4j,
jcl-over-slf4j and logback combinations, this account of how
we solved our problem may be useful to some.... or maybe
someone has a better way.
- use a standard (within our organization) java logging
- have logging for each application be separately configurable
but share a common syntax (so we wouldn't have to remember
all different configuration details)
- use the same logging implementation for tomcat
- support existing applications that send throttled email
alerts (log4j based)
- we had some other desires but the above are important for
We used logback, slf4j, log4j-over-slf4j, and jcl-over-slf4j
in combination with a custom logback context selector.
We ran into similar problems as others have mentioned. Once
we included jcl-over-slf4j in tomcat, we had initialization
problems. We tried the JNDI context selector but it didn't
work. Basically, as tomcat is loading a web app, it attempts
some logging (using jcl) before it sets up the jndi context.
As soon as the first logging statement is run, logback will
be initialized. Since it cant use any jndi information,
it uses the default initialization process. This default
initialization process is not very useful when you want to
have a per application (and tomcat) logback configuration.
We ended up writing a logback context loader that loads
it's configuration based on classpath resources. Then we
placed tomcat specific files in tomcat/server/lib and
tomcat/server/classes (vs. tomcat/common). By placing in
tomcat/server, web apps can't see the tomcat specific
configs and jars. Each web application then placed it's
logging jars and configuration files in their own WEB-INF.
Benefits of this configuration:
- tomcat and each web app can have their own logging
- each logback context can be managed separately via JMX
Hope this helps someone.
More information about the Logback-user