On 7/2/07, Henri Dupre <[EMAIL PROTECTED]> wrote:
Out of curiosity, what is wrong with commons-logging 1.1? SL4J lists a document from 2005 about classloading issues wich have been solved to my knowledge.
It's still too confusing to configure CL, and I frequently end up with conflicts against app servers who include CL on the classpath. And why would you inject loggers? Isn't each class supposed to declare its
own logger?
That's a very limited view of a logger, that it's connected to the class. Not very component thinking. Logging, especially the allocation of loggers, is a concern that should be seperate from the class. Frequently in Tapestry the same class will be configured differently for use as different services; each of those should have a unique logger. Further, the same logger is used to log the creation of a service and it's proxies/dependencies as is used at runtime, this gives you the ability to trace the full lifecycle of a particular service, rather than a class. On 7/1/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> > 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] > > -- Henri Dupre Actualis Center
-- 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
