ZeroTurnaround Blog

Product Updates, Company News & Fun

JRebel and Jelastic: The Silver Lining for Your Java Cloud

Why should I know about JRebel?

For you folks hearing about us for the first time, JRebel is Java’s most popular redeploy killer productivity tool for Java developers that instantly updates the running application whenever changes are made to class structures, resource files and framework configuration files.

Using JRebel, developers can eliminate the need to build and re-deploy the application during development, saving an average of 10.5 minutes out of each coding hour, according to a recent report on Java EE Productivity. This comes out to over 5 work weeks each year – which is over 1 month salary for each developer on a team.

JRebel 5.0 was just released and introduces a new functionality called JRebel Remoting (fresh out of Beta) that enables JRebel to be used in the scenarios where the application is running in remote environments.

With the remoting feature it will be very easy to develop and test Java applications in cloud environments, and Jelastic PaaS is totally suitable for this. Jelastic is a highly-scalable, cloud-based Java host platform that we’ve been following with interest for some time at ZeroTurnaround.

So that’s why we are excited to show you how to setup and configure JRebel in Jelastic. Yee-freakin’-ha!

Installing JRebel to Jelastic PaaS

First, we need an environment that we’ll use to host the application. In the development scenario, it is sufficient to have only one container to which to deploy the application. Let’s describe the procedure for Tomcat, the most widely used application server according to the recent Developer Productivity Report 2012.

Once the environment is created, we can install the JRebel agent into the environment. To do that, we have to upload jrebel.jar from JRebel distribution. Don’t forget the license file which has to reside in {user.home}/.jrebel directory:

Next, we have to enable the JRebel agent for the container that we’ll use to deploy the application. Jelastic has introduced the support for custom JVM properties some time ago and we’ll leverage this feature in order to configure JRebel. The variables.conf file is the one that we have to modify for this matter.

Besides the -javaagent parameter, in order for the remoting functionality to work, we have to enable the “JRebel remoting plugin” using the special JVM argument: -Drebel.remoting_plugin=true. It is useful to enable JRebel logging in order to check if JRebel was installed correctly.

Once the variables.conf is modified and saved, Tomcat node requires a restart in order to apply the new configuration parameters. After the container is restarted, if JRebel was installed correctly, we’ll see jrebel.log – meaning that JRebel agent has bootstrapped with the container and started to work as expected.

N.B! Setting JRebel for Jetty isn’t any different from what we did for Tomcat – there’s the variables.conf file that is used for specifying the auxiliary JVM arguments. Installing JRebel for Glassfish is slightly different as instead of variables.conf Glassfish uses domain.xml configuration file. So we can either modify the configuration file, or set the arguments via Glassfish administration console.

Configuring The Application

JRebel Remoting requires two configuration files to be included into the deployed package: rebel.xml and rebel-remote.xml. JRebel usually requires the rebel.xml configuration file in order to map the running application back to the workspace, so that the classloaders would be able to see the changes made to the project files directly.

The rebel-remote.xml configuration file is specifically required for the remoting functionality to work. It is a very simple configuration file containing two parameters, the ID of the module and the URL, where the application is accessible.

Both the configuration files can be generated using JRebel plugin for Eclipse, which is available from Eclipse Marketplace.

JRebel Remoting in Action

Once both the configuration files are generated, we can package the application and deploy it to Jelastic environment.

After the application up and running we can start making changes to the project and update the application instantly with JRebel.

For the example we’re using the Petclinic demo application built with Spring Framework. Here’s what the first page of the application looks like:

Now we could make a change to the welcome.jsp that implements the first page and make it to display “Welcome to Jelastic!” instead of “Welcome”. Once the value is changed we can push the changes made to the project by calling “Sync Now” action provided by JRebel IDE plugin.

After calling the synchronization action we can observe JRebel messages in the IDE console:

Manually triggered JRebel remoting synchronization.
Scheduling JRebel Remoting synchronization for projects: petclinic
Starting manual synchronization for project: petclinic
Parsing configuration for /Users/anton/work-src/petclinic
Directory target/classes/ will be used for uploading
Directory src/main/webapp/ will be used for uploading

JRebel-Remoting uploaded changes successfully, have fun!

Usually it takes just under a second to upload the changes to the server, but it depends on the connectivity of course. Once the synchronization is complete, we can refresh the page – and voila! – the new value is there!

Currently, the remoting functionality is backed by IDE plugin which is available for Eclipse and the plugins for IntelliJ and NetBeans are to follow very soon.

With the release of JRebel 5.0, our newest remoting feature matches up with Jelastic to give developers working both locally and remotely the chance to taste the sweet musk of JRebel’s zero-downtime classreloading magic.

(Seriously: We need people trying out JRebel Remoting, hacking it apart and telling us what is and isn’t working. Please help us out! :-)

  • Filippo Pacifici

    Great post, I will try it out soon,
    but how does it work if you have more than one tomcat instance? Are the modifications applied on all of them or only on one instance? And what if I create a new instance after having reloaded some classes? Does the new instance take into account the modifications as well?

  • arhan

    If you have more than one tomcat instance, then your tomcats are behind the loadbalancer and that it is a problem. 
    In Jelastic you can assign static IPs to the operational nodes and then you’re good. But this is quite costly and doesn’t make sense. To work with multiple nodes with loadbalancer, the loadbalancer needs to be tuned to support this kind of scenario on Jelastic side.