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