font - mostrar texto en jlabel java

Integridad del marco de registro

Question

Estoy construyendo una pequeña aplicación Java y espero usar logback para iniciar sesión.

Mi aplicación tiene una dependencia en un proyecto anterior que hace su registro a través de

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

... entonces mi plan era usar

org.slf4j | jcl-over-slf4j | 1.5.6

... para redirigir el registro de JCL a

org.slf4j | slf4j-api | 1.6.0

... y finalmente a

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

así que mi aplicación puede iniciar sesión a través de logback a través de su API slf4j, mientras que el código de la biblioteca anterior puede iniciar sesión en la misma ubicación a través de la redirección.

Por desgracia, esto resulta en

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)

He intentado con números de veri fi cación más altos y más bajos en algunos de estos jarrones y también buscando en la documentación de la API y demás ... pero no puedo encontrar y resolver el problema.

¿Ayuda por favor?

Aunque logback se considera el marco de registro "estratégico", tengo un margen de maniobra en el mecanismo de registro que finalmente uso. Sin embargo, espero usar logback o log4j, y definitivamente quiero fusionar el inicio de sesión del proyecto anterior en lo que sea que termine siendo el "nuevo" marco de registro, a través de una configuración común.

Answer 1

Está mezclando la versión 1.5.6 del puente jcl con la versión 1.6.0 del slf4j-api; esto no funcionará debido a algunos cambios en 1.6.0. Use las mismas versiones para ambos, es decir, 1.6.1 (la última). Uso el puente jcl-over-slf4j todo el tiempo y funciona bien.

Answer 2

Las versiones de SLF4J 1.5.11 y 1.6.0 no son compatibles (vea el informe de compatibilidad ) porque la lista de argumentos del método org.slf4j.spi.LocationAwareLogger.log ha sido modificada (se agregó 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 )

Consulte los informes de compatibilidad para otras versiones de SLF4J en esta página .

Puede generar dichos informes con la japi-compliance-checker .

Answer 3

Solo para ayudar a aquellos en una situación similar a mí ...

Esto puede deberse a que una biblioteca dependiente haya incluido accidentalmente una versión anterior de slf4j. En mi caso, fue tika-0.8. Ver https://issues.apache.org/jira/browse/TIKA-556

La solución alternativa es excluir el componente y luego depender manualmente de la versión correcta o parchada.

P.EJ.

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