幾位使用者詢問我們是否致力於 Spring Java 配置，以及它與 Spring 2.5 中引入的 註解配置選項 的關係。答案是肯定的，我們致力於 Java 配置；這兩種方法並非互斥。

這兩種配置方法截然不同：Spring 框架中的 @Autowired 註解透過業務物件中的註解來配置元件，而 Spring Java Config 則採用一種獨特的方法，將註解外部化到專用的配置類中。這兩種方法沒有絕對的對錯之分，在不同的場景下都有其優勢。甚至可以在同一個應用程式中同時使用這兩種方法。

如果您認為 Spring 就等於 XML，那麼是時候重新思考了。（無論如何，這從未完全準確過，因為 Spring 核心容器一直使用自己的 Java 元資料，並不瞭解 XML 或任何其他表示形式。）

這讓我們想起了一個重要的哲學原則：我們使用 Spring 的使命是為企業 Java 提供最佳的元件模型，設定靈活性的標準以滿足複雜的需求，併為現實世界的問題提供全面的解決方案。我們不認為存在適用於所有情況的單一配置模型，我們相信在強大的、可擴充套件的模型內提供選擇。無論您選擇如何定義您的 Spring 管理的物件，它們都可以獲得相同的豐富企業服務、無與倫比的第三方整合、真正的 AOP、許多擴充套件點等。

因此，Spring 2.5 的 @Component 和 @Autowired 註解（讓容器自動檢測 Spring 管理的物件）可以與 Java Configuration、XML 和其他配置選項愉快地共存。

這讓我想起：本週晚些時候，我將在 舊金山 QCon 大會 上討論 Spring 容器的配置方式，屆時可以收集反饋，這應該會很有趣。之後，我會嘗試在這裡或 SpringFramework.org 上釋出幻燈片。

由於 Costin 致力於 Spring Dynamic Modules for OSGi，Spring Java Config 一度進展緩慢，但現在已步入正軌。在過去的幾天裡，我為此做了不少工作：將其更新到 Spring 2.5；移除未使用的程式碼；並添加了一個備受期待的新功能——配置值（以及 Bean）的外部化。

雖然 M2 版本在 2.5RC1 上執行良好（考慮到 JavaConfig 對 Spring IoC 的深度使用，這足以證明 2.5 的向後相容性），但它包含了自己的註解掃描程式碼（Spring 框架採納並進一步發展了它），因此遷移到較新的 Spring 版本是明智的。

新的配置屬性外部化功能採用了 JIRA 中關於使用抽象方法（感謝 Guillaume Duchesneau）的建議。

這些方法使用了新的 @ExternalValue 註解進行註解，如下所示：

@Bean
public Person john() {
	Person john= new Person();
	john.setName(getName());
	john.setAge(methodWithArbitraryNameReturningAge());		
	john.setBusy(busy());
	return john;
}
	
    // Property name defaults to method name.
    // In the case of a getter method, it's the property name--
    // "name" in this case
@ExternalValue
public abstract String getName();
	

    // Property name is taken from annotation value
@ExternalValue("age")                  
public abstract int methodWithArbitraryNameReturningAge();
	
@ExternalValue
protected abstract boolean busy();
	

}

Spring Java Config 會繼承這些類，來實現這些方法，以便在執行時返回外部化屬性。（它還會因為其他原因繼承配置類，例如快取單例 Bean 方法的返回值。）這些方法可以是 public 或 protected。

配置類上的 @ResourceBundles 註解標識了一個或多個要用於解析值的資源束，這些值可以透過方法名或註解上的顯式字串值來指定。這些位置是 Spring 資源位置字串。

帶有 @ExternalBean 註解的方法可以是具體的，在這種情況下，如果找不到外部值，則會使用實際的返回值，如下所示： @ExternalValue public int otherNumber() { return 25; } 這種用法意味著該值是可外部化的，但外部化是可選的，就像具有可用預設值的 Bean 屬性一樣。

正如您所料，示例的屬性檔案如下所示：

底層機制被設計為可擴充套件的，因此屬性檔案不是唯一的選項，我們將在未來的版本中提供其他選項。抽象方法的方式允許動態獲取值：例如，從資料庫中獲取，或者自定義地從另一個系統中獲取。

目前，該示例僅在 SVN 中可用，但我們計劃在本月釋出 M3 版本。未來，位於西雅圖的 Interface21 顧問 Chris Beams 將負責該專案。在 Interface21，我們相信我們所有的技術人員都應該參與到我們作為一家公司所做的一切：產品開發、諮詢和培訓。產品開發人員會提供一些培訓和諮詢；服務交付人員會參與專案。這確保了每個人都能為我們共同關心的開源專案做出貢獻，並且每個人都能紮根於真實的業務需求，而不是（J2EE 過去存在的）與世隔絕地開發基礎設施。Chris 主要從事諮詢和培訓，但他將“對齊”Spring Java Config，使其成為他的主要開發重點，因此他將投入大量時間進行開發，並得到 Costin 和我的幫助。

Spring Java Config 何時能達到 1.0 最終版，部分取決於您。我們需要在實際使用中的反饋；我們需要功能請求（儘管我們可能希望在 1.0 版本中保持範圍的可管理性）；我們需要在優先順序排序方面的幫助。如果您想要這些，請告訴我們，我們會傾聽！