[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avalon-dev
Subject:    RE: Need setPriority in the Avalon Framework Logger
From:       "Stephen McConnell" <mcconnell () apache ! org>
Date:       2002-02-27 18:50:56
[Download RAW message or body]



> -----Original Message-----
> From: Gary Shea [mailto:shea@gtsdesign.com]
> Sent: Wednesday, 27 February, 2002 19:04
> To: Avalon Developers List
> Subject: RE: Need setPriority in the Avalon Framework Logger
>
>
> Ok, I can buy this argument.  But there are still a few troubling
> details ;)

Zuut!

> Right now the LogEnabled interface is the "right" place to
> provide the component with a logger.

Yes.

> That is great as long as a
> component only requires 'a' (i.e., one) logger.

In all cases I have experienced, a component can manage quite well
with just one logger. Think of a logger as a girlfriend - most of the
time you won't want children - you won't need children - but sometime
your engaging in something serious - so make a few children and
scatter then around - child here - child there - etc.

> 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;

I deny this vehemently!!!
If a bit of code has a logger it can do with it what it want - flirting,
heavy petting, even propagation is little baby loggers!  Whatever the
interface allows - that the rules of the game.

> instead it creats new child loggers strictly for the benefits of its
> components.

Umm, misleading - the contract declared by Logger is that an object
acquiring a logger can do whatever it wants with the logger - party time!!
Realistically, you make the decisions about what sub-systems should given
a child logger as opposed to passing the "relative-root" logger.  It simply
a question of clarity/granularity.

> 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.

A container MAY provide a logger to the component it manages.
A container MAY provider component with child loggers derived from its own
logger. It's up to the implementation.

> In that case, shouldn't LogEnabled then take a hash
> or set or array or something?

Eeek - why?
The object supplied with a Logger instance creates its children from
that instance.

> My guess is that this is not what is intended.

Your right - we agree :-)

> How about:
>
> 1) The container will create the "root logger relative to the
> [component]", and hand it to the component via enableLogging().

OK.

> 2) If the component needs additional child loggers, it can derive them
> from the logger handed over by the container.

OK.

> 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.

Gets misty when you try to figure out what "program control" means. I can
control priorities though a log manager - that's under program control -
just not under your component control.  Probably better to use distinctions
of "site" or "application" control as distinct from "component control".

> So log priorities may only be set
> in a configuration file (or maybe the command line).

In effect - a LogManager.

> A bit tortured but it works.  Seriously in need of being stated
> succinctly in the interface doc!!!

Put a patch together!
You know how exciting voting can be here in Avalon :-)

Cheers, Steve.


>         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>


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

[prev in list] [next in list] [prev in thread] [next in thread]