dev@jersey.java.net

Re: Using HttpServletRequest/HttpServletResponse

From: Changshin Lee <iasandcb_at_gmail.com>
Date: Tue, 11 Sep 2007 10:59:44 +0900

Hi,

> Hi,
>
> I want to sound out an idea to see if people think this is
> worthwhile or not. Sorry for the cross post to users/dev for those
> on both, i want to get input from both users and implementors.
>
>
> Currently Jersey uses its own abstraction for the low-level HTTP
> request and response (see
> com.sun.ws.rest.api.core.HttpRequestContext and HttpResponseContext)
> for HTTP containers to implement.
>
> I am wondering if it makes sense to use HttpServletRequest and
> HttpServletResponse and extend this with the additional stuff
> required by HttpRequestContext and HttpResponseContext.
>
> Pros:
>
> 1) This integrates very well when using a servlet container. The
> developer can use familiar stuff in addition to the extended
> stuff that Jersey provides in a consistent manner.
>
> 2) Applications can be more portable across HTTP containers.
>
> 3) Potential to reuse of servlet Filter/FilterChain interfaces and
> implementations.
>
> 4) Easy integration with Jetty, from [1]:
>
> "In Jetty 6, all requests and responses are based on the Servlet
> APIs
> requests and responses."
>
> Cons:
>
> 1) Other HTTP containers have to implement HttpServletRequest and
> HttpServletResponse if they want to plug into Jersey.
>
> 2) Not all methods on HttpServletRequest and HttpServletResponse are
> valid in SE.
>
> 3) The HttpServletRequest and HttpServletResponse are not particularly
> good APIs.
>
>
> I believe cons 1 and 2 could be mitigated by providing abstract
> implementations that profile for SE. Con 3 can be mitigated by
> Jersey providing further support (as it already does), those APIs
> have stood the test of time, and we can learn how Jetty uses those
> APIs.
>
> The pros for better integration and reuse seem to be worth it.
>
> What do people think?

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

Cheers,

ias


>
>
> Paul.
>
> [1] http://docs.codehaus.org/display/JETTY/Porting+to+jetty6
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>