从上图可以看到，Spring IoC容器将读取配置元数据；并通过它对应用中各个对象进行实例化、配置以及组装。通常情况下我们使用简单直观的XML来作为配置元数据的描述格式。在XML配置元数据中我们可以对那些我们希望通过Spring IoC容器管理的bean进行定义。

	Note
	到目前为止，基于XML的元数据是最常用到的配置元数据格式。然而，它并不是唯一的描述格式。Spring IoC容器在这一点上是完全开放的。 在本文写作时，Spring支持三种配置元数据格式：XML格式、Java属性文件格式或使用Spring公共API编程实现。由于XML元数据配置格式简单明了，因而本章采用该格式来表达Spring IoC容器的主要理念和特性。

将XML配置文件分拆成多个部分是非常有用的。为了加载多个XML文件生成一个ApplicationContext实例，可以将文件路径作为字符串数组传给ApplicationContext构造器。而bean factory将通过调用bean defintion reader从多个文件中读取bean定义。

通常情况下，Spring团队倾向于上述做法，因为这样各个配置并不会查觉到它们与其他配置文件的组合。另外一种方法是使用一个或多个的<import/>元素来从另外一个或多个文件加载bean定义。所有的<import/>元素必须放在<bean/>元素之前以完成bean定义的导入。 让我们看个例子：

<beans><import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>
      <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
  </beans>

在上面的例子中，我们从3个外部文件：services.xml、messageSource.xml及themeSource.xml来加载bean定义。这里采用的都是相对路径，因此，此例中的services.xml一定要与导入文件放在同一目录或类路径，而messageSource.xml和themeSource.xml的文件位置必须放在导入文件所在目录下的resources目录中。正如你所看到的那样，开头的斜杠‘/’实际上可忽略。因此不用斜杠‘/’可能会更好一点。

根据Spring XML配置文件的Schema(或DTD)，被导入文件必须是完全有效的XML bean定义文件，且根节点必须为<beans/> 元素。

每个bean都有一个或多个id(或称之为标识符或名称，在术语上可以理解成一回事)。这些id在当前IoC容器中必须唯一。如果一个bean有多个id，那么其他的id在本质上将被认为是别名。

当使用基于XML的配置元数据时，将通过id或name属性来指定bean标识符。id属性具有唯一性，而且是一个真正的XML ID属性，因此其他xml元素在引用该id时，可以利用XML解析器的验证功能。通常情况下最好为bean指定一个id。尽管XML规范规定了XML ID命名的有效字符，但是bean标识符的定义不受该限制，因为除了使用指定的XML字符来作为id，还可以为bean指定别名，要实现这一点可以在name属性中使用逗号、冒号或者空格将多个id分隔。

值得注意的是，为一个bean提供一个name并不是必须的，如果没有指定，那么容器将为其生成一个惟一的name。对于不指定name属性的原因我们会在后面介绍(比如内部bean就不需要)。

<alias name="fromName" alias="toName"/>

<alias name="componentA-dataSource" alias="componentB-dataSource"/>
<alias name="componentA-dataSource" alias="myApp-dataSource" />

就Spring IoC容器而言，bean定义基本上描述了创建一个或多个实际bean对象的内容。当需要的时候，容器会从bean定义列表中取得一个指定的bean定义，并根据bean定义里面的配置元数据使用反射机制来创建一个实际的对象。因此这一节将讲解如何告知Spring IoC容器我们将要实例化的对象的类型以及如何实例化对象。

当采用XML描述配置元数据时，将通过<bean/>元素的class属性来指定实例化对象的类型。class 属性 (对应BeanDefinition实例的Class属性)通常是必须的(不过也有两种例外的情形，见Section 3.2.3.2.3, “使用实例工厂方法实例化”和Section 3.6, “bean的继承”)。class属性主要有两种用途：在大多数情况下，容器将直接通过反射调用指定类的构造器来创建bean(这有点等类似于在Java代码中使用new操作符)；在极少数情况下，容器将调用类的静态工厂方法来创建bean实例，class属性将用来指定实际具有静态工厂方法的类(至于调用静态工厂方法创建的对象类型是当前class还是其他的class则无关紧要)。

<bean id="exampleBean" class="examples.ExampleBean"/>
<bean name="anotherExample" class="examples.ExampleBeanTwo"/>

<bean id="exampleBean"
      class="examples.ExampleBean2"
      factory-method="createInstance"/>

<!-- the factory bean, which contains a method called createInstance() -->
<bean id="myFactoryBean" class="...">
  ...
</bean>
  <!-- the bean to be created via the factory bean -->
<bean id="exampleBean"
      factory-bean="myFactoryBean"
      factory-method="createInstance"/>

通过调用无参构造器或无参static工厂方法实例化bean之后，调用该bean的setter方法，即可实现基于setter的DI。

下面的例子将展示使用setter注入依赖。注意，这个类并没有什么特别之处，它就是普通的Java类。

