Unserialize abstract class SPIN/JACKSON-JSON-01006

Hi Eric,

There’s a couple of things to consider here. First of all, there are two flavours of the Spin artifacts (confer the docs):

  • camunda-spin-core and addititional artifacts for the different data format implementations (e.g. camunda-spin-dataformat-json-jackson for JSON)
  • camunda-spin-dataformat-all: a single artifact that contains camunda-spin-core and the JSON and XML dataformat artifacts

Besides transitivity of dependencies, the crucial difference between these two artifacts is that camunda-spin-dataformat-json-jackson has a regular Maven dependency to jackson-databind. If you use this approach, then you’ll use @JsonIgnore in the regular Jackson package namespace. On the contrary, camunda-spin-dataformat-all contains jackson-databind, but in a relocated package namespace (prefixed with spinjar). The motive behind this is that the Jackson library used in camunda-spin-dataformat-all will not interfere with another Jackson version on your classpath (e.g. on a container like Tomcat, this can be an issue).

Now, if you want to customize Jackson (de-)serialization, you should go with the first flavour. It is not desirable to program against the spinjar packages as your code won’t work outside the Camunda context and you also won’t be able to use third-party Jackson modules in the future (at least without relocating those as well). You are lucky that on Wildfly, we deploy the camunda-spin-core and related libraries by default, as the Wildfly module system deals quite well with multiple Jackson versions. So, if you want the annotation to be recognized on Wildfly, use the regular Jackson packages.

Lastly, if your annotation is still is not picked up, it might be that your application has a dependency to a different Jackson module than the camunda-spin-dataformat-json-jackson module has. In this case, you’ll have to get the module dependencies right, which was previously discussed here.

I hope that helps.


1 Like