問題タブ [declarative-services]

RFC 0172宣言型サービスアノテーション（187ページ）に記載されている提案によると？

私のアプリケーションでは、サービスを単独で使用することはほとんど役に立ちません。サービスを使用できるようにするには、常に何らかの外部構成情報が必要です。

コンポーネントを ConfigurationAdmin と組み合わせることは理にかなっています。これは、作成する構成ごとにコンポーネント インスタンスが作成されるためです。これは私のユースケースにぴったりです。

ここで、別のバンドルのコンポーネントをプログラムで使用したい場合はどうすればよいでしょうか? これは理にかなっていますか？

コンポーネントをサービスとして再度エクスポートし、それを他の Bean から使用できることはわかっていますが、ユーザーが構成を作成できるサーブレットがあり、構成されたインスタンスごとにアクションのリストがあるとします。彼がアクションをクリックしたら、適切なコンポーネントを見つけて、その上でアクションを実行する必要があります。

この機能を OSGi の上に実装する最良の方法は何でしょうか?

OSGi サービスと DS を一緒に使用して正しい軌道に乗っていると思いますが、それを悪用する気がします。それか、純粋に素晴らしいかのどちらかです。（両方ともまだ可能です）。

それでは、次のアプリケーションを想像してみましょう。これは家のデータベースです。House と Window の 2 つのインターフェイスがあります。インスタンス化する構成が必要なコンポーネントとして構成された、利用可能なそれぞれに少なくとも 1 つの実装があるとしましょう。新しいインスタンスを作成するには、この構成を適切な pid に提供するだけです。(これはファクトリ コンポーネントでもサービス ファクトリでもありません。正式名称は何ですか? Neil による優れた投稿があります)。

これまでのところ、これは魅力のように機能します。

家はまさにそれ、家です。独自の住所を持ち、それぞれが異なり、通りのプロパティで簡単に識別できます。ただし、windows インスタンスは家の間で共有できます。それらの構成は基本的に幅と高さです。

現在、これらのコンポーネントは、0..n カーディナリティ構成で相互にバインドすることもできます (窓のない家に住みたくない場合でも)。したがって、各家には窓のリストがあり、窓の種類ごとに、どの家にそれがあるかがわかります (多対多の関係)。

私の問題は、2 つの家が同じ 3 つの窓を共有しているとしましょう。これをどのように説明できますか？プロパティベースのフィルタリングは表現力が足りないように感じます。また、これはフレームワークにオブジェクトをインスタンス化させる正しい方法ではないかもしれないと感じていますが、とても便利です。

考え？悪用していますか、それとも意図したとおりに使用していますか?

(DS を使用して、仕事の半分を完了することもできます。Houses のリストを Window インスタンス参照にバインドするか、またはその逆にバインドすると、コンポーネント インスタンスはターゲット インスタンスで registerWhatever() 関数を呼び出すことができます。 -しかし、少なくともこの半分については、どうにかして説明する必要があります。)

アクティベーターメソッドを使用して、サービスを「古い方法」で宣言するシステムがあります。

現在、Declarative Services を使用して新しいバンドルを作成しています。新しいバンドルで Declarative Services 手法を使用して公開されていないサービスを参照することはできますか?

私はOSGiと宣言型サービス（DS）を使用しており、現在、ロギングを適切に処理する方法を考えています。私はとにかくDSを使用しているので、OSGiサービス大要で指定されたLogServiceを必須のサービス参照として使用するのは自然なことのようです。私はネットのekkesコーナーやnogunnersのブログでたくさん読んでいますが、まだ何かがはっきりしていません。

さまざまなサービスコンポーネント（またはファクタリングされたコンポーネントを使用する場合はさまざまなサービスコンポーネントインスタンス）を適切に区別するにはどうすればよいですか？

Logbackを使用したLogListenerの初心者の実装を見ると、彼はそれらを区別するためにbundlecontextからBundle-Idを使用しています。これまでのところわかりました。しかし、サービスコンポーネントをどのように区別しますか？LogServiceオブジェクトには当然BundleContextへの参照が含まれていますが、（LogServiceインターフェイスを見ると）ServiceReferenceはユーザー（実際に何かをログに記録するユーザー）自身が指定する必要がありますか？これは私には壊れやすいようです。フレームワークがBundleContextを提供するのに、なぜこれを提供できないのですか？

そして、私がそれに取り組んでいる間、なぜOSGi仕様logger.log(LogService.LOG_INFO,...)は準標準logger.info(...), logger.warn(..)などの代わりに冗長を使用するのですか？それには特別な理由がありますか？

私の現在のアプリケーションでは、いくつかの場所でこのパターンに遭遇しました。異なるが関連するジョブを実行する 1 つのバンドルに 2 つのサービス インターフェイスがあります。

両方を実装するシングルトンコンポーネントが必要ですが、それぞれが他方への参照を必要としていることがわかります。

3 つの OSGi コンポーネント モデル (DS、Blueprint、iPOJO) のどれがこれを可能にしますか? 1)Service1ImplとService2Implが同じバンドルにある場合。2）それらが異なるバンドルにあるときは？

aQute.bnd.annotation.componentbndlib-1.50.0のパッケージにある注釈を見ると、http：//www.aqute.biz/Blog/20091020またはhttp://www.aqute.biz/Bnd/Componentsにリストされていない注釈があります。それは何のために使われますか？@Attribute

OSGI を eclipse で使い始めました。Declarative Services の下で、サービスがアクティブ化されると実行されるメソッドが 2 つあることがわかりました。つまり、Activate と Bind です。これら 2 つの違いは何ですか?

サービスの開始時に特定のアクションを実行したい場合、それを Bind メソッドまたは Activate メソッドのどちらに配置しますか?

ある種のAPIを使用して宣言型サービスを追加することは可能ですか？

少し背景：

動的スクリプトに基づくサーバーアプリケーションがあります（スクリプトはいつでも追加、編集、または削除できます）。これらのスクリプトには、OSGiサービスへの依存関係があり、場合によっては相互に依存関係があります。スクリプトが編集されるたびに、スクリプトはjavascriptにコンパイルされ、その依存関係が検出されます。

その時点で、宣言型サービスとして（再）登録したいので、依存関係が出たり消えたりするとアクティブ化/非アクティブ化されます。

• これも可能ですか？それとも私が見逃している主要なものはありますか？
• OSGi標準では不可能な場合、FelixまたはEquinoxに固有のソリューションはありますか？
• iPojoやブループリントなどの他のフレームワークでそれを行うことはできますか？