Hi Gary
I think I understand the problem better. As far as Jettison is concerned, I
reckon we can open an enhancement request.
1) Do you guys know of any jaxb-quality, annotation-driven JSON serializers?
I'm not a JSON expert at all so I can't recommend. I know Jersey does JSON so you might want to check, though, I'd not be surprized
if a feature like the one you're asking about were implemented with the help of a custom configuration option, something we'd
hopefully see in Jettison 1.0.2 or with the help of ContextResolver<JAXBContext>.
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?
I'd happy to consider replacing the existing one with a better quality one if it were JAXB driven as a number of users depend on it
being JAXB aware, such that we can also preserve the existing features like the ability to schema-validate, which should not be a
problem if it were JAXB-aware.
Likewise I'd be happy to consider shipping an alternative JSON provider, though we're a bit conscious about not introducing new
dependencies which such a new provider might bring in.
Thanks, Sergey
----- Original Message -----
From: "Tong, Gary (FID)" <gary.t...@morganstanley.com>
To: <dev@cxf.apache.org>
Sent: Tuesday, February 10, 2009 3:08 PM
Subject: RE: JSON in CXF
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).
