Camunda JSON marshalling and @JsonIgnore


#2

Hi @nvanbelle,

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.

Cheers.
Thorben


#3

Hi Thorben,

I tried packing my process with jackson v2.5.3 as you mentioned but this does not work either.

I get following exception:

Caused by: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "address" (class xx.xx.xx.domain.FunctionalLocation), not marked as ignorable (8 known properties: "street", "country", "gps_lon", "gps_lat", "id", "city", "streetNumber", "zipcode"])

Any help would be much appreciated!


#4

Hi @nvanbelle,

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.

Cheers,
Thorben


#5

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;

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <module name="com.fasterxml.jackson.core.jackson-databind" slot="2.5.3" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

Another thing that confuses me even more is the repackaged jackson libs in camunda-spin-dataformat-all;


#6

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


#7

Hi,

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?

Cheers,
Sebastian


#8

Hi Sebastien, I have sent you in PM the link to the test process.


#9

Hi,

thanks. How do I make it fail? I deployed it to wildfly and started the process with tasklist. I was able to complete all user tasks without an error.

Cheers,
Sebastian


#10

Hi Sebastien, I’ve added the steps the PM.

Steps to reproduce the exception:

  1. complete first task (=Submit Address)
  2. try to re-assign second task (=View Address) (press the X next to the user name so that the assign listener triggers again)

#11

Hi,

sorry I overlooked the first PM. Thanks.

Cheers,
Sebastian


#12

Hi,

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:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <exclude-subsystems>
            <subsystem name="jaxrs" />
        </exclude-subsystems>
        <dependencies>
            <module name="com.fasterxml.jackson.core.jackson-databind" slot="2.5.3" export="true" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

This should fix your issue. I also set the spin dependencies to provided in your pom.xml as they are provided by the wildfly application server.

Cheers,
Sebastian


#13

Hi Sebastian,

This is great news! :+1:
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.:

https://docs.jboss.org/author/display/WFLY8/Implicit+module+dependencies+for+deployments

Anyhow… I’m glad a solution has been found thanks to you and @thorben.


#14

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 :smile_cat:

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.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <exclude-subsystems>
            <!--<subsystem name="jaxrs" />-->
            <subsystem name="com.fasterxml.jackson.core.jackson-annotations" />
            <subsystem name="com.fasterxml.jackson.core.jackson-core" />
            <subsystem name="com.fasterxml.jackson.core.jackson-databind" />
        </exclude-subsystems>
        <dependencies>
            <module name="org.jboss.resteasy.resteasy-jackson-provider" />
            <module name="org.apache.httpcomponents" />
            <module name="org.jboss.resteasy.resteasy-jaxrs" />
            <module name="com.fasterxml.jackson.core.jackson-annotations" slot="2.5.0" export="true" />
            <module name="com.fasterxml.jackson.core.jackson-core" slot="2.5.3" export="true" />
            <module name="com.fasterxml.jackson.core.jackson-databind" slot="2.5.3" export="true" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

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.


#15

Hi @nvanbelle,

Note that the Jackson modules are modules, not a subsystem. For modules, the exclusion looks a little different like so:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <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>
    ...
  </deployment>
</jboss-deployment-structure>

Cheers,
Thorben


#16

My goodness… So obvious… I’ve been staring at this issue so long :sweat_smile:

Thanks!


#17

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.

This is killing me :weary:


#18

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?


#19

Hi @nvanbelle,

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.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <exclusions>
          <module name="org.jboss.resteasy.resteasy-jackson2-provider" />
        </exclusions>
        <dependencies>
          <module name="com.fasterxml.jackson.core.jackson-databind" slot="2.5.3" />
          <module name="deployment.jackson2-provider" />
        </dependencies>
    </deployment>
    <module name="deployment.jackson2-provider" >
      <dependencies>
        <module name="org.jboss.resteasy.resteasy-jackson2-provider" />
      </dependencies>
    </module>
</jboss-deployment-structure>

Variant 2

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.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <exclusions>
            <module name="org.jboss.resteasy.resteasy-jackson2-provider" />
        </exclusions>
        <dependencies>
          <module name="com.fasterxml.jackson.core.jackson-databind" slot="2.5.3" />
          <module name="deployment.jackson2-provider" />
        </dependencies>
    </deployment>
    <module name="deployment.jackson2-provider" >
      <dependencies>
        <module name="org.jboss.resteasy.resteasy-jackson2-provider">
          <imports>
            <exclude path="com/fasterxml/jackson/**" />
          </imports>
        </module>
        <module name="com.fasterxml.jackson.core.jackson-databind" slot="2.5.3" />
        <module name="com.fasterxml.jackson.core.jackson-annotations" slot="2.5.3"/>
        <module name="com.fasterxml.jackson.core.jackson-core" slot="2.5.3"/>
      </dependencies>
    </module>
</jboss-deployment-structure>

I hope that helps.

Cheers,
Thorben


#20

Hi Thorben,

Once again thank you. Variant 1 is working for me!
I’ll reflect on the solution to hopefully grasp it fully :stuck_out_tongue:

Kr,
Nico


#21

Hi Nico,

I updated Variant 1 slightly. The additional export exclusion in the deployment.jackson2-provider module is not needed.

The rationale behind using the deployment.jackson2-provider module is the following: When you look at the module.xml descriptor of org.jboss.resteasy.resteasy-jackson2-provider, you will notice that it exports the Jackson modules it depends on. That means, the Jackson classes of the main slot become visible to any module that depends on the jackson2 module. By putting deployment.jackson2-provider in between org.jboss.resteasy.resteasy-jackson2-provider and your application’s deployment, the jackson2 classes exported by the resteasy module become visible to deployment.jackson2-provider but not to your application (because deployment.jackson2-provider does not export the resteasy module itself).

Cheers,
Thorben