json - WildFly 中的 jackson-jaxrs 提供程序与 EAR 部署冲突

Question

我们有一个在 WildFly 9 上运行的 Java EE 7 应用程序，包括一个展开的 EAR 部署，其中包含几个 WAR 文件、一些 EAR 级别的 JAR 和一个包含 3rd pary JAR 的 lib 文件夹。 (我知道这不是今天人们会这样做的方式，但它就是这样。)
其中一个 WAR 包含一个 JAX-RS REST 服务，它 GET 和 POST 一个包含 Java 8 OffsetDateTime 的数据对象。 .由于 JSON-B 尚不可用，我们使用了 @JsonSerialize/@JsonDeserialize形成 jackson-databind 以便将其从 JSON 编码到 JSON。

这工作得很好，直到由于另一个 WAR 的变化，依赖 jackson-jaxrs 进入了 EAR 级别的 lib 文件夹。然后发生的事情是编码停止工作，因为容器试图将日期字符串从 JSON 直接设置到 OffsetDateTime键入并在获取时写入 Java 8 日期的所有内部字段，而不是格式化字符串。
我假设，上述注释的处理没有发生，因此服务器试图像其他简单类型一样映射它。当我删除属于 jackson-jaxrs 依赖项的 JAR 时，一切正常。然后，应用程序服务器可能会使用它自己的模块文件夹中的这个 JAR 版本。

所以，我的问题是:将 EARs lib 文件夹中的 jackson-jaxrs JAR 附加到系统提供的模块或仅后者有什么区别？为什么在反序列化时不考虑第一种情况下的注释？

Answer 1

Wildfly 9 将 jackson 1.9 捆绑为基本模块，注释位于 org.codehaus.jackson包裹。
我怀疑最近添加的库是(更新的)jackson 2.x，注释现在在 com.fasterxml.jackson包裹。

如果是这种情况，升级到 jackson 2.x(理想情况下与您从 EAR 获得的版本相同)应该可以解决问题。

或者，将您的子部署与 EAR 中存在的 jackson jar 隔离可能会起作用，但它可能会因传递依赖而变得困惑。见 class loading in Wildfly

编辑 正如您所确认的，有两个不同的版本正在运行。如果你负担得起，调整版本将最明确地帮助解决问题。

除此之外，您可能需要隔离每个子部署，以便它只能看到预期的版本。见 this answer例如(将整个部署与基本模块隔离开来)。