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:[email protected]]
Sent: lundi 3 avril 2017 09:49
To: [email protected]
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 <[email protected]
>:
> 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:[email protected]]
> Sent: lundi 3 avril 2017 09:02
> To: [email protected]
> 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.
