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

這兩種配置方法截然不同：Spring Framework 中的 @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 致力於用於 OSGi 的 Spring 動態模組，Spring Java Configuration 停滯了一段時間，但現在它已步入正軌。在過去的幾天裡，我在這方面做了很多工作：將其更新到 Spring 2.5；刪除未使用的程式碼；並添加了一個經常被要求的新功能——配置值的外部化，以及 bean。

雖然 M2 在 2.5RC1 上執行良好（考慮到 JavaConfig 對 Spring IoC 的使用深度，這充分說明了 2.5 的向後相容性），但它包含了自己的註解掃描程式碼（Spring Framework 採用了該程式碼並繼續推進），因此遷移到更高版本的 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 註解標識一個或多個用於解析值的資源包，這些值可以透過方法名稱或透過註解上的顯式 String 值來標識。這些位置是 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 的可管理範圍內）；我們需要幫助確定優先順序。如果您需要這個，請告訴我們，我們會傾聽！