付録 B   実行時の注意事項


この付録には次のトピックがあります。

• 実行時環境

• クラスローダの階層

• ダイナミック再読み込み

実行時環境

---

コンポーネントをスタンドアロンモジュールとして登録するか、アプリケーションとして登録するかによって、ファイルシステムおよびレジストリの状態が変わります。図 B-1 は、スタンドアロンモジュールの実行時環境です。図 B-2 は、アプリケーションの実行時環境です。

標準モジュールの実行時環境

次の図は、モジュールベースで展開した場合の実行時環境です。ファイルシステムエントリの場合、モジュールは次のように抽出されます。

install_dir/ias/APPS/modules/module_name/extracted_class

レジストリエントリは、次のキーの下に追加されます。

SOFTWARE¥iPlanet¥Application Server¥6.5¥J2EE-Module¥module_name

---

ヒント	すべての標準モジュールは、同じディレクトリの同じ LDAP を持つ場所に抽出されます。このため、モジュールの名前は重複しないようにしてください。

---

図 B-1    スタンドアロンモジュールの実行時環境

アプリケーションの実行時環境

次の図は、アプリケーションベースで展開した場合の実行時環境です。ファイルシステムエントリの場合、アプリケーションは次のように抽出されます。

install_dir/ias/APPS/app_name/module_name/extracted_class

レジストリエントリの場合、アプリケーション内のモジュールは次のキーの下に追加されます。

SOFTWARE¥iPlanet¥Application Server¥6.5¥J2EE-Module¥module_name

図 B-2    アプリケーションの実行時環境

クラスローダの階層

---

Java 仮想マシン (JVM) のクラスローダは、依存関係の解決に必要な Java クラスファイルを動的に読み込みます。たとえば、java.util.Enumeration のインスタンスを作成する場合は、クラスローダの 1 つが関連するクラスを実行時環境に読み込みます。iPlanet Application Server 実行時環境のクラスローダは、図 B-3 に示す階層に構成されています。

図 B-3    クラスローダの実行時階層

実行時にクラスおよびリソースを読み込むために、委譲方式が使用されています。この委譲方式では、クラスローダの各インスタンスが親のクラスローダと関連付けられます。親のクラスローダは、システムクラスローダであっても、別のカスタムクラスローダであってもかまいません。

クラスローダのインスタンスがクラスまたはリソースを検索するために呼び出されると、自らがクラスまたはリソースを検出しようとする前に、クラスやリソースの検索を親のクラスローダに委譲します。親クラスローダがクラスを読み込めない場合、カスタムクラスローダで、findClass() と呼ばれるメソッドが呼び出されます。

つまり、カスタムクラスローダは、親が読み込めないクラスだけを読み込みます。このようなクラスは、指定されたファイルシステムやネットワークなど、新しいタイプのクラスリポジトリに存在する可能性があります。クラスローダが参照するクラスリポジトリは、それぞれ異なります。クラスローダおよびクラスローダが参照するファイルについては、表 B-1で説明します。

---

注

iPlanet Application Server 内でバージョン指定が有効な場合、WebClassLoader/EjbClassLoader によって J2EE のコンポーネントクラス (Servlet/JSP および EJB 実装クラス) が読み込まれます。一方、その他のすべてのクラス （ヘルパークラス) は ApplicationClassLoader によって読み込まれます。 同じパッケージ内に入っていた 2 つのクラスが別々のクラスローダで読み込まれ、しかも実行時のパッケージが異なる場合、それらは別のパッケージのクラスであると JVM にみなされます。 したがって、servlet/JSP/EJB 実装クラスからのヘルパークラスにある protected メソッドにアクセスすると、IllegalAccerssError がスローされます。 ダイナミックなクラス読み込みを利用したい場合は、protected メソッドを public にしてください。

---

表 B-1    iPlanet Application Server のクラスローダ 

