commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject [logging] Tapestry and JCL
Date Fri, 28 Jul 2006 12:06:00 GMT
Tapestry is thinking of switching to SL4J instead of Jakarta Commons
Logging:

"A pretty common complaint is that commons-logging is a problem. It does
some wierd and awkward class loading things that ultimately result in memory
leaks.

An alternative is SL4J:

http://www.slf4j.org/

It has an improved API over commons-logging, making it easier to build out
complex messages.

It's basic claim to fame is that it is statically bound. There are different
implementations of the framework for different toolkits. We could bind to
the log4j version for testing and building, and users will bind to a
specific version for deployment.

It is under the X11 license (compatible with the ASL).

The only problem is that the code is not quite threadsafe, something I can
address inside Tapestry 5 code.

Thoughts?"

I have sent them the link to the memory leak WIKI page and suggested adding
in a web filter that releases the resources for the current thread's context
classloader (as prescribed by the WIKI).  Does anyone else have any
suggestions on what could/should be done?  I would really hate to see an
Apache TLP, java-based project switch off JCL in favor of a non-ASF logging
API.





---------------------------------------------------------------------
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