クラスローダーとJ2EEパッケージング戦略を理解する: 第2回「クラスローダーを理解する - シングルトンがシングルトンでなくなる日」

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 上級

夷藤 勇人, ソフトウェア事業, IBM

2005年 04月 20日

J2EE開発プロジェクトにおいて必要不可欠なJ2EEパッケージング戦略とはなにか？すべてのJ2EE開発者が正しいJ2EEパッケージング戦略をとれるように、詳細にその理論・方法を解説していきます。

はじめに

全5回シリーズ「クラスローダーとJ2EEパッケージング戦略を理解する」の第1回となる前回は、Java・クラスローダーの基本となるデリゲーション・モデルについて学びました。第2回となる今回も予告したとおり、クラスローダーそのものが話題です。クラスローダーの設定によって、引き起こされる摩訶不思議な現象に迫っていきます。
今回登場する新しい概念は、「デリゲーション・モード」です。

上に戻る

デリゲーション・モードとは

最初にリスト1をご覧ください。これは、WARクラスローダーそのものを単純に標準出力に表示してみた結果です。該当クラスローダーに関する情報が出力されるように、クラスローダーのtoString()メソッドがオーバーライドされていることがわかります。

                
com.ibm.ws.classloader.CompoundClassLoader@1f7010c3
   Local ClassPath: ...(略)...\installedApps\lemonNode02Cell\
                               luv-app.ear\luv.war\WEB-INF\classes;
                    ...(略)...\installedApps\lemonNode02Cell\
                               luv-app.ear\luv.war;
   Delegation Mode: PARENT_FIRST

出力結果から、該当クラスローダーの「ローカル・クラスパス（Local ClassPath）」を知ることができます。このWARクラスローダーがどこへクラスを探しにいくかがわかります。今回、注目したいのは、出力結果の次の行です。

                
  Delegation Mode: PARENT_FIRST

これがクラスローダーの「デリゲーション・モード（Delegation Mode）」です。この例では、デリゲーション・モードが「PARENT FIRST（親が最初）」に設定されています。

上に戻る

「PARENT FIRST（親が最初）」か？「PARENT LAST（親が最後）」か？

デリゲーション・モードとは何でしょうか？前回を振り返ってみましょう。前回、クラスローダーのデリゲーション・モデルにおいては、「各クラスローダーは自分のローカル・クラスパスを探す前に、最初に親クラスローダーにクラスのロードを依頼する」と説明しました。実はこの挙動は、クラスローダーのデリゲーション・モードがデフォルト値である「PARENT FIRST（親が最初）」の場合です。

前回説明したクラスローダー・ツリーを振り返ってみましょう（図1）。

図1で登場するクラスローダーのうち、アプリケーション・クラスローダーとWARクラスローダーについては、デリゲーション・モードをカスタマイズすることが可能です。デリゲーション・モードの設定は2種類です。「PARENT FIRST（親が最初）」と「PARENT LAST（親が最後）」です。

• 「PARENT FIRST（親が最初）」（デフォルト値）の場合 自クラスローダーのローカル・クラスパスを探す前に、最初に親クラスローダーにデリゲートします。親で見つからなかったときにはじめて、自分のローカル・クラスパスを探しに行きます。
• 「PARENT LAST（親が最後）」の場合 自クラスローダーのローカル・クラスパスを最初に探します。見つからなかったときにはじめて、親クラスローダーにデリゲートします。

デリゲーション・モードの設定によってクラスを探す順番が変わってきます。WARクラスローダーがあるクラスをロードする場合、表1に示す順番で各クラスローダーがクラスを探すことになります。

例えば、デフォルト値である「（A）APP-FIRST、WAR-FIRST」、すなわち、アプリケーション・クラスローダー、WARクラスローダーどちらも「PARENT FIRST」の場合は、探す順番はクラスローダー・ツリーの上から下へ単純に降りてくることになります。

上に戻る

いったい「PARENT LAST（親が最後）」がいつ必要になるっていうのだい？

なぜ「PARENT LAST」にする必要があるのでしょうか？以下に示す、とある日の悲劇を例にとって考えてみましょう。

「PARENT LAST」の存在意義は、まさにこの冗談のような無茶がもたらす悲劇を2度と繰り返さないためです。Aさんがやるべきことは、WARクラスローダーのデリゲーション・モードを「PARENT LAST」に変更することでした。WebSphereそのものに影響を全く与えることなく、自分のWebアプリケーション内に含まれるライブラリーが先に優先されるようになります。これこそが、クラスローダー・ツリーがもたらすメリットです。クラスローダーが複数あることの意味がおわかりでしょうか？

上に戻る

「PARENT LAST」にする必要性だって？いつでもさ。

