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
