Статьи

Весенний ботинок войны упаковки

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 Биджу Кунджуммена из блога « все и вся»