Hi Dan,
Dan Diephouse wrote:
> 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.
Good to know thanks for the feedback, please let us know if anything
does not work or is problematic for you and we can try to resolve it.
> 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.
OK.
> Would there be some jersey specific extensions
> to the objects?
That was the idea. But, given the feedback from yourself and Ias i am
leaning towards Servlet wrapper classes that wraps the Jersey req/resp
ifaces, plus a special wrapping for a servlet container to ensure
consistent interaction.
> For instance, has anyone thought about NIO support and
> implementing some type of pause/resume functionality?
Briefly, related to how can we support 100 (Continue) at the POJO-level.
One solution is to return a 100 response with a Future that returns
another response. As for the more general Async at the low-level i do
not know, i need to understand better this area.
Any ideas from yourself and others on the list on how we may support
such a feature by extending the POJO model and low-level would be very
welcome.
> 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).
>
I am not familiar with the details of Jetty continuations or
AsyncWeb/MINA, but the Servlet 3.0 JSR EG [1] will be looking at how to
support Async/Comet styles.
> Just some uneducated thoughts from outside :-)
>
Very much appreciated :-)
Paul.
[1]
http://jcp.org/en/jsr/detail?id=315
> - 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
>>
>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109