Spring 2.5的新特性:配置简化和基于注解的功能

来源：InfoQ中文站作者：Mark Fisher/沙晓兰出处：巧巧读书 2008-01-09 进入讨论组

生命周期注解：@PostConstruct和＠PreDestroy

@PostConstruct 和@PreDestroy注解分别用来触发Spring的初始化和销毁回调。这个特性在原有基础上得到了扩展，但并没有替代在Spring2.5之前版本中提供的同样的回调的另两个选项。第一个选项是实现Spring的InitializingBean 和DisposableBean 接口中的一个或两个。这两个接口都需要一个回调方法的实现(分别是afterPropertiesSet()和destroy() )。这种基于接口的方法利用了Spring自动识别任何实现这些接口的Spring管理对象的能力，因而不再需要另外的配置。另一方面，Spring的一个关键目标是尽可能的非侵入。因此，许多Spring用户并不采用实现这些Spring特定接口的方法，而利用第二个选项，那就是提供他们自己的初始化和销毁方法。尽管入侵性小，但缺点在于使用这个方式的话就必须显式声明bean元素的init-method或destroy-method属性。显式配置有时候是必须的，例如当回调需要在开发人员控制能力之外的代码上被调用的时候。PetClinic应用程序很好地说明了这个场景。当它和JDBC配置一起运行的时候，会用到一个第三方DataSource，并且它显式声明了一个destroy-method。另外要注意到的是，单独的连接池数据源是dataSource的另一个部署选项，并且不需要修改任何代码。

id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close"
p:driverClassName="${jdbc.driverClassName}"
p:url="${jdbc.url}"
p:username="${jdbc.username}"
p:password="${jdbc.password}"/>

在使用Spring2.5的过程中，如果一个对象需要调用一个初始化的回调方法的话，这个回调方法可以采用@PostConstruct来注解。例如一个假想的例子，一个后台任务需要在启动的时候就开始对一个文件目录进行轮询：

public class FilePoller {
@PostConstruct
public void startPolling() {
...
}
...
}

类似地，一个在Spring管理对象上用@PreDestroy注解的方法会在这个对象寄宿的应用程序上下文（application context）关闭的时候被调用。

public class FilePoller {
@PreDestroy
public void stopPolling() {
...
}
...
}

在添加了对JSR-250注解的支持以后，现在的Spring2.5结合前面提到的两种生命周期方法的长处。将@PostConstruct和@PreDestroy作为方法层注解加入，足可以实现在受Spring管理的上下文（context）中触发回调。换句话说，不需要另外基于XML的配置。同时，这两个注解是Java语言本身的一部分（甚至被包括在Java SE 版本6中），所以无需引入特定Spring包。这两个注解拥有在其他环境中也能理解的标识语义的优点，随着时间的推移，Java开发人员可能会发现这些注解在第三方开发库中被越来越多的运用到。最后，基于注解生命周期回调的其中一个有趣的结果是，不止一个方法可以带有这两个注解中的任何一个，并且所有注解了的方法会被调用。

激活刚刚描述的关于@Resource 、@PostConstruct和@PreDestroy注解的所有行为，正如上文提到的，需要为Spring的CommonAnnotationBeanPostProcessor提供一个bean定义。但另一个更简练的方法则可能是使用2.5中的新的context命名空间：

<context:annotation-config/>

引入这个单个元素将不单单注册一个CommonAnnotationBeanPostProcessor，也会像下文将叙述的那样激活自动装配（autowire）行为。CommonAnnotationBeanPostProcessor也为@WebServiceRef 和@EJB注解提供支持。这些将在本文系列的第三篇中和Spring2.5为企业集成提供的其他新特性一起讨论。

利用注解来优化细粒度自动装配

涵盖Spring对自动装配支持的文档中常常会提到由于自动装配机制的粗粒度而伴随有很多限制性。Spring2.5之前，自动装配可以通过很多不同的方式来配置：构造器，类型setter，名字setter，或者自动侦测（在该方式中Spring选择自动装配一个构造器或者类型setter）。这些不同的选择确实提供了很大程度的灵活性，但它们中没有一个方法能够提供细粒度控制。换句话说，Spring2.5之前还不可能自动装配某个对象setter方法的特定子集，或者通过类型或名字来自动装配它的一些属性。结果，许多Spring用户意识到将自动装配应用到构建原型和测试中的好处，但当提到在产品中维护和支持系统时，大部分人认为，加入冗长的显式配置对于澄清它所担负的职责是非常值得的。

然而，Spring2.5大幅度地改变了布局。如上文所述，自动配置选项现在已经被扩展，支持JSR-250 @Resource注解来激活在每个方法或域基础上被命名资源的自动装配。然而，@Resource注解若单独使用的话有很多限制。因此，Sring2.5引进了一个名为@Autowired的注解进一步提高控制级别。为激活这里所讲的行为需要注册一个单独的bean定义：

class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

另外如上文提到的，context命名空间提供了一个更简明的方法。它将激活本文所讨论的两个post-processor（AutowiredAnnotationBeanPostProcessor和CommonAnnotationBeanPostProcessor）和我们在Spring2.0中引入的基于注解的post-processor：RequiredAnnotationBeanPostProcessor和PersistenceAnnotationBeanPostProcessor。

<context:annotation-config/>

利用@Autowired 注解可以对相应类型注入依赖。域、构造器和方法都可以激活此行为。实际上，aotowired方法并不一定要是setter方法，且可以接受多个参数。下面这个例子是完整的可接受的用法：

@Autowired
public void setup(DataSource dataSource, AnotherObject o) { ... }

默认地，标有@Autowired注解的依赖被认为是必须的。然而，也可以将required属性值设置为false来声明它们中的任何一个。在下面这个例子中，DefaultStrategy只有在context命名空间中没有SomeStrategy类型的Spring管理对象时才能被使用。

@Autowired(required=false)
private SomeStrategy strategy = new DefaultStrategy();

通过类型进行的自动装配明显地在Spring context包含多于一个期望类型的对象的时候造成歧义。默认地，如果一个必须的依赖没不是恰好一个bean与之对应的话，自动装配机制就会失败。同样的，对于任何一个可选属性，如果它拥有一个以上的候选，也都会失败（如果属性可选且没有任何候选可用的话，该属性则会被简单地跳过）。有很多不同的配置选项可以避免这些冲突。

转载:http://www.qqread.com/java/2008/01/f391815.html