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.
2) configuration of all loggers is done at the application level or framework level Stephen McConnell wrote: >Hi Gary: > >>-----Original Message----- >>From: Gary Shea [mailto:[EMAIL PROTECTED]] >>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 >>([EMAIL PROTECTED]) 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. > > <logs> > > <category name="" target="default" priority="ERROR" /> > > <category name="gateway" target="default" priority="INFO" /> > <category name="gateway.orb.iiop" target="default" priority="ERROR" /> > <category name="gateway.orb.pss" target="default" priority="DEBUG" /> > > <log-target name="default" location="/logs/default.log" /> > > </logs> > >Hope that helps! > >Cheers, Steve. > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- Shawn Boyce QCOM, Inc. Quality Software is Our Business http://www.qcominc.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
