Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Derek P. Moore
    @derekm
    I've run into an interesting hiccup that is worth thinking about, and also might be a sort of smell on its own.
    We have a few services that depend on each other (circular dependency) for different things. So using our generic MP-Rest-Client-based healthcheck to check each other's /health endpoint is dangerous.
    Since they'll infinitely recurse checking each other! :D
    should MP Health specify a simpler ping-like endpoint? Or HEAD on /health or something?
    such that GET /health is used by the orchestrator for load-balancer inclusion and dependent services can safely just check the "ping" endpoint to ensure the service is "UP"
    🇮🇪傻瓜
    @irishshagua_twitter
    Is there a way to parameterize ClientRequestFilter that is being added to a Rest Client interface via the RegisterProvider annotation? Ideally I'd like to inject the filter using CDI, as the parameter that I'm using involves a file location which I'd like to change in acceptance tests etc...
    Andy McCright
    @andymc12
    @irishshagua_twitter you cannot parameterize providers in the @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.).
    🇮🇪傻瓜
    @irishshagua_twitter
    @andymc12 cheers for coming back to me. Is ConfigProperty injection available in a class which is registered via RegisterProvider annotation?
    Andy McCright
    @andymc12
    @irishshagua_twitter I don't think it is not defined in the spec. I think most implementations just "new up" an instance of classes defined in the @RegisterProvider, which means that ConfigProperty injection would not be available. Basically, Config injection works in any object instance that is managed by CDI.
    Andy McCright
    @andymc12
    This is probably a good feature request to add to the next version of the Rest Client - basically something that says if CDI is available then all providers registered via @RegisterProvider should be managed by CDI.
    🇮🇪傻瓜
    @irishshagua_twitter

    @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

    🤷‍♂️

    Andy McCright
    @andymc12
    Thanks for opening the issue @irishshagua_twitter - I’m a little bogged down right now, but I’ll take a look at it soon. It should be something that we do for the next release.
    Manish Kumar
    @manish2aug_twitter
    Hi guys, I am seeing an issue with async mp rest client (ibm liberty-19. 0.0.4, mprestclient 1.2) client r
    After retrieving the results from the client I found that it is deserialising list into hasmap
    Andy McCright
    @andymc12
    Hi @manish2aug_twitter - thanks for mentioning this. Can you open a GitHub issue with OpenLiberty at https://github.com/OpenLiberty/open-liberty/issues ? Please include as much information about the problem as possible (a sample app that reproduces the problem is best, but I'll take anything you have - logs, code snippets, etc.). I'll take a look at it when I can.
    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