commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Herrmann <>
Subject Re: [Logging] more issues with stack reading
Date Sun, 28 Jul 2002 03:46:07 GMT
On Fri, 2002-07-26 at 19:14, wrote:
> >On Fri, 26 Jul 2002 wrote:
> >> I'd STILL like to see this explicit, rather than "hidden" behind magic 
> >> attributes:
> >
> >The benefit of attributes ( like those used in SAX, DOM, XSLT, etc ) 
> >is that it is more flexible and allows implementations to expose 
> >specific features.
> That's exactly my point:  for commons-logging we want to minimize that 
> exposure.  Specific API's open the *just* enough to accomplish the 
> required deed, but no more.  setAttribute blasts a hole in the wall.
> >> Regarding versioning - the 2nd edition of the Java Language 
> Specification 
> >> states that as long as we don't break our contract (i.e. remove 
> methods)
> >> with precompiled binaries, we can add-to the existing interfaces 
> (13.5.3).
> >
> >I'm not sure this is correct. Adding methods to an existing interface
> >is what happened to JDBC Connection in JDK1.4 - and the result is that 
> >it is impossible to have a connection pool that works with both 1.3 and 
> >1.4.
> Hmm... one to doubt the spec huh?  Can't blame experience :-)
> I'd like to understand that better.
> >>  Similarly for classes (LogFactory).  So, I believe that we should be 
> OK 
> >> with adding methods to Log and LogFactory - but I would take a very 
> >> conservative approach to that.  To-wit: adding 'entry/exit' log methods 
> >> should be of the same form as the the current log interface (sans 
> >> throwable parameter): (Object message).
> >
> >I'm -0 ( very close to -1 ) on entry/exit.
> There are logging implementations (and loggers implemented under Log) that 
> have these (apparently more than one - the query for this from another 
> user was entirely independent of the other I'm aware of..).  As long as 
> the 'logic' is eliminated (specifying return types, parameter lists, etc) 
> - I'm OK with this.
> >> That said, I'd like to explore the idea of separate interfaces for 
> >> new/difference 'features'.  Rather than changing the Log interface, we 
> can 
> >> introduce a NEW interface:
> >> 
> >>   interface WrappedLog { public void setWrapperClass(Class clazz); }
> >I don't like this... We'll end up with a mess of interfaces. I don't 
> >know any existing API that follows this model, at least no 'mainstream'
> >API.
> I thought somewhere in Excalibur or Avalon or other far-off fairy-land.. 
> :-)
> Seriously, the idea doesn't originate from me, I saw it somewhere in 
> open-source first.
> As long as we take the conservative approach, we shouldn't end up with a 
> mess of interfaces.  There is VERY LITTLE config I would expect to expose. 
>  In this case, we don't have configuration settings for the loggers, and I 
> appreciate the importance of a meaningful log.
> One way to solve this it to push a new attribute into the logging 
> implementations that defines the outermost wrapper class.  I'm just sure 
> Ceki will love that requirement :-).
> >I do agree with your concern on adding configuration features via 
> >attributes - but setWrapperClass is in fact a configuration feature,
> >added in the worst way.
> Can you justify this?  Yes, it's config.  But via the interface it's 
> carefully controlled/exposed,
> If we expose this ONE attribute in the LogFactory implementation, what 
> other attributes filter down next?  How are you going to expose the Log 
> implementation to this attribute w/o changing the interface?
> >I suppose the only way to sort this out is via vote.
> Could be.  I'm learning a lot... I'd hate to loose that :-)
> The alternatives I think we are discussing are (I'm tossing in a few from 
> previous thoughts, sorry for taking the liberties, now it's your turn :-):
> 1.  Log.setAttribute()
> 2.  Log.setWrapperClass()
> 3.  LogImpl(String wrapperClass, String category) with logic in LogFactory 
> to look for this constructor.
> 4.  separate SetWrapper interface, as described previously, 
> 5.  Asking log implementations to provide configuration attributes for 
> wrapper class(es).
> 6.  Exposing MBeans (I like this a lot, but it's going to be some work..)
> 7.  Drop the whole thing, give up on commons-logging, and put our flag in 
> JDK 1.4.
> Did I miss anything?

I am in favor of any approach using the "WrapperClass" as a marker in
the stack.  But I think a more general approach is to allow delegation
of the "Stack Walking Stratagy" to an external class, something like

	Log.setStackWalker( StackWalker x );

where StackWalker is

	interface StackWalker {
		String getMethodName( Throwable t);
		String getClassName( Throwable t);

	interface StackWalker {
		// class and method are returned in dotted notation,
		// i.e.     java.lang.String.toString
		String getClassMethodName( Throwable t);

This gets the logger out of the stack walking business, and allows for
project specific stack walking.

Again, I am in favor of any improvement to the currently limited
commons-logging stack walking.


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

View raw message