ニュース
» 2009年12月18日 08時00分 UPDATE

Java Review:APサーバを問わずJavaアプリケーションを動かすには? (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ファイル構成 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を参照できないためエラーが発生した。

Java3.jpg

対処方法

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


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

       1|2 次のページへ

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -