Provide registerBean variants based on ResolvableType [SPR-15197]

[spring-projects-issues]

Phil Webb opened SPR-15197 and commented

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

spring-framework/spring-context/src/main/java/org/springframework/context/support/GenericApplicationContext.java

Lines 357 to 416 in cb0d992

	//---------------------------------------------------------------------
	// Convenient methods for registering individual beans
	//---------------------------------------------------------------------
	/**
	* Register a bean from the given bean class, optionally customizing its
	* bean definition metadata (typically declared as a lambda expression
	* or method reference).
	* @param beanClass the class of the bean
	* @param customizers one or more callbacks for customizing the
	* factory's {@link BeanDefinition}, e.g. setting a lazy-init or primary flag
	* @since 5.0
	*/
	public <T> void registerBean(Class<T> beanClass, BeanDefinitionCustomizer... customizers) {
	registerBean(null, beanClass, null, customizers);
	}
	/**
	* Register a bean from the given bean class, using the given supplier for
	* obtaining a new instance (typically declared as a lambda expression or
	* method reference), optionally customizing its bean definition metadata
	* (again typically declared as a lambda expression or method reference).
	* @param beanName the name of the bean (may be {@code null})
	* @param beanClass the class of the bean
	* @param customizers one or more callbacks for customizing the
	* factory's {@link BeanDefinition}, e.g. setting a lazy-init or primary flag
	* @since 5.0
	*/
	public <T> void registerBean(String beanName, Class<T> beanClass, BeanDefinitionCustomizer... customizers) {
	registerBean(beanName, beanClass, null, customizers);
	}
	/**
	* Register a bean from the given bean class, using the given supplier for
	* obtaining a new instance (typically declared as a lambda expression or
	* method reference), optionally customizing its bean definition metadata
	* (again typically declared as a lambda expression or method reference).
	* @param beanClass the class of the bean
	* @param supplier a callback for creating an instance of the bean
	* @param customizers one or more callbacks for customizing the
	* factory's {@link BeanDefinition}, e.g. setting a lazy-init or primary flag
	* @since 5.0
	*/
	public <T> void registerBean(Class<T> beanClass, Supplier<T> supplier, BeanDefinitionCustomizer... customizers) {
	registerBean(null, beanClass, supplier, customizers);
	}
	/**
	* Register a bean from the given bean class, using the given supplier for
	* obtaining a new instance (typically declared as a lambda expression or
	* method reference), optionally customizing its bean definition metadata
	* (again typically declared as a lambda expression or method reference).
	* @param beanName the name of the bean (may be {@code null})
	* @param beanClass the class of the bean
	* @param supplier a callback for creating an instance of the bean
	* @param customizers one or more callbacks for customizing the
	* factory's {@link BeanDefinition}, e.g. setting a lazy-init or primary flag
	* @since 5.0
	*/
	public <T> void registerBean(String beanName, Class<T> beanClass, Supplier<T> supplier,

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:

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

0 votes, 5 watchers

[spring-projects-issues]

Phil Webb commented

Also having a FunctionalBeanRegistry interface might be nice.

[spring-projects-issues]

Phil Webb commented

See spring-projects/spring-boot#8115 for some discussion around registering beans functional style with Boot.

[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.

[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.

[spring-projects-issues]

Juergen Hoeller commented

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