Hi Andy, I've been thinking some more about @Context in this context, as it were, and a couple of questions come to mind.
- I've always been uneasy about the relationship between a clients (originally JAX-RS clients but now MP REST clients as well) running in a JAX-RS resource and the server environment. For example, https://issues.redhat.com/browse/RESTEASY-2084 is about whether a @Provider annotated provider should be discovered and made available to a client running on the server side. We made it so for ClientRequestFilters and ClientResponseFilters, but but we still have an open issue about other providers, and we haven't reached a conclusion. In fact, one of our guys opened eclipse-ee4j/jaxrs-api#746 to ask for clarification.
I mention this concern because of Secion 10.2 "Context Types" of the JAX-RS spec:
This section describes the types of context available to providers (client and server) as well as resource classes and Application subclasses (server only). Except for Configuration and Providers, which are injectable in both client and server-side providers, all the other types are server-side only.
So, if a ClientHeadersFactory is created for an MP REST Client running in a JAX-RS resource, what can be @Context injected into it? Do you mean for all server-side injectable types to be available to ClientHeadersFactorys? Maybe that should be clarified, either in the MP REST Client spec or as part of a more general clarification in the JAX-RS spec.
- RestClientBuilder supports registration of JAX-RS providers, but I don't think there's any mention in the spec of supporting injection in that case. Maybe that's just an oversight? But shouldn't ClientHeadersFactory and the JAX-RS provders be treated the same?
-Ron
[Is this too long for glitter?]
Hi Ron - for (1) I don't think the client APIs (JAX-RS Client or MP Rest Client) support automatic provider discovery like the JAX-RS server APIs do. I'm not 100% sure about this, but I think that means that the client APIs should only use the "built-in" providers (like MBRs/MBWs for JSON and XML, etc.) and providers that are explicitly registered by the client (programmatically for the JAX-RS client, or programmatically or declaratively for MP Rest Client).
My thought was that anything that JAX-RS allows to be injected via @Context should be allowed to be injected in the ClientHeadersFactory, though I haven't tested everything in CXF. Some things definitely have more value than others - for example, I think things like SecurityContext, UriInfo, HttpHeaders, Request, Application, etc. are more useful than say ResourceContext or Providers. Would you like to limit what can be injected? If so, I think we should probably phrase it something like "Implementations are required to inject X, Y, and Z, but may optionally inject A, B, and C." - that way implementations don't need to arbitrarily restrict what is injected. In any case, it is probably worth opening an issue to add TCK tests for @Context injection.
For (2), good point. I think this is something that we should clarify - and I think it opens up some interesting situations. For example, suppose that a client has registered a ClientRequestFilter that contains @Context HttpHeaders myHeaders, and the client is executing in a JAX-RS request. Which set of headers should be injected into myHeaders, the headers for the outbound Rest Client request or the headers for the inbound JAX-RS request? Can you open an issue for this? I think we may need to leave it undefined for 1.4, but I think we should clarify it for 2.0.
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.
@Context injection optional for now. I'll update the spec to indicate that. Thanks for following up on this issue!
@RegisterProvider annotation, 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...
eclipse/microprofile-rest-client#256
🤷♂️
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.
