You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2006/07/27 18:57:32 UTC
T5: getting away from 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?
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Jesse Kuhnert <jk...@gmail.com>.
Only out of curiosity, since T5 has so many options library-wise, what's
wrong with the built in jdk logging facilities? (This isn't me saying I
think it's better, I've hardly used the jdk logging facilities at all)
On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
RE: T5: getting away from commons-logging
Posted by James Carman <ja...@carmanconsulting.com>.
Yeah, that was mentioned in the original email.
_____
From: Paul Ferraro [mailto:pmf8@columbia.edu]
Sent: Friday, July 28, 2006 9:45 AM
To: Tapestry development
Subject: Re: T5: getting away from commons-logging
Has anyone considered SLF4J?
http://slf4j.org
Paul
On Fri, 2006-07-28 at 10:21 +0200, Massimo Lusetti wrote:
On 7/28/06, Henri Dupre <he...@gmail.com> wrote:
> On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > 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.
>
>
> I think they solved this issue in their latest version. And given how
> used this project is, I'm sure they will fix the remaining issues.
> Btw, I have not seen any memory leaks with commons-logging that far.
Just do a quick search over googlandia to find out a lot of nesty
things around it.
Re: T5: getting away from commons-logging
Posted by Paul Ferraro <pm...@columbia.edu>.
Has anyone considered SLF4J?
http://slf4j.org
Paul
On Fri, 2006-07-28 at 10:21 +0200, Massimo Lusetti wrote:
> On 7/28/06, Henri Dupre <he...@gmail.com> wrote:
>
> > On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > >
> > > 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.
> >
> >
> > I think they solved this issue in their latest version. And given how
> > used this project is, I'm sure they will fix the remaining issues.
> > Btw, I have not seen any memory leaks with commons-logging that far.
>
> Just do a quick search over googlandia to find out a lot of nesty
> things around it.
>
Re: T5: getting away from commons-logging
Posted by Henri Dupre <he...@gmail.com>.
On 7/28/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> The memory leak issue is well-known and somewhat well-documented:
>
> http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
Yes and this is more an underlying class loader issue rather than specific
to commons logging. I agree with James, it would be better to handle the
release of resources in a WebRequestServiceFilter otherwise, there would
still be space for some classloading issues there, no matter what framework
is used.
--
Henri Dupre
Actualis Center
Re: T5: getting away from commons-logging
Posted by Henri Dupre <he...@gmail.com>.
On 7/29/06, devel - Fashion Content <de...@fashioncontent.com> wrote:
>
> I find memory leaks to be a complete showstopper. I like to do a lot of
> iterative modifications on a test webserver.
> My current setup lasts about 5-10 redeploys before Tomcat runs out of
> memory.
> It makes the whole thing look very fragile.
There are many factors that can contribute to memory leaks. I recently found
that on our main server, there are no leaks on redeployment!
Even the permgen space stays ok.
With a proper configuration, it is possible to prevent most memleaks issues.
There are none that I'm aware of in T4 + tomcat (I did quite a bit of heap
analysis).
If the framework has thread safety issues, is that something that can be
> fixed by patching it ?
The root of all of that are classloading issues with webapps but this is
well documented with commons logging and all the tapestry devs seem to know
that stuff well.
Henrik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Henri Dupre
Actualis Center
Re: T5: getting away from commons-logging
Posted by devel - Fashion Content <de...@fashioncontent.com>.
I find memory leaks to be a complete showstopper. I like to do a lot of
iterative modifications on a test webserver.
My current setup lasts about 5-10 redeploys before Tomcat runs out of
memory.
It makes the whole thing look very fragile.
If the framework has thread safety issues, is that something that can be
fixed by patching it ?
Henrik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: T5: getting away from commons-logging
Posted by James Carman <ja...@carmanconsulting.com>.
The memory leak issue is well-known and somewhat well-documented:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
-----Original Message-----
From: Massimo Lusetti [mailto:mlusetti@gmail.com]
Sent: Friday, July 28, 2006 4:22 AM
To: Tapestry development
Subject: Re: T5: getting away from commons-logging
On 7/28/06, Henri Dupre <he...@gmail.com> wrote:
> On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > 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.
>
>
> I think they solved this issue in their latest version. And given how
> used this project is, I'm sure they will fix the remaining issues.
> Btw, I have not seen any memory leaks with commons-logging that far.
Just do a quick search over googlandia to find out a lot of nesty
things around it.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: T5: getting away from commons-logging
Posted by James Carman <ja...@carmanconsulting.com>.
Maybe the option is to use a WebRequestServicerFilter or something to call:
LogFactory.release(Thread.currentThread().getContextClassLoader());
after the request is finished?
-----Original Message-----
From: Massimo Lusetti [mailto:mlusetti@gmail.com]
Sent: Friday, July 28, 2006 4:22 AM
To: Tapestry development
Subject: Re: T5: getting away from commons-logging
On 7/28/06, Henri Dupre <he...@gmail.com> wrote:
> On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > 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.
>
>
> I think they solved this issue in their latest version. And given how
> used this project is, I'm sure they will fix the remaining issues.
> Btw, I have not seen any memory leaks with commons-logging that far.
Just do a quick search over googlandia to find out a lot of nesty
things around it.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Massimo Lusetti <ml...@gmail.com>.
On 7/28/06, Henri Dupre <he...@gmail.com> wrote:
> On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > 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.
>
>
> I think they solved this issue in their latest version. And given how
> used this project is, I'm sure they will fix the remaining issues.
> Btw, I have not seen any memory leaks with commons-logging that far.
Just do a quick search over googlandia to find out a lot of nesty
things around it.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Henri Dupre <he...@gmail.com>.
On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> 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.
I think they solved this issue in their latest version. And given how
used this project is, I'm sure they will fix the remaining issues.
Btw, I have not seen any memory leaks with commons-logging that far.
Henri.
Re: T5: getting away from commons-logging
Posted by Henri Yandell <fl...@gmail.com>.
+1. This is an email I keep meaning to send to Commons - should
Commons components that are 1.4+ depend on commons-logging.
Hen
On 7/27/06, D&J Gredler <dj...@gmail.com> wrote:
> I like that slf4j fixes jcl classloading issues, and that the
> parametrization of the logging methods allows you to remove that extra call
> to isXxxEnabled().
> But what about JDK logging, since Tap5 is targetted at Java 5+? I keep
> waiting for the need for logging facades to go away, and it nevery happens
> :-)
>
> On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Rahul Akolkar <ra...@gmail.com>.
Oh, and James started a related thread [1] on commons-dev that might
be of interest here. IMO, the best place to separate specific JCL FUD
items from facts, is probably that list.
-Rahul
[1] http://marc.theaimsgroup.com/?t=115408845000001&r=1&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/31/06, Kevin Menard <km...@servprise.com> wrote:
> > -----Original Message-----
> > From: D&J Gredler [mailto:djgredler@gmail.com]
> > Sent: Thursday, July 27, 2006 2:07 PM
> > To: Tapestry development
> > Subject: Re: T5: getting away from commons-logging
>
>
> > But what about JDK logging, since Tap5 is targetted at Java 5+? I keep
> > waiting for the need for logging facades to go away, and it nevery happens
> > :-)
>
> I agree. Alternatively, just use log4j. I've yet to talk to anyone that
> said "yeah, we really liked this logging framework, but midway through, we
> fell in love with another -- thank god we had an abstraction library!" It's
> just one of those things that doesn't happen.
>
<snip/>
Thats a fair observation for an individual application, but doesn't
scale to a framework.
-Rahul
> --
> Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Henri Dupre <he...@gmail.com>.
On 7/31/06, Kevin Menard <km...@servprise.com> wrote:
>
> > -----Original Message-----
> > From: D&J Gredler [mailto:djgredler@gmail.com]
> > Sent: Thursday, July 27, 2006 2:07 PM
> > To: Tapestry development
> > Subject: Re: T5: getting away from commons-logging
>
>
> > But what about JDK logging, since Tap5 is targetted at Java 5+? I keep
> > waiting for the need for logging facades to go away, and it nevery
> happens
> > :-)
>
> I agree. Alternatively, just use log4j. I've yet to talk to anyone that
> said "yeah, we really liked this logging framework, but midway through, we
> fell in love with another -- thank god we had an abstraction
> library!" It's
> just one of those things that doesn't happen.
I thought the same until I had a look at several serlet containers...
Each container has their favorite logging framework and have more support
for it than.
For instance if you want to use glassfish, you would really want to rely on
jdk's logging because they have nice guis and alert mecanisms for it. But
with tomcat and jboss, log4j seems a better solution.
--
Henri Dupre
Actualis Center
RE: T5: getting away from commons-logging
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: D&J Gredler [mailto:djgredler@gmail.com]
> Sent: Thursday, July 27, 2006 2:07 PM
> To: Tapestry development
> Subject: Re: T5: getting away from commons-logging
> But what about JDK logging, since Tap5 is targetted at Java 5+? I keep
> waiting for the need for logging facades to go away, and it nevery happens
> :-)
I agree. Alternatively, just use log4j. I've yet to talk to anyone that
said "yeah, we really liked this logging framework, but midway through, we
fell in love with another -- thank god we had an abstraction library!" It's
just one of those things that doesn't happen.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by D&J Gredler <dj...@gmail.com>.
I like that slf4j fixes jcl classloading issues, and that the
parametrization of the logging methods allows you to remove that extra call
to isXxxEnabled().
But what about JDK logging, since Tap5 is targetted at Java 5+? I keep
waiting for the need for logging facades to go away, and it nevery happens
:-)
On 7/27/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: T5: getting away from commons-logging
Posted by Norbert Sándor <de...@erinors.com>.
I just wanted to recommend switching to /SLF4J/ after looking at the
sources (for the first time :) ). It is sometimes hard to live with
/commons-logging/...
(Although I haven't used it before "seriously", the /logback /framework
seems to be a very good and well documented logger implementation. It
supports /SLF4J /natively resulting in better logging performance for
example.)
Regards:
Norbi
Massimo Lusetti írta:
> On 7/1/07, Howard Lewis Ship <hl...@gmail.com> 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.
>
> For me the SL4J and JDK logging are both fine, i've gone through a
> test with SL4J and the current trunk and it has been easy to switch to
> it, some test (one in ioc) fails but i think it's workable.
>
> Plus using jcl12-over...jar from SL4J let you switch without changing
> a line of java code which seems and easy first step to give it a try.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Massimo Lusetti <ml...@gmail.com>.
On 7/1/07, Howard Lewis Ship <hl...@gmail.com> 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.
For me the SL4J and JDK logging are both fine, i've gone through a
test with SL4J and the current trunk and it has been easy to switch to
it, some test (one in ioc) fails but i think it's workable.
Plus using jcl12-over...jar from SL4J let you switch without changing
a line of java code which seems and easy first step to give it a try.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Fwd: T5: getting away from commons-logging
Posted by Paul Ferraro <pm...@columbia.edu>.
I vote for SLF4J.
I've had many frustrating times with commons-logging class loading
issues - although apparently they've tweaked the auto-discovery
mechanism in 1.1.0. I dislike the idea of using JDK logging because I
hate it when an an application framework or utility library imposes a
logging implementation on me.
The biggest hurdle, IMO, to SLF4J adoption is education users on how to
use it. I've answered many support requests where users included all
slf4j impl jars in their classpath instead of just one because they
didn't follow instructions!
Paul
On Sun, 2007-07-01 at 10:49 -0700, Howard Lewis Ship 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 <hl...@gmail.com>
> Date: Jul 27, 2006 9:57 AM
> Subject: T5: getting away from commons-logging
> To: Tapestry development <de...@tapestry.apache.org>
>
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Howard Lewis Ship <hl...@gmail.com>.
Everything old is new again :-)
On 7/4/07, Lars Kühne <lk...@users.sourceforge.net> wrote:
> On 7/3/07, Howard Lewis Ship wrote:
> > > 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.
>
> Indeed, and this has been the rationale behind the Logger/LogEnabled
> abstraction in Apache Avalon.
>
> http://excalibur.apache.org/apidocs/org/apache/avalon/framework/logger/Logger.html
>
> if you look at that API you'll also see a method getChildLogger.
> Basically it takes the logger injection thought a bit further,
> allowing an Avalon component (or "service" in tap5 speak) to further
> subdivide the logger hierarchy internally. This is cool, because I can
> selectively turn on debug logging for one particular logical subsystem
> of a service.
>
> Now I know that Avalon is not that 'hot' any more, and a better API
> could be designed width Java5 and varargs, but the general idea is
> pretty nice.
>
> Lars
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Lars Kühne <lk...@users.sourceforge.net>.
On 7/3/07, Howard Lewis Ship wrote:
> > 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.
Indeed, and this has been the rationale behind the Logger/LogEnabled
abstraction in Apache Avalon.
http://excalibur.apache.org/apidocs/org/apache/avalon/framework/logger/Logger.html
if you look at that API you'll also see a method getChildLogger.
Basically it takes the logger injection thought a bit further,
allowing an Avalon component (or "service" in tap5 speak) to further
subdivide the logger hierarchy internally. This is cool, because I can
selectively turn on debug logging for one particular logical subsystem
of a service.
Now I know that Avalon is not that 'hot' any more, and a better API
could be designed width Java5 and varargs, but the general idea is
pretty nice.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: getting away from commons-logging
Posted by Howard Lewis Ship <hl...@gmail.com>.
On 7/2/07, Henri Dupre <he...@gmail.com> 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 <hl...@gmail.com> 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 <hl...@gmail.com>
> > Date: Jul 27, 2006 9:57 AM
> > Subject: T5: getting away from commons-logging
> > To: Tapestry development <de...@tapestry.apache.org>
> >
> >
> > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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
Re: T5: getting away from commons-logging
Posted by Henri Dupre <he...@gmail.com>.
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.
And why would you inject loggers? Isn't each class supposed to declare its
own logger?
On 7/1/07, Howard Lewis Ship <hl...@gmail.com> 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 <hl...@gmail.com>
> Date: Jul 27, 2006 9:57 AM
> Subject: T5: getting away from commons-logging
> To: Tapestry development <de...@tapestry.apache.org>
>
>
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Henri Dupre
Actualis Center
Fwd: T5: getting away from commons-logging
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <hl...@gmail.com>
Date: Jul 27, 2006 9:57 AM
Subject: T5: getting away from commons-logging
To: Tapestry development <de...@tapestry.apache.org>
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org