Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 98766 invoked from network); 27 Feb 2002 16:56:19 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Feb 2002 16:56:19 -0000 Received: (qmail 14517 invoked by uid 97); 27 Feb 2002 16:56:20 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 14501 invoked by uid 97); 27 Feb 2002 16:56:20 -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 14490 invoked from network); 27 Feb 2002 16:56:19 -0000 From: "Stephen McConnell" To: "Avalon Developers List" Subject: RE: Need setPriority in the Avalon Framework Logger Date: Wed, 27 Feb 2002 17:57:50 +0100 Message-ID: <010901c1bfaf$e3bef850$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Gary: > -----Original Message----- > From: Gary Shea [mailto:shea@gtsdesign.com] > Sent: Wednesday, 27 February, 2002 17:17 > To: Avalon Developers List > Subject: Re: Need setPriority in the Avalon Framework Logger > > > [2002-02-27 14:06 +0100] Jeremias Maerki > (jeremias.maerki@outline.ch) wrote: > > Yes, there's a reason (if I got it right): All log configuration is done > > in a config file or by the container (means: it is done from outside). > > And I think logging and logging configuration (ex. Priority) are two > > different concerns, so they shouldn't be in the same interface. > > > > So, you should not set the logging priority within your code. Having the > > priorities in a config file enables you to switch on logging for a > > particular category at the customer site if something goes wrong. You > > can't do that if you're hardcoding the priority. > > I agree with your arguments, but we might want to take them a bit > further. In fact, the separation of concerns argument indicates that we > should also remove getChildLogger() from the Logger interface, because > getChildLogger() is definitely configuration. Nope. The getChildLogger is basically creating a new node in the log category hierarchy. The container creating the child does not know (and should not know) about the hierarchy above itself. The hierarchy that your application is creating is not the same as the overall management hierarchy. The management hierarchy from the root down across several systems of which your system is one small part. If you look from the "site" perspective you can see the cascading of logging children that establishes identifiable "category-path-names" that can be used to filter and direct logging information. > At that point the issue > becomes a lot clearer: The top-level container must create and > configure all child loggers needed anywhere in a component hierarchy, > before creating the top element of that heirarchy. Nope - sorry! Position yourself as a container. You are supplied with a logger, which for you is your root logger, but from a management point of view that logger you have been supplied with maybe six or sever levels down in a hierarchy. The container knows about and manages the component within its scope. For example, an ORB is a container that manages an IIOP and a POA sub-system. These category paths "orb.iiop" and "orb.poa" are sub-category paths of "orb", however, if you assume your running somewhere in a bigger system, the manager is looking at a category path something like: "gateway.collaboration.encounter.orb.iiop" And possible somewhere else in the same system is: "pki.orb.iiop" The ORB does not know about the configuration of the hierarchy - it simply manages the sub-logging categories in its scope. The site manager knows about PKI and GATEWAY and can configure these as needed because they logically exist as site scope. > Is that really what we want? I would think that some containers could > be given the ability to configure the child loggers for their > components, either programmatically or from the Configuration. This functionality is associated with the LogManager and exposing the manager means exposing the ability to "some-system" to create arbitrary logging channels - which is a definite security breach. > By the way, Shawn's request arises because we're dealing with a service > (OpenORB Notification) that has 11 child loggers, each of which is > (currently, pre-Avalon) independently configurable both programmatically > and by configuration file. We're trying to figure out how to move that > to a more Avalon-y approach. Here is simplified extract of the logging configuration I have here on my site for an application called "gateway". The gateway application creates a ORB and in the process of doing so, creates a sub-category "orb" and passes this new child logger to the ORB. The ORB is loaded and automatically add child-loggers for the Initializers it encounters (e.g. iiop and pss). These form new child categories. A Notification Service is exactly the same as the Apache PSS implementation - its initialised by and ORB, has sub-categories under the pss category, etc. All configurable using the information detailed below. The important point is that the configuration deals with the "site" configuration - because you service implementation does not know that it being used in my gateway application, and my gateway application does not know if it is top level or embedded. But the site manager knows what's running and can configure priorities accordingly. Hope that helps! Cheers, Steve. -- To unsubscribe, e-mail: For additional commands, e-mail: