Spring JSR-250注解

时间 2019-12-06

标签 spring jsr 注解栏目 Spring 繁體版

原文原文链接

注释配置相对于 XML 配置具备不少的优点：html

它能够充分利用 Java 的反射机制获取类结构信息，这些信息能够有效减小配置的工做。如使用 JPA 注释配置 ORM 映射时，咱们就不须要指定 PO 的属性名、类型等信息，若是关系表字段和 PO 属性名、类型都一致，您甚至无需编写任务属性映射信息——由于这些信息均可以经过 Java 反射机制获取。java
注释和 Java 代码位于一个文件中，而 XML 配置采用独立的配置文件，大多数配置信息在程序开发完成后都不会调整，若是配置信息和 Java 代码放在一块儿，有助于加强程序的内聚性。而采用独立的 XML 配置文件，程序员在编写一个功能时，每每须要在程序文件和配置文件中不停切换，这种思惟上的不连贯会下降开发效率。程序员

所以在不少状况下，注释配置比 XML 配置更受欢迎，注释配置有进一步流行的趋势。Spring 2.5 的一大加强就是引入了不少注释类，如今您已经可使用注释配置完成大部分 XML 配置的功能。在这篇文章里，咱们将向您讲述使用注释进行 Bean 定义和依赖注入的内容。web

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 spring
@PostConstructexpress
@PreDestroyapache

结合Spring，这些注解在任何开发环境下均可以使用——不管是否有应用程序服务器——甚至是集成测试环境均可以。激活这样的支持仅仅是注册一个单独的Spring post-processor的事情：编程

<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor"/> ruby

@Resource注解

@Resource 注解被用来激活一个命名资源（named resource）的依赖注入，在JavaEE应用程序中，该注解被典型地转换为绑定于JNDI context中的一个对象。 Spring确实支持使用@Resource 经过JNDI lookup来解析对象，默认地，拥有与@Resource 注解所提供名字相匹配的“bean name（bean名字）”的Spring管理对象会被注入。在下面的例子中，Spring会向加了注解的setter方法传递bean名为“dataSource”的Spring管理对象的引用。

@Resource(name="dataSource")
 public void setDataSource(DataSource dataSource) {
 this.dataSource = dataSource;
 }

直接使用@Resource 注解一个域（field）一样是可能的。经过不暴露setter方法，代码愈发紧凑而且还提供了域不可修改的额外益处。正以下面将要证实的，@Resource 注解甚至不须要一个显式的字符串值，在没有提供任何值的状况下，域名将被看成默认值。

@Resource
private DataSource dataSource; // inject the bean named 'dataSource'

该方式被应用到setter方法的时候，默认名是从相应的属性衍生出来，换句话说，命名为'setDataSource'的方法被用来处理名为'dataSource'的属性。

private DataSource dataSource;
 @Resource
 public void setDataSource(DataSource dataSource) {
 this.dataSource = dataSource;
 }

当@Resource 没有显式提供名字的时候，若是根据默认名字找不到对应的Spring管理对象，注入机制会回滚至类型匹配（type-match）。若是恰好只有一个Spring管理对象符合该依赖的类型，那么它会被注入。经过设置CommonAnnotationBeanPostProcessor 的‘fallbackToDefaultTypeMatch’属性为“false”（默认值是“true”）能够禁用这一特性。

<bean class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor">
 <property name="fallbackToDefaultTypeMatch" value="false"/>
 </bean>

正如上文所提到的，在解析标有@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也变得愈发简练：

<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/petclinic"/>

这个方法的优势在于间接层带来了巨大的部署弹性。好比说，一个单独的系统测试环境应该再也不须要JNDI注册。在这种状况下，在系统测试配置中能够提供以下的bean定义：

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"
 p:driverClassName="${jdbc.driverClassName}"
 p:url="${jdbc.url}"
 p:username="${jdbc.username}"
 p:password="${jdbc.password}"/>

顺便提一下，上面的例子中，实际的JDBC链接属性从一个属性文件（properties file）解析而来，在这个属性文件里，关键字与提供的${占位符}互相对应，这须要注册一个名为PropertyPlaceholderConfigurer的BeanFactoryPostProcessor实现来完成。这是具体化那些属性（一般是针对特定环境的属性）经常使用的技术，这些属性可能比其余配置修改得更为频繁。

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
 <property name="location" value="classpath:jdbc.properties"/>
 </bean>

Srping2.5中新加入了‘context’命名空间，这个命名空间让咱们可以获得更为简洁的方式来实现属性占位符（property placeholder）的配置：

<context:property-placeholder location="classpath:jdbc.properties"/>

