Hi Gary
Thanks for this information. What you did looks neat.
I'm just thinking that given that Jettison ships JSON objects in its own package we have a case now for improving our JSONProvider:
if @JsonObject class annotation is available then just use the JSONObject serialization, otherwise fallback to JAXB.
In meantime,
1) Two-way serialization. Currently it's only bean -> JSON but not the
other way around.
2) Reflection caching. Currently all reflection happens in the middle of
serialization. Breaking it up into reflection + serialization phases as
JAXB does it would speed things up considerably.
3) Ability to switch between field/method accessors (currently it only reads
fields)
As well as some features that could be really useful such as:
1) Pluggable annotation adapters that can be used to read directly from JAXB
annotations
2) Type adapters that will allow custom marshalling/unmarshalling, although
this could also be done via getters/setters
What's the interest level in putting something like this into CXF?
I think it would be good if we had a solid JSON implementation which could work nicely without JAXB annotations being involved. We
might also need to evaluate Jackson[1] and see how Jettison evolves. Now that you described it, the idea of using Jettison to handle
@JSONObject annotations seems quite attractive to me, such that we can handle beans which may or may nnot be JAXB-aware...
I'd honestly be interested in evaluating your JSON provider, whenever you feel it's ready for 'action' :-). Then, depending on where
Jettison will be at that stage and how it has evolved we can discuss things again and make the right decision.
many thanks for your input, Sergey
[1] http://jackson.codehaus.org/
----- Original Message -----
From: "Gary Tong" <gdevn...@googlemail.com>
To: <dev@cxf.apache.org>
Sent: Thursday, February 26, 2009 12:47 AM
Subject: Re: JSON in CXF
Hi Sergey,
Sorry it too so long to reply to this.
I ended up writing my own converter for JSON that uses its own annotations
seperate from JAXB. It's a pretty quick implementation, and only does what
I need it to do. It depends on the JSON objects from json.org, which are
also included in Jettison under a different package. The annotations can be
used alongside JAXB like so:
@XmlRootElement(name = "response")
@JsonObject
public class MyResponse {
@XmlAttribute
@JsonField
private boolean success;
@XmlElement(name = "msg")
@JsonField(name = "msg")
private String message;
@XmlElementWrapper(name = "errors")
@XmlElement(name = "error")
@JsonField(name = "errors", required = true)
private List<String> errors;
...
}
This will produce this JSON:
{success: true, msg: "Test Message", errors: ["a", "b"]}
And this XML:
<response success="true"><msg>Test
Message</msg><errors><error>a</error><error>b</error></errors></response>
Since this was written only for personal use, it's a fair bit aways from
being a full-featured library. Stuff that needs to be done before public
consumption:
1) Two-way serialization. Currently it's only bean -> JSON but not the
other way around.
2) Reflection caching. Currently all reflection happens in the middle of
serialization. Breaking it up into reflection + serialization phases as
JAXB does it would speed things up considerably.
3) Ability to switch between field/method accessors (currently it only reads
fields)
As well as some features that could be really useful such as:
1) Pluggable annotation adapters that can be used to read directly from JAXB
annotations
2) Type adapters that will allow custom marshalling/unmarshalling, although
this could also be done via getters/setters
What's the interest level in putting something like this into CXF?
Cheers,
Gary
-----Original Message-----
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 18 February 2009 15:15
To: Sergey Beryozkin; dev@cxf.apache.org
Subject: Re: JSON in CXF
Hi Gary
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.
Do you have any concrete idea about the alternative JSON provider ? If you
do then lets discuss it please...
Thanks, Sergey
