it-swarm.com.de

Inkompatibilität des Protokollierungsframeworks

Ich erstelle eine kleine Java App und hoffe, Logback für die Protokollierung zu verwenden.

Meine App ist von einem älteren Projekt abhängig, über das sie protokolliert

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 durch Zurückmelden anmelden, während sich der alte Bibliothekscode über die Umleitung an derselben Stelle 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 bei einigen dieser Gläser höhere und niedrigere Versionsnummern ausprobiert und auch API-Dokumentation und ähnliches durchgearbeitet ... aber ich bin nicht in der Lage, das Problem zu finden und zu lösen.

Hilfe bitte?

Obwohl die Rückmeldung als "strategisches" Protokollierungsframework betrachtet wird, habe ich einen gewissen Spielraum, welchen Protokollierungsmechanismus ich letztendlich verwende. Ich würde jedoch hoffen, entweder logback oder log4j zu verwenden, und ich möchte auf jeden Fall die Protokollierung des alten Projekts über eine gemeinsame Konfiguration mit dem "neuen" Protokollierungsframework zusammenführen.

109
Carl Smotricz

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

111

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

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 japi-compliance-checker erstellen.

enter image description here

41
linuxbuild

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 schließt die Komponente aus und hängt dann manuell von der richtigen oder gepatchten Version ab.

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>
23
Peter L