public class SimpleMovieLister {
      // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;
      // a setter method so that the Spring container can 'inject' a MovieFinder
    public void setMoveFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }
    
    // business logic that actually 'uses' the injected MovieFinder is omitted...
}

基于构造器的DI通过调用带参数的构造器来实现，每个参数代表着一个协作者。此外，还可通过给静态工厂方法传参数来构造bean。接下来的介绍将认为给构造器传参与给静态工厂方法传参是类似的。

下面的展示了只能使用构造器参数来注入依赖关系的例子。再次提醒，这个类并没有什么特别之处。

public class SimpleMovieLister {
      // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;
      // a constructor so that the Spring container can 'inject' a  MovieFinder
    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }
    
    // business logic that actually 'uses' the injected MovieFinder is omitted...
}

首先是一个用XML格式定义的Setter DI例子。相关的XML配置如下：

<bean id="exampleBean" class="examples.ExampleBean">
    <!-- setter injection using the nested <ref/> element -->
  <property name="beanOne"><ref bean="anotherExampleBean"/></property>
    <!-- setter injection using the neater 'ref' attribute -->
  <property name="beanTwo"><ref bean="yetAnotherBean"/></property>
  <property name="integerProperty" value="1"/>
</bean>
  <bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

public class ExampleBean {
      private AnotherBean beanOne;
    private YetAnotherBean beanTwo;
    private int i;
      public void setBeanOne(AnotherBean beanOne) {
        this.beanOne = beanOne;
    }
      public void setBeanTwo(YetAnotherBean beanTwo) {
        this.beanTwo = beanTwo;
    }
      public void setIntegerProperty(int i) {
        this.i = i;
    }    
}

正如你所看到的，bean类中的setter方法与xml文件中配置的属性是一一对应的。

接着是构造器注入的例子。以下是xml配置代码以及相对应的java类代码。

<bean id="exampleBean" class="examples.ExampleBean">
    <!-- constructor injection using the nested <ref/> element -->
  <constructor-arg><ref bean="anotherExampleBean"/></constructor-arg>
  
  <!-- constructor injection using the neater 'ref' attribute -->
  <constructor-arg ref="yetAnotherBean"/>
  
  <constructor-arg type="int" value="1"/>
</bean>
  <bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

public class ExampleBean {
      private AnotherBean beanOne;
    private YetAnotherBean beanTwo;
    private int i;
    
    public ExampleBean(
        AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
        this.beanOne = anotherBean;
        this.beanTwo = yetAnotherBean;
        this.i = i;
    }
}

如你所见，在xml bean定义中指定的构造器参数将被用来作为传递给类ExampleBean构造器的参数。

现在来研究一个替代构造器的方法，采用静态工厂方法返回对象实例：

<bean id="exampleBean" class="examples.ExampleBean"
      factory-method="createInstance">
  <constructor-arg><ref bean="anotherExampleBean"/></constructor-arg>
  <constructor-arg><ref bean="yetAnotherBean"/></constructor-arg>
  <constructor-arg><value>1</value></constructor-arg>
</bean>
  <bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

public class ExampleBean {
      // a private constructor
    private ExampleBean(...) {
      ...
    }
    
    // a static factory method; the arguments to this method can be
    // considered the dependencies of the bean that is returned,
    // regardless of how those arguments are actually used.
    public static ExampleBean createInstance (
            AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
        ExampleBean eb = new ExampleBean (...);
        // some other operations
        ...
        return eb;
    }
}

请注意，传给静态工厂方法的参数由constructor-arg元素提供，这与使用构造器注入时完全一样。而且，重要的是，工厂方法所返回的实例的类型并不一定要与包含static工厂方法的类类型一致。尽管在此例子中它的确是这样。非静态的实例工厂方法与此相同（除了使用factory-bean属性替代class属性外），因而不在此细述。

针对上面的这种情况，我们可以在构造器参数定义中使用type属性来显式的指定参数所对应的简单类型。例如：

<bean id="exampleBean" class="examples.ExampleBean">
  <constructor-arg type="int"><value>7500000</value></constructor-arg>
  <constructor-arg type="java.lang.String"><value>42</value></constructor-arg>
</bean>

通过使用index属性可以显式的指定构造器参数出现顺序。例如：

<bean id="exampleBean" class="examples.ExampleBean">
  <constructor-arg index="0" value="7500000"/>
  <constructor-arg index="1" value="42"/>
</bean>

使用index属性除了可以解决多个简单类型构造参数造成的模棱两可的问题之外，还可以用来解决两个构造参数类型相同造成的麻烦。注意：index属性值从0开始。

	Tip
	指定构造器参数索引是使用构造器IoC首选的方式。

<value/>元素通过字符串来指定属性或构造器参数的值。正如前面所提到的，JavaBean PropertyEditor将用于把字符串从java.lang.String类型转化为实际的属性或参数类型。

<bean id="myDataSource" destroy-method="close"
    class="org.apache.commons.dbcp.BasicDataSource">
  <!-- results in a setDriverClassName(String) call -->
  <property name="driverClassName">
    <value>com.mysql.jdbc.Driver</value>
  </property>
  <property name="url">
    <value>jdbc:mysql://localhost:3306/mydb</value>
  </property>
  <property name="username">
    <value>root</value>
  </property>
