You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/10/02 06:41:42 UTC
Excalibur Logger - questions
I'm starting to dig though Excalibur Logger with the objective of
sorting out integration of this package into the Merlin Kernel. Looking
a the test cases - things are not so clear. Would it be better to look
at Fortress handling of the LoggingManager setup? Any hints/suggestions
welcome.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Noel J. Bergman wrote:
>
>> Stephen McConnell wrote:
>>
>>
>>> Noel J. Bergman wrote:
>>>
>>>
>>>> While on this topic ... James is a Mailet container. We have a
>>>> single log channel for all Mailet log messages. However, James
>>>> might want to change the priority so that a particular mailet uses
>>>> DEBUG priority while others are at the default. I see that
>>>> Logger.getPriority is deprecated. What is the recommended
>>>> solution? Are we supposed to create a child logger just to be able
>>>> to control the priority?
>>>>
>>>
>>
>>
>>
>>> Yes.
>>>
>>
>>
>> I'll have to log more into LogKit to see what help it provides to us for
>> managing that situation. And yes, I have read Berin's message about
>> channels (log destinations) and targets (log specifiers), so I
>> supposed we
>> could check for the presence of a child log for the mailet, e.g.,
>> "mailet.<class>", and use the mailet log if the child log is not
>> found in
>> the environment.
>>
>> The other thing I want to do (or see someone else do, if they've
>> time) is to
>> separate out protocol logging from in-line with the rest of the service,
>> e.g., the SMTP server would have its normal log and a protocol log as a
>> child. The latter would have just the wire-level messages. That would
>> allow keeping the normal log information as part of standard
>> administrative
>> practices, and allow keeping a "recent history" of wire-level
>> transactions.
>> For example, I don't normally keep the wire-level data, but there are
>> occasions where I want to see what is happening. Being able to have
>> a size
>> limited log, keeping say the last 1MB (or N log messages) of wire-level
>> information (not DATA) would be helpful.
>>
>> I know we can rotate on size, but what would be the easiest way to
>> keep just
>> the above sort of size limited log? Is there a suitable log
>> implementation
>> already provided?
>>
>
> The way I deal with this is to create child loggers to seperate out
> these sort of concerns. In the SMTP server you are suipplied a logger
> and in the code you can invoke something like:
>
> Logger protocolLogger = getLogger().getChildLogger( "protocol" );
>
> In you log configration you should be able to declare a seperate
> priority and possible seperate target for the james.smtp.protocol
> logging category.
>
> Steve.
>
p.s. Under the new Avalon Meta package your components can declare the
internal logging channels that it consumes. This information can be
used to automate jmx based controls that will (in the near future)
enable interactive control of logging channel priorities and targets for
components.
SJM.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Noel J. Bergman wrote:
>
>> Stephen McConnell wrote:
>>
>>
>>> Noel J. Bergman wrote:
>>>
>>>
>>>> While on this topic ... James is a Mailet container. We have a
>>>> single log channel for all Mailet log messages. However, James
>>>> might want to change the priority so that a particular mailet uses
>>>> DEBUG priority while others are at the default. I see that
>>>> Logger.getPriority is deprecated. What is the recommended
>>>> solution? Are we supposed to create a child logger just to be able
>>>> to control the priority?
>>>>
>>>
>>
>>
>>
>>> Yes.
>>>
>>
>>
>> I'll have to log more into LogKit to see what help it provides to us for
>> managing that situation. And yes, I have read Berin's message about
>> channels (log destinations) and targets (log specifiers), so I
>> supposed we
>> could check for the presence of a child log for the mailet, e.g.,
>> "mailet.<class>", and use the mailet log if the child log is not
>> found in
>> the environment.
>>
>> The other thing I want to do (or see someone else do, if they've
>> time) is to
>> separate out protocol logging from in-line with the rest of the service,
>> e.g., the SMTP server would have its normal log and a protocol log as a
>> child. The latter would have just the wire-level messages. That would
>> allow keeping the normal log information as part of standard
>> administrative
>> practices, and allow keeping a "recent history" of wire-level
>> transactions.
>> For example, I don't normally keep the wire-level data, but there are
>> occasions where I want to see what is happening. Being able to have
>> a size
>> limited log, keeping say the last 1MB (or N log messages) of wire-level
>> information (not DATA) would be helpful.
>>
>> I know we can rotate on size, but what would be the easiest way to
>> keep just
>> the above sort of size limited log? Is there a suitable log
>> implementation
>> already provided?
>>
>
> The way I deal with this is to create child loggers to seperate out
> these sort of concerns. In the SMTP server you are suipplied a logger
> and in the code you can invoke something like:
>
> Logger protocolLogger = getLogger().getChildLogger( "protocol" );
>
> In you log configration you should be able to declare a seperate
> priority and possible seperate target for the james.smtp.protocol
> logging category.
>
> Steve.
>
p.s. Under the new Avalon Meta package your components can declare the
internal logging channels that it consumes. This information can be
used to automate jmx based controls that will (in the near future)
enable interactive control of logging channel priorities and targets for
components.
SJM.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>>I know we can rotate on size, but what would be the easiest way to keep
>>>
>>>
>just
>
>
>>>the above sort of size limited log? Is there a suitable log
>>>
>>>
>implementation
>
>
>>>already provided?
>>>
>>>
>
>
>
>>The way I deal with this is to create child loggers to seperate out
>>these sort of concerns. In the SMTP server you are suipplied a logger
>>and in the code you can invoke something like:
>>
>>
>
>
>
>> Logger protocolLogger = getLogger().getChildLogger( "protocol" );
>>
>>
>
>
>
>>In you log configration you should be able to declare a seperate
>>priority and possible seperate target for the james.smtp.protocol
>>logging category.
>>
>>
>
>Yes, I understood that, Steven, although I thank for you the clear
>explanation. You will find almost that exact line of code in James.java
>where it gets the mailet logger, since the Mailet log is a child of the
>James log.
>
>The question wasn't how to get the protocol logger, but rather how to have a
>log file limited to either a certain size or number of log entries. I'm
>only familar with the rotation scheme, which could be used to rotate when
>the log reaches a limit, but that doesn't appear to directly handle the
>issue of keeping just the most recent messages, without having an external
>process deleting the old logs.
>
I had a sneaking suspision that I may have been ansering the wrong
question! Sorry about that. What your describing about if a particular
policy on a log target. I honestly don't know much aboput this area -
but just looking at the javadoc - my guess is that what you are
describing is an file stategy with "append" enabled, "size" limit
declared and no rotation strategy. But I'm guessing!
Stephen.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>>I know we can rotate on size, but what would be the easiest way to keep
>>>
>>>
>just
>
>
>>>the above sort of size limited log? Is there a suitable log
>>>
>>>
>implementation
>
>
>>>already provided?
>>>
>>>
>
>
>
>>The way I deal with this is to create child loggers to seperate out
>>these sort of concerns. In the SMTP server you are suipplied a logger
>>and in the code you can invoke something like:
>>
>>
>
>
>
>> Logger protocolLogger = getLogger().getChildLogger( "protocol" );
>>
>>
>
>
>
>>In you log configration you should be able to declare a seperate
>>priority and possible seperate target for the james.smtp.protocol
>>logging category.
>>
>>
>
>Yes, I understood that, Steven, although I thank for you the clear
>explanation. You will find almost that exact line of code in James.java
>where it gets the mailet logger, since the Mailet log is a child of the
>James log.
>
>The question wasn't how to get the protocol logger, but rather how to have a
>log file limited to either a certain size or number of log entries. I'm
>only familar with the rotation scheme, which could be used to rotate when
>the log reaches a limit, but that doesn't appear to directly handle the
>issue of keeping just the most recent messages, without having an external
>process deleting the old logs.
>
I had a sneaking suspision that I may have been ansering the wrong
question! Sorry about that. What your describing about if a particular
policy on a log target. I honestly don't know much aboput this area -
but just looking at the javadoc - my guess is that what you are
describing is an file stategy with "append" enabled, "size" limit
declared and no rotation strategy. But I'm guessing!
Stephen.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Excalibur Logger Improvements
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >I know we can rotate on size, but what would be the easiest way to keep
just
> >the above sort of size limited log? Is there a suitable log
implementation
> >already provided?
> The way I deal with this is to create child loggers to seperate out
> these sort of concerns. In the SMTP server you are suipplied a logger
> and in the code you can invoke something like:
> Logger protocolLogger = getLogger().getChildLogger( "protocol" );
> In you log configration you should be able to declare a seperate
> priority and possible seperate target for the james.smtp.protocol
> logging category.
Yes, I understood that, Steven, although I thank for you the clear
explanation. You will find almost that exact line of code in James.java
where it gets the mailet logger, since the Mailet log is a child of the
James log.
The question wasn't how to get the protocol logger, but rather how to have a
log file limited to either a certain size or number of log entries. I'm
only familar with the rotation scheme, which could be used to rotate when
the log reaches a limit, but that doesn't appear to directly handle the
issue of keeping just the most recent messages, without having an external
process deleting the old logs.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Logger Improvements
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >I know we can rotate on size, but what would be the easiest way to keep
just
> >the above sort of size limited log? Is there a suitable log
implementation
> >already provided?
> The way I deal with this is to create child loggers to seperate out
> these sort of concerns. In the SMTP server you are suipplied a logger
> and in the code you can invoke something like:
> Logger protocolLogger = getLogger().getChildLogger( "protocol" );
> In you log configration you should be able to declare a seperate
> priority and possible seperate target for the james.smtp.protocol
> logging category.
Yes, I understood that, Steven, although I thank for you the clear
explanation. You will find almost that exact line of code in James.java
where it gets the mailet logger, since the Mailet log is a child of the
James log.
The question wasn't how to get the protocol logger, but rather how to have a
log file limited to either a certain size or number of log entries. I'm
only familar with the rotation scheme, which could be used to rotate when
the log reaches a limit, but that doesn't appear to directly handle the
issue of keeping just the most recent messages, without having an external
process deleting the old logs.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen McConnell wrote:
>
>
>>Noel J. Bergman wrote:
>>
>>
>>>While on this topic ... James is a Mailet container. We have a
>>>single log channel for all Mailet log messages. However, James
>>>might want to change the priority so that a particular mailet uses
>>>DEBUG priority while others are at the default. I see that
>>>Logger.getPriority is deprecated. What is the recommended
>>>solution? Are we supposed to create a child logger just to be
>>>able to control the priority?
>>>
>>>
>
>
>
>>Yes.
>>
>>
>
>I'll have to log more into LogKit to see what help it provides to us for
>managing that situation. And yes, I have read Berin's message about
>channels (log destinations) and targets (log specifiers), so I supposed we
>could check for the presence of a child log for the mailet, e.g.,
>"mailet.<class>", and use the mailet log if the child log is not found in
>the environment.
>
>The other thing I want to do (or see someone else do, if they've time) is to
>separate out protocol logging from in-line with the rest of the service,
>e.g., the SMTP server would have its normal log and a protocol log as a
>child. The latter would have just the wire-level messages. That would
>allow keeping the normal log information as part of standard administrative
>practices, and allow keeping a "recent history" of wire-level transactions.
>For example, I don't normally keep the wire-level data, but there are
>occasions where I want to see what is happening. Being able to have a size
>limited log, keeping say the last 1MB (or N log messages) of wire-level
>information (not DATA) would be helpful.
>
>I know we can rotate on size, but what would be the easiest way to keep just
>the above sort of size limited log? Is there a suitable log implementation
>already provided?
>
The way I deal with this is to create child loggers to seperate out
these sort of concerns. In the SMTP server you are suipplied a logger
and in the code you can invoke something like:
Logger protocolLogger = getLogger().getChildLogger( "protocol" );
In you log configration you should be able to declare a seperate
priority and possible seperate target for the james.smtp.protocol
logging category.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen McConnell wrote:
>
>
>>Noel J. Bergman wrote:
>>
>>
>>>While on this topic ... James is a Mailet container. We have a
>>>single log channel for all Mailet log messages. However, James
>>>might want to change the priority so that a particular mailet uses
>>>DEBUG priority while others are at the default. I see that
>>>Logger.getPriority is deprecated. What is the recommended
>>>solution? Are we supposed to create a child logger just to be
>>>able to control the priority?
>>>
>>>
>
>
>
>>Yes.
>>
>>
>
>I'll have to log more into LogKit to see what help it provides to us for
>managing that situation. And yes, I have read Berin's message about
>channels (log destinations) and targets (log specifiers), so I supposed we
>could check for the presence of a child log for the mailet, e.g.,
>"mailet.<class>", and use the mailet log if the child log is not found in
>the environment.
>
>The other thing I want to do (or see someone else do, if they've time) is to
>separate out protocol logging from in-line with the rest of the service,
>e.g., the SMTP server would have its normal log and a protocol log as a
>child. The latter would have just the wire-level messages. That would
>allow keeping the normal log information as part of standard administrative
>practices, and allow keeping a "recent history" of wire-level transactions.
>For example, I don't normally keep the wire-level data, but there are
>occasions where I want to see what is happening. Being able to have a size
>limited log, keeping say the last 1MB (or N log messages) of wire-level
>information (not DATA) would be helpful.
>
>I know we can rotate on size, but what would be the easiest way to keep just
>the above sort of size limited log? Is there a suitable log implementation
>already provided?
>
The way I deal with this is to create child loggers to seperate out
these sort of concerns. In the SMTP server you are suipplied a logger
and in the code you can invoke something like:
Logger protocolLogger = getLogger().getChildLogger( "protocol" );
In you log configration you should be able to declare a seperate
priority and possible seperate target for the james.smtp.protocol
logging category.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Logger Improvements
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen McConnell wrote:
> Noel J. Bergman wrote:
> >While on this topic ... James is a Mailet container. We have a single
log
> >channel for all Mailet log messages. However, James might want to change
> >the priority so that a particular mailet uses DEBUG priority while others
> >are at the default. I see that Logger.getPriority is deprecated. What
is
> >the recommended solution? Are we supposed to create a child logger just
to
> >be able to control the priority?
> Yes.
I'll have to log more into LogKit to see what help it provides to us for
managing that situation. And yes, I have read Berin's message about
channels (log destinations) and targets (log specifiers), so I supposed we
could check for the presence of a child log for the mailet, e.g.,
"mailet.<class>", and use the mailet log if the child log is not found in
the environment.
The other thing I want to do (or see someone else do, if they've time) is to
separate out protocol logging from in-line with the rest of the service,
e.g., the SMTP server would have its normal log and a protocol log as a
child. The latter would have just the wire-level messages. That would
allow keeping the normal log information as part of standard administrative
practices, and allow keeping a "recent history" of wire-level transactions.
For example, I don't normally keep the wire-level data, but there are
occasions where I want to see what is happening. Being able to have a size
limited log, keeping say the last 1MB (or N log messages) of wire-level
information (not DATA) would be helpful.
I know we can rotate on size, but what would be the easiest way to keep just
the above sort of size limited log? Is there a suitable log implementation
already provided?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Logger Improvements
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen McConnell wrote:
> Noel J. Bergman wrote:
> >While on this topic ... James is a Mailet container. We have a single
log
> >channel for all Mailet log messages. However, James might want to change
> >the priority so that a particular mailet uses DEBUG priority while others
> >are at the default. I see that Logger.getPriority is deprecated. What
is
> >the recommended solution? Are we supposed to create a child logger just
to
> >be able to control the priority?
> Yes.
I'll have to log more into LogKit to see what help it provides to us for
managing that situation. And yes, I have read Berin's message about
channels (log destinations) and targets (log specifiers), so I supposed we
could check for the presence of a child log for the mailet, e.g.,
"mailet.<class>", and use the mailet log if the child log is not found in
the environment.
The other thing I want to do (or see someone else do, if they've time) is to
separate out protocol logging from in-line with the rest of the service,
e.g., the SMTP server would have its normal log and a protocol log as a
child. The latter would have just the wire-level messages. That would
allow keeping the normal log information as part of standard administrative
practices, and allow keeping a "recent history" of wire-level transactions.
For example, I don't normally keep the wire-level data, but there are
occasions where I want to see what is happening. Being able to have a size
limited log, keeping say the last 1MB (or N log messages) of wire-level
information (not DATA) would be helpful.
I know we can rotate on size, but what would be the easiest way to keep just
the above sort of size limited log? Is there a suitable log implementation
already provided?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Excalibur Logger Improvements
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Berin,
>
>While on this topic ... James is a Mailet container. We have a single log
>channel for all Mailet log messages. However, James might want to change
>the priority so that a particular mailet uses DEBUG priority while others
>are at the default. I see that Logger.getPriority is deprecated. What is
>the recommended solution? Are we supposed to create a child logger just to
>be able to control the priority?
>
Yes.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger Improvements
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
> Berin,
>
> While on this topic ... James is a Mailet container. We have a single log
> channel for all Mailet log messages. However, James might want to change
> the priority so that a particular mailet uses DEBUG priority while others
> are at the default. I see that Logger.getPriority is deprecated. What is
> the recommended solution? Are we supposed to create a child logger just to
> be able to control the priority?
Not necessarily.
Note the distinction between "channel" and "target".
Each "channel" represents the destination for a set of log entries. For
instance, the mailet.log file. A channel might send the log entries to more
than one location, but it is only one definition for a destination for log
entries.
Each "target" represents a named scope for log messages. In essence, you might
have each mailet have individual targets like this: mailet.spamassassin,
mailet.autorespond, mailet.avalon.mail-list. These targets not only help you
sort out what log entry is for which mailet, but they also allow you to provide
a different priority and channel set for each target.
Both Log4J and LogKit allow you to do this, and the LogKit config file separates
it into separate sections in the same file (not the best, but bear with me for
a minute):
We define a set of channels:
mailet.log -> The mailet log channel
james.log -> Everything else
Then we define our targets:
mailet.spamassassin
uses mailet.log with DEBUG priority
mailet.autorespond
uses mailet.log with INFO priority
mailet.avalon.mail-list
uses mailet.log with INFO priority
uses james.log with ERROR priority
See the distinction? I believe that this is something that Stephen wants in a
clearer format than what is in the Excalibur Logger package.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Logger Improvements
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin,
While on this topic ... James is a Mailet container. We have a single log
channel for all Mailet log messages. However, James might want to change
the priority so that a particular mailet uses DEBUG priority while others
are at the default. I see that Logger.getPriority is deprecated. What is
the recommended solution? Are we supposed to create a child logger just to
be able to control the priority?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger Improvements
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
I did a little start on the separation into the API/classes, etc. Unfortunately
I am running out of time for today, so I can come back to it tomorrow. The main
question before I move forward with this proposal is if it makes sense in
overall concept or not.
It also appears that there is some new "facade" stuff in there, I guess to use
more than one logger manager at a time. That would force our hand on adding a
"facade" subproject.
Also note that I did not attempt to add in the Maven build classes yet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Excalibur Logger Improvements
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> I'm digging into Excalibur Logger as we speak. I remember doing this
> way back and I'm now starting to remember all of the reasons why I don't
> leverage Excalibur Logger at the time. What it comes down to is a few
> problems:
>
> (a) as Berin mentioned - lots of legacy cruft to sift thought
> (b) is too tightly linked with LogKit in its current form
> (c) does not seperate easily named targets establishment from
> parameterized channel establishment
>
> On item (a) a version 2.0 could clear this away.
> On item (b) a new set of SPI interfaces could resolve this + refactoring
> of implementations
> On item (c) means proper thinking and upgrades across multiple
> implemetations
>
> Which all suggests a lot of time - which brings us back to the "use as
> is" scenario - but this is problamatic because Merlin needs seperation
> of target creation from channel creation.
>
> I.e I don't know yet.
:)
Let's talk a bit about Excalibur Logger for a minute. I like your summary
above. First, let me provide some background:
This package was originally created to answer a need in Cocoon where LogKit
was not able to read a configuration file and create the log heirarchy
flexibly, based on user requirements. In essense, it is focused primarily
on the parameterized channel establishment. The crude method of mapping
the channels to the target names was introduced, but never separated into
a new file--i.e. no user requirement for that.
Eventually, folks wanted to use other loggers than LogKit with Avalon. That's
cool, but that meant we needed to change the interface. That is why we have
a LogKitManager and a LoggerManager. Additional cruft was added because we took
the Framework style creation process too far and introduced a LogKitManageable
interface to pass the LogKitManager into the ECM. When I introduced the
LoggerManager interface, I purposely did not include an upgrade for the
LogKitMangeable interface because the LoggerManager could easily be passed in
through the ServiceManager or the Context object.
Eventually the LogKitLoggerManager was a wrapper around the old LogKitManager
and the factory class implementation that it had there. Additionally, there
were some rough hewn implementations for other logging tools, that primarily
relied on the tool's methods for configuration and setup.
The target Loggers are created on demand in each case--again relying on the
tool to manage the Channels and set everything up.
That at least explains where we are.
I believe the LoggerManager in its simple form is a decent way to access the
Logger for any particular target name. Nothing has been done to address the
channel separation. Again, it is decent, but not necessarily the best.
It seems that you have come accross the desire/need to separate channel
definition and channel mapping. Perhaps if we hear your side of the table,
we can see where the simplest mapping can go.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger - questions
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>>From a user's prespective, whatever path would allow Merin to provide proper
>logging removes a barrier to adopting it as a standard container. The
>cleaner proposal is a good one, but is what is the difference in delivery
>time?
>
I'm digging into Excalibur Logger as we speak. I remember doing this
way back and I'm now starting to remember all of the reasons why I don't
leverage Excalibur Logger at the time. What it comes down to is a few
problems:
(a) as Berin mentioned - lots of legacy cruft to sift thought
(b) is too tightly linked with LogKit in its current form
(c) does not seperate easily named targets establishment from
parameterized channel establishment
On item (a) a version 2.0 could clear this away.
On item (b) a new set of SPI interfaces could resolve this + refactoring
of implementations
On item (c) means proper thinking and upgrades across multiple
implemetations
Which all suggests a lot of time - which brings us back to the "use as
is" scenario - but this is problamatic because Merlin needs seperation
of target creation from channel creation.
I.e I don't know yet.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Logger - questions
Posted by "Noel J. Bergman" <no...@devtech.com>.
>From a user's prespective, whatever path would allow Merin to provide proper
logging removes a barrier to adopting it as a standard container. The
cleaner proposal is a good one, but is what is the difference in delivery
time?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger - questions
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>>
>>> I'm starting to dig though Excalibur Logger with the objective of
>>> sorting out integration of this package into the Merlin Kernel.
>>> Looking a the test cases - things are not so clear. Would it be
>>> better to look at Fortress handling of the LoggingManager setup? Any
>>> hints/suggestions welcome.
>>
>>
>>
>> That would be best. Really, the process isn't so hard, its just
>> confusing
>> because of the legacy crap in there.
>
>
>
> Your not wrong!
>
> If I look at the interfaces - we have LoggerManager which is primary
> service interface. Also in the package are a bunch of interfaces
> related to LogTargets. These interfaces reference LogKit (e.g.
> org.apache.log.LogTarget). So in fact - what we have is parts of
> LogKit are making up the API and parts of logkit are used as one of
> multiple possible implementations.
>
> I'm just wondering if it would make sence to think about Excalibur
> Logger V2 as a clean LogKit independent SPI without the legacy content
> backed with plugable implementations.
>
> Any thoughts?
:) It's one of those things I've been thinking of for a while now.
Here is the separation I have been thinking of:
* API (current API, no deprecated)
* LogKit Implementation
* Log4J Implementation
* Java 1.4 Logging Implementation (if it is there)
* Legacy compatibility crap (might be a moot point if necessary for
the LogKit implementation)
That way we have the API, and you can always choose which implementation
makes sense for your project.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger - questions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> I'm starting to dig though Excalibur Logger with the objective of
>> sorting out integration of this package into the Merlin Kernel.
>> Looking a the test cases - things are not so clear. Would it be
>> better to look at Fortress handling of the LoggingManager setup? Any
>> hints/suggestions welcome.
>
>
> That would be best. Really, the process isn't so hard, its just
> confusing
> because of the legacy crap in there.
Your not wrong!
If I look at the interfaces - we have LoggerManager which is primary
service interface. Also in the package are a bunch of interfaces
related to LogTargets. These interfaces reference LogKit (e.g.
org.apache.log.LogTarget). So in fact - what we have is parts of
LogKit are making up the API and parts of logkit are used as one of
multiple possible implementations.
I'm just wondering if it would make sence to think about Excalibur
Logger V2 as a clean LogKit independent SPI without the legacy content
backed with plugable implementations.
Any thoughts?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Logger - questions
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> I'm starting to dig though Excalibur Logger with the objective of
> sorting out integration of this package into the Merlin Kernel. Looking
> a the test cases - things are not so clear. Would it be better to look
> at Fortress handling of the LoggingManager setup? Any hints/suggestions
> welcome.
That would be best. Really, the process isn't so hard, its just confiusing
because of the legacy crap in there.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org