空间站

BeanFactory能够自动装配合作bean之间的关系。这就意味着，让Spring通过检查BeanFactory的内容来自动装配你的bean的合作者（也就是其他的bean）。自动装配功能有5种模式。自动装配可以指定给每一个bean，因此可以给一些bean使用而其他的bean不自动装配。通过使用自动装配，可以 减少（或消除）指定属性（或构造函数参数）的需要，显著节省键入工作。 ^[1] 在XmlBeanFactory中，使用bean元素的autowire属性来指定bean定义的自动装配模式。以下是允许的值.

注意：显式的指定依赖，比如property和constructor-arg元素，总会覆盖自动装配。自动装配的行为可以和依赖检查结合使用，依赖检查会在自动装配完成后发生。

注意：正如我们已经提到过的，对于大型的应用，自动装配不鼓励使用，因为它去除了你的合作类的透明性和结构。

对于部署在BeanFactory的bean的未解决的依赖，Spring有能力去检查它们的存在性。 这些依赖要么是bean的JavaBean式的属性，在bean的定义中并没有为它们设置真实的值， 要么是通过自动装配特性被提供。

当你想确保所有的属性（或者某一特定类型的所有属性）都被设置到bean上面的时候， 这项特性就很有用了。当然，在很多情况下一个bean类的很多属性都会有缺省的值， 或者一些属性并不会应用到所有的应用场景，那么这个特性的作用就有限了 。 依赖检查能够分别对每一个bean应用或取消应用，就像自动装配功能一样。缺省的是不 检查依赖关系。 依赖检查可以以几种不同的模式处理。在XmlBeanFactory中， 通过bean定义中的 dependency-check 属性来指定依赖检查，这个属性有以下的值。

一个bean定义可能会包含大量的配置信息，包括容器相关的信息（比如初始化方法，静态工厂方法名等等）以及构造函数参数和属性的值。一个子bean定义是一个能够从父bean定义继承配置数据的bean定义。 它可以覆盖一些值，或者添加一些其他需要的值。使用父和子的bean定义可以节省很多的输入工作。实际上，这就是一种模版形式。

当以编程的方式使用一个BeanFactory，子bean定义用ChildBeanDefinition类表示。 大多数的用户从来不需要以这个方式使用它们，而是在类似XmlBeanFactory的BeanFactory 中以声明的方式配置bean定义。在一个XmlBeanFactory的bean定义中，使用parent属性指出一个子bean定义，而父bean则作为这个属性的值。

<bean  >
<property ><value>parent</value></property>
<property ><value>1</value></property>
</bean>
<bean
parent="inheritedTestBean" init-method="initialize">
<property ><value>override</value></property>
<!-- age should inherit value of 1 from parent -->
</bean>

这个父bean就无法自己实例化；它实际上仅仅是一个纯模版或抽象bean，充当子定义的父定义。 若要尝试单独使用这样的父bean（比如将它作为其他bean的ref属性而引用，或者直接使用这个父 bean的id调用getBean()方法），将会导致一个错误。同样地，容器内部的preInstantiateSingletons方法会完全忽略这种既没有parent属性也没有class属性的bean定义，因为它们是不完整的。

特别注意：这里并没有办法显式地声明一个bean定义为抽象的。 如果一个bean确实有一个class属性定义，那么它就能够被实例化。而且要注意 XmlBeanFactory默认地将会预实例化所有的singleton的bean。 因此很重要的一点是：如果你有一个（父）bean定义指定了class属性，而你又想仅仅把它当作模板使用， 那么你必须保证将lazy-init属性设置为true（或者将bean标记为non-singleton），否则 XmlBeanFactory（以及其他可能的容器）将会预实例化它。

BeanFactory本质上不过是高级工厂的接口，它维护不同bean和它们所依赖的bean的注册。 BeanFactory使得你可以利用 bean工厂读取和访问bean定义。 当你使用BeanFactory的时候，你可以象下面一样创建并且读入一些XML格式的bean定义：

