具体的には、ApplicationContextを介してプロジェクトを構成するためにのみSpringを使用します。私の春のxmlでは、PropertyPlaceholderConfigurerを介していくつかのBeanプロパティをロードします。依存関係でcommons-logging-xxをjcl-slf4j.jarと交換するときはいつでも、プレースホルダー置換のClassNotFoundExceptionsでコンテキストのロードが失敗します。例：
私のspring.xmlには次のものがあります。
<bean id="testbean" class="${testbean.implementingClass}"/>
ここで、testbean.implementingClassはspring.propertiesで定義されています。
testbean.implementingClass=my.implementation.TestClass
commons-logging jarを使用してプロジェクトを実行すると、すべてが完全に機能します。これをjcl-slf4jに変更すると、クラス[$ {testbean.implementingClass}]が見つからなかったというClassNotFoundExceptionが発生します。つまり、プレースホルダーの置換は行われません。誰かがこれを観察しましたか？
編集：私の問題はjarファイルとは関係ありません： http： //www.slf4j.org/legacy.htmlから：
JCL over SLF4Jの実装により、SLF4Jに段階的に移行できます。特に、ソフトウェアが依存しているライブラリの一部が、予見可能な将来にわたってJCLを使用し続ける場合はなおさらです。SLF4Jの信頼性のメリットをすぐに享受し、同時に下位互換性を維持できます。commons-logging.jarをjcl-over-slf4j.jarに置き換えるだけです。その後、基礎となるロギングフレームワークの選択は、JCLではなくSLF4Jによって行われますが、クラスローダーがJCLを悩ませることはありません。基盤となるロギングフレームワークは、SLF4Jでサポートされている任意のフレームワークにすることができます。多くの場合、commons-logging.jarをjcl-over-slf4j.jarに置き換えると、コモンズロギングに関連するクラスローダーの問題が即座に永続的に解決されます。