Affects: Spring Framework version 5.1.10 & spring boot version 2.1.9

hello , my project use spring boot version 2.1.9 , Spring Framework version is 5.1.10 my class : 

@Component
public class ElasticsearchRestClient {


    public  void test(){
        System.out.println("aaa");
    }

}

my use class:

@Component
public class OrganizationEsHelper {


   @Autowired
    private ElasticsearchRestClient client;

}

then it has a error:

Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2020-01-10 10:46:08.665 [main] ERROR org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter - 

***************************
APPLICATION FAILED TO START
***************************

Description:

 in com.newpearl.dc.service.es.OrganizationEsHelper required a bean of type 'com.newpearl.dc.service.es.ElasticsearchRestClient' that could not be found.

The injection point has the following annotations:
    - @org.springframework.beans.factory.annotation.Autowired(required=true)


Action:

Consider defining a bean of type 'com.newpearl.dc.service.es.ElasticsearchRestClient' in your configuration.

but rename Classname ElasticsearchRestClient to ElasticSearchRestClient. It runs ok . I think it is a bug. I don't have this problem in another project（spring boot version 1.5.9 , spring version 4.3.13 ） 。

Comment From: snicoll

That ElasticsearchRestClient is actually auto-configured by Spring Boot with a different type (but the same bean name). Because they have the same name and no ElasticsearchRestClient is defined (the type from Elasticsearch, not yours), the auto-configuration applies and overrides your bean. When you try to inject your bean, it fails because it wasn't created in the first place

In Spring Boot 2.2. we prevent bean overriding by default so if you upgrade, you'll get a failure analysis that states that the auto-configuration can't override the bean you've defined. Hopefully, this is a much richer error detail that helps you figure out what went wrong.

This is a general problem with bean naming. You could consider renaming your type, provide a different name via the @Component annotation or customize how names for scanned components are determined. We've recently added a way to customize the BeanNameGenerator via @SpringBootApplication.

Comment From: ouminAsk

Oh, I see. Thank you very much.