@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.
RestClientBuilder-built clients
@Path interface-level annotation on the interface, but I notice in the spec, the @Path isn't included in the interface. Is the intent here that only the implementation would include a class-level @Path and in order to point to the right place, you'd include that path value in your baseUri when constructing the client proxy?
Hi @jwcarman - I work on MP Rest Client and on Open Liberty - I'll reply here with "MP" hat on, and reply in the OL channel with my "OL" hat.
The MP Rest Client spec is really only interested in the client side - or rather providing a client side view of the remote service. Since it is intended to work with any REST service, not necessarily a JAX-RS-based service, we don't require or recommend the pattern of JAX-RS resource classes implementing an interface that can also be re-used as the Rest Client interface - though, I do believe that that is a fairly common pattern.
To ensure portability with this pattern, I think that we would need to change the JAX-RS (now Jakarta RESTful Web Services) spec to allow interface inheritance of annotations.
As you mentioned in the other thread, it is possible to put no annotations on the client interface and define the path using the baseUri when creating the client instance - for example:
@Path("path")
public interface MyClient { //...
}
MyClient client = RestClientBuilder.newBuilder().baseUri("http://myhost:9080/app-path").build(MyClient.class);is effectively the same as:
public interface MyClient { //...
}
MyClient client = RestClientBuilder.newBuilder().baseUri("http://myhost:9080/app-path/path").build(MyClient.class);
@Path annotations surprising or confusing. I agree that the current situation makes life easier for application servers, but in this case I would love to see a less surprising behaviour. In fact, a few colleagues of mine tried to refactor our app and tapped into the same pitfall. But defining a good inheritance strategy for conflicting annotations should be possible. Also, JAX-RS endpoints do not need to be CDI beans as far as I know, do they?
I'd call not inheriting the @Path annotations surprising or confusing. I agree that the current situation makes life easier for application servers, but in this case I would love to see a less surprising behaviour. In fact, a few colleagues of mine tried to refactor our app and tapped into the same pitfall. But defining a good inheritance strategy for conflicting annotations should be possible.
No arguments from me, but this is an issue to be taken up with the JAX-RS community. It is possible that this is something that could be put into the 3.1 release - the 3.0 release is basically just changing the package names.
Also, JAX-RS endpoints do not need to be CDI beans as far as I know, do they?
Today, no. The JAX-RS spec is written in such a way that says if CDI is present, then JAX-RS resources and providers will be managed by CDI. But if CDI is not present, then the JAX-RS runtime manages the lifecycle/injection of the resources/providers.
In future JAX-RS spec releases, CDI will be required and will be replacing JAX-RS's mechanism of context injection and lifecycle management.