tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Logging Issues
Date Thu, 08 Mar 2001 23:47:11 GMT
Hi Thomas,

It would be great if you can help adding log4j support in tomcat3.3.

My only problem ( and I'm very strong about this ) is that I don't like
the "only one way to implement something" aproach. Log4j has great
features, I like the code - but it's not the solution for all cases. 

I already did a refactoring of the logging code in 3.3, and now the actual
implementation ( the Queue logger ) is cleanly separated, and tomcat is
using only the util.Log base class. ( the main purpose of refactoring was
exactly this - allow support for log4j and java.log and any other logger).

Remember, tomcat can be embeded in different applications - and it's
important to be able to use the application native logger. And tomcat can
be run in environments where code size is important - and it this case the
current logger is a better solution. Saying "there is only one logger" is

> 2. I am sure that the issues of logging and log4j have been raised
> before.   Clearly logging is a critical function
>  of any servlet engine.   So here it is folks:  If the consensus was
> that log4j was the way to go, I'd be willing to volunteer to  fight

I don't think the "consensus" is that log4j is the "way to go", but "one
way to go".

If you want to plug log4j, one way would be to:

1. Create an adapter between tomcat.util.Log and log4j.
Log is the only class that is used by tomcat, and should be used to plug 
any logger.

2. Create a Log4JInterceptor ( you can use LogSetter as model - it's the
only place where implementation-specific code is present ). You can also
use it to configure it ( or at least pass the log4j config file ). This
will setup log4j and set the adapter into tomcat.

3. Create the admin page or anything else that will make the life easier
for the user.

Of course, this is not the only way to do it :-) 

I would be very much against making this the "default" for 3.3 - we don't
have the time and resources to test it, and the current logger has been
used for a long time, and it's much simpler to configure and debug (
since it doesn't have any fancy feature ).


To unsubscribe, e-mail:
For additional commands, email:

View raw message