</bean>

<bean id="theTargetBean" class="..."/>
  <bean id="theClientBean" class="...">
    <property name="targetName">
        <idref bean="theTargetBean" />
    </property>
</bean>

<bean id="theTargetBean" class="..."/>
  <bean id="client" class="...">
    <property name="targetName">
        <value>theTargetBean</value>
    </property>
</bean>

<property name="targetName">
   <!-- a bean with an id of 'target' must exist, else an XML exception will be thrown -->
   <idref local="theTargetBean"/>
</property>

在<constructor-arg/>或<property/>元素内部还可以使用ref元素。该元素用来将bean中指定属性的值设置为对容器中的另外一个bean的引用。如前所述，该引用bean将被作为依赖注入，而且在注入之前会被初始化（如果是singleton bean则已被容器初始化）。尽管都是对另外一个对象的引用，但是通过id/name指向另外一个对象却有三种不同的形式，不同的形式将决定如何处理作用域及验证。

第一种形式也是最常见的形式是通过使用ref标记指定bean属性的目标bean，通过该标签可以引用同一容器或父容器内的任何bean（无论是否在同一XML文件中）。XML 'bean'元素的值既可以是指定bean的id值也可以是其name值。

<ref bean="someBean"/>

第二种形式是使用ref的local属性指定目标bean，它可以利用XML解析器来验证所引用的bean是否存在同一文件中。local属性值必须是目标bean的id属性值。如果在同一配置文件中没有找到引用的bean，XML解析器将抛出一个例外。如果目标bean是在同一文件内，使用local方式就是最好的选择（为了尽早地发现错误）。

<ref local="someBean"/>

第三种方式是通过使用ref的parent属性来引用当前容器的父容器中的bean。parent属性值既可以是目标bean的id值，也可以是name属性值。而且目标bean必须在当前容器的父容器中。使用parent属性的主要用途是为了能引用到与当前容器中同名的父容器中的bean对象。

<ref parent="someBean"/>

所谓的内部bean（inner bean）是指在一个bean的<property/>或 <constructor-arg/>元素中使用<bean/>元素定义的bean。内部bean定义不需要有id或name属性，即使指定id 或 name属性值也将会被容器忽略。

以下是个关于内部bean例子。

<bean id="outer" class="...">
  <!-- instead of using a reference to a target bean, simply define the target inline -->
  <property name="target">
    <bean class="com.mycompany.Person"> <!-- this is the inner bean -->
      <property name="name" value="Fiona Apple"/>
      <property name="age" value="25"/>
    </bean>
  </property>
</bean>

注意：内部bean中的singleton标记及id或name属性将被忽略。内部bean总是匿名的且它们总是prototype模式的。同时将内部bean注入到包含该内部bean之外的bean是不可能的。

通过<list/>、<set/>、<map/>及<props/>元素可以定义和设置与Java Collection类型对应List、Set、Map及Properties的值。

<bean id="moreComplexObject" class="example.ComplexObject">
  <!-- results in a setAdminEmails(java.util.Properties) call -->
  <property name="adminEmails">
    <props>
        <prop key="administrator">[email protected]</prop>
        <prop key="support">[email protected]</prop>
        <prop key="development">[email protected]</prop>
    </props>
  </property>
  <!-- results in a setSomeList(java.util.List) call -->
  <property name="someList">
    <list>
        <value>a list element followed by a reference</value>
        <ref bean="myDataSource" />
    </list>
  </property>
  <!-- results in a setSomeMap(java.util.Map) call -->
  <property name="someMap">
    <map>
        <entry>
            <key>
                <value>yup an entry</value>
            </key>
            <value>just some string</value>
        </entry>
        <entry>
            <key>
                <value>yup a ref</value>
            </key>
            <ref bean="myDataSource" />
        </entry>
    </map>
  </property>
  <!-- results in a setSomeSet(java.util.Set) call -->
  <property name="someSet">
    <set>
        <value>just some string</value>
        <ref bean="myDataSource" />
    </set>
  </property>
</bean>

注意：map的key或value值，或set的value值不能是以下元素：

bean | ref | idref | list | set | map | props | value | null

<beans>
<bean id="parent" abstract="true" class="example.ComplexObject">
    <property name="adminEmails">
        <props>
            <prop key="administrator">[email protected]</prop>
            <prop key="support">[email protected]</prop>
        </props>
    </property>
</bean>
<bean id="child" parent="parent">
    <property name="adminEmails">
        <!-- the merge is specified on the *child* collection definition -->
        <props merge="true">
            <prop key="sales">[email protected]</prop>
            <prop key="support">[email protected]</prop>
        </props>
    </property>
</bean>
<beans>

[email protected]
[email protected]

[email protected]

public class Foo {
                
    private Map<String, Float> accounts;
    
    public void setAccounts(Map<String, Float> accounts) {
        this.accounts = accounts;
    }
  }

