web-dev-qa-db-ja.com

SLF4Jを維持しながら、ライブラリの依存関係からログバックを削除するにはどうすればよいですか？

私のVaadinプロジェクトでは、特定のライブラリに依存しています。このライブラリは、ロギングにslf4jを使用します。ライブラリpomでは、logbackslf4jバインディングが実行時の依存関係として追加されます。

    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>${logback.version}</version>
        <scope>runtime</scope>
    </dependency>

私のアプリケーションでは、log4jを直接使用してログを記録しています。ライブラリによって追加されたログをlog4jログに記録したいと思います。

このために、slf4jlog4jバインディングを含めるためにpomに以下を追加しました

    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
        <version>1.7.12</version>
    </dependency>

ただし、slf4jは、複数のバインディングが見つかったと文句を言います。

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/D:/program_files/Apache-Tomcat-8.0.24/temp/0-ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/D:/program_files/Apache-Tomcat-8.0.24/temp/0-ROOT/WEB-INF/lib/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]

アプリケーションの依存関係ツリーを確認しました。このツリーには、ログバックへの依存関係があります。 （以下はログバックへの唯一の依存関係です）

[INFO] |  +- com.mycompany.mylib:libname:jar:1.1.0-SNAPSHOT:compile
[INFO] |  |  +- org.slf4j:jcl-over-slf4j:jar:1.7.5:runtime
[INFO] |  |  +- ch.qos.logback:logback-classic:jar:1.0.13:runtime
[INFO] |  |  |  \- ch.qos.logback:logback-core:jar:1.0.13:runtime
[INFO] |  |  +- ch.qos.logback:logback-access:jar:1.0.13:runtime

また、内部を確認したところWEB-INF\lib warファイルのディレクトリで、次のjarファイルが見つかりました。

logback-access-1.0.13.jar
logback-classic-1.0.13.jar
logback-core-1.0.13.jar

ログバックがlibディレクトリに保存されたのはなぜですか？私が聞いたように、ランタイムの依存関係はlibsディレクトリに入るべきではありません。

これをどのように解決すればよいですか？ライブラリは社内で開発されており、必要に応じてライブラリ開発者にログバックランタイムの依存関係を削除するように依頼できます。

javamavenloggingdependenciesslf4j
13
Lahiru Chandima

オプション1：彼らは彼らのpomを変更します。

これを修正する最も簡単な方法は、自社のライブラリ開発者にログバックをoptionalとしてマークさせ、コンパイルの依存関係としてSLF4Jを明示的に要求することです。これは、MavenでSLF4Jを実行するための正しい正規の方法です。言い換えると：

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>${slf4j.version}</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>${logback.version}</version>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

オプション2：pomでそれらの依存関係を修正します。

それらを経由せずに自分で修正したい場合は、依存関係を宣言するときにexclusionsタグを使用できます。言い換えれば、あなたのpomで、次のことを行います。

<dependency>
    <groupId>your.company</groupId>
    <artifactId>libraryname</artifactId>
    <version>${theirlibrary.version}</version>
    <exclusions>
        <exclusion>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Logbackに直接依存する理由があるかどうかを尋ねました。図書館の著者にとっては、一般的にはありません。彼らのpom構成は、おそらく彼らの側のほんの小さな見落としです。特にログバックに依存する理由はいくつかありますが、それらはスタートアップと関係があります（ JoranConfigurator または StatusPrinter のようなものログバッククラスを直接呼び出す他の理由には、 カスタムアペンダー のようなものが含まれます。これもライブラリに表示されるべきではなく、デプロイされたアプリのみです。 。

19
durron597