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.