commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester] plugins module ready for evaluation
Date Mon, 20 Oct 2003 21:46:08 GMT
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 log4j.properties or log4j.xml file)?

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

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


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.

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.

Thoughts??

Regards,

Simon


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