tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <remy.mauche...@gmail.com>
Subject Re: How to approximate tomcat-5.0/4.x/3.x logging in 5.5?
Date Wed, 02 Mar 2005 15:01:10 GMT
On Wed, 02 Mar 2005 09:21:08 -0500, Adrian Robert
<arobert@cogsci.ucsd.edu> wrote:
> 
> On Mar 1, 2005, at 6:45 PM, Remy Maucherat wrote:
> > On Tue, 01 Mar 2005 18:18:49 -0500, Adrian Robert
> > <arobert@cogsci.ucsd.edu> 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message