commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject Re: [logging] Better support for stack walking
Date Tue, 23 Jul 2002 18:19:21 GMT
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.

<ras>


*******************************************
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message