On Apr 21, 2007, at 6:37 PM, Marc Hadley wrote:
> On Apr 20, 2007, at 5:14 PM, Stefan Tilkov wrote:
>>
>> OK; so what about
>>
>> @ProduceMime("application/invoice+xml,application/json,text/plain")
>> @HttpMethod
>> Invoices getInvoices() {...}
>>
> That would work too, the TypeStreamingProvider would need to look
> at the Accept header in the request to determine the format to use.
My suggestion is to add a feature for this to the registry - i.e. the
key to find the right type serializer should not only be the type,
but also the media type (or only one of them). For example, the
default way to convert objects to and from XML would be JAXB when the
JAXB serializer is registered for application/xml. For a type Person,
I could register a handler for {Person.class, "text/x-vcard"}, for
{"application/json"}, some generic Object-to-JSON mapper.
>
>>
>> So does this mean I can do the following?
>>
>> @ProduceMime("text/plain")
>> @HttpMethod
>> String getLastComment() {...}
>>
>> @ProduceMime("application/xml")
>> @HttpMethod
>> javax.xml.transform.Source getDocument() {...}
>>
> Yes.
>
Cool :-)
Stefan
> Marc.
>
>>>>>
>>>>>> 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.
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>