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 15:21:10 GMT
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.


Try this link


https://github.com/pike1212/fortress-rest-service/blob/master/fortressrestapi.png


________________________________
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



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