commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject RE: [logging] Tapestry and JCL
Date Sat, 29 Jul 2006 22:19:42 GMT
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:scolebourne@btopenworld.com] 
> Sent: Friday, July 28, 2006 9:44 AM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] Tapestry and JCL
> 
> From: James Carman <james@carmanconsulting.com>
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message