InputStream is = new FileInputStream("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(is);

基本上这就足够了。使用getBean(String)你可以取得你的bean的实例。 如果你将它定义为一个singleton（缺省的）你将会得到同一个bean的引用， 如果你将singleton设置为false，那么你将会每次得到一个新的实例。 在客户端的眼里BeanFactory是惊人的简单。BeanFactory接口仅仅为客户端调用提供了5个方法：

一个bean post-processor是一个实现了org.springframework.beans.factory.config.BeanPostProcessor的类，它包含两个回调方法。当这样的一个类作为BeanFactory的post-processor注册时，对于这个BeanFactory创建的每一个bean实例，在任何初始化方法（afterPropertiesSet和用init-method属性声明的方法）被调用之前和之后，post-processor将会从BeanFactory分别得到一个回调。post-processor可以对这个bean做任何操作事情，包括完全忽略这个回调。一个bean post-processor通常用来检查标记接口，或者做一些诸如将一个bean包装成一个proxy的事情。一些Spring的助手类就是作为bean post-processor而实现的。

有一点很重要，BeanFactory和ApplicationContext对待bean post-processor有少许不同。 一个ApplicationContext会自动监测到任何部署在它之上的实现了 BeanPostProcessor接口的bean， 并且把它们作为post-processor注册，然后factory就会在bean创建的时候恰当地调用它们。 部署一个post-processor同部属一个其他的bean并没有什么区别。而另一方面，当使用普通的BeanFactory的时候， 作为post-processor的bean必须通过类似下面的代码来手动地显式地注册：

ConfigurableBeanFactory bf = new .....;     // create BeanFactory
...                       // now register some beans
// now register any needed BeanPostProcessors
MyBeanPostProcessor pp = new MyBeanPostProcessor();
bf.addBeanPostProcessor(pp);
// now start using the factory
...

因为手工的注册不是很方便，而且ApplicationContext是BeanFactory功能上扩展，所以通常建议当需要post-processor的时候最好使用ApplicationContext。

一个bean factory post-processor是一个实现了org.springframework.beans.factory.config.BeanFactoryPostProcessor接口的类。它将会被手动执行（BeanFactory的时候）或自动执行（ApplicationContext的时候），在BeanFactory构造出来后， 对整个BeanFactory做某种修改。Spring包含很多已存在的bean factory post-processor， 比如PropertyResourceConfigurer和PropertyPlaceHolderConfigurer（这两个将在下面介绍），以及BeanNameAutoProxyCreator对其他bean进行事务包装或者用其他的proxy进行包装，将会在后面叙述。BeanFactoryPostProcessor也能用来添加自定义的editor（可参见第 4.3.2 节 “内建的(PropertyEditors)和类型转换 ”）。

在BeanFactory中，使用BeanFactoryPostProcessor是手动的，将类似于下面:

XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml"));
// create placeholderconfigurer to bring in some property
// values from a Properties file
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));
// now actually do the replacement
cfg.postProcessBeanFactory(factory);

ApplicationContext将会检测它所部署的实现了BeanFactoryPostProcessor 接口的bean，然后在适当的时候将它们作为bean factory post-processor而使用。部署这些post-processor与部署其他的bean并没有什么区别。

因为这个手动的步骤并不方便，而且ApplicationContext是BeanFactory的功能扩展，所以当需要使用bean factory post-processor的时候通常建议使用ApplicationContext

<bean   destroy-method="close">
<property ><value>${jdbc.driverClassName}</value></property>
<property ><value>${jdbc.url}</value></property>
<property ><value>${jdbc.username}</value></property>
<property ><value>${jdbc.password}</value></property>
</bean>

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

XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml"));
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));
cfg.postProcessBeanFactory(factory);

beanName.property=value

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

当用字符串值设置bean的属性时，BeanFactory实质上使用了标准的JavaBeans 的PropertyEditor将这些String转换为属性的复杂类型。Spring预先注册了很多定制的PropertyEditor（比如，将一个字符串表示的classname转换成真正的Class对象）。另外，一个类的PropertyEditor如果被恰当地命名并且放在与它提供支持的类同一个包内，那么Java标准的JavaBeans PropertyEditor查找机制就会自动找到这个PropertyEditor。

如果需要注册其他定制的PropertyEditor，这里也有几个可用的机制。

最手动的方法，也是通常不方便和不推荐的，就是简单地使用ConfigurableBeanFactory接口的registerCustomEditor()方法，假定你已经有一个BeanFactory引用。

比较方便的机制是，使用一个特殊的叫CustomEditorConfigurer的bean factory post-precessor。尽管bean factory post-processor能够和BeanFactory半手动地使用，但是它有一个嵌套的属性设置。所以强烈建议，就象这里描述的，它能够和ApplicationContxt一起使用，这样它就可以以其它bean的方式被部署，并且被自动监测和应用。

beans包提供了以编程的方式管理和操控bean的基本功能，而context包增加了ApplicationContext，它以一种更加面向框架的方式增强了BeanFactory的功能。多数用户可以以一种完全的声明式方式来使用ApplicationContext，甚至不用去手动创建它，但是却去依赖象ContextLoader的支持类，在J2EE的的web应用的启动进程中用它启动ApplicationContext。当然，这种情况下还是可以以编程的方式创建一个ApplicationContext。

