以下都是剛開始 Geronimo 3.0 時寫在開心網上的一些筆記, 現移到此處權作備份.
Geronimo 3.0 框架重構的工作已進行大半, 說來慚愧, 我除了感嘆大師們的思想和設計之外, 剩下的只有學習了, 不知何時才能與大師們煮酒論 Geronimo.
本周末, 讀了一些代碼, 列了一些要點, 以備以后查詢所需, 并與大家共享.
1. 內核的創建.
在 OSGI 環境中, 所有的組件都已 Bundle 的形式存在, Geronimo 所有的內核類和插件也不例外, 都是在 OSGI
的框架啟動后被載入的, 再無原來的 BootStrap 之類的東西了. 如今的內核的初始化, 基本 Geronimo GBean 的載入和
Geronimo 插件的加載都放到 BootActivator 中, 會在第一個 Geronimo 的 Bundle 中處理, 并將
Kernel 通過 OSGI 的 Service 對外發布.
2. 插件的讀取
原來的
RepositoryConfigurationStore 想來不會再用了, 如今 config.ser 文件的讀取放在
ConfigurationActivator 之中, 在 Bundle 啟動時會被讀取. 同時通過 ConfigurationManager 的
loadConfiguration 方法加載, 如此做目的, 一來將插件的生命周期與 Bundle 的生命周期作了映射, 二來也有機會記錄了
BundleContext 引用.
3. 調用順序
BootActivator ->
PersistentConfigurationListener -> loadConfiguration( Artifact )
-> ConfigurationActivator -> loadConfiguration (ConfigurationData)
整個調用邏輯略顯冗雜, 皆因 Bundle 的生命周期與 Configuration 的生命周期交合一起所致. 前幾天, 我在論壇了回了貼,
竊以為, 既然 Kernel 依舊存在, 何不區分對待, 各管各得, 省得互相映射而導致這樣那樣的問題, 不好之處只是 Geronimo 沒有與
OSGI 像現在一樣結合在一起. 結果被大師們無視了, 想來有什么問題, 抑或大師們覺得俺們都弄得差不多了, 你再提個想法, 讓俺們白干了 !
以以往的經驗, 前者居多, 記錄在此, 今后弄明白了再添加說明, 印象會深刻一點.
下周有機會, 要看一下類載入結構和插件依賴關系的變動, 這個應該是從 OSGI 之最大獲益了.
回憶了一下 Geronimo 進行 OSGI 整合之處的討論, 當時有些還不怎么明白, 現在明朗多了.
總體上, 當時有這么些整合方案 :
一種是將 OSGI 容器以插件的形式部署于 Geronimo 中, 形式和 Web 容器, EJB 容器等一樣, 部署應用時,
通過檢索應用的部署信息, 若與 OSGI 相關, 則部署到 OSGI 容器中, 其他類型的還是各回各家, 各找各媽. 顯而易見,
這種方式是種無痛整合, 工作量只是開發一個新的插件.
第二種方式, 就是 Geronimo 部署到 OSGI 環境中, 所有的
Geronimo 的 JAR 文件和插件均是以 Bundle 的形式存在于 OSGI 環境中, 好處自然是享受到 OSGI 的那些動態載入,
細粒度類載入器關聯等. 依據 Geronimo 的 Kernel 是否存在, 這種方式又可以再做細分. Kernel 存在的情況下,
事實上也就是現在使用的方式, 首先啟動內核, 之后由 ConfigurationManager 啟動各個插件, 再將其加載到內核中去.
這種方式下, Geroniom Is Part Of OSGI, 整合依舊不是很徹底. 最好的自然是 Geronimo IS OSGI, 此時,
再無 Kernel, 再無 GBean, 天下大同, 皆為 Bundle. GBean 之流可以通過 blueprint 的服務來代替,
如此, Geronimo 則完全脫胎換骨了. 革命革命, 先革己命, 在此得到印證.
另外, 我在想, 現在看, OSGI
幾乎成了香饃饃, 感覺你的產品要是沒使用 OSGI 架構, 都不好意思和別人打招呼. 我得承認, OSGI 確實有很多吸引人的地方, 但是應用于
Java EE 的環境下, 還有許多待改進的地方, 這估計也是出了那么多 RFC 的原因, 畢竟 OSGI
之處并不是想應用于企業應用的環境中, 正如 JAVA 之處是想用來做機頂盒的開發一樣, 后來在 Web 環境下確大放異彩. 在整合的過程中,
出現了很多問題, 例如之前討論的, RMI 類載入器的問題, 擴展類路徑的問題, 均未在 OSGI 中得到完美解決. 如此整合 OSGI,
想來也是配合公司新推的EBA 的編程模型, 并為 WAS 先踩踩雷.
以上內容, 均是隨手而寫, 是從我自己的理解和對大師的言論中推斷而來, 大家看的時候自個注意.
OSGI 中 Bundle 之間的依賴關系的處理比較直白， 在一個 Bunlde 安裝之后的某個時機， 對其標注依賴關系進行解析，
如果萬事俱備， 設置其為 Resolved 狀態， 如果不滿足， 則處于 INSTALLED 狀態。 這種處理方式， 與 OSGI
是一個靈活易插拔的環境有關。
而在 Geronimo 中， 可不能任其如此， 所有的 Geronimo 插件都在 geronimo－plugin.xml/config.ser 中標注了依賴關系。在啟動插件時， 必需首先啟動其所依賴的所有其他組件。
在之前版本中， 這些都是由 ConfigurationManager 來處理的， 插件所以依賴的無非是其他插件或者類庫文件， 對于前者， ConfigurationManager 會首先啟動之， 而后者， 則之間將其加入當前類載入器路徑中即可。
當切換到 OSGI之后， 一切都變了 。 首當其沖的是那些類庫文件， 即 JAR 文件， 它們成為了一個個 Bundle， 都有了鮮活的生命，
不可只將其放到類載入器路徑中就一了百了， 需要俺們安裝和啟動之。 其次， 誰負責按順啟動這些插件， 之前是由
ConfigurationManager， 現在則在 DependencyManager （Bundle Extender）來處理。 究其原因，
個人感覺， 技術上不存在限制， 但從設計上而言， ConfigurationManager 管理的是 Geronimo 插件在
Geronimo 內核中的生命周期， 而在 OSGI 環境中，有 OSGI 環境中的組件處理依賴關系， 顯得更自然些。（個人意見， 僅供參考）
最后記錄一下 DependencyManager 的處理邏輯， 它監聽了每個 Bundle 的啟動， 接收到安裝事件之后， 會讀取 geronimo－plugin.xml 文件中的依賴關系， 并嘗試啟動這些依賴組件。