Allow Spring Boot to determine type created by GatewayProxyFactoryBean #1423
Conversation
Spring Boot's @ConditionalOnBean can be used to activate some configuration when a bean of a particular type is present in the application context. To avoid early initialization, the search for beans is performed without instantiating them, i.e. it relies on the information that's available from the bean's class and its bean definition. This causes a problem with GatewayProxyFactoryBean as its a FactoryBean<Object> so Boot's best guess is that the bean that's produced by the factory will be an Object. For cases where the bean's type signiture does not contain enougn information to determine its type, Boot looks at an attribute, factoryBeanObjectType, on the factory bean's definition. The value of this attribute can be a Class or a String class name. This commit updates MessagingGatewayRegistrar to set the value of factoryBeanObjectType attribute to be the configured service interface for the gateway.
| @@ -163,7 +164,10 @@ else if (StringUtils.hasText(asyncExecutor)) { | |||
|
|
|||
| gatewayProxyBuilder.addConstructorArgValue(serviceInterface); | |||
|
|
|||
| return new BeanDefinitionHolder(gatewayProxyBuilder.getBeanDefinition(), id); | |||
| AbstractBeanDefinition beanDefinition = gatewayProxyBuilder.getBeanDefinition(); | |||
| beanDefinition.addMetadataAttribute(new BeanMetadataAttribute("factoryBeanObjectType", serviceInterface)); | |||
There was a problem hiding this comment.
Perhaps we should open issues against Spring Framework and Spring Boot to move the constant FACTORY_BEAN_OBJECT_TYPE to SF - e.g. to BeanMetadataAttribute.
It's a bit brittle to use a literal here and it is possible that other projects may need similar.
For now, I will move this to a constant within SI during the merge.
I will also address @artembilan 's suggestion about fixing the getObjectType() when the service interface is null.
There was a problem hiding this comment.
On the Boot call yesterday, @philwebb mentioned some of the code moving into Spring Framework. It hasn't happened yet, AFAIK. Hopefully Phil can comment with the latest.
There was a problem hiding this comment.
Note that this solution won't work if the service interface is a property placeholder (rare, perhaps, but possible).
We may just have to live with that, or boot will have to resolve property placeholders in BeanTypeRegistry.determineTypeFromDefinitionAttribute().
There was a problem hiding this comment.
@wilkinsona I was thinking of https://jira.spring.io/browse/SPR-11480
|
With polish: garyrussell@29a6bf5 /cc @artembilan |
|
Guys, nothing to complain about. @garyrussell , be careful with back port to Thank you both |
|
@artembilan - @wilkinsona 's PR is against 4.1.x so it certainly sounds like it's needed in 4.1 I just did my polishing on master hence, the reactor issue - will be sure to verify on backport |
|
Doh. I have missed that from the PR header. |
|
Reverting the change to the |
|
Merged as 2653ce9 and cherry-picked to 4.1.x. |
|
Much appreciated! What will be the minimum release versions required for this to work? |
|
4.1.4; we don't currently have a schedule for its release (we only just released 4.1.3). When do you need it? In the meantime, you can test with 4.1.4.BUILD-SNAPSHOT (from the snapshot repo). |
|
Just to be clear, that's Spring Integration - we'll need to coordinate with the boot guys for a boot version. |
|
I have a library to update when it's ready. I'm keeping the old-style explicit import for now instead of using autoconfiguration. |
This PR fixes the Spring Integration portion of spring-projects/spring-boot#2811. Please see the commit message for further details. I've tested the changes against a Spring Boot 1.2.4 snapshot and confirmed that it resolves the problem.