Skip to content

Allow manually registered bean definitions to specify a generic type to participate in generics qualifier resolution [SPR-13898] #18472

@spring-projects-issues

Description

@spring-projects-issues

Oliver Drotbohm opened SPR-13898 and commented

Currently the qualifier resolution inspecting generics is restricted to either the bean type or the return type of a factory methods (as implemented in GenericTypeAwareAutowireCandidateResolver.checkGenericTypeMatch(…)). However, if you want to register bean definitions for generic types manually (to back an @Enable… annotation for example) there's no way to pass the generics information to the container to prevent ambiguities from happening.

Take this scenario for example. declaring a PluginRegistry of the Spring Plugin library in Java configuration looks like this.

@Configuration
class Config {

  @Bean
  public PluginRegistry<MyPlugin, MyDelimiter> myPluginRegistry(List<? extends MyPlugin> plugins) {
    return OrderAwarePluginRegistry.create(plugins);
  }
}

With a bean definition like this the container considers the generics information returned at the method return type and can disambiguate the registry returned from a PluginRegistry<MyOtherPlugin> defined in the same way.

However, the library also provides a shortcut for this configuration to easily configure multiple registries:

@Configuration
@EnablePluginRegistries({MyPlugin.class, MyOtherPlugin.class})
class Config {}

The annotation implementation is backed by a PluginRegistriesBeanDefinitionRegistrar that registers BeanDefinition instances for each of the plugin types listed. However, it's currently impossible to forward the generics information which is totally available at this point to the container. It would be great if there was a way to predict a ResolvableType instead of a raw Class by some means on the BeanDefinition. Looks like a new method RootBeanDefinition.getResolvableType() could expose either a manually defined one or the one derived from the factory method's return type and thus simplify the check in getReturnTypeForFactoryMethod(…) to the assignability to the DependencyDescriptor.


Issue Links:

Metadata

Metadata

Assignees

Labels

in: coreIssues in core modules (aop, beans, core, context, expression)status: duplicateA duplicate of another issuetype: enhancementA general enhancement

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions