I've been strongly thinking about this again; probably the last chance
to do so while T5 is still in alpha.

It really comes down to:

- Leave status quo / commons-logging
- Adopt SL4J
- Adopt JDK logging

The big area this affects is the way a Log can be injected into a
service; the interface injected, etc., may change.

---------- Forwarded message ----------
From: Howard Lewis Ship <[EMAIL PROTECTED]>
Date: Jul 27, 2006 9:57 AM
Subject: T5: getting away from commons-logging
To: Tapestry development <[email protected]>


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?

--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com


--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to