Well, I understand what you're saying, but now I've had the nastyA browse through the CVS history of Log4JLogger (and its predecessor, Log4JCategoryLog) will show that the Log4J wrapper has *always* mapped TRACE level output to Log4J's DEBUG level output, from the very beginning.
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.
http://cvs.apache.org/viewcvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/
We do give you this option -- implement a subclass of Log4JLogger (or create your own -- it's pretty simple) and use that instead.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.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
