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
    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"
    Derek P. Moore
    @derekm
    looks like detecting and handling default methods on proxied interfaces doesn't work the same between Java 8 and Java 9 (you got me wondering if I can just hack in allowing unannotated indirection via default methods)
    I'll find a way to open source my Rest Server abstractions, as I think they'll help drive JPA, JAX-RS and MP specs (and maybe JLS ;)
    Andy McCright
    @andymc12
    FYI: MP Rest Client 1.3.4 is publicly available - confirmed it is available from Maven Central at:
    https://mvnrepository.com/artifact/org.eclipse.microprofile.rest.client/microprofile-rest-client-api/1.3.4
    Derek P. Moore
    @derekm
    Was thinking it would be nice to have MP Rest Client resource interfaces and objects for MP Health endpoints
    Andy McCright
    @andymc12
    Good point. I was thinking along the same lines for the MP Metrics stuff. It might be nice to have a "built-in" client to get metrics data
    Derek P. Moore
    @derekm
    absolutely! Metrics & Health resource interfaces are a must. We're starting to write reusable system tests for all of our MP applications to inherit that will ensure those endpoints are responsive. We recently swapped out Yasson for Johnzon due to JsonbCreator "bugs", and we broke all of our metrics endpoints but didn't notice until we started standing up prometheus after one of our techs got back from PromCon :)
    Derek P. Moore
    @derekm
    *those endpoints == MP Metrics & Health endpoints
    Andy McCright
    @andymc12
    I opened MP HealthCheck issue 216 ( eclipse/microprofile-health#216 ). I think it is a good idea - and could probably be implemented fairly easily (see the issue for my suggestion on how it could be implemented) - if you have additional ideas, please update the issue with them. I'll open another issue for MP Metrics, but that might not be as easy to implement given how many stats are tracked by Metrics.
    Derek P. Moore
    @derekm
    We will be whipping up some interfaces ourselves, so I'll post those when I get a chance. We strictly separate resource-path & http-verb annotations, so ours will be more like: proxyClient.health().live().get().
    Derek P. Moore
    @derekm
    Did we ever get a mode in MP Health that allows Map<String, Check> checks such as Hammock supports or the healthchecks RFC calls for?
    (or even Map<String, List<Check>> checks as per strict RFC conformance?)
    Andy McCright
    @andymc12
    I'm not sure on that - that might be a good question for the MP Health channel (if they have one? if not, you could ask on the MP mailing list)
    {
      "checks": {
        "application:info": {
          "data": {
            "name": "starter-app",
            "version": "1.0.0-SNAPSHOT"
          },
          "name": "application:info",
          "state": "UP"
        },
        "system:info": {
          "data": {
            "componentType": "system",
            "hostname": "Dereks-Work-MacBook-Pro.local",
            "address": "10.37.70.112"
          },
          "name": "system:info",
          "state": "UP"
        },
        "application:uptime": {
          "data": {
            "componentType": "component",
            "observedUnit": "ms",
            "observedValue": 6411,
            "time": "2019-11-12T20:40:17.208Z"
          },
          "name": "application:uptime",
          "state": "UP"
        }
      },
      "outcome": "UP"
    }
    (you'll notice we're still on MP Health 1.0!)
    we get this improved output by setting hammock.health.output.format=map in MP Config
    we need to unwrap data objects and we'll be pretty close to the healthchecks RFC
    Derek P. Moore
    @derekm
    just built a generic healthcheck that checks other healthchecks, based on whatever proxy client configs that we already have :)
    Andy McCright
    @andymc12
    nice! that was one of the use cases I gave the health checks guys! :)
    Derek P. Moore
    @derekm
    Adding a mode where it produces a healthcheck for all discovered @Any Instance<BaseServiceClient>
    Every client the app depends on will have a test
    Derek P. Moore
    @derekm
    right now it is:
    public class StarterAppHealth extends RemoteHealthCheckMap {
    
        @Override
        public String getConfigPrefix() {
            return "starterApp";
        }
    
    }
    public abstract class RemoteHealthCheckMap implements HealthCheck {
    
        RemoteHealthCheckClient client;
    
        abstract public String getConfigPrefix();
    
        @Override
        public HealthCheckResponse call() {
            client = new RemoteHealthCheckClient();
            HealthCheckMapResponse check = client.root().health().get();
    
            return HealthCheckResponse
                    .named(getConfigPrefix() + "-health")
                    .withData("target", client.getTarget().getUri().toString())
                    .state(check.outcome == HealthStatus.UP)
                    .build();
        }
    
        class RemoteHealthCheckClient extends BaseServiceClient<RootHealthMapResource> {
    
            @Override
            protected Class<RootHealthMapResource> getRootClass() {
                return RootHealthMapResource.class;
            }
    
            @Override
            protected String getConfigPrefix() {
                return RemoteHealthCheckMap.this.getConfigPrefix();
            }
    
        }
    
    }
    Derek P. Moore
    @derekm
    our BaseServiceClient can wrap either WebResourceFactory or RestClientBuilder
    Derek P. Moore
    @derekm
    How does RestClientBuilder react to an endpoint that doesn't have a content-type header even when the resource definition says it @Produces(MediaType.APPLICATION_JSON)?
    Andy McCright
    @andymc12
    It should attempt to serialize the request entity to JSON using the most applicable MessageBodyWriter it can find - and then it will generate a Content-type: application/json header in the request.
    Derek P. Moore
    @derekm
    I mean on the client side... WebResourceFactory doesn't like endpoints that drop the Content-Type header even if the interface WRF is using says to expect JSON.
    In other words, WRF always assumes octet-stream if content-type header is missing, even if the JAX-RS resource it is using says what the content-type ought to be.
    was wondering if RestClientBuilder had the same issue
    Andy McCright
    @andymc12
    ah - if the client side has @Produces(MediaType.APPLICATION_JSON) then it will expect that the content is JSON, and will attempt to select a MessageBodyReader that handles JSON and the object in the return type. This is now the default in MP Rest Client 1.3 (the default consumes/produces was previously undefined, but now the default is application/json for both).
    if the pre-1.3 client side interfaces does not have @Produces(...), then it would most likely be application/octet-stream but different vendor implementations might have defaulted to something else (text/plain, etc.).
    Derek P. Moore
    @derekm
    awesome, was just checking that MP Rest Client spec would allow proper deserialization when content-type is missing on the response but when the interface knows what it should accept