2

OSGI 環境で動作するアプリケーションを作成しています。今、いくつかのコードを抽出し、別のバンドル/jar ファイルに入れて、他のアプリケーション (OSGI または非 OSGI の両方) でも再利用したいと考えています。

私の目標は、OSGI 環境クラスへの依存関係を取り除くことです。これは、さまざまな OSGI フレームワーク (Equinox など) のすべての jar を持たない他のアプリでも実行する必要があるためです。しかし同時に、アプリケーションがOSGIアプリである場合、OSGI環境にOSGIサービスを登録したいと思います。

私はすでにコードを分離しており、OSGI に依存するコードの唯一の残りの部分は、現在、いくつかのクラスを OSGI サービスとして登録する Activator クラスです。

context.registerService(MyServiceInterface.class.getName(), new MyServiceImpl(), new Hashtable());

依存関係を削除するには、次のことを考えます。

  • bundle1 から Activator と OSGI の依存関係を削除します
  • Activator を移動する別の bundle2 を作成します

最後に、OSGI 対応にするための Manifest.mf ファイルのみを持つ bundle1.jar がありますが、OSGI フレームワーク クラスに依存するコードはもうありません。bundle1.jar をインポートする現在のアプリケーションにのみ属する別のバンドルがあり、アクティベーターを使用して OSGI コンテナーに MyService.class を登録することのみを目的としています。

  1. このアプローチは問題ありませんか、それとも他にベスト プラクティスはありますか?
  2. OSGI環境でサービスを登録することは良い習慣ですか、それともこれは常にホストアプリケーションが責任を負うべきものですか?
4

4 に答える 4

2

Activator クラスをバンドルに残しておいてはいかがでしょうか。OSGi 以外の環境で実行すると、アクティベーター クラスは呼び出されません。OSGi 環境で実行すると、そうなります。OSGi の依存関係をアクティベーターに分離することは、優れた戦略です。

于 2012-10-07T13:53:29.247 に答える
1

Spring-DM を使用すると、OSGi へのコード依存を取り除くのに役立ちます。バンドルはアクティベーターを必要とせず、サービスは spring-dm config xml からエクスポートできます。ただし、これにより実行時の依存関係が大幅に追加されますが、コンパイルの依存関係は必要ありません。

于 2012-10-11T05:11:30.627 に答える
1

ほとんどの場合、Activator なしでサービスを公開できます。OSGI Community WikiとEquinox の例を見てください。

于 2012-10-07T13:23:24.390 に答える
1

別のアプローチは、ブループリントを使用することです。少なくとも単純なケースでは、OSGi にまったく依存しないようにすることができます。実際のケースでは、通常、少なくともいくつかの OSGi API が必要ですが、OSGi 以外のケースではそれらを単に非アクティブのままにしても問題ありません。

PojoSRも試してみてください。これにより、OSGi の外部でアクティベーターと OSGi サービスを使用できるようになります。OSGi コードをテストするために、Apache Camel でこれを使い始めました。

于 2012-10-08T08:00:25.590 に答える