On Dec 11, 2009, at 5:02 PM, Christian Grobmeier wrote: > Hi, > > That being said, I do not use closed source frameworks because of the > risk of vendor lock in. I use Apache software because I feel good with > it. Logback/SLF4J is open source but driven by a company with a > commercial interest in that software and I usually want to avoid a > link between me and such companies if possible (except I work for > them).
To be fair I have never heard Ceki push his company on any of the mailing lists. To be honest, I really have no idea what Ceki does to earn a living. I don't think he has ever mentioned it on the list. Once he did mention that a feature might be too large for him to do for free, but whatever it was I ended up fixing it myself. > >>> Oh the issue of developing log4j 2.0, my expectation is that it would >>> be largely incompatible with log4j 1.2. I would anticipate that the >>> api would either use SLF4J or, more likely, start from the existing >>> SLF4J code and modify to take advantage of Java 5+ features. The >>> internals of log4j need a large overhaul to fix locking issue by >>> taking advantage of java.util.concurrent and many of the features >>> present in logback need to be added. > > > SLF4J - sorry I don't know much about it. But from its website, its > again a QOS project and it seems to be a wrapper around various > logging APIs. Besides that I never had a benefit from encapsulating a > logging framework (I never switched from JDK logging to Log4J or vice > versa while developing a project) I wonder why you are referring to > this. Maybe I didn't get the point, but why can't we just refactor > Log4J and clean it up and include this locking issue and Java5 > features you mentioned? Separating the API from the actual implementation is very good practice - something I wish Sun had done a better job of with JUL. You will encounter this problem if you try to integrate Spring on JBoss with Apache Jackrabbit and various other frameworks. Some use Log4j directly. Some java.util.logging. Other use Apache Commons Logging and some newer applications use SLF4J. If you want all your logging to be managed by a single framework with a single configuration then you need something - SLF4J provides a nice bridge for all these. Plus, SLF4J has some very nice features that other frameworks don't have. > > I know, logging is critical, but hey, to write an ejb container like > the openejb guys did is much more difficult. Question is how much > features does a logging framework need. > > >> Looking at the bigger picture, the log4j community would render a big >> service to the java world by aligning itself with the SLF4J API >> because logging in java is in need of consolidation. However, the >> extent of the service is diminishing by the week as more and more >> projects migrate to SLF4J. By the time this is obvious to everyone, >> the exercise will become largely pointless and tragically so. > > Ceki, are you saying: "Log4J is dead and logback is the future. Give > up all development, SLF4J is stronger"? > SLF4J is an API, not a logging implementation. Logback is a more modern logging implementation and addresses many, but not all, of the issues Log4j still suffers from. It was time to start working on Log4j 2.0 18 months ago but it isn't a trivial project. Ralph
