Phil Webb opened SPR-15197 and commented

The current registerBean methods added to support functional registration take a beanType class.

https://github.com/spring-projects/spring-framework/blob/cb0d992303213c42403e7c0f2da6253d889b1e37/spring-context/src/main/java/org/springframework/context/support/GenericApplicationContext.java#L357-L416

I have a feeling that we may need to register beans that include generics. e.g.

Repository<Foo> fooRepository = SomeThing.makeSomeFoo();
context.registerBean(..., fooRepository, ...);

Perhaps we should also offer registerBean variants that take a ResolvableType.

Affects: 5.0 M4

Issue Links: - #18353 Programmatic bean registration within configuration classes - #19398 Add a functional way to register a bean - #19149 Allow programmatic registration of bean definitions with a ResolvableType - #19578 getBeanNamesForType(ResolvableType) doesn't match generic factory method return type for yet-to-be-created bean - #21566 Publicly expose ResolvableType in RootBeanDefinition

0 votes, 5 watchers

Comment From: spring-projects-issues

Phil Webb commented

Also having a FunctionalBeanRegistry interface might be nice.

Comment From: spring-projects-issues

Phil Webb commented

See https://github.com/spring-projects/spring-boot/issues/8115 for some discussion around registering beans functional style with Boot.

Comment From: spring-projects-issues

Juergen Hoeller commented

Playing with this for a bit, I don't see common enough use cases for convenience methods there. Also, since we only support such generic type hints outside of the bean class itself through RootBeanDefinition.setTargetType, this is semantically not quite the same thing as the Class based variants that we have on GenericApplicationContext already.

Technically, such an arrangement can be accomplished rather easily already: Create a RootBeanDefinition, populate its setTargetType plus setBeanClass and/or setInstanceSupplier, and register it via registerBeanDefinition.

Comment From: spring-projects-issues

Dave Syer commented

The workaround with RootBeanDefinition is fine for regular autowiring use cases, but it doesn't expose the ResolvableType to any public API that could be used to inspect the BeanDefinition to extract the generic type information. In Spring Cloud Function we have cases where we need to do that and I expect Spring Data does as well (user declares a bean of a specific type and we need the generic type information). We could fix that simply by adding a new public method to RootBeanDefinition I guess, and then leave it up to framework providers to make the registration and inspection friendlier.

For instance, in Spring Cloud Function, the user would like to be able to register a Function like this:

context.registerBean(ResolvableType.forClassWithGenerics(Function.class, String.class, Foo.class),
  () -> function());

...

public Function<String, Foo> function() {
  return value -> new Foo(value);
}

We can support that if the function() method is a @Bean right now, but not the functional variation.

Comment From: spring-projects-issues

Juergen Hoeller commented

Putting this one into the backlog in favor of #21566, as per Dave's comment.