Clarify usage of `@ConditionalOn[Missing]Bean`
Closes gh-4104
This commit is contained in:
parent
9d3858caff
commit
a7bdef61de
|
|
@ -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.
|
||||||
|
====
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue