Re: FAQ? JDK 1.4 Logging in Tomcat - long and discussive
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
Re: FAQ? JDK 1.4 Logging in Tomcat - long and discussive
Yoav Shapira [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. And I wasted all that time writing a repository selector for TC 3.3 ;-(. I'll take a look at Jacob's stuff. It was going to be my next project to port the 3.3 repository selector to TC 4.1.x/5.x, but if it has already been done. Of course, the same sort of thing could be done for JDK1.4 Logging if anyone was motivated enough. Patches are always welcome ;-). 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
