在之前的一篇blog中我曾經寫到過CM對于application level的configuration的不適應，提到的主要是兩點：
1、無法在外部統一的對Bundle中service所需要的屬性進行管理；
??????當時基于這個約束，只好在各自的bundle下編寫一個管理當前bundle屬性的服務，當外部需要管理此bundle的屬性時，必須通過這個服務來管理，否則的話改變是不會起到效果的。
2、無法共享屬性的配置。
????? 每個bundle都保存自己獨立的一份屬性配置，這就導致了當出現共享屬性時，在管理端也不得不同時去重復的更新多個bundle。
昨天在調試產品的時候，又被CM搞的郁悶了一把，由于CM是根據BundleLocation和service.PID共同來綁定屬性的，也就是說當BundleLocation改變了的情況下屬性就無效了，而且也無法被重寫，這對于實際的應用而言幾乎是不可接受的，因為模塊部署的路徑、模塊的名稱改變這都是很正常的事，但根據CM這樣的方式的話，也就意味著模塊部署的路徑、模塊的名稱都是不可改變的。
想想挺惱人的，就開始仔細的看Equinox的CM實現的代碼，經過仔細的查看后，發現自己疏忽了一點，冤枉了CM，其實CM也是留了一個口以供上面這樣的情況下的處理的，后來對照了下OSGi R4中CM規范的描述，確實如此，如果希望配置不要和bundleLocation綁定，那么可以在注冊ManagedService接口實現的服務時將其server.bundleLocation設置為null，如下：
<component?name="PortComponent">
???????<implementation?class="com.terdon.spike.port.PortService"/>
???????<property?name="service.pid"?value="com.terdon.port"/>
???????<property?name="service.bundleLocation"?value="null"/>
???????<service>
???????????????<provide?interface="org.osgi.service.cm.ManagedService"/>
???????</service>
</component>然后就可以在其他的管理屬性的服務中調用ConfigurationAdmin來實現對這個service的屬性的管理：
Configuration configuration=admin.getConfiguration("com.terdon.port", null);
根據這樣的分析，也就是說我以前所說的第一點的情況是冤枉了CM，現在開始給它平反，:)
摘一下OSGi R4 CM規范中對于這種情況的描述：
"Bundles with the required permission can create Configuration objects that
are not bound. In other words, they have their location set to null. This can
be useful for pre-configuring bundles before they are installed without having
to know their actual locations.
In this scenario, the Configuration object must become bound to the first
bundle that registers a Managed Service (or Managed Service Factory) with
the right PID.
A bundle could still possibly obtain another bundle’s configuration by registering
a Managed Service with the right PID before the victim bundle does
so. This situation can be regarded as a denial-of-service attack, because the
victim bundle would never receive its configuration information. Such an
attack can be avoided by always binding Configuration objects to the right
locations. It can also be detected by the Configuration Admin service when
the victim bundle registers the correct PID and two equal PIDs are then registered.
This violation of this specification should be logged."
從上面這段描述中，可以看出，CM之所以這么設計主要還是從安全性的角度考慮的。
但對于第二點，目前看來確實是如此，屬性無法共享，因為pid必須是唯一的，我已經發了郵件給equinox maillist，看看是不是有人會有辦法，:)