I personally do not like servers running in IDEs. I prefer my local environment to be as close as possible to the production environment, so I run SSL, Apache with mod-jk , different IPs for different website projects etc. I also debug all of them and in some cases at the same time without an IDE crashing or giving me extra trouble. Clearly the second advantage of this method is that when you are in needs to debug your real deployment environment you follow the same procedure: Just prepare your server to listen to a debug port and connect to it from Eclipse.
Here are the steps I followed to get JRebel replace the included HotSwap JVM capability to allow remote hot code replacement. This was tested with JRebel 4.6.2 + Eclipse Helios + Tomcat 7.0.22 + Maven 1.6.0-31.
- Hit Eclipse "Help-Eclipse Marketplace" menu option. Look for JRebel and install it
- From Eclipse Preferences choose JRebel and launch the configuration wizard (In version 5 "JRebel Config Centre" link will open all you need within Eclipse interface while previous versions would open a separate java app for configurations). Click on the link so you register and get your license key. Get back and paste it.
- You are presented with some options like running your tomcat locally in Eclipse. I use an external tomcat instance so I unchecked that option, then I ignored the instructions to create a new startup and catalina shell scripts. I want to use the original server scripts.
- Look at the "Embedded JRebel plug-in" link to find out where jrebel.jar is in your system
- Add jrebel.jar and necessary options to setenv.sh:
JAVA_OPTS="-javaagent:/Users/nestor/eclipse-helios/plugins/org.zeroturnaround.eclipse.embedder_18.104.22.168205021255/jrebel/jrebel.jar -Drebel.remoting_plugin=true -Drebel.hotswap=false $JAVA_OPTS"
- From Eclipse Preferences - Java - Debug uncheck all "Hot Code Replace" options
- Right click on Project and select properties, locate "Maven-Lifecycle Mapping" and insert "clean" as the first goal to "Goals to invoke after project clean"
- Make sure Eclipse will build your project automatically: Check "Project-Build Automatically" menu option
- Right click the project and choose "JRebel - Generate rebel.xml" It will generate the file inside the main resources folder
- If your server JVM is running in a different machine than your Eclipse IDE then right click the project and choose "JRebel - Generate rebel-remote.xml" It will prompt for the url you use to reach your project. Like above the file gets generated by default in main resources which means they both will end up in the classpath. Review the files for correct URLs and id. I use as id the name of the project. If you change id please look into my previous post.
- Recompile and redeploy your project so the xml file(s) get to the server
- Exclude rebel.xml (and rebel-remote.xml if it applies) from your versioning control. You do not want to mess with other developers settings unless you all use the same IDE, OS etc.
- If your server JVM is running in a different machine than your Eclipse IDE then right click the project and chose "JRebel - JRebel Remoting: Automatic Sync". You should get a "Jrebel-Remoting uploaded changes successfully, have fun!" message
- Connect to the remote debug port from Eclipse (From Java Perspective, Menu | Run | Debug Configurations | Remote Java Application | Right click and select New | give it a name like "Local" | set Host like localhost | Port like 8000 | click Debug. From that moment on the option will be available when clicking the bug icon arrow), set your break point and hit the page associated to it. You will be able to debug just as you are used to
- Now overload the method holding the breakpoint or create a new one that gets called as well, that way you can see that adding a new method does work. Both the the old and the new methods will be accepted by the server and available locally for debugging. No more redeployments.
Notice that you need to install the rebel xml files in every project you want to hot deploy. For instance if you divide your project in a WAR and a JAR then both will need to be configured to use jrebel properly.
Finally it is always better to make your changes when a breakpoint has already being reached by the debugger, in that way the change will trigger the reload and you can even say so from the changes in the Eclipse code line debugger pointer. However this option might be broken in version 4 as reflected in this "apparent" bug. Apparently it has been fixed in version 5 as i documented there.
Buying JRebelA license key will be sent to you and from Eclipse Preferences, JRebel, open the link to configure. In the latest JRebel 5 licences are activated from the "JRebel Config Centre" which is the only link. In previous versions there were a couple of links, one of which would open a custom Applet. Now the whole process is integrated inside the Eclipse GUI. In order to activate the new license in the server click "Add External Server" or "Add remote Server" depending if you are running the external server locally or remotely then the JAVA_OPT options will show up. Note that I had to tweak the hints as explained in this possible bug:
-javaagent:"/Users/nestor/eclipse-helios/plugins/org.zeroturnaround.eclipse.embedder_5.0.0.RELEASE-201206201947/jrebel/jrebel.jar" -Drebel.workspace.path="/Users/nestor/eclipse-workspace-test" -Drebel.log.file="/Users/nestor/.jrebel/jrebel.log" -Drebel.properties="/Users/nestor/.jrebel/jrebel.properties"
Updating JRebel for EclipseIn Eclipse go to "Menu|Help|Eclipse Marketplace" and click the "Update" button for JRebel. An Eclipse restart will be needed. I have tested this going from JRebel 4 to 5. Do not forget to update the JAVA_OPTS to point to the newest version of the library. For example below is the path for the new JRebel5 in my local OSX Eclipse dev environment: