diff --git a/spring-framework-reference/src/beans.xml b/spring-framework-reference/src/beans.xml
index 6719d4d43fb..50c1c33bfad 100644
--- a/spring-framework-reference/src/beans.xml
+++ b/spring-framework-reference/src/beans.xml
@@ -3370,8 +3370,8 @@ beanFactory.registerScope("thread", threadScope
Where existing bean classes already have callback methods that
are named at variance with the convention, you can override the
default by specifying (in XML, that is) the method name using the
- init-method and destroy-method attributes on the <bean/>
- itself.
+ init-method and destroy-method
+ attributes of the <bean/> itself.
The Spring container guarantees that a configured initialization
callback is called immediately after a bean is supplied with all
@@ -5915,7 +5915,7 @@ public static void main(String[] args) {
tooling is still useful: it will be easy for the developer to get a type hierarchy
of RepositoryConfig implementations. In this way, navigating
@Configuration classes and their dependencies becomes no
- different that the usual process of navigating interface-based code.
+ different than the usual process of navigating interface-based code.
@@ -6090,9 +6090,8 @@ jdbc.password=
to register a bean definition within an
ApplicationContext of the type specified as the method's
return value. By default, the bean name will be the same as the method
- name. (See bean naming for details
- on how to customize this behavior.) The following is a simple example
- of a @Bean method declaration:
+ name. The following is a simple example of a
+ @Bean method declaration:
@Configuration
public class AppConfig {
@@ -6105,7 +6104,7 @@ public class AppConfig {
The preceding configuration is exactly equivalent to the
following Spring XML: <beans>
- <bean name="transferService" class="com.acme.TransferServiceImpl"/>
+ <bean id="transferService" class="com.acme.TransferServiceImpl"/>
</beans> Both declarations make a bean named transferService
@@ -6142,12 +6141,13 @@ public class AppConfig {
Receiving lifecycle callbacks
- Beans created in a
- @Configuration-annotated class supports
- the regular lifecycle callbacks. Any classes defined with the @Bean
- annotation can use the @PostConstruct and @PreDestroy annotations from
- JSR-250, see JSR-250
+ Beans declared in a
+ @Configuration-annotated class support
+ the regular lifecycle callbacks. Any classes defined with the
+ @Bean annotation can use the
+ @PostConstruct and @PreDestroy
+ annotations from JSR-250, see JSR-250
annotations for further details.The regular Spring The @Bean annotation supports
specifying arbitrary initialization and destruction callback methods,
much like Spring XML's init-method and
- destroy-method attributes to the bean
+ destroy-method attributes on the bean
element: public class Foo {
public void init() {
// initialization logic
@@ -6316,7 +6316,7 @@ public CommandManager commandManager() {
// return new anonymous implementation of CommandManager with command() overridden
// to return a new prototype Command object
return new CommandManager() {
- protected Command command() {
+ protected Command createCommand() {
return asyncCommand();
}
}
@@ -6327,8 +6327,8 @@ public CommandManager commandManager() {
Customizing bean naming
- By default, Configuration classes use a
- @Bean methods name as the name of the
+ By default, configuration classes use a
+ @Bean method's name as the name of the
resulting bean. This functionality can be overridden, however, with
the name attribute. @Configuration
public class AppConfig {
@@ -6345,8 +6345,8 @@ public class AppConfig {
Bean aliasingAs discussed in , it is sometimes desirable
- to name a bean multiple names, otherwise known as bean aliasing.
- The name attribute to the @Bean annotation accepts
+ to give a single bean multiple names, otherwise known as bean aliasing.
+ The name attribute of the @Bean annotation accepts
a String array for this purpose. @Configuration
public class AppConfig {