search

spring-projects / spring-framework

Spring Framework
https://spring.io/projects/spring-framework
Apache License 2.0
56.47k stars 38.09k forks source link

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

Open spring-projects-issues opened 10 years ago

spring-projects-issues commented 10 years ago

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:

5 votes, 7 watchers

spring-projects-issues commented 10 years ago

Oliver Drotbohm commented

/cc Dave Syer

spring-projects-issues commented 10 years ago

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 commented 4 years ago

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 commented 4 years ago

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.