eclipse-ee4j / eclipse-ee4j/jersey
Clarification in manual:
- Dominant language
- Java
- Stars
- 730
- Forks
- 382
- PR merge metrics
- No merged PRs in 30d
Description
I would like to propose that the Jersey manual is improved slightly to clarify some open questions when it comes to using the JAX-RS Client API.
* In [5.5. Client Transport Connectors](https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/user-guide.html#connectors) the warning about header issues is rather vaque:
>There is an issue handling HTTP headers in WriterInterceptor or MessageBodyWriter. If you need to change header fields do not use nor ApacheConnectorProvider nor GrizzlyConnectorProvider nor JettyConnectorProvider neither NettyConnectorProvider.
* Can you please clearly describe which particular modifications of the headers are explicitly forbidden or not working?
* Do I see correctly that this effectively means, that *only* the JRE's `UrlConnection` based provider can be used (because the client application author *cannot* know what any *Third Party* JAX-RS component actually does w.r.t headers)?
* Can you please explain *why* a container provider can be selected simply by putting it on the class path (thanks to `ServiceProvider`), but it does *not* work to select a connector provider simply by putting it on the class path (due to missing `service` folder in the provider JARs)? This is rather counter-intuitive and the reader should get an understanding of that design decision.
* Can you please describe how to select a connector provider without making the calling source code Jersey specific? Is there a property that accepts the connector provider's name as a String, so the invoking client application's source code can be *compiled* without Jersey and *run* with competitive JAX-RS client implementations?
Contributor guide
Assessment
This issue has not been assessed yet.