Hi all,

Es begab sich aber da Herko ter Horst zur rechten Zeit 22.02.2007 22:28 folgendes schrieb:
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. 
they all drill down to something like this, I don't see much ways to make it any easier:
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

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.

I meant, you can now screw up the SLF4J configuraiton file (= configuring which real framework to use)
and the configuration file of the actual logging framework.
= 2 file formats, 2 points of failure.

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.
If you have the problem of not using Java Logging,
you can forward JAva logging to XYZ.
If SLF4J makes this easier, its good for those people who don't use Java logging,
they can then forward messages generated by Java Logging to XYZ.,
for java-logging based architectures, nothing is needed.
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*.

That is surely true, but all these question only come up for people who have needs *beyond* java logging.
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.....

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.
Still, if we start a NEW framework, from scratch, like Aperture,
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.
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.
Yes, that would make it easier for these to use the logging framework of choice.
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 of it,
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:  leo.sauermann@dfki.de

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