directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pike, Christopher" <clp...@psu.edu>
Subject Re: FC-250
Date Thu, 20 Dec 2018 13:15:20 GMT
  1.  Is there a way to give me permission to accept the PRs from github?

  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.

  3.  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.

________________________________
From: Kiran Ayyagari <kayyagari@apache.org>
Sent: Thursday, December 20, 2018 12:39:50 AM
To: fortress@directory.apache.org
Subject: Re: FC-250

On Thu, Dec 20, 2018 at 1:40 AM Pike, Christopher <clp207@psu.edu> 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&amp;data=02%7C01%7Cclp207%40psu.edu%7C17cfc158227245fdd4c708d6663da470%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636808812280341605&amp;sdata=C%2FJEfLe02bSjX0iiqcxkcGzLpzXPqVelJw3khxYOxEI%3D&amp;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&amp;data=02%7C01%7Cclp207%40psu.edu%7C17cfc158227245fdd4c708d6663da470%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636808812280351615&amp;sdata=%2FpQz3mZGdXiTG5h07j1rDyUnckLbuLphNrhpYxTnKm8%3D&amp;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

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message