Re: "Dual dispatch"

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Sat, 21 Apr 2007 12:44:41 -0400

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

> 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 Hadley <marc.hadley at>
CTO Office, Sun Microsystems.