構成プロパティーを受け取るためのサービスのコーディング

構成プロパティーは、アクティベーション・メソッドで指定される org.osgi.service.component.ComponentContext オブジェクトを通じて使用することができます。

始める前に

サービスとパーシスト ID との関連付け』に説明されているタスクを実行する必要があります。

このタスクについて

アクティブ化が起こった後にプロパティーが更新 された場合、注入に使用されるメソッドは、サービスが OSGi Declarative Services (DS) 宣言 に指定するコンテキストによって異なります。

一般的に、サービス宣言で modified 属性を使用することによって、 更新されたプロパティーの注入のために特に使用されるメソッドを宣言するのが最適です。 modified メソッドが使用可能でないと、 DS はサービスを非アクティブ化して、新しいプロパティーで再度アクティブ化します。

サービスを非アクティブ化して再度アクティブ化すると、 従属するサービスがリサイクルされることもあるため、特に必要でない限りこういった 操作は避けてください。modified 属性を使用するのが、構成更新を受け取るための好ましい方法です。

前の『サービスとパーシスト ID との関連付け』のタスクで、DS に対してサービスを定義しています。 以下は、そのタスクで説明した DS 宣言からの activate メソッドと modified メソッドの例です。
private static Dictionary<String, Object> _props = null;

    protected void activate(ComponentContext cc) {
        _props = cc.getProperties();
    }

    protected void modified(Map<?, ?> newProperties) {
        if (newProperties instanceof Dictionary) {
            _props = (Dictionary<String, Object>) newProperties;
        } else {
            _props = new Hashtable(newProperties);
        }
    }
構成プロパティーから値を取得する際には、以下のメカニズムを使用して、ある程度の柔軟性を持たせます。
  • ユーザー構成のマイグレーションが必須ではないようにするために、同じバンドル内に含まれるデフォルト・プロパティーを少なくとも要求するが、 ユーザー・オーバーライドを考慮に入れるようにメソッドをコーディングします。
  • 冗長なプロパティーや認識されないプロパティーは無視します。
デフォルト構成のみでサービスが動作可能である必要があります。 妥当なレベルの機能を提供するために、ユーザー・オーバーライドが必須であってはなりません。

トピックのタイプを示すアイコン タスク・トピック

ファイル名: twlp_setup_service_getprops.html