Re: "Dual dispatch"

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 20 Apr 2007 14:38:18 -0400

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.

>>> - 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.

>>> 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


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