commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [digester] plugins module ready for evaluation
Date Tue, 21 Oct 2003 20:30:30 GMT
On Tuesday, October 21, 2003, at 08:04 AM, Craig R. McClanahan wrote:


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

craig: i'm not sure i'm parsing you correctly here. you mean too late to 
change the digester conventions, right? (IMHO it's not too late to change 
the plug-ins stuff.)

i'm not sure that i feel quite so strongly about logging symantics as you 
do. (i probably wouldn't have committed the stuff without changes if i'd 
thought the issues were black-and-white rather than worthy of debate.) the 
plugin package is self-contained and any differences in symantics cannot 
effect users of the other packages. they might have expectations about the 
way that plugins will handling logging but i'm not sure that it will break 
the configurations typically used.

i'd be happy to see the Rule implementations follow the standard 
convention and log to Digester.getLog(). (but someone would need to go 
through and ensure that the calls were correctly prefixed and that the 
levels were appropriate given that it's a multi-purpose log.)

one issue is that there is a *lot* of logging in the plugins packages 
(that is not intended as a criticism). it seems to me that a lot of this 
will be needed by users trying to debug their plug-ins but may obfuscate 
in other cases. i've taken a look and there isn't any real precedent for 
logging in matching Rules. there may be case for directing logging 
messages from matching Rules to a separate Log (in the same way that 
digester has saxLog and Log) since matching Rules get called a *lot* and 
logging would tend to obfuscate if the problem lies elsewhere.

- robert

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

View raw message