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: - log4j.properties - 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 ? Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
