Is your feature request related to a problem? Please describe. Yes. I have a simple FeignClient that has it's own configuration class. I do NOT want this configuration to apply globally.
However the spring boot tools plugin in vscode warns me that I should annotate the class with @Configuration, since it has methods with the @Bean annotation (a standard spring pattern).
Unfortunately if I heed the warning, my config becomes global applying to ALL feign clients in my project.
I raised this over at the vscode plugins github, here, and they are suggesting adding an exclusion somehow, but it would seem to me that in general that warning is valid, and that spring cloud openfeign is perhaps "abusing" the @Bean annotation?
Describe the solution you'd like Presumably when a configuration class is specified explicitly like so:
@FeignClient(
configuration = SomeFeignConfig.class
...
)
public interface SomeServiceClient { ...
Then there should be no need for a @Bean annotation on the methods?
I don't know the internals of how the configuration is applied. I assume it looks for @Bean annotated methods? But when the config is set explicitly like this, is an actual bean even created? Could the return type of the methods in the configuration class not be considered instead?
Describe alternatives you've considered I can disable the warning in the vscode plugin, but that sacrifices the warning where it IS valid.
Comment From: sbreakey
The above was based on the assumption that @Bean had no effect if the enclosing class was not annotated with @Configuration or @Component etc.
I believe, from a stackoverflow post, that this is actually incorrect and beans will be created.
If that's the case, then perhaps this is not a reasonable request?
Comment From: OlgaMaciaszek
Hello, @sbreakey, thanks for reporting the issue. For each Feign Client a child application context will be created and in it actual beans form the @Bean-annotated methods in your configuration. This is a documented feature, that we've used across the Spring Cloud portfolio since its inception, and not something that we're planning to change.