You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Shawn Boyce <sh...@boycefamily.net> on 2002/02/27 05:31:05 UTC
Need setPriority in the Avalon Framework Logger
The org.apache.avalon.framework.logger.Logger
interface is a wrapper for the various loggers that
are available (ie. logkit, log4j, jdk14). However
it is missing a setPriority method which I need.
Logkit/log4J/jdk14 all provide this method in their
Logger interface. Any reason it is not there in the
Framework Logger?
If not, I will provide patches to support it.
Thanks,
-Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Berin Loritsch <bl...@apache.org>.
Shawn Boyce wrote:
> OK. I agree with you in the simple case of a single Logger. The container
> creates and configures it based on a config file, and then passes it to the
> component.
>
> Let me explain more about what's going on. It has to do with child loggers.
> I have a Service component which is passed a Logger via enableLogging.
> It then creates several child loggers (using the getChildLogger). From
> the configuration
> in its context, it then sets the children's logger priorities. So they
> are not hardcoded.
>
> The child loggers show different functional areas of the service's
> operation and so allow
> the user to turn on debugging/logging information in these areas.
>
> Why doesn't the container set the priorities? Well it does not know about
> the child loggers since they are controlled by the Service.
The LoggerManager is able to get the specific logger with the specific
category you want. It also allows you to control the priorities of the
child loggers centrally--in one config file.
You can pass a reference to the LoggerManager in the Context that you
can pass from a parent container to a child container. This, in the
end is much cleaner than what you are proposing.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Shawn Boyce <sh...@qcominc.com>.
OK. I agree with you in the simple case of a single Logger. The container
creates and configures it based on a config file, and then passes it to the
component.
Let me explain more about what's going on. It has to do with child loggers.
I have a Service component which is passed a Logger via enableLogging.
It then creates several child loggers (using the getChildLogger). From
the configuration
in its context, it then sets the children's logger priorities. So they
are not hardcoded.
The child loggers show different functional areas of the service's
operation and so allow
the user to turn on debugging/logging information in these areas.
Why doesn't the container set the priorities? Well it does not know about
the child loggers since they are controlled by the Service.
Given that the Logger interface allows creation of a child logger, why
shouldn't it contain a
way to configure its priority? Also why does Avalon's LogKit allow it?
If the design is wrong, I'd appreciate some pointers on handling this
situation. I'm basically trying to adapt existing code to use the Avalon
framework.
Thanks.
-Shawn
Jeremias Maerki 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.
>
>>The org.apache.avalon.framework.logger.Logger
>>interface is a wrapper for the various loggers that
>>are available (ie. logkit, log4j, jdk14). However
>>it is missing a setPriority method which I need.
>>
>>Logkit/log4J/jdk14 all provide this method in their
>>Logger interface. Any reason it is not there in the
>>Framework Logger?
>>If not, I will provide patches to support it.
>>
>
>Cheers,
>Jeremias Märki
>
>mailto:jeremias.maerki@outline.ch
>
>OUTLINE AG
>Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
>Fon +41 41 317 20 20 - Fax +41 41 317 20 29
>Internet http://www.outline.ch
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Gary Shea <sh...@gtsdesign.com>.
[2002-02-27 13:37 -0500] Shawn Boyce (shawn@qcominc.com) wrote:
>
> Gary Shea wrote:
>
> >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?
> >
> I don't think that is what is meant. The component can use the child
> loggers it creates.
> It can also pass them to components it contains. LogEnabled just passes
> the root Logger
> for this component.
>
> Perhaps the only issue is what if a component needs to write to 2
> different categories
> (ie. Loggers). However, this may mean the logging design is too complex,
> or the
> component is a candidate to be sub-divided.
Ok, this time keep reading... ;)
> >
> >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 :-).
> >>
> >>*snip*
> >>
>
> --
> Shawn Boyce
> QCOM, Inc.
> Quality Software is Our Business
> http://www.qcominc.com
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Shawn Boyce <sh...@qcominc.com>.
Gary Shea wrote:
>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?
>
I don't think that is what is meant. The component can use the child
loggers it creates.
It can also pass them to components it contains. LogEnabled just passes
the root Logger
for this component.
Perhaps the only issue is what if a component needs to write to 2
different categories
(ie. Loggers). However, this may mean the logging design is too complex,
or the
component is a candidate to be sub-divided.
>
>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 :-).
>>
>>*snip*
>>
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Need setPriority in the Avalon Framework Logger
Posted by Stephen McConnell <mc...@apache.org>.
> -----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:
> > <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> >
> > --
> > Shawn Boyce
> > QCOM, Inc.
> > Quality Software is Our Business
> > http://www.qcominc.com
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Need setPriority in the Avalon Framework Logger
Posted by Gary Shea <sh...@gtsdesign.com>.
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:
> <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
> >
>
> --
> Shawn Boyce
> QCOM, Inc.
> Quality Software is Our Business
> http://www.qcominc.com
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Need setPriority in the Avalon Framework Logger
Posted by Stephen McConnell <mc...@apache.org>.
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:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Shawn Boyce <sh...@qcominc.com>.
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: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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Need setPriority in the Avalon Framework Logger
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Gary Shea <sh...@gtsdesign.com>.
[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. 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 heirarchy,
before creating the top element of that heirarchy.
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.
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.
Gary
>
> > The org.apache.avalon.framework.logger.Logger
> > interface is a wrapper for the various loggers that
> > are available (ie. logkit, log4j, jdk14). However
> > it is missing a setPriority method which I need.
> >
> > Logkit/log4J/jdk14 all provide this method in their
> > Logger interface. Any reason it is not there in the
> > Framework Logger?
> > If not, I will provide patches to support it.
>
> Cheers,
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 41 317 20 20 - Fax +41 41 317 20 29
> Internet http://www.outline.ch
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need setPriority in the Avalon Framework Logger
Posted by Jeremias Maerki <je...@outline.ch>.
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.
> The org.apache.avalon.framework.logger.Logger
> interface is a wrapper for the various loggers that
> are available (ie. logkit, log4j, jdk14). However
> it is missing a setPriority method which I need.
>
> Logkit/log4J/jdk14 all provide this method in their
> Logger interface. Any reason it is not there in the
> Framework Logger?
> If not, I will provide patches to support it.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>