felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: (FELIX-212) commons-httpclient 3.0.1 wrapping
Date Mon, 12 Mar 2007 07:01:52 GMT
Hi Roland,

Thanks a lot for the clarifications !

Given these remarks, I would opt to remove the bundling of HTTPClient

As a less dramatic means, a way would be to clearly state the issues (in the
Commons Wiki Page for example) and add a BundleActivator to the bundling,
which calls the shutdownAll method on stop.

What does the community think on this ?


On 3/11/07, Roland Weber <http-async@dubioso.net> wrote:
> Hi Felix,
> sorry for the late reply, I don't access OSS related mail while
> travelling.
> > You also say, that HTTPClient is not built to be used as a shared
> library.
> > Can you elaborate on that a bit, please ? The reason for me asking is
> that
> > we exactly do that, and if there is actually an issue there, I would
> > like to
> > be prepared (or prevent it altogether): Thanks alot.
> There are some issues I am aware of. One is the MTHCM which I already
> mentioned. That can be addressed by calling shutdownAll(). The other
> connection manager (SimpleHCM) can be shut down individually by the
> application using it, there are no shared background threads.
> Another issue is the static map of registered protocols in class
> org.apache.commons.httpclient.protocol.Protocol. Each application
> that needs to use for example HTTPS will register it's HTTPS protocol
> handler there. There is another static map of cookie specs in
> org.apache.commons.httpclient.cookie.Cookie, but that is typically
> not modified since we ship a good selection of cookie specs which
> are all registered by default. Then there's the default parameter
> factory, a static attribute in o.a.c.h.params.DefaultHttpParams.
> Like the cookie specs typically not modified.
> There might be some other open holes elsewhere... I don't care to
> search for them, because the ones I know of already tell me that it
> is imprudent to run HttpClient 3 as a shared library, unless ALL
> the applications using it are perfectly aware of the limitations.
> > Consequently, if there is a problem, we might (a) provide an activator
> > which
> > "shutdownAll()" on bundle stop [I could do that] or (b) remove
> HTTPClient
> > again.
> Unless you want to document the limitations for it's use, I think
> removing it is the better option. If you feel like documenting it,
> we could find a place for that on the HttpClient pages.
> cheers,
>   Roland
> (btw, I'll be offline again for another week)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message