Re: Representation<T> and Entity<T>

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 10 Apr 2007 12:01:27 -0400

On Apr 10, 2007, at 10:38 AM, Jerome Louvel wrote:

>> None of those helps when the return type can't be modified and the
>> media type isn't know in advance.
> In this rather unlikely case, it could simply rely on a wrapper
> POJO that
> would get annotated and would know how to "dynamically serialize" the
> wrapped POJO.
Its not an unlikely case, see APP, WebDAV, Amazon S3 etc.

>> I like the idea of being able to specify additional metadata like
>> language declaratively but you do run into a problem with annotation
>> syntax: as soon as you have more than one field in an annotation you
>> are forced to include the field names even when only specifying the
>> value of one field where all the others have defaults. E.g. with one
>> field you can write:
>> @MediaType("text/foo")
>> with two you can write:
>> @MediaType(mediaType="text/foo", language="en")
>> or
>> @MediaType(mediaType="text/foo")
>> but you can no longer write @MediaType("text/foo").
>> You can always add more single field annotations but then you get an
>> explosion of annotation classes.
> In my the version of the API I described, I identified only 15
> annotations:
> - Representation, Input, Output
> - Resource, Param|Context, Method, Status, Metadata
> - MediaType, Language, CharacterSet, Encoding, Expires,
> LastModified, Tag
> We may need a couple of enumeration, too. That seems far from an
> explosion
> ;)
I think you missed my point. Adding additional properties to an
annotation requires slightly different syntax even when those
additional properties have default values.

BTW, in other threads you've already suggested a number of additional
annotations (e.g. ParentRef, RedirectRef, @Location, ContentLocation,
Context) - as we explore use cases I'm sure that number would grow ;-).


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.