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 19:37:22 GMT
On Monday, October 20, 2003, at 10:46 PM, Simon Kitching wrote:
> On Tue, 2003-10-21 at 10:29, robert burrell donkin wrote:
>> On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote:
>> <snip>
>>> Hmm .. but calling Digester.setLogger probably doesn't override the
>>> object known to the LogFactory...
>>> What exactly is the purpose of being able to set the Log object used by
>>> a class or instance?
>> so the instance used to log by digester can be set programmatically at
>> runtime. this is a useful feature because:
>> 1. it's a very convenient way to bypass the usual commons-logging
>> configuration infrastructure. for example, it's often easier (when
>> debugging) to setLogger programmatically on a particular instance than to
>> reconfigure everything.
> Easier than changing the logging config file for the appropriate logging
> implementation (eg the or log4j.xml file)?

this allows some things to be done easily that otherwise would be 

1a different instances can use different log systems;
1b different instances can use different log levels (this is particularly 
useful in complex systems);

>> 2. it allows digester to participate properly in frameworks based on
>> inversion-of-control. (frameworks of this type are configured and
>> controlled in a parent-child fashion. the Log to be used by a digester
>> should be controlled by the component owning digester)
> This approach requires:
> (a)
> The framework to call setLog on each component used by the framework
> which has a dedicated Log object. Imagine a framework which uses
> Digester + Net + CLI, where each component works like Digester,
> requiring the user to call setLog on each one in turn.

this approach is advocated by many designers of (usually heavyweight) 
frameworks. these kinds of framework have their own configuration 
mechanisms which configure each component in turn.

> (b)
> Requiring classes to log via some object stored on some "main" object in
> the component, like all classes in the Digester project are required to
> get the Log object from their owning Digester object. In fact, in many
> projects this will not be feasable; it only works in Digester because
> every object of interest happens to have a reference to an owning
> Digester object.

yes and no :)

logging to a central object only works when a component has a central 
object. the alternative for components which consist of loose graphs is 
typically having setters and getters for each (principal) object.

> Isn't it much cleaner for the calling framework to set up an appropriate
> implementation of org.apache.commons.loggging.Logfactory that does
> whatever the "framework" wants with respect to logging? If the calling
> framework wants all logging (regardless of category) to go to one
> destination, then it creates a LogFactory implementation which returns a
> single Log object always, and that Log object's implementation writes to
> the desired destination.

1. this pattern has been found to be very powerful. allowing components to 
be configure by setting properties is both common and clean.
2. IMHO library code should seek to work flexible with different designs 
of framework.

> All those getLog and setLog calls go away. Objects don't need to have
> references to the "master" object which holds the Log object to use.
> Objects log via their own Category, so that filtering can be applied
> appropriately.

i'm very keen about leaving the door open for users to integrate digester 
into frameworks using IOC and so i'm probably (sooner or later) going to 
add getters and setters for each log.

the real question (as far as i'm concerned) is whether each class needs it'
s own logger (with a getter and setter) or whether it's better (in this 
case) to follow the digester conventions and feed some (or all?) of these 
into the central digester log. i'd be interested to hear other opinions on 

- robert

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

View raw message