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
    is there a way to tell MP Rest Client in these situations "for this session, use XML"?
    Andy McCright
    @andymc12
    no, in MP Rest Client, all of the content-type negotiation is done via annotation, so it is pretty much static. you'd need to use the JAX-RS Client - which would allow you to specify the media type(s) you want to send/receive
    Derek P. Moore
    @derekm
    My goal is to reuse the same resources and objects on client-side and server-side
    Seems reasonable to allow someone to set a preferred type if resources have multiple types. WebResourceFactory always chooses the 1st in the produces/consumes lists
    Derek P. Moore
    @derekm
    So if I say on a POST resource “consumes(xml, json) produces(json, xml)”, my WebResourceFactory clients will send XML and accept/receive JSON, and my server side will honor it ;)
    But with RestClientBuilder, I want to say “the preferred content type is xml” so that xml happens on both request body content type and accepts header, regardless of annotation values array order
    Ken Finnigan
    @kenfinnigan
    The goal of rest client spec is to be type safe. If you want flexibility, then as Andy mentioned you’re best to stick with the regular JAX-RS Client
    Derek P. Moore
    @derekm
    I don’t want flexibility... I want the same resource definitions on client side and server side
    Derek P. Moore
    @derekm
    I’m not going to write the twice
    I mean: I might be forced to either cripple what I write or write them twice. So far I’m choosing the former in my professional life, but not in my personal life.
    Derek P. Moore
    @derekm

    I organize my projects like:

    starter-app
    ├── starter-app-server
    ├── starter-app-client
    ├── starter-app-resources
    └── starter-app-tests

    starter-app-server depends on starter-app-resources
    starter-app-client depends on starter-app-resources
    starter-app-tests depends on starter-app-client
    starter-app-server & starter-app-tests produce executable jars, the web application and the junit tests that use the client to execute system tests against the deployed web application (this is separate from the server module being thoroughly unit tested during build)

    this way other microservices can depend on starter-app-client & starter-app-resources and guarantee that they're perfectly compatible with starter-app-server
    Derek P. Moore
    @derekm
    additionally, we write our resource definitions such that
    GET /org/:orgId/rep/:repId/project/:projectId
    becomes
    client.root().org().org(orgId)
                 .rep().rep(repId)
                 .project().project(projectId)
                 .get()
    this way you can also: client.root().org().get() to get all orgs or client.root().org().post(org) to create orgs or client.root().org().org(orgId).put(org) to update orgs, etc., very mechanically and 1:1
    with all the benefits of discoverability in sane URL structures and with IDE code assist/type-ahead-find/intellisense
    Derek P. Moore
    @derekm
    since I've established this duality, if I want a more capable server, my client may need to follow suit -- so far at least using the 1st media type in the produces/consumes that have lists is sufficient, so the ability to set a preferred media type may have negligible benefits
    Heiko W. Rupp
    @pilhuhn
    Hey,
    what is the annotation equivalent in MP-rest-client of doing curl -u user:pass http://... ?
    Heiko W. Rupp
    @pilhuhn
    Ok, found it @ClientHeaderParam(name = "Authorization", value = "{lookupAuth}“) and default String lookupAuth() { return "Basic " + Base64.getEncoder().encodeToString(„user:pass“); }
    Heiko W. Rupp
    @pilhuhn
    This is not yet published.
    Andy McCright
    @andymc12
    @pilhuhn that's correct - I can't view the blog post yet, but I'm excited to see it!
    Andy McCright
    @andymc12
    very nice! thanks @pilhuhn !!
    Derek P. Moore
    @derekm
    very cool! I didn't realize MP Rest Client could call default methods like that.
    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 !