現在、さまざまなアプリケーション サーバー (JBoss AS など) に .jar のコレクションとして展開されているアプリケーションとライブラリの大規模なエコシステムがあり、依存関係とライフサイクルを管理するための優れたツール セットを見つけようとしています。各種パッケージ。
私は、パッケージが (少なくとも) 3 つの可能な状態のいずれかにあると考えています: 「アンロード」、「保留中」、および「ロード済み」で、次のように大まかに定義されています。
- Unloaded : パッケージは現在利用できません。
- 保留中: パッケージ自体は利用可能ですが、すべての依存関係は利用できません。そのため、現時点では使用できません。
- Loaded : パッケージは利用可能で、すべての依存関係が満たされています。アプリケーションの場合は実行できます。ライブラリの場合は、別のパッケージで使用する準備ができています。
(さらに、いくつかの状態が存在する場合もあります。たとえば、パッケージを読み込もうとしたが、依存関係が満たされていないこと以外の理由で失敗した場合の「失敗」などです...)
パッケージのライフサイクルでは、いくつかの原因により、パッケージの状態が次の 3 つの間で変化する可能性があります。
- 依存関係のないパッケージが読み込まれ、unloadedからloadedになります。
- パッケージを読み込もうとしましたが、すべての依存関係が満たされているわけではありません。unloadedからpendingになります。
- pending状態のパッケージは、突然すべての依存関係が満たされ (他のパッケージがloaded状態になったため)、自動的にそれ自体のロードを開始します。pendingからloadedへの移行。
- パッケージがアンロードされます。現在アンロードされているパッケージに依存するすべてのロード済みパッケージは、ロード済みから保留中になります。
- パッケージが新しいバージョンに更新されます。すべての依存パッケージは自動的に再読み込みされ、更新されたバージョンにアクセスできます。
依存関係を定義するために OSGi を使用する作業を開始しました。OSGi はビルド システムとうまく連携し、信頼できる依存関係情報を生成します。しかし、2 つの OSGi バンドルA
をに依存するB
JBoss にロードし、次に unload をロードすると、問題なく実行されているように見えます。これを低レベル (フレームワーク イベント) で制御するために使用できるいくつかのフックがあることは理解していますが、これを行うためのより良い方法があるはずだと言って、スパイダーの感覚がうずきます。B
A
A
B
これらの面で OSGi を補完する優れたツール/フレームワーク/呼び名は何でもありますか?