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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
