On March 25, 2014 9:37:10 AM CET, Karl Wright <[email protected]> wrote: >Hi Oleg, > >I've been running into significant difficulties porting ManifoldCF's >various connectors to the new HttpClient 4.3.x paradigms. Basically, >when >I do what I think would be the natural port, I wind up currently with >connections that often don't work. Since MCF is a bit special in that >we >don't have instances of every different kind of repository just hanging >around, that turns this port into a very high-risk affair, unless I can >come up with a methodology to do it that has a high degree of backwards >compatibility. > >With that in mind, let me ask your advice about how best to look at the >problem. > >Most of our connectors used to do the following: They'd create a >DefaultHttpClient instance, change various parameters for it, and then >use >it in an execute() somewhere. What I tried to do based on the builder >model was then the following: > >- use custom() to create a RequestConfig.Builder object >- use custom() to create a SocketConfig.Builder object >- create an HttpClientBuilder object using HttpClients.custom() >- set various properties, including defaultSocketConfig() and >defaultRequestConfig() and the pool reference >- build the httpclient instance > > >What I need to know is the following: >(1) How am I *supposed* to do this now? Am I doing it right? Should I >instead be passing the RequestConfig into the execute()? What is your >preferred canonical form for a request? >(2) What should I change to most closely mimic what was taking place >before? > >Thanks again for your help. > >Karl
You should not try to mimic the old behavior and use HttpContext to customize various aspects of http request execution. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
