avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Excalibur Logger Improvements
Date Thu, 02 Oct 2003 18:32:44 GMT
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

View raw message