インターフェイス名を使用してJavaアプリケーションにjarファイルを追加する

Question

私は実行時に中央データベースからツールを動的に読み込むことができるメディアアプリケーションを開発しています。これらは主に、オーディオとビデオを操作するための信号処理モジュールである必要があります。私はカスタムクラスローダーの実装について読んできましたが、classLoaderを使用するにはクラスの名前を知っている必要があります。これは私にとっては正しいとは思わない。私は、アプリケーションがデプロイされた後にこれらのモジュールをビルドできるようにしたいと思います。

私はインターフェイスを実装する抽象クラスを拡張するためのモジュールを必要とすることを考えていました：

public abstract class AbstractModule implements myInterface{ 
    //.... 
} 

私はまだこれらのモジュールの著者はサブクラスに名前を付けるなるかを知るのいずれかの方法がありません..

私はosgiバンドルについて少し読んでいますが、それは有望そうです...しかし私は明らかに私のアーキテクチャ全体を再設計したくありません...私のアプリケーションのこの部分にOsgiバンドルを使用することは可能でしょうか？私の気持ちは、Osgiバンドルが自分のコンテナを動かす必要があると思われるからです。

とにかく、私のアプリケーションに動的にモジュールをロードさせるには、最高の、最もハッキリで、最も安定した方法は何ですか？モジュールは（抽象クラ​​スを拡張するなどの）何らかの標準化を必要とします。

おかげ

Answer 1

これはOSGIにとってとても使いやすいです。だから私は疑問だと思う - これはデスクトップアプリケーションかサーバーベースですか？デスクトップ上でOSGIを使用することは可能ですが、このルートを使用する場合は、コンテナの選択肢が異なります。

---

EDIT

は、デスクトップアプリケーションでは、あなたは最高のFelixまたはEclipse Equinoxを使用することによって提供されるだろう。両方ともスタンドアロンのリッチクライアントに非常にうまく組み込むことができます。サーバーアプリケーションでは、JBoss 7を十分に推奨できません。 OSGIモジュールのファースト・クラス・サポートを備えた高速Java EE 6サーバーを手に入れることができます。私はあなたのアーキテクチャーの正確な設定についてはまだ分かりませんが、豊富なクライアントとJava EEサーバーの両方に言及しています。もう少し詳しく説明できますか？

Answer 2

あなたはクラスパスをスキャンし、クラスによってクラスを確認する必要があります。
これは非常に迷惑なことです。
Reflectionsをチェックすれば、多すぎる仕事をしなくても、すべてのサブタイプを手に入れることができます。

Answer 3

私は@Perceptionに同意します。これについてはOSGiを考慮する必要があります。車輪を再発明する意味がありません。しかし、他に選択肢がない場合：

各モジュールが実装する必要があるスタンダード化されたインターフェイスを作成します。

public interface ModuleInterface { 
    public String greet(String name); 
} 

モジュールの実装は次のようになります。

public class MyModule implements ModuleInterface { 

    @Override 
    public String greet(String name) { 
     return "Hi "+name+"!"; 
    } 

} 

あなたは、モジュールを作成するために、（それが密閉されていない）ジャーにこれらのクラスをパッケージ化することができます。あなたのアプリケーション（一般的なModuleInterfaceクラスを含む）は、次にモジュールをロードすることができます。

URL classUrl = new URL("file:///modules/server/ModuleJar.jar"); 
URL[] classUrls = {classUrl}; 
URLClassLoader ucl = new URLClassLoader(classUrls); 
Class<?> clazz = ucl.loadClass("com.example.MyModule"); 
ModuleInterface firstModule = (ModuleInterface)clazz.newInstance(); 
System.out.println(firstModule.greet("John Doe")); 

Answer 4

これは、OSGiの素晴らしい使用例です。言及されていない1つの部分はOSGiサービスです。サービスはサービス・レジストリーに登録され、インターフェース名で検索されます。同じインターフェースを実装する複数のサービスがある場合は、すべてのサービスを含むリストを戻すことができます。

サービスをプログラムで登録してアクセスすることはできますが、宣言型サービスまたは設計図を使用して宣言的に行うことができます。どちらもOSGiサービスのための単純な依存性注入を提供します。青写真は春のdmに基づいているので、慣れていればかなりよく見えるはずです。 Glassfishを使用している場合は、OSGiサービスを注入するためのシステムが異なると考えているので、これを使用するか、青写真の実装をコンテナにインストールすることができます。

Glassfish、JBoss、Geronimo、およびWebSphere Application Serverを含む多くのアプリケーションサーバーでは、サーブレットやJPAなどのJava EEパターンを使用しながら、OSGiコンテナでアプリケーションを実行できます。 （グーグルにしたいのであれば、Glassfishはこのハイブリッドアプリケーションを呼び出してアイデアを提供し、他の人はエンタープライズOSGiと呼んでいます）。これにより、大規模な再構築なしにOSGiソリューションをすばらしいクリーンな実装に移行できます。

- アクションで

エンタープライズOSGiの：http://www.manning.com/cummins

Answer 5

私はもちろん、他の回答に反対していません。

さらに、懸念事項の1つは、OSGiコンテナを持つ必要があるようです。これは事実です：オープンソースOSGiフレームワーク実装の例として、Felix（APLv2）、Equinox（EPL）、Knopflerfish（BSD）があります。ただし、これらは非常に軽量で組み込み可能です。実際には、約5〜10行のコードを埋め込むことができます。私はblog postを書いたことがあります。

言い換えれば、アプリケーション全体をOSGiに変換する必要はありません（モジュール性や保守性などの他の理由で行うこともできます）。これらのプラグ可能なツールのロードに純粋に使用される小さなOSGiコンテナをアプリケーション内に作成できます。

いくつかの他の雑多なポイント：

• ホリーは、OSGiサービスを使用して言及し、私は強く同意するものとします。ツールバンドルは、アプリケーションがリッスンするサービスを公開する必要があります。
• ツールバンドルのデータベースではなく、OBRなどのリポジトリテクノロジを使用することをお勧めします。これにより、ツールとライブラリ間の依存関係をリゾルバで管理できるため、開発者がツールをプラットフォームに簡単に追加できます。必要に応じて、OBRリポジトリの物理ストレージをRDBMSにすることができます。