Spring Integration gateways don't trigger @ConditionalOnBean #2811
Comments
|
|
philwebb
added
the
status: waiting-for-feedback
|
I'll try to figure out a minimal reproduction. |
I've very much noticed this, and it's especially glaring when the autoconfiguration report shows negative matches with matching beans. I know the dependency algorithms are hairy, but is there any likelihood of a refactor that will reduce the ordering gotchas, or is that performance-prohibitive? Example turning on |
|
Reproduction here: https://github.com/chrylis/spring-boot-2811 I have an autoconfig class providing a bean through Spring Integration that explicitly indicates configuration before the class with the condition on that bean. Condition doesn't match, the second autoconfiguration doesn't activate, and its bean definitions don't get registered. Flipping on a profile that registers a second matching bean causes the condition to match and then throws on duplicate bean. (Commenting out the condition makes everything resolve and work correctly.) |
wilkinsona
removed
the
status: waiting-for-feedback
|
Thanks for the reproduction. At the time that the A workaround is to change the condition to match the bean by name: |
|
The |
|
I'm not sure why we aren't calling |
|
In this specific instance, should Spring Integration be setting the |
|
I discussed that with @garyrussell and @artembilan earlier today and they're happy to make that change if necessary. However, it'd only be a fix for this specific scenario. Calling |
|
I'm not familiar enough with the internals of bean-providing classes to know, but what I'm asking is whether setting that attribute is just incidentally helpful or the Right Thing that ought to happen anyway. |
|
It entirely depends on whether or not we update Boot to call |
|
Unfortunately we can't call
I can't really see what we can do to improve the situation unfortunately. The general rule that we use internally is |
|
|
If the file has been imported in an auto-configuration, yes. |
|
What this all seems like to me is that the namespace handler for |
|
|
To allow us to determine the type that Spring Integration’s GatewayProxyFactoryBean will create, the bean definition created by MessagingGatewayRegistrar needs to set the factoryBeanObjectType attribute. The current implementation of BeanTypeRegistry requires the attribute’s value to be a Class, however this would require Spring Integration’s namespace handler to load the class and class loading should be avoided in namespace handlers. This commit updates BeanTypeRegistry so that it supports both Class and String values for the factoryBeanObjectType. If the value is a String it will interpret it as a class name and attempt to load it. See gh-2811
|
Note that the solution of populating the hint in the bean definition attribute will only work as long as the Perhaps code could be added to |
|
Spring Integration 4.1.4 has been released so we can complete the fix for this by upgrading |
To allow us to determine the type that Spring Integration’s GatewayProxyFactoryBean will create, the bean definition created by MessagingGatewayRegistrar needs to set the factoryBeanObjectType attribute. The current implementation of BeanTypeRegistry requires the attribute’s value to be a Class, however this would require Spring Integration’s namespace handler to load the class and class loading should be avoided in namespace handlers. This commit updates BeanTypeRegistry so that it supports both Class and String values for the factoryBeanObjectType. If the value is a String it will interpret it as a class name and attempt to load it. See spring-projectsgh-2811
|
After defining both beans like below it works. But do we have some other good solution. |
|
@akibandali I can't see the connection between |
|
@wilkinsona - Yes I will open a case. |
I have an MVC controller bean that's conditional on the registration of a bean implementing a handler interface. I'm using a Spring Integration service gateway to implement the interface and importing an XML integration plan in my own autoconfiguration class, and the debug log shows
very early in the loading process, but the condition does not see the service gateway as a matching bean. I have explicitly listed my application's configuration as
@AutoConfigureBeforethe class that needs the bean, but it still doesn't match. Using@DependsOnand explicitly supplying a bean ID for the gateway also does not work.The text was updated successfully, but these errors were encountered: