INT-4544: Allow runtime MBeans (un)registered #2601
Conversation
JIRA: https://jira.spring.io/browse/INT-4544 * Fix `SourcePollingChannelAdapterFactoryBean` to register an `outputChannelName` into the `SourcePollingChannelAdapter` for late binding, especially in case of dynamic `IntegrationFlow` registrations. This must be back-ported to `5.0.x` * Implement `DestructionAwareBeanPostProcessor` in the `IntegrationMBeanExporter` for the runtime beans tracking, e.g. via dynamic `IntegrationFlow` registrations * Refactor `IntegrationMBeanExporter` for static and dynamic beans registration and destruction * Remove unused properties; introduce some new for tracking beans and their relationship
| @@ -300,6 +306,93 @@ public void afterSingletonsInstantiated() { | |||
|
|
|||
| } | |||
|
|
|||
| private void registerProducer(MessageProducer messageProducer) { | |||
There was a problem hiding this comment.
Should be below the next method.
There was a problem hiding this comment.
It is called from the afterSingletonsInstantiated() first time, so this is normal order for the private methods.
There was a problem hiding this comment.
But it's also called from postProcessAfterInitialization(). I believe the rule is called methods should always be below the last place that calls it.
There was a problem hiding this comment.
Fine with me, but I've followed this rule so far: https://github.com/spring-projects/spring-framework/wiki/Code-Style#java-source-file-organization
Note that private or protected methods called from method implementations should be placed immediately below the methods where they're used. In other words if there 3 interface method implementations with 3 private methods (one used from each), then the order of methods should include 1 interface and 1 private method in sequence, not 3 interface and then 3 private methods at the bottom.
There was a problem hiding this comment.
Maybe it's just my interpretation then; I guess those guidelines don't specifically address this use case.
There was a problem hiding this comment.
OK. Fine with me.
Will fix. 😄
Not sure though, what happened to the org.springframework.integration.monitor.MessageSourceTests on Travis...
`postProcessAfterInitialization()` * Refactor JMX test configurations to reuse MBeanServer as much as possible and destroy the server whenever it is necessary
|
Looks like there are still test issues (instance already exists exceptions). |
|
Yeah... Looks like MBean Server is not closed somewhere yet... |
|
|
||
| @Override | ||
| public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { | ||
| if (this.singletonsInstantiated) { |
There was a problem hiding this comment.
Since we are already at RC, perhaps we should add a try {...} catch {...} under here to fail soft (and log an error) instead of failing hard (just in case there are any regression issues) ?
…ialization()` to avoid breaking changes for the current GA phase * Do not unregister those MBeans explicitly which weren't created at runtime
* Do not use a cst in the `StandardIntegrationFlowContext` for `BeanFactory`, but an explicit `BeanDefinitionRegistry` * Extract targets from proxies in the `IntegrationMBeanExporter.postProcessAfterInitialization()` * Remove logging in the `MBeanExporterIntegrationTests`
similar in the `foo` in the `MessageSourceTests` * Use `MBeanServer` bean in the `Int2307Tests` * Use JUnit 5ctor injection injection in the `MessageMetricsAdviceTests`
on the server provided by the managed `MBeanServerFactoryBean` which destroys a server on application context close * Fix `StoredProcJmxManagedBeanTests-context.xml` to use `MBeanServer` from the `<context:mbean-server>`
|
OK! Finally it is green 😄 Sorry for the mess in tests. Note: When we configure runtime beans, we don't process plain |
Separate PR? |
JIRA: https://jira.spring.io/browse/INT-4544
SourcePollingChannelAdapterFactoryBeanto register anoutputChannelNameinto theSourcePollingChannelAdapterfor latebinding, especially in case of dynamic
IntegrationFlowregistrations.This must be back-ported to
5.0.xDestructionAwareBeanPostProcessorin theIntegrationMBeanExporterfor the runtime beans tracking, e.g. viadynamic
IntegrationFlowregistrationsIntegrationMBeanExporterfor static and dynamic beansregistration and destruction
their relationship