2017-04-03 12:18 GMT+02:00 COURTAULT Francois < francois.courta...@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:rmannibu...@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.courta...@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:rmannibu...@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:rmannibu...@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. >
