directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: FC-250
Date Thu, 20 Dec 2018 16:04:18 GMT
Maybe some code will help explain how it works.

All Fortress Rest services pass in:

https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/model/FortRequest.java

and return:

https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/model/FortResponse.java

Which then contains elements like FortEntity.

There are objects like this, perform the translation, before calling the APIs.  e.g. AdminMgr:

https://github.com/apache/directory-fortress-enmasse/blob/master/src/main/java/org/apache/directory/fortress/rest/AdminMgrImpl.java

Shawn

> On Dec 20, 2018, at 9:55 AM, Kiran Ayyagari <kayyagari@apache.org> wrote:
> 
> On Thu, Dec 20, 2018 at 9:15 PM Pike, Christopher <clp207@psu.edu> wrote:
> 
>> FortEntity really just provides some common fields for every entity
>> correct (modId, modCode, sequenceId)? When do you make a request for some
>> fortress data where you don't know what type will be returned? Or does the
>> api just treat everything as a FortEntity?
>> 
>> This is due to the format of FortRequest, when a FortRequest is received
> by the server in JSON format there must be a way to identify the
> concrete types of FortEntity represented by "entity" and "entity2" fields
> without which deserialization fails.
> 
> Note that the original aim was to only add support for JSON data format
> without shuffling too many things. The invocation mechanism still uses
> FortRequest just like JAXB.
> 
>> ________________________________
>> From: Kiran Ayyagari <kayyagari@apache.org>
>> Sent: Thursday, December 20, 2018 10:25:52 AM
>> To: fortress@directory.apache.org
>> Subject: Re: FC-250
>> 
>> On Thu, Dec 20, 2018 at 8:51 PM Pike, Christopher <clp207@psu.edu> wrote:
>> 
>>> I can certainly add appropriate code to remove the field on both ends. I
>>> was more questioning why the type information is necessary as I don't
>> have
>>> a use case where I need the type information specified in the object, so
>> it
>>> is extra unnecessary data IMO.
>>> 
>> There is no other way to specify the sub-type of FortEntity in JSON format
>> for the deserialization to work.
>> 
>>> 
>>> 
>>> Try this link
>>> 
>>> 
>>> 
>>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithubcom%2Fpike1212%2Ffortress-rest-service%2Fblob%2Fmaster%2Ffortressrestapi.png&amp;data=02%7C01%7Cclp207%40psu.edu%7C43f23ce52e8d42187d5608d6668f771b%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636809163699525418&amp;sdata=GLLSu4JIGHRQDNDgVskDltRzW8St7HxKWC5vpKXkLr8%3D&amp;reserved=0
>>> 
>>> 
>>> ________________________________
>>> From: Shawn McKinney <smckinney@apache.org>
>>> Sent: Thursday, December 20, 2018 10:07:30 AM
>>> To: fortress@directory.apache.org
>>> Subject: Re: FC-250
>>> 
>>> 
>>>> On Dec 20, 2018, at 7:15 AM, Pike, Christopher <clp207@psu.edu> wrote:
>>>> 
>>>>       • Is there a way to give me permission to accept the PRs from
>>> github?
>>> 
>>> Don’t know.  I’d post that question to the dev list.
>>> 
>>>> 
>>>> On Dec 20, 2018, at 7:15 AM, Pike, Christopher <clp207@psu.edu> wrote:
>>>> 
>>>>       • 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.
>>> 
>>> We can fix the 2nd problem (client with new version) by adding the code
>> to
>>> handle the attribute to the rest component.
>>> 
>>> The 1st problem is going to be tricker.  How big of a problem is this,
>> i.e
>>> how many old clients are we talking about?  1, 5, 50, 500? When will
>> they
>>> update to latest?
>>> 
>>> From the project perspective (rationale) we want to support JSON for
>>> obvious reasons that extend beyond the new UI Embrasure. Fortress Rest's
>>> usage of Apache CXF makes this change practically seamless, other than
>> what
>>> we’re discussing here.  It’s literally flipping a few switches.
>>> 
>>> There’s another option, but it’s not pretty.  We can add an annotation to
>>> ignore unknown fields in the request. We’d prefer not to go there, but if
>>> there is no other way, it should be considered (as a band-aid).
>>> 
>>> That’s why I asked the earlier question.  Can we apply a band-aid until
>>> you patch the old clients.
>>> 
>>>> 
>>>> On Dec 20, 2018, at 7:15 AM, Pike, Christopher <clp207@psu.edu> wrote:
>>>> 
>>>>       • 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.
>>> 
>>> I’d say that’s a fair characterization.  Fortress REST are merely
>> XML/JSON
>>> wrapped fortress APIs.  There’s a one-to-one correspondence between a
>>> Fortress REST service and API.  The same entities are passed in /
>> returned
>>> as in the APIs.
>>> 
>>> Your screenshot did not come through.  Can you post it somewhere?
>>> 
>>> Thanks,
>>> —Shawn
>>> 
>>> 
>>> Kiran
>> 
> Kiran


Mime
View raw message