Thanks Jakub for the reply.
Was thinking in case `WhateverException` is an instance of `IOException` is
it *safe*
to close the context's output stream after processing the exception like
the following?
...
} catch (IOException e) {
// process e
try {
ctx.getOutputStream().close();
} catch (Exception ignored) {}
}
...
As I think the response stream would be in a stale state, and it should be
a good practice
to prevent any resource leak by leaving the response stream as it is.
On Mon, Mar 23, 2015 at 1:17 PM, Jakub Podlesak <jakub.podlesak_at_oracle.com>
wrote:
> Hi Behrooz,
>
> I am not pretending it is a best practice, but you should be able to
> capture
> your exception with a WriterInterceptor:
>
> public class ExceptionInterceptor implements WriterInterceptor {
>
> @Override
> public void aroudWriteTo(WriterInterceptorContext ctx) {
> try {
> ctx.proceed();
> } catch (WhateverYouNeedToIntercept e) {
> // TODO: process the exception
> }
> }
> }
>
> The above should work as long as Jetty throws the exception upon a call to
> the underlying
> respose output stream,
>
> ~Jakub
>
> On 19 Mar 2015, at 21:37, Behrooz Nobakht <nobeh5_at_gmail.com> wrote:
>
> Hi,
>
> Is there a way (best practice) to use a ContainerResponseFilter at Jersey
> server layer,
> to capture the potential exceptions that might happen when writing the
> response
> at the level HttpServletResponse?
>
> For example, I have an application that returns an InputStream as the
> response entity.
> Jersey is used in an embedded Jetty. If by any chance, the peer (client)
> connection
> is closed before writing the InputStream to HttpServletResponse output
> stream,
> Jetty throws an EofException. Can I capture this at the level of Jersey
> using a
> ContainerResponseFilter?
>
> Thanks,
> Behrooz
>
>
>
>
--
-- Behrooz Nobakht