問題タブ [declarative-services]

さまざまなコンテキストで機能を同じにする必要があるアプリケーションを設計しています。下の写真を参照してみましょう。

4つのバンドルがあります：

• コンテキストマネージャー
• B1
• B2
• B3

Context Managerは、新しいコンテキストがいつ利用可能になるかを認識し、 B1、B2、およびB3の新しいバージョンをインスタンス化することを担当するバンドルです。B2とB3によって提供されるサービスは、コンテキスト間でまったく同じです。サービスにプロパティを追加して、実行中のコンテキストを区別したいだけです（たとえば、ctx1とctxN）。これが私が達成したいことの理論です。宣言型サービスを介して簡単に実装できると思いました。実際、コンポーネントヘッダーでcomponent.factoryプロパティを指定することで、B1 * B2 *とB3をComponentFactoryにしました。セットB1B2が提供するサービスを参照するには、 B3が提供するサービスを参照するようにB2を設定します。これらは私が直面した課題です：

• Context Managerは、 B3によってのみ提供されるComponentFactoryサービスについて初めて学習します。これは、 B1とB2がまだ満たされていない限り、ComponentFactoryサービスをサービスレジストリに登録しません。これが当てはまる限り、B1とB2は最初のコンテキストでインスタンス化されません。
• B1とB2が作成されると、他のコンテキストから任意のサービスを取得します。同じコンテキストからのみサービスを選択するようにreference.targetパラメーターを設定することを考えていましたが、これを宣言的に行う方法はないようです。同じコンテキストからサービスを選択する唯一の方法は、カーディナリティ0..nで参照を設定し、現在のコンテキストに基づいて選択する「バインド」メソッドを提供することです。これは、すべてのコンポーネントが同じ選択ロジックを複製する必要があることを意味します代わりに、newInstanceが呼び出されたときにコンテキストマネージャーによって提供されると考えていました。実際、呼び出し中にComponentFactory.newtInstance（props）;.target =（context = mycontext）のようなプロパティを提供すると、これを実現できますが、コンポーネントが実際に使用しているすべての参照を知りません。

この時点で、私は実際に宣言型サービスの使用を避け、コンテキストごとのバンドルに提供する基本クラスを拡張させることを考えています。これは、基本的にorg.apache.felicy.dependencymanagerと同様の依存関係の追跡を実装しますが、コンテキストごとのコンポーネントは、コードがどのコンテキストにあるかを知る必要はありません。ただし、このソリューションに戻るのは嫌いです。OSGi仕様にすでに存在する可能性のあるロジックを複製しているだけだと感じているので、私の質問は次のとおりです。

OSGiのコンテキストごとに実行できるバンドルを作成するための最良の方法は何ですか？バンドルは、実行されているコンテキストを明示的に言及することなく、依存関係を宣言的な方法で記述できますか？

OSGi Enterpriseリリース5仕様では、osgi.extender名前空間が導入されています。この名前空間により、BlueprintやDeclarative Servicesなどのエクステンダーがフレームワークにインストールされていることを前提とするバンドルが、Require-Capabilityヘッダーを使用してこの依存関係をモデル化できるようになります。

第135.2章osgi.extender名前空間は、特定の各エクステンダーの機能の値を対応する仕様で指定する必要があることを示しています。ブループリントの例を示します。

ただし、第112章の宣言型サービス仕様では、SCR実装が提供する機能は指定されていません。

Peter Kriensは、要件と機能に関するブログ投稿で、SCRの機能がであることを示唆する例を示していますosgi.component。最終的に、この値は仕様で適切に定義されると思います。でもそれまでは使えません。

Require-CapabilityおよびProvide-CapabilityヘッダーはOSGiCoreリリース4.3で導入されたため、このメカニズムはフレームワークの実装ですでに使用可能です。そのため、SCRの実装をOBRリポジトリから解決できるように、バンドルでSCRの要件を表現する必要があります。

空のバンドルを作成し、一方ではカスタム機能を提供し、他方では実装バンドルを必要とする1つのソリューションを想像できます。例えば：

宣言型サービスを含むバンドルは、この機能の要件を表すことができます。例えば：

これは、宣言型サービスを含むバンドルをデプロイするときにSCRが確実に解決されるようにするための良い方法ですか？他に方法はありますか？

この問題の適切な解決策は、機能を提供しない他のレガシーバンドルにも適用できる解決策です。

私の要件： プロジェクトの永続性を処理するサービスがあります。このサービスをPersistenceProviderサービスと呼び、「my.persistenceservice」バンドルに存在すると仮定します。

これで、MyPersistenseConsumerという名前のクラスの1つのbind（）unbind（）メソッドを使用してPersistenceProviderサービスを参照する「my.persitenceconsumer」バンドルという名前の別のバンドルができました。したがって、「my.persistenceconsumer」バンドルが開始すると、bind（）メソッドを使用してPersistenceProviderサービスの参照を取得し、MyPersistenceConsumerはPersistenceProviderサービスを使用できます。

ただし、「my.persitenceconsumer」バンドルのさまざまなクラスのこのPersistenceProviderサービスも使用する必要があります。

私の質問は次のとおりです。 異なるクラス（同じバンドル内）内でそのような共有サービスを使用するための最良の方法は何ですか？

