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: Jackson vs Johnzon JAX-RS provider
Date Fri, 31 Mar 2017 15:19:50 GMT
2017-03-31 17:17 GMT+02:00 COURTAULT Francois <
Francois.Courtault@gemalto.com>:

> Hello Romain,
>
> What do you mean exactly by "lack of modelling of the json model" ? Do you
> think about Java to JSON mapping which is not standardized yet but should
> be soon ?
>

If you cant almost map 1-1 between the json and your pojo (there are a few
exception like map sinks etc but overall idea is there) then you need to
abuse of trait like feature or views etc. All these features which look
fancy generally lead to a hard to maintain and understand code which is not
something I would recommand if you have the choice (sometimes not like
integrating with 3rd party closed systems but it is rare).


> Do you think that the JSON-B specification (JSR 367) will cover this topic
> and will address all the issues ?
> Tell me, if I am wrong, but Johnzon will follow the JSON-B spec, right ?
>
>
It does (actually an early release included it: johnzon-jsonb module),
another release is coming very soon with a more up to date spec.


> Best Regards.
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: vendredi 31 mars 2017 16:57
> To: users@tomee.apache.org
> Subject: Re: Jackson vs Johnzon JAX-RS provider
>
> Hi Fran├žois,
>
> jackson has a few more advanced feature but I'll say a word on it at the
> end.
> In term of perf it is a bit faster but if you use it for JAXRS then HTTP
> is so slow compared to json roundtrip than you dont care of which provider
> you use (in term of scale).
> jackson has more binding support, the most known are yaml and jaxb...but
> that's out of json
>
> Now johnzon is jsonp based, very light and Apache powered compared to
> jackson (to answer to the implicit "why johnzon in tomee").
>
> About the first point: most of the very advanced features are due to a
> lack of modelling of the json model so before jumping on them you should ask
> yourself: do I need it or am I messing up my app? in 80% of the case it is
> the last one from experience.
>
>
>
> 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-03-31 16:39 GMT+02:00 COURTAULT Francois <
> Francois.Courtault@gemalto.com>:
>
> > Hello,
> >
> > Any reason to prefer Jackson instead of Johnzon (default JAX-RS
> > provider in TomEE 7.x ) like:
> >
> > -          Performance
> >
> > -          Functionality (@JsonInclude, @JsonIgnoreProperties with no
> > equivalence in Johnzon)
> >
> > -          Others ....
> > ?
> >
> > 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