Okay, coming back with a quick design question. The current type for authentication (o.a.j.atlas.web.auth.HttpAuthenticator), works via the following signature:
public void apply(AbstractHttpClient client, HttpContext httpContext, URI target); The idea here (IIUC) is to apply authentication to an _extant_ HTTP client, context and URI. The problem for option 2 is that this is pretty late in the game, obviously later than client construction. Is the idea to bake in the HttpAuthenticator as part of the (immutable) state of a subclass of o.a.h.c.HttpClient that automatically applies the behavior at request execution? That tangles Jena and o.a.http.client types in a way that seems to me to be a bit odd, but my sense of Jena's idiom is pretty undeveloped. Just want to make sure I am on the right road. It would mean altering FormsAuthenticator to factor cookies out of the client into the context, and that means an HttpClientContext, so we'd end up with something like: public void apply(HttpClient client, HttpClientContext httpContext, URI target); which would break HttpAuthenticator impls out there in the world, but not horrifically. It would also mean that the client in that signature would have immutable state going forward, and that has more potential, I think, to break impls, but anyone doing a custom authenticator should also be able to factor that state out of the client into the context like I describe above. --- 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
