AutoConfiguration is skipped because of @EnableScheduling

[Aloren]

Currently we are facing a complex issue with autoconfigurations that are marked with @EnableScheduling. I have created sample project that reproduces an issue.

It consists of 4 modules:

• library-0 module
  This module defines Library0AutoConfiguration that has @EnableScheduling and @AutoConfigureBefore(name = "org.library1.Library1AutoConfiguration"). It will not start because of unsatisfied @ConditionalOnBean (bean is not present in context).
• library-1 module
  This module defines Library1AutoConfiguration that has @AutoConfigureBefore(name = "org.library2.Library2AutoConfiguration").
• library-2 module
  This module defines Library2AutoConfiguration that has @EnableScheduling and @Conditional on bean of type Library1.class.
• service module
  This module imports: library-0, library-1 and library-2 and enables autoconfiguration.
  There is test ServiceConfigurationTest that can be run to reproduce an issue:

@SpringBootTest(
        webEnvironment = SpringBootTest.WebEnvironment.NONE,
        classes = ServiceConfiguration.class
)
@RunWith(SpringRunner.class)
public class ServiceConfigurationTest {

    @Autowired
    Library1 library1;
    @Autowired
    Library2 library2;

    @Test
    public void beans_should_be_present() throws Exception {
        assertNotNull(library1);
        assertNotNull(library2);
    }
}

Actual result: both Library1AutoConfiguration and Library2AutoConfiguration should start, because they do not have dependency on Library0AutoConfiguration, but instead Library2AutoConfiguration will not start and test will fail.

Removing @EnableScheduling from Library0AutoConfiguration fixes an issue.

We have found that TrackedConditionEvaluator.shouldSkip for org.springframework.scheduling.annotation.SchedulingConfiguration skips loading bean definitions for Library2AutoConfiguration.

Spring Boot version 1.5.13

[wilkinsona]

Thanks for the sample and detailed description of the problem.

The behaviour that you are seeing is due to the way that imports are treated during condition evaluation. Your auto-configurations are configured to be processed in the following order:

1. Library0AutoConfiguration
2. Library1AutoConfiguration
3. Library2AutoConfiguration

Both Library0AutoConfiguration and Library2AutoConfiguration are annotated with @EnableScheduling which means that they are both importers of org.springframework.scheduling.annotation.SchedulingConfiguration. Due to being imported by Library0AutoConfiguration, SchedulingConfiguration is processed before it (and, therefore before Library1AutoConfiguration and Library2AutoConfiguration as well). When it's processed, the condition evaluator is called to see if it should be skipped. This evaluation takes into account the conditions on its importers. As a result, the conditions on Library0AutoConfiguration are evaluated. Its conditions do not match so the next importer, Library2AutoConfiguration, is evaluated. Crucially, this is happening before the bean definitions on Library1AutoConfiguration have been processed. As a result, the definition for the Library1 bean does not exist and the condition on Library2AutoConfiguration does match and the Library2 bean is never defined.

The coupling between seemingly unrelated configuration classes that's caused by them both importing the same class is, perhaps, a little surprising but it means that imported configuration can be conditional which is a feature that Boot relies on a lot. It might be possible to make a change in Spring Framework to avoid the coupling, but I am rather doubtful that it'll be possible while also keeping the useful behaviour.

The good news is that you can avoid the problem you're seeing by separating out your auto-configuration that enables scheduling into a separate auto-configuration class:

diff --git a/library-0/src/main/java/org/library0/Library0AutoConfiguration.java b/library-0/src/main/java/org/library0/Library0AutoConfiguration.java
index 9d8b4c4..b2a8e2e 100644
--- a/library-0/src/main/java/org/library0/Library0AutoConfiguration.java
+++ b/library-0/src/main/java/org/library0/Library0AutoConfiguration.java
@@ -3,11 +3,10 @@ package org.library0;
 import org.springframework.boot.autoconfigure.AutoConfigureBefore;
 import org.springframework.boot.autoconfigure.condition.ConditionalOnBean;
 import org.springframework.context.annotation.Configuration;
-import org.springframework.scheduling.annotation.EnableScheduling;

 @ConditionalOnBean(name = "library0")
 @AutoConfigureBefore(name = "org.library1.Library1AutoConfiguration")
-@EnableScheduling
 @Configuration
 public class Library0AutoConfiguration {
+
 }
diff --git a/library-0/src/main/java/org/library0/Library0SchedulingAutoConfiguration.java b/library-0/src/main/java/org/library0/Library0SchedulingAutoConfiguration.java
new file mode 100644
index 0000000..ce98612
--- /dev/null
+++ b/library-0/src/main/java/org/library0/Library0SchedulingAutoConfiguration.java
@@ -0,0 +1,8 @@
+package org.library0;
+
+import org.springframework.scheduling.annotation.EnableScheduling;
+
+@EnableScheduling
+public class Library0SchedulingAutoConfiguration {
+
+}
diff --git a/library-0/src/main/resources/META-INF/spring.factories b/library-0/src/main/resources/META-INF/spring.factories
index 490f25d..515e2b6 100644
--- a/library-0/src/main/resources/META-INF/spring.factories
+++ b/library-0/src/main/resources/META-INF/spring.factories
@@ -1,2 +1,3 @@
 org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
-org.library0.Library0AutoConfiguration
\ No newline at end of file
+org.library0.Library0AutoConfiguration,\
+org.library0.Library0SchedulingAutoConfiguration
\ No newline at end of file

If you'd like to pursue a change to the underlying behaviour, please open a Spring Framework JIRA ticket.

[Aloren]

I've created ticket: SPR-17153.
At least Spring team should be aware of this behavior.