-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Description
Spring Boot has an optimization in which a DeferredImportSelector
implementation has a chance to look at an index to remove auto-configuration classes that do not match conditions that can be evaluated early (typically, @ConditionalOnClass
). This has the net effect of removing the FQN for each non matching candidate so that the class isn't even loaded while still making sure the auto-configuration report contains an entry for it.
Unfortunately, this arrangement does not extend to configuration classes that are imported as a result of processing an auto-configuration. A large number of auto-configurations are enabled with minimal assumptions, followed by all supported combinations in a form of an isolated @Configuration
class, each having their own conditions. Extending this mechanism to "sub-imports" would skip a fair amount of configuration classes, depending on the classpath of the application.
Concretely, everything happens in ConfigurationClassParser
. When processConfigurationClass
kicks in, members are evaluated for a @Component
(that could be configuration classes in the form of inner classes, a very common setup in Spring Boot) and @Import
annotations are processed. This method currently misses some form of "owner" (or the component that required the scan).
If we had such argument, we could check if the owner implements an additional strategy interface, something like
interface ConfigurationClassFilter {
boolean filter(String configurationClassName);
}
On the Spring Boot side of things, we could make sure our DeferredImportSelector
implements this interface as well and filter the class argument the same way it does early on when looking at the list in META-INF/spring.factories
.