Пропустить развертывание или остановить веб-приложение, если инициализация контекста сервлета не удалась

Question

В нашем проекте у нас есть несколько модулей на основе Spring, которые развернуты в WAS в качестве веб-приложений.Нам нужно пропустить развертывание или остановить модуль в случае сбоя инициализации контекста Spring (т. Е. ContextLoaderListener#contextInitialized или DispatcherServlet#init выдает исключение).Теперь, если это происходит, приложение развертывается и запускается, но возвращает HTTP 500 для любого запроса.

Websphere 8.5.5

Смежный вопрос: https://stackoverflow.com/a/272747/3459206

Answer 1

Поищите try-catch на верхнем уровне кода приложения, который перехватывает исключение Spring и позволяет приложению продолжить работу.

Если разрешенным выбросам Spring разрешено распространяться на вершину стека, JVM остановится и, насколько я знаю, не сможет продолжать работу.

Answer 2

Этот APAR, похоже, имеет отношение:

https://www -01.ibm.com / support / docview.wss? Uid = swg1PI58875

Из APARтекст:

Listener exceptions typically should not stop the application
from starting up for service. However, some applications depend
on their listeners to do the necessary setup before the
application is started for service. Such applications prefer to
stop the application from starting up when there is any
exception in their listeners.

Решение проблемы

The WebContainer Container code was modified to provide an
option to stop the application when there is any listener
exception during the application starting up process.

A new WebContainer custom property needs to be set to enable the
behavior provided by this APAR:

For Full Profiles

com.ibm.ws.webcontainer.stopappstartuponlistenerexception = true
(default is false)

For Liberty Profile

stopappstartuponlistenerexception=true

The fix for this APAR is currently targeted for inclusion in
WebSphere Application Server fix packs 8.5.5.11 and  9.0.0.2,
and Liberty 16.0.0.3

Дополнительную информацию см. по ссылке APAR.

Answer 3

Была очень похожая проблема.Дело в том, что - webfear - извините, не смог устоять ;-) не инициализирует все при запуске.

Чтобы вызвать контролируемый запрос, я добавил ScheduledEJB для запуска приложения.Этот компонент сам инициировал http-запрос к определенному URL, который сам вызвал:

• любые фильтры для инициализации в цепочке
• любые необходимые контексты инициализируются

И это само по себе обеспечило очень быстрое тестирование моего приложения (EAR или WAR) после развертывания.Это хорошо работает с небольшим количеством запросов в минуту

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

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

Answer 4

Вы можете использовать Дженкинс + Maven.Добавьте часть, которую вы хотите проверить в вашем тесте, как junit.Тогда, если этот модуль не пройдет тестирование, jenkins не развернет его.

Но я предпочитаю исправлять ошибки перед развертыванием