Hello Berin,
It really great to see your post. Answers in line.
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.
:) I think that is a good thing. I understand about backwards compatibility, and we don't want you to do that just because the way we did it was better ;P
Seriously, we have cruft in the Framework we can't get rid of because of back-compatibility issues.
I am thinking that the Log4J 2.0 will be point where the Avalon team can safely deprecate LogKit.
Of course, nothing prevents us from adding a getChildLogger(String name) to the Logger class. Would that be sufficient for your needs?
For the short term, sure. Right now, the Avalon wrapper for Log4J uses the following code snippet:
Logger getChildLogger(String subCat)
{
return new Log4JLogger(
Logger.getLogger(m_logger.getName() + "." + subCat));
}It's not pretty, but it works.
* 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.
That's definitely better.
* 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?
Not yet. I haven't looked at what is available and what is not.
For the quick rundown of Avalon LogKit log targets, we have:
File Memory JDBC JMS JavaMail Servlet Socket
As well as some file rotation strategies.
If Log4J already has all these then the last bullet point can be ignored.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
