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

Question

我们有一个在 WildFly 9 上运行的 Java EE 7 应用程序，它由一个展开的 EAR 部署组成，其中包含几个 WAR 文件、一些 EAR 级别的 JAR 和一个包含 3rd pary JAR 的 lib 文件夹。 （我知道这不是今天人们会这样做的方式，但它就是这样。） 其中一个 WAR 包含一个 JAX-RS REST 服务，它获取和发布一个包含 Java 8 OffsetDateTime 的数据对象。由于 JSON-B 尚不可用，我们使用 @JsonSerialize/@JsonDeserialize 形式 jackson-databind 来编组它与 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

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

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