生命周期注解：@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的另外一个部署选项，而且不须要修改任何代码。

<bean 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定义：

<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与之对应的话，自动装配机制就会失败。一样的，对于任何一个可选属性，若是它拥有一个以上的候选，也都会失败（若是属性可选且没有任何候选可用的话，该属性则会被简单地跳过）。有不少不一样的配置选项能够避免这些冲突。

若Context中拥有一个指定类型的一个主关键实例，对这个类型定义的bean定义应该包含‘primary’属性。当Context中含有其余可用实例的时候这个方法就很适用，但那些非主关键实例老是显式配置的。

<bean id="dataSource" primary="true"  />

在须要更多控制的时候，任何autowired的域、构造参数、或者方法参数能够进一步加注@Qualifier注解。qualifier能够包含一个字符串值，在这种状况下，Spring会试图经过名字来找到对应的对象。

@Autowired
 @Qualifier("primaryDataSource")
 private DataSource dataSource;

@Qualifier做为一个独立注解存在的主要缘由是它能够被应用在构造器参数或方法参数上，但上文提到的@Autowired注解只能运用在构造器或方法自己。

@Autowired
 public void setup(@Qualifier("primaryDataSource") DataSource dataSource, AnotherObject o) {  }

事实上，@Qualifier做为一个单独的注解在定制化方面提供了更多的好处。用户自定义的注解在自动装配过程当中也能够起到qualifier的做用，最简单的实现方式是在运用自定义注解的同时将@Qualifier做为它的元注解。

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Qualifier
 public @interface VetSpecialty {  }

自定义注解能够选择包含一个值来提供经过名字匹配的功能，但更广泛的用法是将它做为“标记”注解或定义一个对qualifier过程提供一些更多含义的值。例如，下面这个摘录则描绘了一个域，它应该和经过名字匹配获得的结果中合格的对象进行自动装配。

@Autowired
 @VetSpecialty("dentistry")
 private Clinic dentistryClinic;

在使用XML配置来达到依赖解析的目标时，'qualifier' 子元素能够被加注到bean定义中。在下文的组件扫描部分，咱们将呈现一个可供选择的非XML方法。

<bean id="dentistryClinic" class="samples.DentistryClinic">
 <qualifier type="example.VetSpecialty" value="dentistry"/>
 </bean>

为了不对@Qualifier注解的任何依赖性，能够在Spring context中提供一个CustomAutowireConfigurer的bean定义并直接注册全部自定义注解类型：

<bean class="org.springframework.beans.factory.annotation.CustomAutowireConfigurer">
 <property name="customQualifierTypes">
 <set>
 <value>example.VetSpecialty</value>
 </set>
 </property>
 </bean>

如今，自定义修饰符被显式声明了，就再也不须要@Qualifier这个元注解符了。

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 public @interface VetSpecialty {  }

其实，在配置AutowiredAnnotationBeanPostProcessor的时候，取代@Autowired注解都是有可能的。

<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor">
 <property name="autowiredAnnotationType" value="example.Injected"/>
 </bean>

大部分状况下，定义自定义‘标记’注解的能力结合经过名字或其余文法值进行匹配选项，足以完成自动装配过程的细粒度控制。但Spring还支持在qualifier注解上任意数目的任意属性。好比，下面是一个极为细粒度修饰的例子。

@SpecializedClinic(species="dog", breed="poodle")
 private Clinic poodleClinic;

自定义修饰符的实现应该定义这些属性：

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Qualifier
 public @interface SpecializedClinic {
 
 String species();
 
 String breed();
 
 }

自定义修饰符属性能够匹配那些XML中bean定义的qualifier注解的属性子元素。这些元素一般以键／值对方式提供。

<bean id="poodleClinic" class="example.PoodleClinic">
 <qualifier type="example.SpecializedClinic">
 <attribute key="species" value="dog"/>
 <attribute key="breed" value="poodle"/>
 </qualifier>
 </bean>

目前为止，关于autowire的描述都只是针对单独的实例，其实也支持集合。在任何须要获得全部context中某种特定类型的Spring管理对象的时候，只须要简单地在一个强类型（strongly-typed）集合上加注@Autowired 注解。

@Autowired
 private List<Clinic> allClinics;

本章节最后一个值得指出的特性是自动装配的使用替代了Spring的Aware接口。在Spring2.5以前，若是某个对象须要一个Spring context的ResourceLoader的引用，它能够经过实现ResourceLoaderAware的方式使得Spring经过setResourceLoader(ResourceLoader resourceLoader)方法来提供该依赖。借助一样的方法能够获得Spring管理的MessageSource的引用，甚至能够获得ApplicationContext自己。对于Spring2.5用户而言，这个行为如今经过autowiring获得全面支持（须要指出的是包含这些Spring特定依赖的时候应该考虑周到，特别是它们只能用于从业务逻辑清楚地分割出来的基础构架代码中）。

