Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 94740 invoked from network); 2 Oct 2003 17:24:39 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Oct 2003 17:24:39 -0000 Received: (qmail 4150 invoked by uid 500); 2 Oct 2003 17:24:26 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 4125 invoked by uid 500); 2 Oct 2003 17:24:26 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 4112 invoked from network); 2 Oct 2003 17:24:26 -0000 Received: from unknown (HELO smtp.easystreet.com) (206.26.36.40) by daedalus.apache.org with SMTP; 2 Oct 2003 17:24:26 -0000 Received: from apache.org (dsl-208-161-106-6.dsl.easystreet.com [208.161.106.6]) by smtp.easystreet.com (Postfix) with ESMTP id 1A1CA84535A for ; Thu, 2 Oct 2003 10:24:30 -0700 (PDT) Message-ID: <3F7C5F10.5050204@apache.org> Date: Thu, 02 Oct 2003 10:23:28 -0700 From: "Craig R. McClanahan" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Users List Subject: Re: DEBUG vs. TRACE under Log4JLogger References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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:craigmcc@apache.org] >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:craigmcc@apache.org] >>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/apac >>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: commons-user-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: commons-user-help@jakarta.apache.org >> >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: commons-user-help@jakarta.apache.org >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: commons-user-help@jakarta.apache.org >> >> >> >> > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: commons-user-help@jakarta.apache.org > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: commons-user-help@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org