Howdy, You haven't missed something simple. In fact, I'd venture you've spent more time and thought (and reached better conclusions and solutions) that most people who've considered the problem.
Ditch JDK 1.4 logging. Use log4j. Everything you want here can be done using log4j's Repository Selector: and it's even done for you for a webapp/context environment such as tomcat in Jacob Kjome's servlet context repository selector, currently available in the log4j sandbox and slated for inclusion in log4j 1.2.x. Yoav Shapira --- Tim Shaw <[EMAIL PROTECTED]> wrote: > 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 > jre/lib/ext). > > 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 logging.properties mechanism, in the > time-honoured way, by adding '.' separated properties for each > logging-context : > eg <context>.handler.level = INFO > <context>.handler.class = com.xxx.<app>.DBHandler > etc > These are then added into the (system-wide) logging.properties 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 ;-) > > tim > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ===== Yoav Shapira [EMAIL PROTECTED] __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
