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:
@ProduceMime("application/invoice+xml")
@HttpMethod
Invoices getInvoices() {...}
@ProduceMime("application/invoice2+xml")
@HttpMethod
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.
Thanks.
Stefan
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>