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 [mailto:[EMAIL PROTECTED] 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 >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. > > 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. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