<beans>
    
    <bean id="foo" class="x.y.Foo">
        
        <property name="accounts">
            <map>
                <entry key="one" value="9.99"/>
                <entry key="two" value="2.75"/>
                <entry key="six" value="3.99"/>
            </map>
        </property>
      </bean>
  </beans>

<null/>用于处理null值。Spring会把属性的空参数当作空字符串处理。以下的xml片断将email属性设为空字符串。

<bean class="ExampleBean">
  <property name="email"><value></value></property>
</bean>

这等同于Java代码： exampleBean.setEmail("")。 而null值则可以使用<null>元素可用来表示。例如：

<bean class="ExampleBean">
  <property name="email"><null/></property>
</bean>

上述的配置等同于Java代码：exampleBean.setEmail(null)。

针对常见的value值或bean的引用，Spring提供了简化格式用于替代<value/>和<ref/>元素。<property/>、<constructor-arg/>及<entry/>元素都支持value属性（attribute），它可以用来替代内嵌的<value/>元素。因而，以下的代码：

<property name="myProperty">
  <value>hello</value>
</property>

<constructor-arg>
  <value>hello</value>
</constructor-arg>

<entry key="myKey">
  <value>hello</value>
</entry>

等同于：

<property name="myProperty" value="hello"/>

<constructor-arg value="hello"/>

<entry key="myKey" value="hello"/>

通常情况下，当手工编写配置文件时，你可能会偏向于使用简写形式（Spring的开发团队就是这么做的）。

<property/>和<constructor-arg/>支持类似的简写属性ref，它可能用来替代整个内嵌的<ref/>元素。因而，以下的代码：

<property name="myProperty">
  <ref bean="myBean">
</property>

<constructor-arg>
  <ref bean="myBean">
</constructor-arg>

等同于：

<property name="myProperty" ref="myBean"/>

<constructor-arg ref="myBean"/>

注意，尽管存在等同于<ref bean="xxx"> 元素的简写形式，但并没有<ref local="xxx">的简写形式，为了对当前xml中bean的引用，你只能使用完整的形式。

最后，map中entry元素的简写形式为key/key-ref 和 value /value-ref属性，因而，以下的代码：

<entry>
  <key>
    <ref bean="myKeyBean" />
  </key>
  <ref bean="myValueBean" />
</entry>

等同于：

<entry key-ref="myKeyBean" value-ref="myValueBean"/>

再次强调，只有<ref bean="xxx">元素的简写形式，没有<ref local="xxx">的简写形式。

当设置bean的组合属性时，除了最后一个属性外，只要其他属性值不为null，组合或嵌套属性名是完全合法的。例如，下面bean的定义：

<bean id="foo" class="foo.Bar">
  <property name="fred.bob.sammy" value="123" />
</bean>

foo bean有个fred属性，此属性有个 bob属性，而bob属性又有个sammy属性，最后把sammy属性设置为123。为了让此定义能工作， foo的fred属性及fred 的bob属性在bean被构造后都必须非空，否则将抛出NullPointerException异常。

Lookup方法注入利用了Spring IoC容器复写bean的抽象（或具体）方法的能力，从而返回指定名字的bean实例。尽管Lookup方法注入也适用于singleton bean，但是它一般用来得到一个非singleton bean实例（就象上面的那种情形）。Lookup方法注入的内部机制是Spring利用了CGLIB库在运行时生成二进制代码功能，通过动态创建Lookup方法bean的子类而达到复写Lookup方法的目的。

在客户类中将包含被注入的方法，此方法定义必须按以下形式进行定义：

protected abstract SingleShotHelper createSingleShotHelper();

如果方法不是抽象的，Spring会简单地覆盖已有的实现。在基于XML的配置元数据文件中，通过在bean定义中使用lookup-method元素来告诉Spring所要注入/覆盖的方法将要返回的实际bean。例如：

<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="singleShotHelper" class="..." singleton="false"/>
  <!-- myBean uses singleShotHelper -->
<bean id="myBean" class="...">
  <lookup-method name="createSingleShotHelper" bean="singleShotHelper"/>
  <property>
    ...
  </property>
</bean>

在上面的例子中，标识为myBean的bean在需要一个新的singleShotHelperbean实例时，会调用createSingleShotHelper方法。一般情况下，我们会将singleShotHelper指定为非singleton。当然也可以指定为singleton，如果是这样的话，那么每次将返回相同的singleShotHelper实例！

最后需要提到的一点就是，Lookup方法注入既可以采用构造器注入的方式（通过可选的构造器参数来指定要构造的bean），也可以采用setter方法注入的方式（通过set属性指定要构造的bean）。

比起Lookup 方法注入来，还有一种很少用到的方法注入形式，该注入能使用bean的另一个方法实现去替换自定义的方法。除非你真的需要该功能，否则可以略过本节。

当使用基于XML配置元数据文件时，可以在bean定义中使用replaced-method元素来达到用另一个方法来取代已有方法的目的。考虑下面的类，我们将覆盖computeValue方法：

