Re: "Dual dispatch"

From: Stefan Tilkov <>
Date: Fri, 20 Apr 2007 23:14:36 +0200

On Apr 20, 2007, at 8:38 PM, Marc Hadley wrote:

> On Apr 20, 2007, at 1:00 PM, Stefan Tilkov wrote:
>> I meant two different formats for the same business logic and the
>> same Java return type.
>> So this would be:
>> @ProduceMime("application/invoice+xml")
>> @HttpMethod
>> Invoices getInvoices() {...}
>> @ProduceMime("application/invoice2+xml")
>> @HttpMethod
>> Invoices getInvoices2() {...}
> Yes, the TypeStreamingProvider would need to be aware of the MIME
> type and use the correct serialization.

OK; so what about

Invoices getInvoices() {...}


>>>> - 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?
> You could manage the serialization inside the method, e.g. you
> could return a custom javax.xml.transform.Source that outputs a
> wrapper <Invoices> element and then internally uses JAXB to
> marshall a set of Invoice beans. For small amounts of data you
> could just construct a String and return that.

So does this mean I can do the following?

String getLastComment() {...}

javax.xml.transform.Source getDocument() {...}

>>>> 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.
> Its sort of both, it enables a developer to write a plug-in for a
> particular type that is portable across JSR 311 implementations.
> The plug-in can be packaged with an application or separately. We
> called it an SPI since its an API for extending the capabilities of
> the runtime.

Does it really extend the runtime's capabilities? I'd argue that this
is part of the user API, albeit possibly part of the 20% segment.


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