web-dev-qa-db-fra.com

Incompatibilité du cadre de journalisation

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

Mon application est dépendante 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 logback via son API slf4j tandis que l'ancien code de 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 nombres de vérification plus élevés et plus bas sur certains de ces bocaux, ainsi que dans la documentation de l'API, etc., mais je suis incapable de trouver et de résoudre le problème.

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

Bien que la journalisation soit considérée comme le cadre de journalisation "stratégique", j'ai un peu de marge de manœuvre dans laquelle le mécanisme de journalisation que j'utilise finalement. J'espère cependant utiliser logback ou log4j, et je souhaite absolument fusionner la journalisation de l'ancien projet dans le "nouveau" cadre de journalisation qui sera, via une configuration commune.

javacompatibilityapache-commonsslf4jlogback
109
Carl Smotricz

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 plus récente). J'utilise le pont jcl-over-slf4j tout le temps et cela fonctionne bien.

111
Holger Hoffstätte

Les versions SLF4J 1.5.11 et 1.6.0 ne sont pas compatibles (voir rapport de compatibilité ) car la liste des arguments de org.slf4j.spi.LocationAwareLogger.log La méthode a été modifiée (objet ajouté [] 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 l'outil japi-compliance-checker .

enter image description here

41
linuxbuild

Juste pour aider ceux qui se trouvent dans une situation similaire à moi-même ...

Cela peut être dû au fait qu'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 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>
23
Peter L