avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Shea <s...@gtsdesign.com>
Subject RE: Need setPriority in the Avalon Framework Logger
Date Wed, 27 Feb 2002 18:03:44 GMT
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?

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 :-).
>
>
> > Stephen McConnell wrote:
> >
> > >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.
> > >
> > >    <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:avalon-dev-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
> <mailto:avalon-dev-help@jakarta.apache.org>
> >
> >
> >
>
> --
> Shawn Boyce
> QCOM, Inc.
> Quality Software is Our Business
> http://www.qcominc.com
>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message