The following code comes from the DependencyDescriptor
/**
* Resolve the specified bean name, as a candidate result of the matching
* algorithm for this dependency, to a bean instance from the given factory.
* <p>The default implementation calls {@link BeanFactory#getBean(String)}.
* Subclasses may provide additional arguments or other customizations.
* @param beanName the bean name, as a candidate result for this dependency
* @param requiredType the expected type of the bean (as an assertion)
* @param beanFactory the associated factory
* @return the bean instance (never {@code null})
* @throws BeansException if the bean could not be obtained
* @since 4.3.2
* @see BeanFactory#getBean(String)
*/
public Object resolveCandidate(String beanName, Class<?> requiredType, BeanFactory beanFactory)
throws BeansException {
return beanFactory.getBean(beanName);
}
Is there any good reason why beanFactory.getBean
does not use the requiredType
? Especially as there is an overload which accepts a Class
.
I think one should fix this or explain why we don't want to use it
Comment From: snicoll
The beanName
is an identifier on its own. There are three hints in the Javadoc you've pasted:
Resolve the specified bean name
The default implementation calls {@link BeanFactory#getBean(String)}. Subclasses may provide additional arguments or other customizations.
And
@param requiredType the expected type of the bean (as an assertion)
In short, this method is resolving a dependency based on its bean name. The type is provided as an additional argument that subclass may or may not use but it isn't necessary as the bean name itself is enough to resolve the dependency. As it returns Object
, there is no guarantee on the type either.
If you have further questions, please follow-up on StackOverflow. As mentioned in the guidelines for contributing, we prefer to use the issue tracker only for bugs and enhancements.