Need clarification on sub-resource interfaces wrt to @ClientHeaderParam

[andymc12]

This issue came out of a chat between @michalszynkiewicz and me - quoted below:

Michał Szynkiewicz @michalszynkiewicz 06:36
hi @andymc12, how do you handle @ClientHeaderParam with subresources? If someone defines it on a method that "returns" the subresource (in the root interface), will it get applied?

Andy McCright @andymc12 10:16
@michalszynkiewicz we should probably clarify this behavior in the spec... right now, my Liberty / CXF implementation doesn't handle the case where the @ClientHeaderParam(...) is on a method in the sub resource interface, but it does handle it when the annotation is on the sub-resource method in the main resource interface. for example:

public interface SubService {

    @GET
    @ClientHeaderParam(name = "MyHeader", value = "abc") // this is ignored
    String doSomething();

}

public interface Service {

    @Path("/sub")
    @ClientHeaderParam(name = "MyHeader", value = "def") // if this is present, it works - sends "MyHeader: def" when invoking sub().doSomething(...);
    SubService sub();
}

Michał Szynkiewicz @michalszynkiewicz 14:17
thanks, to me the opposite is more intuitive ;)

Andy McCright @andymc12 15:49
yeah, I agree. I think I've got some work to do. :)

So this issue intends to address that @ClientHeaderParam annotations on sub resource interfaces should be honored. There should also be some clarification on annotations on the sub-resource method (Service.sub() in the example above) - and whether or not they should be honored - and if so, in what priority to potentially conflicting annotations on the sub resource interface and methods.