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:55:57 GMT
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%2Fgithub.com%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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message