dev@jsr311.java.net

Summary: Representation<T> and Entity<T>

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 10 Apr 2007 16:28:48 -0400

On Apr 10, 2007, at 2:41 PM, Ryan Heaton wrote:
>
> I'd like to offer my input, but I'm kind of buried by the complexity
> of the thread. It's difficult for me to determine what level of
> consensus we've reached (if any) and what that consensus is.
>
> Could someone sum up the current status of this thread?

I don't know that we've reached any consensus yet but I'll take a
stab at some assertions and we'll see if anyone objects:

- Entity<T> and Representation<T> should only be used in examples
when the functionality they offer is required, where possible
examples should use the bare T
- Entity<T> could be replaced in all instances by a more granular
approach, e.g. we could define a @MediaType annotation for method
parameters that would cause the value of the Content-Type request
header to be passed as the value of the annotated parameter.
- Regardless of whether Entity<T> is retained or not we need a
general purpose mechanism to access request information - said
another way we shouldn't have to define a separate annotation for
each piece of metadata.
- Representation<T> is useful for cases where metadata can't be
determined statically
- For cases where metadata can be determined statically then
annotations should be used instead of Representation<T>. Two
approaches are possible: annotate the type and/or annotate the usage
of the type. Of the two approaches, the latter is more flexible since
it can be applied to types outside the control of the user.
- We need a standard mechanism to plug-in [de]serializers for
arbitrary user-defined types. The JSR specification will define a set
of types that will be supported without user supplied [de]serializers.

Marc.

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