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 whichEven 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 :-).
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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
