You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by COURTAULT Francois <Fr...@gemalto.com> on 2017/04/03 07:00:43 UTC
Not the same behaviour between Johnzon and Jackson
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 ?
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.
Re: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-04-03 15:09 GMT+02:00 COURTAULT Francois <
Francois.Courtault@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:dcominottim@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 <rm...@gmail.com>
> wrote:
>
> > 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.
>
RE: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson
Posted by COURTAULT Francois <Fr...@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?
Best Regards.
-----Original Message-----
From: Danilo Cominotti Marques [mailto:dcominottim@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 <rm...@gmail.com>
wrote:
> 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.
Re: Not the same behaviour between Johnzon and Jackson
Posted by Danilo Cominotti Marques <dc...@gmail.com>.
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 <rm...@gmail.com>
wrote:
> 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.
> >
>
RE: [+SPAM+]: Re: [+SPAM+]: Re: Not the same behaviour between
Johnzon and Jackson
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello Romain,
Forget my last post, I forgot to add @Valid for my POJO, in the JAX-RS method signature.
With this annotation, I got a ConstraintViolationException.
So sorry...
Best Regards.
-----Original Message-----
From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Sent: lundi 3 avril 2017 12:43
To: users@tomee.apache.org
Subject: [+SPAM+]: Re: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson
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.
>
________________________________
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.
Re: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
>
RE: [+SPAM+]: Re: Not the same behaviour between Johnzon and Jackson
Posted by COURTAULT Francois <Fr...@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 ?
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.
Re: Not the same behaviour between Johnzon and Jackson
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
>
RE: Not the same behaviour between Johnzon and Jackson
Posted by COURTAULT Francois <Fr...@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).
- to follow the Must-Ignore policy (eg if there are additional data in the Entity: others than the ones expected are there)
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.
Re: Not the same behaviour between Johnzon and Jackson
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
>
RE: Not the same behaviour between Johnzon and Jackson
Posted by COURTAULT Francois <Fr...@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 ?
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.
Re: Not the same behaviour between Johnzon and Jackson
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
>
RE: Not the same behaviour between Johnzon and Jackson
Posted by COURTAULT Francois <Fr...@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.
Re: Not the same behaviour between Johnzon and Jackson
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
>