我目前在我的OSGi應用程序中面臨一個有趣的問題。
我正在實現一個配置服務，應該從多個來源（文件，註冊表或網絡）檢索應用程序的配置。配置服務應該以特殊順序從源文件讀取，直到他獲得了配置屬性的值。尋找OSGi設計模式
首先，我想將每個源放在一個單獨的包中，爲它們創建一個超級接口並讓它們提供一個聲明式服務。這也有助於模塊化所需的註冊表，因爲它在每個操作系統上都不可用。當配置服務被詢問屬性的值時，它會根據白板模式查詢所有源束並讀取配置，直到獲得非空值。但它是以隨機順序進行的。
有沒有人有一個想法如何實現穿越提供配置服務的捆綁特殊訂單？
問候
OSGi已經有了服務排名的概念。註冊服務時，可以爲屬性「service.ranking」（org.osgi.framework.Constants.SERVICE_RANKING）提供值。
我不認爲這個屬性對BundleContext＃getServiceReferences（）返回可用的服務引用的順序沒有任何影響（至少該規範沒有提到它），但是你仍然可以使用屬性值來訂購由您的「超級」配置服務管理的內部集合。
但是，對我來說，讓服務實現本身確定其相對重要性通常是一個奇怪的想法。我寧願將問題分成兩部分。
第二接口的集合將包括一些特徵概念的一個配置服務（例如一個enum {file, registry, net}）。然後，我會實現第一個接口（外觀）根據每個提供者的特性執行排序（正如克里斯已經提出的第一個答案）。
一般來說，如果你需要遍歷了一堆對象的特別命令，你只需定義對象之間的（部分）訂單。 然後，你排序你得到的對象，並通過該列表。
因此，對於你的問題，當需要一個屬性的值時，你會發現所有的源，你將它們排序在一個列表中，最後遍歷它。
好的。因此，我可以在源的服務聲明中指定一個特殊屬性，並根據例如一個配置文件。但是我錯過了某種編譯時檢查。如果開發人員錯誤地描述了屬性值，那麼在簡單字符串的情況下，將很難調試。 –
如果你想編譯時檢查，你可以定義一個方法，返回你在服務的接口中排序的屬性，或者簡單地擴展「Comparable」接口。 – Kru
我同意你的意見。將這兩方面分開是一條路。當我談論「特殊財產」時，你對枚舉的建議正是我對克里斯的評論意思。謝謝 - 你們倆！ :) –
請注意，如果使用服務排名，則可以對ServiceReference對象進行排序。根據OSGi規範，這些是根據服務排名進行比較的。 –