>> [different method policies for HTTP status codes/rollback]
>
> It should be possible to declare per-method policy using an annotation.
But that would place quite a burden on the user, no?
Ideally I'd like to provide a jersey-xdb package that people can just
use, and that can be used to inject a database session into their user
objects, and that will clean up appropriately. Again, I'd generally
try to stick with current conventions that throwing an exception means
rollback, not throwing one means commit.
> What we could do is store the exception instance in a property if it was
> mapped (WebApplication exceptions are implicitly mapped if the developer
> does not map them).
Then who would access the exception, and where?
> I would also like to try and support another state that declares that the
> runtime threw a mapped exception. That way we can detect the case of no
> resources matched, and thus for filters pass on to the next filter in the
> chain.
Sounds useful. Then we'd need an interface that can either say
"continue in the filter chain" or "use Jersey's response", and also
run some arbitrary code (my session rollback :-)).
>> Somewhat related: there is no catch block around "response.write()" in
>> that place. What happens if a streaming output throws a
>> RuntimeException?
>
> Or an IOException. The problem is that the response may have been committed
> (bytes written out on the wire). In that case there is not much that can be
> done, the server will probably close the connection or prematurely end the
> response, so that the client detects an error, but the server cannot
> communicate using HTTP what that error was.
OK. But any generic exception handler on the Jersey side would also
need to be notified of this.
Martin