Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ken Finnigan
    @kenfinnigan
    I don't have anything
    Andy McCright
    @andymc12
    ok, I'll go ahead and cancel it. Thanks!
    Ken Finnigan
    @kenfinnigan
    FYI. I’m likely not attending these calls going forward. The implementation has been moved into RESTEasy directly, so the team working on that will look to begin attending
    Andy McCright
    @andymc12
    @kenfinnigan sorry to see you leave. on a similar topic, I was kinda thinking that this project might be a good one to go "full async" as has been discussed in the community hangout / google groups.
    Ken Finnigan
    @kenfinnigan
    I think that makes sense
    Derek P. Moore
    @derekm
    Is it possible in MP Rest Client to load a static header value from MP Config and inject that header into every request? I use an interface-only approach in my clients, and right now I'm falling back to using a ClientRequestFilter that I add to the underlying javax.ws.rs.client.Client
    I guess you have @ClientHeaderParam and @RegisterClientHeaders -- I suppose this means I need to finally stop using Jersey's WebResourceFactory!
    Andy McCright
    @andymc12
    @derekm no, but I think that is a good idea. if your client is in a JAX-RS resource method, it is possible to propagate headers from the inbound request via MP Config. You could also annotate your interfaces with @ClientHeaderParam(name="MyHeader", value="someValue") - but you'd have to do that for all interfaces.
    Derek P. Moore
    @derekm
    I use a lot of subresource locator techniques, so that I can actually propagate stuff from a parent-most interface
    I directly reflect the URL structure in my client APIs, e.g. client.root().v1().api().receivingAddress().handle(handle).get();
    then I re-use these interfaces when implementing the server
    Andy McCright
    @andymc12
    that sounds pretty cool. do you have an example on GitHub (or similar) that I could take a look at?
    Derek P. Moore
    @derekm
    sure, but it is all based on WebResourceFactory right now (since I've been using it since 2012)
    turning path parts into method calls makes for very discoverable client APIs, and codifying the URLs into the interfaces is like QA'ing the URL structure!
    Andy McCright
    @andymc12
    thanks
    Derek P. Moore
    @derekm
    handcash-io-api are the resource interfaces, handcash-io-client is the client wrapper based on WebResourceFactory & https://github.com/derekm/jersey-ext
    I use the handcash-io client in this server project: https://github.com/derekm/handcash-to
    where I also define resource interfaces & implement those interfaces for the server functionality
    this powers a Bitcoin project for giving out payment codes against usernames, e.g., handcash.to/$derekm
    I'm integrating with another wallet (RelayX.io) that also has usernames, but there I need to pass a static devid header (I'm spoofing their mobile app to access their handles API) -- my RelayX code isn't yet up on github, but it is the reason for these questions
    Derek P. Moore
    @derekm
    the resource implementations in my handcash-to project are actually quite telling: https://github.com/derekm/handcash-to/tree/master/handcash-to-server/src/main/java/org/hackunix/handcash_to/server (check out HandleEndpoint.java, for example)
    notice how I have to instantiate my own sub-resources with ResourceContext so that I can propagate things from parent resources to child resources
    it is pretty cool doing this kind of thing on both the client and server side, and them mirroring each other nicely
    Andy McCright
    @andymc12
    I've talked with Ken and Michal, and since neither can attend today (and I've got some pressing issues myself), I'm planning to cancel today's meeting. I'll plan to discuss the possibility of going "full async" (i.e. canceling the meetings indefinitely, and using Google Groups and GitHub issues for communication) in the Google Groups
    Andy McCright
    @andymc12
    @kenfinnigan @michalszynkiewicz if you get a chance, can you approve #207 ? once it's in, I'd like to publish a 1.3.3 release that includes that fix and the fix for #204 (both TCK bugs).
    Derek P. Moore
    @derekm
    I think MP Rest Client spec totally overlooked Collection handling
    for example, @QueryParam("foo") Set<String> foo
    MP Rest Client gives foo=[foo1, foo2] instead of foo=foo1&foo=foo2
    Andy McCright
    @andymc12
    @derekm which implementation are you using? I think CXF made a change recently to support multi-valued parameters (I thought it was disabled by default, but maybe not)
    Derek P. Moore
    @derekm
    Andy McCright
    @andymc12

    @derekm here is the CXF issue that I was referring to: https://issues.apache.org/jira/browse/CXF-8089

    but note that it is doing the opposite of what you are wanting.

    Derek P. Moore
    @derekm
    that sounds like MP-Config-isms bleeding into MP Rest Client
    Andy McCright
    @andymc12

    I tested this in Liberty (which uses CXF) and I get the expected query string:

    public interface Client {
        @GET
        @Path("/whatever")
        String whatHappensWhenISendACollectionOfQueryParams(@QueryParam("query") List<String> params);
    }

    when I call client.whatHappensWhenISendACollectionOfQueryParams(Arrays.asList("foo", "bar"));, then I get
    http://localhost:9080/sample-jaxrs-collections/test/whatever?query=foo&query=bar

    Derek P. Moore
    @derekm
    does JAX-RS expect comma separated multi-values?
    oh awesome!
    Andy McCright
    @andymc12
    no, JAX-RS expects ?query=foo1&query=foo2 - but many vendors (like CXF in this case) have settings to allow multiple values for the same query key
    Derek P. Moore
    @derekm
    I know some other backend web platforms expect ?query[]=foo&query[]=bar ... whereas Java usually expects ?query=foo&query=bar
    probably we should realize MP Rest Client intends to target all backends, so we can select the flavor of multi-value
    Andy McCright
    @andymc12
    right - can you update your issue to make that suggestion? I think it would be good for MP Rest Client to default to query=foo1&query=foo2 but be able to switch modes if a config switch is flipped
    Derek P. Moore
    @derekm
    will do, thanks!
    Andy McCright
    @andymc12
    no problem, thank you
    Andy McCright
    @andymc12
    @michalszynkiewicz - would you review the two pull requests (same change - just one for master and one for 1.3.X) for Issue #218?
    Derek P. Moore
    @derekm
    weird use-case here: I'm adding generic @QueryParam filtering to the CollectionEndpoint of my Rest Server abstractions... this turns my get() methods into get(@BeanParam ObjectParams params) ... meaning collection-getting clients need to change from get() to get(null) if they want the full collection, because I can't have ambiguous definitions on my CollectionResource that I share between client and server
    or, rather, the client can handle the ambiguous definitions, but the server cannot
    it would be nice to have a way to have these definitions for the sake of the client without confusing the server
    Derek P. Moore
    @derekm
    Andy McCright
    @andymc12
    @derekm I haven't tried this myself, but would default methods help here? something like this:
    public interface MyResource {
        @GET
        MyObject get(@BeanParam MyBean bean);
        ...
        default MyObject get() {
            return get(null);
        }
    }
    Derek P. Moore
    @derekm
    As you can see in the issue I posted to the jaxrs-api repo, I tried that... But the proxy client needs annotations on the method being called, not just on the indirect method -- maybe that's something that could be clarified about the MP Rest Client spec, if the indirect call will be the appropriately proxied method
    maybe some people feed classes through MP Rest Client, so it wouldn't be appropriate to say, "proxy only unimplemented methods"