On Wed, 02 Mar 2005 09:21:08 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: > > On Mar 1, 2005, at 6:45 PM, Remy Maucherat wrote: > > On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert > > <[EMAIL PROTECTED]> wrote: > >> However, I can't seem to find the right combination of > >> log4j.properties > >> lines, or maybe I'm trying something impossible. (I can't find good > >> docs on the uses of log4j.properties when used inside the hierarchical > >> classloading context that tomcat provides.) What keeps happening is > >> that the webapp's log statements keep going into the global tomcat > >> log. > >> Would I be better off with JDK logging instead? > > > > I am working at the moment on a small package (which will be an > > implementation of java.util.logging) which will allow you doing that > > using the JDK logging. The main issue with it as supplied in the JDK > > is that there is only one global configuration per JVM. The trick is > > to make that per classloader, with delegation, so that webapps are > > isolated. At the moment, I think log4j is your only choice > > (unfortunately, I'm no expert, so I can't give you tricks with this > > particular configuration). > > > > In the same package, I will also provide a handler with daily rotation. > > > > It should be done by the end of the week (it doesn't work at the > > moment, I'm busy debugging ;) ). > > Great news. I'm happy to help test this. I'd rather use JDK logging > than log4j if possible to avoid an additional deployment dependency.
Actually, this is still an extra dependency: you have to add a JAR (10KB at the moment, but it'll likely grow to 12KB once I finish the needed extensions to the standard java.util.logging) for the core (the LogManager) and the rotating file handler (the JDK impl's handler don't have anything which rotates). It works by providing a replacement impementation for the JDK's LogManager which keeps a per classloader set of loggers. This is configured using a per classloader logging.properties (same format as the main logging.properties of the JDK, but with a few additional tricks to allow more flexibility with defining handlers and assigning them to loggers whenever needed). Properties files are simple, and are a good default. If no logging.properties exist anywhere, the JDK configuration will be used. Support for other configuration sources can be done using separate LogManager implementations. At the moment, the code will live in the Tomcat CVS, but the general consensus is to migrate it to commons eventually. We'll see. I don't know either if it will be included in the Tomcat binary; at the moment, I'd say it will not. The "seed" code for the new LogManager (which is attached to bug 33143) is here: http://issues.apache.org/bugzilla/attachment.cgi?id=14036 It doesn't actually work, and all it does is separate logger instances (which is quite good already, as you can programmatically set levels, assign handlers, etc, but you need to code for java.util.logging to use that). So I'm working on extending it at the moment to allow non programmatical configuration, where your webapp can simply be coded for commons-logging. -- xxxxxxxxxxxxxxxxxxxxxxxxx Rémy Maucherat Developer & Consultant JBoss Group (Europe) SàRL xxxxxxxxxxxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
