We've hit an issue when upgrading from spring-boot 1.3.2 to the recently released 1.3.3.
Our application has been making use of the following dependencies, each the latest, without issue:
<neo4j.version>2.3.2</neo4j.version>
<sdn.version>4.0.0.RELEASE</sdn.version>
<sdn.rest.version>3.4.0.RELEASE</sdn.rest.version>
<neo4j.ogm.version>1.1.5</neo4j.ogm.version>
Today I upgraded our spring-boot and Spring Data Neo4j -based application, which starts and works well with spring-boot 1.3.2.RELEASE, by changing the pom.xml from:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.2.RELEASE</version>
</parent>
to
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.3.RELEASE</version>
</parent>
With this being literally the only change, the application now fails to start with the following error:
...
Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
java.lang.AbstractMethodError: ch.qos.logback.classic.pattern.EnsureExceptionHandling.process(Lch/qos/logback/core/pattern/Converter;)V
at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:88)
at ch.qos.logback.classic.encoder.PatternLayoutEncoder.start(PatternLayoutEncoder.java:28)
at ch.qos.logback.core.joran.action.NestedComplexPropertyIA.end(NestedComplexPropertyIA.java:167)
at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:317)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:196)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:182)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:149)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:99)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:49)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:152)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85)
at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:143)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:122)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:378)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:328)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:349)
at com.mycompany.Application.<clinit>(Application.java:35)
As expected, returning to 1.3.2.RELEASE does not cause any issues.
Searching so far reveals no trail to follow. Comparing the mvn dependency:tree output between using spring-boot 1.3.2.RELEASE and 1.3.3.RELEASE, I can see that the transient dependencies of ch.qos.logback:logback-classic and ch.qos.logback:logback-access jars have changed from 1.1.3 for spring-boot 1.3.2.RELEASE to 1.1.5 for spring-boot 1.3.3.RELEASE, while ch.qos.logback:logback-core remains at 1.1.3 for both spring-boot flavors.
Does anyone have any idea of what the underlying issue is (I'm guessing the class failing to instantiate has been removed or relocated) and/or -- more importantly -- what I can do to resolve it?
Spring Boot is missing some dependency management for logback-core which is allowing different versions to creep in. I've opened an issue to address that.
In the meantime, you can avoid the problem by adding your own dependency management for it to your pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
来源：https://stackoverflow.com/questions/35738674/spring-boot-upgrade-from-1-3-2-to-1-3-3-logback-issue