tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Herrmann <...@jadn.com>
Subject Re: [Logging] more issues with stack reading
Date Thu, 25 Jul 2002 18:05:52 GMT
On Thu, 2002-07-25 at 13:15, costinm@covalent.net wrote:
> Ok, back to the subject of extracting the method name from the 
> stack trace.
> 
> The problem is actually a bit more complicated and I think we're
> doing the wrong thing at the moment, and all proposed solutions
> are quite bad.
> 
> What we are trying to solve: display the method and classname that
> makes the log call. 
> 
> Log4j and jdk1.4 logging provide a config format to enable displaying this 
> - logkit doesn't seem to, so it's not a problem there ( since it couldn't
> be displayed in the first place - if it does, same issue as in jdk1.4 
> apply )
> 
> Log4j has the best support for this - if you enable the display for
> method and classname it'll generate a Throwable and walk the stack to
> find the caller. It also have support for passing a Object which is 
> indicates the 'wrapper' - so if log4j is wrapped, we display the real
> caller, not the wrapper.
> 
> JDK1.4 does almost the same thing - if called directly and if the
> method display is configured, it'll walk the stack. It is also possible
> to pass the class/method as String params ( as oposed to log4j 
> where you pass the Object wrapper ).
> 
> The problem in JDK1.4 is that there is no good way to deal with the 
> case when their logger is wrapped ( by commons-logging or by a tomcat
> logger or any other method ). So we have to 'emulate' this and extract
> the information from stack in the wrapper. We could ask the user
> to pass this explicitly - but that's stupid, since the info is redundant
> ( we already _have_ it, in the stack ) and make the logger hard to use.

yea, I imagine the explicit reference might be handy if you generate
java code from another source (like a JSP page.)

> 
> We solve the problem for commons-logging, but what if commons-logging
> itself is wrapped ? Well, same solution as in log4j can be used here, 
> i.e. pass ( somehow ) information about the wrapper and skip it from
> the stack walk.
> 
> However there are 2 huge problems:
> 
> 1. Performance. Generating an exception and parsing the stack trace
> is _extremely_ expensive. If you need the information - you'll have 
> to pay for it, but the problem is that you pay for it even if you
> _don't_ use it. 

Yea, definitely need to be able to switch stack walking on/off.
 
> 2. Configuration. We either add explicit API to pass this info in each
> Log method or we allow to configure it per LogFactory or once per Log
> ( i.e. a single method - generic or not - to configure it ). 
> 
> What that means is that in order to avoid the performance when it is
> not needed, we also need to request the logger to enable stack checking
> in 1.4 ( again, log4j works without problems anyway ). 
> 
> The solution of casting or constructing Jdk14Logger explicitely is 
> wrong - we loose the pluggability and discovery. 
> 
> IMHO the only way to deal with that is to allow some form of 
> configuration ( hints ) that is generic to all loggers. 
> 
> I'll ask for a vote - after I hear your comments. The hints 
> will be passed by whoever creates the Logger, and so far the 
> best solution seems to be setAttribute in Logger.

Hopefully the hint will enable a commons-log user to supply a "Stack
Trace method extraction Strategy" (to make me happy anyway.)

> There is one alternative - that doesn't require API changes, and it
> may be much better: 
> 
> Require ( or recomend ? ) that each Log and LogFactory to support a form 
> of JMX. 
> 
> That would mean that we'll be able to find if a Log or LogFactory support
> configuration, pass configuration using a standard API, use the 
> existing JMX support in log4j, get the loggers to integrate nicely
> in tomcat and apps that use JMX. 
> 
> A static MBean would be the best choice for this case - as it 
> doesn't introduce _any_ dependency on JMX, it's just a programming
> style where each LogFactory/Log impl would also implement an interface
> with getters/setters. For log4j we could expose the 'real' MBean 
> of the Category, since it already exist and get access to all
> the config capabilities. 
> 
> Yet another alternative is to just use getter/setters and the 
> introspection-based dynamic MBean in tomcat-util ( which can be used
> to transparently enable any bean as a JMX component - like 3.3 
> interceptors or jk handlers ).

So commons-logging would expose a JMX version of a logger which my code
can probe, and configure it to use a "Stack Trace classname methodname
extraction Strategy" of my choice (if the exposed logger supported the
ability.)  Sounds workable.

> 
> I hope at least someone has read all this long message and will respond 
> :-)

I read it.  :)

Cheers
-bob







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


Mime
View raw message