以下は、これを機能させるために私がしなければならなかったことです。
OSGI を初めて使用したので、システム バンドルの systemProperties 値に com.sun.management を追加する必要がありました。私は maven-pax-plugin を使用しているので、次のプロパティを追加する必要がありました。デフォルトで機能しなかった理由は、私が選択した osgi コンテナーの com.sun.* パッケージがデフォルトでシステム バンドルに含まれていない分点でした。
これは、bundle 0 コマンドを使用してシステム バンドルを調べることで明らかでした。バンドル 0 は常にシステム バンドルであり、これは私にとって新しいものでした。
<param>--sp=com.sun.management</param>
このコマンドを追加した後、システム バンドルには com.sun.management が含まれ、私のバンドルは問題なくデプロイされました。
equinox がデフォルトで systemProperties に com.sun パッケージを含まない理由については、こちらを参照してください。(sun.* パッケージを直接呼び出す Java プログラムは、すべての Java 互換プラットフォームで動作することが保証されているわけではありません。実際、そのようなプログラムは、同じプラットフォームの将来のバージョンでも動作することが保証されていません。)
したがって、com.sun を osgi コンテナーに追加するには 2 つのオプションがあります。
ソリューション A': 拡張バンドル
これらはフラグメントとして機能します。それらは独自のバンドルではなく、ホストに接続されています。拡張バンドルは、フレームワークのオプション部分を提供するためにシステム バンドルにのみ添付される特別な種類のフラグメントです。このメカニズムを使用して、必要なパッケージを宣言するだけの空の拡張機能を作成し、ロードをそのホスティング バンドル (この場合はフレームワーク) に任せることができます。2 番目のオプションの方が実装が早かったため、このルートには行きませんでした。
解決策 B: ブート委任
最終的に私が選んだオプションは、ブート委任でした。これにより、ユーザーは、バンドルが適切なインポートを提供しない場合でも、フレームワークの親クラス ローダーによって常にロードされる「暗黙の」パッケージを作成できます。com.sun.management を含むようにシステム パッケージを設定することで達成しました。
問題全体をより詳細に説明している次の優れたリンクを参照してください。