Context包的基础是位于org.springframework.context包中的ApplicationContext接口。它是由BeanFactory接口集成而来，提供BeanFactory所有的功能。为了以一种更向面向框架的方式工作，context包使用分层和有继承关系的上下文类，包括：

因为ApplicationContext包括了BeanFactory所有的功能，所以通常建议先于BeanFactory使用，除了有限的一些场合比如在一个Applet中，内存的消耗是关键的，每kb字节都很重要。接下来的章节将叙述ApplicationContext在BeanFactory的基本能力上增建的功能。

正如上面说明的那样，ApplicationContext有几个区别于BeanFactory的特性。让我们一个一个地讨论它们。

<beans>
<bean
>
<property >
<list>
<value>format</value>
<value>exceptions</value>
<value>windows</value>
</list>
</property>
</bean>
</beans> 

<bean  >
<property >
<list>
<value>black@list.org</value>
<value>white@list.org</value>
<value>john@doe.org</value>
</list>
</property>
</bean>
<bean  >
<property >
<value>spam@list.org</value>
</property>
</bean>

public class EmailBean implements ApplicationContextAware {
/** the blacklist */
private List blackList;
public void setBlackList(List blackList) {
this.blackList = blackList;
}
public void setApplicationContext(ApplicationContext ctx) {
this.ctx = ctx;
}
public void sendEmail(String address, String text) {
if (blackList.contains(address)) {
BlackListEvent evt = new BlackListEvent(address, text);
ctx.publishEvent(evt);
return;
}
// send email
}
}
public class BlackListNotifier implement ApplicationListener {
/** notification address */
private String notificationAddress;
public void setNotificationAddress(String notificationAddress) {
this.notificationAddress = notificationAddress;
}
public void onApplicationEvent(ApplicationEvent evt) {
if (evt instanceof BlackListEvent) {
// notify appropriate person
}
}
}

BeanFactory已经提供了许多机制来控制部署在其中的bean的生命周期（比如象InitializingBean或DisposableBean的标志接口，它们的配置效果和XmlBeanFactory配置中的init-method和destroy-method属性以及bean post-processor是相同的。在ApplicationContext中，这些也同样可以工作，但同时也增加了一些用于定制bean和容器行为的机制。

<!-- property placeholder post-processor -->
<bean
>
<property ><value>jdbc.properties</value></property>
</bean>

正如前面曾提到的，Spring使用标准的JavaBeans的PropertyEditor将字符串形式表示的属性值转换为属性真实的复杂的类型。CustomEditorConfigurer，这个bean factory post-processor可以使ApplicationContext很方便地增加对额外的PropertyEditor的支持。

考虑一个用户类ExoticType，以及另外一个需要ExoticType作为属性的DependsOnExoticType类：

public class ExoticType {
private String name;
public ExoticType(String name) {
this.name = name;
}
}
public class DependsOnExoticType {
private ExoticType type;
public void setType(ExoticType type) {
this.type = type;
}
}

当设置好的时候，我们希望能够以字符串的形式指定属性，同时背后的PropertyEditor会将这个字符串转换为一个真正的Exotic类型的对象：

<bean  >
<property ><value>aNameForExoticType</value></property>
</bean>

而这个PorpertyEditor看起来象下面这样：

// converts string representation to ExoticType object
public class ExoticTypeEditor extends PropertyEditorSupport {
private String format;
public void setFormat(String format) {
this.format = format;
}
public void setAsText(String text) {
if (format != null && format.equals("upperCase")) {
text = text.toUpperCase();
}
ExoticType type = new ExoticType(text);
setValue(type);
}
}

最后，我们用CustomEditorConfigurer将新的PropertyEditor注册到ApplicationContext上，然后ApplicationContext就可以在需要的时候使用这个PropertyEditor了：

<bean
>
<property >
<map>
<entry key="example.ExoticType">
<bean >
<property >
<value>upperCase</value>
</property>
</bean>
</entry>
</map>
</property>
</bean>

有些时候，需要用容器中另一个bean的方法返回值来设置一个bean的属性，或者使用其它任意类（不一定是容器中的bean）的静态方法的返回值来设置。此外，有些时候，需要调用一个静态或非静态的方法来执行某些初始化工作。对于这两个目的，可以使用MethodInvokingFactoryBean助手类。它是一个FactoryBean，可以返回一个静态或非静态方法的调用结果。

下面是一个基于XML的BeanFactory的bean定义的例子，它使用那个助手类调用静态工厂方法：

<bean  >
<property ><value>com.whatever.MyClassFactory.getInstance</value></property>
</bean>

下面这个例子先调用一个静态方法，然后调用一个实例方法，来获得一个Java System的属性。虽然有点罗嗦，但是可以工作：

