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 <[email protected]> wrote: > > On Thu, Dec 20, 2018 at 9:15 PM Pike, Christopher <[email protected]> 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 <[email protected]> >> Sent: Thursday, December 20, 2018 10:25:52 AM >> To: [email protected] >> Subject: Re: FC-250 >> >> On Thu, Dec 20, 2018 at 8:51 PM Pike, Christopher <[email protected]> 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&data=02%7C01%7Cclp207%40psu.edu%7C43f23ce52e8d42187d5608d6668f771b%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636809163699525418&sdata=GLLSu4JIGHRQDNDgVskDltRzW8St7HxKWC5vpKXkLr8%3D&reserved=0 >>> >>> >>> ________________________________ >>> From: Shawn McKinney <[email protected]> >>> Sent: Thursday, December 20, 2018 10:07:30 AM >>> To: [email protected] >>> Subject: Re: FC-250 >>> >>> >>>> On Dec 20, 2018, at 7:15 AM, Pike, Christopher <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
