2017-04-03 12:37 GMT+02:00 COURTAULT Francois < francois.courta...@gemalto.com>:
> Hello Romain, > > "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." > Understood and I agree. > > Regarding Bean Validation, I have asked myself how it will be used to > perform this king of checking. > Coming back to my initial test, with Johnzon, on the server side, the > expected payload has its single field annotated with @NotNull and even with > this constraint, the server sends me back a 200 OK with empty content: is > it normal ? Is it a TomEE issue ? > > If you have CDI did you add @ValidatedOnExecution? > Best Regards. > > -----Original Message----- > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] > Sent: lundi 3 avril 2017 12:22 > To: users@tomee.apache.org > Subject: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson > > 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. > > > ________________________________ > 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. >
