Clarify usage of `@ConditionalOn[Missing]Bean`

Closes gh-4104
This commit is contained in:
Stephane Nicoll 2015-10-13 18:55:47 +02:00
parent 9d3858caff
commit a7bdef61de
1 changed files with 15 additions and 5 deletions

View File

@ -3874,16 +3874,26 @@ might not actually appear on the running application classpath. You can also use
[[boot-features-bean-conditions]] [[boot-features-bean-conditions]]
==== Bean conditions ==== Bean conditions
The `@ConditionalOnBean` and `@ConditionalOnMissingBean` annotations allow configurations The `@ConditionalOnBean` and `@ConditionalOnMissingBean` annotations allow a bean
to be included based on the presence or absence of specific beans. You can use the `value` to be included based on the presence or absence of specific beans. You can use the `value`
attribute to specify beans by type, or `name` to specify beans by name. The `search` attribute to specify beans by type, or `name` to specify beans by name. The `search`
attribute allows you to limit the `ApplicationContext` hierarchy that should be considered attribute allows you to limit the `ApplicationContext` hierarchy that should be considered
when searching for beans. when searching for beans.
NOTE: `@Conditional` annotations are processed when `@Configuration` classes are parsed. Conditions are evaluated after all configuration classes have been processed. This clearly
Auto-configured `@Configuration` is always parsed last (after any user defined beans), means that you can't use it to make a whole configuration class conditional on the presence
however, if you are using these annotations on regular `@Configuration` classes, care must (or absence) of another bean. You can, however, use it when you have to share that
be taken not to refer to bean definitions that have not yet been created. condition with all the beans of that configuration class.
[NOTE]
====
You also need to be very careful about ordering as the condition will be evaluated based on
the bean definitions that have been processed so far. Auto-configured `@Configuration` is
always parsed last (after any user defined beans) so it is recommended to restrict the use
of that condition on auto-configuration classes only. However, if you are sure that the bean
targeted at the condition won't be created by auto-configuration, then you could use it on a
normal configuration class with appropriate ordering.
====