tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Shaw <>
Subject FAQ? JDK 1.4 Logging in Tomcat - long and discussive
Date Mon, 16 Jun 2003 23:36:41 GMT
Feedback welcome - I've been working on this without much help, and 
others may well have more experience (which I'd like to benefit from too).
I would love to use a better approach than that described here ...

I needed to be able to log my various (multiple-context) web apps. As I 
couldn't get commons-logging to work with the JDK 1.4 logging, I went 
the 'direct' route ... and it turns out it wasn't the commons-logging 
that was the 'problem'. 'Logging' below refers to the JDK 1.4 
java.util.logging facility ...

Most of the stuff on the web just takes you through the api, and shows 
how easy it is to get logging to work.
That's fine - it actually is fairly easy to program to.

However ...

Running Tomcat, I wanted multiple applications logging to different 
areas (files and/or db etc), and I started to run into difficult behaviour.

The problem I had was to load my logging configurations into the 
LogManager - not the mechanism, but the practice. This is a singleton, 
within the scope of the bootstrap class loader. Consequently, the same 
object is shared across all contexts (and Tomcat itself). This means 
that resetting it and then loading an app-specific config file is not an 
option. Loading an app-specific properties file is an option (via 
getResourceAsStream), but that has the further restriction that each 
web-app has to have a distinct namespace (see below). The properties 
file is not very functional anyway - it specifies defaults for defaults!

There is a 'config' option, which allows you to specify a Class for 
logging initialisation ... but this class has to be accessible from the 
bootstrap loader (common/lib, shared/lib ... nope! - it's gotta be in 

Ideally, I would like to be able to supply an app-specific logging 
configuration file as part of the deployment of my web-app. Potentially, 
this could be done by loading a data-file from the context and 
interpreting it to provide the appropriate logging structure (loggers, 
handlers etc).

But ... I have controller servlets in different contexts extending the 
same class from a 'utility' jar (implementing the Command pattern for 
Servlets). Most of the code is in the super-class (action class 
retrieval/activation etc).
Following the logging examples, using the class name as the logging 
context, and making the log variable visible (protected) down to the 
sub-classes, I end up with multiple log files (logging expands the %u to 
provide a unique filename when it can't open[?] the file ... I don't 
even want to guess what it does when the %u isn't given).
Additionally, I can't find a way to determine whether the logging had 
been initialised for a given context.
This means that (IMHO) utility classes cannot log!

I have ended up by extending the mechanism, in the 
time-honoured way, by adding '.' separated properties for each 
logging-context :
eg <context>.handler.level = INFO
    <context>.handler.class =<app>.DBHandler
These are then added into the (system-wide) file, and 
the Class which interprets them is specified in the config and has to be 
jar'd into the jre/lib/ext.
Additionally, I have removed all logging-system stuff from my utility 
classes. I only get a Logger when I have a sufficiently unique path to 
guarantee no conflicts.

This gives me the flexibility I need to log multiple apps in an 
appserver (tomcat) environment ... but I'm not very happy with it. It 
could be refactored to allow each context's Controller to load their own 
properties, and then interpret those (on my list of things to do), but 
this relies on calling a log-initialisation routine ... not something I 
want to do within 'client' JSP's (which live in another context). I have 
put JSP's into a different package (component separation - no problem), 
so the current setup allows me to specify that package as a root for 
which logging is enabled ... but this would not work without 
initialisation code unless I used the 'config' class approach.

An additional restriction is still that I cannot log directly from the 
utility super-class. I have to create log variables at the concrete level.

Summary : I don't think jdk 1.4 logging has come of age - it's nice and 
simple from the API POV ... but in real world usage it's lacking.

Please tell me I've missed something simple ;-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message