JBoss EAP 7のEJB jarでのlog4j2ロギングのコード

Question

私は次のことを行っています： WebLogicからいくつかのレガシーアプリケーションをJBoss EAP 7に移植しています。他は、これらのEJBを呼び出すサーブレットアプリです。これらのEJBはejb-jarsにデプロイされています。私はこのすべてを大きなEARファイルにまとめることができることを知っていますが、それをしたくありません。サーブレットとEJB jarは、個別にデプロイ可能なコンポーネントである必要があります。

ログ設定があります。私たちはlog4j2を使用しており、JBossのログ設定とは独立していたいと考えています。私は、適切な依存関係を持つすべてのlog4j2 jarsを含むJBossモジュールを作成し、ロギングを行います。 サーブレットは実行され、ログをとり、EJBを呼び出して動作します。

唯一の問題は、EJBのロギングを構成する方法です。サーブレットのようなWebアプリケーションでは、簡単です。web.xmlにlog4jロギング設定ファイルを指定するだけです。 ejb jarのアナログは何ですか？私は方法を考えることができませんでした。

私は以下を試みました：EJBパッケージのサーブレット・アプリケーションの構成にロガー/アペンダーを追加し、新しいファイルを指定します。それは動作しません。新しいログファイルは作成されますが、ログファイルには何も書き込まれません。出力があるはずですが、EJBが実行されているときにLogManagerがサーブレットで指定された構成を使用していないことが明らかです。

JBoss EAP7上のEJB jarにデプロイされたEJBでlog4j2設定を指定する正しい方法は何ですか？

Answer 1

このスペースには、LoggerContextオブジェクトを初期化してシャットダウンするための@postConstructおよび@preDestroyメソッドの使用に関する解決策が以前に投稿されていました。

この計画は、ステートレスセッションBeanに拡張しようとすると崩壊しました。ステートフルビーンズではうまくいきました。それとも私は思った。最終的には私がやっていたことの弱点を露呈したOracle document on EJB Restrictionsが見つかりました。私の "解決策"には、EJBクラスの最終的ではない静的LoggerContextメンバーが含まれていました。私はそれを最終的にする方法を見つけたので、ステートレスケースが動作することができました。しかし私はますます私のアプローチに不満を抱いていました。ステートフルなケースでも、後でクラスタ化された環境で私を噛んでしまうかもしれない問題を発見しました。

今私が信じることは、私がやろうとしていることをすべきではないということです。

static final LoggerContextは、EJBがクラスタ内の別のマシンに配布された場合にどのように見えるのか想像もできません。 LoggerContextのようなオブジェクトは、EJBのようなコンテナ管理オブジェクトの静的かどうかにかかわらず、メンバーとして属しません。

私が構築しようとしているものに対して、EJBが適切な実装技術であることさえ明らかではありません。私のユースケースは実際にはトランザクション的ではないので、EJB実装の場合は強くないため、可能性のあるパスがEJBから完全に遠ざかります。

実際のメッセージは、EJBやその他のコンテナ管理コンポーネントが表示されている場合は、コンテナ提供のログシステムを使用するのが最善の方法です。私はlog4j2が好きですが、JBossがそれをサポートするまでは、コンテナ提供のlog4j1やその他のフレームワークに固執するのが最善です。