commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [digester] plugins module ready for evaluation
Date Mon, 20 Oct 2003 22:49:30 GMT
On Tue, 2003-10-21 at 11:26, Craig R. McClanahan wrote:
> Simon Kitching wrote:

Regarding your "tomcat" example, I will have to have a think about this.
I'm no expert on complex container architectures, nor on Tomcat, so if
you and the Avalon team say the setLog() approach is the only way to go,
I'll believe you. 

Nevertheless, the current approach *feels* wrong to me. I'm just trying
to understand why it is necessary to do logging in this way.

> If you go back in the commons-dev message archives, you'll find that the 
> reason setLog exists in the first place is because the Avalon folks (who 
> know a little about IoC :-) said they needed it.  You seem to be arguing 
> the opposite position, which is kinda interesting.  But, at the end of 
> the day, I can't see why having an optional method to set the Log object 
> a Digester instance can use causes you any grief if you never call it.

The problem is not that the method exists on the Digester class.

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:


rather than

  Logger log = LogFactory.getLogger(ThisClass.class)

The first implication is that with this pattern, *every* object which
wants to log output *requires* a reference to whatever object is the
"holder" of the master Log object (a Digester instance in this case). 

This looks like undesirable coupling to me; I find it difficult to
believe that many other projects would be *able* to implement this
pattern. For example, the commons-net project: does every object have a
reference to some "master" object that can be used to hold a central Log

Also see the "xmlrules" module. This creates new Digester objects to
parse the xmlrules input files, but doesn't copy the set Log object. So
currently xmlrules is broken with respect to Log behaviour: there is no
way for the "framework" to control the Log object used by the Digester
instances created by xmlrules. While this could be considered a bug in
xmlrules, I think it shows a flaw in the concept of a centralised "Log"
object attached to some "master" object; the log control doesn't
automatically propagate, but instead requires explicit code.

The second implication of the "centralised Log object" pattern is that
there is a single Category for all output generated by all classes in
the Digester project. This seems a shame. It may be acceptable for a
project of Digester size (20-30 classes), but I presume that there is a
limit beyond which this would not be acceptable. Does Tomcat use a
single Category to output all of its logging?



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

View raw message