avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: Need setPriority in the Avalon Framework Logger
Date Wed, 27 Feb 2002 16:57:50 GMT

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>


Mime
View raw message