public class MyValueCalculator {
    public String computeValue(String input) {
    // some real code...
  }
    // some other methods...
  }

实现org.springframework.beans.factory.support.MethodReplacer接口的类提供了新的方法定义。

/** meant to be used to override the existing computeValue
    implementation in MyValueCalculator */
public class ReplacementComputeValue implements MethodReplacer {
      public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
        // get the input value, work with it, and return a computed result
        String input = (String) args[0];
        ... 
        return ...;
}

下面的bean定义中指定了将要复写的方法以及执行替换处理的bean定义：

<bean id="myValueCalculator class="x.y.z.MyValueCalculator">
  <!-- arbitrary method replacement -->
  <replaced-method name="computeValue" replacer="replacementComputeValue">
    <arg-type>String</arg-type>
  </replaced-method>
</bean>
  <bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>

在<replaced-method/>元素内可包含一个或多个<arg-type/>元素，这些元素用来标明被复写的方法签名。只有被复写（override）的方法存在重载（overload）的情况（同名的多个方法变体）才会使用方法签名。为了方便，参数的类型字符串可以采用全限定类名的简写。例如，下面的字符串都表示参数类型为java.lang.String。

    java.lang.String
    String
    Str

因为参数个数的不同可以很容易将重载的方法区分开来，所以只要使用的参数类型字符串能匹配一个参数，那么可以采用尽可能少的字符串来减少输入。

你也可以针对单个bean设置其是否为被自动装配对象。当采用XML格式配置bean时，<bean/>元素的 autowire-candidate属性可被设为false，这样容器在查找自动装配对象时将不考虑该bean。

对于那些从来就不会被其它bean采用自动装配的方式来注入的bean而言，这是有用的。不过这并不意味着被排除的bean自己就不能使用自动装配来注入其他bean，它是可以的，或者更准确地说，应该是它不会被考虑作为其他bean自动装配的候选者。

要使用request、session和 global session作用域的bean（即具有web作用域的bean），在开始设置bean定义之前，还要做少量的初始配置。请注意，假如你只想要“常规的”作用域，也就是singleton和prototype，就不需要这一额外的设置。

在目前的情况下，根据你的特定servlet环境，有多种方法来完成这一初始设置。如果你使用的是Servlet 2.4及以上的web容器，那么你仅需要在web应用的XML声明文件web.xml中增加下述ContextListener即可

<web-app>
  ...
  <listener>
    <listener-class>org.springframework.web.context.scope.RequestContextListener</listener-class>
  </listener>
  ...
</web-app>

如果你用的是早期版本的web容器（Servlet 2.4以前），那么你要使用一个javax.servlet.Filter的实现。请看下面的web.xml配置片段：

<web-app>
  ..
  <filter> 
    <filter-name>requestContextFilter</filter-name> 
    <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
  </filter> 
  <filter-mapping> 
    <filter-name>requestContextFilter</filter-name> 
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  ...
</web-app>

RequestContextListener和RequestContextFilter两个类做的都是同样的工作：将HTTP request对象绑定到为该请求提供服务的Thread。这使得具有request和session作用域的bean能够在后面的调用链中被访问到。

考虑下面bean定义：

<bean id="loginAction" class="com.foo.LoginAction" scope="request"/>

针对每次HTTP请求，Spring容器会根据loginAction bean定义创建一个全新的LoginAction bean实例，且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。当处理请求结束，request作用域的bean实例将被销毁。

考虑下面bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例，且该userPreferences bean仅在当前HTTP Session内有效。与request作用域一样，你可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例，将不会看到这些特定于某个HTTP Session的状态变化。当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。

考虑下面bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="globalSession"/>

global session作用域类似于标准的HTTP Session作用域，不过它仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。

请注意，假如你在编写一个标准的基于Servlet的web应用，并且定义了一个或多个具有global session作用域的bean，系统会使用标准的HTTP Session作用域，并且不会引起任何错误。

能够在HTTP request或者Session（甚至自定义）作用域中定义bean固然很好，但是Spring IoC容器除了管理对象（bean）的实例化，同时还负责协作者（或者叫依赖）的实例化。如果你打算将一个Http request范围的bean注入到另一个bean中，那么需要注入一个AOP代理来替代被注入的作用域bean。也就是说，你需要注入一个代理对象，该对象具有与被代理对象一样的公共接口，而容器则可以足够智能的从相关作用域中（比如一个HTTP request）获取到真实的目标对象，并把方法调用委派给实际的对象。

	Note
	<aop:scoped-proxy/>不能和作用域为singleton或prototype的bean一起使用。为singleton bean创建一个scoped proxy将抛出BeanCreationException异常。

让我们看一下将相关作用域bean作为依赖的配置，配置并不复杂（只有一行），但是理解“为何这么做”以及“如何做”是很重要的。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- a HTTP Session-scoped bean exposed as a proxy -->
    <bean id="userPreferences" class="com.foo.UserPreferences" scope="session">
          
          <!-- this next element effects the proxying of the surrounding bean -->
          <aop:scoped-proxy/>
    </bean>
    
    <!-- a singleton-scoped bean injected with a proxy to the above bean -->
    <bean id="userService" class="com.foo.SimpleUserService">
    
        <!-- a reference to the proxied 'userPreferences' bean -->
        <property name="userPreferences" ref="userPreferences"/>

    </bean>
