On Sep 27, 2012, at 10:49 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 9/27/2012 10:30 AM, Sergey Beryozkin wrote:
>> It is really the responsibility of the runtime to make sure the
>> invocation can be properly suspended - but not at the cost of preventing
>> the user from reacting to AsyncResponse immediately.
>>
>
> +1. For example this is a nice use case:
>
> @POST
> void expensiveOperation(AsyncResponse res, Data data) {
> res.resume(Response.status(202));
>
> ... process data
>
> }
Note that the above cannot be covered by spec unless we introduce @ManagedAsync or similar annotation or unless we mandate that all async operations have to be invoked in a separate thread. I'm against such restriction, so if we found a use case that would convince you that @ManagedAsync is useful, then great!
Marek
>
>> The other thing is that AsyncResponse should be able to accept 'null'
>> resumes, example, 204 in return to GET should work too - this makes it
>> difficult to use AsyncResponse.resume for the immediate provision of the
>> response.
>>
>> Thus I'd like to do a minor improvement:
>> - add AsyncResponse.accept(Object)
>
> accept == 202? I don't see why we'd need a special method. Its a rare case and there is a good chance you'll want to populate a Response object for a 202 anyways.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com