I have a Passwords class containing a List where Password is an abstract class having two implementations either LocalPassword or VaultPassword and I’d like to start a process that will use a variable of type Passwords and iterate on its passwords with a multi-instance task.
The problem is that anytime I try to unserialize the Passwords in the workflow I have exceptions like: http://pastebin.com/nD1L0Has
First question is when I annotate the abstract class with a @JsonIgnore like stated in some doc/posts, is it supposed to be @spinjar.com.fasterxml.jackson.annotation.JsonIgnore or @com.fasterxml.jackson.annotation.JsonIgnore
I have a ReadPasswords class that uses Spin and Jackson ObjectMapper successfully to prove my annotations are ok but once deployed in my wildfly Spin doesn’t understand…
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.
