`@EnableIntegrationMBeanExport` can't override the auto-config, because of wrong order of classes processing

[artembilan]

The sample is based on Spring Integration:

@Configuration
@EnableAutoConfiguration
@EnableIntegrationMBeanExport(defaultDomain = "foo.my")
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args).close();
    }
}

The Boot logs show:

o.s.i.monitor.IntegrationMBeanExporter   : Located managed bean 'org.springframework.integration:type=MessageChannel,name=nullChannel': registering with JMX server as MBean [org.springframework.integration:type=MessageChannel,name=nullChannel]

However the test-case passes:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Application.class)
public class ApplicationTests {

    @Autowired
    private IntegrationMBeanExporter integrationMBeanExporter;

    @Test
    public void contextLoads() {
        DirectFieldAccessor dfa = new DirectFieldAccessor(integrationMBeanExporter);
        assertEquals("foo.my", dfa.getPropertyValue("domain"));
    }

}

Reproducible on Boot 1.1.5.

Not sure what's going on, but it looks like @Conditional...s and any auto-config have to be appliend only after after any other custom configs and explicit @Enable... usage.

Suppose the same issue we have with any ...AutoConfiguration which is based on @Enable...

BTW, the same result I see, if I explicitly define:

@Bean
public IntegrationMBeanExporter mbeanExporter(MBeanServer mbeanServer) {
        IntegrationMBeanExporter exporter = new IntegrationMBeanExporter();
        exporter.setDefaultDomain("foo.my");
        exporter.setServer(mbeanServer);
        return exporter;
}

isntead of @EnableIntegrationMBeanExport

[wilkinsona]

This is a tricky one. This test fails:

@Test
public void customJmxDomain() {
    this.context.register(CustomJmxDomainConfiguration.class,
            JmxAutoConfiguration.class, IntegrationAutoConfiguration.class);
    this.context.refresh();
    IntegrationMBeanExporter mbeanExporter = this.context
            .getBean(IntegrationMBeanExporter.class);
    DirectFieldAccessor dfa = new DirectFieldAccessor(mbeanExporter);
    assertEquals("foo.my", dfa.getPropertyValue("domain"));
}

@Configuration
@EnableIntegrationMBeanExport(defaultDomain = "foo.my")
public static class CustomJmxDomainConfiguration {

}

EnableIntegrationMBeanExportConfiguration is imported by two classes: CustomJmxDomainConfiguration and IntegrationAutoConfiguration.IntegrationJmxConfiguration. The latter is annotated with @ConditionalOnMissingBean(IntegrationMBeanExporter.class) and when this condition is evaluated the IntegrationMBeanExporter bean created via CustomJmxConfiguration is found so the configuration class is skipped. However, it's still remembered as an importer of IntegrationMBeanExporterConfiguration. When Spring calls IntegrationMBeanExporterConfiguration.setImportMetadata it passes in the metadata from IntegrationAutoConfiguration.IntegrationJmxConfiguration rather than the metadata from CustomJmxDomainConfiguration.

A change was made in Spring 4.0.5 to improve handling of multiple imports in response to this issue (that was raised by me). It looks like the logic needs to be further enhanced so that, if possible, it applies the correct import metadata.

[artembilan]

Thanks Andy!
So, let's move this issue to SF for the second attempt! 😄

[artembilan]

The linked SF issue: https://jira.spring.io/browse/SPR-12128

[artembilan]

Hi @wilkinsona !
Looks like the issue is fixed in SF 4.1. So we can just close this or, of course, confirm it with tests commit.

Your position?
However it works only with SF 4.1. When is Boot going to move to SF 4.1 ?

[snicoll]

Boot 1.2 is on Spring 4.1 already.

[wilkinsona]

@artembilan I plan to commit the test that I have into master (Boot 1.2) so that we can be sure that this doesn't regress

[jhoeller]

BTW, as already discussed with Phil, I would strongly prefer an early Boot 1.2 release that catches up with Spring Framework 4.1. In particular Boot should not lag behind too long here, otherwise our new release strategy with shorter framework release cycles won't work out and we'll be stuck in backporting hell forever.