2005年12月14日（水）
日本アイ・ビー・エム株式会社 ソフトウェア事業部夷藤勇人
全5回シリーズ「クラスローダーとJ2EEパッケージング戦略を理解する」、第3回となる前回は、クラスローダーがもたらすドッペルゲンガー現象について学びました。
今回は、ロギング・フレームワークとして有名なJakartaプロジェクトのcommons-logging を例として取り上げます。commons-loggingを使用したWebアプリケーションのパッケージング例です。
luv-war
- WEB-INF/classes
- com/example/MyHello
- ...
- WEB-INF/lib
- commons-logging.jar
commons-loggingの使用例です。
...
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class MyHello {
static final Log log = LogFactory.getLog(MyHello.class);
void hello() {
log.info("Hello");
}
...
}
commons-loggingは他のロギング・ライブラリーへのラッパーとして動作します。commons-loggingと組み合わせるものとしては、
Apacheプロジェクトのロギング・ライブラリー・Log4j
J2SE1.4から導入された標準のjava.util.loggingパッケージ
などが一般的です。今回の例では明示的に何を使用するかを指定していません。この場合は、通常、java.util.loggingパッケージが自動的に使用されます。
org.apache.commons.logging.Log;
org.apache.commons.logging.LogFactory;
のみを使用しますが、実際にはjava.util.loggingパッケージを利用する実装が選択され、ロギングそのものはjava.util.loggingパッケージングが最終的に行います。
一見、何の問題もないようですが、WebSphere Application Server V6（またはV5）上でリスト1のWebアプリケーションを動作させると、エラーが発生してしまいます（リスト3）。
...
Caused by: org.apache.commons.logging.LogConfigurationException:
The chosen LogFactory implementation does not extend LogFactory.
Please check your configuration.
(Caused by java.lang.ClassCastException: com.ibm.ws.commons.logging.TrLogFactory)
...
エラーメッセージからは
1.
LogFactoryの実装として「com.ibm.ws.commons.logging.TrLogLogFactory」が選択された
2.
選択されたTrLogFactoryはLogFactoryのサブクラスではない
getClass().getClassLoader.getResource("commons-logging.properties")
結果
jar:file:/.....<WAS_HOME>/lib/ws-commons-logging.jar!
/commons-logging.properties
commons-logging.propertiesファイルは、WebSphereのインストールディレクトリー（[WAS_HOME]）の下、libフォルダ内のJarファイルws-commons-logging.jarの中に含まれていることがわかります。
org.apache.commons.logging.LogFactory=com.ibm.ws.commons.logging.TrLogFactory
commons-loggingのログファクトリーの実装として、TrLogFactoryが選択されたのは、このためです。WebSphereでは「TrLogFactory」をcommons-loggingのロギング実装として使用するように強制的に指定されているのです。
1.
LogFactoryの実装として「com.ibm.ws.commons.logging.TrLogLogFactory」が選択された
2.
選択されたTrLogFactoryはLogFactoryのサブクラスではない
（A）
（WebSphere EXTクラスローダーがロードした）org.apache.commons.logging.LogFactory
（B）
（WARクラスローダーがロードした）org.apache.commons.logging.LogFactory
このように上位クラスローダー配下に「何か」があっただけで、アプリケーションが影響を受けて動かなくなるのでは困ります。アプリケーションの上位クラスローダーに何がおいてあるか・その環境はアプリケーション・サーバーによって大きく異なりますし、同じアプリケーション・サーバーであってもバージョンによって異なります。不完全な他のアプリケーションを動作させるために、アプリケーション・サーバー管理者が「好ましくない」ライブラリーを、全アプリケーションから見える位置においていることもありえます。
今回、例としてとりあげたcommons-loggingの場合は、対策は容易です。最も簡単な方法は、アプリケーション内にcommons-logging.propertiesを用意しておくことです。
luv.war
- WEB-INF/classes
- commons-logging.properties
- log4j.xml
- WEB-INF/lib
- commons-logging.jar
- log4j.jar
commons-logging.propertiesには、以下のように明示的にLog4jによる実装を指定しておきます
org.apache.commons.logging.LogFactory=
org.apache.commons.logging.impl.Log4jFactory
（※実際は一行）
org.apache.commons.logging.LogFactory=
org.apache.commons.logging.impl.Jdk14Logger
（※実際は一行）
WAR単体ではなく、EAR全体でひとつのcommons-loggingを使用する場合はこのようになります。
luv-app.ear
- commons-logging.jar
- log4j.jar
- utility.jar
- commons-logging.properties
- log4j.xml
- ejb1.jar
- luv1.war
- luv2.war
クラスローダーの観点から見た場合は以下のようになります。
今日のオープンソースを最大限に活用するアプリケーション開発においては、「WEB-INF/libにおいてあるjarファイルがいつの間にか30個を超えていた」というのも決して珍しい状況ではありません。オープンソースライブラリーは、アプリケーションだけが使用するものではなく、アプリケーション・サーバー側でも活用しているケースが非常に多いです。
著者である夷藤氏は、現在IBMにおいて、WebSphere Application Serverの技術支援を担当しており、多くのJ2EEプロジェクトにおいてシステムデザインやアプリケーション開発の助言を行っています。また、業界標準パフォーマンス評価団体、SPEC におけるJ2EEアプリケーション・サーバー評価システム、SpecJAppServer2002 の開発を行っていました。Eclipse - RCP やJava/J2EE に関する講演活動などでもおなじみです。
