Правильный способ обработки ошибки запуска веб-приложения Java - PullRequest
Новая
       21

Правильный способ обработки ошибки запуска веб-приложения Java

3 голосов
/ 22 января 2011

В настоящее время я пишу Java-приложение, которое выполняет определенные проверки при запуске.Пример, проверка того, что файл конфигурации существует и определяет все необходимые переменные установки.

Я поместил проверочный код в подкласс класса ServletContextListener и зарегистрировал подкласс ServletContextListener внутри web.xml, используя: 

<listener>
    <listener-class>com.bloxware.lls3.MainContextListener</listener-class>
</listener>

В переопределенном методе contextInitialized () я написал код, который проверяет наличие файла конфигурации и содержит допустимые значения.

Если при запуске возникает ошибка, я хочузарегистрируйте эту ошибку и сообщите подходящему пользователю в Интернете.

Мне нужна помощь о том, как двигаться дальше :

  1. Я читаю параметры файла конфигурации в правильном месте (внутри метода ServletContextListener.contextInitialized (..))?

  2. Как бы я справился с отображением страницы ошибки для пользователя после этогоимеет место (например, я должен добавить код для каждого сервлета и страницы JSP, чтобы проверить глобальный флаг, или я могу сделать это более умным способом, возможно, ServletRequestListener.requestInitialized (..))?

  3. Мне нужен способ, которым, если пользователь исправляет файл конфигурации, достаточно обновить страницу и нет необходимости перезапускать веб-приложение.

1 Ответ

2 голосов
/ 22 января 2011

Я могу уважать цель иметь динамическую конфигурацию, которая проверяет себя, но реально я бы не предложил идти по этому пути.

По большей части (предостережения позже), когда веб-приложение запускается, оно либо настроено правильно, либо нет. Если приложение неправильно настроено, оно просто не будет работать. Например, когда приложения запускаются, многие подключаются к базе данных. Если строка подключения неверна, пользователь никогда не получит хорошего опыта. Это должно быть обработано при запуске, и при запуске только . Веб-приложение НЕ должно запускаться, если оно знает, что оно не может функционировать. Распространение кода по всему приложению для решения этой проблемы - не самый лучший способ.

Идея проверки этого при инициализации контекста прекрасна. Но он должен быть совершенно готов бросить подробное и зарегистрированное исключение на месте, чтобы администратор (а не пользователь!) Мог разобраться с проблемой и перезапустить приложение.

Что касается динамических конфигураций, которые обновляются без перезапуска. Это хорошо для настройки некритических параметров, таких как длительность тайм-аута, уровни ведения журнала или параметры пула. Это должны быть вещи, которые не приводят к немедленной остановке приложения, если они неверны. Например, имя хоста вашего соединения с БД не относится к таким вещам.

По моему опыту, ни одна из этих вещей не стоит усилий, чтобы решить все побочные проблемы, вызванные динамической перезагрузкой конфигураций. Я бы просто проверил вещи при запуске и немедленно остановился, если возникла фатальная проблема.

РЕДАКТИРОВАТЬ: Примечание: проверка того, что ваш файл конфигурации находится на своем месте и содержит все необходимые настройки, это то, что, вероятно, следует делать при тестировании, а не во время запуска приложения. Вы можете сделать это как простой модульный тест для самого файла.

...