Add support for FactoryBean that specify the target type using FactoryBean.OBJECT_TYPE_ATTRIBUTE

[artembilan]

There are some use-cases when FactoryBean target type cannot be determined from generics or some other info during beanFactory.resolveDependency().
For this purpose we rely on the FactoryBean.OBJECT_TYPE_ATTRIBUTE attribute setting on BeanDefinition.
Such an attribute should be copied to the target generated code.
This way we won't need to develop our own simple BeanRegistrationWriter just for a sake of this attribute carrying on.

[snicoll]

I didn't see this issue and commented on the PR instead #1172 (comment)

Let's keep the conversation here please. I'd like to understand what bean definitions in Spring Integration require this.

[artembilan]

See the related issue: #1030.

Perhaps that one is more generic than this one, so it might be considered as duplication.

For more context.

Spring Integration has a @MessagingGateway interfaces parsing. This is done by the GatewayProxyFactoryBean, which does know the target type even during bean definition. See its ctor:

public GatewayProxyFactoryBean(Class<?> serviceInterface) {

But anyway this info is not available during autowiring. See the IntegrationApplication as a sample:

@Bean
public IntegrationFlow controlBusControllerFlow(ControlBusGateway controlBusGateway) {
   ...
}

Where that ControlBusGateway is like this:

@MessagingGateway(defaultRequestChannel = "controlBus.input")
public interface ControlBusGateway {
   ...
}

Spring Integration scans for that interface and expose a GatewayProxyFactoryBean.
The mentioned FactoryBean.OBJECT_TYPE_ATTRIBUTE is used then when this interface type is resolved for the autowiring into that bean method argument.

Probably using a setBeanClass() instead is not a way: we won't be able to autowire the whole GatewayProxyFactoryBean in the end since its type is lost.

[snicoll]

Thanks for the additional feedback. I don't think exposing the factory type in the generated code is the right way to fix this. After all, we have at build time a complete overview of the bean definitions and their state so we should be able to write back something that represents the correct state of the application context without relying on the context to do extra hops for us.

I've been investigating a few options but they all have drawbacks. I'll investigate some more this week.

[artembilan]

Yes, I also had the same doubt about such an extra type info which is really available for us at build time.
And I have just confirmed with tests in Spring Integration that RootBeanDefinition.setTargetType() works for me for all the use-cases.
Only the problem that Spring Native does not carry that info into a generated BeanDefinition, so, I still cannot run Spring Integration properly on AOT.

Thanks

[snicoll]

I changed my mind and I added a dedicated writer for the case of a FactoryBean whose target type is not defined upfront but via the attribute. It does some additional checks to verify that the attribute is compatible with the bounds of the factory bean.