Skip to content
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

Provide registerBean variants based on ResolvableType [SPR-15197] #18463

Open
spring-projects-issues opened this issue Jan 27, 2017 · 5 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jan 27, 2017

Phil Webb opened SPR-15197 and commented

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

//---------------------------------------------------------------------
// 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:

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jan 27, 2017

Phil Webb commented

Also having a FunctionalBeanRegistry interface might be nice.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jan 27, 2017

Phil Webb commented

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

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 9, 2017

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
Copy link
Collaborator Author

spring-projects-issues commented Jul 5, 2018

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
Copy link
Collaborator Author

spring-projects-issues commented Jul 10, 2018

Juergen Hoeller commented

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

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) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant