Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 4387 invoked from network); 20 Oct 2003 22:26:17 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 20 Oct 2003 22:26:17 -0000 Received: (qmail 53648 invoked by uid 500); 20 Oct 2003 22:25:59 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 53577 invoked by uid 500); 20 Oct 2003 22:25:58 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 53563 invoked from network); 20 Oct 2003 22:25:58 -0000 Received: from unknown (HELO smtp.easystreet.com) (206.26.36.40) by daedalus.apache.org with SMTP; 20 Oct 2003 22:25:58 -0000 Received: from apache.org (dsl-208-161-106-6.dsl.easystreet.com [208.161.106.6]) by smtp.easystreet.com (Postfix) with ESMTP id 1951A84551F for ; Mon, 20 Oct 2003 15:26:04 -0700 (PDT) Message-ID: <3F9460FA.8060700@apache.org> Date: Mon, 20 Oct 2003 15:26:02 -0700 From: "Craig R. McClanahan" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [digester] plugins module ready for evaluation References: <6E5F1B42-0344-11D8-8CD3-003065DC754C@blueyonder.co.uk> <1066686367.1806.1816.camel@PCSIMON.ecnnz.ecnetwork.co.nz> In-Reply-To: <1066686367.1806.1816.camel@PCSIMON.ecnnz.ecnetwork.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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: >> >> >> >> >> >>>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)? > > > No. Consider a use case like Tomcat, where Digester is used both by the container (to parse server.xml and web.xml files) and also by an application (say, Struts reading struts-config.xml). It's entirely reasonable to for someone to want the digester log output for the container's use of Digester to go to the container's logging hierarchy, and the webapp's use of Digester to log to a webapp hierarchy. >>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. > *Allows* not *requires*. If you don't call setLog() you get the default names. > 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. > > > *Allows* not *requires*. If you don't call setLog() you get the default names. >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. > > > Can you show me how you'd solve the problem posed above about Tomcat? Especially in the case where you're running in a restricted environment where you are not allowed to modify the LogFactory in the container itself? >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 > > > 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. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org