2

We have a Java EE 7 application running on a WildFly 9, consisting of an exploded EAR deployment, which contains several WAR files, some JARs at EAR level and a lib folder containing 3rd pary JARs. (I know this is not how one would do it today, but it is like it is.) One of the WARs contains a JAX-RS REST service, which GETs and POSTs a data object which contains a Java 8 OffsetDateTime. Since JSON-B is not yet available, we used @JsonSerialize/@JsonDeserialize form jackson-databind in order to marshall it from and to JSON.

This worked quite well until due to a change of another WAR, the dependency jackson-jaxrs came into the lib folder at EAR level. What happened then was that the marshalling stopped working, since the container tried to set the date string from JSON directly into the OffsetDateTime type and when getting it, writing all the internal fields of the Java 8 date instead of the formatted string. I assumed, that the processing of the above-mentioned annotations didn't take place and thus the server tried to map it like other simple types. When I deleted the JARs belonging to the jackson-jaxrs dependeny, everything worked fine again. The application server then probably used its own version of this very JAR from its modules folder.

So, my question is: What is the difference when having the jackson-jaxrs JAR in EARs lib folder additionally to the system provided module or only the latter? Why does it not consider the annontaions in the first case when de/serializing?

Alexander Rühl
  • 6,769
  • 9
  • 53
  • 96

1 Answers1

3

Wildfly 9 bundles jackson 1.9 as a base module and the annotations are in the org.codehaus.jackson package. I suspect that the library added recently is the (more recent) jackson 2.x and the annotations are now in the com.fasterxml.jackson package.

If that's the case, upgrading to jackson 2.x (ideally the same version as the one your get from the EAR) should solve the problem.

Alternatively isolating your subdeployment from the jackson jar present in the EAR might work but it can be messy with transitive dependencies. See class loading in Wildfly

EDIT as you confirmed, there are two different versions running. If you can afford it, aligning the versions would most definitively help solving the problem.

Short of that, you might need to isolate each subdeployment's so it only sees the expected version. See this answer for example (which isolate the entire deployment from the base module).

Guillaume
  • 14,306
  • 3
  • 43
  • 40
  • Thanks for the link. Concerning versions of jackson, we have the 2.x jackson core, annotations and data binding which contains the annotation in our ear. But there was also the jackson-jaxrs provider itself which has the exact same 1.9.x version as the one bundled in WildFly in the ear - and as far as I understood, that's the place where annotation processing takes place. Only thing I could imagine is something in the line of having two annotation processors active at runtime, but the one having read the (de)serialization annotation is not the one be seen at the time of actual marhalling. – Alexander Rühl Feb 07 '20 at 06:54