Blueprint入门之六
Blueprint用另一个命名空间（http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0）支持osgi configadmin来配置节点的相关参数。
上例中”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服务除了读取配置数据外，还可以用来回写配置数据，在这里就暂时不详细描述了。
