从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的内置构造型之一）。请看下面这个例子：
public?class?ClinicController?{
private?final?Clinic?clinic;
public?ClinicController(Clinic?clinic)?{
}
?
自动侦测组件在Spring容器中注册，就像它们在XML中被定义一样。如上所示，那些对象可以轮流利用注解驱动的自动装配。
组件扫描的匹配规则可以通过过滤器（filter）来自定义，以根据类型、AspectJ表达式、或针对命名模式的正则表达式来决定包含或不包含哪些组件。默认的构造型也可以被禁用。比如这里有一个配置的例子，这个配置会忽略默认的构造型，但会自动侦测名字以Stub打头或者包含@Mock注解的所有类：
类型匹配的限制性也可以用排他的过滤器控制。例如，除了@Repository注解外其他都依赖于默认过滤器，那么就需要加入一个排他过滤器(exclude-filter)。
很明显，有很多方法可以扩展组件扫描来注册自定义的类型。构造型注解是最简单的选择，所以构造型概念本身也是可扩展的。像先前提到的，@Component是泛型模型，@Repository、@Service,和@Controller注解都从该构造型逻辑扩展而得。正因为如此，@Component可被用来作为元注解（也就是说，在另外的注解上声明的注解），所有具有@Component元注解的自定义注解都会被默认扫描匹配规则自动侦测到。一个例子就有希望让你领会到其实它根本没有听起来那么难。
让我们回想一下在讲@PostConstruct和@PreDestroy生命周期注解的时候的假想的后台任务。也许一个应用程序有很多很多这样的后台任务，这些任务实例需要XML bean定义以便在Spring context里注册并使它们自己的生命周期方法在正确时候被调用。利用组件扫描就不再需要这些显式的XML bean定义。如果这些后台任务都实现一个相同的接口或者都沿用同样的命名惯例，那么可以用include-filters。然而，更简单的方法是为这些任务对象创建一个注解并提供@Component元注解。
}?
然后在所有后台任务的类定义中提供自定义构造型注解。
泛型@Component注解可以像例子中提供的那样简单使用，自定义注解技术则提供了一个使用更具涵义的、领域特定的名字的机会。这些领域特定注解提供更深入的机会，比如使用AspectJ切点表达式来识别所有后台任务，以便增加advice来监控这些任务的活动性。
默认的，组件被侦测到的时候，Spring会自动生成一个没有修饰符的类名作为bean名字。上一个例子中，生成的bean名字会是filePoller。但是，任何加注了Spring构造型注解（@Component、@Repository、@Service或 @Controller）或是加注了其他的以@Component作为元注解的注解（比如上面例子中的@BackgroundTask ）的类，构造型注解的value属性可以被显式指定，实例将该值作为它的bean名字注册到context中。接下来的例子里，实例名应该是petClinic而不是默认生成的名字simpleJdbcClinic。
同样的，在下面修正版的FilePoller例子里，生成的bean名字应该是poller而不是filePoller。
虽然所有Spring管理对象都被默认地当作单例实例来处理，但有些时候还是有必要为某个对象指明一个备用的范围（scope）。举个例子来说，在web层，一个Spring管理对象可能捆绑到request或session的范围。对于2.0版本，Spring的scope机制更具延展性，这样一来，自定义scope可以被注册到应用程序上下文（application context）。在XML配置中，仅仅是简单地包含进scope属性及该scope的名字就可以了。
Spring2.5中，为被扫描的组件提供@Scope注解可以起到同样的作用。
这里要指出的最后一点是使用组件扫描时qualifier注解应用是多么的简单。在上一节，下面这个对象曾被作为使用自定义qualifier注解进行自动装配的例子：
同样的例子接着展现了在XML内使用‘qualifier’元素为依赖提供指定目标bean定义。在使用组件扫描时，XML元数据不是必须的。但自定义修饰符也许在目标类定义中被作为类型层注解而引入。另一个将被扫描的@Repository实例作为依赖的例子如下：
最终，因为前面的例子展现了自定义注解及其属性的例子，相等同的非XML表示依赖目标的方法如下：
小结
Spring2.5在很多方面都提供了很有意义的新功能。本文主要关注于怎样通过掌控Java注解的力量将配置简化。就如在JSR-250中定义的那样，Spring支持公共注解（Common Annotations），同时为自动装配过程的更细粒度的控制提供了额外注解。Spring2.5也扩展了从Spring2.0的@Repository就开始的构造型（stereotype）注解，并且所有这些构造型注解都可以和新的组件扫描功能结合使用。Spring2.5仍然全面支持基于XML的配置，同时它又引进了一个新的context命名空间对常见配置场景提供更精要的文法。实际上，支持XML和基于注解配置的无缝结合最终产生一个更为平衡的全面的方法。基本构架的复杂配置可以在模块XML文件中定义，而应用程序栈日益增多地更高层配置可以更多的从基于注解的技术中获益――前提是都在同一个Spring2.5应用程序context内。