I think projects should use the best tool for the job (as long as its license is ASL compatible). Apache doesn't have a monopoly on good ideas. If the Tapestry developers really feel SLF4J is better, then that's their choice and all power to them.
Although I contribute patches to JCL, I'm certainly not claiming it is perfect - or even terribly good. Having said that, the 1.1 release of JCL is expected to resolve the vast majority of problems previously experienced by users; it now does its best to avoid throwing exceptions even when this means that output may not be generated, or not generated in the expected way. However JCL is definitely hampered by its history, and is now quite a complex beast. That means a greater risk of bugs/issues of course. A new 2.x version really is needed to get rid of all the old cruft but working on commons-logging is not glamorous or terribly rewarding so this may be a while off yet. SLF4J is a good project. It does have some differences from commons-logging. They are: * if using parent-first classloading, and SLF4J is in an ancestor classpath then there is no way for a webapp to configure its own logging library. And if that library doesn't internally support per-webapp configuration, then logging *config* is global across all webapps. This is a direct consequence of the decision in SLF4J not to use classloader "tricks". Thus SLF4J is more predictable but less flexible. * SLF4J is far less widely used. Many of the issues with JCL only became known as it was used in various containers with weird classloading approaches. SLF4J's simplicity means that it is *less* likely to strike problems that JCL did, but then again there are some truly odd situations out there (that we worked through while creating the 1.1 JCL release). * I'm personally unconvinced by its approach to i18n. Of course JCL doesn't try to support i18n in its api at all, but I would suggest thinking carefully before using the i18n methods in SLF4J. There are some other options. I believe tomcat 6.x currently includes a statically-bound implementation of the JCL API (probably bound to JULI, which is a java.util.logging implementation). I think SLF4J even offers an implementation of the JCL api that maps to SLF4J adapters. Regards, Simon On Fri, 2006-07-28 at 10:14 -0400, James Carman wrote: > Regardless, it's still not an ASF project. We should try to "eat our own > dog food" IMHO. If we don't use our own libraries because we think they're > sub-par, then why should anyone else? > > -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Friday, July 28, 2006 9:44 AM > To: Jakarta Commons Developers List > Subject: Re: [logging] Tapestry and JCL > > From: James Carman <[EMAIL PROTECTED]> > > Thoughts?" > > I would really hate to see an > > Apache TLP, java-based project switch off JCL in favor of a non-ASF > > logging API. > > Unless I'm mistaken, SLF4J comes from Ceki, creator of Log4J. Thus the SLF4J > website and separation is as much for political reasons as anything else. > (ie, if it was release as part of Log4J, people wouldn't see it as truly > independent of Log4J) > > Stephen > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
