On 12.12.09 05:48, Ralph Goers wrote: >>>> 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 agree 100%. >> 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. It's not so much about the features but about being able to get *all* logging to one central point, e.g. a log file. Due to the nature of logging calls to loggers are spread over the whole codebase, something the aspect-OP community refers to as a cross-cutting-concern. Because of this, a breaking change in a log system leads to serious havoc and must therefore be a) optional and b) as minimal as possible from the perspective of the person that decides to "take the plunge". It must also provide a significant additional value to that users, otherwise the effort of transition isn't worth it. We've been discussing such a change at http://bugzilla.slf4j.org/show_bug.cgi?id=31 for >3 years and this is IMO the right way to do it Adding varargs to SLF4J is, on the other hand, absolutely overdue. Doing it the right way has the potential to deliver a much-needed death-stab to java.util.logging, the worst framework of all. (See http://stackoverflow.com/questions/607863/do-you-find-java-util-logging-sufficient/958211#958211 ) >>> 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. I think that any work put into Log4J 2.0 involves a heavy risk of actually wasting time, simply duplicating an effort that has already been done in Logback. I, personally, would *never* use it directly (i.e. without an facade) and nobody influenced by me would do it, either. I've switched from Log4J to commons.logging to SLF4J in the past and I'm not to keen to repeat an effort like this (see b) above). I refrain from log4j.NDC even though I could really, really use it very well in my projects, simply because SLF4J does not support it. I haven't used log4j.MDC while using commons.logging, too, for the very same reasons: being able to switch the logging backend at will. NDC is, for me, the biggest omission from SLF4J. Beside varargs, obviously. Regards, Joern. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
