Okay, I'll try going forward with (2) and barring complications, come back with 
a PR. 

---
A. Soroka
The University of Virginia Library

> On May 15, 2016, at 8:33 AM, Andy Seaborne <[email protected]> wrote:
> 
> On 11/05/16 16:38, A. Soroka wrote:
>> I recently did some work on a project for those exact deprecation
>> warnings (introducing HttpClientBuilder). I would be happy to take a
>> crack at those if you want to make me a ticket. I don't remember it
>> being too hairy.
> 
> https://issues.apache.org/jira/browse/JENA-576
> 
> The uprade looks easy but there is one area
> 
> In the old API http-client, authentication is done by modifying the 
> HttpClient object. In the new API, HttpClient (CloseableHttpClient) is 
> immutable and chnages need to be made at the HttpClientBuilder stage.
> 
> That impacts the HttpOp interface - some functions are of the form 
> HttpClient+HttpAuthenticator.  And the public alls all go to one operation 
> that takes HttpClient+HttpAuthenticator.
> 
> So I think (I have not tried) the forms:
> 
> 1/
> operation(HttpClient, ....) // No auth unless already in HttpClient
> operation(HttpClientBuilder, HttpAuthenticator, ....)
> 
> i.e. HttpClientBuilder if HttpAuthenticator
> 
> 2/
> Or move the creation/setup of authentication out of the operations call flow 
> and provide creator operations.
> 
> Remove all
>  operation(HttpClient, HttpAuthenticator, ....)
> 
> and have
> 
> HttpClient hc
> 
>  hc = createHttpClient(HttpAuthenticator, ....)  // default builder.
>  hc = createHttpClient(HttpClientBuilder, HttpAuthenticator, ....)
> 
> i.e. separate creation and auth setup.
> 
> This, to me, looks more in tune with the new API
> 
> 3/
> Stick to the deprecated AbstractHttpClient style.
> 
> 
> ATM I favour (2).  We don't preserve exact current HttpOp API in (1) or (2) 
> so let's do the better design.  3.2.0 if necessary (but I don't believe that 
> rigid semantic versions makes sense in large system with semi-independent 
> sub-systems; version number changes when many users aren't affected can be 
> more confusion than help; "semantic version" is a guidance not a rule).
> 
>    Andy

Reply via email to