APサーバを問わずJavaアプリケーションを動かすには？：Java Review（1/2 ページ）

Webシステムでは複数のベンダーのアプリケーションサーバを利用していたり、Webシステム更改の際アプリケーションサーバを変更したりする場合がある。このような場合に動くはずのアプリケーションが動かなくなったという経験はないだろうか。今回は、Webアプリケーションサーバを変更した時にJavaの業務アプリケーションで留意すべき点について説明する。

[友成文隆（日立製作所），ITmedia]

Webアプリケーションサーバごとの違いを考慮する

　Javaの業務アプリケーションを異なるWebアプリケーションサーバで動かす場合には「バージョンの違い」、「Webアプリケーションサーバごとの違い」を意識しておく必要がある。前者の「バージョンの違い」では、WebアプリケーションサーバでサポートしているJava EEやJava SEのバージョンに違いが無いかを意識する。バージョンが違う場合には、業務アプリケーションへの影響範囲を調べ、必要に応じて業務アプリケーションを変更する。

　加えて、後者の「Webアプリケーションサーバごとの違い」についても注意が必要だ。Java EEの標準仕様で定められた機能と設定は、Java EEに準拠するすべてのWebアプリケーションサーバで共通だ。しかし、それでもWebアプリケーションサーバごとに違いは存在する。例えば、標準仕様に関するベンダー間の解釈の違いや、Java EE仕様のオプショナル機能のサポートの有無、あるいはベンダー独自の拡張機能が存在するなどといった具合だ。このような違いが存在するときに、Webアプリケーションサーバを移行すると、既存の業務アプリケーションが動作しないことがある。

　今回はWebアプリケーションサーバごとの違いの代表的な例として、EARファイル構成の違い、クラスローダの違い、仕様解釈の差異による文法エラーの発生について説明する。

EARファイル構成の違い

　まず、EARファイル構成の違いについて説明する。Java EEアプリケーションのEARファイル構成は、Java EE仕様で規定されている。Java EE標準のEARファイル構成を示す。

Java EE標準のEARファイル構成

　しかし、すべてのWebアプリケーションサーバで必ずしも図のようなEARファイルの構成をとっているとは限らない。例えば、EARファイル直下の階層に、classファイルやPropertiesファイルを格納するディレクトリを任意に作成できるWebアプリケーションサーバもある。移行先と移行元のWebアプリケーションサーバで対応しているEARファイルの構成が異なると、移行後にJava EE業務アプリケーションが動作しないことがある。移行先のWebアプリケーションサーバでサポートしているEARファイルの構成を確認しておこう。

　また、EARやWARファイルなどに含める設定ファイルの内容についても注意したい。Webアプリケーションサーバによってはエラー検出の条件が緩い場合があり、設定ファイルの一部のタグが指定されていないときでもエラーが検出されないことがある。しかし、ほかのWebアプリケーションサーバではエラーとして検出されることもあるため、設定ファイルの内容については確認が必要だ。なお、設定ファイルの代わりにアノテーションを利用している場合は、アノテーションの指定内容についても確認しておこう。

クラスローダの違い

　Java EEの業務アプリケーションを作成・動作する上で、Webアプリケーションサーバのクラスローダ構成についても忘れずに抑えておきたい。クラスローダ構成は各ベンダーに依存しているため、Webアプリケーションサーバごとに違いがある。クラスローダの違いが、Java EE業務アプリケーションの動作に影響を及ぼす恐れがある。

　例えば、日立のCosminexusの場合、新規インストールした直後のデフォルトのクラスローダ構成は次のようになっている。

デフォルトのクラスローダ構成

　各クラスローダの説明は省略するが、Cosminexusの場合、サーバのクラスをロードするシステムクラスローダを頂点に、コネクタクラスローダ、JavaBeansクラスローダ、アプリケーションクラスローダなどがある。図の矢印のとおり、クラスローダ間には親子関係がある。例えば、システムクラスローダはコネクタクラスローダの親のクラスローダになる。

　このように、クラスローダ間に親子関係があると、以下の規則に従って、クラスローダは動作する。

1. クラスローダでは、委譲モデルを使ってクラスやリソースを検索する。クラスローダが呼び出されると、自分でクラスやリソースを検索を試みる前に、まずはそのクラスローダの親のクラスローダにクラスやリソースの検索を委譲する。
2. 子のクラスローダでロードされたクラスは、親のクラスローダからは見えない仕様になっている（参照できない）

　これらの親子関係の条件を抑えていないと、問題が発生する。ここでは、EJB-JARとWAR内に「Class A」という名称のクラスが存在し、WARのClass AからClass Xを検索しようとしている場合に発生する問題について説明する。

事象

　WARのClass AからClass Xを参照しようとした場合にクラスが見つからない。

原因

　WARに含まれるClass AがEJB-JARにも含まれていることが原因である。クラスのロード時には、親のクラスローダが優先されるため、Class Aのロード時にはWebアプリケーションクラスローダからではなく、アプリケーションクラスローダからロードされる。アプリケーションクラスローダでロードされたClass Aからは、子であるWebアプリケーションクラスローダでロードされたClass Xを参照できないためエラーが発生した。

対処方法

　EJB-JAR内のClass Aが不要である場合は、EJB-JARからClass Aを削除する。

---

　このように、Java EE業務アプリケーションでは、クラスローダ構成も押さえておくことが大切だ。特にWebアプリケーションサーバごとでクラスローダ構成に差異があるときには、これまで動作していた業務アプリケーションが動かなくなるという事象が起こる可能性もあるため、移行時にはクラスローダ構成についても意識する必要がある。