Consider defining a bean of type Autowired(required=true) caused by irregular definition of spring 5.1.x class name

When the project was changed to Micro Services, a higher version of spring 5.1.10 was used.

So one class is wrong


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:

Field organizationEsHelper in com.newpearl.dc.service.es.update.AbstractDataOperator 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.

So I'm going to use https://my.oschina.net/ouminzy/blog/3151195 Instead of injecting the constructor, the same error is reported.

So at this point you need debug.

BUG View spring Execution Code

 @Autowired
    private SpringUtils springUtils;


 @Autowired(required = false)
    private ElasticsearchRestClient client;


    @PostConstruct
    public void initMethod(){
        System.out.println(">>>>>>>>>initMethod<<<<<<<<<<<");

        System.out.println(SpringUtils.getBean(ElasticsearchRestClient.class).toString());

    }

After a bean is initialized, springUtils is used to load the beans. Because springUtils is all about getting the beans from the map bean cache if they exist, or if they don't exist

Then initialize.

Then you can interrupt the point BUG to check in.Then I found that client is a null bean. No wonder it made a mistake.

Continue debug to check in.It is found that within the map allBeanNamesByType, the Beaname corresponding to the class ElasticsearchRestClient has no content.

Even if it's gone:


 @Autowired(required = false)
    private ElasticsearchRestClient client;

Through the debug process, it is found that there are no beaname list s in beanDefinitionNames and manualSingletonNames

The bean name ElasticsearchRestClient exists because if the beans are loaded here, they must be acquired through the bean name and loaded into the initialization bean class.

Guess

Why does the class ElasticsearchRestClient not have a bean name?

Reference https://my.oschina.net/u/1261452/blog/1801885?appinstall=0    

The way the bean name is defined above.And this usage of this class is fine with old projects.

I also noticed that IDEA prompted me to modify the name of this class, ElasticsearchRestClient. Could it be that the bean name does not conform to the hump rules?

Instead, Elastic SearchRestClient does not have this problem.

So I think this is a high version bug.And I find that some of the code for the spring 5.1.x scan class initialization bean s seems to have been rewritten in the kotlin language.

I won't go into it.(

This is my issue: https://github.com/spring-projects/spring-framework/issues/24324

Tags: Programming Spring github

Posted on Thu, 09 Jan 2020 19:58:30 -0800 by dvwhi