Spring boot рекомендует создавать исполняемый jar со встроенным контейнером (tomcat или jetty) во время сборки и использовать этот исполняемый jar как самостоятельный процесс во время выполнения. Однако обычно вместо этого развертывание приложений выполняется во внешнем контейнере, и Spring boot обеспечивает упаковку приложений как войну специально для такого рода потребностей.
Здесь я сосредоточен не на повторении уже подробных инструкций Spring Boot по созданию артефакта войны, а на тестировании созданного файла, чтобы определить, будет ли он надежно работать с автономным контейнером. Недавно у меня возникла проблема при создании войны из проекта Spring Boot и ее развертывании на Jetty, и это, по сути, является уроком из этого опыта.
Лучший способ проверить, будет ли война работать надежно, — это просто использовать плагин jetty -maven и / или tomcat maven со следующими записями в файле pom.xml:
|
01
02
03
04
05
06
07
08
09
10
|
<plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.2</version></plugin><plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.2.3.v20140905</version></plugin> |
С плагинами на месте, начиная войну с плагином tomcat:
|
1
|
mvn tomcat7:run |
и с плагином молы:
|
1
|
mvn jetty:run |
Если есть какие-либо проблемы с тем, как была создана война, она должна появиться во время запуска с этими контейнерами. Например, если бы я оставил во встроенных зависимостях tomcat:
|
1
2
3
4
|
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId></dependency> |
тогда при запуске плагина maven tomcat будет отображаться сообщение об ошибке:
|
1
|
java.lang.ClassCastException: org.springframework.web.SpringServletContainerInitializer cannot be cast to javax.servlet.ServletContainerInitializer |
указание файла jar сервлета, упакованного с файлом war, исправлено путем указания области действия, как указано в зависимостях maven:
|
1
2
3
4
5
|
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope></dependency> |
почему плагины как для Jetty, так и для tomcat, причина в том, что я видел разницу в поведении, особенно с поддержкой websocket с Jetty в качестве среды выполнения, а не в tomcat. Итак, рассмотрим зависимости websocket, которые вытащены следующим образом:
|
1
2
3
4
|
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId></dependency> |
Это дало мне ошибку при запуске с использованием среды выполнения Jetty, и исправление снова заключается в том, чтобы пометить лежащие в основе зависимости tomcat, как указано выше, заменив выше следующее:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-websocket</artifactId></dependency><dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> <scope>provided</scope></dependency><dependency> <groupId>org.springframework</groupId> <artifactId>spring-messaging</artifactId></dependency> |
Итак, в заключение, быстрый способ проверить, будет ли файл war, сгенерированный для приложения Spring-boot, без проблем развернут в контейнере (по крайней мере, tomcat и jetty), — это добавить плагины tomcat и jetty maven и использовать эти плагины для запуска приложения. , Вот пример проекта, демонстрирующего это — https://github.com/bijukunjummen/spring-websocket-chat-sample.git
| Ссылка: | Упаковка для весенней загрузки от нашего партнера JCG Биджу Кунджуммена из блога « все и вся» |