よくある質問とその答え
WebLogic Serverのロギング機能について教えてください。
技術評論社発行「BEA WebLogic Server 8.1J EJB 2.0徹底攻略」Appendix Bより抜粋
普段strutsを使い慣れている方は本書のプログラムを動かしてみて「あれ」っと思うかもしれない。アプリケーションのログ以外に、strutsのログも含めてすべてのログがWebLogic Serverのログに記録されるからだ。
strutsではさまざまなロギング・フレームワークを切り替えられるように、ログファクトリ・フレームワークを提供している。struts上のアプリケーションがログを出力するには、次のように行う。
// ログファクトリ・フレームワークの使用 import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; // ログオブジェクトの取得 Log log = LogFactory.getLog( "system name" ); // ログの出力 log.debug( "This is log message." );
そして、プログラム起動時にどのロギング・フレームワークを使用するかを選択する。例えば、いまやJavaのもっともメジャーなロギング・フレームワークであるLog4jを使用する場合は、プログラム起動時に次のように指定する。
> java -Dorg.apache.commons.logging.Log= org.apache.commons.logging.impl.Log4JCategoryLog
するとstrutsのログファクトリはプログラム実行時にLog4jのログオブジェクトを返してくれるので、アプリケーションのログの出力先がLog4jになる、というものだ。Log4jはスレッドセーフでログの出力フォーマットを柔軟に変えることができ、性能面も考慮されたオープン・ソースのロギング・フレームワークで、フリーであるため企業システムでもかなり利用されてきている。一方、WebLogic Serverも独自の高度なシステム管理機能と密接に結びついたロギング・フレームワークを提供している。以下、WebLogic Serverのロギングサービスを簡単に紹介しよう。
ログ出力API
WebLogic Server上のアプリケーションからWebLogic Serverのロギングサービスにログメッセージを出力するために、WebLogic Serverは次のログ出力APIを用意している。
I18Nメッセージカタログフレームワーク
エディタまたはweblogic.MsgEditorでXML形式のメッセージカタログを作成し、weblogic.i18ngenによりメッセージカタログをコンパイルする。すると、Javaクラスが生成されるのでそのクラスのメソッドをアプリケーションから呼び出すことでログメッセージを出力する。
NonCatalogLogger API
重大度に相当するログ出力メソッドが用意されている、一般的なWebLogic Serverのためのログ出力API。
(例)
NonCatalogLogger log = new NonCatalogLogger( "subsystem name" ); log.info( "アプリケーションが開始しました" );
通常は、国際化対応のために、Java ResourceBundleを併用する。WebLogic Server上のアプリケーションからだけでなく、クライアントアプリケーションでも使用できるAPIである。
GenericServletのlog API
javax.servlet.GenericServletサーブレット仕様のlogメソッドインタフェースの実装を提供している。
サーバおよびドメイン・ワイドのログ管理機能
WebLogic Serverの管理対象サーバは自身のサーバログを管理し、管理サーバはドメインログファイルに管理下の全サーバのログを記録する(図)。管理対象サーバで出力されたログはローカルのログファイルに出力されるほか、ログブロードキャスタを通じて所属するドメインのメッセージリスナに送られ、ドメインのログファイルにも記録される。このとき、DEBUGレベルのメッセージは取り除かれ、ドメインログには出力されない。なお、WebLogic Serverのシステム管理機能は第X章で詳しく説明する。

ログファイルのローテーション機能
ログファイルは出力し続けるとサイズが無限に大きくなってしまう。このようなことを防ぐため、WebLogic Serverではファイルサイズまたは時間間隔の指定により、現在のログファイル名をfilenamennnnnn.logのような数字をつけたファイル名にリネームし、現在のログファイルサイズが無限に大きくなってしまうことを防ぐ。
ログメッセージリスナ機能
ログメッセージ通知リスナを実装して管理サーバに登録できる。これにより、特定のログメッセージの通知に反応してシステム管理者にメール通知するなど、きめ細かい運用を行うようにシステムを構築できる。
ログフィルタ機能
ログフィルタを実装して登録することで、デフォルトではすべてのログメッセージを送信するブロードキャスタの振る舞いをカスタマイズできる。
以上、WebLogic ServerログはWebLogic Serverの高度なシステム管理機能と密接に結びついている。一方でLog4jのようにログ出力の振る舞いを動的に変えるような柔軟性には乏しい。例えば、ドメインログには各サーバのDEBUGレベルのログはフィルタでカットされるが、サーバログファイルにはすべての重大度のログメッセージが出力されてしまう(標準出力へは重大度により出力する・しないをコントロールできる)。
このようにLog4jもWebLogic Serverもそれぞれによいところを持ったロギング・システムを提供しているため、本書に登場するような「WebLogic Server上でstrutsを使用するアプリケーション」は、どのようにログを出力すれば運用しやすいか迷ってしまうかもしれない。本書のアプリケーションではそのひとつの解決策として、strutsのログファクトリ・フレームワークにWebLogic Serverのログを組み込むejbmarket.util.Loggerクラスを提供している。このクラスでは、前述のNonCatalogLoggerを使用してログメッセージを出力している。
本書CD-ROMで提供しているWebLogic Serverの起動スクリプトstartWebLogic.cmdを見ると、デフォルトで次のようにWebLogic Serverが起動されていることが分かるだろう。
> java -Dorg.apache.commons.logging.Log=ejbmarket.util.Logger ... webLogic.Server
この指定により、ログはWebLogic Serverシステムのログ、strutsのログ、WebアプリケーションのログもすべてWebLogic Serverのログに出力されるようになる。上記指定をLog4jにすれば、strutsのログとWebアプリケーションのログはLog4jに出力されるので、運用を考えながらプログラムを変更せずにログの管理方法をある程度変えることができると思うが、いかがだろう。ただし、strutsのログファクトリ・フレームワークを使用してEJBアプリケーションのログを出力することはあまり勧められない。本書のアプリケーションでもEJBから出力するログは別途作成したログファクトリ・フレームワークによらないXXXクラスを使用している。理由は、strutsのログファクトリ・フレームワークはあくまでもWeb層で動作するものだからだ。ClassNotFoundExceptionを避けるためにログファクトリ・フレームワークのライブラリをEJBアプリケーションJARファイルにパッケージすると、のちのちNoClassDefFoundErrorというやっかいなエラーに遭遇する場合がある(ClassNotFoundExceptionやNoClassDefFoundErrorについてはXXXを参照)。第7章で紹介するWebLogic Workshopではstrutsフレームワークを拡張したフレームワークを提供しその中でstrutsのログファクトリ・フレームワークを拡張して使用している。そのライブラリはWeb層にてパッケージ化されている。なかなか便利なログファクトリ・フレームワークだが、EJBアプリケーションからの使用は避けたほうが無難である。