今天釋出了 Spring Java Configuration 專案（簡稱 JavaConfig）的第三個里程碑版本。此版本包含大量錯誤修復和新功能——我將在下面重點介紹一些最有趣的變化，但首先讓我快速回顧一下 JavaConfig 的全部內容。
如果您有 Spring 的經驗，以下 XML 配置片段可能會很熟悉。假設我們正在檢視一個名為 application-config.xml 的檔案
<beans>
<bean id="orderService" class="com.acme.OrderService"/>
<constructor-arg ref="orderRepository"/>
</bean…今天我在拉斯維加斯的 TSSJS 發表了一場題為 面向 Java Server Faces 的 Spring 的演講。演講探討了 JSF 和 Spring 如何協同工作，並引導聽眾瞭解整合這兩種技術的方法。
該幻燈片可供您檢視和隨意使用。
在演講中，我概述了整合 JSF 和 Spring 的兩種方法。第一種方法我稱之為“以 JSF 為中心”，這是大多數具有傳統 JSF 背景的人今天採用的整合方法。第二種方法我稱之為“以 Spring 為中心……”
在 Spring 2.5 中，可以使用註解配置 Web 應用程式的所有部分。在 Web 層應用註解特別有趣，傳統上開發者依賴 SimpleFormController 和 MultiActionController 來處理表單頁面。註解的引入創造了第三種選擇，它不需要基類，同時仍然提供了以前方法的靈活性。
雖然使用帶註解的 POJO 實現 Controller 很容易看出其優雅之處，但在 URL 到 Controller 的領域，這種好處並不那麼明顯……
今年的 EclipseCon 是我們公司第一次參加。我們舉辦了幾場講座，都受到了好評，並且我們宣佈了 SpringSource Tool Suite 的 beta 專案。總的來說，我們都度過了一段非常愉快的時光，並從 Eclipse 社群獲得了關於 Spring Portfolio 專案，特別是我們在 Web 領域工作的許多反饋。我將在接下來的幾周內確保將所有反饋轉達給專案負責人。由於 EclipseCon 今天即將結束，我終於有時間坐下來寫下我們在會議上介紹的內容。
我們在週一的 BoF 期間釋出了 SpringSource Tool Suite (STS) 的個人使用版本，並且花了很多時間與人們討論它帶來了哪些額外價值。在這篇部落格中，我將更詳細地概述 SpringSource Tool Suite 的功能。首先，我已經多次聽說人們認為 SpringSource Tool Suite 的釋出意味著我們將停止改進和塑造 Spring IDE。請允許我強調，這絕對不是事實；實際上，情況恰恰相反，從 Spring IDE 的 JIRA 和 Subversion 倉庫就可以看出。事實上，自從我一月份加入 SpringSource 以來，我在並行開發工具套件的同時，能夠投入更多時間在 Spring IDE 上。
SpringSource Tool Suite 的目標是為您在 Eclipse 平臺上使用 Spring Portfolio 進行企業級開發提供最精密的開發工具——這聽起來像營銷術語，但這正是工具團隊所承諾的使命宣言。STS 顯然建立在成熟的 Spring IDE 之上，但它與 Eclipse Mylyn 緊密結合，並且已經擴充套件了這兩個開源工具，將企業級擴充套件帶入您的 IDE。為了提供最好的 Spring 工具，我們已經開始並將繼續向 Spring 核心框架和其他 Spring 專案新增與工具相關的功能、鉤子和擴充套件點。
因此，使用此工具套件，您最終將獲得 Mylyn 的任務聚焦使用者介面帶來的所有益處，用於 Spring 開發。您在處理 Spring 應用藍圖時可以進行上下文管理和聚焦。此外，我們將任務聚焦 UI 方法提升到了一個新的水平，並引入了一項名為任務聚焦教程的新技術。任務聚焦教程擴充套件了 Eclipse Cheat Sheet 框架，併為教程的每個步驟添加了任務聚焦功能。透過任務聚焦教程，使用者——無論是 Spring 新手，還是想要學習某個特定功能或 Spring 專案的人——都可以透過一次點選匯入一個可執行的示例應用程式，並開始探索該示例。然後，教程的每個步驟將提供教程某個特定方面的解釋，並只顯示與理解和探索該解釋相關的 Java 和 Spring 元素。
從上面的截圖中，您可以看到它在 Eclipse 中的樣子。教程將 PetClinic 示例應用程式匯入到 Eclipse 工作區，並聚焦工作區，使其只顯示 @Autowired 註解以及如何將其應用於應用程式元件。在右側，您可以看到展開的步驟，解釋瞭如何以及為何應該使用 @Autowired 註解。在教程的最後，使用者可以透過一次點選在捆綁的 Tomcat 伺服器上啟動示例應用程式，該伺服器會自動安裝和配置。
我們認為這種介紹新特性和產品的方式是一種非常強大的方法，它讓人們可以非常輕鬆地探索 Spring Portfolio。開發者在開始時所需的一切知識和工具都觸手可及：就在 IDE 內部。當您下載個人使用版 Beta 時，您可以即時訪問大約 20 個教程，這些教程全部由專案負責人或直接與客戶合作的經驗豐富的顧問建立。最值得一提的是，Adrian Colyer 花時間建立了 7 個教程，介紹了 OSGi 概念、Equinox 和 Spring Dynamic Modules。如果您現在想搭上 OSGi 的順風車，這些教程非常棒。工具套件包含一個自動 OSGi bundle 更新/重新整理機制，最終允許您在應用程式上工作，並基於 OSGi 執行時的強大功能實現即時重新部署語義（您是否嘗試過使用 EJB？我試過）。
我想談論的下一個功能稱為 執行時錯誤分析：SpringSource Tool Suite 能夠透過分析 Java 堆疊跟蹤來提供有關如何解決執行時問題的資訊。為了實現這一點，我們建立了一個線上知識庫，它整合到工具套件中，並且可以在 Eclipse IDE 內部直接查詢。該知識庫對所有使用該工具的人開放，我們甚至鼓勵人們使用內建的豐富編輯功能貢獻自己的分析。請看下面的截圖。
使用此工具套件，您不僅可以獲得執行時錯誤分析的支援，工具還會幫助您發現常見的陷阱和違反 Spring 最佳實踐的情況。特別是在處理 XML bean 定義檔案時，此功能非常方便，因為它會直接在 XML 編輯器中告知開發者檔案中可能需要修改的內容。例如，該工具會檢測並推薦在某些情況下使用 bean 繼承。它還會推薦使用不斷改進的名稱空間元素，而不是傳統的 bean 定義樣式。這是一個示例
那麼讓我們看看我們有什麼
還有更多我沒有提及的功能。您看到這些功能列表中的主要主題了嗎？最後列出的三個功能為開發強大的基於 Spring 的應用程式提供了寶貴的幫助。在內部，我們開始使用一個比喻來形容這組功能：盒子裡的顧問。透過 SpringSource Tool Suite，我們希望讓您能夠獲得 SpringSource 的知識，就像您身邊坐著一位顧問一樣！
我想鼓勵大家前往 beta 註冊頁面 試用 Tool Suite。最後，我也想感謝所有已經提交反饋、問題和建議的人。在 EclipseCon 這個令人應接不暇的一週結束後，我會盡快回復大家。
Web Flow 團隊一直致力於 Web Flow 2 的開發。我們剛剛達到了第四個里程碑，最早下週將進入釋出候選階段。2.0 最終版本定於本月底釋出。
從現在到 2.0 最終版本釋出期間，我們期待您的反饋！如果您是目前正在使用 Web Flow 1.x 的應用程式開發者，或者正在評估 Web Flow 用於您的專案，請評估 2.0 M4 版本並告訴我們您的想法。如果您是將 Web Flow 引擎整合到您的框架中的 Web 框架提供商，我們鼓勵您評估 2.0 M4 中最佳化的鉤子以及……
在過去的幾個月裡，我一直在與各種客戶合作使用 Google Web Toolkit [GWT] 的專案。我喜歡 GWT 主要因為它提供了 Java 到 JavaScript 的編譯器。這是讓普通 Java 開發者無需學習新語言即可建立 RIA 的關鍵。
我一直以來都是測試驅動開發（TDD）的粉絲，但令我失望的是，乍一看，TDD 和 GWT 似乎無法協同工作。
測試 GWT 程式碼有點問題。問題的核心在於 GWT 程式碼在執行之前會被編譯成 JavaScript。在許多情況下，一個 GWT.create() 語句……
在接觸 OSGi 時，首先必須學習的概念之一就是bundle的概念。在這篇文章中，我想仔細看看 bundle 到底是什麼，以及一個普通的 jar 如何轉換為 OSGi bundle。 那麼，話不多說，
OSGi 規範將 bundle 描述為“模組化單元”，它“由 Java 類和其他資源組成，這些資源共同可以為終端使用者提供功能。”到目前為止還好，但 bundle 究竟是什麼？再次引用規範
一個 bundle 是一個 JAR 檔案，它
- 包含 [...] 資源
- 包含一個 manifest 檔案，描述 JAR 檔案的內容並提供關於 bundle 的資訊
- 可以在 JAR 檔案的 OSGI-OPT 目錄或其子目錄中包含可選文件
簡而言之，一個 bundle = jar + OSGi 資訊（在 JAR manifest 檔案 - META-INF/MANIFEST.MF 中指定），不需要額外的檔案或預定義的資料夾佈局。這意味著從一個 jar 建立一個 bundle 所需的全部工作就是向 JAR manifest 新增一些條目。
OSGi 元資料由 manifest 條目表示，這些條目向 OSGi 框架指示 bundle 提供和/或需要什麼。規範指出了大約 20 個 manifest 頭，但我們只會看一些您最有可能使用的頭。
顧名思義，此頭指示匯出哪些（在 bundle 中可用的）包，以便其他 bundle 可以匯入它們。只有此頭指定的包會被匯出，其餘的將是私有的，並且在包含此 bundle 的外部不可見。
與 Export-Package 類似，此頭指示 bundle 匯入的包。同樣，只有此頭指定的包會被匯入。預設情況下，匯入的包是強制性的——如果匯入的包不可用，匯入的 bundle 將無法啟動。
下面是一個示例，取自 Spring 2.5.x 核心 bundle 的 manifest 檔案，使用了上面提到的一些頭
Bundle-Name: spring-core
Bundle-SymbolicName: org.springframework.bundle.spring.core
Bundle-ManifestVersion: 2
Export-Package:org.springframework.core.task;uses:="org.springframework.core,org.springframework.util";version=2.5.1 org.springframework.core.type;uses:=org.springframework.core.annotation;version=2.5.1[...]
Import-Package:org.apache.commons.logging,edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional[...]
花在 OSGi 元資料上的大部分時間可能都用於 Export/Import 包條目，因為它們描述了 bundle 之間的關係（即您的模組之間的關係）。對於包來說，沒有任何隱式規則——只有提及的包才會被匯入/匯出，其餘的則不會。這也適用於子包：匯出 org.mypackage 將只匯出這個包，而不是其他任何東西（例如 org.mypackage.util）。匯入也是一樣——即使一個包在 OSGi 空間中可用，除非某個 bundle 明確匯入它，否則它將不可見。
總結一下，如果 bundle A 匯出包 org.mypackage 並且 bundle B 想要使用它，那麼 bundle A 的 META-INF/MANIFEST.MF 應在其 Export-Package 頭中指定該包，而 bundle B 應將其包含在其 Import-Package 條目中。
匯出相當直接，但匯入稍微複雜一些。應用程式通常會透過搜尋環境中的特定庫並僅使用可用的庫來良好地降級，或者庫包含使用者未使用的程式碼。這些例子包括日誌記錄（使用 JDK 1.4 或 Log4j）、正則表示式（Jakarta ORO 或 JDK 1.4+）或併發工具（JDK 5 中的 java.util 或用於 JDK 1.4 的 backport-util-concurrent 庫）。
用 OSGi 的術語來說，根據包的可用性來依賴它，這等同於一個可選的 Package-Import。您已經在前面的示例中看到過這樣的包
```code Import-Package: [...]edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional ```由於在 OSGi 中，可以存在同一個類的多個版本，因此最佳實踐是在匯出和匯入包時都指定類包的版本。這是透過在每個包聲明後新增 version 屬性來完成的。OSGi 支援的版本格式是 <major>.<minor>.<micro>.<qualifier>，其中 major、minor 和 micro 是數字，qualifier 是字母數字。
該版本含義完全由 bundle 提供者決定，但建議使用流行的編號方案，例如 Apache APR 專案的方案，其中
預設版本（如果屬性缺失）是“0.0.0”。
匯出的包必須指定特定版本，而匯入者可以使用數學區間表示法指定範圍 - 例如
[1.0.4, 2.0) 將匹配版本 1.0.42 及以上直至 2.0（不包含）。請注意，如果只指定一個版本而不是區間，將匹配所有大於或等於指定版本的包，即
Import-Package: com.mypackage;version="1.2.3"
等價於
Import-Package: com.mypackage;version="[1.2.3, ∞)"
最後一點提示，指定版本時，無論是範圍還是單個版本，請務必始終使用引號。
既然我們已經瞭解了 bundle 的一些資訊，接下來看看可以使用哪些工具來將現有 jar OSGi 化
不建議採用這種手動方式，因為很容易出現打字錯誤和多餘空格，導致 manifest 檔案失效。即使使用智慧編輯器，manifest 格式本身也可能引發一些問題，因為它規定每行最多 72 個空格，如果超出則可能導致一些難以理解的問題。手動建立或更新 jar 也不是一個好主意，因為 jar 格式要求 META-INF/MANIFEST.MF 條目必須是歸檔中的第一個——如果不是，即使它存在於 jar 中，manifest 檔案也不會被讀取。手動方式只在沒有其他替代方案的情況下才真正推薦使用。
然而，如果確實想要/需要直接處理 manifest 檔案，則應使用能夠處理 UNIX/DOS 空格的編輯器，並結合適當的 jar 建立工具（例如 JDK 自帶的 jar 工具），以滿足所有 MANIFEST 要求。
Bnd 是 BuNDle tool 的縮寫，是一個由 Peter Kriens（OSGi 技術官員）建立的實用工具，它“幫助 [...] 建立和診斷 OSGi R4 bundle”。Bnd 解析 Java 類以瞭解可用和匯入的包，從而建立相應的 OSGi 條目。Bnd 提供了一系列指令和選項，可以自定義生成的 artifact。bnd.jar 本身的優點在於它可以從命令列執行，透過 Ant 的專用任務執行，或作為外掛整合到 Eclipse 中。
Bnd 可以從類路徑中或 Eclipse 專案內的類建立 jar，也可以透過新增所需的 OSGi artifacts 來將現有 jar OSGi 化。此外，它可以列印和驗證給定 jar 的 OSGi 資訊，使其成為一個功能強大但易於使用的工具。
初次使用的使用者可以使用 Bnd 檢視普通 jar 會被新增哪些 OSGi manifest 條目。讓我們選擇一個普通 jar，例如 c3p0（這是一個出色的連線池庫），然後執行列印命令
```code java -jar bnd.jar print c3p0-0.9.1.2.jar ```
輸出內容相當多，包含多個部分
[MANIFEST c3p0-0.9.1.2.jar]
Ant…我們一直在努力開發 Spring Batch，為 Spring Portfolio 2.5 版本釋出列車做準備，我認為現在是時候向大家更新一下情況了。在本文中，我將稍微擴充套件一下領域建模，以及我們決定提升一些核心領域物件的地位並增加其職責的決定。我還將稍微介紹一下接下來幾個版本直到 1.0 版本將要釋出的內容，以便大家有機會發表評論（如果願意的話）。
在此致歉：內部發生了一些相當大的變化……
我的上一篇部落格展示了 Spring 如何超越 EJB。BZ Media 等公司的研究顯示，Apache Tomcat 是領先的開源應用伺服器，市場滲透率達 64%。Spring 和 Tomcat 的主導地位眾所周知。人們可能不太瞭解的是，成千上萬的組織正在 Tomcat 上執行 Spring 作為其中介軟體基礎設施。這些組織希望有一個公司可以為他們提供成功所需的產品和服務。
今天我們宣佈收購了 Covalent Technologies。Covalent 不僅帶來了 Apache 領域的領導地位，而且我們合併後的公司在 Apache Tomcat 和 HTTP 方面也擁有重要的領導地位。兩週前，Sun 為 LAMP 中的“M”支付了 10 億美元。現在 Covalent 傑出的 Apache 專業知識和服務已成為 SpringSource 的一部分，我們在“A”領域也成為了強有力的領導者。我們一直以來都致力於技術領導地位，因此對於我們與 Covalent 攜手合作能取得的成就感到非常興奮。在過去幾年中，Covalent 因其對 Apache 專案（包括 Tomcat 和 Apache HTTP）的支援而在市場上贏得了極高的聲譽。其數百個支援客戶包括財富 500 強中的一半以上，以及輝瑞、強生、英國電信 (BT)、NASA、英特爾、蘇格蘭皇家銀行和貝爾斯登等家喻戶曉的公司。我們的公告……
