cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tong <>
Subject Re: JSON in CXF
Date Thu, 26 Feb 2009 00:47:26 GMT
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, which are
also included in Jettison under a different package.  The annotations can be
used alongside JAXB like so:

@XmlRootElement(name = "response")
public class MyResponse {
  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

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

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

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
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?


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message