hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject [HttpClient] HttpClient 4.0 progress report
Date Fri, 04 May 2007 16:38:39 GMT
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message