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:[email protected]]
Sent: 18 February 2009 15:15
To: Sergey Beryozkin; [email protected]
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
