Hi Stephen,
This is a known issue in JAX-RS.
I think there is a way to fix this in Jersey by sorting the message
body readers/writers such that readers/writers with the most specific
generic type occur first and thus the isWriteable/isReadable if the
more specifc generic types are called first. (Such general sorting is
non-trivial for complex types, and there may be more than one
solution, but for Class types it is easy).
Thus readers/writers for String or StreamOutput would occur before
Object (which is what the Jackson JSON readers/writers support).
Could you log an issue?
Thanks,
Paul.
On Apr 7, 2009, at 3:57 AM, Stephen Duncan Jr 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.
>
> What's the best way to acheive this? In the post I linked to, I
> speculated about some sort of delgating provider implementation. Is
> there some other mechanism in JSR-311? Or in Jersey?
>
> (As a side note: I'm currently using the jersey-spring integration
> to wire things together and to register the Jackson provider, but
> I'm open to alternate techniques if it solves this problem).
>
> --
> Stephen Duncan Jr
> www.stephenduncanjr.com