Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 80335 invoked from network); 23 Jul 2002 18:19:27 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Jul 2002 18:19:27 -0000 Received: (qmail 27371 invoked by uid 97); 23 Jul 2002 18:19:46 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 27294 invoked by uid 97); 23 Jul 2002 18:19:44 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 27273 invoked by uid 98); 23 Jul 2002 18:19:43 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) To: "Jakarta Commons Developers List" MIME-Version: 1.0 Subject: Re: [logging] Better support for stack walking X-Mailer: Lotus Notes Build V60_M13_04302002 Pre-release 2 April 30, 2002 From: rsitze@us.ibm.com Message-ID: Date: Tue, 23 Jul 2002 13:19:21 -0500 X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/23/2002 14:19:22, Serialize complete at 07/23/2002 14:19:22 Content-Type: text/plain; charset="US-ASCII" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hmm... see-saw.. Let's consider this in the broader scope of multipel components and/or service discovery (commons.discovery). Since it's my intent to replace most of the LogFactory logic with calls to Discovery, I'd like to find a solution that works for both. So, let me lay down my thoughts: 1. For Log4J at least, the wrapper class is 'given' to the logger implementation via a constructor argument. 1.a. Log.setLogWrapper/setAttribute isn't enough. Putting aside design/style arguments, it's to late. Granted this COULD be worked around by defering Log implementation creation... but that does create a bit more complexity and overhead. I can accept that when it's required, but I wouldn't want that to be the general case/rule. 1.b. the Factory should be able to have knowledge of the wrapper class, as a general rule. 1.c. The factory could gain knowledge using any of setWrapper, setAttribute, or getInstance(Class wrapper, [String | Class] cat); 2. In an environment where we have multiple components using commons-logging, some may wrap - others may not. A Factory.setAttribute is dangerous here (it's potentially 'global' across multiple components). Note also the the attributes are (pre-)loaded out of a properties file. 3. We need an analogous method (setWrapper or setAttribute) for the Discovery mechanism. A requirement for 'setWrapper' would seem to be fairly specific to logging, it doesn't appear to be generally useful in a 'discovery' tool. (2) is a strong vote for 'LogFactory.getInstance(Class wrapper, [String|Class] cat)', in addition to the current 'getInstance' methods - and a vote against a 'setAttribute' in a singleton (global) Factory. (3) is a strong vote for 'getAttribute' and a vote against special setters. Stepping back from this, I believe that there is a good case for multiple factory instances - one per component. [Currently LogFactory/Discovery cache factories by ClassLoader.] I think that this situation is a good justification for creating component-specific factories. We can still cache, but can do so by a ClassLoader/ComponentID combination. Note that this would also allow us to qualify a service parameter file: axis.commons-logging.properties versus wsif.commons-logging.properties. ******************************************* Richard A. Sitze IBM WebSphere WebServices Development costinm@covalent.net wrote: > This is a problem we have on tomcat, as part of the transition > to commons-logging. We would like to be able to preserve the > existing Logger interface, for backward compatibility and to > allow a smoother transition. > > The problem is that the current implementation of the adapters > will report the class/method who called commons-logging ( i.e. > Logger ). > > There are few possible solutions, with little or no effect on > the API. > > The first is to use LogFactory.setAttribute() to pass the information > about the 'wrapper class'. This will be used in walking the > stack trace or passed to log4j ( or other logger impl. that > support this ). No API change will be needed. > > An alternative is to add a setAttribute() method to Log, or > to add a specialised setWrapperClass() to Log. This will allow > the stack filter to be specified for each log. > > What do you think ? We do have a real need for this feature - > and the impact on API is very small. If it does work, I'd go with the "no API change" solution ;-) You have my non binding +1. Remy -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: