Current status is running with class that is a rip-off from Log4JLogger
with the trace() and isTraceEnabled() methods changed to the behavior I
want. I define this class in a system property and it works.
But I don't think you understand my point. If, instead of doing that, I
would subclass your revised non-final Log4JLogger (instead of copying
it), there are many methods I'm not overriding which have
implementations like this:
/**
* Log a message to the Log4j Logger with <code>DEBUG</code>
priority.
*/
public void debug(Object message) {
getLogger().log(FQCN, Priority.DEBUG, message, null);
}
which reference the private Log4jLogger member variable FQCN
which is defined as
/** The fully qualified name of the Log4JLogger class. */
private static final String FQCN = Log4JLogger.class.getName();
I don't know what the log method does with the FQCN parameter (that's
buried in log4j code somewhere) but I don't see how it can be good to
supply the wrong name.
This isn't a problem in my copied class because I changed the variable
declaration to
private static final String FQCN =
NoOpTraceLog4JLogger.class.getName();
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 12:23 PM
To: Jakarta Commons Users List
Subject: Re: DEBUG vs. TRACE under Log4JLogger
Steve Cohen wrote:
>Actually, in looking at the code, it seems as though subclassing might
>not be enough, anyway. There's also the issue of the FQCN variable
>which, if merely subclassing, would contain an incorrect value. I
>don't know how this might affect the functioning of the system, but it
>does make me think that rolling my own might be safer, pending your
>explanation of how this is used.
>
Have you tried the configuration mechanism I described in my previous
message (Put an "org.apache.commons.logging.Log" property setting in
either "commons-logging.properties" in your webapp's /WEB-INF/classes
directory, or in the container classpath, or in a system property)?
Craig
>
>-----Original Message-----
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 02, 2003 11:17 AM
>To: Jakarta Commons Users List
>Subject: Re: DEBUG vs. TRACE under Log4JLogger
>
>
>Steve Cohen wrote:
>
>
>
>>Actually, I can't do what you suggest. Log4JLogger is declared final.
>>So only the "create your own" option will work.
>>
>>
>>
>Yuck. Fixed in tonight's nightly build (20031003).
>
>Craig
>
>
>
>>-----Original Message-----
>>From: Steve Cohen
>>Sent: Thursday, October 02, 2003 6:19 AM
>>To: Jakarta Commons Users List; Jakarta Commons Users List
>>Subject: RE: DEBUG vs. TRACE under Log4JLogger
>>
>>
>>
>>OK, I stand corrected. I was the victim of my own misunderstanding.
>>I
>>
>>
>
>
>
>>will do what you suggest. Thanks.
>>
>>-----Original Message-----
>>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
>>Sent: Thu 10/2/2003 12:21 AM
>>To: Jakarta Commons Users List
>>Cc:
>>Subject: Re: DEBUG vs. TRACE under Log4JLogger
>>Steve Cohen wrote:
>>
>>
>>
>>
>>
>>>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.
>>>
>>>
>>>
>>>
>>>
>>>
>>A 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.
>>
>>http://cvs.apache.org/viewcvs/jakarta-commons/logging/src/java/org/apa
>>c
>>h
>>e/commons/logging/impl/
>>
>>
>>
>>
>>
>>>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.
>>>
>>>
>>>
>>>
>>>
>>We do give you this option -- implement a subclass of Log4JLogger (or
>>create your own -- it's pretty simple) and use that instead.
>>
>>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]
>>
>>
>>---------------------------------------------------------------------
>>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]
>
>
>---------------------------------------------------------------------
>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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
