首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 編程語言 >  >> Java 程式設計 >> Java 相關知識

GlassFish OSGi-JavaEE 專題(一):企業級 OSGi 開發與 GlassFish 整合

     編輯:Java 相關知識

專題簡介

自 GlassFish v3 起,核心核心採用 OSGi(基於 HK2 與 Apache Felix)重構,實現模組化、輕量化、熱部署。本九部分專題將深入解析 GlassFish OSGi-JavaEE 技術棧,涵蓋 Web、EJB、CDI、JPA、Blueprint 等企業級規範在 OSGi 環境下的整合與開發實戰。

專題規劃

部分主題
Part 1GlassFish OSGi-JavaEE 概覽與企業級 OSGi 現狀(本文)
Part 2OSGi/Web 容器:開發與部署 Web Application Bundle (WAB)
Part 3OSGi/EJB 容器:EJB Bundle 開發與部署
Part 4OSGi/CDI 整合:簡化企業級 OSGi 開發
Part 5-6EAR 與 OSGi 整合:Apache Aries Application 與 EJB Bridge 實戰
Part 7GlassFish、HK2、OSGi 三角關係與 HK2 未來展望
Part 8核心內核深度解析:模組配置、載入、啟動與擴展
Part 9貢獻 GlassFish OSGi 與 OSGi-JavaEE 社群流程

什麼是 GlassFish OSGi-JavaEE?

GlassFish OSGi-JavaEE = 企業級 OSGi 的 GlassFish 實現。 它打通 OSGi 動態模組系統與 JavaEE 成熟組件模型(EJB、JPA、JTA、CDI、JSF…),實現雙向互操作:

  • OSGi 服務可激活 JavaEE 組件
  • JavaEE 組件可透過 CDI/服務登錄表使用 OSGi 服務

為什麼企業級 Java 需要 OSGi?

痛點一:Classpath 地獄

傳統扁平 Classpath 導致:

  • 版本衝突:同類不同版本只能載入第一個
  • 依賴遺失:運行數週後才拋出 ClassNotFoundException
  • 冗餘打包:WAR/WEB-INF/lib 重複封裝共用庫,浪費記憶體

痛點二:混亂耦合

大型系統演變成「義大利麵代碼」,模組間隱性依賴難以追蹤,微小變更引發連鎖崩潰,測試成本指數級上升。

痛點三:缺乏動態性

JavaEE 部署即鎖定,無法運行時熱更新 Servlet、EJB、JSP,維護窗口極窄。

OSGi 如何解決?

模組化與版本隔離

  • Bundle = JAR + MANIFEST.MF 元資料(Export-Package/Import-Package、版本號)
  • 運行時建立依賴圖,強制顯式宣告可見性,同類不同版本共存
  • 啟動時即驗證依賴完整性,缺失即時拋出異常,不再延遲到運行期

動態生命週期

Bundle 狀態機:Installed → Resolved → Starting → Active → Stopping → Uninstalled。支援運行時安裝、更新、解除安裝,服務動態發現與綁定。

企業級規範橋接

OSGi Enterprise 規範(R5+)定義:

  • Web Application Bundle (WAB) — 對標 WAR
  • JPA、JTA、JNDI、JMS、Blueprint、CDI 整合規範
  • Service Loader Mediator — 解決傳統 META-INF/services 在 OSGi 失效問題

GlassFish 中的企業級 OSGi 實現

核心架構

  • 啟動 Apache Felix → 安裝核心 Bundle(HK2 核心、各容器 Bundle)
  • JavaEE 容器(Web、EJB、CDI…)皆打包為 OSGi Bundle
  • 平台服務(事務、HTTP、JMS)發布為 OSGi 服務,Bundle 可透過服務登錄表查找

兩類 Bundle

  1. Plain OSGi Bundle:純 OSGi,無 JavaEE 組件
  2. Composite Application Bundle:含 JavaEE 組件(EJB、Servlet、JPA…),同時受 OSGi 與 JavaEE 容器管理

API 可用性矩陣

類別API 範例Plain BundleComposite Bundle
A:容器管理組件EJB、CDI、Servlet、JSF、JAX-RS❌✅
B:平台服務JNDI、JTA、JDBC、JMS✅(透過 OSGi 服務)✅
C:功能性 APIJAXB、JAXP、JPA✅(GlassFish 修正 ServiceLoader 問題)✅

OSGi 與 JavaEE 類載入衝突的根源

雙親委派 vs OSGi 網狀委派

JavaEE 採用嚴格階層類載入器(Bootstrap → Extension → Application → EAR → WAR),子不可見父同級類。OSGi 採用網狀委派,Bundle 間透過 Import/Export 精確連線。

Thread Context ClassLoader (TCCL) 難題

  • JavaEE 框架慣用 TCCL 載入應用類(JSP、JDBC 驅動、ServiceLoader)
  • OSGi 預設不設 TCCL,導致框架找不到類
  • GlassFish OSGi/Web 模組專門配置 TCCL 以相容既有 Web 應用

ServiceLoader 在 OSGi 的失效與修正

傳統 ServiceLoader 依賴 TCCL 掃描 META-INF/services,OSGi 中:

  1. TCCL 常未設定
  2. Bundle 間單一導出限制,無法多實現共存
  3. 實現類常在 internal 套件,不導出
  4. Bundle 動態來去,缺乏事件通知

OSGi R5 引入 Service Loader Mediator 規範,GlassFish 實現透明橋接,讓既有代碼無修改運行。

下一步預告

Part 2 將實戰演示:開發與部署首個 Web Application Bundle (WAB) 到 GlassFish,深入理解 OSGi Web 規範與開發工具鏈。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved