Incorrect MISSING_CONFIGURATION_ANNOTATION warning in vscode

[sbreakey]

Describe the bug
I am getting a warning that I should annotate a particular class with @Configuration, as the class defines some @Bean methods. The class in question is a Feign configuration class. I apply this class selectively to specific feign clients. If I add the annotation as suggested the class becomes "global" applying to all feign clients.

Interestingly, if I remove the @Bean annotation the RequestInterceptor will not be applied by Feign despite being explicitly set on the FeignClient, so I see 3 possibilities here:

1. the vscode extention is being overzealous in its warning, or
2. the Feign request interceptor is abusing the use of @Bean and should not require that annotation when the config is explicitly applied, or
3. I am just doing something silly... highly likely

To Reproduce
Define a class like so:

public class AdminBearerAuthFeignConfig {

    @Bean
    public RequestInterceptor someInterceptor() {
        return requestTemplate -> {
            requestTemplate.header(
                "Hello",
                "World"
            );
        };
    }
}

This should yield a warning like:

[{
	"resource": "/whatever/SomeClass.java",
	"owner": "_generated_diagnostic_collection_name_#3",
	"code": "MISSING_CONFIGURATION_ANNOTATION",
	"severity": 4,
	"message": "'@Configuration' is missing on a class defining Spring Beans",
	"source": "vscode-spring-boot",
	"startLineNumber": 18,
	"startColumn": 14,
	"endLineNumber": 18,
	"endColumn": 40
}]

Sample

Will provide one later, got to get on with the day job.

[BoykoAlex]

@sbreakey I'm happy you seem to find a false positive for this validation - we'll get in touch with some spring experts about this use case to correct this validation. (Likely we'd make an exclusion from the rule here)
Since it gets in your way I'd go to Settings and then Extensions -> Spring Boot Tools -> Boot 2.x Best Practices and switch MISSING_CONFIGURATION_ANNOTATION to Ignore in the drop-down.

[sbreakey]

@BoykoAlex thanks for the tip, I will disable it for the time being, didn't even know that was possible.

I've raised this over at spring cloud openfeign here too.

I could be completely wrong, but my assumption is that they are "misusing" the @bean annotation in this scenario.
I assume an actual bean is NOT created in this scenario, so they could use a different method, like checking the return types on the methods of the configuration class, and applying them if they are RequestInterceptor, Encoder, Decoder, etc.

[BoykoAlex]

@sbreakey is AdminBearerAuthFeignConfig a bean?
It might be this: https://docs.spring.io/spring-framework/reference/core/beans/java/basic-concepts.html#page-title (this part Full @configuration vs “lite” @bean mode?)

[sbreakey]

@BoykoAlex Hmm, yeah, I guess they are "lite mode" beans. As the AdminBearerAuthFeignConfig class has no annotations at the class level. The only way it is referenced anywhere is like so:

@FeignClient(
        name = "some-client",
        url = "http://www.whatever.com",
        configuration = AdminBearerAuthFeignConfig.class
)

[BoykoAlex]

Fixed with 4093a0e. Config doesn't look like a. bean but it can have @Bean annotations therefore is exception from the rule. The reconciling have re-worked to improve performance hence watch for things like new config class has been added to the @FeignClient but the config class still shows it needs @Configuration - the config class doesn't know it needs to be reconciled hence you could add a space in it or close/open the file. It is a bug with the new implementation for java reconcilings that we'll try to address.