Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

eclipse/microprofile-rest-client

People

Repo info

Activity

Ron Sigal

@ronsigal

Btw, I'm happy to open the appropriate issues, once I know what they are. ;-)

Ron Sigal

@ronsigal

I posed the question about Clients running in JAX-RS resources on eclipse-ee4j/jaxrs-api#746.

Andy McCright

@andymc12

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.

Ron Sigal

@ronsigal

In fact, I lean towards giving the Client access to the server's information. Maybe it could be optional. For now, I'm figuring out how to make it work in RESTEasy and hoping for some feedback.

Ron Sigal

@ronsigal

I've just created issue "Client running in server context" (eclipse-ee4j/jaxrs-api#842) with a proposal to clarify this issue.

Andy McCright

@andymc12

@ronsigal looks like the JAX-RS community likes your proposal. I agree with #249 that we should make @Context injection optional for now. I'll update the spec to indicate that. Thanks for following up on this issue!

Ron Sigal

@ronsigal

Thanks, @andymc12, nice working with you.

Derek P. Moore

@derekm

[CC: from eclipse/microprofile-architecture]

Previously, I brought up the idea of MP Rest Client interfaces for MP Health & generic health checks that use those interfaces -- so that services can easily and generically check their remote service dependencies...

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

Chat via Matrix