我正在前往開羅的路上寫下這些。我們正飛過義大利西部，我能清晰地看到義大利海岸線，那裡海水湛藍，海浪溫柔地湧向岸邊。現在那裡一定很美。我正前往開羅參加由 Ahmed Hashim 組織的 埃及使用者組會議，毫無疑問，他一定會做得非常出色，我對此深信不疑。我將進行關於 Spring 的演講，這次的主題是依賴注入、型別安全和 Java 5。昨天（也就是 3 月 14 日），我在荷蘭 Loenen 的 Profict 冬令營為聽眾做了幾乎相同的演講……

我很高興宣佈 Spring Batch 1.0.0.rc1 已釋出。  您可以透過 Spring Maven Milestone Repository (瀏覽) 或 下載頁面 獲取此版本。

這是 Spring Batch 1.0.0 版本的第一個候選釋出版（release candidate），預計最終版本將於 3 月 28 日釋出。  此版本的主要變化包括

• 參考文件的改進
• spring-batch-infrastructure 和 spring-batch-core 的包結構重組
• spring-batch-core 和 spring-batch-execution 模組的合併

詳情請參閱更新日誌。

Ben Hale
Spring Batch 技術…

親愛的 Spring 社群成員們，

我們很高興宣佈 Spring Web Flow 2.0 M4 現已可用。  下載 | 文件

此版本鞏固了 Web Flow 2 的架構模型，包括 SWF 2 如何與 Spring MVC、JavaServerFaces 和 Ajax 整合。它還引入了許多新功能和改進，包括

2.0 M4 新特性和亮點

• 引入了簡化的 XML 流定義語法。  有關新語法的示例，請參閱 Spring Travel 參考應用程式。

• 使用版本 2 語法可將版本 1 流定義的大小減少多達 50%。  例如，Spring Travel 1.0.5 包含六個工件中的約 200 行流應用程式程式碼。最新的 2.0 M4 版本包含兩個工件中的 93 行程式碼，減少了 50%，需要維護的檔案少了四個。 
  

• 節省主要透過更強的表示式語言（EL）整合以及更簡單的動作執行和資料對映標籤來實現。

• Spring Security 整合。  提供對保護流、狀態和轉換的全面支援。
  一個新的 "currentUser" EL 變數使得從流定義或檢視模板中引用已認證的主體（Principal）變得容易。

• 在 Spring MVC 內部靈活支援流異常處理，包括對自動重新啟動已結束或已過期的流的預設支援。

• 支援處理不改變當前頁面的 Ajax 事件。  一個新的 "render" 元素允許您在處理 Ajax 事件後選擇性地重新渲染頁面的片段。

• 檢視變數。  檢視變數在其包含的檢視狀態進入時分配，並在狀態退出時超出範圍。這些變數提供頁面上下文，對於透過同一頁面的系列 Ajax 請求更新模型特別有用。

• @Autowired 流變數。  流變數現在可以透過 Spring 進行 @Autowired 依賴注入，使其能夠持有對 Spring 管理的 @Services 的引用。   在變數反序列化後，服務引用會在請求之間自動重新連線。

• 支援彈出視窗。  將檢視狀態標記為 popup=true，當客戶端啟用 Javascript 時，它將在模態彈出對話方塊中渲染。

• 從 Web Flow 的 JSF 支援中剝離出一個名為 "Spring Javascript" 的 Javascript 抽象層。  目前，提供了基於 Dojo 和 Ext 的此層實現。  Spring.js 提供
  
• 為 Ajax 提供一個通用介面，無論底層使用哪種工具包
• 一個類似面向切面（aspect-oriented）的 API，用於修飾 HTML DOM 節點，賦予其行為，包括客戶端驗證行為。

• 一個小型 JSF 元件庫，底層使用 Spring.js 來逐步增強使用 JSF 的 Spring Web 應用程式。  如果客戶端未啟用 Javascript，此庫會降級。  請參閱 Spring Travel 示例以瞭解演示：關閉 Javascript，並與開啟 Javascript 時進行比較。

• 支援在標準 Spring MVC 環境中渲染 JSF 檢視。  這使得普通 Spring MVC 控制器和流都可以渲染 Facelets 模板。

請參閱版本中包含的 Spring Travel 參考應用程式，以實際演示所有這些功能。  這些參考專案可以直接作為 Dynamic Web Projects 匯入到 Eclipse 中。

1.x 相容性

給現有 Web Flow 使用者一個特別說明：即將釋出的 2.0 RC1 將在版本 2 環境中提供對版本 1 流的支援。  這將允許 1.0.x 流在與版本 2 流相同的應用程式中無需修改即可執行。

