Latest changes in the trunk =========================== * Made the default HttpClient implementation more DI frameworks friendly. Most dependencies (barring the client connection manager) can now be in injected through a setter. If a dependency has not been explicitly specified by the consumer, HttpClient will create an instance of the default implementation lazily on demand. No objects get created unnecessary. No intermediate garbage.
* Made the default HttpClient implementation threading safe by creating local copies of all shared resources that are potentially threading unsafe. This should also improve performance by reducing resource contention when employing a significant number of worker threads at the expense of slightly greater memory footprint. * Ported HTTP state management code to the new API. This is actually a pretty good example how much cleaner and better the code gets thanks to the new protocol framework. Cross-cutting aspects such as the HTTP state management can be isolated and implemented as a number of protocol interceptors. Those protocol interceptors apply transparently to all HTTP messages that pass through the HTTP client. If one wants to customize the way cookies are handled all it takes is overriding the default interceptor with a custom one without having to touch a single line of application code. http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpclient/trunk/src/java/org/apache/http/client/protocol/RequestAddCookies.java http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpclient/trunk/src/java/org/apache/http/client/protocol/ResponseProcessCookies.java Compare this to the horrendous mess that is cookie management in Commons HttpClient and feel the difference. Next steps: =========== * Port HTTP method recovery code to the new framework. This will involve fixing HttpRequestExecutor which is kind of broken at the moment * Better request URI handling. HttpCore represents request URIs as strings in order to avoid dependency on any particular URI implementation. However, there are a couple of places in HttpClient where a manipulation with request URIs is required. At the moment we have to parse the same request URI several times in the course of the HTTP method execution. Something needs to be done about it. Roland, I was trying to be gentle about your code and but I did have to change a few things here and there. Please review the changes whenever you happen to have time and inclination for some HttpClient hacking Evil Comrade Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
