Hi Guys,
Thanks for the quick responses.
Here's an example of what I'm talking about. Let's say I wanted to expose an
API for blog posts, and I wanted reasonable responses in both XML and JSON
format.
The XML should probably look like:
<post>
<title>My Blog Post</title>
<text>Test Blog</title>
<author>Some Guy</author>
<comments>
<comment>
<author>Some Other Guy</author>
<text>Test Comment</text>
</comment>
</comments>
</post>
And the JSON should probably look like:
{
title: "My Blog Post",
text: "Test Blog",
author: "Some Guy",
comments: [{
author: "Some Other Guy",
text: "Test Comment"
}]
}
The bean should look like:
class Post {
private String title;
private String text;
private String author;
private List<Comment> comments;
...
}
These are just the resonably intuitive response formats for each format. The
problem is that the packaged providers (JSONProvider and JAXBElementProvider)
cannot provide both formats from the same bean without some ugly hacks.
Getting the bean to output the correct XML means that you end up with JSON that
looks like this:
{
title: "My Blog Post",
text: "Test Blog",
author: "Some Guy",
comments: {
comment: [{
author: "Some Other Guy",
text: "Test Comment"
}]
}
}
And getting the bean to output the correct JSON means that you end up with XML
that looks like this:
<post>
<title>My Blog Post</title>
<text>Test Blog</title>
<author>Some Guy</author>
<comment>
<author>Some Other Guy</author>
<text>Test Comment</text>
</comment>
</post>
The problem is that because the JSON provider piggybacks off the JAXB XML
annotations, you only get indirect control of the way the bean is marshalled,
and if you need tight control over both the XML and JSON representations,
things get either messy or impossible.
My solution to this is to replace the standard JSON provider with my own
implementation. I was curious about 2 things
1) Do you guys know of any jaxb-quality, annotation-driven JSON serializers?
2) Are you guys interested in replacing the existing JSON provider, or making
an alternative one available that allows a bit more control over how the JSON
is rendered?
Thanks,
Gary
-----Original Message-----
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 10 February 2009 13:23
To: Sergey Beryozkin; dev@cxf.apache.org
Subject: Re: JSON in CXF
I think going with ContextResolver<JAXBContext> may be a workable workaround,
but I'd like to ask for some clarification in meantime...
I've talked to Dejan who is a Jettison commiter and perhaps Jettison can get
enhanced a bit in some time to deal with such cases natively with the help of
some additional configuration (which will obvioulsy be available at a
JSONProvider level). However we'd like to get some additional clarifications
> Gives XML like:
>
> <foo>
> <values>
> <value>foo</value>
> <value>bar</value>
> </values>
> </foo>
>
> And json like:
> {foo: {values: {value: ["foo", "bar"]}}}
>
> Whereas really, if this is an API that you want to publicize, you really want:
>
> {values: ["foo", "bar"]}
Gary - is it a typical requirement for developers producing JSON ? How it can
be characterized ? We can see that a root element needs to be dropped and names
of children of an element marked with @XmlElementWrapper need to be ignored
too. Can you please explain a bit more ? Any links will be appreciated.
Likewise, few more samples with slightly different object graphs but showing
the same pattern in action would help us to come up with a new feature
enhancement request for Jettison
Thanks, Sergey
>
> ----- Original Message -----
> From: "Tong, Gary (FID)" <gary.t...@morganstanley.com>
> To: <dev@cxf.apache.org>
> Sent: Tuesday, February 10, 2009 11:24 AM
> Subject: RE: JSON in CXF
>
>
> I think it's a limitation of the underlying JSON library. Something like:
>
> @XmlRootElement
> public class Foo {
> @XmlElementWrapper(name="values")
> @XmlElement(name="value")
> private List<String> values
> }
>
> Gives XML like:
>
> <foo>
> <values>
> <value>foo</value>
> <value>bar</value>
> </values>
> </foo>
>
> And json like:
> {foo: {values: {value: ["foo", "bar"]}}}
>
> Whereas really, if this is an API that you want to publicize, you really want:
>
> {values: ["foo", "bar"]}
>
> Seems like the JSON is generated via JAXB and an XMLStreamWriter,
> which unfortunately is too limited to provide real control over the JSON.
>
> Thanks,
> Gary
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sbery...@progress.com]
> Sent: 10 February 2009 10:48
> To: dev@cxf.apache.org
> Subject: Re: JSON in CXF
>
> Hi Gary
>
>> JSON via JAXB definitely leaves something to be desired.
>
> Do you reckon it's the limitations of the underlying JSON library that
> we use (Jettison) or do you refer to the insufficient number of hooks for our
> JSON JAXRS reader/writer whiich would help in producing a better quality JSON
> ?
>
> Can you post some examples please - I hope it will help us to improve
> what we have
>
> Thanks, Sergey
>
> Hi guys,
>
> I really like how CXF provides both JSON and XML out of the box.
> However, after working with the JSON serializer a bit, it's obvious
> that the JAXB annotations translate poorly to JSON, and that while you have
> great control over XML via JAXB, JSON via JAXB definitely leaves something to
> be desired.
>
> Do you guys know of any jaxb-quality, annotation-driven JSON serializers?
>
> Cheers,
> Gary
>
> ----------------------------------------------------------------------
> ---- This is not an offer (or solicitation of an offer) to buy/sell
> the securities/instruments mentioned or an official confirmation.
> Morgan Stanley may deal as principal in or own or act as market maker
> for securities/instruments mentioned or may advise the issuers. This
> is not research and is not from MS Research but it may refer to a
> research analyst/research report. Unless indicated, these views are
> the author's and may differ from those of Morgan Stanley research or
> others in the Firm. We do not represent this is accurate or complete
> and we may not update this. Past performance is not indicative of
> future returns. For additional information, research reports and
> important disclosures, contact me or see
> https://secure.ms.com/servlet/cls. You should not use e-mail to
> request, authorize or effect the purchase or sale of any security or
> instrument, to send transfer instructions, or to effect any other
> transactions. We cannot guarantee that any such requests received via e-mail
> will be processed in a timely manner. This communication is solely for the
> addressee(s) and may contain confidential information. We do not waive
> confidentiality by mistransmission. Contact me if you do not wish to receive
> these communications. In the UK, this communication is directed in the UK to
> those persons who are professional and eligible counterparties (as defined in
> the UK Financial Services Authority's rules).
>
>
> ----------------------------------------------------------------------
> ---- This is not an offer (or solicitation of an offer) to buy/sell
> the securities/instruments mentioned or an official confirmation.
> Morgan Stanley may deal as principal in or own or act as market maker
> for securities/instruments mentioned or may advise the issuers. This
> is not research and is not from MS Research but it may refer to a
> research analyst/research report. Unless indicated, these views are
> the author's and may differ from those of Morgan Stanley research or
> others in the Firm. We do not represent this is accurate or complete
> and we may not update this. Past performance is not indicative of
> future returns. For additional information, research reports and
> important disclosures, contact me or see
> https://secure.ms.com/servlet/cls. You should not use e-mail to
> request, authorize or effect the purchase or sale of any security or
> instrument, to send transfer instructions, or to effect any other
> transactions. We cannot guarantee that any such requests received via e-mail
> will be processed in a timely manner. This communication is solely for the
> addressee(s) and may contain confidential information. We do not waive
> confidentiality by mistransmission. Contact me if you do not wish to receive
> these communications. In the UK, this communication is directed in the UK to
> those persons who are professional and eligible counterparties (as defined in
> the UK Financial Services Authority's rules).
--------------------------------------------------------------------------
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation. Morgan Stanley
may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers. This is not
research and is not from MS Research but it may refer to a research
analyst/research report. Unless indicated, these views are the author’s and may
differ from those of Morgan Stanley research or others in the Firm. We do not
represent this is accurate or complete and we may not update this. Past
performance is not indicative of future returns. For additional information,
research reports and important disclosures, contact me or see
https://secure.ms.com/servlet/cls. You should not use e-mail to request,
authorize or effect the purchase or sale of any security or instrument, to send
transfer instructions, or to effect any other transactions. We cannot guarantee
that any such requests received via e-mail will be processed in a timely
manner. This communication is solely for the addressee(s) and may contain
confidential information. We do not waive confidentiality by mistransmission.
Contact me if you do not wish to receive these communications. In the UK, this
communication is directed in the UK to those persons who are professional and
eligible counterparties (as defined in the UK Financial Services Authority’s
rules).
