Restating some JAX-RS debates

[Benson Margulies <bi...@gmail.com>]

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.

Re: Restating some JAX-RS debates

[Benson Margulies <bi...@gmail.com>]

On Mon, Sep 7, 2009 at 1:20 PM, Sergey Beryozkin
<se...@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.
>
>

Re: Restating some JAX-RS debates

[Sergey Beryozkin <se...@iona.com>]

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. 

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

[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.