<bean  >
<property ><value>java.lang.System</value></property>
<property ><value>getProperties</value></property>
</bean>
<bean  >
<property ><ref local="sysProps"/></property>
<property ><value>getProperty</value></property>
<property >
<list>
<value>java.version</value>
</list>
</property>
</bean>

注意，实际上这个类多半用来访问工厂方法，所以MethodInvokingFactoryBean默认以singleton方式进行操作。经由容器的第一次请求工厂生成对象将会引起调用特定的工厂方法，它的返回值将会被缓存并且返回供这次请求和以后的请求使用。这个工厂的一个内部singleton属性可以被设置为false，从而导致每次对象的请求都会调用那个目标方法。

通过设置targetMethod属性为一个静态方法名的字符串来指定静态目标方法，而设置targetClass为定义静态方法的类。或者，通过设置targetObject属性目标对象，设置targetMethod属性要在目标对象上调用的方法名，来指定目标实例方法。方法调用的参数可以通过设置args属性来指定。

与BeanFactory总是以编程的方式创建相反，ApplicationContext可以通过使用比如ContextLoader声明式地被创建。当然你也可以用ApplicationContext的任一种实现来以编程的方式创建它。首先，我们来看看ContextLoader以及它的实现。

ContextLoader有两个实现：ContextLoaderListener和ContextLoaderServlet。它们两个有着同样的功能，除了listener不能在Servlet 2.2兼容的容器中使用。自从Servelt 2.4规范，listener被要求在web应用启动后初始化。很多2.3兼容的容器已经实现了这个特性。使用哪一个取决于你自己，但是如果所有的条件都一样，你大概会更喜欢ContextLoaderListener；关于兼容方面的更多信息可以参照ContextLoaderServlet的JavaDoc。

你可以象下面这样用ContextLoaderListener注册一个ApplicationContext：

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- OR USE THE CONTEXTLOADERSERVLET INSTEAD OF THE LISTENER
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
-->

这个listener需要检查contextConfigLocation参数。如果不存在的话，它将默认使用/WEB-INF/applicationContext.xml。如果它存在，它就会用预先定义的分隔符（逗号，分号和空格）分开分割字符串，并将这些值作为应用上下文将要搜索的位置。ContextLoaderServlet可以用来替换ContextLoaderListener。这个servlet像listener那样使用contextConfigLocation参数。

一个应用中的大多数代码最好写成依赖注射（反向控制）的风格，这样这些代码就和BeanFactory容器或者ApplicationContext容器无关，它们在被创建的时候从容器处得到自己的依赖，并且完全不知道容器的存在。然而，对于少量需要与其它代码粘合的粘合层代码来说，有时候就需要以一种singleton（或者类似singleton）的方式来访问BeanFactory或ApplicationContext。举例来说，第三方的代码可能想要（以Class.forName()的方式）直接构造一个新的对象，却没办法从BeanFactory中得到这些对象。如果第三方代码构造的对象只是一个小的stub或proxy，并且使用singleton方式访问BeanFactroy/ApplicationContext来获得真正的对象，大多数的代码（由BeanFactory产生的对象）仍然可以使用反向控制。因此大多数的代码依然不需要知道容器的存在，或者容器是如何被访问的，并保持和其它代码解耦，有着所有该有的益处。EJB也可以使用这种stub/proxy方案代理到一个普通的BeanFactory产生的java实现的对象。虽然理想情况下BeanFactory不需要是一个singleton，但是如果每个bean使用它自己的non-singleton的BeanFactory，对于内存使用或初始化次数都是不切实际。

另一个例子，在一个多层的复杂的J2EE应用中（比如有很多JAR，EJB，以及WAR打包成一个EAR），每一层都有自己的ApplicationContext定义（有效地组成一个层次结构），如果顶层只有一个web-app（WAR）的话，比较好的做法是创建一个由不同层的XML定义文件组成的组合ApplicationContext。所有的ApplicationContext变体都可以从多个定义文件以这种方式构造出来。但是，如果在顶层有多个兄弟web-apps，为每一个web-app创建一个ApplicationContext，但是每个ApplicationContext都包含大部分相同的底层的bean定义，这就会因为内存使用而产生问题，因为创建bean的多个copy会花很长时间初始化（比如Hibernate SessionFactory），以及其它可能产生的副作用。作为替换，诸如ContextSingletonBeanFactoryLocator和SingletonBeanFactoryLocator的类可以在需要的时候以有效的singleton方式，加载多个层次的（比如一个是另一个的父亲）BeanFactory或ApplicationContext，这些将会作为web-app ApplicationContext的parents。这样做的结果就是，底层的bean定义只在需要的时候加载并且只被加载一次。