RE: Representation<T> and Entity<T>

From: Jerome Louvel <>
Date: Tue, 10 Apr 2007 14:47:49 +0200


> If there is a header that is decided dynamically (based on
> some computation) you cant specify it with static metadata. I
> would much prefer the Representation<T> wrapper to forcing
> adding the metadata to the returned entity.

Yes you can. If you annotate your getModificationDate() method with the
@LastModifiedDate annotation, then your method can return a data that
changes dynamically. Same for other metadata.

> I certainly would
> like to have the flexibility to use arbitrary domain objects
> (that may be written by other developers) as my content
> payload and register serializers for them. This is not
> uncommon in large projects.

This is a useful case. I need to think more about how (de-)serialization of
representation POJOs should be supported. But, if you control your resource
POJO, then you can add annotated "serialization" method like:

public MyResource {

        Foo foo; // the representation domain object to reuse

        public Document toXML() {
                // logic to generate a DOM document
            // from the current "foo" instance.

        public JSONObject toJSON() {
                // logic to generate a JSON object
            // from the current "foo" instance.

> I dont suggest getting rid of the entity-level annotations. I
> agree they are a useful addition and generally like the idea.
> I feel however, that the broader use case calls for external
> (registered) serializers as you call them, for reasons
> mentioned above, and is a good alternative.
> You could capture this with a static binding too:
> @Externalizer(MyPojo.class, MyPojoExternalizer.class)
> @URITemplate(...)
> public class RestfulService {
> //..
> }

Isn't the solution proposed above even simpler?

> @Method
> public void post(
> @Input InputStream in,
> @Context("serverInfo.address") String serverAddress,
> @Context("serverInfo.userAgent") String userAgent){
> ...
> }
> We would just need to standardize the list of property names.
> I'd go a step further and make them typesafe enums.

Agreed, that sounds useful.

> > Personally, I don't see the need of either the
> > Representation class or the Entity interface
> > in our JSR API.

> I agree viz. Entity<T>, however as stated above, I believe an
> optional Representation<T> artifact would be an elegant and
> flexible solution to dynamic metadata, especially in cases
> where I cant/dont want to annotate entity classes.

Do you still this so after considering the solution above?

Best regards,