I had an encouraging chat with the Log4J folks (Ceki in particular), and we have some good news from the logger front. We all knew that Log4J surpasses LogKit in the feature list. We also know that LogKit does its job well for only 25% of the weight. We also know that Log4J is not currently friendly to IOC with the Logger.getLogger() call.
When I introduced these concerns, it appears that they are all addressable, and actually being addressed. They are working hard on Log4J 1.3 which will address the issues of one 345 KB JAR, and the new JAR will weigh in at 210 KB--not 25% the size, but a step in the right direction. The remaining 135 KB+ will be separated out into two utility JARs that will add the extra functionality that some folks will need, but not everybody.
They also expressed willingness to include the getChildLogger() method that we have in LogKit.
The only thing that Log4J 1.3 cannot address is the factory method (Logger.getLogger()) due to compatibility issues. At the same time, Log4J 2.0 will address this issue. In fact Logger will not be a class, but an interface.
I believe the best course of action is to continue to support LogKit until Log4J 2.0 is released. However, in the mean time we should start putting together stronger support for Log4J in the Avalon containers. Many of our users will most likely be more willing to work with Log4J, and it will be one less issue to worry about.
I would also like us to help make Log4J 2.0 a reality. If there are any volunteers who want to help in that direction, please subscribe to the Log4J list.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
