On Jun 11, 2009, at 12:16 PM, Martin Probst wrote:
>>> [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?
>
Perhaps, I think it depends on what the defaults are. But we are back
to using status codes or exceptions discussion :-)
> 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.
>
Right, but you are defining a convention that may not work in all
cases. But i think that is OK as long as you are clear on what that
convention is.
>> 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?
>
By the component that performs the commit or rollback, that same
component that checks for the response state. Then you can check if
the exception was mapped and if so what the type of the exception was.
>> 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 :-)).
>
Usually the trigger would be a 404 status code for passing on to the
next filter chain. Produced by the runtime because the URI could not
be matched such that a resource method would be invoke. In addition it
could be the case that a sub-resource locator, constructor, or
resource method, or filter returned a 404 (directly or via an
exception).
I suppose we could make that logic plug-able so it could be overridden.
>>> 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.
>
It does not really fit because there is no response to map, as the
exception mapping is all about creating a response.
I think in this case we need to flag the response state as
UNMAPPED_EXCEPTION.
Paul.