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