在之前的一篇blog中我曾經(jīng)寫到過CM對于application level的configuration的不適應(yīng)，提到的主要是兩點：
1、無法在外部統(tǒng)一的對Bundle中service所需要的屬性進(jìn)行管理；
??????當(dāng)時基于這個約束，只好在各自的bundle下編寫一個管理當(dāng)前bundle屬性的服務(wù)，當(dāng)外部需要管理此bundle的屬性時，必須通過這個服務(wù)來管理，否則的話改變是不會起到效果的。
2、無法共享屬性的配置。
????? 每個bundle都保存自己獨立的一份屬性配置，這就導(dǎo)致了當(dāng)出現(xiàn)共享屬性時，在管理端也不得不同時去重復(fù)的更新多個bundle。
昨天在調(diào)試產(chǎn)品的時候，又被CM搞的郁悶了一把，由于CM是根據(jù)BundleLocation和service.PID共同來綁定屬性的，也就是說當(dāng)BundleLocation改變了的情況下屬性就無效了，而且也無法被重寫，這對于實際的應(yīng)用而言幾乎是不可接受的，因為模塊部署的路徑、模塊的名稱改變這都是很正常的事，但根據(jù)CM這樣的方式的話，也就意味著模塊部署的路徑、模塊的名稱都是不可改變的。
想想挺惱人的，就開始仔細(xì)的看Equinox的CM實現(xiàn)的代碼，經(jīng)過仔細(xì)的查看后，發(fā)現(xiàn)自己疏忽了一點，冤枉了CM，其實CM也是留了一個口以供上面這樣的情況下的處理的，后來對照了下OSGi R4中CM規(guī)范的描述，確實如此，如果希望配置不要和bundleLocation綁定，那么可以在注冊ManagedService接口實現(xiàn)的服務(wù)時將其server.bundleLocation設(shè)置為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>然后就可以在其他的管理屬性的服務(wù)中調(diào)用ConfigurationAdmin來實現(xiàn)對這個service的屬性的管理：
Configuration configuration=admin.getConfiguration("com.terdon.port", null);
根據(jù)這樣的分析，也就是說我以前所說的第一點的情況是冤枉了CM，現(xiàn)在開始給它平反，:)
摘一下OSGi R4 CM規(guī)范中對于這種情況的描述：
"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之所以這么設(shè)計主要還是從安全性的角度考慮的。
但對于第二點，目前看來確實是如此，屬性無法共享，因為pid必須是唯一的，我已經(jīng)發(fā)了郵件給equinox maillist，看看是不是有人會有辦法，:)