Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 24453 invoked from network); 27 Feb 2002 18:43:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Feb 2002 18:43:38 -0000 Received: (qmail 14661 invoked by uid 97); 27 Feb 2002 18:43:39 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 14636 invoked by uid 97); 27 Feb 2002 18:43:38 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 14612 invoked from network); 27 Feb 2002 18:43:37 -0000 Date: Wed, 27 Feb 2002 11:42:57 -0700 (MST) From: Gary Shea X-X-Sender: shea@ns.local.net To: Avalon Developers List Cc: Shawn Boyce Subject: Re: Need setPriority in the Avalon Framework Logger In-Reply-To: <3C7D2769.6040607@qcominc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N [2002-02-27 13:37 -0500] Shawn Boyce (shawn@qcominc.com) wrote: > > Gary Shea wrote: > > >Ok, I can buy this argument. But there are still a few troubling > >details ;) Right now the LogEnabled interface is the "right" place to > >provide the component with a logger. That is great as long as a > >component only requires 'a' (i.e., one) logger. > > > >Your re-phrasing of Shawn's sentence suggests that a container may > >create child loggers, but may not directly use the logs it has created; > >instead it creats new child loggers strictly for the benefits of its > >components. Unless more re-phrasing is called for, that means that a > >container must provide a component with all of the child loggers needed > >by that component. In that case, shouldn't LogEnabled then take a hash > >or set or array or something? > > > I don't think that is what is meant. The component can use the child > loggers it creates. > It can also pass them to components it contains. LogEnabled just passes > the root Logger > for this component. > > Perhaps the only issue is what if a component needs to write to 2 > different categories > (ie. Loggers). However, this may mean the logging design is too complex, > or the > component is a candidate to be sub-divided. Ok, this time keep reading... ;) > > > >My guess is that this is not what is intended. How about: > > > >1) The container will create the "root logger relative to the > >[component]", and hand it to the component via enableLogging(). > > > >2) If the component needs additional child loggers, it can derive them > >from the logger handed over by the container. > > > >3) There is an implicit assumption that configuration of log priorities > >is a different concern than configuration of the logging heirarchy, and > >where logging heirarchy is under program control, log priorities are > >explicitly NOT under program control. So log priorities may only be set > >in a configuration file (or maybe the command line). > > > >A bit tortured but it works. Seriously in need of being stated > >succinctly in the interface doc!!! > > > > Gary > > > >[2002-02-27 18:35 +0100] Stephen McConnell (mcconnell@apache.org) wrote: > > > >>Shawn Boyce wrote: > >> > >>>So to summarize: > >>>1) a component can create its own child loggers/categories > >>>relative to its "root" logger. Its container does not know or > >>>manage these. A component does not configure its child loggers however. > >>> > >>I think the answer may be Yes! > >>But I'll rephrase what you said. > >> > >> 1. a object is supplied with a logger (which it the > >> root logger relative to the object) > >> 2. that object can create child logger from the suplier > >> logger, and apply these child logger to the components > >> it manages > >> 3. management of logging priority (INFO, DEBUG, ERROR, etc. > >> is not a concern of the object) > >> > >>>2) configuration of all loggers is done at the application level > >>>or framework level > >>> > >> 4. The configuration of the log hierachy is done at a "site" > >> or "framework" level > >> > >>So, yes - I agree :-). > >> > >>*snip* > >> > > -- > Shawn Boyce > QCOM, Inc. > Quality Software is Our Business > http://www.qcominc.com > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: