Minimal example reproducing the problem: https://github.com/klach-ocado/enablescheduling-configurationphase-issue

  • AaaUnrelatedAutoConfiguration is where @EnableScheduling annotation was added, or (another case, when @EnableScheduling was already there) where existing conditions were collapsed to a single @Conditional.
  • TriggeringAutoConfiguration (before = TriggeredAutoConfiguration.class) registers TriggeringBean.
  • TriggeredAutoConfiguration depends on TriggeringBean being registered, and has @EnableScheduling.

Normally those classes are in separate modules, TriggeringAutoConfiguration is in a module that is an extension to the module with TriggeredAutoConfiguration, no other relations.

What is known already?

There is an issue that @EnableScheduling annotation added to a seemingly unrelated class (AaaUnrelatedAutoConfiguration), or collapsing existing conditions in an unrelated class to a single @Conditional causes existing (and working previously) @AutoConfiguration-s with @Conditional with ConfigurationPhase.REGISTER_BEAN (e.g. @ConditionalOnBean) being skipped.

AaaUnrelatedAutoConfiguration class has comments for possible changes in the code showing that it's indeed that class that caused problems.

There of course are other options, like in TriggeredAutoConfiguration moving @ConditionalOnBean from the class to the @Bean method but let's assume we don't want @EnableScheduling being activated unnecessarily.

Similar issues: * https://github.com/spring-projects/spring-boot/issues/14018 * https://github.com/spring-projects/spring-framework/issues/21690

What enhancement is suggested?

Rather than introducing changes to the condition handling for configuration classes, or to the logic of @Import annotation (used underneath of @EnableScheduling), maybe it could be possible to add some validation for @EnableScheduling annotation? Among common @Enable* annotations, also @EnableCaching may be worth to protect, other ones are less likely to be used with REGISTER_BEAN phase.

I consider a protection similar to this one: https://github.com/spring-projects/spring-framework/issues/23206 (does not have to be so sophisticated), or at least some warning in logs (but typically only org.springframework.boot.autoconfigure logger is enabled by users, which may not cover that).

Rationale: Those are common annotations, and user does not expect that e.g. collapsing existing conditions to a single @Conditional in one class can accidentally cause skipping completely unrelated @AutoConfiguration-s.