Include @ConditionalOnMissingBean and @ConditionalOnClass from Spring Boot [SPR-11296]

[spring-projects-issues]

Oliver Drotbohm opened SPR-11296 and commented

@ConditionalOnMissingBean and @ConditionalOnClass allow to selectively register bean definitions in case a different bean definition is already registered or a type being present on the classpath.

This is really useful to ecosystem projects to be able to pick up user configuration or fall back to defaults otherwise without necessarily creating a dependency on Spring Boot (which might cause a cyclic dependency if boot provides additional defaulting).

---

Issue Links:

• Port @ConditionalOn... from Spring Boot into Spring Core [SPR-10964] #15592 Port @ConditionalOn... from Spring Boot into Spring Core

5 votes, 7 watchers

[spring-projects-issues]

Oliver Drotbohm commented

/cc Dave Syer

[spring-projects-issues]

Dave Syer commented

One problem is that @ConditionalOnMissingBean(annotations=...) really doesn't work yet, even after some last minute changes to Spring 4.0 to try and support it - it tends to trigger early instantiation of @Configuration beans with fairly disasterous consequences. I think we should try and address that before migrating the @Conditional features to spring-framework.

[sdeleuze]

I have tagged this issue with the native label (related to GraalVM native) because import selectors are causing troubles (by design) when we try to convert @Configuration to functional variant at build time. They are dynamic by nature, the String[] return value is very reflection oriented, etc.

After a discussion, with @dsyer and @wilkinsona, I am tempted to think that for most use cases we could replace import selectors by providing more advanced conditions in Spring Framework (inspired by Spring Boot one), in order to make it possible for Spring portfolio projects to selectively register bean definitions as requested by @odrotbohm. That would also increase the maintainability and the expressiveness of Spring configurations.

I guess that will trigger questions like what conditions should be moved to Framework. Maybe also this could create an opportunity to see if we should support those conditions more natively without requiring DeferredImportSelector usage for example.

cc @philwebb @jhoeller.

[philwebb]

This probably isn't something we can easily do in Boot 2.x/Framework 5.x since our conditions in Boot contribute to an auto-configuration report. It would be a good 6.x candidate I think.