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,
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
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,
I think it is important that we work toward a clearly stated goal here. You
originally recruited me to plug in Aegis to JAX-RS because, as I recall, the
DOSGi people wanted a way to use JAX-RS without the burden of JAX-B and
other related components.
Now, on the one hand, Aegis+Jettison