</beans>

在XML配置文件中，要创建一个作用域bean的代理，只需要在作用域bean定义里插入一个<aop:scoped-proxy/>子元素即可（你可能还需要在classpath里包含CGLIB库，这样容器就能够实现基于class的代理）。上述XML配置展示了“如何做”，现在讨论“为何这么做”。在作用域为request、session以及globalSession的bean定义里，为什么需要这个<aop:scoped-proxy/>元素呢？下面我们从去掉<aop:scoped-proxy/>元素的XML配置开始说起：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

<bean id="userManager" class="com.foo.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

从上述配置中可以很明显的看到singleton bean userManager被注入了一个指向HTTP Session作用域bean userPreferences的引用。singleton userManager bean会被容器仅实例化一次，并且其依赖（userPreferences bean）也仅被注入一次。这意味着，userManager在理论上只会操作同一个userPreferences对象，即原先被注入的那个bean。而注入一个HTTP Session作用域的bean作为依赖，有违我们的初衷。因为我们想要的只是一个userManager对象，在它进入一个HTTP Session生命周期时，我们希望去使用一个HTTP Session的userPreferences对象。

当注入某种类型对象时，该对象实现了和UserPreferences类一样的公共接口（即UserPreferences实例）。并且不论我们底层选择了何种作用域机制（HTTP request、Session等等），容器都会足够智能的获取到真正的UserPreferences对象，因此我们需要将该对象的代理注入到userManager bean中, 而userManager bean并不会意识到它所持有的是一个指向UserPreferences引用的代理。在本例中，当UserManager实例调用了一个使用UserPreferences对象的方法时，实际调用的是代理对象的方法。随后代理对象会从HTTP Session获取真正的UserPreferences对象，并将方法调用委派给获取到的实际的UserPreferences对象。

这就是为什么当你将request、session以及globalSession作用域bean注入到协作对象中时需要如下正确而完整的配置：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session">
    <aop:scoped-proxy/>
</bean>

<bean id="userManager" class="com.foo.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

实现org.springframework.beans.factory.InitializingBean接口允许容器在设置好bean的所有必要属性后，执行初始化事宜。InitializingBean接口仅指定了一个方法：

void afterPropertiesSet() throws Exception;

通常，要避免使用InitializingBean接口（而且不鼓励使用该接口，因为这样会将代码和Spring耦合起来）可以在Bean定义中指定一个普通的初始化方法，即在XML配置文件中通过指定init-method属性来完成。如下面的定义所示：

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

public class ExampleBean {
    
    public void init() {
        // do some initialization work
    }
}

（效果）与下面完全一样

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>

public class AnotherExampleBean implements InitializingBean {
    
    public void afterPropertiesSet() {
        // do some initialization work
    }
}

但是没有将代码与Spring耦合在一起。

实现org.springframework.beans.factory.DisposableBean接口的bean允许在容器销毁该bean的时候获得一次回调。DisposableBean接口也只规定了一个方法：

void destroy() throws Exception;

通常，要避免使用DisposableBean标志接口（而且不鼓励使用该接口，因为这样会将代码与Spring耦合在一起）可以在bean定义中指定一个普通的析构方法，即在XML配置文件中通过指定destroy-method属性来完成。如下面的定义所示：

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>

public class ExampleBean {

    public void cleanup() {
        // do some destruction work (like releasing pooled connections)
    }
}

（效果）与下面完全一样

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>

public class AnotherExampleBean implements DisposableBean {

    public void destroy() {
        // do some destruction work (like releasing pooled connections)
    }
}

但是没有将代码与Spring耦合在一起。

public class DefaultBlogService implements BlogService {

    private BlogDao blogDao;

    public void setBlogDao(BlogDao blogDao) {
        this.blogDao = blogDao;
    }

    // this is (unsurprisingly) the initialization callback method
    public void init() {
        if (this.blogDao == null) {
            throw new IllegalStateException("The [blogDao] property must be set.");
        }
    }
}

<beans default-init-method="init">

    <bean id="blogService" class="com.foo.DefaultBlogService">
        <property name="blogDao" ref="blogDao" />
    </bean>

</beans>

3.5.1.2.2. 在非web应用中优雅地关闭Spring IoC容器

	Note
	在基于web的ApplicationContext实现中已有相应的代码来处理关闭web应用时如何恰当地关闭Spring IoC容器。

如果你正在一个非web应用的环境下使用Spring的IoC容器，例如在桌面富客户端环境下，你想让容器优雅的关闭，并调用singleton bean上的相应析构回调方法，你需要在JVM里注册一个“关闭钩子”（shutdown hook）。这一点非常容易做到，并且将会确保你的Spring IoC容器被恰当关闭，以及所有由单例持有的资源都会被释放（当然，为你的单例配置销毁回调，并正确实现销毁回调方法，依然是你的工作）。

