Paul gave a good answer already, but just some additional notes:
On Mon, Aug 16, 2010 at 11:24 PM, Tauren Mills <tauren_at_groovee.com> wrote:
> Tatu,
>
>> Yes, and that's where registering typed handled (MessageBodyWriter)
>> would make things easier.
>> Otherwise you will have to manually handle mapping of requested type
>> into appropriate converter, which can add lots of code for larger
>> systems.
>
> If I create a MessageBodyWriter<ByteArrayOutputStream> with
> @Produces("application/pdf"), then any Resource method that returns
> ByteArrayOutputStream with the PDF mimetype will use the writer,
> correct? Is this what you mean by "registering a converter"? It looks
> like the entity-provider sample does this.
Yes I think so.
> But what do I do if I don't want to return a ByteArrayOutputStream and
> instead want to return a Response? For instance, getJSON() below
Actually, to make registered handlers work well you should neither
return "raw" types (byte array) nor data format specific ones
(ObjectNode or JsonObject), but rather POJOs that framework can
convert.
Those will then be passed to writers. So you should not define
getJSON() (and similar) at all, but rather constructing object and let
format-specific MessageBodyWriter handle conversion.
The alternative here is to do it all yourself and not defining any
MessageBodyWriters; and that is when you would do conversion first and
wrap it within StreamingOutput or return as byte[] (which usually will
not be further processed by default MessageBodyWriters).
I think that what Paul said (apologies if I am wrong) is that it is ok
to have multiple methods mapped to single URL, as long as they produce
different content types; and that this is the way to go so that Jersey
can match content type with method, instead of application code having
to (try to) do that.
But that there is still just one external endpoint to access, just
gets dispatches to one of alternative Java methods.
-+ Tatu +-