I am using logback for my logging and it has been working however; the other day I started getting a warning
log4j:WARN No appenders could be found for logger (org.apache.axis.i18n.ProjectResourceBundle).
log4j:WARN Please initialize the log4j system properly.
I am not using log4j nor have I ever with this project.
I have a logback.xml in my resources folder.
Any ideas on why this warning started to show up?
You must be using a library that does use log4j. Can you post anything more about your project?
You should probably just put log4j bridge on the classpath. Read more here:
http://www.slf4j.org/legacy.html
The jar you want to look into is log4j-over-slf4j. It will bridge log4j API to actually make calls to your implementation of slf4j API (in your case - logback).
If you are using Maven to build your project then it might be as simple as putting
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
in dependencies.
Excluding a library (if needed) would be done in this fashion (this assumes we are talking about the transitive dependency from the jar you've mentioned):
<dependency>
<groupId>org.swift.common</groupId>
<artifactId>jira-soap</artifactId>
<version>4.4.0</version>
<exclusions>
<exclusion>
<groupId>...</groupId>
<artifactId>...</artifactId>
</exclusion>
</exclusions>
</dependency>
Took me some time to find out since the message was log4j:WARN No appenders could be found for logger
I tried to exclude log4j and I tried the log4j-over-slf4j.
Then I ran mvn dependency:tree and finally found out that mye commons-configuration actually was using commons-logging
[INFO] +- commons-configuration:commons-configuration:jar:1.9:compile
[INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] +- ch.qos.logback:logback-classic:jar:1.0.13:compile
[INFO] | +- ch.qos.logback:logback-core:jar:1.0.13:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.5:compile
[INFO] +- org.slf4j:log4j-over-slf4j:jar:1.7.6:compile
[INFO] \- org.apache.commons:commons-lang3:jar:3.1:compile
This became the solution for me.
<!-- logging with logback (and slf4j)-->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.13</version>
</dependency>
<!-- had a dep in commons-configuration -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.6</version>
</dependency>
Related
Getting this Esception java.lang.NoClassDefFoundError: org/apache/kafka/streams/internals/QuietStreamsConfig.
Possibly because of dependency conflict. Related jars in pom.xml
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-streams-test-utils</artifactId>
<version>5.5.0-ccs</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-streams</artifactId>
<version>1.0.1</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
<exclusion>
<groupId> org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>1.0.1</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
When I run this command
**
mvn dependency:tree -Dverbose -Dincludes=org.apache.kafka
**
com.walmart.sims.ica:fault-handler:jar:0.0.1-SNAPSHOT
[INFO] +- org.apache.kafka:kafka-streams-test-utils:jar:5.5.0-ccs:test
[INFO] | +- (org.apache.kafka:kafka-streams:jar:5.5.0-ccs:test - omitted for conflict with 1.0.1)
[INFO] | \- (org.apache.kafka:kafka-clients:jar:5.5.0-ccs:test - omitted for conflict with 1.0.1)
[INFO] +- org.apache.kafka:kafka-streams:jar:1.0.1:compile
[INFO] | \- org.apache.kafka:connect-json:jar:1.0.1:compile
[INFO] | \- org.apache.kafka:connect-api:jar:1.0.1:compile
[INFO] \- org.apache.kafka:kafka-clients:jar:1.0.1:compile
So my test dependencies are getting omitted due to conflict because of which I get ClassNotFoundException when I run my test.
How should I resolve the conflict such that dependencies from test-utils are available at test scope otherwise at compile scope kafka-streams and kafka-clients dependencies are used?
What's the point of using one version in real prod code and much newer version of dependency for test code?
I would recommend to either downgrade kafka-streams-test-utils to a version that uses kafka-streams:1.0.1 or upgrade kafka-streams version used by your app to 5.5.0-ccs. I do not think test-utils version 5.5.0-css will work correctly with stream version 1.0.1 anyway.
But if you want to try you can exclude kafka-streams and kafka-client dependencies from test-utils
So,
once again im totally stuck with this error..
I've read few threads about the issue but cant fix it..
SLF4J: Found binding in [jar:file:/home/me/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.10.0/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/me/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
mvn dependency:tree gives following:
[INFO] +- org.springframework.boot:spring-boot-starter-data-jpa:jar:2.0.3.RELEASE:compile
[INFO] | +- org.springframework.boot:spring-boot-starter:jar:2.0.3.RELEASE:compile
[INFO] | | +- org.springframework.boot:spring-boot:jar:2.0.3.RELEASE:compile
[INFO] | | +- org.springframework.boot:spring-boot-autoconfigure:jar:2.0.3.RELEASE:compile
[INFO] | | +- org.springframework.boot:spring-boot-starter-logging:jar:2.0.3.RELEASE:compile
[INFO] | | | +- ch.qos.logback:logback-classic:jar:1.2.3:compile
[INFO] | | | | \- ch.qos.logback:logback-core:jar:1.2.3:compile
[INFO] | | | \- org.apache.logging.log4j:log4j-to-slf4j:jar:2.10.0:compile
For what i understand one instance is under starter-data-jpa
and in the folder .m2/ch/qos
but i cant delete that folder or the app wont start.
i cant seem to exclude it either.
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
</exclusions>
After exclusion i run mvn clean and re-import all the dependecies but it still wont start.
And when i delete the whole
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
</exclusions>
</dependency>
section, it now resides under [INFO] +- org.springframework.boot:spring-boot-starter-jdbc:jar:2.0.3.RELEASE:compile
according to mvn dependency:tree and app still wont start, same error.
So how do i get rid of this thing?
I have no idea how this happend. i have not added or removed anything in pom for weeks.
Decided to exclude all the logging framework so there wont be anymore unwanted loggers anywhere... it works
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
This problem exists from a long time. The best way to deal with this is to follow the steps:
Look for maven dependencies. Search for log4j-slf4j. This library can be from multiple dependencies. I didn't want to remove spring-boot-starter-logging as it effects regular pretty spring logs. How to get a dependency tree for an artifact?.
mvn dependency:tree
Exclude the dependency. You must be able to find one or more dependencies which has the same library. I had slf4j-log4j12 only in kafka-avro-serializer so I excluded from it. If your mvn dependency tree shows more thatn one make sure you exclude from all.
<dependency>
<groupId>io.confluent</groupId>
<artifactId>kafka-avro-serializer</artifactId>
<version>4.0.0</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
</exclusions>
</dependency>
I'd like to use Logback, for its performance and flexibility, with a Spring Boot project. I added the Logback dependencies to pom.xml:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.3</version>
</dependency>
... and ensured that the logging, within each of the classes in my project, was created like this:
public class MyClass {
static final Logger LOG = LoggerFactory.getLogger(MyClass.class);
When the project starts, the following warning is displayed in the console:
log4j:WARN No appenders could be found for logger (org.springframework.boot.logging.ClasspathLoggingApplicationListener).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
It seems that Spring is still trying to use log4j and not logback. I tried adding logging.config=classpath:logback.xml to the Spring application.properties, but it didn't resolve the issue.
Can you see what I'm doing wrong?
Update
Both #AliDehghani and #chrylis suggested that log4j is being referenced by another package in the pom. The output from mvn dependency:tree confirmed that hbase-common was the source:
com.woolford:my-project:jar:1.0-SNAPSHOT
+- org.apache.hbase:hbase-common:jar:1.1.2:compile
| [... etc ...]
| +- commons-logging:commons-logging:jar:1.2:compile
| [... etc ...]
| +- org.apache.hadoop:hadoop-common:jar:2.5.1:compile
| [... etc ...]
| | +- org.slf4j:slf4j-log4j12:jar:1.7.5:compile
| | \- com.jcraft:jsch:jar:0.1.42:compile
| +- org.apache.hadoop:hadoop-mapreduce-client-core:jar:2.5.1:compile
| [... etc ...]
| +- log4j:log4j:jar:1.2.17:compile
| [... etc ...]
\- org.apache.hbase:hbase-client:jar:1.1.2:compile
[... etc ...]
I tried excluding log4j (and slf4j) from hbase-common like this:
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-common</artifactId>
<version>1.1.2</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
The project failed to build:
[ERROR] Failed to execute goal on project my-project: Could not resolve dependencies for project com.woolford:my-project:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: javax.jms:jms:jar:1.1, com.sun.jdmk:jmxtools:jar:1.2.1, com.sun.jmx:jmxri:jar:1.2.1: Could not transfer artifact javax.jms:jms:jar:1.1 from/to java.net (https://maven-repository.dev.java.net/nonav/repository): Cannot access https://maven-repository.dev.java.net/nonav/repository with type legacy using the available connector factories: BasicRepositoryConnectorFactory: Cannot access https://maven-repository.dev.java.net/nonav/repository with type legacy using the available layout factories: Maven2RepositoryLayoutFactory: Unsupported repository layout legacy -> [Help 1]
I tried adding these dependencies to pom.xml, but that didn't help.
#AliDehghani noted, in his answer below, that Spring Boot uses Logback by default and so adding logback-core and logback-classic to the pom.xml shouldn't be necessary. I'm sure he's 100% correct. However, when I comment out the logback-core and logback-classic in pom.xml I see several warnings, e.g.
log4j:ERROR Could not create an Appender. Reported error follows.
java.lang.ClassNotFoundException: ch.qos.logback.core.ConsoleAppender
you already know this, but i wanted to wrap it up and generalize...
there are these three logging frameworks:
log4j (ancient)
slf4j (api used everywhere, there are different backends available)
logback (has nice features and configuration, successor of slf4j)
you have to manually throw out log4j and replace it with the compatibility bridge log4j-over-slf4j.
there is a slf4j backend called logback-classic.
mvn:
<dependency>
<!-- legacy log4j ==> slf4j -->
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.21</version>
</dependency>
<dependency>
<!-- slf4j ==> logback -->
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.7</version>
</dependency>
<dependency>
<groupId>...no maintainer...</groupId>
<artifactId>...old stuff...</artifactId>
<version>...ancient...</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
</exclusions>
</dependency>
sbt:
libraryDependencies ++= Seq(
Seq(...),
Seq(
"org.slf4j" % "log4j-over-slf4j" % "1.7.21", // legacy log4j --> slf4j
"ch.qos.logback" % "logback-classic" % "1.1.7" // slf4j --> logback
)
).flatten.map(_.excludeAll(
ExclusionRule(organization = "log4j", name = "log4j", artifact = "*"),
ExclusionRule(organization = "org.slf4j", name = "slf4j-log4j12", artifact = "*")
))
Spring Boot by default using Logback for its logging. There is no need for adding it explicitly:
By default, If you use the ‘Starter POMs’, Logback will be used for
logging. Appropriate Logback routing is also included to ensure that
dependent libraries that use Java Util Logging, Commons Logging, Log4J
or SLF4J will all work correctly.
You can also, change the log levels through using logging.level.*=LEVEL in your application.properies.
In my Vaadin project, I have a dependency on a certain library. This library uses slf4j for logging. In the library pom, logback slf4j binding is added as a runtime dependency.
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
<scope>runtime</scope>
</dependency>
In my application, I directly use log4j for logging. I want the logs added by the library to go in my log4j log.
For this, I added following to my pom to include slf4j log4j binding
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.12</version>
</dependency>
However, slf4j complains that it has found multiple bindings.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/D:/program_files/apache-tomcat-8.0.24/temp/0-ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/D:/program_files/apache-tomcat-8.0.24/temp/0-ROOT/WEB-INF/lib/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
I checked the dependency tree of my application, which has following for its dependency on logback. (Following is the only dependency on logback)
[INFO] | +- com.mycompany.mylib:libname:jar:1.1.0-SNAPSHOT:compile
[INFO] | | +- org.slf4j:jcl-over-slf4j:jar:1.7.5:runtime
[INFO] | | +- ch.qos.logback:logback-classic:jar:1.0.13:runtime
[INFO] | | | \- ch.qos.logback:logback-core:jar:1.0.13:runtime
[INFO] | | +- ch.qos.logback:logback-access:jar:1.0.13:runtime
Also, when I checked inside WEB-INF\lib directory in my war file, I found following jars.
logback-access-1.0.13.jar
logback-classic-1.0.13.jar
logback-core-1.0.13.jar
Why did logback ended up in my lib directory? As I have heard, runtime dependencies should not come into libs directory.
How should I resolve this? The library is developed within my company and I can ask the library developers to remove the logback runtime dependencies if needed.
Option 1: They change their pom.
The easiest way to fix this would be to have the library developers in your own company mark logback as optional and require SLF4J as a compile dependency explicitly. This is the right, canonical way to do SLF4J in Maven. In other words:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
Option 2: You revise their dependencies in your pom.
If you want to fix it yourself, without going through them, then you can use the exclusions tag when declaring their dependency. In other words, in your pom, do:
<dependency>
<groupId>your.company</groupId>
<artifactId>libraryname</artifactId>
<version>${theirlibrary.version}</version>
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
</exclusions>
</dependency>
You asked if there's an reason to depend on Logback directly; generally there isn't, for a library author. Their pom configuration is probably just a minor oversight on their part. There are some reasons to depend on logback specifically, but they have to do with startup (stuff with JoranConfigurator or StatusPrinter, that sort of thing, which shouldn't come up with a library. Other reasons to call Logback classes directly include stuff like custom appenders, which, again, shouldn't come up in a library, only a deployed app.
I have a problem when I deploy a webapp with hibernate 5
Caused by: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
at org.hibernate.internal.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:149) [hibernate-core-5.0.0.CR2.jar:5.0.0.CR2]
at org.hibernate.internal.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:759) [hibernate-core-5.0.0.CR2.jar:5.0.0.CR2]
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:490) [hibernate-core-5.0.0.CR2.jar:5.0.0.CR2]
at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) [hibernate-core-5.0.0.CR2.jar:5.0.0.CR2]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:708) [hibernate-core-5.0.0.CR2.jar:5.0.0.CR2]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:724) [hibernate-core-5.0.0.CR2.jar:5.0.0.CR2]
at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSessionFactory(LocalSessionFactoryBuilder.java:372) [spring-orm-4.1.7.RELEASE.jar:4.1.7.RELEASE]
at org.springframework.orm.hibernate4.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:454) [spring-orm-4.1.7.RELEASE.jar:4.1.7.RELEASE]
at org.springframework.orm.hibernate4.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:439) [spring-orm-4.1.7.RELEASE.jar:4.1.7.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1633) [spring-beans-4.1.7.RELEASE.jar:4.1.7.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1570) [spring-beans-4.1.7.RELEASE.jar:4.1.7.RELEASE]
... 23 more
With Hibernate 4 everything is OK.
I had a look at the class NamedQueryRepository at line 149. That class is calling the method debugf in this way
log.debugf( "Checking %s named HQL queries", namedQueryDefinitionMap.size() );
I can not see the problem
Here is my dependency tree
[INFO] ------------------------------------------------------------------------
[INFO] Building app Maven Webapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # app---
[INFO] +- org.springframework:spring-aspects:jar:4.1.7.RELEASE:compile
[INFO] | \- org.aspectj:aspectjweaver:jar:1.8.6:compile
[INFO] +- org.springframework:spring-tx:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-beans:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-context-support:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-context:jar:4.1.7.RELEASE:compile
[INFO] | \- org.springframework:spring-expression:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-core:jar:4.1.7.RELEASE:compile
[INFO] | \- commons-logging:commons-logging:jar:1.2:compile
[INFO] +- org.springframework:spring-orm:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-web:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-aop:jar:4.1.7.RELEASE:compile
[INFO] | \- aopalliance:aopalliance:jar:1.0:compile
[INFO] +- org.springframework:spring-jdbc:jar:4.1.7.RELEASE:compile
[INFO] +- org.springframework:spring-test:jar:4.1.7.RELEASE:test
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- org.hibernate:hibernate-entitymanager:jar:5.0.0.CR2:compile
[INFO] | +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
[INFO] | +- org.hibernate:hibernate-core:jar:5.0.0.CR2:compile
[INFO] | | +- antlr:antlr:jar:2.7.7:compile
[INFO] | | \- org.jboss:jandex:jar:1.2.2.Final:compile
[INFO] | +- dom4j:dom4j:jar:1.6.1:compile
[INFO] | | \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] | +- org.hibernate.common:hibernate-commons-annotations:jar:5.0.0.Final:compile
[INFO] | +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:compile
[INFO] | +- org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile
[INFO] | \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] +- org.hibernate:hibernate-c3p0:jar:5.0.0.CR2:compile
[INFO] | \- com.mchange:c3p0:jar:0.9.2.1:compile
[INFO] | \- com.mchange:mchange-commons-java:jar:0.2.3.4:compile
[INFO] +- org.primefaces:primefaces:jar:5.2.RC3:compile
[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.2:compile
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.2:compile
[INFO] \- net.sourceforge.jtds:jtds:jar:1.2.8:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
In glass fish This problem is caused by collision with dependencies of glassfish modules. If you check lib list in glassfishdir/modules you would see boss-logging.jar. You can delete it and replace with latest such as org.jboss.logging:jboss-logging:jar:3.3.0.Final. It worked for me.
In my case the culprit was the Jersey bean validator artifact.
One of its dependencies, bean-validation-2.4.0-b06.jar contains Jboss logging classes, for some reason.
I had to exclude the jersey-bean-validation and bean-validator artifacts from the spring-boot-starter-jersey dependency:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jersey</artifactId>
<exclusions>
<exclusion>
<artifactId>jersey-bean-validation</artifactId>
<groupId>org.glassfish.jersey.ext</groupId>
</exclusion>
<exclusion>
<artifactId>bean-validator</artifactId>
<groupId>org.glassfish.hk2.external</groupId>
</exclusion>
</exclusions>
</dependency>
EDIT: As of spring-boot 1.3.0, this is fixed and the exclusions above are not necessary anymore.
Try upgrading jboss-logging.jar to a more recent version. The one you are using does not seem to be compatible with Hibernate 5.
I also faced with such kind of problem when deployed ear on weblogic server.
Apparently, weblogic also use jboss logging system, and use old version of it.
My fix:
Add "weblogic-application.xml" to META-INF folder with this content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application>
<prefer-application-packages>
<package-name>org.jboss.logging.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>org/jboss/logging/Logger.class</resource-name>
</prefer-application-resources>
</weblogic-application>
I was getting the same error using jersey-spring-3 and hibernate 5.0.1.Final.Excluding org.glassfish.hk2.external:bean-validator from jersy-spring-3 and adding org.glassfish.jersey.ext:jersey-bean-validation worked for me.Here is my final dependency.
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.22.2</version>
<exclusions>
<exclusion>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>bean-validator</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>2.22.2</version>
</dependency>
from :
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.22.2</version>
</dependency>
In all probability you've got an outdated JBoss Logging JAR on the application's classpath. The ...f methods are a relatively new addition to the Logger API. Hibernate 5 directly depends on Logging version 3.3.0, but it is possible that somehwere in your pom.xml you have an overriding dependency to an earlier version. Another possibility is that you are deploying to a JBoss container where the logging API is container-provided. Then you may need to upgrade the JBoss server, or introduce a workaround to prefer classes contributed by your application.
Check my answer at NoSuchMethodError: org.jboss.logging.Logger.debugf
Even I was having issues after upgrading to Hibernate 5.2 , and the culprit was "jboss-logging 3.3.0.Final" which I see present in your dependencies too.
Following the steps on the link shared in the answer, you can reduce the dependency jboss-logging to 3.2 level which has the required function.
In my case the issue was caused by an older version of jboss-logging coming as transitive dependency from hibernate-ehcache, which I found by looking into the maven dependencies tree. I solved it by adding the exclusion:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>${hibernate.version}</version>
<exclusions>
<exclusion>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
I had the same error, it is solved by
First add the dependency of jboss logging jar as follows
<!-- https://mvnrepository.com/artifact/org.jboss.logging/jboss-logging -->
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
</dependency>
And if the error still exists then add following exlcusion to the maven dependency.
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.12</version>
<exclusions>
<exclusion>
<groupId>org.glassfish.hk2</groupId>
<artifactId>hk2</artifactId>
</exclusion>
</exclusions>
</dependency>
After doing these two things, it is working fine for me.I hope it will work for
you also.
Error that i got was "
Application run failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
:::
:::
Caused by: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V"
i deleted the jboss-logging folder <.m2\repository\org\jboss\logging\jboss-logging> and restarted the jboss server.
The jars got addedback and the error was gone. (i got some other error after that, but atleast this error was gone)
I too faced this issue. This is what fixed it for me
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.1.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
I have the same problen with spring4.2.1+hibernate5.0.2+jersey2.23.1.
My solution is the same: Excluding org.glassfish.hk2.external:bean-validator from jersy-spring-3 and adding org.glassfish.jersey.ext:jersey-bean-validation.
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.23.1</version>
<exclusions>
<exclusion>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>bean-validator</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
<version>2.23.1</version>
</dependency>
In my product environment, just delete bean-validator-2.4.0-b34.jar and add jersey-bean-validation-2.23.1.jar
This can be caused if a dependency includes
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.6.2</version>
</dependency>
Exclude it using an exclusions element in dependency.
JBoss 6.1+??
I set org.jboss.logging for jboss-logging-3.3.0.Final-redhat-1.jar in modules of jboss.
Its works for me.
Att.,
You can use Eclipse to find out which jar is causing the problem:
Setup a project with all your jars on the classpath
Navigate -> Open Type...
Type in org.jboss.logging.Logger
This will give you a list of jars which include the class. One of these is out of date and needs to be excluded (refer to other answers for variations on this).
My error was caused by GlassFish and I fixed it by configuring glassfish-web.xml:
The Java Servlet specification recommends that a web module's class loader look in the local class loader before delegating to its parent. You can make this class loader follow the delegation inversion model in the Servlet specification by setting delegate="false" in the class-loader element of the glassfish-web.xml file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
<context-root>/myContext</context-root>
<!–– Change this line "true" to "false" -->
<class-loader delegate="false"/>
<jsp-config>
<property name="keepgenerated" value="true">
<description>Keep a copy of the generated servlet class' java code.</description>
</property>
</jsp-config>
</glassfish-web-app>