Developerサイトに移行します。見た目やトピックエリアなど更新されますが、開発者に必要とされるコンテンツを引き続き提供していきます。LAST」にする必要性だって?いつでもさ。クラスローダーとJ2EEパッケージング戦略を理解する/developerworks/jp/websphere/library/java/j2ee_classloader/このシリーズの続きに乞うご期待。このコンテンツはシリーズの一部分です:クラスローダーとJ2EEパッケージング戦略を理解するこのシリーズの続きに乞うご期待。はじめに全5回シリーズ「クラスローダーとJ2EEパッケージング戦略を理解する」の第1回となる前回は、Java・クラスローダーの基本となるデリゲーション・モデルについて学びました。第2回となる今回も予告したとおり、クラスローダーそのものが話題です。クラスローダーの設定によって、引き起こされる摩訶不思議な現象に迫っていきます。今回登場する新しい概念は、「デリゲーション・モード」です。デリゲーション・モードとは最初にリスト1をご覧ください。これは、WARクラスローダーそのものを単純に標準出力に表示してみた結果です。該当クラスローダーに関する情報が出力されるように、クラスローダーのtoString()メソッドがオーバーライドされていることがわかります。ClassPath)」を知ることができます。このWARクラスローダーがどこへクラスを探しにいくかがわかります。今回、注目したいのは、出力結果の次の行です。FIRST(親が最初)」に設定されています。LAST(親が最後)」か?デリゲーション・モードとは何でしょうか?前回を振り返ってみましょう。前回、クラスローダーのデリゲーション・モデルにおいては、「各クラスローダーは自分のローカル・クラスパスを探す前に、最初に親クラスローダーにクラスのロードを依頼する」と説明しました。FIRST(親が最初)」の場合です。前回説明したクラスローダー・ツリーを振り返ってみましょう(図1)。図1:クラスローダー・ツリークリックして大きなイメージを見る図1で登場するクラスローダーのうち、アプリケーション・クラスローダーとWARクラスローダーについては、デリゲーション・モードをカスタマイズすることが可能です。デリゲーション・モードの設定は2種類です。LAST(親が最後)」です。自クラスローダーのローカル・クラスパスを探す前に、最初に親クラスローダーにデリゲートします。親で見つからなかったときにはじめて、自分のローカル・クラスパスを探しに行きます。自クラスローダーのローカル・クラスパスを最初に探します。見つからなかったときにはじめて、親クラスローダーにデリゲートします。デリゲーション・モードの設定によってクラスを探す順番が変わってきます。WARクラスローダーがあるクラスをロードする場合、表1に示す順番で各クラスローダーがクラスを探すことになります。FIRST」の場合は、探す順番はクラスローダー・ツリーの上から下へ単純に降りてくることになります。mode)と表記されています(図2、3)。この連載シリーズでは、直接意味が伝わりやすいように、クラスローダー・モードというより、デリゲーション・モードという言葉を使用します。LAST」にする必要があるのでしょうか?以下に示す、とある日の悲劇を例にとって考えてみましょう。ABC-1.2.jarを使用しているのですけど、どうもおかしな挙動なのです。「ちゃんとWEB-INF/libにおいてる?」Aさん:「おいています。クラスは確かに見つかっているんです。・・・(30分後)Aさん:「調査してみました。WebSphereのインストールしたディレクトリー(WAS_HOME)下のlibディレクトリー内に同じライブラリーABCの古いバージョンABC-1.1.jarが置いてありました。自分のアプリケーション内に置いておいたWEB-INF/lib/ABC-1.2.jarではなくそちらが先に使用されているようです。1.2はWebSphereでは使用できないってこと?」Aさん:「名案があります。WAS_HOME/lib/ABC-1.1.jarをABC-1.2.jarで置き換えちゃいましょう。