分析

首先是一些随机的事实：

• 如果不是 given a class loader ， JAXBContext::newInstance 在查找JAXB实现时将使用 the thread's context class loader -即使您调用 newInstance(Class...) (可能会错误地认为它使用了提供的类实例的加载器)
• Tomcat构建 a small class loader hierarchy 以将web应用程序彼此分开<代码>H29<代码>H110通过不依赖于模块java.xml.bind，在Java9中，JAXB类不会由引导程序或系统类加载器加载<代码>H211<代码>F212

下面是在Java 8上发生的事情：

Tomcat没有传递类加载器给JAXB (oops)，所以它使用线程的上下文类加载器

• 我们猜测Tomcat没有显式地设置上下文类加载器，所以它最终将是加载Tomcat的那个: system类

，因为系统类加载器可以看到整个

• ，因此包含在其中的JAXB实现

Java 9进入-钢琴停止演奏，每个人都放下苏格兰酒：

• 我们添加了 JAXB as a regular dependency ，所以它是由web应用程序的类加载器
• 加载的，就像在Java8中一样，JAXB搜索系统类加载器，但是人们看不到应用程序的加载器(只能反过来)
• JAXB找不到实现，并导致

崩溃

解决方案

解决方案是确保JAXB使用正确的类加载器。我们知道有三种方法：

• 调用 Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
• create a context resolver ，但这确实不是一个好主意，但这需要JAX-WS，感觉就像用另一个
• 替换一个邪恶，使用 JAXBContext::newInstance 的包接受变体(<代码>C39)，它也接受一个类加载器并传递正确的加载器，尽管这需要一些重构<代码>H240<代码>F241

我们使用了第三种选择，并对 JAXBContext::newInstance 的包接受变体进行了重构。卑微的工作，但解决了问题。

备注

User 提供了关键信息，但删除了他们的答案。我希望这不是因为我要求了一些编辑。所有的功劳/报应都应该归功于他们！@curlals:如果你恢复并编辑了你的答案，我将接受并提升它。