Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Manish Kumar
    @manish2aug_twitter
    Thanks Andy! I logged eclipse/microprofile-rest-client#263, should I log on open-liberty github?
    Andy McCright
    @andymc12
    yes - this sounds like more of an issue with the implementation than the spec/API. We can leave the MP Rest Client issue open for now until we have determined for sure that it is an implementation issue.
    Manish Kumar
    @manish2aug_twitter
    Agree, issue created (OpenLiberty/open-liberty#11534), thanks
    Lorenzo Vannucchi
    @poldinik
    Hi, anyone knows how solve Invalid HTTP method: PATCH exception? I'm using microprofile 3.3 with Quarkus
    RestClient seems to not work with @PATCH
    Michał Szynkiewicz
    @michalszynkiewicz
    @poldinik I think it may be better to raise it on the Quarkus' Zulip. Personally, I haven't tried it and I don't remember if it should be supported
    Lorenzo Vannucchi
    @poldinik
    @michalszynkiewicz ok, thanks. however I thought it was a MP rest client problem
    i move on zulip
    Andy McCright
    @andymc12

    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+...).

    Lorenzo Vannucchi
    @poldinik
    @michalszynkiewicz @andymc12 if you are interested, the solution is using @POST and @HeaderParam("X-HTTP-Method-Override"). Then you have to set X-HTTP-Method-Override as "PATCH". This is workaround. I've solved in this way
    Andy McCright
    @andymc12

    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.

    Lorenzo Vannucchi
    @poldinik
    ok thanks for the advice
    ya, your solution is more elegant
    Heiko W. Rupp
    @pilhuhn
    Thanks for #217 I was just about to open the same issue :)
    Btw I submitted my PR for #267, but I fear it took me too long to still get it into 2.0
    Andy McCright
    @andymc12
    Hi Heiko, sorry for the delayed response. I'm still trying to figure out whether we can pull it in to the 2.0 release or not. I'll hopefully know more next week.
    Heiko W. Rupp
    @pilhuhn
    :thumbsup:
    Michał Szynkiewicz
    @michalszynkiewicz
    hi, I'm reworking how ClientHeaderParams are filled in Quarkus. In Quarkus we try to do as much as possible during build and I'm wondering if throwing an exception then on invalid method defined in ClientHeaderParam annotation could be thrown then too. WDYT?
    (currently TCK expects it thrown later, when the JAX-RS interface that has the error is used)
    Andy McCright
    @andymc12
    Hi @michalszynkiewicz - overall, I think that sounds reasonable. which TCK test are you referring to? I know that there are a few that will throw a RestClientDefinitionException when the client interface has something wrong with it
    Michał Szynkiewicz
    @michalszynkiewicz
    InvalidInterfaceTest for sure has some tests that assume the deployment goes okay and the exception is thrown later
    If I have a while, I will try to change the tests for params to accept either failing during deployment or on usage\
    Michał Szynkiewicz
    @michalszynkiewicz
    thanks @andymc12 !
    Andy McCright
    @andymc12
    no problem - thank you, @michalszynkiewicz
    Michał Szynkiewicz
    @michalszynkiewicz
    @andymc12 hi Andy, I have one more question, not related. InvokeWithJson*ProviderTests create a rest client in @BeforeTest. Does it have to work?
    I made some changes in Quarkus and it doesn't anymore with them :D but does if I move client initialization to the test method itself
    Andy McCright
    @andymc12
    Hi @michalszynkiewicz - I think we did that just for convenience (since it didn't matter if we re-used the same client instance) - it should be fine to split that out into a separate method that is called by each test. the main point is that JSON-P/B should work with CDI-injected clients and RestClientBuilder-built clients
    James Carman
    @jwcarman
    I have typically used interfaces to define my "api" for my JAX-RS services, including a @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?
    When running in OpenLiberty, it doesn't recognize any class-level annotations inherited from my service interface. I know CXF itself supports that paradigm, because this works fine in Spring Boot. But, it does look like the JAX-RS spec (2.1) specifically says that class-level annotation inheritance is not supported.
    Andy McCright
    @andymc12

    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);
    Derek P. Moore
    @derekm
    I reuse interfaces on both the server side and the client side
    You do have to repeat path annotations on your root resources (I use subresources extensively)
    Andy McCright
    @andymc12
    right - I think that is the only portable approach. afaik, you would not need to repeat method- or parameter-level annotations, as those are inherited from the super-class(es) and/or interfaces
    Derek P. Moore
    @derekm
    Right
    Subresources are actually preferred for awesome client APIs
    You can recreate URL structure in the client method calls, makes things really discoverable
    Benjamin Marwell
    @bmhm
    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. Also, JAX-RS endpoints do not need to be CDI beans as far as I know, do they?
    Andy McCright
    @andymc12

    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.

    Benjamin Marwell
    @bmhm

    It is possible that this is something that could be put into the 3.1 release

    Great! Where do I make such a request? :)

    James Carman
    @jwcarman
    I don't like the idea of requiring CDI for JAX-RS. I write a lot of apps using JAX-RS in Spring Boot (love the glue, hate WebMVC).
    James Carman
    @jwcarman
    it might be better to place certain requirements on IOC containers supporting JAX-RS.
    Then, folks like the CXF project would need to fulfill all of those requirements the "Spring Way" when inside Spring Boot (my usual stack)
    Andy McCright
    @andymc12

    that's good feedback - you might want to add that to:
    eclipse-ee4j/jaxrs-api#569

    I like this statement :-)

    JAX-RS in Spring Boot (love the glue, hate WebMVC).

    James Carman
    @jwcarman
    Added a comment.
    Andy McCright
    @andymc12
    :thumbsup:
    Emily Jiang
    @Emily-Jiang
    @andymc12 In preparation for creating 4.0-RC1, Rest Client needs to create release plan https://groups.google.com/g/microprofile/c/Fyg6Hpi0mRw
    Andy McCright
    @andymc12
    Michał Szynkiewicz
    @michalszynkiewicz
    hi @andymc12, I'm working on implementation of MP Rest Client on top of Reactive RestEasy (a new thing, at the moment element of Quarkus). I tried to reuse the CDI interceptor mechanism for Rest Client interceptors and encountered an issue that MP Rest Client assumes that InvocationContext#getMethod returns an interface method, while the "normal" cdi interceptor mechanism returns my "implementation" class there
    Do you think the check could be loosened a bit to allow an implementation of the interface returned there?
    The downside is that it is probably more intuitive for the users to have the interface method returned there...