ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

バンドル・クラスローディング・フロー

OSGiコンテナーは、インポートされたクラスをいくつかの場所で検索します。それがどこを、どのような順序で検査するかを知ることが重要です。 OSGiバンドルのLiferay DXPのクラスローディングフローは、OSGiコア仕様に従います。これはわかりやすいですが、複雑でもあります。次の図はフローを示しており、この記事ではそのフローについて説明します。

図1：このフローチャートは、バンドル内のクラスローディングを示しています。

以下は、バンドルでのクラスロードのアルゴリズムです。

クラスが java.* パッケージにある場合、読み込みを親クラスローダに委譲します。そうでなければ、続けてください。
クラスがOSGiフレームワークのブートデリゲーションリストにある場合、ロードを親クラスローダーにデリゲートします。そうでなければ、続けてください。
クラスがバンドルがワイヤードエクスポーターからインポートするパッケージのひとつである場合、エクスポートするバンドル側のクラスローダーがそれをロードします。 wired exporter は、以前にパッケージを読み込んだ別のバンドルのクラスローダーです。クラスが見つからない場合は、続けてください。
クラスがバンドルの必須バンドルのいずれかによってインポートされている場合、必須バンドルのクラスローダーがそれをロードします。
クラスがバンドルのクラスパスにある場合 (マニフェストヘッダ Bundle-ClassPath)、バンドルのクラスローダはそれをロードします。そうでなければ、続けてください。
クラスがバンドルのフラグメントクラスパスにある場合、バンドルのクラスローダーはそれをロードします。
クラスが DynamicImport-Package を使って動的にインポートされたパッケージ内にあり、エクスポートするバンドルとワイヤが確立されている場合、エクスポートするバンドルのクラスローダーがそれをロードします。それ以外の場合、クラスは見つかりません。

　これで、Liferay DXP がどのように OSGi バンドル用のクラスを見つけ、ロードするかがわかりました。