6

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

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

Provide-Capability: osgi.extender;
  osgi.extender="osgi.blueprint";
  uses:="org.osgi.service.blueprint.container,org.osgi.service.blueprint.reflect"
  version:Version="1.0"

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

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

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

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

Provide-Capability: com.example.extender; extender=scr
Require-Bundle: org.apache.felix.scr; bundle-version=1.6.0

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

Require-Capability: com.example.extender; filter:="(extender=scr)"

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

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

4

1 に答える 1

4

仕様はosgi.extender名前空間を定義していますが、実装が適切なエクステンダー機能を提供することを義務付けるために、さまざまなエクステンダー仕様（Blueprint、DS）を更新する必要があります。今のところ、おそらくそうではありません。

したがって、今のところ、DSバンドルがDS実装バンドルを解決する（またはインストールする）ことを「要求」する方法があります。

OSGiは、BlueprintとDSの次の更新のために進行中の作業を行っており、これらの更新によりosgi.extender機能が義務付けられます。

于 2012-10-24T21:40:25.077 に答える