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
@ProduceMime("application/invoice+xml,application/json,text/plain")
@HttpMethod
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?
@ProduceMime("text/plain")
@HttpMethod
String getLastComment() {...}
@ProduceMime("application/xml")
@HttpMethod
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.
Stefan
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>