On 08/02/13 14:18, Sergey Beryozkin wrote:
> Hi,
> I've been experimenting with throwing unmapped exceptions via
> AsyncResponse.resume(Throwable); and expecting to see a registered
> CompletionCallback.onComplete(Throwable) be invoked in such cases, with
> the runtime making sure the underlying javax.servler.AsyncListener
> onComplete and onError callbacks delegating to
> CompletionCallback.onComplete(Throwable).
>
> What I'm seeing is that CompletionCallback.onComplete(Throwable) is
> indeed called in case of unmapped exceptions, but via
> AsyncListener.onComplete path, and thus,
> CompletionCallback.onComplete(Throwable) having a null Throwable.
>
> What I'm not sure if it is the JAX-RS implementation problem or that of
> the underlying javax.servlet.AsyncContext's implementation ?
>
> In other words, how to get it call back AsyncListener.onError() ?
OK, I'm thinking I've got it. It is the responsibility of the JAX-RS
runtime to ensure that the unmapped exception can be made visible to
CompletionCallback,
Marek - if it is not the case please correct me, but I think this is how
it should work,
Now, back to that updated AsyncResponse.resume() Javadocs update:
"except that unmapped exceptions are not re-thrown by JAX-RS runtime to
be handled by a hosting I/O container. Instead, any unmapped exceptions
are propagated to the hosting I/O container via a container-specific
callback mechanism. Depending on the container implementation,
propagated unmapped exceptions typically result in an error status
being sent to the client and/or the connection being closed."
FYI, rethrowing it works with Jetty - but not with Tomcat.
Either way, why can't we simply say that "unmapped exceptions will
result in 500 status being sent to the client" and thus make it up to
the given JAX-RS implementation to ensure it is the case ?
Cheers, Sergey
>
> Thanks, Sergey