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-client depends on
starter-app-tests depends on
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)
starter-app-resourcesand guarantee that they're perfectly compatible with
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
curl -u user:pass http://...?
ClientHeadersFactoryand 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 ?
handlesmethod - 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).
@/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?
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).
Hi Andy, I've been thinking some more about @Context in this context, as it were, and a couple of questions come to mind.
I mention this concern because of Secion 10.2 "Context Types" of the JAX-RS spec:
This section describes the types of context available to providers (client and server) as well as resource classes and Application subclasses (server only). Except for Configuration and Providers, which are injectable in both client and server-side providers, all the other types are server-side only.
So, if a ClientHeadersFactory is created for an MP REST Client running in a JAX-RS resource, what can be @Context injected into it? Do you mean for all server-side injectable types to be available to ClientHeadersFactorys? Maybe that should be clarified, either in the MP REST Client spec or as part of a more general clarification in the JAX-RS spec.
[Is this too long for glitter?]
Hi Ron - for (1) I don't think the client APIs (JAX-RS Client or MP Rest Client) support automatic provider discovery like the JAX-RS server APIs do. I'm not 100% sure about this, but I think that means that the client APIs should only use the "built-in" providers (like MBRs/MBWs for JSON and XML, etc.) and providers that are explicitly registered by the client (programmatically for the JAX-RS client, or programmatically or declaratively for MP Rest Client).
My thought was that anything that JAX-RS allows to be injected via
@Context should be allowed to be injected in the ClientHeadersFactory, though I haven't tested everything in CXF. Some things definitely have more value than others - for example, I think things like
Application, etc. are more useful than say
Providers. Would you like to limit what can be injected? If so, I think we should probably phrase it something like "Implementations are required to inject X, Y, and Z, but may optionally inject A, B, and C." - that way implementations don't need to arbitrarily restrict what is injected. In any case, it is probably worth opening an issue to add TCK tests for
For (2), good point. I think this is something that we should clarify - and I think it opens up some interesting situations. For example, suppose that a client has registered a
ClientRequestFilter that contains
@Context HttpHeaders myHeaders, and the client is executing in a JAX-RS request. Which set of headers should be injected into
myHeaders, the headers for the outbound Rest Client request or the headers for the inbound JAX-RS request? Can you open an issue for this? I think we may need to leave it undefined for 1.4, but I think we should clarify it for 2.0.