Registrazione dell'incompatibilità del framework

Sto creando una piccola app Java e spero di utilizzare il logback per la registrazione.

La mia app dipende da un vecchio progetto che esegue la registrazione tramite

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

... quindi il mio piano era usare

org.slf4j | jcl-over-slf4j | 1.5.6

... per reindirizzare la registrazione JCL a

org.slf4j | slf4j-api | 1.6.0

... e infine a

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

quindi la mia app può accedere tramite logback tramite la sua API slf4j mentre il vecchio codice della libreria può accedere alla stessa posizione tramite il reindirizzamento.

Ahimè, questo si traduce 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)

Ho provato numeri di versione più alti e più bassi su alcuni di questi barattoli e ho anche scavato nella documentazione API e simili ... ma non sono in grado di trovare e risolvere il problema.

Aiuto per favore?

Sebbene il logback sia considerato il framework di registrazione "strategico", ho un certo margine di manovra nel meccanismo di registrazione che alla fine utilizzo. Spero di poter utilizzare logback o log4j, tuttavia, e voglio assolutamente unire la registrazione del vecchio progetto a qualunque sia il "nuovo" framework di registrazione, tramite una configurazione comune.

Stai mescolando la versione 1.5.6 del jcl bridge con la versione 1.6.0 di slf4j-api; questo non funzionerà a causa di alcune modifiche nella 1.6.0. Usa le stesse versioni per entrambi, cioè 1.6.1 (l'ultima). Uso sempre il bridge jcl-over-slf4j e funziona bene.

Le versioni SLF4J 1.5.11 e 1.6.0 non sono compatibili (vedi rapporto di compatibilità ) perché l'elenco degli argomenti del org.slf4j.spi.LocationAwareLogger.logmetodo è stato modificato (aggiunto Object [] 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 )

Vedi i rapporti di compatibilità per altre versioni di SLF4J in questa pagina .

È possibile generare tali rapporti tramite lo strumento di verifica della conformità japi .

Solo per aiutare chi si trova in una situazione simile alla mia ...

Ciò può essere causato quando una libreria dipendente ha accidentalmente impacchettato una vecchia versione di slf4j. Nel mio caso, era tika-0.8. Vedi https://issues.apache.org/jira/browse/TIKA-556

La soluzione è escludere il componente e quindi dipendere manualmente dalla versione corretta o patchata.

PER ESEMPIO.

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