Incompatibilité du cadre de journalisation

Je construis une petite application Java et j'espère utiliser Logback pour la journalisation.

Mon application dépend d'un projet plus ancien qui se connecte via

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

... donc mon plan était d'utiliser

org.slf4j | jcl-over-slf4j | 1.5.6

... pour rediriger la journalisation JCL vers

org.slf4j | slf4j-api | 1.6.0

... et finalement à

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

afin que mon application puisse se connecter via la connexion via son API slf4j tandis que l'ancien code de la bibliothèque peut se connecter au même emplacement via la redirection.

Hélas, cela se traduit par

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)

J'ai essayé des numéros de version de plus en plus bas sur certains de ces bocaux et j'ai également fouillé dans la documentation de l'API et autres ... mais je suis incapable de trouver et de résoudre le problème.

Aidez-moi, s'il vous plaît?

Bien que le logback soit considéré comme le cadre de journalisation «stratégique», j'ai une certaine marge de manœuvre dans le mécanisme de journalisation que j'utilise finalement. J'espère cependant utiliser soit logback, soit log4j, et je veux absolument fusionner la connexion de l'ancien projet dans ce que le «nouveau» cadre de journalisation finit par être, via une configuration commune.

Vous mélangez la version 1.5.6 du pont jcl avec la version 1.6.0 de slf4j-api; cela ne fonctionnera pas à cause de quelques changements dans 1.6.0. Utilisez les mêmes versions pour les deux, c'est-à-dire 1.6.1 (la dernière). J'utilise le pont jcl-over-slf4j tout le temps et cela fonctionne très bien.

Les versions SLF4J 1.5.11 et 1.6.0 ne sont pas compatibles (voir rapport de compatibilité ) car la liste d'arguments de la org.slf4j.spi.LocationAwareLogger.logméthode a été modifiée (Object [] p5 ajouté):

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 )

Voir les rapports de compatibilité pour les autres versions de SLF4J sur cette page .

Vous pouvez générer de tels rapports à l' aide de l' outil japi-compliance-checker .

Juste pour aider ceux qui se trouvent dans une situation similaire à moi ...

Cela peut se produire lorsqu'une bibliothèque dépendante a accidentellement regroupé une ancienne version de slf4j. Dans mon cas, c'était tika-0.8. Voir https://issues.apache.org/jira/browse/TIKA-556

La solution consiste à exclure le composant, puis à dépendre manuellement de la version correcte ou corrigée.

PAR EXEMPLE.

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