[jax-rs-spec users] [jsr339-experts] Re: Contexts in TimeoutHandler

From: Sergey Beryozkin <>
Date: Wed, 10 Jul 2013 16:26:14 +0100

Hi Bill
On 10/07/13 14:35, Bill Burke wrote:
> It is not a valid option because UriInfo may be proxied depending on the
> lifecycle of the resource class (per request or singleton) and the
> implementation.
I think you've raised an interesting issue.

FYI, I believe the runtime actually needs to remember the service object
which suspended the invocation and ask the life-cycle handlers to
release it only after the invocation has been completed. This is how CXF
manages its Continuation objects (which is private to CXF)

If that does not happen:

- users will have to keep AsyncResponse in static maps, in cases where
we have an unlimited timeout, this example:

- the last code fragment I provided; a developer may not even know what
lifecycle will be assigned at the deployment time, it looks naturally
correct, but it won't work

I think we really need either:
- to highlight the fact that the state needs to be kept in static stores
or in TimeoutHandlers for it not be lost across the same request invocations
- request the runtime to remember the service object which suspended the
invocation - this might be tricky to fix for all of the cases, I agree


> On 7/10/2013 9:04 AM, Sergey Beryozkin wrote:
>> One more thought:
>> public class Root {
>> @Context
>> private UriInfo ui;
>> @GET
>> public void get(@Suspended AsyncResponse ar) {
>> ar.setTimeoutHandler(new MyTimeoutHandler());
>> // instead of new MyTimeoutHandler(ui.getAbsoluteUri());
>> }
>> private class MyTimeoutHandler implements TimeoutHandler {
>> public void handleTimeout(AsyncResponse asyncResponse) {
>> URI uri = Root.this.ui.getAbsoluteUri();
>> // use this uri to create a response somehow
>> }
>> }
>> }
>> I think this is a valid code option, I'm not advocating strongly for it
>> to be supported, but it seems to me users may expect the above code
>> working, i.e, TimeoutHandler implementation being able to access a
>> request context from a root class.
>> If this case is not going to be supported then IMHO it has to be noted
>> (say in TimeoutHandler docs) that the implementations should store the
>> context information at the handler initialization time should they need
>> an access to it
>> Sergey
>> On 09/07/13 17:11, Sergey Beryozkin wrote:
>>> Hi Marek
>>> On 09/07/13 16:50, Marek Potociar wrote:
>>>> Hi Sergey,
>>>> What is the use case you have in mind?
>>> I was looking at something else and then realized that if we have
>>> TimeoutHandler then it means by the time it is ready to provide a final
>>> Response, it won't be able to use a context info to build this Response
>>> (for whatever reasons one may want to do it, example, build new links
>>> based on the info obtained from UriInfo, etc),
>>> unless this info was captured when AsyncResponse method was invoked.
>>> I guess this can work actually so I'm fine with not doing anything extra
>>> in this regard unless it proves limiting...
>>> Thanks, Sergey
>>>> Marek
>>>> On Jul 9, 2013, at 1:23 PM, Sergey Beryozkin <>
>>>> wrote:
>>>>> Hi,
>>>>> would anyone see a value in injecting contexts in AsyncResponse
>>>>> TimeoutHandler implementations ?
>>>>> Otherwise, when needed, a context info would need to be saved in the
>>>>> original AsyncResponse method handler for TimeoutHandler see UriInfo,
>>>>> etc...
>>>>> Sergey