tomee-users mailing list archives

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

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