Страница ошибки Возвращает код состояния 200 ответ по умолчанию

Question

Мы хотели бы реализовать стратегию " неисправность " для управления исключениями в наших приложениях.Одна вещь, которую имеют наши приложения, это концепция ответа «passback», по сути, no-op, который мы хотели бы вернуть, а не 500, 400 и т. Д. Коды состояния HTTP - например, наши внешние приложения всегда должны возвращатьдействительный ответ, даже если было выдано основное исключение - мы бы хотели обработать его внутри приложения и по-прежнему возвращать действительный noop-ответ.

Нашей первой реализацией был фильтр сервлетов, который обернул бы все запросыв блоке try / catch и возвращают возвращаемый по умолчанию возврат из catch, например:

try{
  chain.doFilter()
} catch (Throwable t) {
  generatePassbackResponse(HttpServletRequest req, HttpServletResponse res)
}

Хотя это в основном работает и выглядит хорошо и чисто (мы можем вернуть хороший текст, установить содержимое / тип соответствующим образоми т. д.), похоже, единственной проблемой является то, что при возникновении исключения ответ по-прежнему поступает с кодом состояния: 500.

HttpServletResponse.setStatus (200) не оказывает влияния, а javadoc говорит, что это применимо только к обычным запросам.

Наша вторая идея реализации заключается внам, возможно, придется перейти на другую страницу или подключить errorPage к web.xml и вручную отправитьEeror на эту страницу - хотя нас интересует, есть ли у кого-то конкретные рекомендации.

Answer 1

Существует два способа настройки HTTP-статуса ответа:

• setStatus () просто установит статус
• sendError () установит статус и вызовет механизм <error-page>

Javadoc для sendError говорит, что ответ должен считаться принятым после вызова sendError (это может объяснить поведение вашего сервера приложений).

Реализация пользовательского HttpServletResponseWrapper позволит вам реализовать поведение, необходимое для sendError (и, возможно,буферизуйте весь запрос в памяти, чтобы можно было отправлять «ответные сообщения» для исключений, возникающих после точки, в которой запрос обычно принимается).

Answer 2

Если я правильно помню, вам не следует вызывать chain.doFilter (), если вы не хотите, чтобы что-то еще обрабатывало запрос. Фильтр будет выполняться в каждом случае, но chain.doFilter () обеспечит вызов всех остальных фильтров. Чтобы правильно заблокировать доступ пользователя к исключению, необходимо остановить обработку запроса / ответа.

Вы также можете выбрать другой маршрут, используя такую ​​среду, как Spring и ее перехватчики (как фильтр). Spring дает вам большой контроль над перехватчиками и тем, как обрабатываются ответы. Конечно, это немного сложное решение вашего вопроса.

В ответ на комментарий, согласно http://java.sun.com/products/servlet/Filters.html:

Самый важный метод в Интерфейс фильтра - это doFilter метод ... Этот метод обычно выполняет некоторые из следующих действий:

Если текущий фильтр является последним фильтр в цепи, которая заканчивается целевой сервлет, следующая сущность ресурс в конце цепочки; в противном случае это следующий фильтр, который был настроен в WAR. Это вызывает следующий объект, вызвав метод doFilter для объекта цепочки (передача запроса и ответа это было вызвано, или завернутый версии, которые он, возможно, создал). Кроме того, он может заблокировать просьба не звонить вызвать следующую сущность. В последнем В этом случае фильтр отвечает за заполнив ответ.

Идея состоит в том, что этот "барьер отказов" должен останавливать выполнение всех других фильтров и просто обрабатывать запрос / ответ так, как он считает нужным.

Answer 3

Среда RESTEasy позволяет вам выбрать, какой код ответа вы будете использовать, используя ExceptionMappers. Возможно, вы отказываетесь использовать его, но я обнаружил, что он очень быстрый и эффективный.

Документация JBoss, охватывающая ExceptionMappers http://docs.jboss.org/resteasy/docs/2.0.0.GA/userguide/html_single/index.html#ExceptionMappers

Моя статья в блоге с фрагментом кода RESTEasy общего назначения. http://gary -rowe.com / agilestack / 2010/08/22 / мой тока, развитие стека /

Answer 4

Можете ли вы не просто использовать стандартную конфигурацию web.xml:

<error-page>
    <error-code>500</error-code>
    <location>/error.jsp</location>
</error-page>

<error-page>
    <location>/error.jsp</location>
    <exception-type>java.lang.Exception</exception-type>
</error-page>

Я не вижу, что еще вы пытаетесь сделать, что это уже не обслуживает? Если это просто код ошибки, то я думаю, что вы можете установить это, используя объект ответа.