It really great to see your post. Answers in line.
At 12:04 PM 6/17/2003 -0400, Berin Loritsch wrote:
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.
Let bygones be bygones.
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):
I have yet to see an unreasonable demand made by our users. Your requests are not an exception. :-)
However, as I have stated in the past both privately and publicly, we are ready to take the necessary steps to satisfy the Avalon community. Let me address the points you raised.
* 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.
Agreed completely. With hindsight, I think the Logger (aka Category class) should have been an interface. This is one of my secret plans for log4j version 2.0, the one after 1.3. Having said that, I don't see how to accomplish strict IOC without removing the factory method Logger.getLogger(). Moreover, we cannot just break backward compatibility of a class as central as Logger.
Of course, nothing prevents us from adding a getChildLogger(String name) to the Logger class. Would that be sufficient for your needs?
* 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.
With very little work, the log4j.jar can be as small as 140K or so. Removing appenders and other less used components is relatively easy. For log4j 1.3, we have separated lf5 and chainsaw so that the official log4j.jar file is around 230 Kb.
* All the log targets that LogKit has should be available in some form with Log4J (which I think is the case already).
Do you have any missing component in mind?
I really don't think these are all that demanding, and we would like to help in the process if possible.
Sounds good.
-- Ceki For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
In the USA the log4j manual is carried by Softpro books.
http://store.yahoo.com/softpro/2-9700369-0-8.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
