tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Not the same behaviour between Johnzon and Jackson
Date Mon, 03 Apr 2017 07:49:17 GMT
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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message