GH-3376: Remove gauges on application ctx close

[artembilan]

Fixes #3376

The MeterRegistry may request meters on application shutdown.
The gauges for channels, handlers and message sources don't make sense
at the moment since all those beans are going to be destroyed.

• Remove gauges for channel, handler and message source numbers from the
  IntegrationManagementConfigurer.destroy()

Cherry-pick to 5.3.x & 5.2.x

[wilkinsona]

Is there an existing relationship between beans that will ensure that IntegrationManagementConfigurer is disposed before the Micrometer MeterRegistry? I couldn't spot anything but I'm not too familiar with the code so may well have missed something.

[artembilan]

@wilkinsona ,

thank you for feedback!

So, let's see together what we have so far!

Since Micrometer is an optional dependency we can't make a hard class reference into that MeterRegistry everywhere we need metrics to expose. So, we have introduced a facade in front of it as a MetricsCaptor.
The further logic is like this then in the IntegrationManagementConfigurer:

public void afterSingletonsInstantiated() {
	Assert.state(this.applicationContext != null, "'applicationContext' must not be null");
	Assert.state(MANAGEMENT_CONFIGURER_NAME.equals(this.beanName), getClass().getSimpleName()
			+ " bean name must be " + MANAGEMENT_CONFIGURER_NAME);
	if (ClassUtils.isPresent("io.micrometer.core.instrument.MeterRegistry",
			this.applicationContext.getClassLoader())) {
		this.metricsCaptor = MicrometerMetricsCaptor.loadCaptor(this.applicationContext);
	}

And already that MicrometerMetricsCaptor.loadCaptor() does this:

MeterRegistry registry = applicationContext.getBean(MeterRegistry.class);

So, I think according your requirement there is no such a dependency injection relationship between IntegrationManagementConfigurer and MeterRegistry.

Maybe we should think about applying @Conditional on the inner Micrometer-specific @Configuration instead and then have an optional injection into the IntegrationManagementConfigurer bean definitiont. See an IntegrationManagementConfiguration.

Thanks again

[artembilan]

@wilkinsona ,

any further feedback, please?

We probably need to see how this can make it into the upcoming release this Wednesday.

Thanks

[wilkinsona]

I wonder if you could use a BeanFactoryPostProcessor or ImportBeanDefinitionRegistrar to register the MetricsCaptor implementation when Micrometer is on the classpath. It would be configured to depend on the MeterRegistry and could then be injected into IntegrationManagementConfigurer using an ObjectProvider so that it can be optional. This injection should then result in IntegrationManagementConfigurer being destroyed before the MeterRegistry.

[artembilan]

OK. I have added a MicrometerMetricsCaptorRegistrar implements ImportBeanDefinitionRegistrar to satisfy dependency tree.

Please, take a look how is this now, @wilkinsona .

Thank you!

[wilkinsona]

With the caveat that I haven't tried to run the code, those changes look good to me now.

[artembilan]

Back-ported to 5.3.x as d0cab67 after fixing some conflicts.

Back-ported to 5.2.x as a2a8764 with more conflict resolutions.