@Autowired
private MessageSource messageSource;

@Autowired
private ResourceLoader resourceLoader;

@Autowired
private ApplicationContext applicationContext;

自动侦测Spring组件

从2.0版本开始，Spring引入了构造型（stereotype）注解的概念以及将@Repository注解做为数据访问代码的标记的方法。在此基础上，Spring2.5又加入了两个新的注解 —— @Service 和@Controller 来完成为一般的三层架构（数据访问对象、服务、web控制器）角色委任。Spring2.5也引入了泛型@Component注解，其余构造型可从逻辑上对其进行扩展。经过清晰地指明应用程序的角色，这些构造型方便了Spring AOP和post-processor的使用，这些post-processor给基于这些角色的加了注解的对象提供了附加行为。好比，Spring2.0引入了PersistenceExceptionTranslationPostProcessor对任何带有@Repository 注解的对象自动激活其数据访问异常转换。

这些注解一样能够结合Spring2.5其余一些新性能来使用：自动侦测classpath上的组件。尽管XML已经成为最多见的Spring元数据的格式，但它决不是惟一选择。实际上，Spring容器内的元数据是由纯Java来表示的，当XML被用来定义Spring管理对象时，在实例化过程以前，那些定义会被解析并转化成Java对象。Spring2.5的一个巨大的新功能是支持从源码层注解读取元数据。于是，上文描述的自动装配机制使用注解的元数据来注入依赖，但它仍然须要注册至少一个bean定义以便提供每一个Spring管理对象的实现类。组件扫描功能则使得这个XML中最起码的bean定义都再也不存在需求性。

正如上面所示，Spring注解驱动的自动装配能够在不牺牲细粒度控制的前提下极大程度地减小XML的使用。组件侦测机制将这个优势更发扬光大。全面替代XML中的配置再也不必要，组件扫描反而能够处理XML元数据来简化总体配置。结合XML和注解驱动技术能够获得一个平衡优化的方法，这在2.5版本的PetClinic范例中有详细阐述。在该范例中，基础构架组件（数据源、事务管理等）结合上文提到的外化属性在XML中定义。数据访问层对象也有部分在XML中定义，它们的配置也都利用了@Autowired注解来简化依赖注入。最后，web层控制器彻底不在XML中显式定义，相反，下面提供的这段配置被用来触发全部web控制器的自动侦测：

<context:component-scan base-package="org.springframework.samples.petclinic.web"/>

须要注意到的是这段示例中使用到了base-package属性。组件扫描的默认匹配规则会递归侦测该包（多个包能够以逗号分隔的list方式提供）内的全部类的全部Spring构造型注解。正由于如此，PetClinic应用程序范例中的各种控制器的实现都采用了@Controller 注解（Spring的内置构造型之一）。请看下面这个例子：

