В чем отличие артефакта war от war exploded
When using IDEA development projects, the following situations usually occur when deploying Tomcat:
Is it war or war exploded? First look at the difference between the two:
War mode: upload the WEB project to the server in the form of a package;
war exploded mode: upload the WEB project to the server in the current folder position relationship;
(1) War mode This can be called the release mode. See the name and know that this is the first package and then released.
(2) War exploded mode is to directly move folders, jsp pages, classes, etc. to the Tomcat deployment folder for loading and deployment. This approach therefore supports hot deployment, which is generally used in development.
(3) In the usual development, if you use hot deployment, you should set the Tomcat accordingly, so that anything modified in the jsp interface can be displayed in time.
Modify the location of the arrow so that hot deployment can be achieved.
Pit encountered when developing with war mode
First, the location of the project code is as follows:
The above project is an SSM project.
Second, the location of the Tomcat deployed:
Third, the code used to obtain the absolute path of the context:
String contextPath = request.getSession().getServletContext().getRealPath("/");
Four, two ways of experimentation and results:
(1) When using the war mode development, obtain the relative path of the project by the following code:
The war mode is always the path obtained as follows:
among them C:\Software\apache-tomcat-8.0.32 It is the location of my Tomcat.
Can be seen through War mode It is the final package to deploy to Tomcat.
(2) Then look again War exploded mode , also set up, run the same piece of code, the results are as follows:
It can be seen that the final result is the location of my project, which is actually the location of the target of this project.
According to the experimental results of (1)(2) above, it can be seen that the deployment methods of the two methods are different, so the results obtained when obtaining the relative path of the project are different.
Понимание WAR
WAR (Web application ARchive) файлы используются для распостранения Java web-приложений. WAR имеет такую же структуру, как и JAR-файл, единый сжатый файл, содержащий несколько файлов внутри него.
WAR-файлы используются для объединения JSP-файлов, сервлетов, Java class-файлов, XML-файлов, javascript-библиотек, JAR-библиотек, статических web-страниц и любых других ресурсов, необходимых для работы приложения.
WAR-файлы обычно разворачивают в контейнерах сервлетов, но также возможно разворачивать и в Java EE серверах приложений. Когда WAR-файл разворачивается в контейнере, контейнер обычно распаковывает его для доступа к файлам, а затем запускает приложение. На основе контейнеров сервлетов получается наиболее производительная платформа для Java web-приложений, WAR-файлы являются не только стандартом Java спецификации, но WAR-файлы нельзя редактировать, пока работает приложение. Любые изменения потребуют пересборки файла.
Сборка war-проекта
Фактически jar-библиотека – это просто zip архив, что напрямую следует из его имени: J ava Ar chive . Чаще всего он содержит просто четыре вещи:
- скомпилированные классы;
- ресурсы: properties-файлы и тому подобное;
- манифест MANIFEST.MF;
- другие jar-библиотеки (редко).
Типичная структура такого архива имеет вид:
Теперь давай рассмотрим типичный war-файл. Кстати, war не от слова война, а от W eb Ar chive . Структура war-файла обычно посложнее. Чаще всего он состоит из двух частей:
- Java-часть
- скомпилированные классы
- ресурсы для java-классов: properties-файлы и тому подобное
- другие jar-библиотеки (часто)
- манифест MANIFEST.MF
- web-xml – дескриптор развертывания веб-сервиса
- jsp-сервелеты
- статические веб-ресурсы: HTML, CSS, JS-файлы
Пример типичного war-файла:
Важно! jar-файл может запустить просто java-машина, для запуска же war-файла его нужно загрузить на веб-сервер. Самостоятельно он не запускается.
Плагин создания war-файла с помощью maven-war-plugin
Давайте представим, что у нас есть простой веб-проект. Пусть проект задается такой структурой файлов, как нам его собрать?
Во-первых, нам нужно указать Maven, собрать все это в виде war-файла , для этого есть тег <package> , пример:
Во-вторых, нам нужно подключить плагин maven-war-plugin . Пример:
Тут мы просто задаем плагин, который в будущем можно конфигурировать. Также с помощью тега webappDirectory переопределяем директорию, в которую будет развернут проект. Сейчас расскажу подробнее, о чем идет речь.
Плагину можно задать два режима сборки (два вида goal):
- war:war
- war:exploded
В первом случает итоговый war-файл просто кладется в папку target и имеет имя <artifactId>-<version>.war .
Но можно “попросить” плагин, чтобы в итоговую папку содержимое war-файла было помещено в том состоянии, в котором оно будет распаковано веб-сервером у себя внутри. Для этого используется goal war:exploded .
Второй подход используется часто, если ты запускаешь или дебажишь проект прямо из Intellij IDEA.
Кстати, тег webappDirectory в примере выше позволяет переопределить директорию куда будет распакован ваш war-файл при сборке в режиме war:exploded.
О других настройках плагина вы можете узнать из его официальной странички.
Сборка web-приложения на основе SpringBoot
Ну и хотелось бы разобрать какой-нибудь реальный пример сборки. Давай не мелочиться и рассмотрим это на примере приложения на основе SpringBoot.
Шаг первый. Создай пустой Maven web-проект с помощью IDEA.
Шаг второй. Добавь в его pom.xml зависимости от Spring.
Шаг третий. Создай класс com.javarush.spring.MainController . Его нужно разместить в папке src/main/java :
Тут описаны 3 вещи. Во-первых, аннотация @Controller указывает фреймворку SpringBoot, что этот класс будет использоваться для обслуживания входящих веб-запросов.
Во-вторых, аннотация @GetMapping , указывает, что наш метод будет вызываться для обслуживания GET-запроса на корневой URI — /
В-третьих, метод возвращает строку «index» . Это говорит фреймворку SpringBoot, что в качестве ответа нужно отдать содержимое файла index.html .
Шаг четвертый. Нужно добавить в проект файл index.html с таким содержимым:
Это не просто html. Перед тем, как его содержимое отдадут клиенту, оно будет модифицировано на сервере фреймворком Thymeleaf. В этот файл встроены специальные теги, которые позволяют библиотеке Thymeleaf обрабатывать и модифицировать содержимое страницы.
Красным отображены теги, которые будут обработаны библиотекой Thymeleaf, зеленым – стили CSS-библиотеки Bootstrap.
Шаг пятый. Задаем плагин в pom.xml:
Немного переоценил свои силы. Чтобы полностью разобрать простой пример, нужно много времени. Но ты можешь скачать полный код проекта из GitHub и попробовать разобраться в нем самостоятельно. Кстати, процентов 80% своего рабочего времени ты будешь делать именно это 🙂