Incompatibilité du cadre de journalisation


109

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.

Réponses:


111

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.


2
Cela a fonctionné tout de suite, bien sûr; Merci beaucoup! Je n'avais pas utilisé 1.6.1 de ces jar parce qu'ils ne semblaient pas être disponibles. Je suis très ennuyé par m2eclipse, qui prétend me montrer toutes les versions disponibles mais en abandonne mystérieusement un nombre important.
Carl Smotricz

1
Juste pour l'intérêt de tous les autres suivants: je me suis retrouvé avec une flèche rouge dans le graphique de dépendances car même le dernier logback-core insiste sur slf4j-1.6.0. Il a fallu encore plus de choses à faire avec les versions jusqu'à ce que toutes les flèches rouges disparaissent, mais maintenant cela fonctionne à la fois et toutes les flèches bleues.
Carl Smotricz

1
Comment faire exactement cela.
user1721803

Merci ... L'utilisation du 'jcl-over-slf4j' a sauvé ma journée.
Tariq M Nasim

41

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 .

entrez la description de l'image ici


23

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>

Merci! J'ai été touché par cela en essayant d'utiliser Jackrabbit 2.2.5 avec SLF4J 1.6.1 et Logback 0.9.28!
Hendy Irawan

Merci. J'ai lié à votre réponse ici: spring-java-ee.blogspot.com/2011/04/…
Hendy Irawan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.