Вероятно, мы не сможем решить эту проблему в Stackoverflow. Я надеюсь, что вы оцените мою попытку поддержки, если не сможете найти более качественную информацию.
Во-первых, документация Grails предлагает перезапустить Tomcat после (повторного) развертывания. Но это не должно быть необходимым в большинстве случаев.
Когда Tomcat перезагружает веб-приложение, Grails ServletContextListener
получает информацию об этом событии и создает (должен создать) Grails / Spring ApplicationContext
, который связывает все компоненты Spring приложения (используя вышеупомянутый метод refresh(..)
, BTW). Это идет не так в вашем случае.
Обычно, после горячего развертывания, вам просто нужно подождать некоторое время, пока ApplicationContext
не станет полностью доступным, но это должно произойти, наконец, через некоторое время. Между этими двумя состояниями ваша ошибка будет нормальной. Spring работает над проблемой (уже довольно давно), чтобы заставить DispatcherServlet
Spring ожидать второго состояния, даже когда запросы поступают до этого. Так что это считается улучшением , а не ошибкой.
Что касается процесса развертывания для самого Tomcat, см. Документацию Tomcat . По умолчанию горячее развертывание должно быть таким же простым, как перезапись существующего файла WAR и позволить Tomcat распаковать его, но это можно настроить в теге <Host>
в conf / server.xml .
Другие идеи:
- Я полагаю, что после повторного развертывания вы достаточно долго ждали, чтобы ошибка не возникала в течение ограниченного времени.
- Вы можете опубликовать полную трассировку стека.
- В файле web.xml вашей WAR есть ли
<listener>
s или <filter>
s, которые не принадлежат пространству имен org.codehaus...
?
- Используете ли вы какие-либо специальные плагины, версии, спецификации?
- Если вы настроили виртуальный хост в Tomcat, взгляните на настройки
autoDeploy
и unpackWAR
.