親愛的 Spring 社群：

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

我一直都是測試驅動開發的粉絲，但起初令我失望的是，TDD 和 GWT 似乎無法協同工作。

測試 GWT 程式碼有點問題。 問題的核心是 GWT 程式碼在執行之前會被編譯成 javascript。 在許多情況下，GWT.create() 語句…

在接觸 OSGi 時，首先需要學習的概念之一是bundle的概念。 在這篇文章中，我想更仔細地研究一下 bundle 實際上是什麼，以及如何將普通的 jar 轉換為 OSGi bundle。 所以，事不宜遲，

什麼是 bundle？

OSGi 規範將 bundle 描述為“模組化單元”，它“由 Java 類別和其他資源組成，這些資源可以共同向最終使用者提供功能。”。 到目前為止還不錯，但是 bundle 究竟是什麼？ 再次引用規範

bundle 是一個 JAR 檔案，它

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

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

OSGi 元資料

OSGi 元資料由資訊清單條目表示，這些條目指示 OSGi 框架 bundle 提供或/和需要什麼。 規範指示大約 20 個資訊清單標頭，但我們只會查看您最有可能使用的那些。

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 術語中，根據套件的可用性來依賴套件會轉化為可選的套件匯入。 您已經在先前的範例中看到了這樣的套件

由於在 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 是什麼的資訊，讓我們看看我們可以使用哪些工具來 osgi-fying 現有的 jar

手動

不建議使用這種自行手動的方式，因為很容易不小心輸入錯誤或多餘的空格，導致 manifest 檔案無法使用。即使使用智慧型編輯器，manifest 檔案格式本身也可能造成一些問題，因為每行限制為 72 個字元，如果超出限制，可能會產生一些難以理解的問題。手動建立或更新 jar 檔案也不是一個好主意，因為 jar 檔案格式要求 META-INF/MANIFEST.MF 條目必須是封存檔中的第一個條目 - 如果不是，即使它存在於 jar 檔案中，manifest 檔案也不會被讀取。只有在沒有其他替代方案時，才真的建議使用手動方式。

然而，如果真的想要/需要直接處理 manifest 檔案，則應使用可以處理 UNIX/DOS 空格的編輯器，以及適當的 jar 檔案建立工具（例如 JDK 附帶的 jar 工具），以符合所有 MANIFEST 的要求。

Bnd

Bnd 代表 BuNDle 工具，是由 Peter Kriens (OSGi 技術主管) 創建的一個實用的工具，它可以「幫助 […] 建立和診斷 OSGi R4 bundles」。 Bnd 解析 java 類別，以了解可用的和導入的套件，因此它可以建立等效的 OSGi 條目。 Bnd 提供了一系列的指令和選項，可以自定義產生的成品。 Bnd.jar 本身的好處是，它可以從命令列運行，通過專用的 tasks 使用 Ant，或作為 plug-in 整合到 Eclipse 中。

Bnd 可以從類別路徑或 Eclipse 專案中可用的類別建立 jar 檔案，也可以通過添加所需的 OSGi 成品來 osgi-fy 現有的 jar 檔案。此外，它可以列印和驗證有關給定 jar 檔案的 OSGi 資訊，使其成為一個功能強大且易於使用的工具。

第一次使用的使用者，可以使用 Bnd 來查看將添加到 vanilla jar 檔案中的 OSGi manifest。讓我們選擇一個 vanilla jar 檔案，例如 c3p0 (這是一個優秀的連接池函式庫)，並發出 print 命令

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

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

1. 通用 manifest 資訊

   [MANIFEST c3p0-0.9.1.2.jar]
   Ant…

Spring Batch 1.0.0.m4 今天通過 s3 Milestone 儲存庫提供（在 http://s3browse.com/explore/maven.springframework.org/milestone/org/springframework/batch 瀏覽）。  有關更多資訊，請參閱 Spring Batch 下載頁面 (http://static.springframework.org/spring-batch)。

我們已經重新調整了發佈時間表，以擠出一個額外的里程碑版本，Ben 和 Lucas 將專注於此版本，因此 1.0.0.m5 將在接下來的 10-14 天內發佈。 然後我們只有時間發佈 rc1，如果需要，還可以增加一些 rc2 的緊急應變，預計 3 月 20 日最終發佈。 

我們一直在努力準備 Spring Batch，以便與 Spring Portfolio 2.5 發佈列車一起發佈，我認為現在是時候向大家更新正在發生的事情了。 在本文中，我將詳細介紹域建模，以及我們決定提高一些核心域對象的關注度並增加其職責。 我還將簡要介紹接下來幾個版本中即將推出的內容，以便人們有機會發表評論（如果他們願意）。

謹此道歉：內部結構發生了一些非常重大的變更…

