dev@jsr311.java.net

RE: Representation<T> and Entity<T>

From: Jerome Louvel <jerome.louvel_at_noelios.com>
Date: Thu, 12 Apr 2007 10:35:41 +0200

Marc,

> > I propose to unify Entity, HttpRequestContext and
> > HttpResponseContext into a
> > single Context class that could be inject at the local variable
> > level and
> > eventually at the parameter level.
> >
> You mean like HttpContext :-). You can already write:

I mean a merging and simplification of:
 - HttpContext, HttpRequestContext, HttpResponseContext interfaces
 - Created, HttpResponse, NotModified, TemporaryRedirect classes
into a single Context or RWSContext (so match JAXBContext naming) class.
 
> @UriTemplate(...)
> public class SomeResourceClass {
>
> @Resource
> HttpContext context;
>
> ...
> }
>
> The context field is initialized via injection when an instance is
> created. The @Resource annotation is one of the common annotations
> defined by JSR 250 and given that one can expect that this
> annotation will be used in JSR 311 application classes I think we need to
> avoid using the same name for any of our annotations :-(.

This is an unfortunate name collision indeed... I suggest to use
@WebResource as the annotation name instead. We could also use this 'Web'
prefix for other related annotations like @WebMethod.

> > It would be a two-way communication point with the API
> > implementation and
> > could contains methods such as:
> >
> > get/setInput(): Representation<T>
> > get/setOutput() : Representation<T>
> >
> That is in line with the design of the context interfaces though
> currently HttpRequestContext and HttpResponseContext manage the
> request and response separately. We can discuss whether that is more
> or less confusing than mixing the methods in a single interface.
> Personally I quite like the separation.

Merging 7 artifacts into a single class should really simplify the API
without loosing any feature. As we are now explicitely processing a
request/response cycle in this JSR, contrary to the Servlet API or Restlet
API, we can afford to abstract and simplify this aspect. This is due to the
fact that a WebResource will we the last handler in the request processing
chain.

Best regards,
Jerome