Caution more strongly against using @ComponentScan in auto-configuration

[bcalmac]

Consider two mutually exclusive beans defined in a starter project:

@Component
@ConditionalOnBean(annotation = EnableSomething.class)
public class ZombieBean {
}

@Component
@ConditionalOnMissingBean(ZombieBean.class)
public class AlternateBean {
}

The natural expectation would be that when the application doesn't have @EnableSomething then AlternateBean exists and ZombieBean doesn't. However, in practice neither of them exists.

A project demonstrating the issue can be found at https://github.com/bcalmac/zombie-bean. Run mvn test and it should fail.

What seems to happen is that ZombieBean does not exist, but when @ConditionalOnMissingBean(ZombieBean.class) is evaluated, a ZombieBean exists in some zombie state and the conditional doesn't match.

   ZombieBean:
      Did not match:
         - @ConditionalOnBean (; SearchStrategy: all) did not find any beans annotated with io.github.bcalmac.zombiebean.starter.EnableSomething (OnBeanCondition)

   AlternateBean:
      Did not match:
         - @ConditionalOnMissingBean (types: io.github.bcalmac.zombiebean.starter.ZombieBean; SearchStrategy: all) found beans of type 'io.github.bcalmac.zombiebean.starter.ZombieBean' zombieBean (OnBeanCondition)

There are ways to refactor the auto-configuration and achieve the desired functionality, I'm submitting this primarily to question whether it is in some way an expected behavior.

[wilkinsona]

Thanks for the sample. This looks like a Spring Framework bug to me. Here's what's happening:

1. Configuration class parsing processes MyStarter
2. @ComponentScan is found so ComponentScanAnnotationParser.parse is called
3. It calls ClassPathBeanDefinitionScanner.doScan which unconditionally registers bean definitions for AlternateBean and ZombieBean
4. ConfigurationClass instances are created for AlternateBean and ZombieBean
5. ConfigurationClassPostProcessor calls ConfigurationClassBeanDefinitionReader.loadBeanDefinitions(Set<ConfigurationClass>)
6. loadBeanDefinitionsForConfigurationClass is called for the AlternateBean configuration class. The ZombieBean definition is present so condition evaluation indicates that it should be skipped. The bean definition added by component scanning in step 3 is removed.
7. loadBeanDefinitionsForConfigurationClass is called for the ZombieBean configuration class. There's is no bean annotated with @EnableSomething so condition evaluation indicates that it should be skipped. The bean definition added by component scanning in step 3 is removed.

I think the bug is in step 3. My expectation is that condition evaluation should have been performed prior to registering the bean definitions. I've opened SPR-17552.

Generally speaking, I would avoid the use of component scanning in a starter. This is already mentioned in the documentation:

Auto-configurations must be loaded that way only. Make sure that they are defined in a specific package space and that, in particular, they are never the target of component scanning.

I'll leave this open for now so we can consider updating the documentation to caution more strongly against the use of @ComponentScan in auto-configuration.