我的 上一篇博文 顯示 Spring 如何超越 EJB。 BZ Media 和其他機構的研究 表明，Apache Tomcat 是領先的開源應用程式伺服器，市場滲透率為 64%。 Spring 和 Tomcat 的優勢是眾所周知的。 人們可能不太了解的是，成千上萬的組織正在 Tomcat 上運行 Spring 作為其中介軟體基礎設施。 這些組織希望有一家公司來提供他們成功所需的產品和服務。

今天，我們宣布收購 Covalent Technologies。 Covalent 不僅帶來了 Apache 的領導地位，而且我們合併後的公司現在在 Apache Tomcat 和 HTTP 方面也擁有重要的領導地位。 兩週前，Sun 支付了 10 億美元購買了 LAMP 中的 "M"。 現在 Covalent 出色的 Apache 專業知識和服務已成為 SpringSource 的一部分，我們成為 “A” 方面的強大領導者。 我們一直致力於技術領先地位，因此我們對與 Covalent 合作能夠做的事情感到非常興奮。 在過去的幾年中，Covalent 在市場上因其對 Apache 專案（包括 Tomcat 和 Apache HTTP）的支援而贏得了良好的聲譽。 其數百個支援客戶包括超過一半的財富 500 強企業，以及 Pfizer、Johnson & Johnson、British Telecom (BT)、NASA、Intel、Royal Bank of Scotland 和 Bear Stearns 等家喻戶曉的企業。 我們的公告…

Spring 2.5 背後的核心主題之一是全面的基於註解的配置。 我們已經討論和寫了很多關於 @Autowired、Spring MVC 的 @RequestMapping 以及使用 JUnit4 或 TestNG 編寫的註解測試的新支援。 @Autowired 肯定是 Spring 2.5 註解的核心之一，可用於服務組件、Web 組件、單元測試 – 甚至在使用 Spring 的 @Configurable 和 AspectJ 編織時的域對象。 Spring MVC 的 @RequestMapping 同樣靈活，支援處理方法簽名的多種變體。

今天我…

嗯，它花費的時間比我們最初預期的要長得多，但我很高興地說 Spring Dynamic Modules 專案今天達到了它的 1.0 里程碑。 當我早在 2006 年 9 月首次發布關於這個主題的文章時 ("Spring OSGi 支援正在增強")，最初的規範只是一個針對 Spring Framework 的問題的附件，並且與更廣泛的 OSGi 社群的聯繫才剛剛開始形成。

快進到十八個月後，Spring Dynamic Modules 已經成為 Spring 產品組合中的一個完整的專案，擁有來自 SpringSource、BEA 和 Oracle 的提交者。 BEA 和 Oracle 都在使用 Spring Dynamic Modules 來構建他們自己的基於 OSGi 的產品（例如，參見 "WebLogic Event Server - 為什麼我們使用 Spring")，並且 Spring Dynamic Modules 討論組擁有近 1000 名成員。 OSGi Alliance 本身已經成立了一個 企業專家組…

我很高興地報告 (與 Adrian 一起)，經過 3 個里程碑版本和 2 個候選版本，Spring Dynamic Modules (以前稱為 Spring OSGi) 1.0 已經發佈。

自從我之前的 post (關於 1.0 M1) 以來，許多功能都得到了改進或添加； 我將在未來的文章中更多地討論它們（還有參考 文檔，其中詳細解釋了該函式庫），所以我只會列出幾個

- 一致性

我們希望提供一個強大、簡單且一致的編程模型。 這就是為什麼 Spring Dynamic Modules 建立在 Spring 之上並使用其經過驗證的概念、可靠性和普遍性的原因。

- 高度非侵入性

使用 Spring DM 的推薦方法是不要在您的程式碼中使用它的類別，或者在您的 bundle manifest 檔案中包含任何對它們的導入。 如果您不在程式碼中使用 Spring，而僅用於您的應用程式配置，則適用相同的規則。 Spring DM 為您建立應用程式上下文，因此您無需依賴 Spring 或 Spring DM。 並且不要擔心自定義命名空間或 XML schema 等問題 – 我們已經涵蓋了它們。

- OSGi 服務動態生命週期管理

這是 Spring DM 最重要的功能之一 – 能夠像與普通 bean 一樣與 OSGi 服務交互。 您無需編寫任何程式碼即可發布和使用 OSGi 服務； 我們將為您處理動態 – 並且您擁有完全的控制權（未來將有更多相關資訊）。

- 更智慧的整合測試框架

由於我們在內部廣泛使用了 Spring-DM 整合測試，因此我們改進了預設值、maven 整合，並使自動 manifest 檔案生成更快、更智慧。 例如，該框架自動確定測試 bundle 中可用的類別，並且不會為其生成導入。

