OSGI Blueprint入門之六

     Blueprint用另一個命名空間（http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0）支持osgi configadmin來配置節點的相關參數。

 

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd" default-timeout="0">

 <!--從ConfigAdmin服務裏獲取ID爲"com.ponder.configuration"的配置數據，如果配置數據裏沒有以下數據，則用以下的默認值 -->
<cm:property-placeholder persistent-id="com.ponder.configuration">
<cm:default-properties>
<cm:property name="Type" value="0" />
<cm:property name="URL" value="http://192.168.0.2/" />
</cm:default-properties>
</cm:property-placeholder>
<!--使用配置數據的例子 -->
<bean id="bean04" class="com.ponder.examples.bean04">
<property name="url" value="${URL}"/>
<property name="type" value="${Type}"/>
</bean>
</blueprint>

 

 

    上例中”URL”和”Type”就是兩個可從osgi ConfigAdmin服務獲取配置值的變量。如果在ConfigAdmin服務無法獲得相應的值，將採用以上cm:property裏指定的默認值。

 

    在此，我們簡單介紹一下OSGI ConfigAdmin服務: OSGI ConfigAdmin服務是採用whiteboard模式來處理各bundle的配置數據。

 

    一方面提供ConfigAdmin服務的bundle從外部資源（如property文件、xml文檔、數據庫等等，這完全由ConfigAdmin服務的具體實現bundle決定，在同一平臺上可有多個ConfigAdmin服務的實現） 讀取名/值對形式的配置數據，這些配置數據都用service.pid（就是一串字符串）來分組。

 

    另一方面，需要獲得配置數據的bundle將發佈ManagedService服務，並且設定服務屬性service.pid。當ManagedService發佈後，提供ConfigAdmin服務的bundle將感知這個ManagedService服務，並將由服務屬性service.pid決定的那組配置數據通過調用ManagedService服務的void updated（java.util.Dictionary props）方法注入目標bundle裏。這樣就完成了配置數據的注入。

 

    之所以要採用whiteboard pattern，是因爲這樣可以動態地實現配置數據的注入，即每次ManagedService服務發佈時，都可以獲得配置數據，而這恰好是OSGI平臺上bundle可能經常需要動態加載/卸載的動態性所要求的。

 

    在Karaf環境下，配置數據通常以<service.pid>.cfg的文件名格式放在<karaf-root>/etc/下，由Karaf集成的ConfigAdmin服務bundle讀取。

 

    在上面的blueprint的配置例子中，cm:property-placeholder節點指定的persistence-id屬性就是ConfigAdmin所需的setvice.pid。

 

    最後補充一下，ConfigAdmin服務除了讀取配置數據外，還可以用來回寫配置數據，在這裏就暫時不詳細描述了。