tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject PROPOSAL: Consistent logging ( for 3.x, 4.x )
Date Wed, 05 Jun 2002 18:19:39 GMT

At the moment we have about 4 logger APIs in use:
- commons logging - in coyote and jk
- 3.3 o.a.t.util.Log in some utils and tomcat3.3
- catalina Logger in 4.x 
- jasper's Logger used in jasper

We have about 5 different implementations:
- one for 3.3 Log and one for catalina Logger. Both had a number
of optimizations and specific features
- one for jasper. 
- log4j or jdk1.4 - when commons-logging is used.

We have about 5 different config mechanisms we have to know about:
- jdk1.4
- server.xml ( one for each version )
- jasper still uses params on the servlet to tune the level.

What I'm proposing is to gradually cut down to one logger API
( commons-logging ) and the 2 major implementations ( log4j and
jdk1.4 ) and the associated ( and well-documented/well known )
config files.

This may take a long time, but there are few steps that we 
can ( should ) take for the next releases ( 4.1.0 and 3.3.3 ).
Most of those are cosmetic ( i.e. minimal code changes ):

1. Include log4j.jar in the distributions. 

2. In util, make o.a.t.util.Log use commons-logging as backend
by default.

3. In 3.3, remove the configs for queue-logging. That will make
all 3.3 use the default logger, which in turns use commons-logging.

4. Eventually provide a small fix in 4.x so that LoggerBase 
defaults to commons-logging if no other logger is specified,
and don't specify any logger in the config file.

5. Same for jasper ( that's the most urgent, as it's logger
is the worst ).

In all cases the explicit setting in server.xml will activate 
the current logger.

Long term ( for next releases ):

- replace the use of the old loggers to direct calls to commons-log.

- other advanced stuff, like advanced configurations 

Opinions ?


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

View raw message