Issue 116 - Header Propagation Part 2

[andymc12]

This should complete issue #116 - it adds the @RegisterClientHeaders annotation (by default this will propagate all opted-in JAX-RS headers specified via MP Config property) and the ClientHeadersFactory interface that a user could implement to generate headers themselves.

It includes TCK tests and spec updates. Note that the TCK does not test JAX-RS header propagation (it does test custom ClientHeadersFactory implementations) - the reason for this is because that would add dependencies on a JAX-RS server implementation - and would complicate the test environment. I have verified that my local CXF implementation will propagate JAX-RS headers (using CXF in Jetty as the JAX-RS server).

Signed-off-by: Andy McCright j.andrew.mccright@gmail.com

[eclipsewebmaster]

Issue tracker reference:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=116

[eclipsewebmaster]

Issue tracker reference:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=116

[michalszynkiewicz]

Why do we want to ignore factory classes that are not available on classpath?

[andymc12]

That line is intended to describe an error path behavior. For example, if a user has a rest client interface like:

@RegisterClientHeaders(MyMissingHeaderFactory.class)
public interface MyServiceWithMissingHeaderFactory { ...

and MyMissingHeaderFactory is not packaged with the app - and the implementation cannot find/load it - then the behavior would be to continue the request without invoking the default client headers factory. Ideally the implementation would also log a warning.

We could change this behavior so that if the class is missing, then we would throw a deployment exception - preventing the rest client instance from being created? I am fine either way.

[michalszynkiewicz]

I haven't looked at implementing it yet but I think from the user perspective it would be better if it failed with an exception. It should speed up spotting the problem.

[andymc12]

Sounds good. I'll update and submit a new commit with this change.

[michalszynkiewicz]

@andymc12 I don't fully understand what does "TCK does not test JAX-RS header propagation" mean.
Could you add a link to the CXF test for it that you mention?

[andymc12]

@andymc12 I don't fully understand what does "TCK does not test JAX-RS header propagation" mean.
Could you add a link to the CXF test for it that you mention?

Sure - it just means that the TCK tests a custom implementation of the the ClientHeadersFactory, but it doesn't test that the MP server correctly propagates HTTP headers using the DefaultClientHeadersFactoryImpl - the MP server implementation is supposed to propagate all listed incoming (via JAX-RS service) HTTP headers to the outgoing rest client request. There is a unit test that the DefaultClientHeadersFactoryImpl works as advertised, but nothing that tests that the MP server actually propagates the specified headers.

The test case that I used in CXF has not been merged yet, but you can see it in my branch at:
https://github.com/andymc12/cxf/tree/mpRest12initial-part2/systests/microprofile/client/jaxrs/src/test/java/org/apache/cxf/systest/microprofile/rest/client

Thanks!

[kenfinnigan]

Think it looks good, maybe just change copyright year to 2019?

[andymc12]

Good catch @kenfinnigan ! I've updated the copyright dates to be 2019. Thanks for the review!