On Apr 21, 2007, at 12:24 AM, Dhanji R. Prasanna wrote:
> I am curious, how is a TypeStreamingProvider intended to be
> registered to a type? Is there a registry of such serializers? Or
> does each @HttpMethod need to return a TypeStreamingProvider impl
> (as necessary)?
>
Its explained in the ServiceFinder Javadoc.
> I would favor the registry of externalizers discussed in another
> thread (registration with annotations), something like:
>
> @URITemplate(...)
> @Externalizer(Class<T>, Class<? extends
> TypeStreamingProvider<T>>) //example psuedo-signature
> public class InvoicesService {
> //..
> }
>
An annotation approach could also be good, in fact an annotation
could be used to generate the ServiceFinder configuration files
during apt processing.
>
> I would propose:
>
> @Produces(@MediaType("application/invoice+xml"), @MediaType
> ("application/json"), @MediaType(MediaTypes.TEXT_PLAIN)) //etc.
> @HttpMethod
> Invoices getInvoices() { ... }
>
All those @MediaType annotations in the @Produces look a little
superfluous.
>
> So does this mean I can do the following?
>
> @ProduceMime("text/plain")
> @HttpMethod
> String getLastComment() {...}
>
> @ProduceMime("application/xml")
> @HttpMethod
>
> javax.xml.transform.Source getDocument() {...}
>
>
> Hmm, so something like an "inline" serializer + http service-method?
> How would you distinguish between an raw entity (String xml) with
> an external serializer and a representation (Document xml)? Perhaps
> Jerome's suggestion of an @Output annotation has relevance here?
>
You don't need to distinguish, a String TypeStreamingProvider always
just dumps the String, same for other things like InputStream.
> > 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.
>
> I agree, it doesn't seem like part of the spi. I also feel the
> custom/portable serializers should be commonplace and not
> necessarily of the 20% segment. I can see users wanting to do some
> subtle modifications via custom type serializers quite often.
>
I suggest we don't worry too much for now about whether we call the
package spi or something else. I think we need to focus on refining
the approach first and then worry about finessing the naming later.
It sounds like there's general agreement that custom+portable
serializers is a desirable feature though.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s