commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] JCL in SLF4J flavour - a demo for discussion
Date Tue, 03 Apr 2007 10:51:34 GMT
On Mon, 2007-03-26 at 15:51 +0200, Oleg Kalnichevski wrote:
> On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote:
> > Hello,
> > 
> > I have seen the recent discussions on JCL 2.0.0 and a version without 
> > autodiscovery.
> > Someone stated to stop any further development (with good reasons 
> > behind) but I am
> > thinking different.
> > 
> > Please have a look at the (working) code:
> > https://issues.apache.org/jira/browse/LOGGING-112
> > 
> > It has a static binding, some improvements in the logfactories 
> > (recognizes native implementations).
> > API and implementations are cleanly separated, the 1.1.x diagnostic 
> > function is still used.
> > 
> > What are your thoughts?
> > Is this a possible direction?
> > 
> 
> Hi Boris,
> 
> I think this patch represents the way I personally would like to see JCL
> evolve in the future. If JCL 2.0 were being developed along these lines,
> I (personally) would be very inclined to continue using JCL for the next
> major version of HttpClient.

Would you both mind explaining what benefits you see in a new JCL
implementation that cannot be obtained via java.util.logging?

I'm no fan of the j.u.l design, but it seems to me less effort to use it
than to fight it. What have I not understood?

And what would a new JCL do for anyone that they could not do by just
using SLF4J via its JCL API? The SLF4J team have already done a lot of
hard work; what benefit would there be to duplicating that?

Regards,

Simon


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