I'm not super clear on the difference between beanClass
and targetType
in a BeanDefinition
, but if I do this:
context.registerBean("foo", Foo.class, () -> new Foo());
I think it's pretty clear that the type of the bean is Foo
. But Spring only sets the beanClass
and not the targetType
. It actually only hardly ever causes issues, but maybe the intent would be more clearly encapsulated if the bean definition was created with its target type already resolved?
Comment From: dsyer
I suppose I might want to be able to do this
context.registerBean("foo", FooFactoryBean.class, () -> new FooFactoryBean());
and have the target type resolved through the FooFactoryBean
. That might be why it is the way it is right now, but probably the registerBean()
method will know that the bean is a factory bean, so it can decide what to do without me having to add a customizer.
Comment From: sdeleuze
Hey Dave, based on @jhoeller insights, targetType
is meant to carry type information beyond the bean class itself (generics). If not explicitly set, we derive the type information from the bean class / factory method return type / FactoryBean declaration etc.
We differentiate between user-set type information and internally derived type information in a few places, that's why we're not setting that particular field ourselves there. This shouldn't make a difference in terms of actual type handling at runtime.
Using FactoryBeans is possible but maybe not a first class use case with functional bean registration.
Could you share more about your use case(s)? Maybe spring-init
related?
The point you raise also make me wondering if we should set targetType
in Kotlin registerBean<Foo>(...)
extensions since we do have the required information to build it.
Comment From: sdeleuze
Closing due to lack of feedback.