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.
This issue came out of a chat between @michalszynkiewicz and me - quoted below:
}
public interface Service {
}