tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: PROPOSAL: Consistent logging ( for 3.x, 4.x )
Date Thu, 06 Jun 2002 06:40:24 GMT
On Wed, 5 Jun 2002, Bill Barker wrote:

> At least in 3.3 land, I'm leaning to Remy's opinion.  It's going to be
> painful.  However,  I'm +1 (i.e. I'll help on the 3.3 stuff) .  As Remy
> points out, TINA.

Ok, what does 'TINA' mean :-) ???

I see your point, I'll play a bit more with the class loaders ( I'm using
log4j in common ). 

In JDK1.4 we don't have the option to move the logging in
the container loader :-), and at least log4j can be upgraded in common
at any time, not only when you upgrade the VM.

> 3.3.1 as recommended on the Coyote download page (tomcat-util.jar is in
> common, and commons-logging.jar is in container).  Now, commons-logging is
> pretty stable, so I don't have a problem with (like in 3.3.2-dev) putting it
> in common.  However, I really don't want to put log4j.jar in common since
> then it would over-ride the one in WEB-INF/lib.  This is almost as bad as
> putting JAXP in common.

I'll try to get it in container. It should work, except the messages that
are displayed before the logger is set up ( where the 'default' of 
commons-logging will be used ).

What I'm worried about is setting up the per/context loggers and where 
they'll write. I assume webapps using log4j will provide their own 
configuration, but how do we mix this with the global settings ? And 
how do we deal with the sandbox.

Fortunately ( or not ) JDK1.4 logger doesn't seem to care about security,
so why should we worry ...

Ok, it'll be more painfull than I thought - but still we should do it,
it's a mess.

> My first thought was to move o.a.t.u.log back to jakarta-tomcat, and convert
> the rest of o.a.t.u.** to commons-logging.  But this still has the same
> problems.....

> Now that recycling is working again, I'm very fond of qlog.  I'd like to be
> able to keep it as an option (as a plugin to commons-logging).

Long term I think o.a.t.u.log should be deprecated. I agree qlog is a nice 
( and quite efficient ) piece, so maybe it can be turned into a 
common-logging logger ( and so available to other apps ). 

The last thing we need is yet-another logging API ( o.a.t.u.log is 
probably older than most others, but that doesn't matter ). 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message