On Thu, 2012-09-27 at 13:33 +0100, Dominique Jaeggi wrote: > hi all >
Hi Dominique > on of our products is an OSGi-based CMS, within which we're using the > venerable apache commons http-client 3.x since many years. > > at that time we wrapped it as an OSGi bundle ourselves, in addition to > providing a bundle activator as well as patching the http client > source, all for the following purpose: > > - on CMS shutdown, kill all open http-client connections in > order to ensure proper and timely shutdown of the CMS. this > was done by simply calling: > > MultiThreadedHttpConnectionManager.shutdownAll(); > > in the bundle activator's stop() method. > > - transparently provide a central proxy configuration for all > http-client requests issued within the realm of the CMS (be > it product code or e.g. user/client's template code. the > configuration is OSGi based (in apache felix). a central > proxy-selector injects any configured proxy through a patched > org.apache.commons.httpclient.HostConfiguration class. this > central proxy configuration is quite essential in e.g. > enterprise deployments where outside internet access must > flow through a proxy server. > > we're now at the point where we'd like to upgrade to apache httpcomponents > 4.x. > > for that purpose we have experimented with version 4.2.1 of the > httpcomponents: > > - applied a similar patching approach for the central proxy > configuration requirement > > - we have not yet found a way to easily implement the shutdown > requirement > > seeing as httpcomponents 4.x are released as OSGi binaries as well, we > were wondering: > > - would it be beneficial to have a bundle activator? I think so. > - do you agree that a central proxy configuration capability > in the context of OSGi would benefit httpcomponents? I think so, as long as it is not specific to a particular OSGi container > - do you have any hints or ideas how the shutdown feature could > be implemented? > Connection manager shutdown should work exactly the same way in HC 4.x as in HC 3.1. What kind of difficulties are you having with the new API? > if you are so inclined, we'd be happy to contribute what we already > have, or to invest time for fixing/extending such contributions in the > context of above stipulated requirements. it would please us to see > such features in a future release of httpcomponents - so you deem them > fitting. > We would happily accept such a contribution given that we have rather limited resources to work on things that are not directly related to HTTP. Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
