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.
Stupid question time (especially since every else seems to know): What does IOC stand for?
[snip]
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.
What about creating a separate interface, e.g. ILogger that Logger can implement? Then Logger still exists as is for backwards compatibility and moving forward people could use ILogger. I'm not sure of the total impact of this on log4j but I imagine it is doable. The simple approach is to make ILogger contain every public method that Logger contains and then to replace Logger with ILogger throughout the log4j code wherever possible.
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
