You will then need to modify the startup procedure for the application server itself (in our case, JBoss) in order for JRebel to work. In addition to this, you will then need to build the module in order to perform the minification/aggregation process again.Īfter you finish configuring JRebel to work with all of the modules for which you would like to hot deploy changes, you need to perform a full build and deploy of the application. For these applications, you will need to configure the rebel.xml file to point to the location of the minified/aggregated files instead of the source location (most likely under the target/ directory instead of the src/ directory for the module). However, in many applications (including the one that we are developing on my current project), the JavaScript is minified and aggregated before being deployed to the server. In this scenario, JRebel will detect and deploy changes to the file as soon as the file is saved. If you are simply deploying these static resources “as is” to the server, then the path in the rebel.xml file can simply point to the original source files. You must modify the rebel.xml file for the module containing these static resources for JRebel to work properly (see the JRebel documentation for information about how to do this). In addition to supporting hot deployments of Java classes, JRebel also supports reloading static resources such as JavaScript, Velocity templates, and HTML. This file contains the full path to the target/classes/ directory, and must be included in the artifact that is deployed to JBoss (typically something like a JAR or WAR file). This file can either be created by using an IDE plugin to generate this file for modules within your project (JRebel provides a plugin for Eclipse, IntelliJ, and NetBeans) or by using a Maven plugin to automatically generate this file as part of your Maven build. You tell JRebel which directory to monitor for class file changes by creating a rebel.xml configuration file. In order for JRebel to detect changes in the build output directory it must know where this directory is located. If there is a change to any of the class files in this directory, then JRebel will update the classes in the container’s JVM to reflect those changes. In Maven, this is the target/classes/ directory of your Java project. JRebel works by monitoring the directory that contains the class files that are produced as part of a build. In order to enable developers to be more productive, we decided to try using JRebel, a tool created by ZeroTurnaround that allows developers to see the effect of their code changes immediately. It is important to get quick feedback when working in order to maintain flow and productivity, and this wait time clearly violates that principle. This means that after a developer makes a change to the code, they must wait at least this long (in addition to the amount of time that it takes to get to the correct context in the application to test the change that they are going to make) to see whether the changes that they made achieved the desired result. This application server takes about 1.5 minutes to start. On our current project, we are using a JBoss application server to host the services that the application needs to function.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |