Inkompatibilität des Protokollierungsframeworks

Ich baue eine kleine Java-App und hoffe, Logback für die Protokollierung verwenden zu können.

Meine App ist von einem älteren Projekt abhängig, über das die Protokollierung erfolgt

org.apache.commons | com.springsource.org.apache.commons.logging | 1.1.1

... also war mein Plan zu verwenden

org.slf4j | jcl-over-slf4j | 1.5.6

... um die JCL-Protokollierung umzuleiten

org.slf4j | slf4j-api | 1.6.0

... und letztendlich zu

ch.qos.logback | logback-classic | 0.9.22
ch.qos.logback | logback-core | 0.9.22

So kann sich meine App über die slf4j-API per Logback anmelden, während sich der alte Bibliothekscode über die Umleitung am selben Speicherort anmelden kann.

Leider führt dies zu

java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
at   org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:141)

Ich habe versucht, bei einigen dieser Gläser höhere und niedrigere Verifizierungszahlen zu ermitteln und auch die API-Dokumentation und dergleichen zu durchsuchen ... aber ich kann das Problem nicht finden und lösen.

Hilfe bitte?

Obwohl Logback als "strategisches" Protokollierungsframework angesehen wird, habe ich einen gewissen Spielraum für den Protokollierungsmechanismus, den ich letztendlich verwende. Ich hoffe jedoch, entweder logback oder log4j verwenden zu können, und ich möchte auf jeden Fall die Protokollierung des alten Projekts über eine gemeinsame Konfiguration mit dem "neuen" Protokollierungsframework zusammenführen.

Sie mischen die 1.5.6-Version der jcl-Bridge mit der 1.6.0-Version der slf4j-api. Dies funktioniert aufgrund einiger Änderungen in 1.6.0 nicht. Verwenden Sie für beide die gleichen Versionen, dh 1.6.1 (die neueste). Ich benutze die jcl-over-slf4j-Brücke die ganze Zeit und es funktioniert gut.

Die Versionen SLF4J 1.5.11 und 1.6.0 sind nicht kompatibel (siehe Kompatibilitätsbericht ), da die Argumentliste der org.slf4j.spi.LocationAwareLogger.logMethode geändert wurde (Objekt [] S. 5 hinzugefügt):

SLF4J 1.5.11:

LocationAwareLogger.log ( org.slf4j.Marker p1, String p2, int p3,
                          String p4, Throwable p5 )

SLF4J 1.6.0:

LocationAwareLogger.log ( org.slf4j.Marker p1, String p2, int p3,
                          String p4, Object[] p5, Throwable p6 )

Siehe Kompatibilitätsberichte für andere SLF4J-Versionen auf dieser Seite .

Sie können solche Berichte mit dem Tool zur Überprüfung der Japi-Konformität erstellen .

Nur um denen zu helfen, die sich in einer ähnlichen Situation wie ich befinden ...

Dies kann verursacht werden, wenn eine abhängige Bibliothek versehentlich eine alte Version von slf4j gebündelt hat. In meinem Fall war es Tika-0,8. Siehe https://issues.apache.org/jira/browse/TIKA-556

Die Problemumgehung besteht darin, die Komponente auszuschließen und dann manuell von der richtigen oder gepatchten Version abhängig zu sein.

Z.B.

    <dependency>
        <groupId>org.apache.tika</groupId>
        <artifactId>tika-parsers</artifactId>
        <version>0.8</version>
        <exclusions>
            <exclusion>
                <!-- NOTE: Version 4.2 has bundled slf4j -->
                <groupId>edu.ucar</groupId>
                <artifactId>netcdf</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <!-- Patched version 4.2-min does not bundle slf4j -->
        <groupId>edu.ucar</groupId>
        <artifactId>netcdf</artifactId>
        <version>4.2-min</version>
    </dependency>