簡介
從誕生之初，Spring框架就堅守它的宗旨：簡化企業級應用開發，同時給復雜問題提供強大的、非侵入性解決方案。一年前發布的Spring 2.0就把這些主題推到了一個新的高度。XML Schema的支持和自定義命名空間的使用大大減少了基於XML的配置。使用Java 5及更新版本java的開發人員如今可以利用植入了像泛型（generic）和注解等新語言特性的Spring庫。最近，和AspectJ表達式語言的緊密集成，使得以非侵入方式添加跨越定義良好的Spring管理對象分組的行為成為可能。
新發布的Spring 2.5繼續堅持了這個發展趨向，特別是為那些使用Java 5或更新版本java的開發人員提供了進一步簡化而強大的新特性。這些新特性包括：注解驅動的依賴性注入（annotation-driven dependency injection），使用注解而非XML元數據來自動偵測classpath上的Spring組件，注解對生命周期方法的支持，一個新的web控制器模型將請求映射到加注解的方法上，在測試框架中支持Junit4，Spring XML命名空間的新增內容，等等。
本文是探討這些新特性的3篇系列文章中的第一篇。本文將主要關注於簡化的配置和在Spring應用程序上下文（application context）核心新增的基於注解的功能；第二篇文章將涵蓋web層可用的新特性；最後一篇文章將著重介紹集成和測試的新增性能。這一系列的三篇文章中引用的例子都基於Spring PetClinic應用程序范例。此范例最近被重構以用於展示Spring最新功能，並被包含於Spring 2.5的發布下載包中，可以從Spring Framework 下載網頁下載。查看“samples/petclinic”目錄下的“readme.txt”文件可以得知關於如何構建和部署PetClinic應用程序，掌握本文提到的新技術的最佳方法也許就是對PetClinic應用程序中所展示的特性進行試驗。
Spring支持JSR-250注解
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的事情：
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管理對象的引用。
@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”）可以禁用這一特性。
class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor">
name="fallbackToDefaultTypeMatch" value="false"/>
正如上文所提到的，在解析標有@Resource注解的依賴時，Spring支持JNDI-lookup。如若要強制對所有使用@Resource注解的依賴進行JNDI lookup，那也只要將CommonAnnotationBeanPostProcessor的'alwaysUseJndiLookup' 標識設置為true就可以了（默認值是false）。
class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor">
name="alwaysUseJndiLookup" value="true"/>
另一個選擇是，激活指定為‘resource-ref-mappings’的依據全局JNDI名的查找，在@Resource注解內提供‘mappedName’屬性。即使目標對象實際上是一個JNDI資源，仍然推薦引入一個Spring管理對象，這樣可以提供一個間接層並且因此降低耦合程度。自Spring2.0開始添加命名空間以來，定義一個委托Spring處理JNDI lookup的bean也變得愈發簡練：
這個方法的優點在於間接層帶來了巨大的部署彈性。比如說，一個單獨的系統測試環境應該不再需要JNDI注冊。在這種情況下，在系統測試配置中可以提供如下的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實現來完成。這是具體化那些屬性（通常是針對特定環境的屬性）常用的技術，這些屬性可能比其他配置修改得更為頻繁。
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
name="location" value="classpath:jdbc.properties"/>
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的另一個部署選項，並且不需要修改任何代碼。
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與之對應的話，自動裝配機制就會失敗。同樣的，對於任何一個可選屬性，如果它擁有一個以上的候選，也都會失敗（如果屬性可選且沒有任何候選可用的話，該屬性則會被簡單地跳過）。有很多不同的配置選項可以避免這些沖突。
若Context中擁有一個指定類型的一個主關鍵實例，對這個類型定義的bean定義應該包含‘primary’屬性。當Context中含有其他可用實例的時候這個方法就很適用，但那些非主關鍵實例總是顯式配置的。
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方法。
id="dentistryClinic" class="samples.DentistryClinic">
type="example.VetSpecialty" value="dentistry"/>
為了避免對@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注解都是有可能的。
class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor">
name="autowiredAnnotationType" value="example.Injected"/>
大部分情況下，定義自定義‘標記’注解的能力結合通過名字或其他文法值進行匹配選項，足以完成自動裝配過程的細粒度控制。但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注解的屬性子元素。這些元素通常以鍵／值對方式提供。
id="poodleClinic" class="example.PoodleClinic">
type="example.SpecializedClinic">
key="species" value="dog"/>
key="breed" value="poodle"/>
目前為止，關於autowire的描述都只是針對單獨的實例，其實也支持集合。在任何需要得到所有context中某種特定類型的Spring管理對象的時候，只需要簡單地在一個強類型（strongly-typed）集合上加注@Autowired 注解。
@Autowired
private List 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的內置構造型之一）。請看下面這個例子：@Controllerpublic class ClinicController {
private final Clinic clinic;
@Autowired
public ClinicController(Clinic clinic) {
this.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元注解。
@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的名字就可以了。
id="shoppingCart" class="example.ShoppingCart" scope="session">
...
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內。
在接下來的文章中，我們將討論到在Spring web層強大的基於注解的新功能項。敬請關注該系列的下一篇文章。