解決策の1つ： 静的getInstance（）メソッドを持つ「my.persitenceconsumer」バンドルにActivatorクラスを追加できます。これはMyPersistenceConsumer.bind（）によって呼び出すことができ、ActivatorとともにPersistenceProviderを格納します。「my.persitenceconsumer」バンドル内のすべてのクラスは、Activatorクラスを使用してPersistenceProviderを使用できます。

コードは次のとおりです。

最後に： 上記は良い方法ですか..またはより良い方法はありますか？

Eclipse4rcpアプリケーションで使用するOSGiバンドルを作成しました。依存関係を追加し、これらのサービスをアクティベーターに登録してクラスに注入すると、サービスの使用法は正常に機能します。

アクティベーターで

私のクラスで

宣言型サービスを介してバンドルを使用する方が良い方法であると読みました。だから私の実装を変更しました。サービスを提供するために、バンドルにコンポーネント定義を作成しました。

次に、アクティベーターからサービス登録を削除し、サービスコンシューマークラスを作成しました。

および別のコンポーネント定義：

これらの変更後、私のサービスの注入は機能しなくなります。問題は、注入されたサービス参照が毎回NULLになることです。

誰かが理由を知っていますか？何か忘れましたか？

どうもありがとう！

OSGi 環境で次の問題に直面しています。com.mybiz.example パッケージをエクスポートするバンドル A があるとします。このパッケージのバージョン 1.0.0 には、Bean クラス MyBean が含まれているため、

バンドル B は、MyBean を使用するインターフェース MyService をエクスポートします。

注: 私たちのアーキテクチャでは、MyBean はインターフェイスではなくクラスである必要があります。

バンドル C は、MyService を宣言型サービスとして次のように使用します。

MyBean クラスでホット フィックスを実行する必要がある場合、問題が発生します。フィールドといくつかのメソッドを追加する必要があるとしましょう。次に、バンドル A、B、C がデプロイされた実行中の OSGi 環境を取得しました。

私の要件は、バンドルを停止できないことです。

したがって、これらの仮説の下で、バンドル A の新しいバージョン、たとえば A_1.1.0.jar をデプロイします。A_1.1.0.jar に含まれる新しいバージョンの MyBean クラスを使用するバンドル C を作成できません。

どうすればいいですか？

どうもありがとうございました！

よろしくお願いします

シゲルシ

Client、Executor、および Methodology の 3 つの異なるコンポーネントを作成しました。

独自の Executor インスタンスを参照する Client インスタンスを複数持つことができます。そこで、Executor を DS ファクトリー コンポーネントにしました。

Executor は、1 つ以上の方法論に従ってクライアント要求を実行できます。そのため、(1..n) Methodology サービスを動的に参照します。

ここまでは順調ですね。私の問題は、クライアントの希望に応じて Executor コンポーネントで使用される方法論を絞り込む必要があることです。

どうすればそれができますか？

Declarative Services を使用して、別のバンドルに機能を提供するサービス バンドルを作成しようとしています。ただし、サービス プロバイダー バンドルが必要になるまで起動しないようにします。私の条件を説明しましょう。

2 つのバンドルがあります。

-com.example.serviceprovider

-com.example.serviceconsumer

Service Provider バンドルは、次のように Declarative Services を使用してサービスを提供します。

サービス コンシューマは、提供されたサービスを次のように参照します。

これらのバンドルの両方が起動時に「アクティブ」である場合、サービス コンシューマは、サービス プロバイダによって宣言されたサービスとの通信に問題はありません。この問題は、サービス プロバイダーを怠惰な方法で起動しようとすると発生します。

Service Provider が遅延読み込みに設定されると、OSGi コンソールに次のように表示されます。

私が期待するのは、バンドル 16 が「解決済み」であるにもかかわらず、少なくとも登録されているのはサービスであるということです。しかし、「バンドル」コマンドを呼び出すと、「登録されたサービスはありません」と表示されます。

たぶん、遅延ロードされたバンドルとサービス登録の基本的な概念を見逃していたのでしょう。バンドルが「解決済み」状態にある場合、すべての「ワイヤ」を接続する必要はありませんか? (つまり、クラスローダがあり、インポートとエクスポートの依存関係が解決され、サービスが登録されています。) サービス コンシューマがサービスにアクセスしようとすると、そのバンドルは "ACTIVE" 状態に移行するべきではありませんか? ここで欠けているのは何ですか？

OSGi Declarative Services を使用していて、policy = dynamic で多数の参照を持つサービスがあると仮定します...

A - 必須単項。

B - 必須単項。

C - 必須倍数。

D - オプションの単項。

E - オプションの倍数。

私のサービスが開始されると、すべての参照が利用可能になります。バインドが呼び出される順序を制御する方法はありますか?

B を最初にバインドし、入ってくる E ごとに何かをしたいのですが、B が E の前にバインドされていることを保証する方法がありません。

はい、より論理的なアプローチは、B を表すサービスを E にもバインドさせ、必要なことは何でも実行させることですが、B を変更することはできず、使用することしかできません。B と E にバインドするだけの新しいサービスを作成しても、同じ問題が発生します。

すべてがバインドされているときに activate メソッドで必要なことは何でも実行でき、追加の (動的) E がバインドされているときにそれを実行できますが、別の方法があるかどうか疑問に思っていました...