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
    Hey, is there some preferred approach to intercepting exceptions? I need something almost like how the above blog post has a header param call a default method combined with an MP-Fault-Tolerance-ish approach... When my auth token expires and I get a 403 Forbidden, I need to renew my auth token and repeat the call.
    Andy McCright
    @andymc12
    @derekm MP Rest Client 1.2 or 1.3 should support CDI interceptors and MP Fault Tolerance. So you could have an MP Rest Client interface - configure it with a ResponseExceptionMapper (or just use the default of WebApplicationException if a >=400 response code is returned) and then either use MP FT or a CDI interceptor to handle the exception in the response.
    Marcin Czeczko
    @marcinczeczko
    Hey, re setting up MP rest client headers. There is ability to implement ClientHeadersFactory and register in the client interface via @RegisterClientHeaders. However the spec doesn't say anything about support of injections in the ClientHeadersFactory implementations. As a contrast providers support this. Is it something that to be covered by spec some time in the future ?
    Andy McCright
    @andymc12
    @marcinczeczko I think that we should definitely plan to address that in the next release - thanks for opening issue #234 for this. I've targeted this issue for the "v.next" release (most likely "2.0" since we are also changing pre-req dependencies to work with Jakarta EE 8).
    Marcin Czeczko
    @marcinczeczko
    @andymc12 thats for update.
    Heiko W. Rupp
    @pilhuhn
    https://gitter.im/eclipse/microprofile-rest-client?at=5ddd935c26eeb8518f203423 is interesting. I am also currently dealing with an API, that communicates state via response code. So basically I also need to react on responses of e.g. a 412. Using FT sounds interesting
    Are the concrete response codes available to the user code? Or how could I have different ExceptionMappers per response code?
    anyway .. l8er
    Andy McCright
    @andymc12
    Nice article @pilhuhn ! Thanks for posting and sharing. You can multiple ResponseExceptionMappers that are tied to specific error codes - you just need to implement (or override? it is a default method in the interface) the handles method - by default, it returns true for all response codes >=400. But you could be more specific and create mappers specifically for different response codes - even "good" response codes, like maybe you want to ensure a non-null entity so you could create a mapper that returns an exception for 204s (no content).
    Andy McCright
    @andymc12
    Hi All - I'm planning to be out tomorrow, but I'd like to push a release candidate of 1.4 on Monday. Before I do, I'd like to merge pull requests #243 and #247 - both have at least one approval, but I thought I'd mention it here in case anybody wanted to take a look. Any objections?
    Andy McCright
    @andymc12
    MP Rest Client 1.4-RC1 is published - the push to Maven Central may still take a little while, but the release page is here: https://github.com/eclipse/microprofile-rest-client/releases/tag/1.4-RC1
    Emily Jiang
    @Emily-Jiang
    @andymc12 you need to undo the Jakarta alignment and then do another release
    Ken Finnigan
    @kenfinnigan
    @Emily-Jiang 1.4 isn't Jakarta aligned, only master is, as far as I recall
    Andy McCright
    @andymc12
    Correct. The jakarta alignment (and any breaking changes) are going into master (tentatively 2.0). The 1.4 release is based on the 1.4.x branch.
    Emily Jiang
    @Emily-Jiang
    ah. ok. thanks for the explaination @andymc12 @kenfinnigan !
    Andy McCright
    @andymc12

    @/all I think we're just about ready to release 1.4 (it's been in release candidate for two weeks, and no issues reported). However, I had a thought I wanted to run by this group - our next release will have breaking changes (provider scope, jakarta dependencies, etc.) so should we break anything else while we're at it?

    The only thing I can really think to break would be baseURL (as opposed to base URI). What would you all think about deprecating usage of URLs in MP Rest Client 1.4, and then removing support in 2.0?

    Ken Finnigan
    @kenfinnigan
    @andymc12 you mean stick with URI and remove URL?
    Andy McCright
    @andymc12
    @kenfinnigan yes, exactly
    (not completely sold on the idea myself - just thinking that if we were going to remove URL, this might be a good time to do it - deprecate in 1.4, remove in 2.0)
    Ron Sigal
    @ronsigal
    I have a question about ClientHeadersFactory injection. I just implemented CDI injection for ClientHeadersFactory's in RESTEasy, and the TCK passes. But I wonder about the mandate for @Context injection, since Jakarta RESTful Web Services plans to deprecate @Context injection in release 3.1 (July, 2020). Notes: 1) I haven't implemented @Context injection, and 2) the TCK doesn't seem to enforce @Context injection. Thanks.
    Andy McCright
    @andymc12

    I had intended to support @Context injection in ClientHeadersFactory. The main reason it isn't tested in the TCK is that I haven't had time to build tests that run in a JAX-RS environment. There are some infrastructure things that are missing - for other HTTP header propagation tests, we're stubbing out the JAX-RS request headers, iirc.

    I did create some @Context tests in the CXF codebase.

    I think that enough people use JAX-RS injection that it is worth doing - especially given how long it will be until it is completely replaced by CDI (which cannot come soon enough, IMHO).

    Ron Sigal
    @ronsigal
    Ok, thanks, Andy. I'll look into supporting @Context injection.
    Andy McCright
    @andymc12
    Thanks @ronsigal !
    Ron Sigal
    @ronsigal

    Hi Andy, I've been thinking some more about @Context in this context, as it were, and a couple of questions come to mind.

    1. 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.

    1. 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?]

    Mmm, my 1 and 2 got turned into a 1 and 1.
    Andy McCright
    @andymc12

    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.

    Ron Sigal
    @ronsigal
    Hi @andymc12, in eclipse-ee4j/jaxrs-api#746, Marek is proposing that automatic discovery of @Provider annotated providers should work on the server side. In that case, I think we could say that a Client would be getting endowed with some of the server environment. Similarly, if we mandate @Context injection of HttpHeaders, which the JAX-RS spec says is for the server-side only, then some of the server environment is available to the Client. What I'm trying to say is that I think the server environment either should or shouldn't be accessible from the Client. From that I would derive that either all of the @Context types should be injectable into ClientHeadersFactory, et al, or only Configuration and Providers should be injectable. I'm not even sure what the right answer is. I just think that whatever we say about @Context injection should follow from an answer to this deeper question. Because of that, I lean toward making @Context injection optional for now .... Having said that, I apologize for throwing sand in the gears at this late date.
    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.