commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [logging] JCL in SLF4J flavour - a demo for discussion
Date Tue, 03 Apr 2007 11:25:30 GMT
On Tue, 2007-04-03 at 22:51 +1200, Simon Kitching wrote:
> 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
> 

Let me take my best shot at trying to explain it.

(1) HttpClient is meant to be a low level transport library and as such
it is supposed to be as non-intrusive toward its upstream dependencies
as possible. To me _personally_ this also means not imposing a
particular choice of a logging toolkit. The reliance on JUL for logging
in HttpClient 4.0 would seem to prevent the use of some popular
toolkits. I am _personally_ not aware of a good JUL to Log4J adapter

(2) I _personally_ am fine with just dumping JCL in favor or SLF4J, but
other HttpComponents committers are currently not.

(3) The only serious gripe about JCL I am aware of is its auto-discovery
mechanism. There _appears_ to be a consensus, please correct me if I am
wrong, that auto-discovery was indeed a mistake.    

(4) I _personally_ still have a rather naive belief that Jakarta stands
for something and we should "eat our own dog food" whenever possible. If
JCL 2.0 were to address the auto-discovery issue, that would remove my
only reservation about using JCL in HttpClient 4.0.

That's just my take on the issue for what it is worth. 

Oleg

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


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