Hey @kenfinnigan - was talking with Emily Jiang, and she was saying that by adding a hard dependency on JSON-B (which is an EE8 technology) in MP Rest Client, we should've made that a major version upgrade (2.0 instead of 1.3). The specific text in question is
Implementations must provide built-in JSON-P and JSON-B entity providers.. In 1.2, we had this text (essentially making JSON-B optional):
Implementations must provide a built-in JSON-P entity provider. If the implementation supports JSON-B, then it must also provide a built-in JSON-B entity provider.
Would you be ok with releasing a 1.3.1 reverting that language?
ClientRequestFilterthat I add to the underlying
@RegisterClientHeaders-- I suppose this means I need to finally stop using Jersey's
@ClientHeaderParam(name="MyHeader", value="someValue")- but you'd have to do that for all interfaces.
devidheader (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
handcash-toproject 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)
ResourceContextso that I can propagate things from parent resources to child resources
@QueryParam("foo") Set<String> foo
foo=[foo1, foo2]instead of
@andymc12 -- we're beginning to test things with: https://github.com/eclipse-ee4j/jersey/blob/master/ext/microprofile/mp-rest-client/src/main/java/org/glassfish/jersey/microprofile/restclient/RestClientBuilderImpl.java
Do you have a link to a Jira or commit in CXF for this fix?
@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.