users@jersey.java.net

Re: Using HttpServletRequest/HttpServletResponse

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 13 Sep 2007 14:36:22 +0200

Dan Diephouse wrote:
>> 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.
>>
>
> Everything went very well so far. I have to say it was way way easier to
> integrate than I thought it would be.

That is great to hear. I reckon it should be possible to improve things,
for example i notice you are depending on:

com.sun.ws.rest.impl.HttpRequest/ResponseContextImpl

so i should move these to the API.

As it happens i am currently working on this area to clear up the
confusion of encoded/decoded space of a request URI and URI templates,
for example handling a request URI path "/a%20b/". So while i am it i
can make the contract clearer and less fragile.


> My only gripe is that things
> aren't in the Maven repository yet :-)
>

Hopefully this will happen soon :-)


> If anyone is interested the code is here:
>
> https://svn.muleforge.org/mule-transport-jersey/trunk/
>
> Would it be appropriate to announce integration like this on the
> dev/user list once its ready for more general consumption?
>

Definitely.


>>
>>> 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.
>
> Another approach might be to handle some type of special exception. i.e.
> something like throw new PauseInvocationException(callback); At this
> point Jersey could stop the invocation. It could then resume upon some
> event (of the user's triggering) and the user could use the callbackto
> send the actual response.
>

An interesting approach, i will include that in a list of possible
options to compare the pros/cons.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109