3

プロジェクトのプラグインを管理する手段としてOSGIを使用することに興味があります。つまり、私のインターフェースには多くの実装者が存在する可能性があり、それぞれが独自の/個別のOSGIバンドルに表示され、実装クラスがエクスポートされます...

4

2 に答える 2

1

これは宣言的に (VonC のように) 詳細に行うことも、標準サービス レジストリを介して実行時に動的に行うこともできます。

実装者は実装をサービスとして簡単に登録でき、消費者はレジストリから実装を取得できます。これは非常に基本的な OSGi の機能です。サービスはプロパティに登録することもできるため、コンシューマーはこれらのプロパティを使用して、サービスを検索するときに実装を区別できます。

于 2009-04-23T13:14:07.770 に答える
1

宣言型サービスが進むべき道です。

インターフェイスをサービスとして宣言できます 

<service>
    <provide interface="my.Interface"/>
    <property name="foo" value="bar"
</service>

そのインターフェースの各実装では、バンドルのアクティブ化と非アクティブ化のメソッドを定義できます。
しかし、本当に優れているのはその性質です。最新の SCR (新しく改良された OSGi R4.2 DS - Declarative Service - 仕様を実装する「エクステンダー バンドル」である「サービス コンポーネント ランタイム」) を使用している場合、クラスはOSGI モデルからは何もインポートしません。それらは純粋な POJO のままです。

次に、最初のサービスに依存する別のサービスを定義します。

<reference name="myInterfaceServiceName"
    interface="my.Interface"
    bind="myActivationMethod" unbind="myDeactivationMethod"
    cardinality="0..n"/>

そのサービスは、最初のサービスのすべての具体的なインスタンスを検出して一覧表示し、意図したとおりに処理します。

詳細については、Eclipse Extensions and Declarative Servicesの質問を参照してください。

プレゼンテーション: EclipseCON2009 のDeclarative Services、Spring Dynamic Modules、および Apache iPOJO を使用した OSGi でのコンポーネント指向開発は、具体的な例を提供します。

于 2009-04-23T04:39:06.277 に答える