Re: Summary: Representation<T> and Entity<T>

From: Dhanji R. Prasanna <>
Date: Thu, 12 Apr 2007 20:30:32 +1000

On 4/12/07, Heiko Braun <> wrote:
> On Thu, 12 Apr 2007 18:20:23 +1000
> "Dhanji R. Prasanna" <> wrote:
> > On 4/12/07, Heiko Braun <> wrote:
> > >
> > Couldnt you mark it transient?
> That's right. But it it simple? Take the possible way's to express this
> times the number of representations and it becomes quiet complex.

I take your point. Im not fond of having this metadata within the entity
object anyway (I understand this to be an alternative case). If you read
earlier in the thread you will see suggestions for something like:

@MediaType("text/xml") //produced content type
public MyEntity serviceMethod(@MediaType("text/plain")
MyEntityForConsumption) //consumed content type

...which liberates the POJO from having anything to do with the framework.
In this case you'd have (and I encourage) a separate registry of
serializers. I believe Jerome was referring to the case where an entity may
produce its own representation via the use of toString(), toJson() etc.

Fwiw, I dont believe the latter is the mainstream (atleast not the only one)

The reason why i addressing this is that i favor Representation<T> to
> contain meta-data, clearly separated from the actual payload.

Yep, I think we're all quite happy with Representation<T> as a wrapper for
returned metadata but NOT as the canonical case (the exemplary case should
prefer the use POJOs alone as I recall). Atleast this is the story so far,
feel free to add your own twists =)

"Entity<T> and Representation<T> encapsulate the type to be
> parsed/serialized, with common meta-data of the request and response,
> respectively without requiring modification of that type."

Not to put words in anyone's mouth, but so far Jerome and I have objected to
the use of Entity<T> as a metadata wrapper. cf. earlier in this thread:

"The discussion is around whether jsr311 can offer both granular metadata
injection points (fine grained @[MetadataItem] on method params--which may
do some parsing/type coercion) as well as a more raw glob of request
metadata: HttpRequestContext or (the less-http-gnostic) EntityMetadata."

...and Marc:

"- 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."