Estoy construyendo una pequeña aplicación Java y espero usar logback para registrar.
Mi aplicación depende de un proyecto anterior que realiza 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 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
para que mi aplicación pueda 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)
Probé números de versión más altos y más bajos en algunos de estos frascos y también busqué en la documentación de la API y demás ... pero no puedo encontrar y resolver el problema.
¿Ayuda por favor?
Aunque el logback se considera el marco de registro "estratégico", tengo cierto margen 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 antiguo en lo que sea que el marco de registro "nuevo" termine siendo, a través de una configuración común.
fuente
Las versiones de SLF4J 1.5.11 y 1.6.0 no son compatibles (ver informe de compatibilidad ) porque la lista de argumentos del
org.slf4j.spi.LocationAwareLogger.log
método ha sido cambiada (Objeto agregado [] p5):SLF4J 1.5.11:
SLF4J 1.6.0:
Consulte los informes de compatibilidad para otras versiones de SLF4J en esta página .
Puede generar dichos informes con la herramienta japi-compliance-checker .
fuente
Solo para ayudar a aquellos en una situación similar a la mía ...
Esto puede ocurrir cuando una biblioteca dependiente ha empaquetado 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 es excluir el componente y luego depender manualmente de la versión correcta o parcheada.
P.EJ.
fuente