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: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson
Date Mon, 03 Apr 2017 10:42:48 GMT
2017-04-03 12:37 GMT+02:00 COURTAULT Francois <
Francois.Courtault@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:rmannibucau@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.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.
> >
> ________________________________
>  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