They don't have to wrap it. There's a full JAX-RS 1.0 provider provided. I added a test for our cooperation with it to the systests.
Why don't we just endorse it over our on JSON provider? It makes cleaner JSON, and is smaller, lighter, faster and more flexible. On Sun, Sep 6, 2009 at 6:11 PM, Sergey Beryozkin <sbery...@progress.com>wrote: > Users can easily wrap Jackson if they prefer. We can add a property to > existing providers which will allow for namespaces be dropped altogether > during the serialization if users prefer to parse JSON manually. > > Cheers, Sergey > > -----Original Message----- > From: Benson Margulies [mailto:bimargul...@gmail.com] > Sent: 05 September 2009 22:40 > To: CXF Dev > Subject: Possible alternative source of JSON > > http://wiki.fasterxml.com/JacksonInFiveMinutes > > It looks to me as if a Jackson 'provider' would be a pretty > straightforward > construction. To be clear, there's be no CXF DataBinding in the process > at > all. Jackson maps pojos to JSON and vica versa. > > The plus side of this is that it would yield, if successful, 'natural' > json, > unencrusted with namespace glop, in both directions. > > The minus side of this would be that it doesn't help those people who > want a > JSON JAX-RS endpoint as a sort of instant side-effect of their > preexisting > stack of JAXB @nnotations or Aegis XML files or whatever. > > Personally, I think that I'd be coding something a whole lot more useful > by > adding this than by putting more lipstick on the pig of producing and > consuming extremely ugly JSON via Aegis. > > Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already > does the job, why do all that work? > > Not to mention the fact that Tatu is likely to prove responsive in case > of > need. >
