Browse Source

Resolved SPR-6187: touch-ups based on mfisher's feedback.

git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@2689 50f2f4bb-b051-0410-bef5-90022cba6387
pull/1/head
Chris Beams 16 years ago
parent
commit
9efc62b34a
  1. 38
      spring-framework-reference/src/beans.xml

38
spring-framework-reference/src/beans.xml

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

Loading…
Cancel
Save