hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Brown" <chris92...@hotmail.com>
Subject Re: [POLL] Minimal JRE requirement for HttpClient 4.0
Date Wed, 26 Jan 2005 18:55:18 GMT
OK, it was just an idea!  Thanks for taking the time to consider it anyway.

Turning the problem on its head, it seems like HttpClient 4 is intended to 
be a really complete package...  Are there any features that aren't intended 
for say HttpClient 4 that might be implemented in HttpClient 5 (that you've 
already thought of) ?

The worry about choosing a JDK is that some new features might not be 
available on platforms that are at present, if I'm correct.  How about 
making HttpClient 1.3+ compatible, then say making HttpClient 5 to run with 
Java 5, no new features, just a new implementation that takes advantage of 
Java 5's new and useful stuff..?

- Chris

>From: Ortwin Glück <ortwin.glueck@nose.ch>
>Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
>To: HttpClient Project <httpclient-dev@jakarta.apache.org>
>Subject: Re: [POLL] Minimal JRE requirement for HttpClient 4.0
>Date: Wed, 26 Jan 2005 10:10:39 +0100
>Chris Brown wrote:
>>Hi all,
>>I was thinking that one of the most annoying aspects of current releases 
>>of HttpClient (as far as I'm concerned) is that it depends upon 
>>commons-logging, and as such it's not always easy to mix-and-match with 
>>other Java APIs that use different versions of commons-logging.  By 
>>settling on Java 1.4, you could use the built-in logging API (any 
>>shortcomings can be addressed by dropping in custom handlers and 
>>formatters, it's not difficult, if the user requires it).
>>Another possible advantage of 1.4 is that it builds in all the JSSE and 
>>JCE stuff that's useful for SSL and NTLM support.
>I want to make some statements regarding commons-logging and DLL hell.
>We use commons-logging because HttpClient is a library and as such must not 
>dictate which logging implementation to use. The user can choose the one he 
>likes and HttpClient will use it.
>Many products use common-logging. Some of them in an old version. This is a 
>problem and usually results in a "no such method" exception. However, 
>problems like this one are pretty normal in software development. Just look 
>at a Linux distribution. It is essential that all binaries on a 
>distribution use the same glibc (or any other library) version. There is no 
>possibility that some binaries use one version and some use another version 
>*). They all have to agree on one version to make the system work. In some 
>cases this requires patching the original code.
>The exact same thing applies to Java applications that use common 
>libraries. All components of an applications have to agree on the same 
>version of common libraries (or need to use ugly Classloader bricolage). As 
>HttpClient is open source you always have the option to create a patch to 
>an older version of the commons-logging API.
>Best we can do is use the commons-logging API version that is most widely 
>Ortwin Glück
>*) You can argue that the dynamic linker (ld) can be controlled by some 
>environment variable to load a specific version of a DLL. While this works 
>for a simple dependency on a library, it doesn't in a more complex 
>situation. In the following setup for instance the problems can not be 
>solved by setting ld environment variables.
>app ---->  glibc (2.3)
>     ---->  zlib ---> glibc (2.2)
>To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

MSN Messenger : dialoguez en temps réel avec vos amis ! 

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

View raw message