I have mixed feelings on this. I've done some integration between Jersey
and Mule, and the HTTP interfaces that are there worked quite well. It
would be much more of a pain to try and implement the servlet spec IMO.
While some abstract classes could help with this, I think there are
cases where Jersey might still want its own methods on the http
request/response object. Would there be some jersey specific extensions
to the objects? For instance, has anyone thought about NIO support and
implementing some type of pause/resume functionality? How would this
work with the Http servlet apis? (I'm thinking less about jetty here
which advocates contiuations AFAIK, and more about something like
AsyncWeb which is built on MINA).
Just some uneducated thoughts from outside :-)
- Dan
Marc Hadley wrote:
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog