Hi, >> 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. >> ... >> 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. I don't want to start a philosophical debate about Leadership vs Community models. However, I don't want a leader by position, I want to be lead by a community (and sometimes lead myself). As what I can say in the time I was working as contributor and committer to Apache, I was never disappointed or anything. I have learned much and like the model as it is. I am sure that drawbacks will be removed with time, that has already been proven. I also saw projects made quick decisions. It's not necessary that things stay forever. It all depends on the people working on a project. At least, Apache Geronimo, Camel, Cocoon, OpenEJB and other really huge projects proved that this model works - otherwise that unbelievable great pieces of Software would never have come into existent. I simply can't believe that such a small API like a logging framework cannot run with this model. I cannot accept that an API like Log4J needs a leader to become great. 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). >> 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? 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"? Best regards, Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
