commons-dev mailing list archives

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

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

And, without a getLog() call, it would not even be *possible* to share 
the same Log instance, which is what the Avalon folks were complaining 
about.

>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). 
>
>  
>
Even if this were a *must* requirement, how many objects n the Digester 
API don't have a Digester instance already?  That's right, basically 
none of them :-).

>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
>object?
>
>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?
>
>  
>

Centralized logging for Digester is used by the standard Digester 
classes to minimize the number of log names you have to administer.  
Whether you utilize it in your own code (or whether your own code is 
even aware that the possibility exists) is totally up to you.

>Regards,
>
>Simon
>
>  
>

Craig


>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message