我很高興（與 Adrian 一起）報告，在經歷了 3 個里程碑和 2 個釋出候選版本之後，Spring Dynamic Modules（前身為 Spring OSGi）1.0 已釋出。

自上次 帖子（關於 1.0 M1）以來，許多功能得到了改進或新增（大約 1.0 M1）；我將在未來的文章中詳細介紹它們（還有詳細介紹該庫的參考 文件），所以這裡我只列舉幾項：

- 一致性

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

- 高度非侵入性

使用 Spring DM 的推薦方法是*不要*在程式碼中使用其類，或者在捆綁包清單中匯入它們。如果您不在程式碼中使用 Spring，而僅用於應用程式配置，則相同的規則適用。Spring DM 會為您建立應用程式上下文，因此您無需依賴 Spring 或 Spring DM。而且不用擔心自定義名稱空間或 XML 模式等問題——我們已經解決了它們。

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

這是 Spring DM 最重要的功能之一——能夠像處理*普通* Bean 一樣與 OSGi 服務進行互動。您可以在不編寫任何程式碼的情況下發布和消耗 OSGi 服務；我們會為您處理動態性——並且您擁有完全的控制權（未來將提供更多關於此的資訊）。

- 更智慧的整合測試框架

由於我們在內部廣泛使用了 Spring-DM 整合測試，因此我們改進了預設設定、Maven 整合，並使自動清單生成比以前更快、更智慧。例如，該框架會自動確定測試捆綁包中可用的類，並且不會為其生成匯入。

- 簡單的捆綁包互動

Andy Piper（部落格）添加了一種簡單、宣告式的方法，可以根據模組生命週期和 Spring Bean 依賴關係來安裝/啟動/停止/更新捆綁包。

- 受管啟動/關閉上下文建立

在 OSGi 中，應用程式被分解成各種相互依賴服務的模組（也稱為捆綁包）。這會在模組之間建立依賴關係樹，這在啟動和關閉過程中很重要。傳統上，這可以透過根據依賴順序安裝和啟動捆綁包來解決，但這並不能完全解決問題。如 OSGi 規範所建議的，耗時初始化的 OSGi 服務（如連線池）應該依賴於與啟動和停止捆綁包所用的執行緒不同的執行緒。這意味著，如果一個捆綁包已啟動，並不意味著它的服務已經可用。並非所有應用程式都已準備好在啟動時等待其所需的服務——實際上，很少有應用程式這樣做。這意味著捆綁包將失敗，因為它依賴於在幾毫秒後釋出的*其他*服務（OSGi 預設情況下是一個 VM 內平臺，事物*非常*快速地發生）。

這種行為並不少見——實際上，在多核平臺上，多個捆綁包在啟動時很常見。Spring DM 透過確定依賴關係（來自 Spring 配置）並在建立應用程式上下文之前等待它們可用，來解決此問題。在關閉時將進行類似的流程，Spring DM 將根據依賴順序停止上下文，因此您不必擔心啟動或停止您的捆綁包。

- 無執行緒依賴等待

在討論依賴機制時，我不能不提 Hal Hildebrand（請參閱他的 部落格）實現的“無執行緒”依賴等待方法（我知道這聽起來有點像矛盾修飾法——我們正在為其尋找一個好名字）。由於模組正常啟動需要各種服務可用，因此需要某種形式的等待/監控，這通常需要使用執行緒。

然而，在一個 OSGi 平臺上，可以有（並且將會有）多個模組（很容易達到幾十個）——每個模組使用一個等待執行緒根本無法擴充套件。我們努力改進了這個模型，並且我認為我們提供了一個非常好的解決方案——為等待過程根本*不*使用執行緒。這意味著，無論部署了 3 個捆綁包還是 300 個，只要您的模組沒有實際啟動，就不會花費任何 CPU 時間。

 

Spring Dynamic Modules 不僅僅是“spring-ify”一個 API，而是處理一個不同的執行時環境。

 

在工具方面，Spring IDE 支援 Spring DM 名稱空間，並且（感謝 Christian）還為 Eclipse PDE 提供了 Spring-DM 特定的 目標，這些功能在 Spring IDE 的 nightly builds 中可用（有關安裝和使用外掛的更多資訊，請參閱參考文件 可用）。

 

未來方向

 

既然 1.0 已釋出，下一步是什麼？有很多領域需要涵蓋。

Web 支援

OSGi 平臺提供了一個專用的 Http Service，但使用它需要編寫程式碼。諸如資源載入、JSP 生成和部署之類的事情可以大大簡化。這是 1.1 版本的主要關注點。

持久化

現代持久化工具提供高階功能，如懶載入，這些功能會違反 OSGi 環境強制的模組化邊界，因為它們依賴於類生成和代理。我們希望解決這個問題，就像 Web 支援一樣，無論使用純 JDBC 或/和 ORM 工具，都能提供順暢的體驗。

AOP

在持久化問題之後，我們正在尋求在 OSGi 中執行通用 AOP 的解決方案。這是一個棘手的難題，要正確處理需要內部 OSGi 平臺支援。好訊息是，像 Equinox Aspects 這樣的專案已經開闢了道路，而 OSGi 企業專家組（EEG）也已將該問題提上日程。

 

廢話少說

 

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

未來還會有更多螢幕截圖——請告訴我們您想看什麼，我們將根據請求數量對其進行排隊。

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