January 10, 2012 at 00:11JRebel Quickstart
In the last article, I talked a bit about JRebel and what it can be used for. Now I’ll try to describe how you can try to use JRebel, step by step.
For example, take the Petclinic application , the source code of which can be found on GitHub . I will use my favorite IntelliJIDEA as an IDE .
First, install the JRebel plugin for IntelliJIDEA. Go to Settings -> Plugins , click Browse repositories ... , we can easily find the JRebel Plugin in the list of plugins - you can install.
During the first installation, of course, you will need to register.
Get the project code for the exercise.
Open the resulting project in the IDE ( as a Maven project ).
1. Generate rebel.xml It is best to
save rebel.xml to the directory that will be marked as the directory for the sources in this project, ie either in src / main / java or in src / main / resources . This is necessary so that after building the project, rebel.xml would be in WEB-INF / classes of the deployed application.
2. Add main / java / resources to rebel.xml
, since this plugin generates rebel.xml , the paths of which are obtained based on where the source code will be compiled ( target \ classes ) and where the web part files of the application are located ( main / webapp), in some cases additional paths have to be added manually. At the moment, there is just such a case - the src / main / resources directory will not be included by the generator in rebel.xml . And in this directory there are some resources that we will want to change later.
After adding the appropriate element, our new rebel.xml will look like this:
This approach was chosen in order to indicate some nuances. In fact, if Maven is used to build the project, then it is more reasonable to use a special plugin to generate rebel.xml , which can be configured accordingly.
We will run the application on Tomcat 7. To do this, select Edit Configurations ..
Choose the configuration Tomcat -> Local
Next, add the artifact for deployment. The choice suggests deciding whether the application will be deployed in packaged or unpacked ( exploded ) mode. This choice is currently unprincipled. Let's say that we have selected the unpacked mode.
After the done manipulations, we are ready to start the project.
When starting up, in the launch console we will see the following:
That is - everything is fine - JRebel was turned on. Further, as the application development process goes on, you will see messages indicating that JRebel will track changes in some directories:
Это те самые директории которые были записаны в rebel.xml. В момент загрузки приложения, первое, что сделает JRebel — попробует найти наш конфигурационный файл в WEB-INF/classes, и, в случае успеха, попросит загрузщик (classloader) искать ресурсы по тем путям, которые были найдены в rebel.xml. Если искомый ресурс не будет найден в тех каталогах, которые указаны в rebel.xml, то будет сдалан “откат” на обычную логику загрузщика, т.е. ресурс будет искаться из развёрнутого приложения.
Let's see first what we have in the beginning, by opening the application at localhost : 8080 We will
go to the Find owner link , then Add owner , and try to save the empty values in the form. The validation result is visible in the picture below:
Let's try to make some changes to the code so that it is easy to see the result. The OwnerValidator class is responsible for checking the form fields . We take out part of the checks in a separate method, and for clarity, we remove the address check at all. Those. as a result of the changes, a new method was added to the OwnerValidator class, with slight changes in the original logic, which will be seen the next time you try to save the data.
The modified class should be copied, after which we can try to save empty data, as a result of which we will see the following result:
As you can see, the Address field is no longer required, as expected. In the console, you will see the following messages from JRebel:
When you call the methodOwnerValidator # validate checked the file for updating, and since the code compiled, JRebel determined that the class should be updated. Thus, we can see that JRebel updates classes only at the very last moment, before the call - so to speak, in lazy mode.
Now let's try something more interesting. Suppose we would like to “hang up” another class on the same form for verification. Let's call it FirstNameValidator . We will also add a new entry to messages.properties.
Moreover, I would like to add a new class using the Spring features . Add a new component to petclinic-servlet.xml :
The last step is to add the component using the @Autowired annotationto the controller code, which is implemented in the AddOwnerForm class :
In total, 4 files were changed:
Now you need to compile the new and changed classes, and you can try filling out the form again. When you enter a value other than “Anton” in the First name field , the check will give “Should be Anton” - the same message that we added to messages.properties and use in FirstNameValidator , which, in turn, was added to the application using Spring .
I hope this little guide will help those who are interested and want to try using JRebel in their project. If you have questions - write - I will be happy to answer!
For example, take the Petclinic application , the source code of which can be found on GitHub . I will use my favorite IntelliJIDEA as an IDE .
Training
JRebel4IntelliJ
First, install the JRebel plugin for IntelliJIDEA. Go to Settings -> Plugins , click Browse repositories ... , we can easily find the JRebel Plugin in the list of plugins - you can install.
During the first installation, of course, you will need to register.
Petclinic
Get the project code for the exercise.
git clone git://github.com/xebia-france-training/xebia-petclinic.gitOpen the resulting project in the IDE ( as a Maven project ).
Small setting
1. Generate rebel.xml It is best to
save rebel.xml to the directory that will be marked as the directory for the sources in this project, ie either in src / main / java or in src / main / resources . This is necessary so that after building the project, rebel.xml would be in WEB-INF / classes of the deployed application.
2. Add main / java / resources to rebel.xml
, since this plugin generates rebel.xml , the paths of which are obtained based on where the source code will be compiled ( target \ classes ) and where the web part files of the application are located ( main / webapp), in some cases additional paths have to be added manually. At the moment, there is just such a case - the src / main / resources directory will not be included by the generator in rebel.xml . And in this directory there are some resources that we will want to change later.
After adding the appropriate element, our new rebel.xml will look like this:
This approach was chosen in order to indicate some nuances. In fact, if Maven is used to build the project, then it is more reasonable to use a special plugin to generate rebel.xml , which can be configured accordingly.
We work with JRebel
Launch
We will run the application on Tomcat 7. To do this, select Edit Configurations ..
Choose the configuration Tomcat -> Local
Next, add the artifact for deployment. The choice suggests deciding whether the application will be deployed in packaged or unpacked ( exploded ) mode. This choice is currently unprincipled. Let's say that we have selected the unpacked mode.
After the done manipulations, we are ready to start the project.
When starting up, in the launch console we will see the following:
That is - everything is fine - JRebel was turned on. Further, as the application development process goes on, you will see messages indicating that JRebel will track changes in some directories:
Это те самые директории которые были записаны в rebel.xml. В момент загрузки приложения, первое, что сделает JRebel — попробует найти наш конфигурационный файл в WEB-INF/classes, и, в случае успеха, попросит загрузщик (classloader) искать ресурсы по тем путям, которые были найдены в rebel.xml. Если искомый ресурс не будет найден в тех каталогах, которые указаны в rebel.xml, то будет сдалан “откат” на обычную логику загрузщика, т.е. ресурс будет искаться из развёрнутого приложения.
Исходное положение
Let's see first what we have in the beginning, by opening the application at localhost : 8080 We will
go to the Find owner link , then Add owner , and try to save the empty values in the form. The validation result is visible in the picture below:
Make changes
Let's try to make some changes to the code so that it is easy to see the result. The OwnerValidator class is responsible for checking the form fields . We take out part of the checks in a separate method, and for clarity, we remove the address check at all. Those. as a result of the changes, a new method was added to the OwnerValidator class, with slight changes in the original logic, which will be seen the next time you try to save the data.
The modified class should be copied, after which we can try to save empty data, as a result of which we will see the following result:
As you can see, the Address field is no longer required, as expected. In the console, you will see the following messages from JRebel:
When you call the methodOwnerValidator # validate checked the file for updating, and since the code compiled, JRebel determined that the class should be updated. Thus, we can see that JRebel updates classes only at the very last moment, before the call - so to speak, in lazy mode.
Now let's try something more interesting. Suppose we would like to “hang up” another class on the same form for verification. Let's call it FirstNameValidator . We will also add a new entry to messages.properties.
Moreover, I would like to add a new class using the Spring features . Add a new component to petclinic-servlet.xml :
The last step is to add the component using the @Autowired annotationto the controller code, which is implemented in the AddOwnerForm class :
In total, 4 files were changed:
- new FirstNameValidator class added
- changed existing class AddOwnerForm
- changed messages.properties
- edited by petclinic-servlet.xml
Now you need to compile the new and changed classes, and you can try filling out the form again. When you enter a value other than “Anton” in the First name field , the check will give “Should be Anton” - the same message that we added to messages.properties and use in FirstNameValidator , which, in turn, was added to the application using Spring .
Total
I hope this little guide will help those who are interested and want to try using JRebel in their project. If you have questions - write - I will be happy to answer!