Es begab sich aber da Herko ter Horst zur rechten Zeit 20.02.2007 14:46
It is thin, but its not as easy to use as java logging.
This gives us some relief but the problem remains that it depends on the
servlet container whether logging will behave as expected or not.
Not just servlet containers, any managed container that needs to keep
code from one classloader isolated from other code (e.g. OSGi
containers) will run into the same issue.
This LogManager issue is one of the issues that I believe will keep
other logging frameworks alive, even with a standard logging framework
available in Java SE.
In addition, the huge current installed base of other logging frameworks
(most notably log4j) makes it important to consider the use of Aperture
within applications that use different logging frameworks. IMO, a thin,
easy-to-use abstraction that specifically avoids classloading issues
gives Aperture users the necessary freedom to choose their own logging
implementation based on their specific needs.
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
Then, you have to manage two additional configuration file formats -
SLF4J and the underlying logger framework.
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
This guy suggests to only use non-standard loggers if you need their
features. I don't see that we need these features.
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.
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?
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.
Still, if aduna insists on using SLF4J because of customer demands, I
agree to switch to it.
Herko ter Horst
Senior Software Engineer
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