directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: FC-250
Date Thu, 20 Dec 2018 15:25:52 GMT
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://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
>
>
> Kiran

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