Re: (FELIX-212) commons-httpclient 3.0.1 wrapping

[Roland Weber <ht...@dubioso.net>]

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)

Re: (FELIX-212) commons-httpclient 3.0.1 wrapping

[Felix Meschberger <Fe...@day.com>]

Hi Roland,

Thanks a lot for the clarifications !

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

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 ?

Regards
Felix

On 3/11/07, Roland Weber <ht...@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)
>