War exploded artifact что это
Intellij IDEA деплой на Tomcat
Хочу показать как можно быстро тестировать проект прям с IDE Intellij IDEA, а также расскажу плюсы от этого.
Шаг 0. Для чего это нужно?
Думаю вы уже работали над разработкой Java EE проектов ивам приходилось проверять его после написания очередной фитчи, а даже если не приходилось то придётся 🙂
Deploy – процесс развертывания (распаковки) проекта на сервере приложений.
О серверах приложений можно почитать тут. Так вот стандартный процесс деплоя:
1. Вы либо в ручную через Admin Panel или же через Console деплоите;
2. Вы используете Maven, Ant либо Gradle инструмент для этого.
Но не первый не второй способ не совсем удобный если вам к примеру нужно провести Debug проекта и отловить неисправность. И это одна из значительных причин использовать способ о котором я расскажу ниже.
Давайте теперь познакомимся собственно со способом деплоя используя Intellij IDEA.
Шаг 1. Готовим проект
Для того чтобы продемонстрировать данный способ мне необходимо иметь пример проекта для деплоя. Я буду использовать проект с этого урока Spring 3. JavaConfig на примере Spring MVC.
В скачанном вами проекте для деалоя на Tomcat необходимо в pom.xml добавить еще одну зависимость:
Открываем проект, справа в меню Maven Project выбираем clean | install как показано на изображении ниже, таким образом мы соберем наш проект и в итоге у нас получится war файл, который мы будем деплоить на сервер:
После этого в корне проекта появится папка target и в ней будет лежать ваш war архив.
Дальше нам нужно скачать сервер приложений Tomcat 8+ Скачать
Внимание! Вы можете использовать любой сервер приложения не обязательно Tomcat. Я рекомендую использовать его так как он лёгкий и быстро стартует.
Шаг 2. Конфигурируем Intellij IDEA для Deploy
Теперь в открытом вами проекте который вы хотите задеплоить, со студии IDEA выполните действия, которые показанные на изображении ниже:
После этого в появившемся окне нажмите на плюс и выберите Tomcat Server – Local:
После этого вводим имя и нажимаем Configure выбираете где лежит скачанный и распакованный Tomcat и жмете ОК.
Теперь переходите во вкладку Deployment жмем плюсик выбираем Artifact:
B в появившемся окне выбираете свой Artifact war:
Жмете ОК дважды. Вот общая конфигурация, которая должна появится у вас:
Шаг 3. Run и Debug
После настройки вы можите либо просто запускать ваш проект со студии либо проводить Debug со студии в зависимости от режима:
Зеленый треугольник просто запускает проект, а точней деплоит его и запускает в выбранном вами браузере при конфигурации.
Зеленый жучек деплоит проект на сервер и запускает Debug режим, который позволит вам отловить ошибки.
После запуска я получу задеплоиный проект:
Зеленый индикатор в Deployment говорит о том что проект удачно развернулся на сервере.
War exploded artifact что это
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.
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-файлы и Java-приложения со встроенными серверами
Большинство серверных Java-приложений (например, веб-или сервис-ориентированных) предназначены для работы в контейнере. Традиционный способ упаковки этих приложений для распространения — это объединение их в файл WAR. Это не более чем ZIP-архив со стандартной компоновкой каталогов, содержащий все библиотеки и зависимости уровня приложения, необходимые во время выполнения. Этот формат в основном совместим и может быть развернут на любой серверный контейнер, который вам нравится, Tomcat или Jetty, JBoss или GlassFish и т. Д.
Однако есть еще одна школа мысли, которая полностью переворачивает эту модель с ног на голову. При таком подходе приложения Java упаковываются для выполнения из командной строки, как любое обычное приложение. Вместо того, чтобы развертываться в контейнере, встроенный контейнер развертывается внутри самого приложения!
Встроенное приключение
Обычно я использую Eclipse в своей собственной среде разработки и указываю на локальный экземпляр Tomcat для тестирования веб-приложений. Однако я хотел поддержать читателей, которым было удобнее использовать IntelliJ, Netbeans или вообще не использовать IDE. Поэтому я решил, что мой скрипт сборки должен встраивать тестовый сервер, чтобы читатели могли запускать примеры без установки или настройки чего-либо.
Использование встроенного сервера с Maven
Моей первой целью было просто запустить сервер из сценариев сборки Maven, чтобы читателям не пришлось устанавливать сервер или интегрировать его в свою среду IDE. Я видел, как это было сделано раньше, и было просто добавить Jetty Maven Plugin в POM проекта. Читатели должны иметь возможность создать пример приложения и запустить его за один шаг с помощью команды:
Однако вам нужно взломать файл Jetty JAR, чтобы получить правильную копию этого файла конфигурации. Во-первых, вам нужно покопаться в вашем локальном репозитории Maven и выяснить, какой JAR-файл взломать (оказывается, это jetty-webapp, а не jetty-server). После того, как вы получите копию файла webdefault.xml и переключите параметр useFileMappedBuffer, вам нужно сохранить свою копию где-нибудь в вашем проекте и обновить POM Maven, чтобы он смотрел там, а не внутри Jetty JAR:
Хорошо … немного больше хлопот, чем я ожидал, но я могу с этим справиться.
Использование встроенного сервера с другими системами сборки
Я знаю, что многие Java-разработчики ненавидят Maven. Поэтому я хотел предоставить версию примера приложения моей книги, созданного с использованием Ant, чтобы проиллюстрировать, как можно адаптировать концепции по умолчанию. Итак, какую строку мне добавить в build.xml, чтобы Ant использовал Jetty?
Я вижу, что они наконец добавили Jetty 8 в прошлом месяце, но это не помогло мне, когда я писал книгу прошлой осенью. Мне пришлось переписать эту версию моего примера приложения для Servlet 2.5 вместо 3.0, и я начал задаваться вопросом, действительно ли это того стоило.
Использование встроенного сервера из кода 
В последней главе моей книги рассказывается о приложениях Hibernate Search, работающих в среде кластерного сервера. Плагин Maven предназначен только для одного экземпляра, поэтому я решил написать небольшой класс начальной загрузки, который бы программно запускал два экземпляра Jetty на разных портах. Структурируя этот класс как тест JUnit, я мог бы заставить Maven запускать его автоматически следующим образом:
Честно говоря, я до сих пор не совсем понимаю, как определить разницу между «высоким» и «не высоким». Все, что я могу вам сказать, это то, что мне пришлось добавить этот кусок кода в мой класс начальной загрузки, чтобы аннотации работали:
Намного проще и понятнее, чем сбросить файл WAR в папку Tomcat / webapps, верно?
Использование встроенного сервера из консоли и облака
Эх, не так быстро. Если ваше приложение ожидает, что соединения с базой данных (или что-то еще) будут зарегистрированы как ресурсы JNDI, то вы сами по себе. Связанный с Heroku Tomcat Runner не поддерживает настройку JNDI. Хм … может быть, именно поэтому демонстрация ванильного сервлета Heroku на самом деле ничего не делает, и почему единственное демонстрационное приложение, которое делает что-то, — это Spring-based. Теперь, когда я думаю об этом, Джеймс Уорд покинул Heroku, чтобы работать в TypeSafe в прошлом году, и Heroku не сделал ни одного обновления для своего сайта Java с тех пор, как ушел. Глоток.
Эх, все еще слишком быстро. Если вы используете теги JSTL в своих представлениях JSP (т.е. вы живете в 21-м веке), то Jetty Runner — это беспорядок, который ставит вас в ад пути к классам. При запуске из командной строки вам нужно передать параметры в Java для:
Мой профиль Heroku в итоге выглядел так:
Здесь работает более одного загрузчика классов, и это позволяет Jetty Runner загружать материал JSTL / taglib из его пути к классам, а не к пути к классам веб-приложения.
Вывод
С другой стороны, концепция слишком хрупкая и хрупкая для широкого использования общего назначения. Привязка встроенного сервера к обычному Java-приложению — это просто боль. Возможно, вы сможете цепляться за безопасность чужого рабочего примера, но в тот момент, когда ваше приложение делает что-то другое, вы сами можете устранить поломку. Возьмите мое встроенное приключение выше и сопоставьте его с «хлопотами» использования Tomcat:
Отличия war от war exploded
Уровень знаний, необходимых для понимания статьи: вы уже более-менее разобрались с Java Core и хотели бы посмотреть на JavaEE-технологии и web-программирование. Логичнее всего, если вы сейчас изучаете квест Java Collections, где рассматриваются близкие статье темы. 
В настоящее время я использую IntelliJ IDEA Enterprise Edition (это платная расширенная версия IDE, её обычно используют в профессиональной разработке, — прим. ред.). В ней гораздо проще работать с веб-проектами, чем в бесплатной Edition. Так, в Enterprise Edition буквально по одному щелчку мышки происходит сборка проекта, заливается в контейнер сервлетов, запускается сервер и даже открывается страничка с запущенным проектом в браузере. В бесплатной версии идеи многое из этого пришлось бы делать самостоятельно, так сказать, «ручками». Для сборки проекта и управления его жизненным циклом я пользуюсь Apache Maven. В этом я использовал лишь малую толику его возможностей (управление пакетами/зависимостями). В качестве контейнера сервлетов/сервера приложений (Application server) я выбрал Apache Tomcat версии 9.0.0.М4. Я знаю, что уже есть и более новые версии, но у меня установлена именно эта.
Приступаем
Для начала откроем IntelliJ IDEA и создадим пустой Maven-проект.
Тут слева выбираем Maven, проверяем, чтобы сверху была указана JDK для проекта. Если её нет, выберите необходимую из списка, либо жмите New… и выбирайте напрямую с компьютера. В середине окна у меня крутится анимация загрузки списка архетипов. Нам они не нужны, поэтому, не дожидаясь загрузки, смело клацаете Next внизу окна.
В этом окне необходимо указать GroupId и ArtifactId. Под GroupId подразумевается уникальный идентификатор компании, которая выпускает проект. Обычно принято использовать доменное имя компании, только в обратном порядке. Не в смысле, зеркально, а если, например, доменное имя компании maven.apache.org, то ее GroupId будет org.apache.maven. То есть сначала пишем домен первого уровня, отделяем точкой, пишем имя домена второго уровня, и так далее. Это общепринятый подход. В том случае, если вы «пилите» проект самостоятельно, а не в составе компании, пишите сюда ваше личное доменное имя (тоже в обратном порядке!). Если оно у вас, конечно же, есть:). Если нет — не расстраивайтесь. В действительности сюда можно написать что угодно.
Для компании с доменным именем vasya.pupkin.org, GroupId будет org.pupkin.vasya. Такой подход к именам нужен для того, чтобы отделять проекты с одинаковым названием, но которые выпустили разные компании.
В этом примере я буду использовать вымышленное доменное имя fatfaggy..javarush.ru. Соответственно, в поле GroupId я вписываю ru.javarush..fatfaggy. ArtefactId — это просто название нашего проекта. Можно использовать буквы и некоторые знаки (дефис, например) для разделения слов. Наш «артефакт» будет называться именно так, как мы тут напишем. В этом примере, я пишу my-super-project. Поле версии пока не трогаем, оставляем как есть.
Ну и стандартное окошко IDEA при создании нового проекта. Назовем его по традиции my-super-project.
Перед нами сразу открылся файл pom.xml. Это файл, с настройками Maven. Если мы хотим «рассказать» Maven’у, что и как делать или откуда что-то брать, мы описываем всё это в этом самом файле pom.xml. Он находится в корне проекта.
Видим, что в нём указаны сейчас именно те данные, которые мы вводили при создании Maven-прокта: groupId, artifactId и version (последний мы не трогали).
Структура нашего проекта
Этот Maven-проект имеет определенную структуру.
Как видим, в корне лежат:
В папке src в свою очередь лежат две подпапки:
Превращение в веб-проект
Пришло время наш преобразовать наш Maven-проект в веб-проект. Для этого кликаем правой кнопкой мышки по названию проекта в этом дереве и выбираем пункт Add framework support…
Откроется окно, где мы можем добавить поддержку всяких разных фреймворков для нашего проекта. Но нам нужен только один: Web Application. Его и выбираем.
Проверяем, что стоит галочка напротив Web Application, а в основной части окна отмечено, что мы хотим, чтобы для нас создали сразу ещё и файл web.xml (рекомендую поставить галочку, если её там нет). После этого мы увидим, что структура нашего проекта пополнилась папочкой web.
Это корень нашего веб-проекта с адресом /. То есть, если мы введем в браузере адрес localhost (когда запустим, конечно же), то это будет обращение именно сюда, в корень веб-проекта. Если введем localhost/addUser, то в папочке web будет искаться ресурс с названием addUser.
Главное, надо понять, что папка web — корень нашего проекта, когда мы его зальем на Tomcat. Сейчас у нас есть определённая структура папок, но в готовом проекте, который мы будем заливать, она будет немного другой, и именно папочка web там будет корнем.
В web лежит обязательная папка с названием WEB-INF, где находится файл web.xml, который мы просили создать на прошлом шаге. Откроем его.
Как видим, в нем пока нет ничего интересного, одна только «шапка». Кстати, если бы мы не просили его создавать, нам бы, возможно, пришлось создавать его вручную, то есть набирать «ручками» всю эту «шапку», или, в крайнем случае искать готовый вариант в интернетах. Для чего нужен web.xml? Для маппинга. Здесь мы распишем для Tomcat, какие url-запросы передавать на какие сервлеты. Но это все позже, пока оставляем его пустым. Ещё в папочке web есть файл index.jsp. Откроем его.
Это файл, который будет выполнен по умолчанию, так сказать. То есть когда мы запустим проект, то именно его и узреем. По сути, jsp — обычный html-файл, с той разницей, что в нём можно выполнять java-код.
Немного про статический и динамический контент
Статический контент — такой, который не меняется со временем. Всё то, что мы написали в html файле написали — то и будет отображаться без изменений. Если мы написали hello world — то эта надпись отобразится и как только мы откроем страничку, и через 5 минут, и завтра, и через неделю, и через год. Она не изменится. Но что, если мы хотим на страничке вывести текущую дату? Если мы просто напишем «27 октября 2017 года» — то и завтра мы увидим такую же дату, и через неделю, и через год. А хотелось бы, чтобы эта дата была все-таки актуальна. Именно тут нам и приходит на помощь возможность выполнять какой-то код прямо внутри страницы. Мы можем получить объект даты, привести его к нужному нам виду и вывести на странице. Тогда каждый день когда бы мы не открыли страничку — дата будет всегда актуальна. Если нам нужен только статический контент — то нам достаточно обычного веб-сервера и html файлов. Никакой джавы, мавенов, томкатов нам и не нужно. Но если мы хотим использовать динамический контент — вот тут то нам все это и пригодится. Но пока вернемся к нашему index.jsp. Давайте укажем вместо стандартного заголовка что-то свое, например «My super web-app!», а в теле напишем например «I’m alive!». Мы уже почти готовы к тому, чтобы запустить наш проект! Но, к сожалению, привычный зеленый треугольничек для запуска программы у нас не активен.
Нажмем на кнопку слева от него (указал на скрине красной стрелочкой) и выберем Edit configurations… Откроется окно, где нам предлагают нажать на зеленый плюсик чтоб добавить какую-то конфигурацию. Нажмем на него, он находится в левом верхнем углу окна.
Выберем пункт Tomcat Server и подпункт Local. Откроется окно со множеством всяческих параметров, но нас почти все устраивает и дефолтное.
Можем как-нибудь красиво назвать нашу конфигурацию вместо стандартного Unnamed (в самом верху). Так же необходимо проверить, что идея успешно нашла томкат у нас в системе (вы же его перед этим уже скачали и установили, да?). Если не нашла (что вряд ли) — нажимаем стрелочку вниз и выбираем где он у нас установлен, ну или же другую версию, если у вас их несколько. У меня он один и уже установлен, поэтому выглядит все так, как на скрине. И в самом низу окна видим, что светится предупреждение, что пока нет ни одного артефакта, предназначенного для деплоя на сервер. А справа от этой надписи кнопочка, которая предлагает этот недочет исправить. Жмем на нее и видим, что идея сама все нашла, сама все создала, чего ей не хватало, и сама все настройки проставила.
Видим, что нас со вкладки Server перебросило на вкладку Deployment, в разделе Deploy at the server startup у нас уже указан артефакт, который надо деплоить, ну а внизу указано, что перед деплоем этот артефакт будет билдиться. Apply, Ok. И видим, что во первых, внизу окна появился раздел с нашим локальным сервером томкат, в который будет помещен наш артефакт. Свернуть этот раздел можно нажав на соответствующею кнопку в правой части окна.
Так же видим, что зеленый треугольничек для запуска уже активен. Для тех, кто хочет все проверить — можно нажать на кнопку с настройками проекта (справа от кнопок запуска, помечена красной стрелкой), перейти в раздел Artifacts и убедиться, что артефакт действительно создан. Его не было до того момента, пока мы не нажали ту кнопку Fix, но теперь все ок. И такая конфигурация нас вполне устраивает. Если в двух словах чем отличается my-super-project:war от my-super-project:war exploded — так это тем, что my-super-project:war создаст только один файл war (который является просто архивом), а вариант с exploded — это просто «распакованный» war. И именно такой вариант лично мне более удобен, так как позволяет быстрее деплоить мелкие изменения на сервер. По сути, артефакт — это и есть наш проект, только уже скомпилированный, и в котором изменена структура папок так, чтобы его можно было выкладывать уже напрямую на томкат. Выглядеть она будет примерно вот так:
Ну что ж, теперь все готово для запуска нашего проекта. Жмем заветную зеленую кнопочку запуска и наслаждаемся результатом! 
WAR-файлы и Java-приложения со встроенными серверами
Большинство серверных Java-приложений (например, веб-или сервис-ориентированных) предназначены для работы в контейнере. Традиционный способ упаковки этих приложений для распространения — это объединение их в файл WAR. Это не более чем ZIP-архив со стандартной компоновкой каталогов, содержащий все библиотеки и зависимости уровня приложения, необходимые во время выполнения. Этот формат в основном совместим и может быть развернут на любой серверный контейнер, который вам нравится, Tomcat или Jetty, JBoss или GlassFish и т. Д.
Однако есть еще одна школа мысли, которая полностью переворачивает эту модель с ног на голову. При таком подходе приложения Java упаковываются для выполнения из командной строки, как любое обычное приложение. Вместо того, чтобы развертываться в контейнере, встроенный контейнер развертывается внутри самого приложения!
Встроенное приключение
Обычно я использую Eclipse в своей собственной среде разработки и указываю на локальный экземпляр Tomcat для тестирования веб-приложений. Однако я хотел поддержать читателей, которым было удобнее использовать IntelliJ, Netbeans или вообще не использовать IDE. Поэтому я решил, что мой скрипт сборки должен встраивать тестовый сервер, чтобы читатели могли запускать примеры без установки или настройки чего-либо.
Использование встроенного сервера с Maven
Моей первой целью было просто запустить сервер из сценариев сборки Maven, чтобы читателям не пришлось устанавливать сервер или интегрировать его в свою среду IDE. Я видел, как это было сделано раньше, и было просто добавить Jetty Maven Plugin в POM проекта. Читатели должны иметь возможность создать пример приложения и запустить его за один шаг с помощью команды: