Thanks for posting the question on the JAX-RS issue - I'm also interested to see what the community says.
For ClientHeadersFactory, I think it makes more sense to inject server-specific data since the intent of the CHF is to propagate or compute headers from the inbound JAX-RS request to the outbound MP Rest Client request.
But for other providers, I don't think it is quite so clear... and there are probably use cases that could benefit from either one... but I agree with your comment in the issue that MP Rest Client should be consistent with the JAX-RS client.
@Contextinjection optional for now. I'll update the spec to indicate that. Thanks for following up on this issue!
@RegisterProviderannotation, but iiuc, you should be able to accomplish the same thing using MP Config - i.e. use a default file location in the code, but lookup the file location using a config property so that you could change the location in different environments (using system properties, env vars, etc.).
@RegisterProvider, which means that ConfigProperty injection would not be available. Basically, Config injection works in any object instance that is managed by CDI.
@andymc12 It would definitely be a big +1 for me. I added an issue in github, maybe it can start the conversation there...
We don't specify
@PATCH in the spec or test it in the TCK. That might be something we want to add?
If the implementation is based on Java's
HttpURLConnection API, then PATCH requests won't work - the Java implementation only allows HTTP methods that it knows about (GET, POST, PUT, DELETE, HEAD, OPTIONS - a few others, I think), but it doesn't allow PATCH methods...
Implementations could use deep reflection to get around that limitation in the JDK - or use another HTTP Client API, like Apache HTTP Client. Also, I think the Java 11 HTTP Client API does not have this limitation (but of course, that requires Java 11+...).
Glad to hear that you are unstuck - keep in mind that HTTP servers not required to support
X-HTTP-Method-Override (though most REST servers do).
You could also use
@ClientHeaderParam(name = "X-HTTP-Method-Override", value = "PATCH") on the method and then avoid needing to create a parameter for callers to pass "PATCH" to.