В прошлой статье я немного рассказал о JRebel и для чего его можно использовать. Теперь попробую описать как можно попробовать JRebel использовать, шаг за шагом.
Для примера возьмём приложение Petclinic, исходной код которого можно найти на GitHub. В качестве IDE буду использовать свою любимую IntelliJIDEA.
Для начала установим JRebel плагин для IntelliJIDEA. Идём в Settings -> Plugins, жмём Browse repositories..., в списке плагинов без труда найдём JRebel Plugin — можно устанавливать.
При первой установке, конечно же, надо будет зарегистрироваться.
Получим код проекта для упражнения.
Откроем полученный проект в IDE (как Maven проект).
1. Сгенерируем rebel.xml
Сохранить rebel.xml лучше всего в ту директорию, которая будет помечена как директория для исходников в данном проекте, т.е. либо в src/main/java, либо в src/main/resources. Нужно это для того, чтобы после сборки проекта, rebel.xml оказался бы в WEB-INF/classes развёрнутого приложения.
2. Добавим main/java/resources в rebel.xml
По-скольку данный плагин генерирует rebel.xml, пути которого получены исходя из того, куда будут компилироваться исходники (target\classes), и где находятся файлы web-части приложения (main/webapp), то в некоторых случаях дополнительные пути приходится добавлять вручную. В данный момент как раз и есть такой случай — каталог src/main/resources не будет включен генератором в rebel.xml. А в этом каталоге как раз и находятся некоторые ресурсы, которые мы захотим менять позже.
После добавления соответствующего элемента, наш новый rebel.xml будет выглядеть так:
Данный подход был выбран с той целью, чтобы указать на некоторые нюансы. На самом деле, в случае если для сборки проекта используется Maven, то для генерирования rebel.xml разумнее использовать специальный плагин, который можно настроить соответствующим образом.
Запускать приложение будем на Tomcat 7. Для этого выберем Edit Configurations..
Выберем конфигурацию Tomcat -> Local
Далее, следует добавить артефакт для развёртывания. В выборе предлагается решить, будет ли данное приложение развёрнуто в запакованом или распакованом (exploded) режиме. В данный момент этот выбор непринципиален. Допустим, что мы выбрали распакованый режим.
После проделанных манипуляций, мы готовы запустить проект.
При запуске, в консоли запуска мы увидим следующее:
То есть — всё хорошо — JRebel был включён. Далее, по мере того как идёт процесс развёртки приложения, можно будет увидеть сообщения о том, что JRebel будет отслеживать изменения в некоторых директориях:
Это те самые директории которые были записаны в rebel.xml. В момент загрузки приложения, первое, что сделает JRebel — попробует найти наш конфигурационный файл в WEB-INF/classes, и, в случае успеха, попросит загрузщик (classloader) искать ресурсы по тем путям, которые были найдены в rebel.xml. Если искомый ресурс не будет найден в тех каталогах, которые указаны в rebel.xml, то будет сдалан “откат” на обычную логику загрузщика, т.е. ресурс будет искаться из развёрнутого приложения.
Посмотрим сначала, что мы вообще имеем вначале, открыв приложение по адресу localhost:8080
Пойдём по ссылке Find owner, далее Add owner, и попробуем сохранить пустые значения в форме. Результат валидации виден на картинке ниже:
Попробуем внести некоторые изменения в код, так чтобы было легко увидеть результат. За проверку полей формы отвечает класс OwnerValidator. Вынесем часть проверок в отдельный метод, и для наглядности уберём проверку адреса совсем. Т.е. в результате внесённых изменений в класс OwnerValidator был добавлен новый метод, с небольшими изменениями в изначальной логике, что и будет видно при следующей попытке сохранения данных.
Следует откопмилировать изменённый класс, после чего можем повторить попытку сохранения пустых данных, в результате чего мы увидим следующий результат:
Как видно, поле Address более не является обязательным для заполнения, как и ожидалось. В консоли можно будет увидеть следующие сообщения от JRebel:
При вызове метода OwnerValidator#validate была произведена проверка файла на обновление, и, поскольку код компилировался заного, JRebel определил, что надо бы обновить класс. Тем самым, мы можем видеть что JRebel обновляет классы только в самый последний момент, перед вызовом — так сказать, в ленивом режиме.
Попробуем теперь что нибудь более интересное. Предположим, нам хотелось бы на ту же самую форму “подвесить” ещё один класс для проверки. Назовём его FirstNameValidator. Также добавим новую запись в messages.properties
Более того, хотелось бы добавить новый класс используя возможности Spring. Добавим новый компонент в petclinic-servlet.xml:
Последний шаг — добавить компонен при помощи аннотации @Autowired в код контроллера, который реализован в классе AddOwnerForm:
В сумме было изменено 4 файла:
Теперь требуется скомпилировать новый и изменённый классы, и можно опробовать заполнение формы снова. При вводе в поле First name значения, отличного от “Anton”, проверка выдаст “Should be Anton” — то самое сообщение, которое мы добавили в messages.properties и используем в FirstNameValidator, который, в свою очередь был добавлен в приложение при помощи Spring.
Надеюсь, это небольшое руководство поможет тем, кто заинтересовался, и хочет попробовать использовать JRebel в своём проекте. Если есть вопросы — пишите — с удовольствием отвечу!
Для примера возьмём приложение Petclinic, исходной код которого можно найти на GitHub. В качестве IDE буду использовать свою любимую IntelliJIDEA.
Подготовка
JRebel4IntelliJ
Для начала установим JRebel плагин для IntelliJIDEA. Идём в Settings -> Plugins, жмём Browse repositories..., в списке плагинов без труда найдём JRebel Plugin — можно устанавливать.
При первой установке, конечно же, надо будет зарегистрироваться.
Petclinic
Получим код проекта для упражнения.
git clone git://github.com/xebia-france-training/xebia-petclinic.gitОткроем полученный проект в IDE (как Maven проект).
Небольшая настройка
1. Сгенерируем rebel.xml
Сохранить rebel.xml лучше всего в ту директорию, которая будет помечена как директория для исходников в данном проекте, т.е. либо в src/main/java, либо в src/main/resources. Нужно это для того, чтобы после сборки проекта, rebel.xml оказался бы в WEB-INF/classes развёрнутого приложения.
2. Добавим main/java/resources в rebel.xml
По-скольку данный плагин генерирует rebel.xml, пути которого получены исходя из того, куда будут компилироваться исходники (target\classes), и где находятся файлы web-части приложения (main/webapp), то в некоторых случаях дополнительные пути приходится добавлять вручную. В данный момент как раз и есть такой случай — каталог src/main/resources не будет включен генератором в rebel.xml. А в этом каталоге как раз и находятся некоторые ресурсы, которые мы захотим менять позже.
После добавления соответствующего элемента, наш новый rebel.xml будет выглядеть так:
Данный подход был выбран с той целью, чтобы указать на некоторые нюансы. На самом деле, в случае если для сборки проекта используется Maven, то для генерирования rebel.xml разумнее использовать специальный плагин, который можно настроить соответствующим образом.
Работаем с JRebel
Запуск
Запускать приложение будем на Tomcat 7. Для этого выберем Edit Configurations..
Выберем конфигурацию Tomcat -> Local
Далее, следует добавить артефакт для развёртывания. В выборе предлагается решить, будет ли данное приложение развёрнуто в запакованом или распакованом (exploded) режиме. В данный момент этот выбор непринципиален. Допустим, что мы выбрали распакованый режим.
После проделанных манипуляций, мы готовы запустить проект.
При запуске, в консоли запуска мы увидим следующее:
То есть — всё хорошо — JRebel был включён. Далее, по мере того как идёт процесс развёртки приложения, можно будет увидеть сообщения о том, что JRebel будет отслеживать изменения в некоторых директориях:
Это те самые директории которые были записаны в rebel.xml. В момент загрузки приложения, первое, что сделает JRebel — попробует найти наш конфигурационный файл в WEB-INF/classes, и, в случае успеха, попросит загрузщик (classloader) искать ресурсы по тем путям, которые были найдены в rebel.xml. Если искомый ресурс не будет найден в тех каталогах, которые указаны в rebel.xml, то будет сдалан “откат” на обычную логику загрузщика, т.е. ресурс будет искаться из развёрнутого приложения.
Исходное положение
Посмотрим сначала, что мы вообще имеем вначале, открыв приложение по адресу localhost:8080
Пойдём по ссылке Find owner, далее Add owner, и попробуем сохранить пустые значения в форме. Результат валидации виден на картинке ниже:
Вносим изменения
Попробуем внести некоторые изменения в код, так чтобы было легко увидеть результат. За проверку полей формы отвечает класс OwnerValidator. Вынесем часть проверок в отдельный метод, и для наглядности уберём проверку адреса совсем. Т.е. в результате внесённых изменений в класс OwnerValidator был добавлен новый метод, с небольшими изменениями в изначальной логике, что и будет видно при следующей попытке сохранения данных.
Следует откопмилировать изменённый класс, после чего можем повторить попытку сохранения пустых данных, в результате чего мы увидим следующий результат:
Как видно, поле Address более не является обязательным для заполнения, как и ожидалось. В консоли можно будет увидеть следующие сообщения от JRebel:
При вызове метода OwnerValidator#validate была произведена проверка файла на обновление, и, поскольку код компилировался заного, JRebel определил, что надо бы обновить класс. Тем самым, мы можем видеть что JRebel обновляет классы только в самый последний момент, перед вызовом — так сказать, в ленивом режиме.
Попробуем теперь что нибудь более интересное. Предположим, нам хотелось бы на ту же самую форму “подвесить” ещё один класс для проверки. Назовём его FirstNameValidator. Также добавим новую запись в messages.properties
Более того, хотелось бы добавить новый класс используя возможности Spring. Добавим новый компонент в petclinic-servlet.xml:
Последний шаг — добавить компонен при помощи аннотации @Autowired в код контроллера, который реализован в классе AddOwnerForm:
В сумме было изменено 4 файла:
- добавлен новый класс FirstNameValidator
- изменён существующий класс AddOwnerForm
- изменён messages.properties
- изменён petclinic-servlet.xml
Теперь требуется скомпилировать новый и изменённый классы, и можно опробовать заполнение формы снова. При вводе в поле First name значения, отличного от “Anton”, проверка выдаст “Should be Anton” — то самое сообщение, которое мы добавили в messages.properties и используем в FirstNameValidator, который, в свою очередь был добавлен в приложение при помощи Spring.
Итого
Надеюсь, это небольшое руководство поможет тем, кто заинтересовался, и хочет попробовать использовать JRebel в своём проекте. Если есть вопросы — пишите — с удовольствием отвечу!
