I think this proposal makes sense. Jersey needs to define a contract
that can be used to plug-in support for additional containers. It can
either define a custom interface (as is currently the case) or use a
standard one and, given the adoption of Servlet, I think that
adopting that makes sense. The downside of this (lots of methods,
some unused etc) can be offset by providing an abstract class that
implements all but the essential methods.
Marc.
On Sep 10, 2007, at 6:43 AM, Paul Sandoz wrote:
> 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?
>
> Paul.
>
> [1] http://docs.codehaus.org/display/JETTY/Porting+to+jetty6
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.