Affects: \
First of all, I'm sorry for my poor English. The following is a software translation. Please forgive me；
As shown in the following figure
The variable cache contains many empty arrays, causing the if condition below to be true and the method to return early. So that the parent factory cannot be accessed
Comment From: jhoeller
This is just meant to shirt-circuit the bean name retrieval in the local factory since getBeanNamesForType is a local operation. Only BeanFactoryUtils.beanNamesForTypeIncludingAncestors actually accesses ancestor factories as well.
What kind of bean names do you mean to obtain there? You might have to change your call to BeanFactoryUtils.beanNamesForTypeIncludingAncestors in order to see beans from your parent factory as well.
Comment From: buhtigub
This is just meant to shirt-circuit the bean name retrieval in the local factory since
getBeanNamesForTypeis a local operation. OnlyBeanFactoryUtils.beanNamesForTypeIncludingAncestorsactually accesses ancestor factories as well.What kind of bean names do you mean to obtain there? You might have to change your call to
BeanFactoryUtils.beanNamesForTypeIncludingAncestorsin order to see beans from your parent factory as well.
Thank you for your reply. I understand
Comment From: buhtigub
Sorry, I opened this again, as shown in the following figure. The variable cache stores an empty array, but the bean factory has corresponding objects. Once the if branch is established, it is shorted out in advance, and the objects in the bean factory cannot be obtained
Comment From: jhoeller
For new bean definition registrations, we generally clear the by-type cache, so this should not get out of sync. However, we potentially see incomplete type information, are you maybe seeing an effect of that?
How is that "httpClient" bean declared in your configuration? If it is an @Bean method, is the return type maybe declared as plain HttpClient rather than CloseableHttpClient? In such a case, we only really see the declared return type for early type checks, even if the runtime instance ultimately implements a more specific type. As a consequence, the by-type cache would potentially just contain matches against the declared type of your bean definitions, not the runtime type of those beans.
As a general rule, and in particular if you perform by-type searches for specific types, make sure that the declared types of your beans are expressive enough. It is generally a good idea to declare the actual implementation class as the return type of an @Bean method, exposing all of its runtime-implemented interfaces upfront, or alternatively to declare the most specific interface as the return type.
Comment From: buhtigub
For new bean definition registrations, we generally clear the by-type cache, so this should not get out of sync. However, we potentially see incomplete type information, are you maybe seeing an effect of that?
How is that "httpClient" bean declared in your configuration? If it is an
@Beanmethod, is the return type maybe declared as plainHttpClientrather thanCloseableHttpClient? In such a case, we only really see the declared return type for early type checks, even if the runtime instance ultimately implements a more specific type. As a consequence, the by-type cache would potentially just contain matches against the declared type of your bean definitions, not the runtime type of those beans.As a general rule, and in particular if you perform by-type searches for specific types, make sure that the declared types of your beans are expressive enough. It is generally a good idea to declare the actual implementation class as the return type of an
@Beanmethod, exposing all of its runtime-implemented interfaces upfront, or alternatively to declare the most specific interface as the return type.
As you said, it is true that declaring it as a more specific type can solve my problem, but it seems to become a convention. Is this a good idea?
Comment From: snicoll
@kynightyk sorry but we don't use the issue tracker for questions. If you have more questions, please direct them to StackOverflow.