cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Restating some JAX-RS debates
Date Mon, 07 Sep 2009 17:33:36 GMT
On Mon, Sep 7, 2009 at 1:20 PM, Sergey Beryozkin
<sergey.beryozkin@iona.com>wrote:

>
> Hi
>
> [1] +1 to b. yes it does, I haven't tried but users can wrap whatever
> providers they want into their custom JAXRS providers. I'd rather do a
> system test showing users they can do if they want.
>

I did the systest. If you think more testing is called for, let me know
what.



>
> possible pros : jackson will do natural JSON easily
> possible cons : it's convention-based, that is it thinks that json has to
> follow the natural convention; and having Aegis users who are working with
> Map/List based interfaces to download jackson seems a bit harsh - in OSGI
> they'll also need to install another bundle
>

Let's see what we hear from the users list about these Aegis users.


>
> [3] +1 to 'unqualified' Aegis for JSON but only when users have asked for
> it. I think it is a better solution than bringing a new dependency to CXF.
> Basically, if users are working with existing CXF DataBindings then they
> should be given an option to use then for creating JSON. So
> DataBindingJSONProvider can be told to produce 'unqualified' JSON in all
> cases (for Aegis, SDO, XMLBeans, etc). Not sure how it will work for cases
> when derived types are returned when Base is expected....
>
> Sergey
>
>
> bimargulies wrote:
> >
> > I am hoping to attract some comments from other members of the community
> > by
> > gathering a few threads of debate between Sergey and myself in one place.
> > If
> > I misrepresent his side of these arguments I'm sure he'll let me know. I
> > also plan to ask some questions on the user list.
> >
> > [1] The default JSON provider.
> >
> > I've been comparing the Jackson JSON provider to the JSONProvider in CXF.
> > I
> > see three possibilities:
> >
> > [a] Deprecate ours in favor of theirs
> > [b] Document the fact that Jackson works with CXF and write up the
> > tradeoffs.
> > [c] Do nothing.
> >
> > I would like to see us at least take door [b]. Our JSONProvider has some
> > issues: it consists of a combination of JAXB and Jettison. The latter has
> > bugs that keep coming up. The former poses issues for some users, or so I
> > am
> > told. Jackson has some advantages, I think. The most notable is an
> > annotation model that is small and straightforward for JSON production
> and
> > consumptin.
> >
> > [2] The role of data binding providers.
> >
> > I can see why users would find a lot of value in the data binding
> > providers
> > when their content type is XML. The existing data bindings are all in the
> > XML business; their various controls and options are all relevant. Work
> > users put into setting them up is largely relevant, it not always
> > sufficient
> > (e.g. @XmlRootElement requirements). However, I think that there are
> > caveats
> > that deserve discussion in our documentation. Marking a transient
> property
> > to be ignore, that's good all around. A production schema, on the other
> > hand, may well have XML constructs that are not friendly to some sort of
> > simple Javascript client.
> >
> > When we get to JSON, however, I'm much more skeptical. Even without the
> > various bugs encountered in Jettison, the JSON you get when you push a
> > complex pile of XML into Jettison is pretty convoluted. I offer a sort of
> > a
> > reduction argument: if the interface is a simple one, then no one needs a
> > complex data binding, and if it is a complex one, expecting to use what
> > comes out of the data binding + Jettison is likely to run into trouble.
> >
> > I'm not proposing to delete any code here, just to set expectations.
> >
> > [3] The role of Aegis in all of this
> >
> > Aegis has turned into a central point in these issues for several
> reasons.
> > First, we put effort into making Aegis work with JAX-RS, so that people
> > who
> > wanted to avoid JAXB had an alternative. Then we noticed that Aegis
> always
> > produces 'qualified' schemas. Then we noticed that Jettison's model of
> > namespace management doesn't work for this purpose. It requires a static
> > mapping of namespaces to prefixes, rather than a dynamic mapping as in
> XML
> > itself.
> >
> > So, my view is that we should push Jackson as a solution to a JAXB-less
> > mapping from Java to and from JSON. The alternative would be to invent
> > 'unqualified' Aegis. (a) I don't know if I have time, (b) I fear that it
> > will only expose a next layer of things people don't like, like the extra
> > layer of elements in Aegis maps. Sergey is unpersuaded. Anybody else care
> > to
> > toss an opinion into the right?
> >
> > If someone else wants to jump on an option to make Aegis unqualified,
> > don't
> > think for a moment that I'll protest.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Restating-some-JAX-RS-debates-tp25329761p25333768.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>

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