Incompatibilité du cadre de journalisation

Question

Je suis en train de construire une petite application Java et j'espère utiliser logback pour la journalisation.

Mon application dépend d'un ancien projet qui effectue la journalisation par le biais de

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

Ainsi, mon application peut se connecter à travers logback via son API slf4j tandis que l'ancien code de la bibliothèque peut se connecter au même endroit via la redirection.

Hélas, il en résulte

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é d'augmenter et de diminuer les numéros de version de certains de ces jars et j'ai également cherché dans la documentation de l'API et autres... mais je ne parviens pas à trouver et à résoudre le problème.

De l'aide, s'il vous plaît ?

Bien que logback soit considéré comme le cadre de journalisation "stratégique", j'ai une certaine marge de manœuvre dans le choix du mécanisme de journalisation que j'utiliserai finalement. J'espère cependant utiliser soit logback, soit log4j, et je veux absolument fusionner la journalisation de l'ancien projet avec le "nouveau" cadre de journalisation, quel qu'il soit, via une configuration commune.

Answer 1

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

Answer 2

Les versions SLF4J 1.5.11 et 1.6.0 ne sont pas compatibles (cf. rapport de compatibilité ) parce que la liste des arguments de org.slf4j.spi.LocationAwareLogger.log a été modifiée (ajout de l'objet[] 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 )

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 la fonction japi-compliance-checker outil.

Answer 3

Juste pour aider ceux qui sont dans une situation similaire à la mienne...

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

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

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>