commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: DEBUG vs. TRACE under Log4JLogger
Date Wed, 01 Oct 2003 22:20:56 GMT
Well, I understand what you're saying, but now I've had the nasty
surprise of upgrading to 1.0.3 under the assumption that TRACE would be
a no-op under log4j only to find that it's been redefined out from under
me.  You haven't commented on my question as to whether that's the way
it used to work but I have a pretty strong remembrance that that's what
it did.  I remember a pretty nasty RTFM from the Log4j people when I
asked them why trace() did nothing.  

Unfortunately I can't find the old docs.

I still don't see what the problem would be in giving the user the
NON-DEFAULT option of treating trace as a no-op.  However, I guess I can
do what you suggest without too much difficulty.

-----Original Message-----
From: Craig R. McClanahan [] 
Sent: Wednesday, October 01, 2003 4:26 PM
To: Jakarta Commons Users List
Subject: Re: DEBUG vs. TRACE under Log4JLogger

Steve Cohen wrote:

>In commons-logging-1.0.3, it seems that the package has been configured

>so that if a commons-logging Log4JLogger is in use, TRACE is treated 
>exactly as if the code said DEBUG.  This is true for isTraceEnabled() 
>as well.
>I may be remembering wrong, but I think I remember that in past 
>versions it didn't work that way.  In a Log4JLogger isTraceEnabled 
>simply returned FALSE and TRACE logging statements did nothing.
Log4J itself doesn't itself support the notion of trace-level 
debugging.  Therefore, we chose to map Log.trace() to the nearest 
reasonable thing.

>I actually have a use case where I would like commons-logging to 
>function that way. That use case is in JUnit testing where the JUnit 
>test runs under SimpleLogger, but when the application is deployed, it 
>uses log4j and I would like all the trace messages to be silent in that

>However, this is not the way 1.0.3 works.  Contrary to my 
>expressed-in-code wishes to have two separate levels, it promotes my 
>TRACE statements to be DEBUG statements.
Doing what you suggest would be a really nasty surprise to people who 
developed their apps with trace level debugging (because JDK 1.4 or 
SimpleLog both support it) an then try to run that app with Log4J.  All 
their trace level logs would disappear.  Therefore, I'm -1 on doing what

you propose in the standard release.

>Is there some way to defeat this in commons-logging 1.0.3?  I don't 
>seem to find one in the docs.  I would like to have this "feature" be 
>configurable off.

Nothing stops you from creating your own modified implementation of 
Log4JLogger that behaves the way you want, and set the right config 
property (org.apache.commons.logging.Log) so that your implementation 
gets picked up instead of the standard one.


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

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

View raw message