On Mon, Apr 6, 2009 at 6:57 PM, Stephen Duncan Jr
<stephen.duncan_at_gmail.com> wrote:
> I'm prototyping some use of JAX-RS and JSON. I'm trying to use Jersey and
> Jackson (http://jackson.codehaus.org/). I'd like to bring over a particular
> issue I'm facing with this that I brought up on the Jackson user mailing
> list:
> http://archive.codehaus.org/lists/org.codehaus.jackson.user/msg/b20ce4ed0904061253w38bcaa0crccd0fff3803f3390@mail.gmail.com
>
> To summarize: Jackson has a JAX-RS Provider implementation. However, since
> Jackson can convert POJOs to JSON, it essentially registers itself to handle
> any object where the media-type is application/json. What I want, however,
> is the flexibility to still return or process JSON through alternate means
> when it's appropriate: as StreamingOutput, as a String, or as some other
> libraries JSON object model.
...
One additional thought regarding this: I was thinking that maybe there
should be (or is? apologies if I missed it) a way to define
precedence/priority for content providers. Since some providers are
very specific (like one for StreamingOutput, for example), they could
have higher precedence for handling that type. And other more generic
ones (like Jackson-based, anything is potentially mappable) would be
used if more specific ones are not found.
For what it's worth, it looks like other generic content providers are
based on JAXB, which requires a root element annotation
(@XmlRootElement or @XmlType), and that is enough to eliminate
overlapping problems with types like StreamingOutput, String,
InputStream and byte[].
-+ Tatu +-