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 :-).
> 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
