On Wed, 2012-09-05 at 15:30 -0400, Daniel Kulp wrote:
> On Sep 5, 2012, at 10:49 AM, Daniel Kulp <[email protected]> wrote:
>
> >
> > On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski <[email protected]> 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