为了注册“关闭钩子”，你只需要简单地调用在AbstractApplicationContext实现中的registerShutdownHook()方法即可。也就是：

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public final class Boot {

    public static void main(final String[] args) throws Exception {
        AbstractApplicationContext ctx
            = new ClassPathXmlApplicationContext(new String []{"beans.xml"});

        // add a shutdown hook for the above context... 
        ctx.registerShutdownHook();

        // app runs here...

        // main method exits, hook is called prior to the app shutting down...
    }
}

对于实现了org.springframework.beans.factory.BeanFactoryAware接口的类，当它被BeanFactory创建后，它会拥有一个指向创建它的BeanFactory的引用。

public interface BeanFactoryAware {

    void setBeanFactory(BeanFactory beanFactory) throws BeansException;
}

这样bean可以以编程的方式操控创建它们的BeanFactory，当然我们可以将引用的BeanFactory造型（cast）为已知的子类型来获得更多的功能。它主要用于通过编程来取得BeanFactory所管理的其他bean。虽然在有些场景下这个功能很有用，但是一般来说应该尽量避免使用，因为这样将使代码与Spring耦合在一起，而且也有违反转控制的原则（协作者应该作为属性提供给bean）。

与BeanFactoryAware等效的另一种选择是使用org.springframework.beans.factory.config.ObjectFactoryCreatingFactoryBean。不过该方法依然没有降低与Spring的耦合，但是它并没有像BeanFactoryAware那样，违反IoC原则。）

ObjectFactoryCreatingFactoryBean是FactoryBean的一个实现，它返回一个指向工厂对象的引用，该对象将执行bean的查找。ObjectFactoryCreatingFactoryBean类实现了BeanFactoryAware接口；被实际注入到客户端bean的是ObjectFactory接口的一个实例。这是Spring提供的一个接口（因而依旧没有完全与Spring解耦），客户端可以使用ObjectFactory的getObject()方法来查找bean（在其背后，ObjectFactory实例只是简单的将调用委派给BeanFactory，让其根据bean的名称执行实际的查找）。你要做的全部事情就是给ObjectFactoryCreatingFactoryBean提供待查找bean的名字。让我们看一个例子：

package x.y;

public class NewsFeed {
    
    private String news;

    public void setNews(String news) {
        this.news = news;
    }

    public String getNews() {
        return this.toString() + ": '" + news + "'";
    }
}

package x.y;

import org.springframework.beans.factory.ObjectFactory;

public class NewsFeedManager {

    private ObjectFactory factory;

    public void setFactory(ObjectFactory factory) {
        this.factory = factory;
    }

    public void printNews() {
        // here is where the lookup is performed; note that there is no
        // need to hardcode the name of the bean that is being looked up...
        NewsFeed news = (NewsFeed) factory.getObject();
        System.out.println(news.getNews());
    }
}

下述是XML配置：

<beans>
    <bean id="newsFeedManager" class="x.y.NewsFeedManager">
        <property name="factory">
            <bean
class="org.springframework.beans.factory.config.ObjectFactoryCreatingFactoryBean">
                <property name="targetBeanName">
                    <idref local="newsFeed" />
                </property>
            </bean>
        </property>
    </bean>
    <bean id="newsFeed" class="x.y.NewsFeed" singleton="false">
        <property name="news" value="... that's fit to print!" />
    </bean>
</beans>

这里有一个测试用的小程序：在NewsFeedManager的printNews()方法里，每次针对被注入的ObjectFactory的调用，实际上返回的是一个新的（prototype）newsFeed bean实例。

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import x.y.NewsFeedManager;

public class Main {

    public static void main(String[] args) throws Exception {

        ApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
        NewsFeedManager manager = (NewsFeedManager) ctx.getBean("newsFeedManager");
        manager.printNews();
        manager.printNews();
    }
}

上述程序的执行输出如下所示（当然，返回结果会根据你机器的不同而不同）

x.y.NewsFeed@1292d26: '... that's fit to print!'
x.y.NewsFeed@5329c5: '... that's fit to print!'

感兴趣的读者还可以用一下ServiceLocatorFactoryBean（在org.springframework.beans.factory.config包里），该方法类似于ObjectFactoryCreatingFactoryBean，但是它允许指定你自己的查找接口，而不是非得使用像ObjectFactory那样的Spring专门的查找接口。对于ServiceLocatorFactoryBean，请参考（详实的）Javadoc，以获得这一替代方案的完整处理方法（它减少了对Spring的耦合）。

假如bean实现了org.springframework.beans.factory.BeanNameAware接口并被部署在一个BeanFactory中，BeanFactory会通过该接口的setBeanName()方法以告知其被部署时的bean id。在bean属性被设置完成之后，在像InitializingBean的afterPropertiesSet或是自定义init-method这样的初始化回调执行之前，该接口的回调方法会被调用。

