Protokollierungs-Framework-Inkompatibilität

Question

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

Meine App hat eine Abhängigkeit von einem älteren Projekt, das seine Protokollierung bietet über

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

... so mein Plan

org.slf4j | jcl-over-slf4j | 1.5.6 

... zu verwenden, war die JCL Anmeldung zu umleiten

org.slf4j | slf4j-api | 1.6.0 

... und schließlich zu

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

so kann meine App durch loggback über seine slf4j API protokollieren, während der alte Bibliothekscode sich über die Umleitung am selben Ort anmelden kann.

Leider führt dies in

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, höhere und niedrigere verision Zahlen auf einige dieser Gläser und auch über die API-Dokumentation zu graben und so ... aber ich bin nicht in der Lage zu finden und zu lösen das Problem.

Hilfe, bitte?

Obwohl Logback als das "strategische" Logging-Framework betrachtet wird, habe ich einen gewissen Spielraum, in welchem ​​Logging-Mechanismus ich letztendlich verwende. Ich hoffe jedoch, entweder logback oder log4j zu verwenden, und ich möchte definitiv die Protokollierung des alten Projekts über eine gemeinsame Konfiguration in das, was das "neue" Protokollierungs-Framework ist, einbinden.

Answer 1

Sie mischen die Version 1.5.6 der jcl-Bridge mit der 1.6.0-Version der slf4j-api; Dies wird nicht funktionieren, da einige Änderungen in 1.6.0 vorgenommen wurden. Verwenden Sie die gleichen Versionen für beide, d. H. 1.6.1 (die neueste). Ich benutze die jcl-über-slf4j Brücke die ganze Zeit und es funktioniert gut.

Answer 2

Nur kann helfen diejenigen, die in einer ähnlichen Situation wie mir ...

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

Die Umgehung schließen die Komponente aus und hängen dann manuell von der richtigen oder gepatchten Version ab.

EG.

<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> 

Answer 3

SLF4J 1.5.11 und 1.6.0-Versionen nicht kompatibel sind (siehe compatibility report), weil die Liste der Argumente org.slf4j.spi.LocationAwareLogger.log Methode (hinzugefügt Object [] p5) geändert:

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ät Berichte fo r andere SLF4J-Versionen on this page.

Sie können solche Berichte mit dem Tool japi-compliance-checker erstellen.