Es begab sich aber da Herko ter Horst zur rechten Zeit 20.02.2007 14:46 folgendes schrieb:
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.
  
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.

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 their choice.

This guy suggests to only use non-standard loggers if you need their features. I don't see that we need these features.
http://java.sys-con.com/read/48541_2.htm

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.

best
Leo



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:  leo.sauermann@dfki.de

Geschaeftsfuehrung:
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
____________________________________________________