コード内からバンドルのインポートにパッケージを追加するにはどうすればよいですか? リフレクションに依存し、他のパッケージを必要とするライブラリを使用しており、開発するバンドルごとにそれらのパッケージを MANIFEST.MF に手動で追加する必要がないため、必要です。
2 に答える
それはいけません。インポート-パッケージは解決フェーズで評価されます。(フェーズはインストールされています->解決済み->アクティブです)。
バンドルがアクティブなときにコードが実行されるため、Import-Packagesを追加するには遅すぎます。
あなたは2つのことをすることができます:
- インポート-使用するパッケージをパッケージ化します
- Dynamic-ImportPackageプロパティを使用して、実行時に解決を延期できるパッケージを指定します
Filippo のソリューションに加えて、依存関係を逆転させることができます。他のバンドルを呼び出して検査する代わりに、バンドルにそれをさせることができます。もう 1 つの方法は、バンドル トラッカーを使用して、追跡対象のバンドルの ClassLoader を取得することです。このクラスローダーを使用すると、「バンドルとして」機能できるため、Import-Package 句はもう必要ありません。
私が OSGi を使い始めたとき、これは私が思いついた最初の要件の 1 つでした。時間が経つにつれて、ほとんどすべての場合に、よりクリーンで一貫性のあるソリューションがあることに気付きました。この依存関係が本当に必要な場合は、考えてみてください。それを反転または抽象化して一般的なソリューションを作成する方法はありませんか?
何も解決しない場合 (最後の手段として)、必要なインポートを提供して、コア バンドルをホストとして (メモリ内に) フラグメントを作成することもできます。BundleContext は、ストリームからバンドルをロードする方法を提供します。次に、更新された ClassLoader を取得するために、ホスト バンドルで refreshpackages を更新して (PackageAdmin サービス経由で) 呼び出す必要があります (バンドルの再起動を意味します)。ただし、最終的にはすべてのパッケージにアクセスできます。
補足として、インポートステートメントを微調整してから更新することでホストバンドルを操作することはお勧めしません...これにより、バンドルが不確定になり、署名付きバンドルでは機能しません。また、これは OSGi に期待されるすべてに反します (時間の経過とともにバンドルが成長することを想像してみてください... ある時点でインポートも縮小する必要があります!!!)
乾杯、ミルコ