<snip>
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