- 簡單的 bundle 交互

Andy Piper (blog) 添加了一種簡單、宣告式的方法，可以根據模組生命週期和 Spring bean 依賴關係來安裝/啟動/停止/更新 bundle。

- 受管理的啟動/關閉上下文創建

在 OSGi 應用程式中，應用程式被分解為各種模組（也稱為 bundle），這些模組相互依賴服務。 這在模組之間創建了一個依賴樹，該依賴樹在啟動和關閉期間變得非常重要。 傳統上，可以通過基於依賴順序安裝和啟動 bundle 來解決此問題，但是，這並不能完全解決該問題。 正如 OSGi 規範建議的那樣，初始化時間較長的 OSGi 服務（例如連接池）應依賴於與用於啟動和停止 bundle 的線程不同的線程。 這意味著如果啟動了 bundle，並不意味著它的服務已經啟動。 並不是每個應用程式都準備好在其啟動期間等待其所需的服務 – 事實上，很少有應用程式這樣做。 這意味著 bundle 將失敗，因為它依賴於幾毫秒後發布的服務（預設情況下，OSGi 是一個在 VM 中發生的平台，事情發生得非常快）。

這種行為並不罕見 – 事實上，在具有多個 bundle 的多核平台上，這種情況在啟動時非常普遍。 Spring DM 通過確定依賴關係（來自 Spring 配置）並等待它們在創建應用程式上下文之前變為可用來解決此問題。 關閉時將使用類似的過程，Spring DM 將根據其依賴順序停止上下文，因此您不必擔心啟動或停止您的 bundle。

- 無線程依賴等待

在討論依賴機制時，我不能不提到 Hal Hildebrand 實現的用於依賴等待的「無執行緒」方法（聽起來有點自相矛盾，我知道 - 我們正在為它設計一個炫酷的標題）（請參閱他的部落格）。由於各種服務需要可用，模組才能正確啟動，因此需要某種等待/監控機制，傳統上這意味著使用執行緒。

然而，在 OSGi 平台上，可以（而且會有）多個模組（很容易達到數十個） - 為每個模組使用一個等待執行緒根本無法擴展。 我們努力改善的一個重點就是這個模型，我相信我們提供了一個非常好的解決方案 - 在等待過程中完全不使用執行緒。 這意味著無論部署了 3 個 bundle 還是 300 個 bundle，除非您的模組真正開始啟動，否則不會消耗任何 CPU 時間。

Spring Dynamic Modules 不僅僅是將 API「Spring 化」，而是處理不同的執行期環境。

關於工具方面，Spring IDE 支援 Spring DM 命名空間，並且（感謝 Christian）還為 Eclipse PDE 提供了 Spring-DM 特定的 targets，這個功能在 Spring IDE 每夜建置版本中可用（有關安裝和使用外掛程式的更多資訊，請參閱參考文檔中的 說明）。

未來方向

現在 1.0 已經發布，下一步是什麼？ 有很多領域需要涵蓋

Web 支援

OSGi 平台提供專用的 Http Service，但使用它需要編碼。 資源載入、JSP 生成和部署等事情可以顯著簡化。 這是 1.1 版本的主要重點。

持久層

現代持久層工具提供了高級功能，例如延遲載入，它們依賴於類生成和代理，從而彎曲了 OSGi 環境強制執行的模組化邊界。 我們希望解決這個問題，就像 Web 支援一樣，無論是使用普通的 JDBC 還是/和 ORM 工具，都能提供流暢的體驗。

AOP

在解決持久層問題之後，我們正在尋找在 OSGi 內部進行通用 AOP 的解決方案。 這是一個難題，要正確地解決它，需要 OSGi 平台內部的支援。 好消息是，像 Equinox Aspects 這樣的專案已經開闢了道路，並且 OSGi Enterprise Expert Group (EEG) 也將這個問題納入了他們的雷達。

說夠了

如果您想了解更多關於 Spring Dynamic Modules 的資訊，請參閱專案頁面和參考文檔，並使用我們的郵件列表（論壇很快就會出現）。 此外，最近我們製作了一些 OSGi/Spring DM 的 螢幕錄影，可以在 Spring DM 首頁上找到。 第一個（由兩部分組成），由我製作，展示了如何快速創建一個專案來使用 Spring DM 進行整合測試。
為什麼要進行整合測試？ 因為使用 Spring DM，這是一個非常簡單快速的過程，也是學習 OSGi 的非常有效的方式（尤其是在模組化方面）。

未來還會有更多的螢幕錄影 - 只要告訴我們您想看什麼，我們會根據請求的數量相應地安排它們。

廢話不多說，「使用 Spring DM 進行 OSGi 整合測試」