On 22/10/12 13:56, Marek Potociar wrote:
>
> On Oct 22, 2012, at 2:52 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> On 22/10/12 13:35, Marek Potociar wrote:
>>>
>>> On Oct 22, 2012, at 12:52 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>>
>>>> On 22/10/12 11:42, Marek Potociar wrote:
>>>>> Sergey,
>>>>> At this stage I would appreciate more concrete suggestions. E.g. what methods are missing, what would the suggested API look like, what use cases the additional API is trying to address etc. Makes sense?
>>>>>
>>>> Well, I'm trying to imagine myself why would I use ResumeCallback - so as far as the usecases are concerned: guess we should refer to your earlier answer in this thread.
>>>>
>>>> Do you see any optional need to associate AsyncResponse with 'something' in ResumeCallback implementations ? If yes then adding
>>>>
>>>> public void setUserObject(Object)
>>>> public Object getUserObject()
>>>>
>>>> or may be just
>>>>
>>>> public void setUserKey(String)
>>>> public String getUserKey()
>>>>
>>>> to AsyncResponse
>>>>
>>>> may do... Note the above object/property does not affect the actual Response, it is really a means to associate
>>>
>>> So why is the AsyncResponse instance not good enough for the key?
>>
>> Possible - but requires saving original AsyncResponses in whatever internal map/queue is used, as opposed to using something more application-specific
>>
>>> Also, why you could not pass the key to the callback (as a shared final variable or via constructor, setter, etc.)?
>>>
>> This is the only option - works well if the callback instance is visible to the original method accepting AsyncResponse
>
> I read your response as "what we have is not ideal but good enough". Correct? :)
>
I was not implying it was "not ideal", rather I was trying to explore if
it would make sense to make it possibly easier for ResumeCallback
implementations to do something with AsyncResponse.
> If yes, the in this particular case, why don't we keep the API as is and think about additions if we see our users are asking for them?
No problems, lets not worry about it.
Cheers, Sergey
>
> Marek
>
>>
>> Sergey
>>
>>> Marek
>>>
>>>>
>>>> Sergey
>>>>
>>>>> Marek
>>>>>
>>>>> On Oct 22, 2012, at 12:24 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>>>>
>>>>>> I wonder, should AsyncResponse user object be introduced (as opposed to the the actual object returned in the end) .
>>>>>> For example, when we have ResumeCallback.onResume(AsyncResponse, Response), there's no easy way to figure out what state needs to be released and such given the current AsyncResponse instance only. As I said earlier, I guess the users would do whatever the cleanup is needed before resuming AsyncResponse, but in cases when ResumeCallback may indeed prove useful, an extra hint may be needed
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>> On 04/10/12 00:13, Marek Potociar wrote:
>>>>>>> Well, it is a generic extension point that lets you plug in any custom processing aspect. You may want to e.g. start measuring performace of how long it took to process filters in the response filter chain, remove the suspended response from some processing queue of yours, notify a transaction manager about a transactional context that has to be resumed, etc...
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On Oct 2, 2012, at 2:00 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>>>>>>
>>>>>>>> So from another thread I'm getting a hint, using ResumeCallback is to do with the orthogonal (presumably to the use of AsyncResponse) use case.
>>>>>>>>
>>>>>>>> Would like to hear more about it please
>>>>>>>>
>>>>>>>> Sergey
>>>>>>>>
>>>>>>>> On 01/10/12 12:55, Sergey Beryozkin wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> I wonder if
>>>>>>>>>
>>>>>>>>> http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/ResumeCallback.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> is needed ?
>>>>>>>>>
>>>>>>>>> It does not harm, to have it, but it is really an extra check/execution
>>>>>>>>> call as far as I can see. ResumeCallback can log the message, but what
>>>>>>>>> else can it do, in addition to what the application code that either
>>>>>>>>> resumes or cancels the invocation can and which has much more info about
>>>>>>>>> why the response is resumed or cancelled ?
>>>>>>>>>
>>>>>>>>> It is only when a timeout occurs with no TimeoutHandler available when
>>>>>>>>> ResumeCallback can report something that the application code does not
>>>>>>>>> know about - in this case may be CompletionCallback can be extended with
>>>>>>>>> 'onTimeout()',
>>>>>>>>> so CompletionCallback will cover: the completion, the escaped exception
>>>>>>>>> case, the timeout
>>>>>>>>>
>>>>>>>>> Sergey
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>