Es begab sich aber da Herko ter Horst zur rechten Zeit 22.02.2007 22:28
they all drill down to something like this, I don't see much ways to
make it any easier:
It is thin, but its not as easy to use as java logging.
You have to read additional documentation, developers need more
training, and you have two problems and two points of failure when using
it, first SLF4J can fail and then the underlying framework can fail.
From a coding point of view, I think SLF4J is actually easier to use
than Java logging.
Log log = ....getLogger(...);
Of course, if all you have ever used before is Java
logging, then yes, this is an additional thing to learn, but it's really
simple (it's called Simple Logging Framework 4 Java for a reason), not
in the least because the concepts are pretty much the same across all
As far as reliability goes: because SLF4J doesn't actually do the
decision-making, formatting or actual logging, the chances of anything
going seriously wrong within the SLF4J framework are very small. All it
does is accept logging calls and forward them to the actual logging
sure, SLF4J can break and the underlying framework
I meant, you can now screw up the SLF4J configuraiton file (=
configuring which real framework to use)
Then, you have to manage two additional configuration file formats -
SLF4J and the underlying logger framework.
Not true, because SLF4J is *only the interface* to program to. The
actual framework implementation controls what type of configuration is
needed, so you can keep using your existing Java Logging or log4j
configuration without change.
and the configuration file of the actual logging framework.
= 2 file formats, 2 points of failure.
If you have the problem of not using Java Logging,
If people use alternate logging implementations as default logging for
their applications, then they can use some forwarding mechanism to catch
the java logger messages and forward them to the log-framework of their
All these forwarding mechanisms are exactly what SLF4J already provides.
JUL, log4j, Apache Commons Logging are all supported out of the box.
you can forward JAva logging to XYZ.
If SLF4J makes this easier, its good for those people who don't use
they can then forward messages generated by Java Logging to XYZ.,
for java-logging based architectures, nothing is needed.
That is surely true, but all these question only come up for people who
have needs *beyond* java logging.
This guy suggests to only use non-standard loggers if you need their
features. I don't see that we need these features.
SLF4J isn't an alternative for Java Logging or Log4J in the way
described in that article. As such it doesn't have "more" or "better"
features. For example, SLF4J doesn't have handlers, formatters or
whatever. All it does is provide the *library* programmer with an
interface to program too. The actually logging is done by whatever
logging implementation is selected for the end-user *application*.
The point is not what SLF4J does or does not, its that
* in 90% of all cases, Java logging is enough
* if not, you can forward messages generated by Java logging to XYZ to
have more features.
in 10% of the cases, you can then use SLF4J/Log4j etc.....
Still, if we start a NEW framework, from scratch, like Aperture,
I see that using a non-standard logger + abstraction layer always cries
for having two additional jars in your code, two jars that are unneeded.
Again, all non-standard logger frameworks are pre-2002, we have 2007 now.
SLF4J was started in 2005 because it was obvious at that time that
multiple logging implementations were available which would continue to
be used for a long time to come. For example, log4j isn't going away
anytime soon. It has a huge installed base and I imagine that most of
those applications will continue to use log4j for new versions.
we don't have to care for all these legacy things.
If you want to use aperture in a legacy logging environment, forward
JUL to the framework you use.
Yes, that would make it easier for these to use the logging framework
Also, logging isn't that mysterious rocket science, and java.logging is
ok enough for most applications, why think about this stuff and waste
endless time to choose the "right" logging framework if SUN provides one
that works for 90% of all cases pretty well?
The problem is that we don't control "most applications". Most
applications are written by others and they will select the logging
implementation of their preference. Being able to use the Aperture
libraries in any application, regardless of the logging implementation
it uses seems like a big plus to me.
So if you want to keep using JUL in your applications based on Aperture,
that's fine, no problem at all. If at Aduna we want to start using log4j
for our web-based products because we don't want to rely on the servlet
container to solve the LogManager problem for us, that's fine too. If
<insert random Apache project here> wants to keep using Apache Commons
Logging for their application, but still be able to integrate Aperture,
that will work as well.
If its just the nerdy discussion "which logging framework has better
features, mine is better than yours", I would definitly go for jul. JUL
was created as a copy/paste of all the other framworks that were out
there before 2002, it is a JSR, its the right descision.
It's not a discussion of better or more features, it's a discussion of
forcing a logging *implementation* on users of the library because we
selected a particular logging *API*. SLF4J allows you to select the
logging implementation at *deployment* time just by dropping in the
correct jar file.
ok, I was not on this situation before,
so I trust you guys learned from your Sesame experience that you are
sure that this is a problem enough
and that you had this problem appear in the past and lost money because
otherwise it wouldn't be so important for you, or?
if it can't be done with JUL, we have to go with SLF4J.... so be it :-)
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Aperture-devel mailing list
DI Leo Sauermann http://www.dfki.de/~sauermann
Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080 Fon: +49 631 20575-116
D-67663 Kaiserslautern Fax: +49 631 20575-102
Germany Mail: email@example.com
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313