Description
See spring-attic/spring-native#1022 for background.
While working on spring-native, we've found a behavior that might be a bug in the core container support for the functional registration of beans (through instance suppliers).
Some of our samples are failing with org.springframework.beans.factory.NoSuchBeanDefinitionException. The missing bean is of type PluginRegistry<T,S> and is contributed through a PluginRegistryFactoryBean<T,S> (with T and S being concrete types: 'org.springframework.plugin.core.PluginRegistry<org.springframework.hateoas.server.LinkRelationProvider,
org.springframework.hateoas.server.LinkRelationProvider$LookupContext>').
While debugging the issue, we've found that the current code generation process in spring-native contributes that definition to the context with:
BeanDefinitionRegistrar.of("relProviderPluginRegistry", ResolvableType.forClassWithGenerics(PluginRegistryFactoryBean.class, LinkRelationProvider.class, LinkRelationProvider.LookupContext.class)).withFactoryMethod(HateoasConfiguration.class, "relProviderPluginRegistry")
.instanceSupplier(() -> context.getBean(HateoasConfiguration.class).relProviderPluginRegistry()).register(context);The important part is that we're declaring the PluginRegistryFactoryBean type as the ResolvableType target type in the definition; this seems to confuse the core container in the org.springframework.beans.factory.support.DefaultListableBeanFactory#doResolveDependency and especially the org.springframework.beans.factory.support.DefaultListableBeanFactory#findAutowireCandidates sequence. Instead of considering the generic type of the bean produced by the FactoryBean and if it's assignable to the required type for the injection point, this seems to only consider the provided target type.
This might be linked with the fact that we're heavily using the instanceSupplier mechanism instead of factory methods.
We've validated that providing the type produced by the Factory directly as the target ResolvableType (so 'PluginRegistry<LinkRelationProvider, LookupContext>' instead of 'PluginRegistryFactoryBean<LinkRelationProvider, LookupContext>' solves the issue.
We need to consider this case and know whether this behavior is expected or if this shows a problem with the current suport of instance suppliers.