On Thu, 2012-09-06 at 10:14 -0400, Daniel Kulp wrote: > On Sep 6, 2012, at 9:42 AM, Oleg Kalnichevski <[email protected]> wrote: > > > 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: > >> > >> 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; > > > > } > > Possibly, but if HttpHost is eventually made non-final, with the current > setup it would be very trivial to rip out large chunks of code. :-) > >
No problem at all. Besides, if this experimental code eventually lends in the main code line I'll make sure generic bits get migrated back to the framework. This should help reduce the footprint of custom code you need to maintain internally. I have already made necessary changes to the shared content i/o classes in the 4.3 branch of HttpCore so that they could be used instead of the custom classes currently in the sandbox. Oleg
