|
|
@ -113,7 +113,8 @@ issue, because no compiler is involved, and you can declare |
|
|
|
When using `@Configuration` classes, the Java compiler places constraints on |
|
|
|
When using `@Configuration` classes, the Java compiler places constraints on |
|
|
|
the configuration model, in that references to other beans must be valid Java syntax. |
|
|
|
the configuration model, in that references to other beans must be valid Java syntax. |
|
|
|
|
|
|
|
|
|
|
|
Fortunately, solving this problem is simple. As xref:core/beans/java/bean-annotation.adoc#beans-java-dependencies[we already discussed], |
|
|
|
Fortunately, solving this problem is simple. As |
|
|
|
|
|
|
|
xref:core/beans/java/bean-annotation.adoc#beans-java-dependencies[we already discussed], |
|
|
|
a `@Bean` method can have an arbitrary number of parameters that describe the bean |
|
|
|
a `@Bean` method can have an arbitrary number of parameters that describe the bean |
|
|
|
dependencies. Consider the following more real-world scenario with several `@Configuration` |
|
|
|
dependencies. Consider the following more real-world scenario with several `@Configuration` |
|
|
|
classes, each depending on beans declared in the others: |
|
|
|
classes, each depending on beans declared in the others: |
|
|
@ -204,7 +205,6 @@ Kotlin:: |
|
|
|
---- |
|
|
|
---- |
|
|
|
====== |
|
|
|
====== |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There is another way to achieve the same result. Remember that `@Configuration` classes are |
|
|
|
There is another way to achieve the same result. Remember that `@Configuration` classes are |
|
|
|
ultimately only another bean in the container: This means that they can take advantage of |
|
|
|
ultimately only another bean in the container: This means that they can take advantage of |
|
|
|
`@Autowired` and `@Value` injection and other features the same as any other bean. |
|
|
|
`@Autowired` and `@Value` injection and other features the same as any other bean. |
|
|
@ -216,6 +216,11 @@ classes are processed quite early during the initialization of the context, and |
|
|
|
to be injected this way may lead to unexpected early initialization. Whenever possible, resort to |
|
|
|
to be injected this way may lead to unexpected early initialization. Whenever possible, resort to |
|
|
|
parameter-based injection, as in the preceding example. |
|
|
|
parameter-based injection, as in the preceding example. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoid access to locally defined beans within a `@PostConstruct` method on the same configuration |
|
|
|
|
|
|
|
class. This effectively leads to a circular reference since non-static `@Bean` methods semantically |
|
|
|
|
|
|
|
require a fully initialized configuration class instance to be called on. With circular references |
|
|
|
|
|
|
|
disallowed (e.g. in Spring Boot 2.6+), this may trigger a `BeanCurrentlyInCreationException`. |
|
|
|
|
|
|
|
|
|
|
|
Also, be particularly careful with `BeanPostProcessor` and `BeanFactoryPostProcessor` definitions |
|
|
|
Also, be particularly careful with `BeanPostProcessor` and `BeanFactoryPostProcessor` definitions |
|
|
|
through `@Bean`. Those should usually be declared as `static @Bean` methods, not triggering the |
|
|
|
through `@Bean`. Those should usually be declared as `static @Bean` methods, not triggering the |
|
|
|
instantiation of their containing configuration class. Otherwise, `@Autowired` and `@Value` may not |
|
|
|
instantiation of their containing configuration class. Otherwise, `@Autowired` and `@Value` may not |
|
|
|