4

Eclipseアーキテクチャの拡張機能/サービスへのアプローチについて少し混乱しています。開発者が利用できるオプションは2つあります。

  1. Eclipseプラグイン拡張機能の使用-http ://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
  2. 宣言型サービスの使用-http://www.eclipse.org/equinox/bundles/

どちらを使用する場合、それぞれのアプローチの長所と短所は何ですか？また、どちらが好ましいアプローチですか？

4

2 に答える 2

4

EclipseZone: A Comparison of Eclipse Extensions and OSGi Services にはかなり良い比較があります (2007 年以降だと思います) 。

ターゲット プラットフォームの規則に従います。したがって、たとえば、Eclipse 3.4 用のプラグインを作成している場合は、Eclipse 3.4 プラグインを作成します (依存関係にMANIFEST.MFを使用し、拡張機能/拡張ポイントにplugin.xmlを使用します。リンク先の記事は Eclipse 2 用です)。 。バツ）。pluginsディレクトリの内容を調べて、これを確認できます。

于 2009-03-27T11:46:30.800 に答える
2

「現在の」アプローチ（eclipse3.4などのpre3.5M5）の問題は、Eclipseプラグイン拡張機能とOSGI DS（宣言型サービス）の両方で、プラグインに拡張機能固有またはOSGI固有のAPIが存在する必要があることです。

このPowerpointプレゼンテーションで宣言型サービスのこの優れた紹介を確認することをお勧めします： EclipseCON2009
の宣言型サービス、Spring Dynamic Modules、およびApacheiPOJOを使用したOSGiでのコンポーネント指向開発。

ここに味があります：

モジュールレイヤーを使用すると、静的な依存関係を最小限に抑えることができます。静的な依存関係が少ないということは、コンポーネントが機能するために存在しなければならないものが少ないことを意味します。
サービスを使用すると、コンポーネントを他のコンポーネントと相互作用させることができます。

コンポーネントは、OSGiサービスと一緒に接着されたPOJO（Plain Old Java Objects）として実装する必要があります。

宣言型サービス（DS）は、OSGi Compendiumのセクション112の仕様です
。これは、リリース4.0で導入され、エクステンダーモデルに基づいています。

すべてのエクステンダーと同様に、DSは他のバンドルに代わってタスクを実行します。DS仕様はこのエクステンダーを定義し、フレームワークによって実装されます。
エクステンダーバンドル自体は、サービスコンポーネントランタイムまたはSCRと呼ばれます。

DSとSCRという用語は混同されることがあります
。DSは仕様であり、SCRは仕様を実装する実際のバンドルです。

OSGiR4.2のDSには大幅な改善があります。
これらの変更の多くは、Equinox3.5M5+でサポートされています。

SCR（新しく改良されたOSGi R4.2 DS-宣言型サービス-仕様を実装する「エクステンダーバンドル」である「サービスコンポーネントランタイム」）は次のようになります。

  • コンポーネントを作成します。
  • それらをサービスと構成にバインドします
  • バインドされたサービスの出入りに応じて、コンポーネントのライフサイクルを管理します。
  • オプションで、コンポーネントをサービス自体として公開します

あなたはまだMANIFEST.MFを持っています：

Bundle-SymbolicName : mybundle
Bundle-Version : 1.0.0
Service-Component : OSGI-INF/minimal. xml

使用します：

org.eclipse.equinox.ds <version>.jar
org.eclipse.equinox.util <version>.jar

SCRは、アクティブ化/非アクティブ化メソッドを自動的に検出します。
XML宣言に属性を追加することで、それらを別の名前で呼び出すことができます。

R4.2より前では、メソッド名は変更できず、DSAPIComponentContextからタイプのパラメーターを取得する必要がありました。これにより、コンポーネントの可能性が失われました。

したがって、 " BundleActivator"（コンポーネント内のOSGI固有のAPI：BAD）を記述する代わりに、プレーンPOJOオブジェクトを記述します。

public class PollingComponent {
    private static final int DEFAULT_PERIOD = 2000;
    private PollingThread thread ;
    protected void activate ( Map<String , Object> config ) {
        System.out.println( " Polling Component Activated " );
        Integer period = (Integer)config.get( " period " );
        thread = new PollingThread(
            period!=null ? period : DEFAULT_PERIOD);
        thread.start();
    }
    protected void deactivate() {
        System.out.println( " Polling Component Deactivated " );
        thread.interrupt();
    }
}

他のサービスへの参照を宣言するだけです。

<reference name="LOG"
    interface="org.osgi.service.log.LogService "
    bind="setLog" unbind="unsetLog"
    cardinality="0..1"/>

また、コンポーネントをサービス自体として公開できます。
これは<service>、XML記述子の要素を使用して行われます。

<service>
    <provide interface="net ... ContactRepository"/>
    <property name="foo" value="bar"
</service>

<provide>要素を追加するだけで、複数のサービスを提供できます。
要素を使用してサービスプロパティを指定します<property>。これらのプロパティは、アクティブ化時にコンポーネントに渡され、サービスレジストリに公開されます

于 2009-03-27T12:43:34.813 に答える