レベル: 初級 Mike Casile, WebSphere Serviceability Architect, IBM
Russell Wright, WebSphere Serviceability Development, IBM
2008年 12月 10日 
Jakarta Commons Logging (JCL)を、IBM® WebSphere® Application Serverにデプロイされたアプリケーションで使用される様々なロギング実装のラッパーとして使用する方法を学びます。
IBM WebSphere Developer Technical Journalより.
サポート通信の各コラムでは、IBM テクニカル・サポートによって提供される WebSphere 製品群向けのリソース、ツール、その他の要素について説明するのに加え、IBM サポートのエクスペリエンスをさらに高めることができる手法や新しい考え方について説明します。
はじめに
いつものように、WebSphereコミュニティーにおいて重要ないくつかの新しいアイテムを紹介します（訳中：これらの最新ニュースは原文が公開された時点のものです）。
- WebSphereソフトウェアやサービス指向アーキテクチャー（SOA）を使用する他ユーザーと協力したいですか？その場合にはWebSphereグローバル・ユーザー・グループ・コミュニティー (US)に参加することをご検討ください。このコミュニティーに参加すると世界中の28000人以上のWebSphereユーザーと協力することができたり、ローカルのユーザー・グループに参加できたり、またIBMプレス・ブックやIBMイベント、研修などを割安で手に入れることができ、さらにIBMにフィードバックすることも出来ます。
- IBM Support Assistant (US)から提供されている以下の診断ツールも進化し、新機能も追加されましたのでぜひ試してください。
- HTTPプロトコルについてより詳しく知りたい場合には以下の新しいWebSphere Technical Exchange webcastでHTTPプロトコルのリクエストやレスポンス・ヘッダー、共通のステータス・コードについて詳しく書かれていますのでそちらを参照してください。
- WebSphere Application Server V7 for z/OSを使用している場合には、診断情報を素早く集めるためにもMVSコンソールから新しいMODIFYコマンドを実行してください。 特にMODIFYコマンド（制御領域ジョブ名）、JAVACOREコマンド、HEAPDUMPコマンドはJavacore TXTファイルやHeapdump PHDファイルをそれぞれHFS/ZFSに提供することが出来ます。Javacore ファイルはJVMのスナップ・ショットであり、実行には数秒しかかかりません。また、サイズも小さく（約2MB）、ヘルス・チェック、ハングやパフォーマンス問題のときに便利です。 Heapdumpファイルはより大きいJVMのJavaメモリーの概略であり、サイズもより大きく、メモリー・リークの解析に有用です。
- WebSphere PortalとWeb Content Managementを使用している場合には以下の重要な新情報をご覧ください：
- IBM BPM製品V6.2の有用性について：
- WebSphere Process ServerもしくはWebSphere Enterprise Bus Serviceを使用している場合にはV6.2に移行させる必要があります。詳細は次のリンク先を参照してください。
- 移行させる際には、問題を防ぐために以下の記事も読む必要がある場合があります。
引き続きこのコラム同様に関係する様々なサポートWebサイトをチェックし、他ツールの新情報を入手してください。
それでは、このコラムの本題に入ります。
Jakarta Commons Logging (JCL)とは
サポート通信の2008年2月版「developer’s
guide to WebSphere Application Server logging（翻訳版は「開発者のためのWebSphere Application Serverロギング・ガイド」）ではWebSphere Application Serverのアプリケーションにおけるロギングやトレースへのイントロダクションや使用可能なさまざまなAPIをサマリーしました。
この記事ではWebSphere Application Serverにデプロイされたアプリケーションで使用される異なるロギング実装を、共通のロギング実装機能にまとめるラッパーとしてのJakarta Commons Logging (JCL)の使用方法について紹介します。
JCLはラッパーとしてのAPIを提供することを目的としたApacheプロジェクトです。他のロギングAPIとは異なり、JCLはランタイムのロギング呼び出しを、その環境に対して適切なロギング実装に委譲します。例えばWebSphere Application ServerではJCLからのイベントがWebSphere Application Serverのログやトレース機能に渡されます。他の環境ではJCLからの出力をLog4Jに渡すことは珍しくありません。ここでのキーポイントはJCLが標準に基づくAPIではなく、むしろJCLはどこにトレースが出力されるかということを開発者が気にする必要がないフレームワークである、ということなのです。JCLは標準APIを先行しています。
JCLはどのようなロギング機能がランタイムに存在しているか、コードが最終的に実行されるのはどのランタイムか、などを一切考慮する必要なく、コードにロギング呼び出しを実装出来ることが強さの鍵となっています。
JCLはWebSphere Application Serverに統合されて、パッケージされています。アプリケーションがアプリケーション自身でもつJCL JARのコピーをバンドルしており、またIBMから提供されているデフォルトの宛先以外にロギング出力させたい場合には、アプリケーション・サーバー・ランタイムに含まれているJCLのバージョンとのクラス・ロードの衝突を避けるために十分な考慮が必要になります。この記事ではクラス・ロードの衝突を避けるためのアプリケーションの構成の仕方について説明します。
いつJCLを使うべきか？
全てのJ2SE 1.4もしくはそれ以降のJVMにおいて、java.util.logging (JUL)が共通に利用できるので、ポータブルなロギング・ラッパーとしてのJCLの必要性は小さくなりました。
従って、新規のアプリケーション・コードにおいては、必ずしもJCLを使うべきではありません。
しかし、あなたのアプリケーションは既にJCLを使用しているかもしれませんし、もしくはJCLを使用しているベンダーのソフトウェアや他のスタック製品を使用しているかもしれません。
こうした場合には、新しいアプリケーションの推奨ロギング方法に従うためだけに、何千行ものコードを書き換え、問題を誘発するのは、一般的には好ましいことではありません。
もし使用しているアプリケーションがWebSphere Application Serverで提供されているもの（V1.0.3）とは異なるバージョンのJCLを使用している場合には、環境を構成する際にこの記事の情報を使用することが出来ます。
JCL環境の構成
JCL環境の構成手順は使用しているWebSphere Application ServerとJCLのバージョンによって異なります。
JCL V1.0.3
新しいバージョンのアプリケーションでは，最新のバージョンのJCLを使用します。もし，アプリケーションがJCL 1.0.3を使用しているソフトウェアを含んでいるなら，二つのシンプルな方法で構成することができます。
- JCLをWebSphere Application Serverのデフォルトロギング機能にルーティングする
JCLロギングをJDKロギングを使用してWebSphere Application Serverログにルーティングしてかまわない場合には、特にアクションは必要ありません。ランタイム、JCLをJDKロガーを通じてルーティングを行い、WebSphere Application Serverのログに出力させるためのライブラリーを提供しています。これはデフォルトの動作です。
- JCLをLog4J にルーティングする
JCL 1.0.3によるロギングを、Log4Jを使用して処理したい場合にはシンプルな構成が必要になります。
アプリケーションのWEB-INF/libディレクトリーにLog4J JARとJCL 1.0.3 JARを含んでいる場合には、META-INF/servicesディレクトリーにorg.apache.commons.logging.LogFactoryという名前のファイルを作成してください。このファイルにはテキストで以下の1行を記入してください：
org.apache.commons.logging.impl.Log4jFactory
JCL V1.1 もしくはそれ以上のバージョン
アプリケーションでより新しいバージョンのJCLを使用する必要がある場合、アプリケーション内のWEB-INF/libディレクトリーにライブラリーを用意し、構成を変更する必要があります。以下のオプションはLog4Jを使用している場合（最も一般的なケース）を想定していますが、それ以外の場合にも同様に当てはめることが出来ます。
これらのサンプルで使用するJARはJCL 1.1.1を参照していますが、1.1やそれ以上のバージョンのものも使用できます。
- 「親は最後」クラス・ロード (*)
シンプルな方法はアプリケーションやモジュールで「親は最後」クラス・ローダー順序を使用することです。適切なバージョンのJCLとLog4Jをアプリケーション内のWEB-INF/libディレクトリーに用意し、以下の手順に沿ってアプリケーションに「親は最後」クラス・ローダー順序を構成してください。
(*) 管理コンソール上は「最初にローカル・クラス・ローダーをロードしたクラス（親は最後）」と表示されます。（訳者注）
- WebSphere Application Serverの管理コンソールを開き、「アプリケーション」＞「エンタープライズ・アプリケーション」＞「application_name」＞「モジュールの管理」＞「module_name」と進みます。
- クラス・ローダー順序を「最初にローカル・クラス・ローダーをロードしたクラス（親は最後）」に設定します。（図1）
図1. アプリケーションへの「親は最後」クラス・ロードの設定
このステップにより、アプリケーションの構成やJARファイルがWebSphere Application Serverで提供されるものよりも優先して使用されます。
- 共有ライブラリーとサーバーを有効範囲とするクラス・ローダー
JCL 1.1もしくはそれ以上のバージョンのものを使用するためにWebSphere Application Server V6もしくはそれ以上のアプリケーションを構成するには、サーバーに関連付けられた共有ライブラリーと共有ライブラリーのみに関連付けられたクラス・ローダーを作成し、「親は最後」のクラス・ローダー・ポリシーを使用する必要があります。
- 単一ディレクトリーへのロギング・プロパティーとJARファイルの移動
commons-logging-1.1.1.jar、log4j JARファイルとcommons-logging.propertiesファイルのみを他のファイルは入れずに単一ディレクトリーに移動させます。これらのJARファイルはオープン・ソースのソフトウェアとして使用でき、サンプルの構成は以下で説明されています。図2はこれらの三つのファイルのみを含むディレクトリーのWindowsエクスプローラ画面です。
図2. 単一ディレクトリー内の二つのJARファイルと一つのプロパティ・ファイル
このシナリオではcommons-logging.propertiesファイルは以下のようになります：
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
priorityはJCL 1.1の新しいパラメータであり、デフォルトは0です。クラスパスの中で最もpriorityが高いプロパティー・ファイルが使用されます。
- 共用ライブラリーの作成
WebSphere Application Server管理コンソールから共用ライブラリーを作成するには、「環境」＞「共用ライブラリー」を選択します。この画面で有効範囲にサーバーを選択し、「新規作成」を選択します。（図3）共用ライブラリーはサーバー、ノードもしくはセルに定義づけることが出来ます。共用ライブラリーの有効範囲をセルに設定した場合には、ノード・レベルでの設定はセル・レベルの設定によってオーバー・ライドされます。
図3. 共用ライブラリーの作成
共用ライブラリーの新規作成画面（図4）：
- 名前を入力します。（例：jcl111）このステップは後のステップで関係してきます。
- （オプション）説明を入力します。
- クラスパスには前のステップで作成した二つのJARファイルと一つのプロパティ・ファイルを含むディレクトリーを指定します。
- ネイティブ・ライブラリー・パスは空欄のままにし、「OK」を選択します。
図4はWebSphere Application Server V6.1の画面です。上記ステップが完了しましたら構成を保管します。
図4. 共用ライブラリーの構成
- サーバーを有効範囲とするクラス・ローダーの作成
- 管理コンソールから「サーバー」＞「アプリケーション･サーバー」を選択し、該当のアプリケーションを含むサーバーを選択します。（図5）
図5. クラス・ローダーの作成（ステップa）
- サーバーの構成が表示されましたら、「Javaおよびプロセス管理」から「クラス・ローダー」を選択します。（図6）
図6. クラス・ローダーの作成（ステップb）
- 次の画面で「新規作成」を選択します。構成タブの一般プロパティーで「最初にアプリケーション・クラス・ローダーをロードしたクラス」を選択し、「OK」を押します。
図7. クラス・ローダーの作成（ステップc）
- 作成したクラス･ローダーを選択します。（図8）
図8. クラス・ローダーの作成（ステップd）
- クラス･ローダーを選択すると、図9のような画面が表示されます。「共用ライブラリー参照」を選択します。
図9. クラス・ローダーの作成（ステップe）
- ステップ2（図4）で作成した共用ライブラリーを選択します。
- 分離された共用ライブラリー（WebSphere Application Server V7もしくはそれ以上のバージョンのみ）
WebSphere Application Server V7では分離された共用ライブラリーという新しい機能が加わることで、JCLの構成が容易になりました。WebSphere Application Server V7では共用ライブラリーを作成する画面下に分離された共用ライブラリーを選択するチェック・ボックスがあります。（図10）
図10. WebSphere Application Server V7の分離された共用ライブラリー
このオプションを選択した場合にはクラス・ローダーを新しく作成する必要がありません。分離された共用ライブラリーは管理コンソールから次のステップを実行することでアプリケーションやモジュールに関連付けられた共用ライブラリーとして追加されます：
「アプリケーション」＞「アプリケーション・タイプ」＞「WebSphereエンタープライズ・アプリケーション」＞「application_name」を選択します。その画面の「参照」セクションから「共用ライブラリー参照」を選択すると、図11のような画面が表示されます。アプリケーションを選択し、「参照共用ライブラリー」をクリックします。
図11. 共用ライブラリー参照
図12では使用可能な共用ライブラリーが表示されています。追加したい共用ライブラリーを選択し、右矢印を選択して「OK」をクリックし、保管します。この手順をアプリケーションやモジュール毎に行います。
図12. 共用ライブラリー参照の追加と削除
 |
