I’m having an issue with the Spin plugin of Camunda. My JsonIgnore annotations are getting ignored (how ironic).
I have found this post of last year that may give a clue of the actual issue:
My deployed process has no bundled jackson libs. I depend (as I should) on the bundled jackson libs of WildFly8. However when I check the camunda-engine-rest-7.4.0.war that is predeployed on the WildFly distribution, it bundles it’s own version of the jackson libraries. Given the answer in the previous topic, this will probably cause the issue that I am having.
Can I fix this in a clean way? Does the topic describes the real issue here or could it be related to something else?
Camunda Spin uses a different version of the Jackson module, i.e. not the main slot but one with version 2.5.3 (in Camunda 7.4.0). We add this to the default Wildfly distribution. If you want to use Jackson annotations, your application should depend on that version of the Jackson module as well.
Don’t include Jackson in your application. In this case, you have the correct Jackson version but the classes exist twice and your application uses different Jackson classes than Spin, so the problem is not solved. You’ll have to set a module dependency from your application to the Wildfly Jackson module with version (i.e. slot name) 2.5.3. Then Spin and your application have access to the module’s classloader and both see the same loaded classes.
Hey thorben, I tried this before but I see my mistake now.
I used the system module which is 2.4.1
(modules > system > layers > base > com > fasterxml > core > jackson-core > main > xxx-2.4.1)
While I indeed had to use version 2.5.3 from another location
(modules > com > fasterxml > core > jackson-core > 2.5.3 > xxx-2.5.3)
Anyway, thank you very much. It all works now!
UPDATE: It looks as if I jumped the gun. I did not check the correct use case from where the exception was thrown and it still occurs.
In pom.xml I use version 2.5.3 and set the dependency scope to provided as before but no luck there.
I also tried using a jboss-deployment-structure.xml with following content;
I have reason to believe that version 2.5.3 is in fact loaded now but that my annotation is not taken into account as it is on method level rather than on field leven.
DEBUG [org.jboss.modules] (ServerService Thread Pool – 54) Module com.fasterxml.jackson.core.jackson-databind:2.5.3 defined by local module loader @763d9750 (finder: local module finder @5…
the camunda-spin-dataformat-all is not used by wildfly. It is used on other application servers like tomcat to ensure the correct jackson version. Wildfly uses camunda-spin-dataformat-json-jackson which does not include jackson.
Would it be possible to provide a small example to reproduce this problem on our site?
thanks for the source code. @thorben and I were able to debug the problem. I created a pull request on GitHub.
In summary the problem is that widfly adds per default resteasy to every deployment. The resteasy modules export the jackson module from the main slot as dependency. So these lead to a classloading problem while reading the jackson annoations in your application.
A fix is to exclude either this jackson modules in deployment structure. Or the whole jaxrs subsystem as I done it in the pull request:
This is great news!
It crossed my mind at one point that it could be a classloading issue due to jax-rs libs being loaded but I discarded that option as my reference of implicitly loaded dependencies was the following help page and I don’t use any jax-rs annotations.:
Most recently I was forced to add some REST services directly in my application. With the jaxrs subsystem completely disabled this is kind of hard to attain
I tried the workaround of excluding the jackson libs instead of the whole jaxrs subsystem but without success. I also cannot find which modules exactly get loaded by this subsystem.
If anyone knows what’s wrong or can give a hint it is much appreciated!
modules org.jboss.resteasy.resteasy-jackson-provider, org.apache.httpcomponents and org.jboss.resteasy.resteasy-jaxrs are included because I consumed a REST service via a reasteasy client already.
Thing is when I replace <exclude-subsystems> <subsystem name="jaxrs" /> </exclude-subsystems>
with <exclusions> <module name="com.fasterxml.jackson.core.jackson-annotations" /> <module name="com.fasterxml.jackson.core.jackson-core" /> <module name="com.fasterxml.jackson.core.jackson-databind" /> </exclusions>
I once again have the issue of ignoring my @JsonIgnore annotations.
Can you share the sources of a minimal application with this problem?
Do you also have the problem if you remove the resteasy dependencies and the code that uses them?
This is the minimal jboss-deployment-structure.xml that works for me with your example:
Now, if you want to use resteasy-jackson2-provider nonetheless, I think one of these should work (haven’t tried them, though):
Variant 1
Declares a custom module deployment.jackson2-provider that mirrors jackson but does not re-export jackson. I think this provider would ignore any custom Jackson annotations in your classes since the deployment.jackson2-provider module still uses its own Jackson dependencies.
Declares a custom module deployment.jackson2-provider that excludes the Jackson classes from the org.jboss.resteasy.resteasy-jackson2-provider dependency and imports the 2.5.3 version instead.
I’m a skeptical that this works, i.e. if the 2.5.3 Jackson classes become visible to the imported Resteasy Jackson classes. If this does not work,
an alternative approach would be creating a full copy of the org.jboss.resteasy.resteasy-jackson2-provider module in a custom slot, use a different
Jackson version there and import that in your application.