WebSphere Application Serverが内部でどんなライブラリーを使用していようとも、それに影響されることなく自分の好きなライブラリーの最新バージョンを使用したいという欲求は開発者なら誰もが思うところです。「PARENT LAST」にするのは自然なことです。

実際、サーブレット仕様でもこのことについて触れている箇所があります。以下、サーブレット 2.4 Specification SRV.9.7.2からの引用です。

あくまで"recommended（推奨）"ですから、必須事項ではありません。ですから、WebSphere Application Serverにおいて、アプリケーション・クラスローダー、WARクラスローダーのデフォルト値が「PARENT FIRST」であることは、仕様に違反しているわけではないです。決して褒められたものではありませんが・・・。

この連載での推奨は、当然、表1の（D）、すなわちアプリケーション・クラスローダー、WARクラスローダーともに「PARENT LAST」に設定することです。

ちなみに、他のアプリケーション・サーバー、たとえばWebコンテナーであるTomcatはどうなっているか見てみましょう。「The Apache Jakarta Tomcat 5.5 Servlet/JSP Container Class Loader HOW-TO」からTomcatのクラスローダー・ツリーについて説明した図を以下に引用します（図4）。

Tomcatの場合は、EARが存在せず、Webアプリケーション（WAR）だけですので、若干の違いはあります。それでも、図4において、Tomcatでは「common」「share」配下よりも各「webapp」内のクラス・リソースが優先されると、ドキュメントには明記されています。Webアプリケーションのクラスローダーに関しては、やはり「PARENT LAST」の設定になっているわけです。

上に戻る

シングルトンがシングルトンでなくなる日

このように必要とされる「PARENT LAST」設定ですが、これは通常のJavaのクラスローダーのデリゲーション・モードとは異なる設定です。そのため普段はなかなかお目にかかることのできない不思議な現象を作り出すことができます。リスト2をご覧ください。

                
package com.example;
public class Singleton {
    
    private static Singleton instance = new Singleton();
    private int counter;
    private Singleton() {}
    
    public static Singleton getInstance() {
        return instance;
    }
    
    public void increment(int i) {
        counter += i;
    }
    
    public int getCounter() {
        return counter;
    }

}

一見したところ何の変哲もないおなじみのシングルトン・パターンです。クラスcom.example.Singletonのインスタンスはひとつしか存在しないはずです。はたしてそうでしょうか？ここで、以下のルールを紹介しましょう。

全く同じパッケージ名・同じ名前のクラスでも、違うクラスローダーからロードされたものは、同一クラスとは扱われません。別クラス扱いとなります。

このルールを使用すればシングルトンが唯一のものだという固定観念を破ることは簡単に行えます。サンプルとして以下のようなEARを用意してみましょう。

                
luv-app.ear
    - luv-ejb.jar
       - com.example.Singleton
       - com.example.ejb.InEJB
    - luv.war
        - WEB-INF/
          - classes/
            - com.example.Singleton
            - com.example.web.ClassLoaderTestServlet

 

シングルトン・クラスを、EJBモジュール、Webモジュール、両方に入れておきます。さらに、アプリケーション・クラスローダー、WARクラスローダー、共にデリゲーション・モードを「PARENT LAST」に設定します。クラスローダーの観点で見た場合は、図5のようになります。

この状態でシングルトンのテストをしてみましょう。テストコードはリスト4のようになります。

                
package com.example.web;

import com.example.Singleton;
import com.example.ejb.InEJB;
...
public class ClassLoaderTestServlet extends HttpServlet {

    protected void service(HttpServletRequest req, 
    HttpServletResponse res)
            throws ServletException, IOException {
        testSingleton();
    }

    private void testSingleton() {
        Singleton singleton = Singleton.getInstance();

        System.out.println("1. InWeb - counter: "
                         + singleton.getCounter());
        System.out.println("counter: +1");
        singleton.increment(1);
        System.out.println("2. InWeb - counter: " 
                         + singleton.getCounter());        
        InEJB.testSingleton();
        System.out.println("5. InWeb - counter: " 
                         + singleton.getCounter());
        
    }
}

package com.example.ejb;

import com.example.Singleton
...

public class InEJB {

    public static void testSingleton() {
        Singleton singleton = Singleton.getInstance();

        System.out.println("3. InEJB - counter: " 
                         + singleton.getCounter());
        System.out.println("counter: +10");
        singleton.increment(10);
        System.out.println("4. InEJB - counter: " 
                         + singleton.getCounter());
    }
    
    public static Singleton getSingleton() {
        return Singleton.getInstance();
    }
}

 

