It might be common to composite HTTP interfaces like:

@HttpExchange("/v1")
interface V1Api { ... }

@HttpExchange("/v2")
interface V2Api { ... }

interface Api extends V1Api, V2Api {}

There's a probable defect that the HttpExchange is not resolved as expected. The HttpExchange of V2Api is not resolved because the annotation is found based on the Api class. So, when we execute a method in the V2Api class, /v1 prefix is added because the first annotation of the Api class is @HttpExchange("/v1") on V1Api.

This commit fixes the bug by finding the annotation from the declaring class first. HttpRequestValuesInitializer tries to get the annotation from the containing class only when the declaring class is not annotated.

Comment From: pivotal-cla

@0x1306e6d Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: rstoyanchev

We've discussed this on the teams and have decided not accept this change. While the use case here is clear, it opens the possibility for other more confusing cases, for example if a method is on more than one interface. You can achieve a similar effect with one container object and two separate instances of V1Api and V2Api that would eliminate any amiguity.