We are currently using Jersey 2 and have jersey.config.server.response.setStatusOverSendError set to true so that we can post-process the response in a servlet filter when exceptions make their way out of Jersey and to a servlet filter.

Here is snippet from setStatusOverSendError docs explaining the behavior we are relying on:

However if you want to post-process response (e.g. by servlet filter) the only way to do it is calling setStatus(...) on container Response object.

This is necessary because sendError will cause the servlet container to close the response. Using setStatus by setting jersey.config.server.response.setStatusOverSendError=true avoids this and allows post-processing the response.

Jersey 3.1 introduces a default exception mapper that adds the following error message to the response for unmapped exceptions:

An exception mapping did not successfully produce and processed a response. Logging the exception propagated to the default exception mapper.

The fact that this message exists makes post-processing of the response when setStatusOverSendError=true impossible because servlet container will close the response when Content-Length is set and the full response entity has been written. While sendError is one way that will trigger the servlet container to close the response (which is what setStatusOverSendError is trying to account for), setting Content-Length and writing this much data will also trigger the servlet container to close the response.

Expected Outcome

When jersey.config.server.response.setStatusOverSendError=true, exceptions that make their way to servlet filter do not trigger response closure so that post-processing of the response is possible.