テストコードを見てみましょう。Webモジュール内のサーブレットClassLoaderTestServletと、EJBモジュール内のクラスInEJBの中では、どちらも同じシングルトン・クラスcom.example.Singletonを使用しています。シングルトン・インスタンスのcounter値を増加して値がどのように変化したか、そのつど表示しています。
このサーブレッドを実行してみましょう。シングルトンですので、結果はリスト5のようになると予想されます。

                            
1. InWeb - counter: 0
counter: +1
2. InWeb - counter: 1
3. InEJB - counter: 1
counter: +10
4. InEJB - counter: 11
5. InWeb - counter: 11

しかし、実際の出力結果はリスト6のようになります。

                
1. InWeb - counter: 0
counter: +1
2. InWeb - counter: 1
3. InEJB - counter: 0
counter: +10
4. InEJB - counter: 10
5. InWeb - counter: 1

            

実行結果からなにが読み取れるでしょうか？そうです。シングルトンはひとつではありません。Webモジュール内のサーブレット、EJBモジュール内のクラスInEJB、それぞれ違うシングルトンのインスタンスを見ているのです。図6をご覧ください。WARアプリケーション・クラスローダーのデリゲーション・モードを「PARENT LAST」に設定したため、サーブレットがシングルトン・クラスを探しにいくとき、最初に見つかるのは、WARクラスローダー内のシングルトン・クラスです。一方、クラスInEJBからは同じEJBモジュール内のシングルトン・クラスが最初に見つかります。
アプリケーション・クラスローダー、WARクラスローダー、それぞれのクラスローダーが、まったく同じ名前のクラスcom.example.Singletonをそれぞれ別々にロードすることになります。当然、シングルトン・クラスのstatic変数instanceも、それぞれのクラスに存在します。そのため、今回のように、シングルトンのインスタンスが2つ存在する結果となったのです。

「PARENT FIRST」なら、このようなことは起きませんでした（図7）。たとえ、Webアプリケーション内にシングルトン・クラスを入れておいても、サーブレットからはアプリケーション・クラスローダー配下のシングルトン・クラスが先に見つかります。アプリケーション・クラスローダーがロードしたシングルトン・クラスが、両方で使用されることになります。そのため、シングルトンはまさに「JVM全体でシングルトン」の役割を果たすことになります。

ひとつのJVM内で、クラスを識別するキーとなるのは「パッケージ名＋クラス名」ではないのです。「パッケージ名＋クラス名＋ロードしたクラスローダー」が識別のためのキーとなるのです。

上に戻る

まとめ

「クラスローダーとJ2EEパッケージング戦略を理解する」、第2回となる今回はクラスローダーのデリゲーション・モード、「PARENT LAST」の必要性、クラスの同一性に関する話題を扱いました。

次回の「ドッペルゲンガーの恐怖」では、いよいよJ2EEの世界で、EARをどのようにパッケージングすればよいか、具体的なパッケージング戦略について解説していきます。
ライブラリーはどこにおけばよいか、モジュール分割の方針、さらに世にも恐ろしいドッペルゲンガー現象について説明します。「デリゲーション・モードをPARENT LASTにして、WEB-INF/libにライブラリーは何でも気にせず全部放り込んでおけば大丈夫」という考え方がいかに危険であるか、解説していきたいと思います。

最後に余談になりますが、通常は不可能であるクラスローダー境界を超えた動的メソッドコールを、Dynamic Proxyを使用して実現するという「トリッキー」なテクニックがあります。第1回、第2回と解説したクラスローダーに関する基礎知識は、このような不可能を可能にする応用例にも生かすことにもできます。これらのテクニックは、数少ないJavaの醍醐味のうちのひとつです。
アプリケーション・サーバー以外の世界でも、Java開発者にとってクラスローダーに関する知識は、Javaを続けていく限り将来役にたつときが必ずやってくることでしょう。

参考文献

• アプリケーション・サーバー
  
  
• WebSphere Studio
  
  
• developerWorks Japan: WebSphere: WebSphereの日本の技術情報サイトです
  
  
• developerWorks: WebSphere(US) : WebSphereの英語の技術情報サイトです

著者について

		著者である夷藤氏は、現在IBMにおいて、WebSphere Application Serverの技術支援を担当しており、多くのJ2EEプロジェクトにおいてシステムデザインやアプリケーション開発の助言を行っています。また、業界標準パフォーマンス評価団体、 SPECにおけるJ2EEアプリケーション・サーバー評価システム、 SpecJAppServer2002の開発を行っていました。 SPEC （US） SpecJAppServer2002 （US） 専門はJava/J2EEですが、彼の興味はサーバーサイドのみならずクライアントサイド・テクノロジー、Python、Eclipseなどへと多岐に渡っており、雑誌「Eclipseパーフェクトマニュアル」でのテストファースト・プログラミングに関する記事執筆や、Eclipse - RCPやJava/J2EEに関する講演活動などでもおなじみです。 Eclipse - RCP Java/J2EE

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る