You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/02 15:01:35 UTC
JDK1.4 logging vs. LogKit
I have been thinking, and one of the previous arguments
against Java's Logging API was, "Who needs three levels
of debugging?".
In developing with Cocoon, it has become clear that three
levels of debugging may in fact be just what the doctor
ordered. Let me give you a scenario:
Excalibur's ComponentManager and ComponentSelector and
friends output _alot_ of debugging code. It is what
makes it so easy to maintain. However, I don't want
to clutter the logfile with all that information unless
I really need to. Therefore I need a base log level
for INFRASTRUCTURE, so that I can see the inner workings
if I wanted to.
Second, in order to track down ClassLoader issues using
Excalibur's Factories and Pools, It would be useful to
output a message saying "loading class xxxx with ClassLoader
Classloader$3242335" at a higher level. That way by placing
this type of information at an CLASSLOADER priority, I
can easily filter it out--but I have it if I need it and I
don't have to troll through all the INFRASTRUCTURE level
entries to find them.
Last, we would need an APPLICATION level debugging to differentiate
between Cocoon's DEBUG information and Avalon's. This way,
I don't have to artificially upgrade Cocoon's logging
entries on new components while I am developing them. Using
that approach I record the component's log entries at INFO--unless
I catch an exception which has to be at DEBUG or WARN and above.
This is not desireable to me.
Peter, what do you think of adding two additional log levels
below DEBUG in LogKit?
The new hierarchy of debug levels would be:
INFRASTRUCTURE
CLASSLOADER
DEBUG
INFO
WARN
ERROR
FATAL_ERROR
Alternatively, we could call them DEBUG3 and DEBUG2 respectively,
but it does not capture the intent of those log levels properly.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Donald <do...@apache.org>.
On Thu, 2 Aug 2001 23:33, Stuart Roebuck wrote:
> On Thursday, August 2, 2001, at 02:01 pm, Berin Loritsch wrote:
> > Peter, what do you think of adding two additional log levels
> > below DEBUG in LogKit?
-1, INFRASTRUCTURE and CLASSLOADER are not priorities but categories. The way
you should be doing it is creating categories like
cocoon.classloader
cocoon.infrastructure
cocoon.xsp.compiling
cocoon.xsp.running
cocoon.some-other-component-here
then assign different priorities to different categories. ie Turn classloader
to debug, compiling to fatal, etc. Each different component that you
potentially want to log at a different level can be a different category.
> How about providing mechanisms for displaying different levels of
> debugging output based on the package hierarchy so that you can do things
> like: "Display only WARN messages or above for org.apache.avalon.*, but
> all levels for everything else". If necessary an extra "DETAIL" /
> "LOW_LEVEL_DEBUG" or equivalent level could be added as well, though I
> sometimes wonder weather "DEBUG" is currently over used and "INFO" under
> used.
Simple to do if you name the categories after package name.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Thursday, August 2, 2001, at 02:01 pm, Berin Loritsch wrote:
> Peter, what do you think of adding two additional log levels
> below DEBUG in LogKit?
>
> The new hierarchy of debug levels would be:
>
> INFRASTRUCTURE
> CLASSLOADER
> DEBUG
> INFO
> WARN
> ERROR
> FATAL_ERROR
>
> Alternatively, we could call them DEBUG3 and DEBUG2 respectively,
> but it does not capture the intent of those log levels properly.
Whilst I can see the real benefit of these in the Cocoon context you
described, I wonder whether these levels are only really apparent in
hindsight, and whether many writing specialist Cocoon Transformers would
see Cocoon as INFRASTRUCTURE.
How about providing mechanisms for displaying different levels of
debugging output based on the package hierarchy so that you can do things
like: "Display only WARN messages or above for org.apache.avalon.*, but
all levels for everything else". If necessary an extra "DETAIL" /
"LOW_LEVEL_DEBUG" or equivalent level could be added as well, though I
sometimes wonder weather "DEBUG" is currently over used and "INFO" under
used.
Just my thoughts,
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Royal <pr...@managingpartners.com>.
At 09:01 AM 8/2/2001 -0400, Berin Loritsch wrote:
>In developing with Cocoon, it has become clear that three
>levels of debugging may in fact be just what the doctor
>ordered. Let me give you a scenario:
>
>Excalibur's ComponentManager and ComponentSelector and
>friends output _alot_ of debugging code. It is what
>makes it so easy to maintain. However, I don't want
>to clutter the logfile with all that information unless
>I really need to. Therefore I need a base log level
>for INFRASTRUCTURE, so that I can see the inner workings
>if I wanted to.
As a fellow Cocoon2 user, I definitely see the itch you are trying to
scratch with this, but could it not be solved by using different log
categories? You could have a "classloader" category and a
"componentmanager" or more generic "avalon" category and just set the
priority to info if you don't care about their debug info. Of course what
might be needed is the ability for the ExcaliburComponentManager to be able
to give the components that it manages a different logger category from the
one that it uses itself. That is something that could be easily specified
in an .xconf somewhere (as a tag on the root element perhaps?)
Of course, this all ties in with the desire to be able to control LogKit's
configuration dynamically rather than programmatically. That was one cool
feature that Log4j had.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: JDK1.4 logging vs. LogKit
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 2 augusti 2001 15:02
> To: avalon-dev@jakarta.apache.org
> Subject: JDK1.4 logging vs. LogKit
>
>
> I have been thinking, and one of the previous arguments
> against Java's Logging API was, "Who needs three levels
> of debugging?".
Berin,
I have to agree with that. I see no need for two levels below debug.
I think we have two different types of control here. First, it is the
SEVERITY of the event, defined basically as "just how deep trouble is the
component in?". Then there is the SOURCE of log events, which can be the
ComponentManagers, ClassLoaders etc.
For example, consider the possibility of several layers of infrastructure.
I think a per-component, or per-category, setting of the log level would be
more appropriate.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 8 Aug 2001 22:42, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>
>>>Hi,
>>>
>>>On Wed, 8 Aug 2001 06:10, giacomo wrote:
>>>
>>>>I have to confess that I don't know how this works in all my components
>>>>that are based on AbstractLoggable and have the logger passed in from
>>>>ExcaliburCM.
>>>>
>>>Just looked at ExcaliburCM and it doesn't really support separate loggers
>>>per component. Berin what do you think of adding an extra attribute to
>>>component definition so that you can specify name of logger. Then later
>>>on instead of doing
>>>
>>I was thinking about that before. We need to add an attribute to the
>>component definitions (probably "logger"). Something like this to specify
>>it:
>>
>><component role="com.foo.Component"
>> class="com.foo.DefaultComponent"
>> logger="foo"/>
>>
>>The attribute name is negotiable ;).
>>
>
> logger works for me.
>
>
>>Think this will help, combined with your changes for the Logger?
>>
>
> Which changes are you referring to? It should work without any changes.
The changes that test if the "logger" variable has a value.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Thu, 9 Aug 2001 00:16, Leo Sutic wrote:
> > Peter, Berin,
> >
> > how will this work with individual log levels for each
> > logger/category/channel?
> >
> > If one adds two properties: logger and loglevel, like this:
> >
> > <component role="com.foo.Component"
> > class="com.foo.DefaultComponent"
> > logger="foo"
> > loglevel="DEBUG"/>
> >
> > Is there a problem when having multiple components using the same logger?
> >
> > <component role="com.foo.Component"
> > class="com.foo.DefaultComponent"
> > logger="foo"
> > loglevel="DEBUG"/>
> >
> > <component role="com.foo.Component2"
> > class="com.foo.DefaultComponent2"
> > logger="foo"
> > loglevel="ERROR"/>
> >
> > If the two components share the same logger instance,
>
> they do.
>
> > I don't see how this can work.
>
> It can't work the way it is currently implemented. The only way around it is
> using separate loggers per component. Of course this makes configuration of
> logging even more difficult for cocoon ...
>
> hmmmm ... maybe it would be useful for me to not work on a
> LogManager/LogConfigurator next time I get free time rather than adding more
> targets ... not sure ... sounds too much like work ;) I don't suppose anyone
> from the Cocoon community has volunteered to make a Configurator ? ;)
I had one bite 3 days ago. Carston Ziegler also proposed to develop one.
I haven't had any information since.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Donald <do...@apache.org>.
On Thu, 9 Aug 2001 00:16, Leo Sutic wrote:
> Peter, Berin,
>
> how will this work with individual log levels for each
> logger/category/channel?
>
> If one adds two properties: logger and loglevel, like this:
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"
> loglevel="DEBUG"/>
>
> Is there a problem when having multiple components using the same logger?
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"
> loglevel="DEBUG"/>
>
> <component role="com.foo.Component2"
> class="com.foo.DefaultComponent2"
> logger="foo"
> loglevel="ERROR"/>
>
> If the two components share the same logger instance,
they do.
> I don't see how this can work.
It can't work the way it is currently implemented. The only way around it is
using separate loggers per component. Of course this makes configuration of
logging even more difficult for cocoon ...
hmmmm ... maybe it would be useful for me to not work on a
LogManager/LogConfigurator next time I get free time rather than adding more
targets ... not sure ... sounds too much like work ;) I don't suppose anyone
from the Cocoon community has volunteered to make a Configurator ? ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Peter, Berin,
>
> how will this work with individual log levels for each
> logger/category/channel?
>
> If one adds two properties: logger and loglevel, like this:
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"
> loglevel="DEBUG"/>
This is something that is setup for the whole category. Each component cannot have
it's own priority if they share a category.
> Is there a problem when having multiple components using the same logger?
Yes. LogKit is not constructed in a way that handles this scenario. If you want
two different logging levels, then you need two different categories.
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"
> loglevel="DEBUG"/>
>
> <component role="com.foo.Component2"
> class="com.foo.DefaultComponent2"
> logger="foo"
> loglevel="ERROR"/>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, August 08, 2001 8:17 PM
Subject: Re: JDK1.4 logging vs. LogKit
> On Thu, 9 Aug 2001 10:15, Mircea Toma wrote:
> > ----- Original Message -----
> > From: "David BERNARD" <dw...@java-fan.com>
> > To: "Avalon Development" <av...@jakarta.apache.org>
> > Sent: Wednesday, August 08, 2001 6:40 PM
> > Subject: Re: JDK1.4 logging vs. LogKit
> >
> > > Hi Everyone,
> > >
> > > I'm newby in Avalon and C°, and I've got a suggestion (if stupid say
> > > it).
> > >
> > > Actually I do a evaluation for "services engine"for my client, and
I've
> > > promote Avalon.
> > > The first set of services is for the migration of a old big java
> > > application. This application have some target in services management,
> > > log...
> > >
> > > In the first step, we design a from scratch system, and the choice for
> > > log is : "log is a service like anyother".
> >
> > No quite.... the logging is a fundamental part that should be available
> > immediately, it means that a Hierarchy has to be instantiated in the
> > container.
>
> I tend to agree. I put it in the same boat as ClassLoader and thread
> managment.
>
> > >So why, it's not a nice/good
> > > idea to define a role Logger and use a LoggerSelector (use category
> > > string as key) to get the instance of Logger.
> > > In this case, there implementation for LogKit, Log4J... and the
> > > configuration of Log system is independent of each Component
> > > configuration (The default category a component can use is the ROLE
> > > constant).
>
> Thats the way Avalon/Phoenix used to work about a year ago. We had a
Logger
> service that allowed all sorts of pluggability. The problem was that every
> block would require access to this service. This created a lot of
redundent
> coding in each Block. The other problem was you could not log any problems
> earlier in lifecycle - ie WHat happens when you want to log data in
> contextualize() method.
>
> > I already did that in the project I work and I can tell you it's not the
> > best approach. I think you can have only LogTarget-s as components
> > configured to use a certain Hierarchy ( we have two Hierarchies for
logging
> > and auditing). In this way you can have a configured LogTargetComponent
> > like: FileTargetComponent, DatabaseTargetComponent,
JMSQueueTargetComponent
> > ..... and you would configure them to with a certain Hierarchy, Category
> > and Priority as common attributes.
>
> Thats kinda the way I have been swaying recently but I really don't want
to
> create a circular dependency (ie framework depends upon logkit and logkits
> output targets depend on framework).
I agree! The components should be part of Excalibur/Phoenix or just custom
components!
Cheers,
Mircea
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Donald <do...@apache.org>.
On Thu, 9 Aug 2001 10:15, Mircea Toma wrote:
> ----- Original Message -----
> From: "David BERNARD" <dw...@java-fan.com>
> To: "Avalon Development" <av...@jakarta.apache.org>
> Sent: Wednesday, August 08, 2001 6:40 PM
> Subject: Re: JDK1.4 logging vs. LogKit
>
> > Hi Everyone,
> >
> > I'm newby in Avalon and C°, and I've got a suggestion (if stupid say
> > it).
> >
> > Actually I do a evaluation for "services engine"for my client, and I've
> > promote Avalon.
> > The first set of services is for the migration of a old big java
> > application. This application have some target in services management,
> > log...
> >
> > In the first step, we design a from scratch system, and the choice for
> > log is : "log is a service like anyother".
>
> No quite.... the logging is a fundamental part that should be available
> immediately, it means that a Hierarchy has to be instantiated in the
> container.
I tend to agree. I put it in the same boat as ClassLoader and thread
managment.
> >So why, it's not a nice/good
> > idea to define a role Logger and use a LoggerSelector (use category
> > string as key) to get the instance of Logger.
> > In this case, there implementation for LogKit, Log4J... and the
> > configuration of Log system is independent of each Component
> > configuration (The default category a component can use is the ROLE
> > constant).
Thats the way Avalon/Phoenix used to work about a year ago. We had a Logger
service that allowed all sorts of pluggability. The problem was that every
block would require access to this service. This created a lot of redundent
coding in each Block. The other problem was you could not log any problems
earlier in lifecycle - ie WHat happens when you want to log data in
contextualize() method.
> I already did that in the project I work and I can tell you it's not the
> best approach. I think you can have only LogTarget-s as components
> configured to use a certain Hierarchy ( we have two Hierarchies for logging
> and auditing). In this way you can have a configured LogTargetComponent
> like: FileTargetComponent, DatabaseTargetComponent, JMSQueueTargetComponent
> ..... and you would configure them to with a certain Hierarchy, Category
> and Priority as common attributes.
Thats kinda the way I have been swaying recently but I really don't want to
create a circular dependency (ie framework depends upon logkit and logkits
output targets depend on framework).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
----- Original Message -----
From: "David BERNARD" <dw...@java-fan.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, August 08, 2001 6:40 PM
Subject: Re: JDK1.4 logging vs. LogKit
> Hi Everyone,
>
> I'm newby in Avalon and C°, and I've got a suggestion (if stupid say
> it).
>
> Actually I do a evaluation for "services engine"for my client, and I've
> promote Avalon.
> The first set of services is for the migration of a old big java
> application. This application have some target in services management,
> log...
>
> In the first step, we design a from scratch system, and the choice for
> log is : "log is a service like anyother".
No quite.... the logging is a fundamental part that should be available
immediately, it means that a Hierarchy has to be instantiated in the
container.
>So why, it's not a nice/good
> idea to define a role Logger and use a LoggerSelector (use category
> string as key) to get the instance of Logger.
> In this case, there implementation for LogKit, Log4J... and the
> configuration of Log system is independent of each Component
> configuration (The default category a component can use is the ROLE
> constant).
> The problem is all Loggeable must be Composable to access
> LoggerSelector.
I already did that in the project I work and I can tell you it's not the
best approach. I think you can have only LogTarget-s as components
configured to use a certain Hierarchy ( we have two Hierarchies for logging
and auditing). In this way you can have a configured LogTargetComponent
like: FileTargetComponent, DatabaseTargetComponent, JMSQueueTargetComponent
..... and you would configure them to with a certain Hierarchy, Category and
Priority as common attributes.
Mircea
>
> In this case Configurator/and dynamic Reconfiguration can be develop and
> specialize like any Service.
>
> I will try this in my evaluation. If it's OK, then I could give my first
> version.
>
> PS: Sorry for my english.
>
> > On Wed, 8 Aug 2001, Leo Sutic wrote:
> >
> > > Peter, Berin,
> > >
> > > how will this work with individual log levels for each
> > > logger/category/channel?
> > >
> > > If one adds two properties: logger and loglevel, like this:
> > >
> > > <component role="com.foo.Component"
> > > class="com.foo.DefaultComponent"
> > > logger="foo"
> > > loglevel="DEBUG"/>
> > >
> > > Is there a problem when having multiple components using the same
logger?
> > >
> > > <component role="com.foo.Component"
> > > class="com.foo.DefaultComponent"
> > > logger="foo"
> > > loglevel="DEBUG"/>
> > >
> > > <component role="com.foo.Component2"
> > > class="com.foo.DefaultComponent2"
> > > logger="foo"
> > > loglevel="ERROR"/>
> >
> > I don't really like specifying the LOGLEVEL in the
> > component configuration. I think this is something that has to be
> > specified at the class instantiating the loggers. Do you see yourself
> > changing all loglevels in the config file when you deploy it for
> > production?
> >
> > Giacomo
> >
> > >
> > > If the two components share the same logger instance, I don't see how
this
> > > can work. Of course, the fact that I have no idea of how the contract
for
> > > getChildLogger is in respect to multiple children with the same
subcategory.
> > >
> > > /LS
> > >
> > > > -----Original Message-----
> > > > From: Peter Donald [mailto:donaldp@apache.org]
> > > > Sent: den 8 augusti 2001 15:22
> > > > To: Avalon Development
> > > > Subject: Re: JDK1.4 logging vs. LogKit
> > > >
> > > >
> > > > On Wed, 8 Aug 2001 22:42, Berin Loritsch wrote:
> > > > > Peter Donald wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Wed, 8 Aug 2001 06:10, giacomo wrote:
> > > > > >>I have to confess that I don't know how this works in all my
> > > > components
> > > > > >>that are based on AbstractLoggable and have the logger passed in
from
> > > > > >>ExcaliburCM.
> > > > > >
> > > > > > Just looked at ExcaliburCM and it doesn't really support
> > > > separate loggers
> > > > > > per component. Berin what do you think of adding an extra
attribute to
> > > > > > component definition so that you can specify name of logger.
> > > > Then later
> > > > > > on instead of doing
> > > > >
> > > > > I was thinking about that before. We need to add an attribute to
the
> > > > > component definitions (probably "logger"). Something like this
> > > > to specify
> > > > > it:
> > > > >
> > > > > <component role="com.foo.Component"
> > > > > class="com.foo.DefaultComponent"
> > > > > logger="foo"/>
> > > > >
> > > > > The attribute name is negotiable ;).
> > > >
> > > > logger works for me.
> > > >
> > > > > Think this will help, combined with your changes for the Logger?
> > > >
> > > > Which changes are you referring to? It should work without any
changes.
> > > >
>
> --
> --------------------------------------------------------------
> David "Dwayne" Bernard Freelance Developer (Java)
> mailto:dwayne@java-fan.com
> \|/ http://dwayne.java-fan.com
> --o0O @.@ O0o-------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by David BERNARD <dw...@java-fan.com>.
Hi Everyone,
I'm newby in Avalon and C°, and I've got a suggestion (if stupid say
it).
Actually I do a evaluation for "services engine"for my client, and I've
promote Avalon.
The first set of services is for the migration of a old big java
application. This application have some target in services management,
log...
In the first step, we design a from scratch system, and the choice for
log is : "log is a service like anyother". So why, it's not a nice/good
idea to define a role Logger and use a LoggerSelector (use category
string as key) to get the instance of Logger.
In this case, there implementation for LogKit, Log4J... and the
configuration of Log system is independent of each Component
configuration (The default category a component can use is the ROLE
constant).
The problem is all Loggeable must be Composable to access
LoggerSelector.
In this case Configurator/and dynamic Reconfiguration can be develop and
specialize like any Service.
I will try this in my evaluation. If it's OK, then I could give my first
version.
PS: Sorry for my english.
> On Wed, 8 Aug 2001, Leo Sutic wrote:
>
> > Peter, Berin,
> >
> > how will this work with individual log levels for each
> > logger/category/channel?
> >
> > If one adds two properties: logger and loglevel, like this:
> >
> > <component role="com.foo.Component"
> > class="com.foo.DefaultComponent"
> > logger="foo"
> > loglevel="DEBUG"/>
> >
> > Is there a problem when having multiple components using the same logger?
> >
> > <component role="com.foo.Component"
> > class="com.foo.DefaultComponent"
> > logger="foo"
> > loglevel="DEBUG"/>
> >
> > <component role="com.foo.Component2"
> > class="com.foo.DefaultComponent2"
> > logger="foo"
> > loglevel="ERROR"/>
>
> I don't really like specifying the LOGLEVEL in the
> component configuration. I think this is something that has to be
> specified at the class instantiating the loggers. Do you see yourself
> changing all loglevels in the config file when you deploy it for
> production?
>
> Giacomo
>
> >
> > If the two components share the same logger instance, I don't see how this
> > can work. Of course, the fact that I have no idea of how the contract for
> > getChildLogger is in respect to multiple children with the same subcategory.
> >
> > /LS
> >
> > > -----Original Message-----
> > > From: Peter Donald [mailto:donaldp@apache.org]
> > > Sent: den 8 augusti 2001 15:22
> > > To: Avalon Development
> > > Subject: Re: JDK1.4 logging vs. LogKit
> > >
> > >
> > > On Wed, 8 Aug 2001 22:42, Berin Loritsch wrote:
> > > > Peter Donald wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, 8 Aug 2001 06:10, giacomo wrote:
> > > > >>I have to confess that I don't know how this works in all my
> > > components
> > > > >>that are based on AbstractLoggable and have the logger passed in from
> > > > >>ExcaliburCM.
> > > > >
> > > > > Just looked at ExcaliburCM and it doesn't really support
> > > separate loggers
> > > > > per component. Berin what do you think of adding an extra attribute to
> > > > > component definition so that you can specify name of logger.
> > > Then later
> > > > > on instead of doing
> > > >
> > > > I was thinking about that before. We need to add an attribute to the
> > > > component definitions (probably "logger"). Something like this
> > > to specify
> > > > it:
> > > >
> > > > <component role="com.foo.Component"
> > > > class="com.foo.DefaultComponent"
> > > > logger="foo"/>
> > > >
> > > > The attribute name is negotiable ;).
> > >
> > > logger works for me.
> > >
> > > > Think this will help, combined with your changes for the Logger?
> > >
> > > Which changes are you referring to? It should work without any changes.
> > >
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer (Java)
mailto:dwayne@java-fan.com
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: JDK1.4 logging vs. LogKit
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: den 8 augusti 2001 18:09
> To: Avalon Development
> Subject: RE: JDK1.4 logging vs. LogKit
>
>
> I don't really like specifying the LOGLEVEL in the
> component configuration. I think this is something that has to be
> specified at the class instantiating the loggers.
I like it because it allows very fine-grained control over logging levels
and allows for logging configuration for the component manager to be given
in the component manager configuration (and not, as it is now, in a separate
place). I dislike it because it doesn't allow for switching on/off entire
hierarchies of loggers and leads to "paradoxes" as the situation I
described, where the same category has two different logging levels.
I really like the idea of being able switch logging levels for entire
hierarchies - for example, given categories:
cocoon2
cocoon2.mytransformer
cocoon2.mytransformer.mychildlogger
cocoon2.othercomponent
and the logger config:
<logger name="cocoon2" level="INFO"/>
all categories would be logging at the INFO level.
But with:
<logger name="cocoon2" level="INFO">
<logger name="mytransformer" level="DEBUG">
</logger>
cocoon2 and cocoon2.othercomponent are at INFO, cocoon2.mytransformer and
cocoon2.mytransformer.mychildlogger are at DEBUG.
This would be specified in the configuration as, for example:
<components>
<logger name="cocoon2" level="INFO">
<logger name="mytransformer" level="DEBUG">
</logger>
<component role="..." class="..." logger="cocoon2"/>
<component role="..." class="..." logger="cocoon2.mytransformer"/>
.
.
.
</components>
I have this undertaking in my list of stuff that I'd really like to do.
However, I will need to study the behaviour of LogKit and the behaviour of
the component manager in relation to the Logger hierarchy, as well as the
way one specifies logger categories. For example, what if the component
manager above has the category "componentmanager". That would make the fully
qualified names of the cocoon2 logger componentmanager.cocoon2, and so on.
> Do you see yourself
> changing all loglevels in the config file when you deploy it for
> production?
That in itself is no problem and can be automated easily. Replace log levels
with @loglevel.category@ in the config file and use Ant's filtering. I do
this already with host names etc. that differ between development
environment and deployment environment.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: JDK1.4 logging vs. LogKit
Posted by giacomo <gi...@apache.org>.
On Wed, 8 Aug 2001, Leo Sutic wrote:
> Peter, Berin,
>
> how will this work with individual log levels for each
> logger/category/channel?
>
> If one adds two properties: logger and loglevel, like this:
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"
> loglevel="DEBUG"/>
>
> Is there a problem when having multiple components using the same logger?
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"
> loglevel="DEBUG"/>
>
> <component role="com.foo.Component2"
> class="com.foo.DefaultComponent2"
> logger="foo"
> loglevel="ERROR"/>
I don't really like specifying the LOGLEVEL in the
component configuration. I think this is something that has to be
specified at the class instantiating the loggers. Do you see yourself
changing all loglevels in the config file when you deploy it for
production?
Giacomo
>
> If the two components share the same logger instance, I don't see how this
> can work. Of course, the fact that I have no idea of how the contract for
> getChildLogger is in respect to multiple children with the same subcategory.
>
> /LS
>
> > -----Original Message-----
> > From: Peter Donald [mailto:donaldp@apache.org]
> > Sent: den 8 augusti 2001 15:22
> > To: Avalon Development
> > Subject: Re: JDK1.4 logging vs. LogKit
> >
> >
> > On Wed, 8 Aug 2001 22:42, Berin Loritsch wrote:
> > > Peter Donald wrote:
> > > > Hi,
> > > >
> > > > On Wed, 8 Aug 2001 06:10, giacomo wrote:
> > > >>I have to confess that I don't know how this works in all my
> > components
> > > >>that are based on AbstractLoggable and have the logger passed in from
> > > >>ExcaliburCM.
> > > >
> > > > Just looked at ExcaliburCM and it doesn't really support
> > separate loggers
> > > > per component. Berin what do you think of adding an extra attribute to
> > > > component definition so that you can specify name of logger.
> > Then later
> > > > on instead of doing
> > >
> > > I was thinking about that before. We need to add an attribute to the
> > > component definitions (probably "logger"). Something like this
> > to specify
> > > it:
> > >
> > > <component role="com.foo.Component"
> > > class="com.foo.DefaultComponent"
> > > logger="foo"/>
> > >
> > > The attribute name is negotiable ;).
> >
> > logger works for me.
> >
> > > Think this will help, combined with your changes for the Logger?
> >
> > Which changes are you referring to? It should work without any changes.
> >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > *-----------------------------------------------------*
> > | "Faced with the choice between changing one's mind, |
> > | and proving that there is no need to do so - almost |
> > | everyone gets busy on the proof." |
> > | - John Kenneth Galbraith |
> > *-----------------------------------------------------*
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: JDK1.4 logging vs. LogKit
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Peter, Berin,
how will this work with individual log levels for each
logger/category/channel?
If one adds two properties: logger and loglevel, like this:
<component role="com.foo.Component"
class="com.foo.DefaultComponent"
logger="foo"
loglevel="DEBUG"/>
Is there a problem when having multiple components using the same logger?
<component role="com.foo.Component"
class="com.foo.DefaultComponent"
logger="foo"
loglevel="DEBUG"/>
<component role="com.foo.Component2"
class="com.foo.DefaultComponent2"
logger="foo"
loglevel="ERROR"/>
If the two components share the same logger instance, I don't see how this
can work. Of course, the fact that I have no idea of how the contract for
getChildLogger is in respect to multiple children with the same subcategory.
/LS
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: den 8 augusti 2001 15:22
> To: Avalon Development
> Subject: Re: JDK1.4 logging vs. LogKit
>
>
> On Wed, 8 Aug 2001 22:42, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > Hi,
> > >
> > > On Wed, 8 Aug 2001 06:10, giacomo wrote:
> > >>I have to confess that I don't know how this works in all my
> components
> > >>that are based on AbstractLoggable and have the logger passed in from
> > >>ExcaliburCM.
> > >
> > > Just looked at ExcaliburCM and it doesn't really support
> separate loggers
> > > per component. Berin what do you think of adding an extra attribute to
> > > component definition so that you can specify name of logger.
> Then later
> > > on instead of doing
> >
> > I was thinking about that before. We need to add an attribute to the
> > component definitions (probably "logger"). Something like this
> to specify
> > it:
> >
> > <component role="com.foo.Component"
> > class="com.foo.DefaultComponent"
> > logger="foo"/>
> >
> > The attribute name is negotiable ;).
>
> logger works for me.
>
> > Think this will help, combined with your changes for the Logger?
>
> Which changes are you referring to? It should work without any changes.
>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
> --
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Donald <do...@apache.org>.
On Wed, 8 Aug 2001 22:42, Berin Loritsch wrote:
> Peter Donald wrote:
> > Hi,
> >
> > On Wed, 8 Aug 2001 06:10, giacomo wrote:
> >>I have to confess that I don't know how this works in all my components
> >>that are based on AbstractLoggable and have the logger passed in from
> >>ExcaliburCM.
> >
> > Just looked at ExcaliburCM and it doesn't really support separate loggers
> > per component. Berin what do you think of adding an extra attribute to
> > component definition so that you can specify name of logger. Then later
> > on instead of doing
>
> I was thinking about that before. We need to add an attribute to the
> component definitions (probably "logger"). Something like this to specify
> it:
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"/>
>
> The attribute name is negotiable ;).
logger works for me.
> Think this will help, combined with your changes for the Logger?
Which changes are you referring to? It should work without any changes.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
--
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by giacomo <gi...@apache.org>.
On Wed, 8 Aug 2001, Berin Loritsch wrote:
> Peter Donald wrote:
> > Hi,
> >
> > On Wed, 8 Aug 2001 06:10, giacomo wrote:
> >
> >>I have to confess that I don't know how this works in all my components
> >>that are based on AbstractLoggable and have the logger passed in from
> >>ExcaliburCM.
> >>
> >
> > Just looked at ExcaliburCM and it doesn't really support separate loggers per
> > component. Berin what do you think of adding an extra attribute to component
> > definition so that you can specify name of logger. Then later on instead of
> > doing
>
>
> I was thinking about that before. We need to add an attribute to the component
> definitions (probably "logger"). Something like this to specify it:
>
> <component role="com.foo.Component"
> class="com.foo.DefaultComponent"
> logger="foo"/>
>
> The attribute name is negotiable ;).
>
> Think this will help, combined with your changes for the Logger?
I like it, +1.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> Hi,
>
> On Wed, 8 Aug 2001 06:10, giacomo wrote:
>
>>I have to confess that I don't know how this works in all my components
>>that are based on AbstractLoggable and have the logger passed in from
>>ExcaliburCM.
>>
>
> Just looked at ExcaliburCM and it doesn't really support separate loggers per
> component. Berin what do you think of adding an extra attribute to component
> definition so that you can specify name of logger. Then later on instead of
> doing
I was thinking about that before. We need to add an attribute to the component
definitions (probably "logger"). Something like this to specify it:
<component role="com.foo.Component"
class="com.foo.DefaultComponent"
logger="foo"/>
The attribute name is negotiable ;).
Think this will help, combined with your changes for the Logger?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Donald <do...@apache.org>.
Hi,
On Wed, 8 Aug 2001 06:10, giacomo wrote:
> I have to confess that I don't know how this works in all my components
> that are based on AbstractLoggable and have the logger passed in from
> ExcaliburCM.
Just looked at ExcaliburCM and it doesn't really support separate loggers per
component. Berin what do you think of adding an extra attribute to component
definition so that you can specify name of logger. Then later on instead of
doing
myComponent.setLogger( getLogger() );
you do
if( null != loggerName )
{
myComponent.setLogger( getLogger().getChildLogger( loggerName ) )
}
else
{
myComponent.setLogger( getLogger() )
}
Thoughts?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by giacomo <gi...@apache.org>.
On Tue, 7 Aug 2001, Peter Donald wrote:
> On Tue, 7 Aug 2001 15:12, giacomo wrote:
> > > Peter, what do you think of adding two additional log levels
> > > below DEBUG in LogKit?
> > >
> > > The new hierarchy of debug levels would be:
> > >
> > > INFRASTRUCTURE
> > > CLASSLOADER
> > > DEBUG
> > > INFO
> > > WARN
> > > ERROR
> > > FATAL_ERROR
> > >
> > > Alternatively, we could call them DEBUG3 and DEBUG2 respectively,
> > > but it does not capture the intent of those log levels properly.
> >
> > And I lately had the need for a log level between DEBUG and INFO which
> > I'd like to call TRACE. This was because we used (esp. Cocoon) the DEBUG
> > level for exactly that but had the need to separate out other (tracing)
> > information that doesn't belong to the INFO level. In the environment
> > our Avalon/Cocoon application is running the levels INFO and higher will
> > be used by the support staff to detect failures and anomalies.
>
> I used to have another level in there - EDEBUG for Extreme DEBUGing ;)
> However I still think that what you probably want is more fine grain
> categorys setup. That way each category (or channel, or subject or whatever
> you call it) is explicitly setup to carry a certain type of information and
> can control it more effectively. Could this work with Cocoon?
I have to confess that I don't know how this works in all my components
that are based on AbstractLoggable and have the logger passed in from
ExcaliburCM.
Giacomo
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by Peter Donald <do...@apache.org>.
On Tue, 7 Aug 2001 15:12, giacomo wrote:
> > Peter, what do you think of adding two additional log levels
> > below DEBUG in LogKit?
> >
> > The new hierarchy of debug levels would be:
> >
> > INFRASTRUCTURE
> > CLASSLOADER
> > DEBUG
> > INFO
> > WARN
> > ERROR
> > FATAL_ERROR
> >
> > Alternatively, we could call them DEBUG3 and DEBUG2 respectively,
> > but it does not capture the intent of those log levels properly.
>
> And I lately had the need for a log level between DEBUG and INFO which
> I'd like to call TRACE. This was because we used (esp. Cocoon) the DEBUG
> level for exactly that but had the need to separate out other (tracing)
> information that doesn't belong to the INFO level. In the environment
> our Avalon/Cocoon application is running the levels INFO and higher will
> be used by the support staff to detect failures and anomalies.
I used to have another level in there - EDEBUG for Extreme DEBUGing ;)
However I still think that what you probably want is more fine grain
categorys setup. That way each category (or channel, or subject or whatever
you call it) is explicitly setup to carry a certain type of information and
can control it more effectively. Could this work with Cocoon?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JDK1.4 logging vs. LogKit
Posted by giacomo <gi...@apache.org>.
On Thu, 2 Aug 2001, Berin Loritsch wrote:
> I have been thinking, and one of the previous arguments
> against Java's Logging API was, "Who needs three levels
> of debugging?".
>
> In developing with Cocoon, it has become clear that three
> levels of debugging may in fact be just what the doctor
> ordered. Let me give you a scenario:
>
> Excalibur's ComponentManager and ComponentSelector and
> friends output _alot_ of debugging code. It is what
> makes it so easy to maintain. However, I don't want
> to clutter the logfile with all that information unless
> I really need to. Therefore I need a base log level
> for INFRASTRUCTURE, so that I can see the inner workings
> if I wanted to.
>
> Second, in order to track down ClassLoader issues using
> Excalibur's Factories and Pools, It would be useful to
> output a message saying "loading class xxxx with ClassLoader
> Classloader$3242335" at a higher level. That way by placing
> this type of information at an CLASSLOADER priority, I
> can easily filter it out--but I have it if I need it and I
> don't have to troll through all the INFRASTRUCTURE level
> entries to find them.
>
> Last, we would need an APPLICATION level debugging to differentiate
> between Cocoon's DEBUG information and Avalon's. This way,
> I don't have to artificially upgrade Cocoon's logging
> entries on new components while I am developing them. Using
> that approach I record the component's log entries at INFO--unless
> I catch an exception which has to be at DEBUG or WARN and above.
> This is not desireable to me.
>
> Peter, what do you think of adding two additional log levels
> below DEBUG in LogKit?
>
> The new hierarchy of debug levels would be:
>
> INFRASTRUCTURE
> CLASSLOADER
> DEBUG
> INFO
> WARN
> ERROR
> FATAL_ERROR
>
> Alternatively, we could call them DEBUG3 and DEBUG2 respectively,
> but it does not capture the intent of those log levels properly.
And I lately had the need for a log level between DEBUG and INFO which
I'd like to call TRACE. This was because we used (esp. Cocoon) the DEBUG
level for exactly that but had the need to separate out other (tracing)
information that doesn't belong to the INFO level. In the environment
our Avalon/Cocoon application is running the levels INFO and higher will
be used by the support staff to detect failures and anomalies.
Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org