特定の GlassFish アプリケーションで SLF4J を使用し、そのアプリケーション専用に SLF4J を構成することは可能ですか? 私たちは現在、Hibernate がインストールされたGlassFish 自体 に SLF4J API とロガー バインディングがその lib ディレクトリに含まれているという事実に取り組んでいます。
私たちのチームは、Java EE 6 Web アプリケーションを開発しています。開発のために、アプリケーションは GlassFish 3.1.2 にデプロイされますが、可能な限り移植可能である必要があります。
アプリケーション メッセージのログ記録には SLF4J を使用することにしました。メッセージ レベルに応じて、アプリケーションは特定のログ メッセージを異なる方法で処理する必要があるため、アプリケーション サーバーでログを構成するのではなく、独自にログ バックエンドを構成できる必要があります。
残念ながら、GlassFish 3.1.2 には、lib フォルダーにslf4j-api-1.5.8.jarとslf4j-jdk14-1.5.8.jarが含まれています。これにより、アプリケーションでslf4j-api-1.7.5.jarとslf4j-simple-1.7.5.jarを使用できなくなります(後者は最終的に別のバインディングに置き換えられます)。
GlassFish に独自のライブラリを考慮する前に (正しいバージョンの API が使用されるように) アプリケーションの lib を考慮するように指示する方法と、アプリケーションが提供する SLF4J バインディングが使用されていることを確認する方法はありますか?
開発には Eclipse を使用していますが、Maven は使用していません。これまでに見つけたほとんどの微調整/回避策は、使用できない Maven の構成を参照しています。Eclipse 固有のヒントを提供できれば、それは素晴らしいことです。Eclipse プロジェクトのプロパティで、Web アプリ ライブラリが一番上になるようにビルド パスの順序を既に構成しています。しかし、どういうわけかこれでは十分ではないようです。
助けてくれて本当にありがとうございます！
更新 1:一時的に機能させるために、GlassFish lib ディレクトリから SLF4J ライブラリを削除しました。次に、アプリケーションは、自己提供の SLF4J ライブラリを使用します。しかし、私はこれを展開プロセスの解決策とは考えていません。これが GlassFish で使用されるものを壊す可能性があるかどうかはわかりません (なぜライブラリが存在するのでしょうか?)。また、これは私たちの開発チームにとって実用的な解決策ではありません。
更新 2:実際には、すぐに使用できる干渉 SLF4J ライブラリが含まれているのは GlassFishではなく、更新ツールを介してインストールしたHibernate JPAパッケージです。現在、Hibernate JPA は必要ありませんが、Hibernate に変更する必要がいつか発生する可能性があります。また、Hibernate JPA またはその他の SLF4J を含むパッケージがインストールされているアプリケーション サーバーにアプリケーションを簡単に移植できるようにしたいと考えています。それに応じて質問のタイトルを更新しました。アプリケーションサーバーとアプリケーションの依存関係を干渉するというこの一般的な問題をどのように解決できますか?