On Wed, 2012-09-05 at 15:30 -0400, Daniel Kulp wrote: > On Sep 5, 2012, at 10:49 AM, Daniel Kulp <dk...@apache.org> wrote: > > > > > On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > >> > >> 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. If HttpHost wasn't final, it would be so much > > more useful. Is there a particular reason why it has to be final? > > > > 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. > > OK. Went ahead and ripped out the HttpHost related stuff and replaced with a > CXFHttpHost which is basically a copy of the HttpHost with extra params for > the TLS and Proxy stuff (Proxy stuff unused right now). With that, we're > back to a single connection for all the TLS requests (providing they CAN). > So that looks good now. That pretty much just leaves the Proxy stuff as > the major missing piece. >
Would not aggregation be more appropriate here? class CXFRoute { HttpHost host; HttpHost proxy; SSLStuff sstuff; } Oleg