Changshin Lee wrote:
> Servlet's Request and Response model is actually a firm basis to build a
> message processor on top of, but I'd like to point out that the model is
> not designed (solely) for the REST architecture. It seems that Pros
> above help integration based on the widespread technology, Servlet. On
> the other hand, Cons imply that we may need to make a brand-new start
> for better groundwork. The current implementation seems:
>
> 1. Design Jersey's own R/R model interface. (com.sun.ws.rest.api.core)
> 2. Provide an adapter of the model for Servlet.
> (com.sun.ws.rest.impl.container.servlet)
>
> IMHO, it makes sense in terms of balance between leveraging and
> inception.
IIUC you proposing a quick shuffle in the positioning of layers.
We could provide JerseyHttpServletRequest and JerseyHttpServletResponse
that wrap the Jersey specific request and response interfaces. Thus
non-servlet HTTP containers do not need to implement the servlet interfaces.
There could be a special case for a servlet container where the
request/response state read/write using HttpServletRequest and
HttpServletResponse need to be consistent with read/write using Jerseys
specific interfaces, but access to the underlying servlet specific
functions could still be achieved.
> As you pointed out, Servlet API is relatively old and hence
> has some legacy (and even deprecation). Now Servlet 3.0 is going to get
> aligned with JAX-RS, so we may be able to discuss this issue with
> respect to standard and spec.
>
Yes, although i my guess is the scope for backward incompatible changes
to those interfaces may be rather limited.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109