Log4J itself doesn't itself support the notion of trace-level debugging. Therefore, we chose to map Log.trace() to the nearest reasonable thing.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.
I actually have a use case where I would like commons-logging toDoing 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.
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
case.
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.
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.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
