-
Notifications
You must be signed in to change notification settings - Fork 38.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bean definition extending FactoryBean with generics is not injected #27383
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
status: duplicate
A duplicate of another issue
type: enhancement
A general enhancement
Comments
bclozel
added
the
status: waiting-for-triage
An issue we've not yet triaged or decided on
label
Sep 10, 2021
Closing in favor of spring-attic/spring-native#1030 |
bclozel
added
status: declined
A suggestion or change that we don't feel we should currently apply
and removed
status: waiting-for-triage
An issue we've not yet triaged or decided on
labels
Sep 14, 2021
snicoll
added
type: bug
A general bug
status: waiting-for-triage
An issue we've not yet triaged or decided on
and removed
status: declined
A suggestion or change that we don't feel we should currently apply
labels
Sep 15, 2021
Discussing this topic further, we'd still like to experiment how we can check the |
The following bean definition fails to inject the plugin registry: BeanDefinitionRegistrar.of("relProviderPluginRegistry", ResolvableType.forClassWithGenerics(PluginRegistryFactoryBean.class, LinkRelationProvider.class, LinkRelationProvider.LookupContext.class)).withFactoryMethod(HateoasConfiguration.class, "relProviderPluginRegistry")
.instanceSupplier(() -> context.getBean(HateoasConfiguration.class).relProviderPluginRegistry()).register(context); If we move the target type to the actual type produced by the BeanDefinitionRegistrar.of("relProviderPluginRegistry", ResolvableType.forClassWithGenerics(PluginRegistry.class, LinkRelationProvider.class, LinkRelationProvider.LookupContext.class)).withFactoryMethod(HateoasConfiguration.class, "relProviderPluginRegistry")
.instanceSupplier(() -> context.getBean(HateoasConfiguration.class).relProviderPluginRegistry()).register(context); |
rstoyanchev
added
the
in: core
Issues in core modules (aop, beans, core, context, expression)
label
Nov 11, 2021
jhoeller
added
type: enhancement
A general enhancement
and removed
status: waiting-for-triage
An issue we've not yet triaged or decided on
type: bug
A general bug
labels
Dec 29, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
status: duplicate
A duplicate of another issue
type: enhancement
A general enhancement
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 typePluginRegistry<T,S>
and is contributed through aPluginRegistryFactoryBean<T,S>
(withT
andS
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:
The important part is that we're declaring the
PluginRegistryFactoryBean
type as theResolvableType
target type in the definition; this seems to confuse the core container in theorg.springframework.beans.factory.support.DefaultListableBeanFactory#doResolveDependency
and especially theorg.springframework.beans.factory.support.DefaultListableBeanFactory#findAutowireCandidates
sequence. Instead of considering the generic type of the bean produced by theFactoryBean
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.
The text was updated successfully, but these errors were encountered: