On Wed, 2012-09-05 at 10:49 -0400, Daniel Kulp wrote: > On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski <[email protected]> wrote:
... > >> 2) Lots of issues trying to associate the request with the connection at > >> connection creation time. I needed information from the request in order > >> to setup the SSL stuff. However, I had a LOT of issues trying to > >> accomplish that. The only thing the ConnectionFactory gets it the > >> IOSession. All that has in it is the HttpHost. The HttpHost is final. > >> The connect occurs on a different thread so thread locals won't work. > >> Also note that all the fields in SSLIOSession are final and private. > >> Thus, I also couldn't find a way to delay the SSL setup stuff till later. > >> Thus, I had to get the request/connection stuff associated up front. I > >> ended up using a IdentityHashMap to associate the HttpHost with the > >> request stuff, but it seemed very hacky. > >> > >> Not really sure what the right solution would be. My initial thought was > >> to make HttpHost non-final so that I could subclass it with an CXFHttpHost > >> or SSLHttpHost or something that would contain extra methods that I could > >> call. Alternatively, add a "properties" map to HttpHost or similar that > >> I could store additional stuff. Another option would be to have the > >> IOSession passed to the factory also contain the "state" (if specified) > >> as a property that could be queried. > >> > > > > Just ditch HttpHost. You obviously need a richer class to represent > > connection routes. HttpClient has HttpRoute class for that matter. You > > probably should be using a custom class that also includes HTTP proxy > > and SSL context bits specific to CXF. > > > > Does this help you in any way? > > Yep. Just feels like I have to subclass/override a lot of behavior from HC > instead of "using" it. Well, in a way this is intended. For better or worse HttpCore was always meant to be a set of low level components one could re-use and extend to build custom HTTP services, primarily HTTP proxies and gateways. For end users we provide HttpClient and HttpAsyncClient modules that are based on HttpCore and represent more 'out of the box' products. > If HttpHost wasn't final, it would be so much more useful. Is there a > particular reason why it has to be final? > There is no particular reason but this is the very first time some one actually wanted to extend it. I cant help thinking aggregation would be more appropriate here than extension. > Still not sure about the Proxy stuff at all, but that's likely because I > don't know much about Proxies at all. I'll likely need to look more into > what proxy stuff does on the wire. > > HTTP proxy support is not all that difficult _as long as_ support for complex HTTP authentication schemes is not required. If you need to support NTLM, Kerberos and the likes, expect a lot of grief and massive scalp hair loss. HttpAsyncClient provides full support for HTTP proxies and most commonly used authentication schemes but it is still considered BETA quality. If you want to re-use CXF authentication code HttpCore would give you more flexibility at the expense of having to write more custom code. Otherwise you might want consider trying out HttpAsyncClient. Oleg
