Hi Oleg, > * Made the default HttpClient implementation more DI frameworks > friendly. Most dependencies (barring the client connection manager) can > now be in injected through a setter.
I consider reliance on setters rather than constructors as a limitation of the DI framework. Anyway, I have no problem with setters in the implementation class. > * 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. Indeed. > 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. Any idea yet of how to deal with CONNECT requests? Those are meant for the proxy, not for the actual target host. I'm not sure how to avoid for example adding cookies to them without cluttering the interceptors with HTTP method checks. But we'll have a few alphas to sort this out. > Next steps: > =========== > * Port HTTP method recovery code to the new framework. This will involve > fixing HttpRequestExecutor which is kind of broken at the moment I'd call it _incomplete_ :-) Yes, retry handling was one of those things I omitted, since I wasn't sure where exactly it should reside. > * 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. Good point. I was hoping that we could handle it somehow with an HttpHost and a String. But since we can rely on Java 1.4, we could parse it once into a URI and access that whenever we need the pieces of the URL. > 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 Fair. I had a brief look at the commit messages and noticed the removal of Clonable from HttpRoute and RouteTracker because of the missing clone() implementation. For RouteTracker, that was clearly a programming error on my part. I think the HttpRoute has no attributes that need sub-cloning. When I get around to it, I'll review the code and implement suitable clone() methods. Nevertheless, I'll keep test coverage for HttpConn higher on my to-do list. After all, I started on HttpClient only because I needed an idea of the requirements for HttpConn. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
