[logging] Better support for stack walking

[co...@covalent.net]

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. 

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [logging] Better support for stack walking

[Remy Maucherat <re...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>