無効なクラスローダー階層を回避するにはどうすればよいですか？

Question

iPlanetのJavaアプリケーションサーバーを実行していますが、その中にはcommons-logging-1.0.4.jarがロードされています。

私のアプリケーションの1つがAuthSSLProtocolSocketFactory（これはcommons-loggingも使用する別のapacheライブラリ）を呼び出すまでは問題ありません。

私は、JVMのクラスパスにjarファイルを入れて、このエラーを取得：

Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy....

commons-loggerは異なるクラスローダにロードされた自身の2つのインスタンスを持つ好きではないようです。私は、アプリケーションサーバがそれを初めてロードしているクラスローダを持っていると仮定しています（アプリケーションサーバコンフィグレーションを見つけることができません）ので、アプリケーションをロードしてその例外をスローします。

私はWebサーバーを変更できません。また、Apacheのライブラリを変更することはできません。提案？

Answer 1

クラスパスにコモンズを明示的に記録していますか？あなたはjvm classpathと言ったので、iPlanetを起動するときにコマンドラインで指定していると仮定します。これは、J2EEアプリケーションでjarをロードするための推奨方法ではありません。

最も簡単なことは、iPlanetに付属のcommons logging jarをApacheライブラリに使用させるのが最も簡単なことです。 WEB-INF/libディレクトリまたはクラスパス設定にcommons-logging.jarを置かないでください.iPlanetを自動的に取得する必要があります。

Answer 2

SLF4Jをご覧ください。

さらに、http://www.qos.ch/logging/classloader.jspが役立ちます。

Answer 3

iplanetに精通していませんが、WebSphereでは、アプリケーションのクラスローディング・ポリシーをPARENT_LASTに設定できます。これにより、アプリケーションのクラスローダー内のすべてがロードされてから、親プロセスが表示されます。これは、あなたの設定が似ていると仮定すると、この種の問題を解決するはずです。

これは、自分のアプリケーションにすべての依存関係を指定する必要があることを意味します（とにかくベストプラクティスです）。