Logging Issues

[Thomas Riemer <to...@58k.com>]

Here's a couple of thoughts/notes on logging:  (3_3_1_m1)

1. I ran into a problem with mod_jk where I got hideous performance once
my mod_jk log file got up over a certain
size.  (requests that normally take 1200 ms, taking 12,000 ms).   The
solution seemed to be to pare down
mod_jk logging to a bare minimum.   It looked like mod_jk was doing a
complete scan of the log each time
it wrote something to it.

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
through the issues and make the changes to A) get the 3.3 line to use
log4j  B) provide reasonable configuration files for log4j and C) Write
a generic admin configurator to spit out a simplistic version of a log4j
configuration file for  tomcat.    I've been impressed with log4j to
date.    I've recently gone through this process
with our own internal software here.  Its a tedious editting chore, but
generally a no brainer.

-Tom



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org

Re: Logging Issues

[cm...@yahoo.com]

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
wrong. 


> 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 ).

Costin



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org