Assuming we're just talking conceptually here, let me provide my comments:
On Feb 5, 2013, at 4:06 PM, Bill Burke <bburke_at_redhat.com> wrote:
> I'm thinking it should be like this:
>
> boolean resume(Object obj) {
> if (completed)return false;
assuming there is a "completing" state between suspended and completed, the decision should be based on suspended, and not on completed...
> try {
> sendResponse(obj);
> connection.close();
...IMO connection.close() should happen in finally...
> callbacks.onComplete(null);
> } catch (Throwable t) {
> return resume(t);
> }
> return true;
> }
>
> boolean resume(Throwable t) {
> if (completed)return false;
>
> try {
> if (mappable(t)) {
> mapException(t);
> } else {
> sendError(500);
...this decision should be made by container...
> }
> } catch (Throwable t) {
> log.error(t);
> } finally {
> connection.close();
> }
> callbacks.onComplete(t);
> return true;
> }
>
>
> The Javadoc should change to say that the connection will be completed/closed after resume() is finished. If there is an exception, it will be handled according to the resource method rules. Unhandled exceptions are turned into a 500, InternalServiceError response to the client.
Except for the last sentence, I thought that's obvious from the current javadoc. Please, send me a diff with the suggested wording, but I'm against making comments about what should be the processing of unmapped exceptions in the underlying IO container. That should be left up to the container to decide the best action.
Marek
>
> These methods return false if the connection has been closed or completed already.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com