概略
Jakarta Commons Logging 1.0.3があなたの要望に応えられている場合には、そのままデフォルトの実装（JDK14ロガー）もしくはLog4Jを使用するのがシンプルな方法です。またアプリケーションが「親は最後」クラス･ロードを使用している場合には、そのまま使用しているバージョンのJCLを使用するのがシンプルな方法です。
もし上記のどちらにも当てはまらない場合には、JCLとLog4Jとプロパティー・ファイルを含んだ共用ライブラリーを作成し、有効範囲をサーバーとするクラス･ローダーを作成して共用ライブラリーに関連付けるのが最も良い方法です。WebSphere Application Server V7では分離された共用ライブラリーの導入によって、この手順を非常に簡単になっています。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | | | Mike CasileはWebSphereのサービサビリティー・アーキテクトであり、チーム・リーダーです。彼のチームはReliability、Serviceability、Class Loader Viewer、First Failure Data Capture、RAS Diagnostic Providersとその他のWebSphereランタイム・コンポーネントをサービサビリティーに焦点を当ててサポートしています。
またこのチームはIBM Support Assistant (ISA)やその他のMDD4J、 Dump Analyzer、 Log Analyzer、 やWebSphere Data CollectionsのようなISAの鍵となるツールにも貢献しています。 |
| | | Russell Wrightは数年間データ・コミュニケーションやWebSphere Application Serverを含むミドルウェア・ソフトウェアの開発やサポートを行っていました。最近ではIBM Support Assistantへのトラブルシューティング・ツールのデプロイメントの責任者であり、またIBM Guided Activity Assistantの開発者でもあります。 |
記事の評価
| 
