Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

FEATURE REQUEST:Multi Level Multiple Inheritance and Override Support

See original GitHub issue

WIP still working on the issue and its associated PR, please bear with me

Goals

Multi Level (Generic) Inheritance With Multiple Inheritance Support at the Second (and Higher) Level And Generic Method Override

Here, the feign client interface SomeServiceClientApi inherits from the interface SomeService, which then inherits from multiple other (generic) interfaces, sharing its interface with the SomeServiceApiController rest controller via the SomeService interface.

interface RetrieveService<T> {
  T retrieve(String key);
}

interface StatusService {
  String status();
}

interface SomeService extends RetrieveService<String>, StatusService {
}

@FeignClient
interface SomeServiceClientApi extends SomeService {
   @GetMapping("/retrieve/{key}", produces="text/plain")
   @Override
   String retrieve(@PathVariable("key") String key);

   @GetMapping("/status", produces="text/plain")
   @Override
   String status();
}

@RestController
class SomeServiceApiController implements SomeService {

  @GetMapping("/retrieve/{key}", produces="text/plain")
  @Override
  @ResponseBody
  public String retrieve(@PathVariable("key") String key) { ... }

  @GetMapping("/status", produces="text/plain")
  @Override
  @ResponseBody
  String status() { ... }
}

or, alternatively (and most provably in combination with the above)

interface RetrieveService<T> {
  T retrieve(String key);
}

interface StatusService {
  String status();
}

interface SomeService extends RetrieveService<String>, StatusService {
}

interface SomeServiceApiBase extends SomeService {
   @GetMapping("/retrieve/{key}", produces="text/plain")
   @ResponseBody
   @Override
   String retrieve(@PathVariable("key") String key);

   @GetMapping("/status", produces="text/plain")
   @ResponseBody
   @Override
   String status();
}

@FeignClient
interface SomeServiceClientApi extends SomeServiceApiBase {
}

@RestController
class SomeServiceApiController implements SomeServiceApiBase {

  @Override
  // going for the naive Spring will fixit approach here, alternatively one must repeat the `@PathVariable` annotation
  // on the formal method parameter here
  public String retrieve(String key) { ...; }

  @Override
  public String status() { ...; }
}

Decomposition of the Service Interface for both Testing and Delegation Purposes

A so composed service interface can be decomposed so that one can test indiividual features of a service a/o client using shared (generic) test classes a/o strategies, when considering standard CRUD and other operations.

One could also use delegates on the server side to realize specific facets of the service interface, e.g. one that will realize the status and one that will realize the retrieve, and so on.

And while the Spring framework already provides for such, Feign will currently prevent this from happening as it does not support multiple inheritance on the interface level. Basically meaning that one cannot have a service interface that is shared between both the client and the server without having to redeclare the client interface.

Positive Side Effects

overriding methods from (parameterized) base interfaces is now supported

Implementation Notes

Since spring-cloud-openfeign does override some of the process* methods from Contract.BaseContract, I resorted to just detecting when multiple methods with the same key are available.

Annotations on base interfaces, except for when it is the first inherited one, are simply ignored.

Additional test cases have been introduced that provide for a basic safeguard but do not realize every possible combination.