Folks, Correct me if I am wrong, but my understanding is that all existing versions of commons-logging are fully API compatible. Where they differ is the implementation of discovery algorithm. HttpClient should work just fine with all versions of c-l from 1.0 to 1.4
Oleg On Wed, Jan 26, 2005 at 10:10:39AM +0100, Ortwin Gl?ck wrote: > 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. > > Chris, > > 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 used. > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
