JENA-1378 : Set the accept header in the default use case.#271
JENA-1378 : Set the accept header in the default use case.#271asfgit merged 2 commits intoapache:masterfrom
Conversation
For use by RDFParserBuilder.
| }); | ||
| HttpClient hc = CachingHttpClientBuilder.create().setDefaultHeaders(hdrs).build(); | ||
| return hc; | ||
| HttpClient hc = HttpOp.createPoolingHttpClientBuilder() |
There was a problem hiding this comment.
Should we maybe just put the default headers into the clients built by HttpOp as options (e.g. HttpOp.createPoolingHttpClientBuilder(boolean useDefaultAcceptHeaderForRdf) or something like that?
There was a problem hiding this comment.
A possibility though I like that HttpOp is neutral as to its usage - it is not RDF-specific and the default headers are none. There are different headers for graph, datasets and result sets. Responsibility for the customization is in the RDFParser which here (this is the case of the app making detailed settings) captures those choices for a reusable parser process.
Adding to the complexity of HttpOp.createPoolingHttpClient seems a slippery slope that goes against the builder pattern (IMO). It would be easier if there were an HttpComponents way to say "make a builder that would produce this HttpClient" capturing the internal settings details of an HttpClient.
There was a problem hiding this comment.
Merged, which fixes the bug as reported. That does not preclude refining it some more.
There was a problem hiding this comment.
For future refining, my understanding of HttpClientBuilder is that it does exactly what you describe above. IOW, you can call build() on it and get a client but keep it around to call build() on it later for another same-config client, over and over again.
There was a problem hiding this comment.
What is required is a builder that is based on another but isolated from it by cloning (or in some way) so that adding new builder settings only changes the clone, not also the original (the current active default in HttpOp in this case).HttpClientBuilder is a setter only style, you can't get settings from it (builder builder needed ?!). RDFparserBuilder has clone().
...while still respecting any direct HttpClient setup.