On Thu, Dec 20, 2018 at 6:45 PM Pike, Christopher <[email protected]> wrote:
> > 1. Is there a way to give me permission to accept the PRs from github? > > The code is already in the FC-247 branch, so should be accessible to all committers. I am gonna merge the relevant parts of this branch into master this weekend, this probably makes it easier for you and others. > > 1. > 2. Understand that the fqcn field is automatically included, but the > issue is that clients and servers with different versions of the FortEntity > class are now incompatible. A client with the old version won't include the > field, so the server will fail on de-serialization, or a client with the > new version expects it to be there when de-serializing, so will fail if the > server doesn't provide it. > > So I am assuming that the FortEntity is being exchanged in JSON format (otherwise this issue won't happen), are you using a custom JSON provider than com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider? because I didn't encounter any issue with "fqcn" mapping when JacksonJsonProvider was used > > 1. > 2. It's been a while since I looked at the fortress REST api, but it > seems more xml rpc that REST. I've attached a screen shot that shows a high > level of how we have our REST api structured. > > The attachment didn't make it to the list, but yes it is more like XML rpc but to drive the effort for a simplified web admin UI the JSON support was added. > > 1. > > ------------------------------ > *From:* Kiran Ayyagari <[email protected]> > *Sent:* Thursday, December 20, 2018 12:39:50 AM > *To:* [email protected] > *Subject:* Re: FC-250 > > On Thu, Dec 20, 2018 at 1:40 AM Pike, Christopher <[email protected]> wrote: > > > This commit is a potentially breaking change. ( > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fdirectory-fortress-core%2Fcommit%2F2d8a53071b8d8b5bb3b6256f084a9e12d4a7cc10%23diff-280616e1526a17336cdb4ff1855d7439&data=02%7C01%7Cclp207%40psu.edu%7C17cfc158227245fdd4c708d6663da470%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636808812280341605&sdata=C%2FJEfLe02bSjX0iiqcxkcGzLpzXPqVelJw3khxYOxEI%3D&reserved=0 > > ) > > > > > > 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=" > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance&data=02%7C01%7Cclp207%40psu.edu%7C17cfc158227245fdd4c708d6663da470%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636808812280351615&sdata=%2FpQz3mZGdXiTG5h07j1rDyUnckLbuLphNrhpYxTnKm8%3D&reserved=0 > "> > </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 > Kiran