クラスローダ	説明
ブートストラップクラスローダ	ブートストラップクラスローダは、rt.jar の実行時クラスおよび i18n.jar の国際化クラスを参照する ブートストラップクラスローダは、拡張クラスローダおよびシステムクラスローダの親ローダである
拡張クラスローダ	インストール済み拡張クラスローダは、JRE の lib/ext ディレクトリにある JAR ファイルのクラスを参照する
システムクラスローダ	システムクラスパスクラスローダは、システムプロパティ java.class.path に指定されたパスにある JAR ファイルのクラスを参照する。システムクラスローダがクラスを読み込むには、関連するディレクトリをクラスパスに指定する必要がある。つまり、iasenv.ksh (UNIX の場合)、実行時環境 (UNIX または NT の場合)、または ¥Software¥iPlanet¥Application Server¥6.5¥Java¥Classpath レジストリエントリ (NT の場合) を指定しなければならない
モジュールクラスローダ	iPlanet Application Server モジュールクラスローダは、install_dir/ias/APPS/modules/* の下にあるすべてのディレクトリにあるクラスを参照する。すべてのモジュールがこのクラスローダを共有する モジュールクラスローダは、アプリケーションクラスローダの別のインスタンスである
アプリケーションクラスローダ	登録済み J2EE アプリケーションは、それぞれ対応するクラスローダによって読み込まれる。アプリケーションクラスローダは、install_dir/ias/APPS/app_name とそのすべてのサブディレクトリの下にあるクラスを参照する このクラスローダは、アプリケーション内の Web/Ejb クラスローダの親である。同様に、すべての登録済みスタンドアロンモジュールのクラスを読み込むためのモジュールクラスローダがある。モジュールクラスローダはアプリケーションクラスローダの別のインスタンスにほかならなく、すべてのスタンドアロンモジュールにおいて 1 つのアプリケーションに関して同じ階層構造を持つ 実際、すべてのスタンドアロンモジュールはデフォルトアプリケーションの一部とみなされる
Web クラスローダ	J2EE アプリケーション内の各 Web モジュール (WAR) には、1 つの Web クラスローダが割り当てられる。Web モジュール内のすべての Web コンポーネント、つまり Servlet クラスと JSP クラス (直接または間接的に javax.servlet.Servlet インタフェースを実装している) は、Web クラスローダによって読み込まれる。スタンドアロンの Web モジュールの場合は、Web クラスローダが作成され、モジュールクラスローダがその親である 注 Web コンポーネントクラスは、ダイナミックな再読み込みが有効な場合にだけ、Web クラスローダに読み込まれる。ダイナミックな再読み込みが無効な場合、アプリケーション内のすべてのクラスがアプリケーションクラスローダ (スタンドアロンの Web モジュールに対してはモジュールクラスローダ) で読み込まれる
Ejb クラスローダ	J2EE アプリケーション内の各 Ejb モジュール (JAR) には、1 つの Ejb クラスローダが割り当てられる。Ejb モジュール内のすべての EJB コンポーネント (EJB 実装クラス) は、このクラスローダによって読み込まれる。このクラスローダには、アプリケーションクラスローダという共通の親クラスローダがある スタンドアロンの Ejb モジュールの場合は、Ejb クラスローダが作成され、モジュールクラスローダがその親である 注 Ejb コンポーネントクラスは、ダイナミックな再読み込みが有効な場合にだけ、Ejb クラスローダに読み込まれる。ダイナミックな再読み込みが無効な場合、アプリケーション内のすべてのクラスがアプリケーションクラスローダ (スタンドアロンの EJB モジュールに対してはモジュールクラスローダ) で読み込まれる

クラスローダ階層ごとの制限事項と対応策について説明します。

• すべての独立モジュール用の iPlanet Application Server モジュールクラスローダと iPlanet Application Server アプリケーションクラスローダとの間で、対話は行われません。このため、J2EE アプリケーションから J2EE スタンドアロンモジュールクラスを読み込んだり、J2EE モジュールから J2EE アプリケーションを読みこむことはできません。この問題に対応するには、たとえば、関連するパスをシステムクラスパス内の必要なクラスに指定してください。パスを指定したクラスが、システムクラスローダによって読み込まれます。次の例を参照してください。

  http://developer.iplanet.com/appserver/samples/pkging/docs/sampleC.html

  ただし、システムクラスパス内にクラスへの相対パスを含めると、Application Server の制御下に配置されたすべてのアプリケーションに対してクラスが公開されるため、アプリケーションのセキュリティ要件を危険にさらすことになります。また、システムクラスパス内のクラスはシステムクラスローダによって読み込まれるため、再読み込みできなくなります。

• J2EE の仕様ではアプリケーションが別のアプリケーション内のコンポーネントにアクセスできなければなりませんが、iPlanet Application Server の各 J2EE アプリケーションはそれぞれのクラスローダによって読み込まれるため、アプリケーションとして登録された 2 つの EAR ファイルは、相手ファイルのクラスを読み込めません。つまり、2 つのアプリケーションのクラスは個別に読み込まれるため、複数のアプリケーションから名前が似ている 2 つのクラスを読み込んでも、クラスローダ内で互いに上書きされることがありません。

• 1 つの iPlanet Application Server アプリケーションクラスローダだけが、すべての J2EE のスタンドアロンモジュールを読み込むために割り当てられます。これにより、2 つのスタンドアロンモジュール間で対話することができます。このとき、スタンドアロンモジュール内のクラスの名前が重複していてはなりません。たとえば、ejb1.jar が com.samples.company.DBConnector を読み込もうとし、war1.war が com.samples.company.DBConnector を読み込もうとすると、一方が他方を上書きします。

  
  

  ---

  ヒント	すべてのスタンドアロンモジュールの読み込みに使用されるクラスローダは 1 つだけなので、あるスタンドアロンモジュールのクラスに対して、他のすべてのスタンドアロンモジュールからアクセスできるようにすると、セキュリティ上の潜在的な危険性が高くなります。このため、スタンドアロンモジュールは、すべてのユーザがアクセスできる再利用可能なコンポーネントだけで構成するようにしてください。

  ---

  
  

  
  

  ---

  注	Servlet、JSP、または EJB がアクセスするファイルなどのリソースは、クラスローダのクラスパスが指定するディレクトリにある必要があります。たとえば、Web クラスローダのクラスパスには次のようなディレクトリがあります。 module_name/WEB-INF/classes module_name/WEB-INF/compiled_jsp module_name/WEB-INF/lib Servlet がリソースにアクセスする場合、これらのディレクトリにリソースがないと読み込まれません。

  ---

  
  

ダイナミック再読み込み

---

Servlet、JSP、および EJB 実装クラスは、サーバの動作中にダイナミックに再読み込みされます。このため、モジュール、アプリケーションコード、および記述子を変更しても、サーバを再起動する必要がありません。この機能は、変更したコードをすぐにテストできるため、開発環境で役に立ちます。

ダイナミック再読み込みは、運用環境にはお勧めしません。パフォーマンスが低下することがあります。また、再読み込みを行うと、送信時のセッションが無効になります。クライアントはセッションを再起動する必要があります。

ダイナミック再読み込みが無効になっている場合、モジュールクラスローダ 1 つとアプリケーションクラスローダ 1 つだけが読み込まれます。

ダイナミック再読み込みの有効化

すべてのクラスに対するダイナミック再読み込みは、次の方法でオンまたはオフにできます。

• Administration Tool の使用

• レジストリの変更

Administration Tool の使用

1. Administration Tool の左側のペインで、アプリケーションサーバのインスタンスを選択します。

2. 「ダイナミッククラスの再読み込みを有効にする」チェックボックスをクリックします。

3. 「適用」をクリックします。

   ダイナミックなクラスの再読み込みを有効にするために、Administration Tool によってレジストリ内で適切な変更が行われます。

レジストリの変更

SYSTEM_JAVA¥Versioning¥Disable

デフォルトでは 1 に設定されており、ダイナミック再読み込みが無効であることを示しています。0 の値は、ダイナミック再読み込みを有効にします。

レジストリは、kregedit ツールを使って編集できます。詳細については、『管理者ガイド』を参照してください。

Servlet および JSP のダイナミック再読み込み

ダイナミック再読み込みを有効にすると、Servlet および JSP 用のサーバに組み込まれます。iPlanet Application Server の動作中に行った変更は、その Servlet および JSP に次回のリクエストが着信したときに有効になります。

EJB のダイナミック再読み込み

ダイナミック再読み込みを有効にすると、EJB のサーバに組み込まれます。iPlanet Application Server の動作中に行った変更は、その EJB に次回の作成リクエストが着信したときに有効になります。

ただし、EJB のインタフェースとヘルパークラスの再読み込みは動的に行われないので、それらを変更した場合は、サーバを再起動する必要があります。

EJB がセッション時に変更されると、EJB コンテナによりセッションに関連した EJB インスタンスのステートが直列化され、インスタンスプールを作成し直した後に直列化が解除されます。

ダイナミック再読み込みの制限

J2EE コンポーネント (Servlet または Ejb 実装クラス) がほかのクラスから直接参照されている場合、参照されている J2EE コンポーネントが属するモジュールのダイナミック再読み込みは機能しません。たとえば、ヘルパークラスから Servlet や EJB 実装クラスの新しいインスタンスを作成する場合です。これは、J2EE ではお勧めしません。

ある J2EE コンポーネントがヘルパークラスのパッケージアクセス番号にアクセスしている場合 (番号が保護されていても、J2EE コンポーネントとヘルパークラスが同じパッケージ内にあるとこの状況が発生)、しかもダイナミック再読み込みが有効になっている場合は、IleegalAccesError が発生します。このような状況では、ダイナミック再読み込みを無効にする必要があります。

---

注	iPlanet Application Server 6.0 SPx を 6.5 に移行した場合は、EJB のスタブを再度生成する必要があります。生成しない場合、EJB 実装クラスのダイナミック再読み込みは機能しません。

---