Enabling configuration properties scanning by default prevents conditional registration of @ConfigurationProperties-annoted types that are found by scanning

[chengchen]

Hello,

We were trying to migrate from 2.1.9 to 2.2.0 for our applications last week and encountered a startup failure due to a configuration validation failure. In short, if we are using @EnableConfigurationProperties combined with @ConditionalOnProperty for some beans, the new version is not respecting the conditional on the config part.

Here is a tiny example:

If we add this component to any Spring Boot application, it will fail to start with 2.2.0.

@Component
@ConditionalOnProperty(prefix = "foo", name = "enabled")
@EnableConfigurationProperties(FooBarConfig.class)
public class FooBar {

    public FooBar() {
        Logger.getGlobal().info("Starting FooBar...");
    }

    @ConfigurationProperties(prefix = "foo")
    @Validated
    static class FooBarConfig {

        @NotNull
        String bar;

        public void setBar(String bar) {
            this.bar = bar;
        }

    }

}

Expected behavior:
The bean initialization of FooBar and FooBarConfig should be skipped because @ConditionalOnProperty doesn't match.

Actual behavior:
FooBar is skipped but the FooBarConfig keeps initializing thus failed startup.

[snicoll]

I understand that FooBar is in a package that is a target of component scan given the @Component on it. Spring Boot 2.2 now scans @ConfigurationProperties automatically and that arrangement above is really two separate components (i.e. excluding the parent doesn't mean that the inner class should not be scanned).

If you want to conditionally create such bean, you shouldn't put them in a package that is target for classpath scanning (auto-configurations shouldn't use package scanning in the first place). If you EnableConfigurationProperties(FooBar.class) from your auto-configuration, things should work fine in both versions.

This is based on partial code snippet so I might be missing something. Does that make sense?

[chengchen]

@snicoll Thanks for the quick explanations. I see what you meant and I just noticed this on the upgrade instructions:

Classes annotated with @ConfigurationProperties can now be found via classpath scanning as an alternative to using @EnableConfigurationProperties or @component. If you use @SpringBootApplication, scanning is enabled by default for the package that contains the @SpringBootApplication-annotated class.

We wanted to put the our service bean together with its configuration, and use @EnableConfigurationProperties to conditional switch on/off the bean initialization in a consistent way.

[snicoll]

We wanted to put the our service bean together with its configuration, and use @EnableConfigurationProperties to conditional switch on/off the bean initialization in a consistent way.

And that's a perfectly reasonable thing to do. I can see now how scanning user-config makes it harder. Flagging for team attention to see how we could mitigate this.

[philwebb]

One idea we discussed is adding a @SpringBootApplication(configurationPropertiesScanning=false) option to disable scanning. Another option would be a similar attribute on @ConfigurationProperties.