BlueDavy之技術Blog

這是Lifecycle Layer中的最大改進，在之前的規范中只是簡單的描述了下框架的啟動和關閉，在制定了這個規范后，以后無論是啟動equinox還是felix，都可采用同樣的方式啟動，詳細的來看看，本文摘自《OSGi原理與最佳實踐》。

首先來看看外部應用如何通過Framework的API來實現Framework的啟動，來看張啟動方法的時序圖先：

這個時序圖完整的說明了如何通過Framework的API來實現OSGi Framework的啟動和停止：

n  調用FrameworkFactory的newFramework方法

所有OSGi的實現都必須實現FrameworkFactory接口，此接口中只有一個方法，即newFramework(Map configuration)，外部容器在實例化FrameworkFactory實現對象上有兩種做法：

A.        Class.forName(FrameworkFactory實現類).newInstance()

B.        通過Java 6中提供的ServiceLoader尋找并加載FrameworkFactory的實現類，使用方法為：

假設com.acme.osgi.Factory是FrameworkFactory的實現類，那么則在META-INF下新建services目錄，在此目錄下建立一個org.osgi.framework.launch.FrameworkFactory的文件，文件內容即為：com.acme.osgi.Factory，在程序中則這么編寫來加載此FrameworkFactory實現類：

ServiceLoader<FrameworkFactory> sl=ServiceLoader.load(FrameworkFactory.class);

Iterator<FrameworkFactory> it=sl.iterator();

在創建了FrameworkFactory實現的實例后，就可調用newFramework方法了，newFramework方法中的Map參數為控制OSGi框架行為的一些配置項，關鍵的有：

n  org.osgi.framework.bootdelegation

配置哪些package需要從boot classloader中加載，配置的值可為com.acme.*或com.acme.services。

n  org.osgi.framework.executionenvironment

配置Framework執行所需的環境，例如J2SE-1.5。

n  org.osgi.framework.library.extensions

native code的擴展名配置，例如so,dll。

n  org.osgi.framework.startlevel

配置Bundle啟動級別。

n  org.osgi.framework.storage

配置用于存儲OSGi應用運行時的Bundle狀態等信息的路徑，當此路徑不存在時，框架應負責進行創建，如創建失敗則拋出異常。

n  org.osgi.framework.storage.clean

配置storage目錄是否要清除，例如值配置為onFirstInit，意味著當Framework Bundle第一次初始化之前，storage目錄將被清空，這個配置項的好處是可以控制Framework重啟后是否需要根據上次運行時的狀態來啟動。

n  org.osgi.framework.system.packages

Framework的parent ClassLoader應對外export的packages。

n  org.osgi.framework.system.packages.extra

在上面的配置項的基礎上增加了擴展屬性的配置，例如：

org.osgi.framework.system.packages.extra=org.acme.foo;version=1.2

n  org.osgi.framework.bundle.parent

和equinox中的osgi.parentClassLoader屬性的含義一樣，用于控制boot classloader具體是哪個classloader，有四個可選的屬性值：boot、app、ext、framework，含義和equinox完全相同。

根據需要給這些屬性配置相應的值后，即可調用newFramework方法創建出Framework對象了。

n  調用Framework的init方法

在init方法中完成Bundle Context的創建以及Framework services的注入。

n  通過Framework獲取BundleContext

n  安裝Bundle

通過BundleContext.installBundle來安裝需要的Bundle。

n  調用Framework的start方法

Framework將StartLevel service設置為指定的啟動級別，從而促發已安裝的所有的Bundle的resolve和啟動。

n  調用Framework的waitForStop方法

調用此方法，等待Framework的停止運行。

按照以上說明，一個典型的基于OSGi R4.2規范的OSGi Framework的啟動過程代碼編寫示例如下：

Map p=new HashMap();

p.put(“org.osgi.framework.storage”,System.getProperties(“user.home”)+File.separator+”osgi”);

FrameworkFactory factory=Class.forName(factoryClassName).newInstance();

Framework framework=factory.newFramework(p);

framework.init();

BundleContext context=framework.getBundleContext();

…//安裝Bundles

framework.start();

framework.waitForStop();

對比Felix的啟動代碼，是不是覺得有點相似呢？

OSGi規范中對Framework的生命周期也做了詳細的說明，圖示如下：

具體來看看init、start以及stop Framework時會做哪些事情。

n  init

init后，需要做到以下效果：

啟動事件分發處理功能；

配置好Security Manager；

StartLevel設置為指定的startlevel，默認為0；

創建可用的BundleContext對象；

所有安裝的Bundles的狀態均設置為INSTALLED；

Framework提供的services都可用；

Framework的狀態為STARTING。

n  start

負責根據StartLevel啟動相應的已安裝的Bundle，如Bundle啟動失敗，則廣播Framework.ERROR的事件，啟動完畢后Framework的狀態為ACTIVE。

n  stop

負責停止所有運行的Bundle，釋放所有的資源，并將Framework的狀態置為RESOLVED。

n  update

停止Framework，并給Framework.waitForStop方法返回STOPPED_UPDATE或STOPPED_BOOTCLASSPATH_MODIFIED事件值，然后應用代碼應自行完成update處理。

在Framework規范中，OSGi還說明了Framework運行于多線程模式下，即所有Bundle都運行在各自的線程中，基于事件機制來響應其他Bundle的事件。