tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Not the same behaviour between Johnzon and Jackson
Date Mon, 03 Apr 2017 10:22:09 GMT
2017-04-03 12:18 GMT+02:00 COURTAULT Francois <
Francois.Courtault@gemalto.com>:

> Hello Romain,
>
> I agree with you about report.
> What does "report" mean ? Is it a log ? Is it an error/exception returned
> back to the client ?
>
> About "Do you want to report it to the spec?":  my answer is yes.
> I would be pleased this point to be clarified by the spec as it is
> ambiguous according to me !
>
> My point would be during deserialization:
>       - to have all the fields, not annotated by JsonbTransient, mandatory
> for the Entity expected and so if one of them is missing, sending back an
> error to the
>          caller (4xx better than 500).
>

This is super constrained and prevent the usage of PUT/PATCH with partial
mapping so I would enable it with a flag in JsonbConfig but wouldnt use it
as a default.


>       - to follow the Must-Ignore policy (eg if there are additional  data
> in the Entity: others than the ones expected are there)
>

Probably same comment there.


Note that enforcing all fields to be there is very doable with bean
validation and since JAXRS and bean validation are integrated it is maybe a
false issue?


>
> Make sense ?
>
> Just my 2 cents ...
>
> Best Regards.
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: lundi 3 avril 2017 11:09
> To: users@tomee.apache.org
> Subject: Re: Not the same behaviour between Johnzon and Jackson
>
> 2017-04-03 11:06 GMT+02:00 COURTAULT Francois <
> Francois.Courtault@gemalto.com>:
>
> > Hello Romain,
> >
> > I believe I have understood that "JSON serialization is NOT in EE 7".
> > This is why I said: " the behavior of the readFrom is not really
> described"
> > in JAX-RS 2.0.
> >
> > BTW, I have read some parts of the current JSON-B specification and,
> > according to me, this is not quite clear (eg the spec is ambiguous)
> > Indeed:
> >      - in § 3.2, it is stated " Implementations SHOULD also report an
> > error during a deserialization operation, if it is not possible to
> > represent a JSON document value with the expected Java type."
> >      - in § 3.7.1, it is stated "If a JSON document contains a
> > name/value pair not corresponding to field or setter method, then this
> > name/value pair MUST be ignored. "
> >
> > So, according to what it is written above, what is the right behavior ?
> >      - report an error because it is not possible to "represent a JSON
> > document value with the expected Java type" during deserialization ?
> >      - to ignore a JSON name/value pair if this one doesn't
> > correspond to a field or setter method ?
> >
> >
> ignore, reporting can be a log statement or anything (but being undefined
> it wouldnt be tested so right this first quote is useless for now). Do you
> want to report it to the spec? Guess it will just clarify it before the
> final release (likely remove it since a log by error would mean always
> logging an error which would pollute logs or it would mean logging first
> error which is not that useful IMO)
>
>
> > Best Regards.
> >
> > -----Original Message-----
> > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Sent: lundi 3 avril 2017 09:49
> > To: users@tomee.apache.org
> > Subject: Re: Not the same behaviour between Johnzon and Jackson
> >
> > Hmm, not sure I 100% understand so if my next comment is inaccurate
> > please shout (also not capitals are not cause i'm angry or anything,
> > just to highlight the word ;)):
> >
> > JAX-RS is NOT about JSON or XML but about a way to serialize a payload
> > to some format. JAX-RS supports JSON, XML, binary protocols etc... so
> > it doesn't own anything but a word saying "we integrate with this other
> spec".
> > An example on another layer is: it doesn't define how bean validation
> > works but only that it works on some JAX-RS components/parts.
> >
> > The JSON serialization is NOT in EE 7 and therefore fully vendor
> > specific for now.
> >
> > JSON-B default is to ignore unknown fields (as in I-JSON spec IIRC)
> > whereas Jackson chose to fail on them. Both defaults can make sense so
> > I guess you just have to know which one you use and adapt.
> >
> > Agree that JSON-B/Johnzon one makes more sense when you use a js front
> > which can leak some attributes ;).
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog <
> > https://blog-rmannibucau.rhcloud.com> | Old Blog <
> > http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau>
> > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > | <
> > https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-04-03 9:45 GMT+02:00 COURTAULT Francois <Francois.Courtault@gemalto.
> > com
> > >:
> >
> > > Hello Romain,
> > >
> > >  I have read the specification and I haven't seen what you have
> > mentioned.
> > > In §4.2.1: Message Body Reader, point 5, it is written:
> > > "If step 4 locates a suitable MessageBodyReader then use its
> > > readFrom method to map the entity body to the desired Java type."
> > >
> > > But the behavior of the readFrom is not really described.
> > > I hope it will be clarified in JAX-RS 2.1 specification with JSON-B
> ....
> > >
> > > Best Regards.
> > >
> > > -----Original Message-----
> > > From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Sent: lundi 3 avril 2017 09:02
> > > To: users@tomee.apache.org
> > > Subject: Re: Not the same behaviour between Johnzon and Jackson
> > >
> > > Hello
> > >
> > > 2017-04-03 9:00 GMT+02:00 COURTAULT Francois
> <Francois.Courtault@gemalto.
> > > com
> > > >:
> > >
> > > > Hello,
> > > >
> > > > I have written a simple JAX-RS endpoint (POST) which takes an
> > > > object which contain one String field annotated @NotNull.
> > > > The POST method returns the object received.
> > > >
> > > > Then I invoke this endpoint:
> > > >
> > > > -          Johnzon:
> > > >
> > > > o   If I send a payload with one field which doesn't match the field
> > name
> > > > of the Class defined at server side: I get a 200 OK and a returned
> > > > payload empty
> > > >
> > > > o   If I send a payload with 2 fields whether the second one is
> > valuated
> > > > or not: I get a 200 OK and a returned payload empty
> > > >
> > > > -          Jackson:
> > > >
> > > > o   If I send a payload with one field which doesn't match the field
> > name
> > > > of the Class defined at server side: I get a 500 KO with
> > > > UnrecognizedPropertyException
> > > >
> > > > o   If I send a payload with 2 fields whether the second one is
> > valuated
> > > > or not: I get a 500 OK with UnrecognizedPropertyException
> > > >
> > > > What is the right behavior (Johnzon or Jackson) ? Is this behavior
> > > > defined in the JAX-RS 2.0 specification ?
> > > >
> > > >
> > > Right = none
> > > Defined in JAXRS = none (this is jsonp which is lower level, jsonb
> > > will be like johnzon but in EE 8 only)
> > >
> > > Note that you can customize jackson to ignore unknown fields and
> > > behave as johnzon, just different defaults
> > >
> > >
> > > > Best Regards.
> > > > ________________________________
> > > > This message and any attachments are intended solely for the
> > > > addressees and may contain confidential information. Any
> > > > unauthorized use or disclosure, either whole or partial, is
> prohibited.
> > > > E-mails are susceptible to alteration. Our company shall not be
> > > > liable for the message if altered, changed or falsified. If you
> > > > are not the intended recipient of this message, please delete it
> > > > and notify the
> > > sender.
> > > > Although all reasonable efforts have been made to keep this
> > > > transmission free from viruses, the sender will not be liable for
> > > > damages caused by a transmitted virus.
> > > >
> > > ________________________________
> > >  This message and any attachments are intended solely for the
> > > addressees and may contain confidential information. Any
> > > unauthorized use or disclosure, either whole or partial, is prohibited.
> > > E-mails are susceptible to alteration. Our company shall not be
> > > liable for the message if altered, changed or falsified. If you are
> > > not the intended recipient of this message, please delete it and
> > > notify the
> > sender.
> > > Although all reasonable efforts have been made to keep this
> > > transmission free from viruses, the sender will not be liable for
> > > damages caused by a transmitted virus.
> > >
> > ________________________________
> >  This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> ________________________________
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

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