INT-4517: Refactor beans in IntegrationRegistrar #2537
Conversation
| if (!registry.containsBeanDefinition(INTEGRATION_FLOW_BPP_BEAN_NAME)) { | ||
| registry.registerBeanDefinition(INTEGRATION_FLOW_BPP_BEAN_NAME, | ||
| new RootBeanDefinition(IntegrationFlowBeanPostProcessor.class)); | ||
| registry.registerBeanDefinition(INTEGRATION_FLOW_CONTEXT_BEAN_NAME, | ||
| new RootBeanDefinition(StandardIntegrationFlowContext.class)); | ||
| } | ||
|
|
||
| if (!configurableListableBeanFactory.containsBean(INTEGRATION_FLOW_REPLY_PRODUCER_CLEANER_BEAN_NAME)) { |
There was a problem hiding this comment.
Wouldn't this be a problem if the child context is loaded by a different class loader?
There was a problem hiding this comment.
Gary, do you mean that IntegrationFlowDefinition is going to be loaded one more time in the child context when it uses its own class loaded?
Then indeed that private static final Set<MessageProducer> REFERENCED_REPLY_PRODUCERS = new HashSet<>(); store is going to be a fresh in that class loaded...
But I'm not so good in such a low level of JVM.
So, please, confirm how it is going and I'll change respectively or let's leave it as is!
Thanks
There was a problem hiding this comment.
Yes, that's what I meant; it's unlikely because, normally, class loaders are hierarchical and the child loader will find the existing class instance in the parent loader.
However, it's possible, so the question is whether saving an extra bean in the child context is worth the risk of a memory leak; but I think the risk is very small - weird class loaders combined with a lot of dynamic flow recycling, so I really don't mind either way - I just thought it was worth raising.
There was a problem hiding this comment.
Just reverted that change.
Thank you for clarification!
JIRA: https://jira.spring.io/browse/INT-4517 The `IntegrationRegistrar` populates beans into the application context too early and when the `allowBeanDefinitionsOverride` is disabled we end up with the `BeanDefinitionOverrideException` just because end-user beans are applied later. * Move most of the bean definitions which can be overridden in the target application from the `IntegrationRegistrar` into the `DefaultConfiguringBeanFactoryPostProcessor` * Revise their registration logic to be sure that some of them are registered only once in the parent context nad others are registered in the child context as well * Refactor a `DslIntegrationConfigurationInitializer` do not register an `IntegrationFlowDefinition.ReplyProducerCleaner` in the child context one more time: it doesn't bring any local store within the current child context * Introduce a `NoBeansOverrideAnnotationConfigContextLoader` in tests to ensure that in some test-cases we disallow an `allowBeanDefinitionsOverride` as it is now in Spring Boot since it is enabled by default in the Spring Framework
Regsiter all the required infrastructure beans in all the application contexts to avoid class loader issue for `static` store access
JIRA: https://jira.spring.io/browse/INT-4517
The
IntegrationRegistrarpopulates beans into the application contexttoo early and when the
allowBeanDefinitionsOverrideis disabled weend up with the
BeanDefinitionOverrideExceptionjust because end-userbeans are applied later.
application from the
IntegrationRegistrarinto theDefaultConfiguringBeanFactoryPostProcessorregistered only once in the parent context nad others are registered
in the child context as well
DslIntegrationConfigurationInitializerdo not registeran
IntegrationFlowDefinition.ReplyProducerCleanerin the child contextone more time: it doesn't bring any local store within the current
child context
NoBeansOverrideAnnotationConfigContextLoaderin teststo ensure that in some test-cases we disallow an
allowBeanDefinitionsOverrideas it is now in Spring Boot since it isenabled by default in the Spring Framework