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 18:29:04 GMT
> From: [] 
> On Thu, 25 Jul 2002, Berin Loritsch wrote:
> > 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.
> That's what we're using for the JDK1.4 logger ( where 
> obviously JDK1.4 is required anyway ). 

It can also be used for the other wrappers as well--if we are running
on JDK 1.4.

> The problem we're having is support for the old wrappers in 
> tomcat, as we need to filter them out too. We're trying to 
> get commons-logging used everywhere, but keep backward 
> compatibility since the Logger/Log interface is part of the 
> tomcat APIs. 


Does Tomcat expose its API beyond the Servlet spec?  IOW, is
it common to have direct plugins to Tomcat that are specific
to Tomcat?

If Tomcat is not meant to be used that way, you have the
ability to upgrade the logger in one massive sweep and be
done with it.

I wasn't aware of a real Tomcat Platform.

> > LogKit also allows displaying this information.
> I couldn't find this info - in any case the API doesn't seem 
> to allow passing the 'wrapper' class, nor the 
> classname/methodname, so it may be more difficult than for JDK1.4.

You are correct about the 'wrapper' class, but it can and does
print the current thread, and the calling class.  It might control
the wrapper class issue by just a number of stack trace entries.
It also might be that we never got around to making that part
work yet.

> > If a logging wrapper is wrapped, then there is a real 
> design problem.
> :-)
> I don't see any other solution - we can't abandon the old 
> wrapper interface for backward compatibility, and we want
> to migrate to commons-logging. 

For something like Tomcat where it *is* the application, and
does not provide any exposed framework, I don't see where that
need has to be enforced.  IOW it is probably easier to just
go through and change the logger wrapper.

> We could leave the old interfaces use their own file-based 
> logging, but that wouldn't be very nice.

How many third or second party plugins exist for Tomcat?

> > 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.
> I believe it's better to have the choice of multiple logger 
> implementations, and commit to one particular logger API.

Yep, and there are a couple of APIs that do that much.

> As for discovery/pluggability - it is allways possible to 
> explicitely select an implementation, and we're using a very 
> basic and clear standard ( the META-INF/services ).

I understand.  I just come from a different mindset, and am
naturally distrusting of discovery/pluggability.  Granted,
I am also an outsider so to speak.

> The JMX solution can avoid adding the configuration features 
> into the loggers and keep the API simpler ( but it may make 
> the implementation a bit more complex - but not very much )

The problem is where does it stop?  If you start down the road
of configuring the underlying logging API, other users will start
in with, "Yeah that's nice, but wouldn't it be great if...
...and it won't be that much more complex...."

Before you even consider going down that path, you need to
draw a very clear line in the sand and explain exactly why
you won't consider anything more than the wrapper layer issues.

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

View raw message