You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The feign client can support one contract only, and contracts tend to initialize themselves in the constructor. However, contracts are generally not mutually exclusive, and mixing, let’s say, default and spring contracts is totally possible if one transitions from one contract to another. My current workaround uses reflection and simply merges lists and maps of annotation processors of the two, which works because each contract supports its own set of annotations, so only one processor works at a time. It would be great if feign can provide composite contract out of the box that accept a list of contracts as an argument. The rest already works fine thanks to DeclarativeContract
Thanks for spelling this out. A composite Contract sounds like a reasonable additive feature, as long as it does not change how existing single-contract clients behave.
I would take a PR that introduces this as opt-in API, with tests covering mixed default/Spring-style annotation handling and precedence when more than one contract can interpret the same method. If you would rather sponsor/commission the work, I am available via GitHub Sponsors: https://github.com/sponsors/velo.
Activity
velo commentedon Jun 18, 2026
Thanks for spelling this out. A composite
Contractsounds like a reasonable additive feature, as long as it does not change how existing single-contract clients behave.I would take a PR that introduces this as opt-in API, with tests covering mixed default/Spring-style annotation handling and precedence when more than one contract can interpret the same method. If you would rather sponsor/commission the work, I am available via GitHub Sponsors: https://github.com/sponsors/velo.