从1.3.2升级到1.3.3的春季启动:登录问题

从spring-boot 1.3.2升级到最新发布的1.3.3时遇到了一个问题.

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>

今天，我通过将pom.xml更改为以下内容，升级了基于spring-boot和基于Spring Data Neo4j的应用程序，该应用程序可以在spring-boot 1.3.2.RELEASE中启动并正常运行:

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>

到

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

如预期的那样，返回1.3.2.RELEASE不会引起任何问题.

As expected, returning to 1.3.2.RELEASE does not cause any issues.

到目前为止，没有发现可追踪的线索.比较使用spring-boot 1.3.2.RELEASE和1.3.3RELEASE之间的mvn dependency:tree输出，我可以看到ch.qos.logback:logback-classic和ch.qos.logback:logback-access的瞬时相关性jar从spring-boot 1.3.2.RELEASE的1.1.3更改为spring-boot 1.3.3.RELEASE的1.1.5，而ch.qos.logback:logback-core在两次spring-boot都保持在1.1.3口味.

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?