NoSuchMethodError с API SLF4J
При использовании с slf4j,
String test = blahblahblah;
logger.info("{}",test);
Трассировка, как показано ниже
java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at org.slf4j.impl.JDK14LoggerAdapter.info(JDK14LoggerAdapter.java:304)
7 ответов
Похоже, у вас есть несовпадение версий между различными API SLF4J и библиотеками интеграции. SLF4J чрезвычайно раздражителен, когда дело доходит до совместимости версий (например, 1.6.x не обратно совместим с 1.5.x).
Убедитесь, что разные версии JAR совпадают, и убедитесь, что на пути к классам нет повторяющихся JAR.
Я получаю эту ошибку:
SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6]
SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
.
.
.
Теперь я только что прокомментировал строку с версией из pom.xml, как показано ниже, и теперь она работает:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<!-- <version>1.6.5</version> -->
</dependency>
Также убедитесь, что вы внедряете в Glassfish внешне (не локально), чтобы удалить дублирующиеся зависимости в папке lib установки Glassfish на этом сервере.
В моем случае все работало нормально локально, но после развертывания на сервере я получил эту ошибку.
Я столкнулся с той же проблемой с Spark Application. Это вызвано смешиванием разных версий.
Мы должны использовать что-то вроде этого:
"org.slf4j" % "slf4j-log4j12" % "1.7.30" % Test,
"org.slf4j" % "slf4j-api" % "1.7.30" % Test,
Я ожидаю, что это из-за несовместимой версии, например (если вы запускаете свое приложение 6.0 и держите файл jar (slf4j 1.5) или держите оба (slf4j 1.5 и 1.6)), тогда может возникнуть исключение.
Рекомендуется перейти на правильную версию. Не помещайте в путь сборки более одного файла версии (slf4f 1.5 и slf4j 1.6), удалите соответствующий файл.
а также
тогда беги уверен, получишь.
В моем случае я получал тот же "java.lang.NoSuchMethodError", который развертывал файл EAR в JBoss EAP 5.2.
Логи показали:
SLF4J: Запрошенная версия 1.5.6 из-за вашей привязки slf4j не совместима с [1.6]
Журналы: (server.log)
2018-11-05 09:59:46,382 ERROR [STDERR] (main) SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
2018-11-05 09:59:46,395 ERROR [STDERR] (main) SLF4J: The requested version 1.5.6 by your slf4j binding is not compatible with [1.6]
2018-11-05 09:59:46,395 ERROR [STDERR] (main) SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
2018-11-05 09:59:46,402 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/common-scheduling/services]] (main) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.validation.beanvalidation.LocalValidatorFactoryBean#0': Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/String;
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1512)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
at
Проблема:
Проблема заключалась в том, что на пути к классам имелись две разные версии файлов slf4j-api. (slf4j-log4j12-1.5.6.jar, slf4j-api-1.6.1.jar)
Разрешение:
- Я запустил "mvn dependency:tree", чтобы найти местоположение транзитивной зависимости.
- Затем я добавил тег исключения maven, чтобы исключить нежелательную версию артефакта.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.6</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Похоже, у вас другая версия класса MessageFormatter, чем у вашего класса JDK14LoggerAdapter. Контролируйте свой путь к классу.
В моем случае мы имеем правильное совпадение версий между различными API SLF4J и библиотеками интеграции. Но мы также используем tika-app
jar, в котором также есть классы SLF4J.
Чтобы проверить, есть ли у вас (толстый) jar, содержащий классы SLF4J, в системе Unix:
Перейдите в каталог WEB-INF/lib/ и выполните следующую команду
for i in *.jar; do jar -tvf "$i" | grep -Hsi MessageFormatter && echo "$i"; done
Это напечатает результат совпадения из всех банок на консоли.
Наконец мы заменили tika-app
раздражать мимо tika-core
баночка.