commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Logging] more issues with stack reading
Date Thu, 25 Jul 2002 17:41:50 GMT
Keep in mind that JDK 1.4 has some improvements in this area,
allowing you to iterate more easily through the stack trace.
It could be a feature that is enabled by the JDK you are using.

You can detect the JDK at runtime by checking if the
java.sql.SavePoint class or the java.lang.CharSequence interface
exists.  If so, then we can do this:

StackTraceElement[] trace = throwable.getStackTrace();

That will allow us to iterate neatly through the stacktrace and
make it work for us.  Also, there is the ability to set the
stack trace (i.e. for those more advanced cases where you need
to override the stack trace information).

Relying on strings alone is quite problematic.

> From: [] 
> 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. 

The problem is due to the additional layer of the wrapper class.
You need to work with the back end logging systems to come up with
a proper solution.  What calls the backend logger is not the line
of code but the wrapper class.

> 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 )

LogKit also allows displaying this information.

> 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.

If a logging wrapper is wrapped, then there is a real design

> 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. 

It gets better in JDK 1.4 as a platform.  However the point is

> 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. 

The whole discovery/pluggability framework is what you are now
finding you need to support now.  Too much automagic stuff, and
you will find even more places where something as simple as logging
will fail.  There comes a point where it is just easier to commit
to one particular logger.

> IMHO the only way to deal with that is to allow some form of 
> configuration ( hints ) that is generic to all loggers. 

All I can say is beware of feature creep.  By adding in more
things into your logging framework, you raise the bar to add in
yet another logging backend.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message