On 27/09/12 13:56, Sergey Beryozkin wrote:
> Hi,
>
> I can see AsyncResponse.resume throws IllegalStateException if the
> invocation has not been suspended.
>
> IMHO it is too much of a restriction, possibly an implementation
> specific one.
>
> IMHO, the following should work
>
> @GET
> void getIt(AsyncResponse response) {
> response.resume(myObject);
> }
>
> if 'myObject' happens to be available immediately.
> The runtime has to suspend only after "getIt" returns, but only if no
> response object is already available.
Here is some more reasoning about it.
AsyncResponse does not let users explicitly initiate suspend() but warns
them they can 'hit' IllegalStateException.
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.
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)
- make AsyncResponse.resume(Object) throw ISE if it is called in scope
of method like getIt(), and make accept either throw ISE or let the
runtime delegate to resume() if called outside of getIt().
That will make it unambiguous but will also let implementations do
whatever they want with respect to managing AsyncResponse, example, fork
a thread and suspend the invocation even before getIt is invoked or
suspend only after getIt returns and no accept has been called
Does it make sense ?
Sergey