spring 注解（转）
spring 注解
关键字: spring
????
正如上文所提到的，在解析标有@Resource注解的依赖时，Spring支持JNDI-lookup。如若要强制对所有使用@Resource注解的依赖进行JNDI lookup，那也只要将CommonAnnotationBeanPostProcessor的'alwaysUseJndiLookup' 标识设置为true就可以了（默认值是false）。
另一个选择是，激活指定为‘resource-ref-mappings’的依据全局JNDI名的查找，在@Resource注解内提供‘mappedName’属性。即使目标对象实际上是一个JNDI资源，仍然推荐引入一个Spring管理对象，这样可以提供一个间接层并且因此降低耦合程度。自Spring2.0开始添加命名空间以来，定义一个委托Spring处理JNDI lookup的bean也变得愈发简练：
这个方法的优点在于间接层带来了巨大的部署弹性。比如说，一个单独的系统测试环境应该不再需要JNDI注册。在这种情况下，在系统测试配置中可以提供如下的bean定义：
Srping2.5中新加入了‘context’命名空间，这个命名空间让我们能够得到更为简洁的方式来实现属性占位符（property placeholder）的配置：
在需要更多控制的时候，任何autowired的域、构造参数、或者方法参数可以进一步加注@Qualifier注解。qualifier可以包含一个字符串值，在这种情况下，Spring会试图通过名字来找到对应的对象。
为了避免对@Qualifier注解的任何依赖性，可以在Spring context中提供一个CustomAutowireConfigurer的bean定义并直接注册所有自定义注解类型：
大部分情况下，定义自定义‘标记’注解的能力结合通过名字或其他文法值进行匹配选项，足以完成自动装配过程的细粒度控制。但Spring还支持在qualifier注解上任意数目的任意属性。比如，下面是一个极为细粒度修饰的例子。
目前为止，关于autowire的描述都只是针对单独的实例，其实也支持集合。在任何需要得到所有context中某种特定类型的Spring管理对象的时候，只需要简单地在一个强类型（strongly-typed）集合上加注@Autowired 注解。
自动侦测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控制器的自动侦测：
?