[jboss-jira] [JBoss JIRA] (DROOLS-5586) Uniform way to handle types in JSON payload

[ https://issues.redhat.com/browse/DROOLS-5586?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5586: -------------------------------------- Description: There are some behaviour differences in JSON payload type handling: (A) JSONMarshaller.marshall() produces type with FQCN. {code:json} { "org.kie.server.api.marshalling.objects.Pojo1" : { "desc" : "C", "pojo2" : { "org.kie.server.api.marshalling.objects.Pojo2" : { "desc2" : "B", "primitiveBoolean" : true, "pojo3" : { "org.kie.server.api.marshalling.objects.Pojo3" : { "desc3" : "A" } } } } } } {code} This is properly unmarshalled by JSONMarshaller.unmarshall(). And we can consider that this is the standard payload. (B) Then, if we edit the above payload to use "simple class name" by removing packages, {code:json} { "Pojo1" : { "desc" : "C", "pojo2" : { "Pojo2" : { "desc2" : "B", "primitiveBoolean" : true, "pojo3" : { "Pojo3" : { "desc3" : "A" } } } } } } {code} This is not properly unmarshalled. pojo1's fields are populated but pojo2's fields become 'null'. (C) Btw, if we have a type (of "simple class name") only for a top level object, {code:json} { "Pojo1" : { "desc" : "C", "pojo2" : { "desc2" : "B", "primitiveBoolean" : true, "pojo3" : { "desc3" : "A" } } } } } } {code} This is properly unmarshalled by JSONMarshaller.unmarshall(). ------------- So I conclude that "simple class name" works only for a top level object now. The "simple class name" is handled by this part of JSONMarshaller$CustomObjectDeserializer.mapObject() https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... because JSONMarshaller$CustomObjectDeserializer.classes contains simple class names: https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... However, the mapObject() is called only for top level objects so nested objects are not properly handled. ---- I confirmed with Enrique that (A) is correct and (B) is not. (C) is for convenience. So we don't take the behaviour difference as a bug. In other words, users should use (A) approach. Enrique noted that he can provide a more uniform way to handle this. So I filed this JIRA. FYI) You may use unit tests in this draft PR if useful: https://github.com/kiegroup/droolsjbpm-integration/pull/2202 was: There are some behaviour differences in JSON payload type handling: (A) JSONMarshaller.marshall() produces type with FQCN. {code:json} { "org.kie.server.api.marshalling.objects.Pojo1" : { "desc" : "C", "pojo2" : { "org.kie.server.api.marshalling.objects.Pojo2" : { "desc2" : "B", "primitiveBoolean" : true, "pojo3" : { "org.kie.server.api.marshalling.objects.Pojo3" : { "desc3" : "A" } } } } } } {code} This is properly unmarshalled by JSONMarshaller.unmarshall(). And we can consider that this is the standard payload. (B) Then, if we edit the above payload to use "simple class name" by removing packages, {code:json} { "Pojo1" : { "desc" : "C", "pojo2" : { "Pojo2" : { "desc2" : "B", "primitiveBoolean" : true, "pojo3" : { "Pojo3" : { "desc3" : "A" } } } } } } {code} This is not properly unmarshalled. pojo1's fields are populated but pojo2's fields become 'null'. (C) Btw, if we have a type (of "simple class name") only for a top level object, {code:json} { "Pojo1" : { "desc" : "C", "pojo2" : { "desc2" : "B", "primitiveBoolean" : true, "pojo3" : { "desc3" : "A" } } } } } } {code} This is properly unmarshalled by JSONMarshaller.unmarshall(). ------------- So I conclude that "simple class name" works only for a top level object now. The "simple class name" is handled by this part of JSONMarshaller$CustomObjectDeserializer.mapObject() https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... because JSONMarshaller$CustomObjectDeserializer.classes contains simple class names: https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... However, the mapObject() is called only for top level objects so nested objects are not properly handled. ---- I confirmed with Enrique that (A) is correct and (B) is not. (C) is for convenience. So we don't take the behaviour difference as a bug. In other words, users should use (A) approach. Enrique noted that he can provide a more uniform way to handle this. So I filed this JIRA. FYI) You may use unit tests in this draft PR: https://github.com/kiegroup/droolsjbpm-integration/pull/2202 -- This message was sent by Atlassian Jira (v7.13.8#713008)