Skip to content
This repository has been archived by the owner on Feb 23, 2023. It is now read-only.

Bean definition extending FactoryBean with generics is not injected #1022

Closed
bclozel opened this issue Sep 10, 2021 · 2 comments
Closed

Bean definition extending FactoryBean with generics is not injected #1022

bclozel opened this issue Sep 10, 2021 · 2 comments
Assignees
Labels
status: superseded An issue that has been superseded by another

Comments

@bclozel
Copy link
Contributor

bclozel commented Sep 10, 2021

This problem can be seen with the hateoas and data-rest samples currently.
They're both contributing PluginRegistry<T,S> beans through PluginRegistryFactoryBean<T,S> declared as bean definitions.

Samples fails with the following:

org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No qualifying bean of type 'org.springframework.plugin.core.PluginRegistry<org.springframework.hateoas.server.LinkRelationProvider, 
org.springframework.hateoas.server.LinkRelationProvider$LookupContext>' available:
expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

While debugging the issue, we've found that the current code generation process 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);

Declaring the FactoryBean type as the ResolvableType target type in the definition 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 tweaking the targetType to represent the actual type produced by the FactoryBean fixes the issue, but this might not be in line with the expected API usage. This should be discussed in a Spring Framework issue (to be linked here).

@bclozel bclozel added theme: aot status: blocked An issue that's blocked on an external project change or another issue labels Sep 10, 2021
@bclozel bclozel added this to the 0.11.0 milestone Sep 10, 2021
@bclozel bclozel self-assigned this Sep 10, 2021
@bclozel
Copy link
Contributor Author

bclozel commented Sep 10, 2021

Blocked until spring-projects/spring-framework#27383 is triaged.

@snicoll
Copy link
Contributor

snicoll commented Sep 14, 2021

Closing in favor of #1030

@snicoll snicoll closed this as completed Sep 14, 2021
@snicoll snicoll added status: superseded An issue that has been superseded by another and removed status: blocked An issue that's blocked on an external project change or another issue labels Sep 14, 2021
@snicoll snicoll removed this from the 0.11.0 milestone Sep 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: superseded An issue that has been superseded by another
Development

No branches or pull requests

2 participants