JRebel Quickstart

10 Янв
2012

В прошлой статье я немного рассказал о JRebel и для чего его можно использовать. Теперь попробую описать как можно попробовать 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 в своём проекте. Если есть вопросы — пишите — с удовольствием отвечу!
По материалам Хабрахабр.



загрузка...

Комментарии:

Наверх