2017-04-03 15:09 GMT+02:00 COURTAULT Francois < francois.courta...@gemalto.com>:
> Hello Danilo, > > Yes I know we can use Bean Validation. > My point is more about default behavior in case of non Bean Validation > usage? > > definitively not fail to support all the partial cases without requiring another payload. We discuss it while doing json-b and think that's one thing where we all agreed very quickly. Here a trivial example where it would not make sense: - you have an @Entity - you save it (EntityPayload without id) - you update it (EntityPayload with id) do you want 2 payloads or 1 there? > Best Regards. > > -----Original Message----- > From: Danilo Cominotti Marques [mailto:dcominot...@gmail.com] > Sent: lundi 3 avril 2017 14:35 > To: users@tomee.apache.org > Subject: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson > > My impression is that making all fields implicitly mandatory would give > way to confusion given that Bean Validation is used for *explicit > *validation, with constraints such as @NotNull, @NotEmpty (which was in > Hibernate Validator and will be in the next specification, as far as I > know), etc. > Additionally, if for whatever reason you don't have access to edit the > classes used for mapping, making all fields implicitly mandatory would > break your system. > > To customize Jackson with regard to this point, you can use either of the > two solutions below: > > @JsonIgnoreProperties(ignoreUnknown = false) > > objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, > false); > > > On Mon, Apr 3, 2017 at 7:22 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > 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. >
