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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
