Spring JSR-250注解
Spring JSR-250注解
注释配置相对于 XML 配置具有很多的优势：
- 它可以充分利用 Java 的反射机制获取类结构信息，这些信息可以有效减少配置的工作。如使用 JPA 注释配置 ORM 映射时，我们就不需要指定 PO 的属性名、类型等信息，如果关系表字段和 PO 属性名、类型都一致，您甚至无需编写任务属性映射信息——因为这些信息都可以通过 Java 反射机制获取。
- 注释和 Java 代码位于一个文件中，而 XML 配置采用独立的配置文件，大多数配置信息在程序开发完成后都不会调整，如果配置信息和 Java 代码放在一起，有助于增强程序的内聚性。而采用独立的 XML 配置文件，程序员在编写一个功能时，往往需要在程序文件和配置文件中不停切换，这种思维上的不连贯会降低开发效率。
因此在很多情况下，注释配置比 XML 配置更受欢迎，注释配置有进一步流行的趋势。Spring 2.5 的一大增强就是引入了很多注释类，现在您已经可以使用注释配置完成大部分 XML 配置的功能。在这篇文章里，我们将向您讲述使用注释进行 Bean 定义和依赖注入的内容。
Java EE5中引入了“Java平台的公共注解（Common Annotations for the Java Platform）”，而且该公共注解从Java SE 6一开始就被包含其中。 2006年5月，BEA系统宣布了他们在一个名为Pitchfork的项目上与Interface21的合作，该项目提供了基于Spring的Java EE 5编程模型的实现，包括支持用于注入（injection）、拦截（ interception）和事务处理（transactions）的JSR-250注解和EJB 3注解(JSR-220)。 在2.5版本中，Spring框架的核心（core）现在支持以下JSR-250注解：
- @Resource
- @PostConstruct
- @PreDestroy
结合Spring，这些注解在任何开发环境下都可以使用——无论是否有应用程序服务器——甚至是集成测试环境都可以。激活这样的支持仅仅是注册一个单独的Spring post-processor的事情：
< bean class ="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor" />
@Resource注解
@Resource 注解被用来激活一个命名资源（named resource）的依赖注入，在JavaEE应用程序中，该注解被典型地转换为绑定于JNDI context中的一个对象。 Spring确实支持使用@Resource通过JNDI lookup来解析对象，默认地，拥有与@Resource注解所提供名字相匹配的“bean name（bean名字）”的Spring管理对象会被注入。 在下面的例子中，Spring会向加了注解的setter方法传递bean名为“dataSource”的Spring管理对象的引用。
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
}
直接使用@Resource注解一个域（field）同样是可能的。通过不暴露setter方法，代码愈发紧凑并且还提供了域不可修改的额外益处。正如下面将要证明的，@Resource注解甚至不需要一个显式的字符串值，在没有提供任何值的情况下，域名将被当作默认值。
该方式被应用到setter方法的时候，默认名是从相应的属性衍生出来，换句话说，命名为'setDataSource'的方法被用来处理名为'dataSource'的属性。
当@Resource没有显式提供名字的时候，如果根据默认名字找不到对应的Spring管理对象，注入机制会回滚至类型匹配（type-match）。如果刚好只有一个Spring管理对象符合该依赖的类型，那么它会被注入。通过设置CommonAnnotationBeanPostProcessor 的‘fallbackToDefaultTypeMatch’属性为“false”（默认值是“true”）可以禁用这一特性。
正如上文所提到的，在解析标有@Resource注解的依赖时，Spring支持JNDI-lookup。如若要强制对所有使用@Resource注解的依赖进行JNDI lookup，那也只要将CommonAnnotationBeanPostProcessor的'alwaysUseJndiLookup' 标识设置为true就可以了（默认值是false）。
<
bean
class
="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor"
>
<
property
name
="alwaysUseJndiLookup"
value
="true"
/>
</
bean
>
另一个选择是，激活指定为‘resource-ref-mappings’的依据全局JNDI名的查找，在@Resource注解内提供‘mappedName’属性。即使目标对象实际上是一个JNDI资源，仍然推荐引入一个Spring管理对象，这样可以提供一个间接层并且因此降低耦合程度。自Spring2.0开始添加命名空间以来，定义一个委托Spring处理JNDI lookup的bean也变得愈发简练：
这个方法的优点在于间接层带来了巨大的部署弹性。比如说，一个单独的系统测试环境应该不再需要JNDI注册。在这种情况下，在系统测试配置中可以提供如下的bean定义：
顺便提一下，上面的例子中，实际的JDBC连接属性从一个属性文件（properties file）解析而来，在这个属性文件里，关键字与提供的${占位符}互相对应，这需要注册一个名为PropertyPlaceholderConfigurer的BeanFactoryPostProcessor实现来完成。这是具体化那些属性（通常是针对特定环境的属性）常用的技术，这些属性可能比其他配置修改得更为频繁。
Srping2.5中新加入了‘context’命名空间，这个命名空间让我们能够得到更为简洁的方式来实现属性占位符（property placeholder）的配置：
生命周期注解：@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的另一个部署选项，并且不需要修改任何代码。
在使用Spring2.5的过程中，如果一个对象需要调用一个初始化的回调方法的话，这个回调方法可以采用@PostConstruct来注解。例如一个假想的例子，一个后台任务需要在启动的时候就开始对一个文件目录进行轮询：
public void startPolling() {
}
类似地，一个在Spring管理对象上用@PreDestroy注解的方法会在这个对象寄宿的应用程序上下文（application context）关闭的时候被调用。
在添加了对JSR-250注解的支持以后，现在的Spring2.5结合前面提到的两种生命周期方法的长处。将@PostConstruct和@PreDestroy作为方法层注解加入，足可以实现在受Spring管理的上下文（context）中触发回调。换句话说，不需要另外基于XML的配置。同时，这两个注解是Java语言本身的一部分（甚至被包括在Java SE 版本6中），所以无需引入特定Spring包。这两个注解拥有在其他环境中也能理解的标识语义的优点，随着时间的推移，Java开发人员可能会发现这些注解在第三方开发库中被越来越多的运用到。最后，基于注解生命周期回调的其中一个有趣的结果是，不止一个方法可以带有这两个注解中的任何一个，并且所有注解了的方法会被调用。
激活刚刚描述的关于@Resource 、@PostConstruct和@PreDestroy注解的所有行为，正如上文提到的，需要为Spring的CommonAnnotationBeanPostProcessor提供一个bean定义。但另一个更简练的方法则可能是使用2.5中的新的context命名空间：
引入这个单个元素将不单单注册一个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定义：
另外如上文提到的，context命名空间提供了一个更简明的方法。它将激活本文所讨论的两个post-processor（AutowiredAnnotationBeanPostProcessor和CommonAnnotationBeanPostProcessor）和我们在Spring2.0中引入的基于注解的post-processor：RequiredAnnotationBeanPostProcessor和PersistenceAnnotationBeanPostProcessor。
利用@Autowired 注解可以对相应类型注入依赖。域、构造器和方法都可以激活此行为。实际上，aotowired方法并不一定要是setter方法，且可以接受多个参数。下面这个例子是完整的可接受的用法：
默认地，标有@Autowired注解的依赖被认为是必须的。然而，也可以将required属性值设置为false来声明它们中的任何一个。在下面这个例子中，DefaultStrategy只有在context命名空间中没有SomeStrategy类型的Spring管理对象时才能被使用。
通过类型进行的自动装配明显地在Spring context包含多于一个期望类型的对象的时候造成歧义。默认地，如果一个必须的依赖没不是恰好一个bean与之对应的话，自动装配机制就会失败。同样的，对于任何一个可选属性，如果它拥有一个以上的候选，也都会失败（如果属性可选且没有任何候选可用的话，该属性则会被简单地跳过）。有很多不同的配置选项可以避免这些冲突。
若Context中拥有一个指定类型的一个主关键实例，对这个类型定义的bean定义应该包含‘primary’属性。当Context中含有其他可用实例的时候这个方法就很适用，但那些非主关键实例总是显式配置的。
在需要更多控制的时候，任何autowired的域、构造参数、或者方法参数可以进一步加注@Qualifier注解。qualifier可以包含一个字符串值，在这种情况下，Spring会试图通过名字来找到对应的对象。
@Qualifier作为一个独立注解存在的主要原因是它可以被应用在构造器参数或方法参数上，但上文提到的@Autowired注解只能运用在构造器或方法本身。
事实上，@Qualifier作为一个单独的注解在定制化方面提供了更多的好处。用户自定义的注解在自动装配过程中也可以起到qualifier的作用，最简单的实现方式是在运用自定义注解的同时将@Qualifier作为它的元注解。
自定义注解可以选择包含一个值来提供通过名字匹配的功能，但更普遍的用法是将它作为“标记”注解或定义一个对qualifier过程提供一些更多含义的值。例如，下面这个摘录则描绘了一个域，它应该和通过名字匹配得到的结果中合格的对象进行自动装配。
在使用XML配置来达到依赖解析的目标时，'qualifier' 子元素可以被加注到bean定义中。在下文的组件扫描部分，我们将呈现一个可供选择的非XML方法。
为了避免对@Qualifier注解的任何依赖性，可以在Spring context中提供一个CustomAutowireConfigurer的bean定义并直接注册所有自定义注解类型：
现在，自定义修饰符被显式声明了，就不再需要@Qualifier这个元注解符了。
其实，在配置AutowiredAnnotationBeanPostProcessor的时候，取代@Autowired注解都是有可能的。
大部分情况下，定义自定义‘标记’注解的能力结合通过名字或其他文法值进行匹配选项，足以完成自动装配过程的细粒度控制。但Spring还支持在qualifier注解上任意数目的任意属性。比如，下面是一个极为细粒度修饰的例子。
自定义修饰符的实现应该定义这些属性：
自定义修饰符属性可以匹配那些XML中bean定义的qualifier注解的属性子元素。这些元素通常以键／值对方式提供。
目前为止，关于autowire的描述都只是针对单独的实例，其实也支持集合。在任何需要得到所有context中某种特定类型的Spring管理对象的时候，只需要简单地在一个强类型（strongly-typed）集合上加注@Autowired 注解。
本章节最后一个值得指出的特性是自动装配的使用替代了Spring的Aware接口。在Spring2.5之前，如果某个对象需要一个Spring context的ResourceLoader的引用，它可以通过实现ResourceLoaderAware的方式使得Spring通过setResourceLoader(ResourceLoader resourceLoader)方法来提供该依赖。借助同样的方法可以得到Spring管理的MessageSource的引用，甚至可以得到ApplicationContext本身。对于Spring2.5用户而言，这个行为现在通过autowiring得到全面支持（需要指出的是包含这些Spring特定依赖的时候应该考虑周到，特别是它们只能用于从业务逻辑清楚地分割出来的基础构架代码中）。
![]()
分享到：
发表评论
评论