第一个实例似乎不太吸引人，但是它适合用来阐述BeanPostProcessor的基本用法。我们所有的工作是编写一个BeanPostProcessor的实现，它仅仅在容器创建每个bean时调用bean的toString()方法并且将结果打印到系统控制台。它是没有很大的用处，但是可以让我们对BeanPostProcessor有一个基本概念。

下面是BeanPostProcessor具体实现类的定义：

package scripting;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.beans.BeansException;

public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {

    // simply return the instantiated bean as-is
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean; // we could potentially return any object reference here...
    }

    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("Bean '" + beanName + "' created : " + bean.toString());
        return bean;
    }
}

这里是相应的XML配置：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:lang="http://www.springframework.org/schema/lang"
       xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang.xsd">

    <lang:groovy id="messenger"
          script-source="classpath:org/springframework/scripting/groovy/Messenger.groovy">
        <lang:property name="message" value="Fiona Apple Is Just So Dreamy."/> 
    </lang:groovy>
    
    <!-- 
        when the above bean ('messenger') is instantiated, this custom
        BeanPostProcessor implementation will output the fact to the system console
     -->
    <bean class="scripting.InstantiationTracingBeanPostProcessor"/>

</beans>

注意InstantiationTracingBeanPostProcessor是如此简单，甚至没有名字，由于被定义成一个bean，因而它跟其它的bean没什么两样（上面的配置中也定义了由Groovy脚本支持的bean，Spring2.0动态语言支持的细节请见Chapter 24, 动态语言支持）。

下面是测试代码：

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.scripting.Messenger;

public final class Boot {

    public static void main(final String[] args) throws Exception {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("scripting/beans.xml");
        Messenger messenger = (Messenger) ctx.getBean("messenger");
        System.out.println(messenger);
    }
}

上面程序执行时的输出将是（或象）下面这样：

Bean 'messenger' created : org.springframework.scripting.groovy.GroovyMessenger@272961
org.springframework.scripting.groovy.GroovyMessenger@272961

在Spring的BeanPostProcessor实现中调用标志接口或使用注解是扩展Spring IoC容器的常用方法。对于注解的用法详见Section 25.3.1, “@Required”，这里没有做深入的说明。通过定制BeanPostProcessor实现，可以使用注解来指定各种JavaBean属性值并在发布的时候被注入相应的bean中。

PropertyPlaceholderConfigurer是个bean工厂后置处理器的实现，可以将BeanFactory定义中的一些属性值放到另一个单独的标准Java Properties文件中。这就允许用户在部署应用时只需要在属性文件中对一些关键属性（例如数据库URL，用户名和密码）进行修改，而不用对主XML定义文件或容器所用文件进行复杂和危险的修改。

考虑下面的XML配置元数据定义，它用占位符定义了DataSource。我们在外部的Properties文件中配置一些相关的属性。在运行时，我们为元数据提供一个PropertyPlaceholderConfigurer，它将会替换dataSource的属性值。

<bean id="dataSource" destroy-method="close"
      class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="${jdbc.driverClassName}"/>
    <property name="url" value="${jdbc.url}"/>
    <property name="username" value="jdbc.username"/>
    <property name="password" value="${jdbc.password}"/>
</bean>

实际的值来自于另一个标准Java Properties格式的文件：

jdbc.driverClassName=org.hsqldb.jdbcDriver
jdbc.url=jdbc:hsqldb:hsql://production:9002
jdbc.username=sa
jdbc.password=root

PropertyPlaceHolderConfigurer如果在指定的Properties文件中找不到你想使用的属性，它还会在Java的System类属性中查找。这个行为可以通过设置systemPropertiesMode属性来定制，它有三个值：让配置一直覆盖、让它永不覆盖及让它仅仅在属性文件中找不到该属性时才覆盖。请参考PropertiesPlaceholderConfigurer的JavaDoc以获得更多的信息。

另一个bean工厂后置处理器PropertyOverrideConfigurer类似于PropertyPlaceholderConfigurer。但是与后者相比，前者对于bean属性可以有缺省值或者根本没有值。如果起覆盖作用的Properties文件没有某个bean属性的内容，那么将使用缺省的上下文定义。

bean工厂并不会意识到被覆盖，所以仅仅察看XML定义文件并不能立刻知道覆盖配置是否被使用了。在多个PropertyOverrideConfigurer实例中对一个bean属性定义了不同的值时，最后定义的值将被使用（由于覆盖机制）。

Properties文件的配置应该是如下的格式：

beanName.property=value

一个properties文件可能是下面这样的：

dataSource.driverClassName=com.mysql.jdbc.Driver
dataSource.url=jdbc:mysql:mydb

这个示例文件可用在这样一个bean容器：包含一个名为dataSource的bean，并且这个bean有driver和url属性。

注意它也支持组合的属性名称，只要路径中每个组件除了最后要被覆盖的属性外全都是非空的（比如通过构造器来初始化），在下例中：

foo.fred.bob.sammy=123

foo bean的fred属性的bob属性的sammy属性被设置为数值123。