更多資訊，請參閱完整的 Web Flow 2 更新日誌 和 路線圖。  我們還鼓勵您訪問我們的支援論壇和 JIRA 系統，向開發團隊提供您對 M4 的反饋。

盡情享用吧！  2.0 最終版即將到來。

Keith Donald
Web Flow 技術負責人
SpringSource

Web Flow 團隊一直在努力開發 Web Flow 2。我們剛剛達到了第四個里程碑，最早下週將進入候選釋出版狀態。2.0 最終版本計劃於本月底釋出。

從現在到 2.0 最終版本之間，我們希望得到您的反饋！如果您是當前使用 Web Flow 1.x 或正在評估 Web Flow 用於您專案的應用程式開發人員，請評估 2.0 M4 並告訴我們您的想法。如果您是將 Web Flow 引擎整合到您的框架中的 Web 框架提供商，我們鼓勵您評估 2.0 M4 中改進的鉤子（hooks）和…

Spring Batch 1.0.0.m5 今日透過 s3 里程碑倉庫釋出（可在此處瀏覽：http://s3browse.com/explore/maven.springframework.org/milestone/org/springframework/batch）。更多資訊，請訪問 Spring Batch 下載頁面：http://static.springframework.org/spring-batch。

從使用者的角度來看，m5 的主要變化是透過各種工廠 Bean 配置作業（jobs）、步驟（steps）和啟動器環境（launcher environment）。新的 BatchListener 介面組解決了幾個關鍵的使用者關注點。API 中的一些關鍵介面，如 ItemReader 和 ItemWriter，也發生了一些變化，這使得我們能夠更好地分離使用者和框架之間的關注點。網站上有一節詳細描述瞭如何從 1.0.0.m4 遷移到 1.0.0.m5 (http://static.springframework.org/spring-batch/migration/1.0-m4-m5.html)。

我們對自上次里程碑以來在 Spring Batch 上取得的進展感到非常高興，現在終於感覺一切都已為最終版本做好準備。按計劃，我們現在只剩下釋出 rc1 的時間了，如果需要，還可以考慮 rc2，然後就是預期的 3 月 20 日最終釋出。

親愛的 Spring 社群成員們，
 
我很高興宣佈 Spring Framework 2.5.2 已釋出。下載 | 文件
 
這是 Spring 2.5 系列的第二個更新版本。它修復了自 2.5.1 以來報告的所有問題，並在整個框架中引入了各種增強功能

• 恢復了特定擴充套件點的完整 Spring 2.0 相容性
• 擴充套件了對 MS SQL, MySQL, PostgreSQL 和 Oracle 的 SQL 錯誤碼對映
• 修訂了 JDBC BeanPropertyRowMapper，改進了值提取邏輯
• 支援將 GlassFish/JBoss JCA WorkManager 作為 TaskExecutor 後端
• 支援 Eclipse Persistence Services 1.0 M4 (EclipseLink JPA provider)
• 與 WebSphere JPA provider (源自 OpenJPA) 的相容性
• @RequestMapping 支援 "!myParam" 表示式，用於判斷引數不存在的情況
• @RequestMapping 的 "params" 屬性也支援在型別級別使用
• 修訂了 JSP CheckboxesTag 和 RadioButtonsTag (以嚴格遵守 HTML 標準)

親愛的 Spring 社群成員們，

在過去的幾個月裡，我一直在與各種客戶合作使用 Google Web Toolkit [GWT] 的專案。我喜歡 GWT，主要是因為它提供了 Java 到 javascript 的編譯器。這是開啟大門的關鍵，讓普通 Java 開發者無需學習新語言即可建立 RIA。

我一直是測試驅動開發（TDD）的擁躉，令我失望的是，乍一看似乎 TDD 和 GWT 不太相容。

測試 GWT 程式碼有點問題。核心問題在於 GWT 程式碼在執行之前需要編譯成 javascript。在很多情況下，一個 GWT.create() 語句……

在接觸 OSGi 時，首先需要學習的概念之一就是 bundle 的概念。在這篇文章中，我想仔細看看 bundle 到底是什麼，以及一個普通的 jar 檔案如何轉化為 OSGi bundle。  那麼，話不多說，

什麼是 bundle？

OSGi 規範將 bundle 描述為“模組化單元”，它“由 Java 類和其他資源組成，它們共同可以為終端使用者提供功能”。到目前為止一切順利，但 bundle 到底是什麼？再次引用規範

bundle 是一個 JAR 檔案，它

• 包含 [...] 資源
• 包含一個清單檔案（manifest file），描述 JAR 檔案的內容並提供關於 bundle 的資訊
• 可以在 JAR 檔案的 OSGI-OPT 目錄或其子目錄中包含可選文件

簡而言之，bundle = jar + OSGi 資訊（在 JAR 清單檔案 - META-INF/MANIFEST.MF 中指定），不需要額外的檔案或預定義的資料夾佈局。這意味著從 jar 建立 bundle 所需要做的就是向 JAR 清單中新增一些條目。

OSGi 元資料

OSGi 元資料由清單條目表示，這些條目規定 bundle 向 OSGi 框架提供或/和需要什麼。規範指出了大約 20 個清單頭部（manifest headers），但我們只看您最可能使用的一些頭部。

Export-Package

顧名思義，此頭部指示將 bundle 中可用的哪些包匯出，以便其他 bundle 可以匯入它們。只有頭部指定的包會被匯出，其餘的將是私有的，並且在包含該 bundle 的外部不可見。

Import-Package

與 Export-Package 類似，此頭部指示 bundle 匯入的包。同樣，只有此頭部指定的包才會被匯入。預設情況下，匯入的包是強制性的——如果匯入的包不可用，匯入 bundle 將無法啟動。

Bundle-SymbolicName

Bundle-Name

Bundle-Activator

Bundle-Classpath

Bundle-ManifestVersion

下面是一個示例，取自 Spring 2.5.x 核心 bundle 的清單檔案，它使用了上面提到的一些頭部

 
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 看到。

總結一下，如果 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。您已經在前面的例子中看到了這樣一個包

由於在 OSGi 中，同一類可以存在多個版本，因此在匯出和匯入包時都指定類包的版本是最佳實踐。這是透過在每個包聲明後新增 version 屬性來完成的。OSGi 支援的版本格式是 <major>.<minor>.<micro>.<qualifier>，其中 major、minor 和 micro 是數字，qualifier 是字母數字。

版本的含義完全取決於 bundle 提供者，但是建議使用流行的編號方案，例如 Apache APR 專案的方案，其中

• <major> - 表示重大更新，不保證任何相容性
• <minor> - 表示維護與舊次要版本相容性的更新
• <micro> - 表示從使用者角度來看不重要的更新，向前和向後都完美相容
• <qualifier> - 是一個使用者定義的字串 - 它不常用，可以為版本號提供一個額外的標籤，例如構建號或目標平臺，沒有標準化含義

預設版本（如果屬性缺失）是 "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, ∞)"

最後一點提示，指定版本時，無論是範圍還是單個版本，請務必始終使用引號。

使用 OSGi 元資料

現在我們對 bundle 有了一些瞭解，接下來看看我們可以使用哪些工具來將現有的 jar 轉化為 OSGi bundle（osgi-fy）

手動

不建議採用這種“自己動手”的方式，因為很容易出現拼寫錯誤和多餘空格，導致清單檔案無效。即使使用智慧編輯器，清單檔案格式本身也會帶來一些問題，因為它每行限制 72 個字元，如果超過這個限制，可能會導致一些難以理解的問題。手動建立或更新 jar 檔案不是個好主意，因為 jar 格式要求 META-INF/MANIFEST.MF 條目必須是歸檔中的第一個條目——如果不是，即使它存在於 jar 檔案中，清單檔案也不會被讀取。手動方法只建議在沒有其他替代方案的情況下使用。

然而，如果確實想/需要直接處理清單檔案，那麼應該使用可以處理 UNIX/DOS 空格的編輯器，並結合合適的 jar 建立工具（例如 JDK 自帶的 jar 工具）來滿足所有 MANIFEST 要求。

Bnd

Bnd 是 BuNDle tool 的縮寫，是由 Peter Kriens（OSGi 技術官員）建立的一個很棒的工具，它“幫助 […] 建立和診斷 OSGi R4 bundle”。Bnd 解析 Java 類以瞭解可用和匯入的包，從而建立等效的 OSGi 條目。Bnd 提供了一系列指令和選項，可以自定義生成的工件。bnd.jar 本身的好處是它可以在命令列執行，可以透過 Ant 的專用任務執行，也可以作為外掛整合到 Eclipse 中。

Bnd 可以從類路徑或 Eclipse 專案中的類建立 jar 檔案，也可以透過新增所需的 OSGi 工件來將現有 jar 轉化為 OSGi bundle。此外，它可以列印和驗證給定 jar 的 OSGi 資訊，使其成為一個非常強大但易於使用的工具。

首次使用的使用者可以使用 Bnd 檢視會向普通 jar 檔案新增哪些 OSGi 清單資訊。讓我們選擇一個普通 jar 檔案，比如 c3p0（一個非常優秀的連線池庫），併發出 print 命令

```code java -jar bnd.jar print c3p0-0.9.1.2.jar ```

輸出內容相當大，包含幾個部分

1. 通用清單資訊

   [MANIFEST c3p0-0.9.1.2.jar]
   Ant…