commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [digester] plugins module ready for evaluation
Date Tue, 21 Oct 2003 07:04:08 GMT
Simon Kitching wrote:

>On Tue, 2003-10-21 at 17:36, Craig R. McClanahan wrote:
>>Simon Kitching wrote:
>>>I'm looking at this from the point-of-view of a contributor to Digester,
>>>not a user (hence the dev list address). The problem is that in order to
>>>integrate with this solution, every class written for the Digester which
>>>needs to log output *must* do:
>>> digester.getLog().warn("oops")
>>>rather than
>>> Logger log = LogFactory.getLogger(ThisClass.class)
>>> ..
>>> log.warn("oops")
>>Why?  The first approach is only required if you want your log messages 
>>to go to the same Log instance that Digester is using.  If you don't 
>>care, don't bother.
>Hmm .. we don't seem to be connecting here. 
>The original cause of this thread was that I wrote a new set of classes
>for Digester (plugins) and submitted them for inclusion in the base
>Digester distribution. In these classes I use a Log category created via
>LogFactory. Robert Donkin told me off (nicely) for not using
>The easiest path for me is to accept Robert's solution and change the
>code (which has been committed by Robert to the digester cvs repository
>with the controversial code currently intact). 
>However it seems to me that the current logging approach is broken (or
>at least very clumsy), for the reasons I have put forward in the
>previous emails [and are summarized at the end of this mail].
>Rather than change my code to comply with what I think is an incorrect
>API, I would like to discuss this and maybe come up with a better
>solution. Or maybe I will just learn why the current solution is
>necessary. So far my original questions have not been answered, though.
>It may well be that my proposed solution (just use commons-logging's
>LogFactory functionality) is broken too (does not support the needs of
>users like Tomcat and Avalon).

That explanation makes life really simple.  The issues are *totally* 
different for classes inside commons-digester (more specifically, inside 
the org.apache.commons.digester) than outside.

For classes inside, consistency with past practice overwhelms any 
principle about the desireability of the practice--otherwise, you 
totally screw up any existing Digester user that expects his or her 
current log settings to continue to work when we add additional classes 
to the package.  I'm also going to -1 any proposed class that 
gratuitously breaks backwards compatiblity (even though it is not an 
issue that will cause compile-time behavior differences) in this way.  
It's too late to change this, even if there were good reasons.

For classes outside the org.apache.commons.digester package, do whatever 
you want.  Digester doesn't care, and I don't care.


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

View raw message