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?
Let me ask you the other question. If users have already done Aegis, why would they want to bring in Jackson ? 'unqualified' Aegis will do exactly what they want too, as far as dealing with explicit collections/maps is concerned cheers, Sergey
Not to mention the fact that Tatu is likely to prove responsive in case of need.