On Thu, Dec 20, 2018 at 1:40 AM Pike, Christopher <[email protected]> wrote:
> This commit is a potentially breaking change. ( > https://github.com/apache/directory-fortress-core/commit/2d8a53071b8d8b5bb3b6256f084a9e12d4a7cc10#diff-280616e1526a17336cdb4ff1855d7439 > ) > > > Specifically > > > @JsonTypeInfo(use=Id.CLASS, include=As.PROPERTY, property="fqcn", > visible=false) > public abstract class FortEntity > > This was added to emit the fully qualified name of the class so that JSON deserializer can detect the underlying sub-type of FortEntity present in the FortRequest received by the server. For example in XML the FortRequest for searching users is represented as: <FortRequest> <entity xsi:type="user" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance";> </entity> <contextId>HOME</contextId> </FortRequest> In JSON the same request is represented as: { "entity": { "fqcn": "org.apache.directory.fortress.core.model.User" }, "contextId": "HOME" } Here the "fqcn" attribute is equivalent to "xsi:type" attribute in XML > > now requires an id field to be added to all fortress entities when > serializing / de-serializing. Can someone provide insight into what problem > this is solving? > Though this field is required while deserializing, none of the model classes need to declare it (in fact no model classes in fortress-core were updated to include this) and this field is automatically included while serializing. This is all taken care of by the JacksonJsonProvider coupled with a custom field only mapper, both configured in applicationContext.xml of fortress-rest. This piece of code and config changes are present in the git branch named "FC-247". This branch is not yet merged into the master. > > > ~Chris P. > Kiran
