そのため、いくつかのサービスを移植して、log4j で Logback を使用し、log4j-over-slf4j jar を使用して、従来の依存関係のために log4j を偽装しています。唯一の問題は、log4j-over-slf4j が log4j のクラスの多くを実装していないことです。そのため、依存する jar から例外が見つからないクラスがいくつか見られます。人々はこれをどのように回避しましたか？log4j-over-slf4j jar の代わりに nlog4j をクラスパスに入れるだけで十分ですか? この最後のアイデアはまだテストしていませんが、明日実行する予定です。
参照：
唯一の問題は、log4j-over-slf4jがlog4jのクラスの多くを実装していないことです。そのため、依存するjarからの例外が見つからないまともな少数のクラスが表示されます。人々はこれをどのように回避しましたか？
さて、あなたが投稿したブリッジングレガシーAPIリンクで明示的に言及されている「問題」に直面していると思います。
いつ動作しませんか？
log4j-over-slf4jモジュールは、アプリケーションがブリッジに存在しないlog4jコンポーネントを呼び出す場合は機能しません。たとえば、アプリケーションコードがlog4jアペンダー、フィルター、またはPropertyConfiguratorを直接参照している場合、log4j-over-slf4jはlog4jの代わりとしては不十分です。ただし、log4jが構成ファイル（log4j.propertiesまたはlog4j.xml）を介して構成されている場合、log4j-over-slf4jモジュールは正常に機能するはずです。
依存するJARが制御下にある場合は、SLF4JMigratorツールを使用してコードを移行してみてください。
log4j-over-slf4j jarの代わりにnlog4jをクラスパスに入れるだけで十分ですか？
これで解決するかもしれませんがClassNotFoundException、ロギング全体がどのように機能するのだろうかと思います。そして、NLog4Jがもはや積極的に開発されていないことを考えると、これは良い長期的な解決策であるかどうか疑問に思います。