I've been thinking about this some more... thoughts below:
On 5 October 2012 18:19, Matthew Swift <matthew.swift_at_gmail.com> wrote:
> [...]
>
> The call to resp.isCommitted() is the one triggering the exception, which
> seems a little harsh! How can it ever return true since, when a response is
> committed, I get an exception instead?
>
>
This has to be a bug, I'm pretty sure of that. There's no point in having
the method if it's going to never return true. Let me know if you agree,
and I'll raise an issue in JIRA for it.
> At the moment I'm having to be really careful about how I use these APIs.
> In particular, I have to be super careful not to try and accidentally
> complete a response more than once (the sort of thing that is pretty easy
> to do when unrolling the stack through try...finally blocks. In addition,
> I've had to be really careful to avoid accidentally closing the response's
> output stream after the response has completed since this causes an NPE
> (remembering that the stream may be closed automatically by other wrapper
> layers like Jackson). In fact I would go say this is definitely a bug -
> close() is usually idempotent and robust against multiple invocations.
>
>
Regardless of what you guys do to make Grizzly servlet support more
forgiving, I still need to code as defensively as possible because other
containers may not be as forgiving. It's a shame that the Servlet API spec
is, from what I have seen, poorly defined in this respect - the only hint
I've seen in the Servlet javadoc which indicates they you can only complete
a response once is in the doc for sendError.
Matt