OSGI Module&lifecycle
OSGI概念中主要分為了Bundle和Service，可以認為Bundle是一個模塊的管理器，主要是通過BundleActivator管理模塊的生命周期，而Service則是這個模塊可暴露對外的服務對象，這里體現了OSGI和傳統的Plugin Framework不同的一個地方，管理和靜態結構分開，在OSGI中通過在manifest.mf文件中增加一些內容來發布Bundle，在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露對外的包、所依賴的包；每個Bundle擁有自己的ClassLoader以及context，通過context可進行服務的注冊、卸載等，這些操作都會通過事件機制廣播給相應的其他的Bundle；一般來說都為通過在Bundle中編寫初始需要注冊的服務的方法來完成Bundle可供外部使用的服務的暴露功能；如需要調用其他Plugin提供的服務可通過context的getServiceReference先獲取Service的句柄，再通過context.getService(ServiceReference)的方法獲取Service的實體。
前一段時間對osgi的service層做了介紹，下面介紹module和lifecycle層，在這里主要介紹lifecycle
系統框架對bundle的生命周期進行了管理。
osgi生命周期的管理，覆蓋到bundle的安裝，啟動，停止，更新，卸載，和監控這么一個過程。
Bundle的生命周期
下面是bundle的lifecycle的類圖
下面詳細介紹bundle的幾個對象
l Bunlde 標識
Identifier
Location
symbolicName
l bundle的狀態
狀態轉換圖
ü bundle的安裝一般有兩種方式：
通過另外一個bundle的bundlecontext來完成
通過命令行的形式（比如系統bundle一般是這樣的）來完成的
ü Bundle的解析（一般是在啟動過程中完成的）
根據bundle的定義，創建基于版本的module（ModuleDefinition，ContentLoader，Wire）
ü Bundle的啟動，由該bundle的調用start api來完成的
這里包含創建該bundle的上下文（BundleContext）
創建該bundle的activator，可以在activator里進行與該bundle相關的service的注冊，bundlelistener，servicelistener ,frameworklistener的注冊以及安裝其他的bundle.等.
是否要立即觸發該activator，需要根據該bundle的activator policy來決定；在用bundle獲取resource的時候，采取解析bundle，才創建該bundle的classloader和activate該bundle。這樣能節省啟動的時間，實現了懶加載。
下圖描述了bundle的啟動過程中的狀態變化
ü Bundle的更新
Bundle的更新，是從一個版本到另一個版本的遷移過程
流程如下：
1． 檢查bundle的狀態
如果是uninsalled，拋出異常
2． ，但是不改變持久化的狀態Stop bundle
3． 版本的修訂
4． 更改bundle的時間戳，狀態設置成installed
5． 發送unresolved事件給bundle
6． 把該bundle的老的module做一個removal標記，表示不可用
7． 發送updated事件給bundle
8． 啟動（start）bundle
ü Bundle的停止
1． 把bundle的持久化狀態設置成inactive
2． 檢查bundle的狀態
如果狀態是Installed，Resolved，就返回
如果是uninstalled，拋出異常
如果是starting，stopping，拋異常
如果ACTIVE，把bundle的狀態設置成stopping，發stopping事件跟響應的bundle
3． 調用該bundle的activator的stop操作，清理分配的資源
4． 清除bundle的上下文
清理該bundle注冊的service
釋放該bundle用到的service
刪除該bundle注冊的listener
5． 該bundle的狀態返回到resolved狀態
6． 發stopped事件給該bundle
ü Bundle的卸載
1． Stop bundle
2． 把該bundle從緩存中刪除
3． 把該bundle放入uninstall 類別中
4． 該bundle狀態設置成uninstalled
5． 觸發bundle的uninstall事件
6． 看是否有以來該bundle的module，如果沒有則垃圾回收
Listener和事件機制
關于這一部分功能和用法已在上一篇service層里已經做了介紹，這里只做一下簡單的羅列
ü Framework
FrameworkListener：
注冊時間：
觸發時間：
作用：OSGI environment
FrameworkEvent: type，bundle，throwable
ü Bundle
BundleListener
注冊時間：
觸發時間：
作用：a bundle lifecycle change.
BundleEvent: Bundle,type
ü Service
ServiceListener
注冊時間：
觸發時間：
作用：a service lifecycle change.
ServiceEvent:serviceReference ,type
|
資源
|
事件類型
|
觸發時機
|
|
Framework
|
STARTED
|
Framework啟動完成
Framework has started after all installed bundles that are marked to be started have been started and the Framework has reached the intitial start level.
|
|
ERROR
|
There was an error associated with a bundle.
|
|
PACKAGES_REFRESHED
|
Framework has completed the refresh packages operation initiated by a call to the
PackageAdmin.refreshPackages method.
|
|
STARTLEVEL_CHANGED
|
the Framework has completed changing the active start level initiated by a call to the StartLevel.setStartLevel
method.
|
|
WARNING
|
There was a warning associated with a bundle.
|
|
INFO
|
There was an informational event associated with a bundle.
|
|
Bundle
|
INSTALLED
|
The bundle has been installed.
|
|
STARTED
|
The bundle has been started.
|
|
STOPPED
|
The bundle has been stopped.
|
|
UNINSTALLED
|
The bundle has been uninstalled.
|
|
RESOLVED
|
The bundle has been resolved.
|
|
UNRESOLVED
|
The bundle has been unresolved.
|
|
STARTING
|
The bundle is about to start.
|
|
STOPPING
|
The bundle is about to stop.
|
|
Service
|
REGISTERED
|
This service has been registered.
|
|
MODIFIED
|
The properties of a registered service have been modified.
|
|
UNREGISTERING
|
This service is in the process of being unregistered.
If a bundle is using a service that is <code>UNREGISTERING</code>, the
bundle should release its use of the service when it receives this event.
If the bundle does not release its use of the service when it receives
this event, the Framework will automatically release the bundle's use of
the service while completing the service unregistration operation.
|
|
|
|
資源的查找
幾點說明
系統啟動時候，會把所有職責的關聯關系wire起來
并且創建核心的查找資源policy
還有就是有的module可以放在resolve階段可以放到查找資源的時候進行，實現懶加載的功能
1.查找資源的核心類，分發中心，所有的調度邏輯都在這里
2.所有的資源查找都代理到該核心類，有點象代理的方式
3.module的修改，這里會實時的得到更新（通過注冊listener）
資源的查找：在本bundle的classloader范圍內，進行class的查找，資源加載的順序可以參見規范
下面是類查找的類圖
該bundle的Classloader在bundle的resolve階段就創建好了
關于bundle的說明定義中的import export詳見規范
系統Bundle的啟動過程
1．系統bundle由框架啟動，并且只啟動一次
2． 創建服務的注冊中心，該中心作為各種事件的分發場所。
3． 創建核心的查找資源的policy，加入resolver listener到該policy，可以在module解析后，得到通知更新bundle的狀態
4． 初始化事件分發器
5. 在加載其他的bundle之前，創建系統的bundle負責容器相關的service，resolve系統bundle，創建系統bundle的activator，創建bundle的上下文，并觸發activator
6. 安裝其他的bundle
7 觸發系統bundle的started事件，標志系統bundle啟動完成
8. 觸發框架的started時間，標志框架啟動完成