On Sep 18, 2006, at 6:31 AM, Benoitx wrote:
Hi *,
I need some light shed on this... What should a user do nowadays?
- I have seen comments about slf4j, is it an "official" or
recommended way
to do things?
If you want to be able to select at configuration time between the
supported logging implementations (log4j, JDK 1.4 logging, et al), it
is a way to accomplish that. Jakarta Commons Logging (JCL) addresses
the same need. SLF4J was started to provide an alternative to JCL to
address some problems due to JCL attempting to select the
implementation depending on what classes were available on the
classpath (see http://www.qos.ch/logging/thinkAgain.jsp) and concerns
that the Apache License was considered too restrictive (SLF4J is an
X11 license). The logging API's in JCL and SLF4J are similar to
log4j both log4j-like but with different package names. So switching
most log statements from one to another can be done just by changing
package names.
If you are looking for "officialness" in a logging API, then the
javax.util.logging classes (aka JSR-47 or JDK 1.4 logging) would seem
to have that wrapped up.
Will the Apache Log4J "comply" to the facade or at least work
with the writers of slf4j?
SLF4J.org provides an implementation of the SLF4J interfaces that
delegates to log4j like it provides an implementation that delegates
to JDK 1.4 logging. Given the license and code maturity
considerations, having SLF4J provide a wrapper for log4j is
preferable in my opinion than having log4j depend on SLF4J.
- release 1.3 promises a lot of goodies, should I wait? or use an
existing
alternative?
Sorry, not enough information to even start making that decision for
you. You would need to know what JDK that you are targeting (JDK 1.4
logging might not be a candidate if you wanted to run on JDK 1.3, for
example), feature needs, licensing concerns, and process concerns.
- LogBack claims to be a candidate replacement for Log4J and
although I
agree that Log4J needs to evolve (jdk 5 features please), I am very
worried
about a split or yet another way to do things. I am not willing to
risk my
systems with an untested logging mechanism but I shall keep my eyes
open. I
do not know the issue(s) behind what looks like the split from
Log4J by
Cedik but this both brings weight and extra risk to LogBack (lack of
traction, dependency on one or little more individuals)
Ceki is a Logging Services PMC member and log4j committer. However,
since the recalled log4j 1.2.10 release, he has limited his
participation in the log4j community to participating in the mailing
lists and has spent his efforts on the SLF4J, NLOG4J and logback
projects. If you search the log4j-dev archives for 1.2.10, you
should get an understanding of what has led to the current state.
I have seen a recent roadmap but we need some more precise
deadlines...
By the way the links to javadoc on the website are both the same
for 1.2.13
and 1.3-alph8, this is not correct:
http://logging.apache.org/log4j/docs/documentation.html
It has been reported as a bug and I expect to fix it when the site is
updated for log4j 1.2.14.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
