I posed the question to the Avalon guys about oficially collaborating
with the Log4J team regarding the future direction of LogKit and Log4J.
The major thing is that the Avalon team wants to focus on their core
art which is the Framework and its containers, not the Logging toolkit.
As a breif history for those who don't know, Avalon LogKit was created
by Peter Donald and introduced prior to Log4J's acceptance to Apache.
Avalon did need a proper logging tool, and at the time, Peter's
contribution seemed the best road to take. There have been attempts to
make one logging toolkit in the past, but they have failed for various
reasons. One of the chief reasons is that the Avalon team was not
ready at that time to cooperate.
Over the years, both Log4J and LogKit learned from each other. There
were different basic philosophies regarding how to use the loggers,
but I think they can be resolved. Log4J has always lead the feature
list, and LogKit has always remained small and compact (Log4J is 345k
and LogKit is 85k).
Nicola Ken turned me on to the fact that Ceki was interested in getting
us to work together. To that end, I want to lay down what the Avalon
team would like to see (which I think is reasonable):
* The Logger instance does not combine factory and logging logic
together.
- For systems where IOC is important (like Avalon), the Logger has
a pure concept, and it cannot be obtained by other means.
- For systems where static a factory is important, like Jakarta
Commons, another class can provide that access (preferably in
a separate JAR)
- If the factory is never used, then we have better control in
complex classloader enabled systems.
* The concept of a micro-jar would be entertained.
- LogKit is small because it does not have any direct configuration
logic or other utilities.
- When 25% of the size handles 80% or more of the needs, then most
systems should be able to optimize for what they really want/need.
* All the log targets that LogKit has should be available in some
form with Log4J (which I think is the case already).
I really don't think these are all that demanding, and we would
like to help in the process if possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
