私は現在OSGiアプリケーションで興味深い問題に直面しています。
私は、複数のソース（ファイル、レジストリ、またはネットワーク）からアプリケーションの設定を取得する設定サービスを実装しています。構成サービスは、構成プロパティーの値を取得するまで、ソースから特別な順序で読み取る必要があります。OSGiデザインパターンをお探しですか？
まず、各ソースを別々のバンドルに入れ、それらのスーパーインタフェースを作成して宣言型サービスを提供することを考えました。これは、すべてのOSで利用できないため、レジストリをモジュール化するのにも役立ちます。構成サービスがプロパティーの値を要求されると、ホワイトボード・パターンに従ってすべてのソース・バンドルを照会し、非ヌル値を取得するまで構成を読み取ります。しかし、それはランダムな順序でそれを行います。
コンフィグレーションサービスを提供するバンドルを走査する際に特別な命令をどのように実装するか考えている人はいますか？一般的に
敬具
OSGiには既にサービスランク付けの概念があります。サービスを登録するときは、プロパティ "service.ranking"（org.osgi.framework.Constants.SERVICE_RANKING）の値を指定できます。
BundleContext＃getServiceReferences（）が利用可能なサービス参照を返す順序（少なくとも仕様には何も言及していません）にこのプロパティが何らかの影響を与えるとは思いませんが、あなたの "スーパー"設定サービスによって管理される内部コレクションを注文するための値。
しかし、私にとっては、サービスの実装そのものが相対的な重要性を決定するのは、一般に奇妙な考えです。むしろ2つの部分で問題を分割したいと思います。
第2のインタフェースの集合を作用する構成サービス（例えばenum {file, registry, net}）。私は最初のインターフェイスの実装（ファサード）は、各プロバイダの特性に基づいて順序を実行する（クリスの最初の答えが既に示唆しているように）。
使用すると、オブジェクトの束のための横断の特別な順序が必要な場合、あなたは自分のオブジェクト間の（部分）順番を定義します。 次に、取得したオブジェクトを並べ替えて、そのリストを調べます。
プロパティの値が必要なときは、すべてのソースを見つけてリストでソートし、最後にそれを繰り返します。
だから私は、ソースのサービス宣言に特別なプロパティを指定して、それをソートすることができます。設定ファイル。しかし、私はある種のコンパイル時のチェックが欠けています。開発者がプロパティ値の綴りを間違えた場合、単純な文字列の場合はデバッグが難しくなります。 –
コンパイル時のチェックが必要な場合は、サービスのインタフェースでソートするプロパティを返すメソッドを定義するか、単純に 'Comparable'インタフェースを拡張することができます。 – Kru
私はあなたに同意します。これらの2つの側面を分割することは、道のりです。列挙によるあなたの提案は、私が「特別な財産」について話したときの私のコメントに私が意味していたものとまったく同じです。ありがとうございます - あなたは両方！ :) –
サービスランキングを使用する場合、ServiceReferenceオブジェクトを並べ替えることができます。 OSGi仕様に従って、それらはサービスランキングに基づいて比較されます。 –