@Controller
 public class ClinicController {
 
 private final Clinic clinic;
 
 @Autowired
 public ClinicController(Clinic clinic) {
 this.clinic = clinic;
 }

自动侦测组件在Spring容器中注册，就像它们在XML中被定义同样。如上所示，那些对象能够轮流利用注解驱动的自动装配。

组件扫描的匹配规则能够经过过滤器（filter）来自定义，以根据类型、AspectJ表达式、或针对命名模式的正则表达式来决定包含或不包含哪些组件。默认的构造型也能够被禁用。好比这里有一个配置的例子，这个配置会忽略默认的构造型，但会自动侦测名字以Stub打头或者包含@Mock 注解的全部类：

<context:component-scan base-package="example" use-default-filters="false">
 <context:include-filter type="aspectj" expression="example..Stub*"/>
 <context:include-filter type="annotation" expression="example.Mock"/>
 </context:component-scan>

类型匹配的限制性也能够用排他的过滤器控制。例如，除了@Repository注解外其余都依赖于默认过滤器，那么就须要加入一个排他过滤器(exclude-filter)。

<context:component-scan base-package="example">
 <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Repository"/>
 </context:component-scan>

很明显，有不少方法能够扩展组件扫描来注册自定义的类型。构造型注解是最简单的选择，因此构造型概念自己也是可扩展的。像先前提到的，@Component是泛型模型，@Repository、@Service ,和@Controller 注解都从该构造型逻辑扩展而得。正由于如此，@Component可被用来做为元注解（也就是说，在另外的注解上声明的注解），全部具备@Component元注解的自定义注解都会被默认扫描匹配规则自动侦测到。一个例子就有但愿让你领会到其实它根本没有听起来那么难。

让咱们回想一下在讲@PostConstruct和@PreDestroy生命周期注解的时候的假想的后台任务。也许一个应用程序有不少不少这样的后台任务，这些任务实例须要XML bean定义以便在Spring context里注册并使它们本身的生命周期方法在正确时候被调用。利用组件扫描就再也不须要这些显式的XML bean定义。若是这些后台任务都实现一个相同的接口或者都沿用一样的命名惯例，那么能够用include-filters。然而，更简单的方法是为这些任务对象建立一个注解并提供@Component元注解。

@Target({ElementType.TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 @Component
 public @interface BackgroundTask {
 String value() default "";
 }

而后在全部后台任务的类定义中提供自定义构造型注解。

@BackgroundTask
 public class FilePoller {
 
 @PostConstruct
 public void startPolling() {
 
 }
 
 @PreDestroy
 public void stopPolling() {
 
 }
 
 }

泛型@Component注解能够像例子中提供的那样简单使用，自定义注解技术则提供了一个使用更具涵义的、领域特定的名字的机会。这些领域特定注解提供更深刻的机会，好比使用AspectJ切点表达式来识别全部后台任务，以便增长advice来监控这些任务的活动性。

默认的，组件被侦测到的时候，Spring会自动生成一个没有修饰符的类名做为bean名字。上一个例子中，生成的bean名字会是filePoller。可是，任何加注了Spring构造型注解（@Component、@Repository、@Service 或 @Controller ）或是加注了其余的以@Component做为元注解的注解（好比上面例子中的@BackgroundTask ）的类，构造型注解的value属性能够被显式指定，实例将该值做为它的bean名字注册到context中。接下来的例子里，实例名应该是petClinic而不是默认生成的名字simpleJdbcClinic。

@Service("petClinic")
 public class SimpleJdbcClinic {
 
 }

一样的，在下面修正版的FilePoller例子里，生成的bean名字应该是poller而不是filePoller。

@BackgroundTask("poller")
 public class FilePoller {
 
 }

虽然全部Spring管理对象都被默认地看成单例实例来处理，但有些时候仍是有必要为某个对象指明一个备用的范围（scope）。举个例子来讲，在web层，一个Spring管理对象可能捆绑到request或session的范围。对于2.0版本，Spring的scope机制更具延展性，这样一来，自定义scope能够被注册到应用程序上下文（application context）。在XML配置中，仅仅是简单地包含进scope属性及该scope的名字就能够了。

<bean id="shoppingCart" class="example.ShoppingCart" scope="session">
 
 </bean>

Spring2.5中，为被扫描的组件提供@Scope注解能够起到一样的做用。

@Component
 @Scope("session")
 public class ShoppingCart {
 
 }

这里要指出的最后一点是使用组件扫描时qualifier注解应用是多么的简单。在上一节，下面这个对象曾被做为使用自定义qualifier注解进行自动装配的例子：

@VetSpecialty("dentistry")
 private Clinic dentistryClinic;

一样的例子接着展示了在XML内使用‘qualifier’元素为依赖提供指定目标bean定义。在使用组件扫描时，XML元数据不是必须的。但自定义修饰符也许在目标类定义中被做为类型层注解而引入。另外一个将被扫描的@Repository实例做为依赖的例子以下：

@Repository
 @VetSpecialty("dentistry")
 public class DentistryClinic implements Clinic {
 
 }

最终，由于前面的例子展示了自定义注解及其属性的例子，相等同的非XML表示依赖目标的方法以下：

@Repository
 @SpecializedClinic(species="dog", breed="poodle")
 public class PoodleClinic implements Clinic {
 
 }

小结

Spring2.5在不少方面都提供了颇有意义的新功能。本文主要关注于怎样经过掌控Java注解的力量将配置简化。就如在JSR-250中定义的那样，Spring支持公共注解（Common Annotations），同时为自动装配过程的更细粒度的控制提供了额外注解。Spring2.5也扩展了从Spring2.0的@Repository就开始的构造型（stereotype）注解，而且全部这些构造型注解均可以和新的组件扫描功能结合使用。Spring2.5仍然全面支持基于XML的配置，同时它又引进了一个新的context命名空间对常见配置场景提供更精要的文法。实际上，支持XML和基于注解配置的无缝结合最终产生一个更为平衡的全面的方法。基本构架的复杂配置能够在模块XML文件中定义，而应用程序栈日益增多地更高层配置能够更多的从基于注解的技术中获益——前提是都在同一个Spring2.5应用程序context内。

本文转自:http://www.cnblogs.com/rubys/archive/2009/02/04/1384139.html