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:
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/client/AsyncInvoker.html
- 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
Sergey
> 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 <sberyozkin_at_talend.com>
>>>> 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
>>>>
>>>
>>>
>>
>>
>