Re: "Dual dispatch"

From: Stefan Tilkov <>
Date: Fri, 20 Apr 2007 19:00:34 +0200

On Apr 20, 2007, at 6:24 PM, Marc Hadley wrote:

> On Apr 20, 2007, at 11:50 AM, Stefan Tilkov wrote:
>> Taking an example from Paul:
>> @ProduceMime("application/vnd.blinksale+xml")
>> @HttpMethod
>> Invoices getInvoices() {
>> // ...
>> }
>> As Paul wrote, this assumes the "Invoices" JAXB bean has been
>> created.
>> Some questions:
>> - Does this mean there can only be one XML "serialization" of
>> "Invoices"?
> No, you could have another method:
> @ProduceMime("application/somethingelse+xml")
> @HttpMethod
> SomeOtherClass getInvoices() {...}

I meant two different formats for the same business logic and the
same Java return type.
So this would be:

Invoices getInvoices() {...}

Invoices getInvoices2() {...}

>> - How do I provide an alternative format, let's say JSON, YAML or
>> HTML?
> For JSON:
> (i) Add a method annotated with @ProduceMime("application/json")
> (ii) Register a TypeStreamingProvider to do the serialization for
> the returned type
> Same for the other media types. Note that you can also support
> different formats using separate classes with the same URI
> template, the runtime can choose the correct class based on the
> value of the Accept header and the @ProduceMime annotations.
>> - Is there a way around the slightly strange "Invoices" JAXB bean,
>> i.e. can I have an InvoicesResource and a class Invoice, but avoid
>> "Invoices"?
> Not sure I understand, but JAXB lets you customize class names as
> desired.

Sorry, that was not really understandable. What I meant was how do I
mix JAXB beans with "manual" XML creation, i.e. is there a way for me
to write out the surrounding XML without having to create a bean for
"Invoices". In case you consider this a weird use case, let me
rephrase again: is the only non-POJO-based way of generating output
via the TypeStreamingProvider?

>> I believe we probably need some way for a "dual dispatch" style of
>> consuming and producing a representation from an object, based on
>> the Java type *and* the MIME content type - i.e. there may be more
>> than one content type for a given Java type, and more than one
>> Java type for a given content type. I don't believe the current
>> proposal addresses this?
> A TypeStreamingProvider can produce/consume multiple MIME types for
> a single Java type so that is covered.

I see; this was not clear to me -- I thought the SPIs were mainly
there to support different containers while this seems to be an
application-level API.


> Marc.
> ---
> Marc Hadley <marc.hadley at>
> CTO Office, Sun Microsystems.