On Dec 11, 2009, at 2:24 PM, Ceki Gülcü wrote: > Ralph Goers wrote: > > > This is actually my biggest issue with Logback (and SLF4J). I've been > > thinking recently of starting work on Log4j 2.0 simply because I do > > not like the "community" model of Logback. This is no criticism of you > > - it should go without saying that you are extremely talented. But > > there have been times when you have been on vacation and nothing can > > happen. Plus having to get your approval for everything is extremely > > frustrating. So although there are at least 5 active participants, of > > which I am one, we are not necessarily happy or satisfied > > participants. > > Point well taken. Admittedly, I can be a bottleneck. Nevertheless, the > ASF model where there is no official leader has issues of its own. Do > you think you'd have less trouble getting the RFC 5424 idea pushed > through quickly at log4j-...@? As I said in another occasion, the > RFC 5424 idea is good, except that it's seems like a big step and I > need some time to digest it. Don't lose hope just yet.
In all the various projects I have committed to at Apache I have found that the ASF model works very well, especially as the number of committers grows. I can't speak to what went on at Log4j years ago, although I do understand that not breaking compatibility played some part in the issues. I can understand that since logging is such a critical component. It is somewhat ironic that one of the issues facing SLF4J today is that compatibility will be broken in moving to support Java 5+. Although I know you prefer the "benevolent dictator" model, I am quite certain Logback would be even more widely used if it was Log4j 2.0. I still get queries from engineers about "what the heck is logback and why don't we use Log4j". Even though the current Log4j code is seriously outdated, the brand name is incredibly strong. I don't pretend to believe that if SLF4J and Logback were ASF projects that the code I wrote for RFC 5424 would have been adopted as is. More than likely I would have committed it to a branch where some collaboration could take place before merging to trunk. With SLF4J/Logback all I can really do is create a fork and hope something happens. Yes, you eventually do look at submissions but it isn't really collaborative development. I commit to several Apache projects. What is different between the ASF and QOS.ch projects is that at the ASF the group determines what happens and how, not a single individual. I can start committing to Log4j 2.0 right now. Other people can dialogue about what I am doing and then recommend changes or make them themselves. Nothing is in the hands of a single individual. Yes, this does occasionally have drawbacks, but I believe it leads to a much stronger community. Chris Davis has given a talk at several ApacheCons - Great Code comes from Great Community - where he mentions the benevolent dictatorship model. The slides are at http://www.viddler.com/explore/chrisjdavis/videos/25/. > > > 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. > > 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. > I see no point in having Log4j 2.0 adhere to the SLF4J 1.x API. As has been discussed on the SLF4J list, it is time to start work on upgrading to Java 5 (or 6). In the API I would like to take advantage of both generics and annotations where appropriate. To be honest, simply because of the way the communities work I'd prefer to do that work as part of a Log4j 2.0 Facade (or API) subproject. Ralph
