Hi Mark! Exactly the classloader problem is what we try to solve in log4j-2.0. Tomcat is by far not the only project which suffers a lot from this shortcoming. OpenWebBeans, MyFaces, OpenJPA, etc - all projects which are usually in a shared classpath have the problem that they cannot cleanly use static Loggers in their classes. Plus jul is _not_ Serializable. With jul, you have to add 20++ lines of code to every class just to fix the most fundamental functionality fixed. In this terms jul is a single big mess...
LieGrue, strub --- On Sun, 8/7/11, Mark Thomas <ma...@apache.org> wrote: > From: Mark Thomas <ma...@apache.org> > Subject: Re: [logging] logging vs slf4j > To: "Commons Developers List" <dev@commons.apache.org> > Date: Sunday, August 7, 2011, 9:57 AM > On 07/08/2011 09:31, Jochen Wiedmann > wrote: > > On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > >> Or maybe Log4j 2 could replace [logging]. > > > > If we really have to reconsider this stuff, then I'd > propose to > > > > a) Use java.util.logging, because it doesn't require > any additional > > dependencies and is guaranteed to work anywhere. > > b) Carefully document how to bridge jul to log4j, > because that's > > exactly what's required in almost any application > container I am aware > > of. (The exception being Tomcat, which uses jul > anyways.) > > c) If the slf4j fans insist, add similar documentation > for bridging > > jul to slf4j. > > +1. I like this plan. > > As an aside, Tomcat doesn't use jul, it uses JULI which is > a modified > commons logging implementation hard coded to output to jul > by default > with an alternative Jar that is hard-coded for log4j. Why > the > complexity? jul is not class loader aware which is a > problem as soon as > web applications start declaring loggers with the same > name. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
