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服务除了读取配置数据外，还可以用来回写配置数据，在这里就暂时不详细描述了。