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

這兩種配置方法截然不同：Spring Framework 中的 @Autowired 註解使用業務物件中的註解來配置元件，而 Spring Java Config 採用一種獨特的方法，將註解外部化到專用的配置類別中。這兩種方法沒有絕對的對錯，並且在不同的情況下都很有用。甚至沒有理由不能在同一個應用程式中使用它們。

如果您認為 Spring = XML，那麼現在是時候重新思考了。（無論如何，這從來都不是完全準確的，因為 Spring 核心容器一直使用它自己的 Java metadata，並且不了解 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 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 的可管理範圍內）；並且我們需要優先順序方面的幫助。如果您需要它，請告訴我們，我們會傾聽！