Горячее развертывание Eclipse Kepler и JBoss Wildfly

Я пытаюсь использовать eclipse kepler для Java EE 7. Я уже установил JBoss Tools и успешно добавил JBoss Wildfly в качестве сервера. Однако мои изменения не развертываются автоматически. В любом случае приложение может быть развернуто автоматически, как при использовании Glassfish?


person zulqarnain    schedule 26.11.2013    source источник


Ответы (5)


Используя Eclipse, дважды щелкните ваш сервер WildFly, чтобы изменить следующие свойства:

  1. Публикация: выберите «Автоматически публиковать после сборки». Мне также нравится менять интервал публикации на 1 секунду.
  2. Поведение при перезагрузке приложения: установите флажок "Настроить перезагрузку приложения..." и измените шаблон регулярного выражения на \.jar$|\.class$.

Вот и все. Удачи!

person Valdemar    schedule 25.02.2014
comment
+1, но, к сожалению, у второго варианта есть серьезный недостаток: теряется все состояние приложения. - person G. Demecki; 10.09.2014
comment
Одна вещь, которая заставила меня работать: не развертывать в виде сжатых файлов. В свойствах eclipse Wildfly НЕ устанавливайте флажок Развертывать проекты как сжатые архивы. - person Edu Castrillon; 22.08.2017

И @varantes, и @Sean по сути верны, но эти ответы не полны.

К сожалению, единственный способ в среде Java-сервера обеспечить полное горячее развертывание без простоев — это использовать платный JRebel или бесплатный инструмент пружинный.

Но для небольшого проекта есть несколько способов ускорить работу за счет частичного горячего развертывания. По сути:

  1. Если включен параметр Автоматически публиковать при изменении ресурса, изменения внутри *.html, *.xhtml файлов сразу же отражаются, как только вы обновляете браузер.
  2. Чтобы горячее развертывание работало и для файлов *.jsp, вам следует внутри ${wildfly-home}/standalone/configuration/standalone.xml внести следующие изменения:
    <jsp-config/>
    заменить на:< бр> <jsp-config development="true"/>

перезапустите сервер и наслаждайтесь горячим развертыванием веб-файлов.


Но при изменении *.java исходных файлов возможно только частичное горячее развертывание. Как заявил @varantes в своем ответе, включение Application Reload Behavior с шаблоном регулярного выражения, установленным на \.jar$|\.class$, является вариантом, но имеет серьезный недостаток: перезапускается весь модуль, таким образом:

  1. Это занимает некоторое время (в зависимости от размера модуля).
  2. Все состояние приложения теряется.

Так что лично я не одобряю это решение. JVM поддерживает (в режиме отладки) замену кода для тел методов. Так что, пока вы модифицируете только тела существующих методов, вы чувствуете себя как дома (нулевое время простоя, изменения отражаются немедленно). Но вы должны отключить автоматическую публикацию в настройках сервера, иначе состояние приложения все равно будет уничтожено этой повторной публикацией.

Но если вы интенсивно создаете Java-код (добавляете классы, аннотации, конструкторы), то, к сожалению, я могу только порекомендовать установить публикацию на Никогда не публиковать автоматически (или отключить сервер), и когда вы закончите свою работу с файлами Java, затем вручную перезапустите ваш модуль (или включите сервер). Вам решать.


Он работает для небольших Java-проектов, но для более крупных JRebel бесценен (или просто подпружинен), потому что всех подходов, описанных выше, недостаточно. Также из-за таких проблем такие решения, как Rails/Django/Play! Фреймворк приобрел столь огромную популярность.

person G. Demecki    schedule 10.09.2014
comment
Даже с Play! Framework, если проект вырастет до приличного размера, вы снова столкнетесь с теми же проблемами. - person Anton Arhipov; 12.09.2014
comment
@AntonArhipov Я не понимаю, почему. Вы имеете в виду проблемы с горячей заменой кода? Я так не думаю (хотя никогда не видел такого большого проекта Play!). Или вы имеете в виду просто долгий запуск? - person G. Demecki; 12.09.2014
comment
В частности, горячая замена кода. Я в команде JRebel (для протокола), и мы никогда не рассматривали возможность реализации поддержки JRebel для этих причудливых фреймворков. Но теперь пользователи все больше и больше начинают спрашивать о поддержке - приложения стали большими, а перезагрузка нативного фреймворка не поспевает. - person Anton Arhipov; 12.09.2014
comment
@ G.Demecki Ты уже дважды помог мне. Я только что нашел этот ответ и понял, что уже нашел и проголосовал за него раньше! Извините, я не могу проголосовать за вас дважды :) Спасибо! - person Stijn de Witt; 19.11.2015

Я предполагаю, что вы используете последнюю версию Wildfly (8.0 Beta 1 на момент написания статьи).

В файле конфигурации standalone.xml найдите ‹jsp-config/›. Добавьте атрибут development="true", и он должен быть развернут в горячем режиме. В результате конфиг будет выглядеть так:

<jsp-config development="true"/>
person umphy    schedule 01.12.2013
comment
Привет @Sean Я сделал это, но когда я изменил исходный файл Java, я не заметил изменений. Однако, если я изменяю xhtml, это отражается. - person zulqarnain; 02.12.2013

Добавьте атрибуты (разработка, интервал проверки, интервал проверки модификации, перекомпиляция при сбое) в файле конфигурации в xPath = //servlet-container/jsp-config/

<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
    <jsp-config development="true" check-interval="1" modification-test-interval="1" recompile-on-fail="true"/>
</servlet-container>

(Работает в WildFly-8.0.0.Final)

person PeterB    schedule 12.02.2014

Запустите сервер в режиме отладки, и он будет отслеживать шансы внутри методов. Другие изменения Будет предложено перезапустить сервер.

person erickdeoliveiraleal    schedule 21.01.2017