Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Documentation updates around configuration classes

Browse Source 
(cherry picked from commit aff914c)
This commit is contained in:
Juergen Hoeller
2016-09-01 12:41:55 +02:00
parent 086e764845
commit efb5f17a60
1 changed files with 16 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
src/asciidoc/core-beans.adoc
View File

@@ -2946,7 +2946,6 @@ to perform certain actions upon initialization and destruction of your beans.
[TIP] [TIP]
==== ====
The JSR-250 `@PostConstruct` and `@PreDestroy` annotations are generally considered best The JSR-250 `@PostConstruct` and `@PreDestroy` annotations are generally considered best
practice for receiving lifecycle callbacks in a modern Spring application. Using these practice for receiving lifecycle callbacks in a modern Spring application. Using these
annotations means that your beans are not coupled to Spring specific interfaces. For annotations means that your beans are not coupled to Spring specific interfaces. For
@@ -6715,13 +6714,17 @@ The behavior could be different according to the scope of your bean. We are talk
about singletons here. about singletons here.
==== ====
[NOTE] [TIP]
==== ====
There are a few restrictions due to the fact that CGLIB dynamically adds features at There are a few restrictions due to the fact that CGLIB dynamically adds features at
startup-time: startup-time, in particular that configuration classes must not be final. However, as
of 4.3, any constructors are allowed on configuration classes, including the use of
`@Autowired` or a single non-default constructor declaration for default injection.
* Configuration classes should not be final If you prefer to avoid any CGLIB-imposed limitations, consider declaring your `@Bean`
* They should have a constructor with no arguments methods on non-`@Configuration` classes, e.g. on plain `@Component` classes instead.
Cross-method calls between `@Bean` methods won't get intercepted then, so you'll have
to exclusively rely on dependency injection at the constructor or method level there.
==== ====
@@ -6781,6 +6784,14 @@ This approach simplifies container instantiation, as only one class needs to be
with, rather than requiring the developer to remember a potentially large number of with, rather than requiring the developer to remember a potentially large number of
`@Configuration` classes during construction. `@Configuration` classes during construction.
[TIP]
====
As of Spring Framework 4.2, `@Import` also supports references to regular component
classes, analogous to the `AnnotationConfigApplicationContext.register` method.
This is particularly useful if you'd like to avoid component scanning, using a few
configuration classes as entry points for explicitly defining all your components.
====
[[beans-java-injecting-imported-beans]] [[beans-java-injecting-imported-beans]]
===== Injecting dependencies on imported @Bean definitions ===== Injecting dependencies on imported @Bean definitions