On 13/02/2010 5:59 AM, Curt Arnold wrote: > I believe the thread that you are thinking about is > http://marc.info/?l=log4j-dev&m=122841935827332&w=2.
I was indeed thinking of the message you referenced above. > You were arguing that log4j 1.2 should make a significant API change > (changing Logger.info(Object) to Logger.info(String) et al) to enable > convergence to a logging standard (SLF4J). My statement was to the > effect that the API standardization war was won by java.util.logging > and isn't going to be deprecated in favor of SLF4J if only log4j would > change its API to align with SLF4J. It is possible to have log4j adopt the SLF4J without breaking compatibility with existing client code. As I outlined in LOG4J2-27 on 5th of December 2008, we could alter the org.apache.log4j.Category class to keep the same signatures but have the method implemenations delegate to org.apache.log4j.impl.Logger. The org.apache.log4j.impl.Logger class would implement the org.slf4j.Logger interface. As I explained then, clients wishing to use the existing log4j classes and API could continue to do so. Those wishing to standardize on the SLF4J API could do so as well. The API standardization question has certainly not been won by java.util.logging. I find it troubling that you as the chair of the Apache Logging PMC should make a statement to the contrary, but maybe that's just me, the founder of the log4j project. > I do believe that incremental fixes and enhancements to log4j 1.2 are > worthwhile for the established community. While I'm not making as > many commits as I would like, I'm making a whole lot more than someone > who wants log4j to vegetate and die. Due to the large number of > implementation details exposed in the classes, it is very difficult to > make substantial changes to log4j 1.2 without compatibility issues. It boils down to the vision you have of the log4j project. As I see it, j.u.l. is beyond redemption. More importantly, the java platform is in need of consolidation with respect to logging. The current situation is way too confusing for users. SLF4J is making strides in this regard and is on its way in establishing itself as a de facto standard. If log4j adopted SLF4J as its core interface, it would go a long way in solving the logging consolidation issue. You have previously stated that log4j endorsing SLF4J would boost the SLF4J project without tangible gains for log4j. I, in contrast, believe that having a common vision for log4j would benefit the log4j project as well. Also keep in mind that one of the main selling points of logback is it is a native implementation of the SLF4J API. Log4j's adoption of SLF4J would reduce the relevance of that particular competitive advantage logback has over log4j. Anyway, to keep a long story short, you had over 5 years to impart your vision of log4j, now it is high time to put your seat as PMC-chair up for elections. You might get re-elected in which case things would probably continue as they are, or another candidate might be elected who could set a new direction for the log4j project. -- Ceki --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
