Sorry Oleg, I didn't explain myself well! I do actually like the APIs, I just had some difficulty adapting. I wanted to understand the rationale for these changes, to ensure I was using them as intended.
Thanks for your explanations, I do appreciate! -- Christopher Le 5 nov. 2013 20:22, "Oleg Kalnichevski" <[email protected]> a écrit : > On Tue, 2013-11-05 at 19:37 +0100, Christopher BROWN wrote: > > Oleg, > > > > OK, I did this. I thought that, given that using DefaultHttpClient was > > deprecated in favor of using CloseableHttpClient, the API had been > changed > > to a "build immutable objects for better performance" model, with the > > fluent API as a side-effect. > > > > Is the API still totally or partially mutable then, with a new > requirement > > to maintain related object instances instead of obtaining them from the > > HTTP client instance? > > > > I've not noticed any significant reduction in lines of code, and it took > a > > lot of time and searching (despite the hints and tutorial) to rewrite > code > > such that there were no "deprecated" warnings. > > > > Thanks, > > Christopher > > > > Christopher > > The internal implementation of CloseableHttpClient is fully immutable. > This makes it significantly easier to ensure its thread safety and also > faster. That does not mean though its dependencies must be fully > immutable. They just need to be thread safe. > > There are better ways of managing variable aspects of HTTP request > execution than messing with the HttpClient instance, namely by using > custom HttpContext instances and per request parameters. The HttpClient > instance should be a shared singleton and ought not be changed (or > changed often). > > I am sorry if you do not like the new APIs, but just cannot make > everyone happy, can I? > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
