Metrics 2.3 optional TCK seems to rely on a non-standard JAX-RS feature: array parameters

[Tim Quinn]

The optional portion of the metrics 2.3 TCK seems to use a non-standard JAX-RS feature: namely array parameters.

The MetricAppBeanOptional class includes several methods with array parameters. 

The JAX-RS spec has no mention of array parameters (although it does, of course, address collections-based parameters).

I even looked for a ParamConverter in the optional TCK code but did not find one.

Am I missing something? 

[Werner Keil]

Did you check if it uses the MP "Rest Client" or if it's really a fork of JAX-RS?

The latter case would pervert the whole idea of compatibility and as I mentioned in another thread here go against Jakarta EE compatibility, but hopefully you really missed something?

Werner

[Tim Quinn]

Sorry, I'm not clear how you see the MP REST client factoring into this, and I'm not sure what you meant by "it being a fork of JAX-RS."

In the optional part of the TCK, the declaration of some of the REST endpoints (server side) are similar to this (from https://github.com/eclipse/microprofile-metrics/blob/a1326c30d1be2018e1e7dfa177322f276d9739d6/tck/optional/src/main/java/org/eclipse/microprofile/metrics/test/optional/MetricAppBeanOptional.java#L171-L175):

    @GET

    @Path("/get-array-param1")

    public String  getArrayParam1(@QueryParam("qp1") String[] v1) throws Exception {

        return "This is a GET request with array parameter";

    }

Note the array parameter, something not mentioned in the JAX-RS spec and therefore outside the standard. 

I get server-side errors when I run the TCK because the JAX-RS implementation we use (Jersey) does not have support for array parameters. But as a spec-compliant implementation, Jersey should be adequate for running the TCK, no?

- Tim

[Werner Keil]

Tim,

Thanks for the detailed explanation. If this was using MP Rest (would be org.eclipse.microprofile.* too) it could have been a different story, but as you outline, it does not, so yes, it should be running with any compatible JAX-RS implementation. If it doesn't that is a serious problem.

Can you confirm the array parameters are not in the JAX-RS spec, because then it would be a "fork" or change that is not compatible with Java EE, that's what I mean. It should pass with a JAX-RS implementation that also passes the JAX-RS TCKs which Jersey obviously does because it was the Reference Implementation (until Jakarta EE changed the term but it is still a Compatible Implementation, see https://jakarta.ee/specifications/restful-ws/2.1/

However 2.3 still uses JAX-RS 2.0.1.

You may want to create an issue ticket in https://github.com/eclipse/microprofile-metrics/issues

Werner

[Tim Quinn]

https://github.com/eclipse/microprofile-metrics/issues/601

[Andy McCright]

I scanned through the JAX-RS 2.1 spec and agree that it does not mention support for array types as query params - at least not without having a ParamConverter provider to deserialize them. IMO, this is an oversight in the spec, since it does cover collections.  I'll bring this to the attention of the JAX-RS community for a possible change in a future release of Jakarta RESTful Web Services.

Until then, I'd recommend that all tests using arrays as query parameters should be removed or made optional.  It looks like there are some tests for Lists already, but the Set/SortedSet test method also includes an array. I'd recommend removing the array to ensure that Sets and SortedSets are handled correctly without needing to handle arrays.

[Santiago Pericas-Geertsen]

On Aug 3, 2020, at 9:46 AM, Andy McCright <j.andrew...@gmail.com> wrote:

I scanned through the JAX-RS 2.1 spec and agree that it does not mention support for array types as query params - at least not without having a ParamConverter provider to deserialize them.

 That is correct.

— Santiago