From: Leo S. <leo...@df...> - 2007-02-22 16:39:20
|
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...@df... 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 ____________________________________________________ |