Blog

Although this tutorial concerns the Tomcat container, exactly the same instructions also can be used for JBoss and Jetty containers.

Compared to other containers out there, the Tomcat web container is one of the fastest when it comes to startup and redeploy times. Still, in a survey we conducted, developers estimate spending 18% of their coding time (about 145 hours annually, per developer – somewhere between 3-4, full, 40-hour workweeks) waiting for applications to redeploy. JRebel eliminates the need to redeploy in 80% of situations, and it’s easy to get started. In the embedded video you can take a quick look at how coding looks when using JRebel.

Tutorial

In this tutorial we explain how to install and use it step-by-step. We assume that you are using Eclipse 3.x with Tomcat 5.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

Contents:

• STEP 1: Install JRebel
• STEP 2: Installing JRebel Eclipse IDE plugin
• STEP 3: Make a rebel.xml for your application
• STEP 4: Configuring the Eclipse WTP IDE
• STEP 5: Configuring the Eclipse IDE
• STEP 6: Success!

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

STEP 2: Installing JRebel Eclipse IDE plugin

The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.

STEP 3: Make a rebel.xml for your application

In order to do it’s magic, JavaRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).

If you use Maven you can use the JavaRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

In 99% of cases, you probably use one module per project. In these cases, the JavaRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:

Click on your project and pick Generate rebel.xml.

Repeat this for all projects that you’d like to update with JRebel.

If you’d like to use one rebel.xml for your whole team, start with the generated rebel.xml, then replace the absolute paths to your workspace with a system property. JavaRebel will expand expressions like “${myProject.root}” in rebel.xml to a system property that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject. This allows to you to use a single configuration for everyone and then customize it when starting the server.

STEP 4: Configuring the Eclipse WTP IDE

You may skip this step if you run Tomcat outside of the Eclipse IDE.

Open the Servers View and double click the Tomcat Server that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

Open Publishing and choose Never publish automatically.

It may seem strange to disable automatic publishing, but as JRebel will take care of updates from now on it would just slow you down.

Open JavaRebel Integration and check Enable JavaRebel agent.

STEP 5: Configuring the Eclipse IDE

Go to Window » Preferences and from there to Java » Debug » Step Filtering.

Check Use Step Filters, Filter synthetic methods, and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.

Now go to Project » Build automatically and make sure it is checked.

STEP 6: Success!

To check that the installation was successful, access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

• Eclipse Plugin Tutorial
• Installation manual
• Configuration manual
• Maven Plugin configuration manual

These results are preserved for comparison, but see the later report for a full analysis of the completed survey.

Last week we asked a few questions regarding Java EE development, containers and redeploy and restart times. It was surprising to see how quickly people responded — I suppose it’s becoming a hot topic!

We had to draw the line for our analysis somewhere, so we took the first 700 responses and created the charts below. If there is a significant change in the number of responses, we’ll update these charts with new results. The 2 minute survey is still running here.  Feel free to fill it out if you haven’t already.

If you’d like to analyze the results for yourself, we have provided a copy of the data. This data may be updated as new responses come in. Email addresses have been removed from this data set.

We hope this info provides interesting insights into the world of Java EE containers and development productivity! Since we’re not professional surveyors there may be some flaws in the data and in our interpretation — so we mention some of them below, and you’re welcome to analyze the data yourself :-)

“Most Often Used Java EE Containers”

We asked, “What container do you use on your largest current Java EE project?”, which is slightly different than the chart title. Unfortunately, we didn’t clarify the difference between containers used for development and production, so answers here may be mixed – we’ll do better next time.

As usual, there was a long tail of answers. Any answer that did not receive at least 7 votes (1% of the total votes in the survey) was not put on the pie chart. The omitted containers were:

• Tmaxsoft JEUS- 4
• SAP NetWeaver- 3
• Iona/Progress Artix- 1
• zeus 4.x- 1
• Sybase EAServer- 1
• Impala- 1
• Adobe JRun- 1
• Jonas 4.x- 1
• Assorted earlier versions of containers listed in the chart- 13

“How long is the average container redeploy + app restart?”

Actual question asked: “How long does it take to restart your container and redeploy your app?” Now, you would think that folks who answered “I never redeploy” in the next question would have had a challenge with this one, since, well… they never redeploy. Apparently they overcame that challenge. They may have answered randomly, or, if they are JavaRebel users, answered with the amount of time that it used to take to redeploy/restart, before they eliminated redeploys.

“How often do Java EE developers redeploy, per hour?”

Actual question asked: “In an hour of coding, how many times do you redeploy?” Unfortunately, we made an error here. When choosing how many times you redeploy, folks who know for a fact that they redeploy exactly seven (7) times per hour faced a dilemma. Hopefully they were able to overcome this and err on the side that felt more reasonable to them: 5-7 or 7-10.

For the folks who answered, “I never redeploy”, we asked some of them how they did this. Responses were:

1. “I’m not the guy that does the redeploys”
2. “We develop on embedded jetty & activemq & atomikos in debug mode instead of nearly unusable target OracleAS. So of course we need redeploy or restart jetty as usual, but not the OAS.”
3. “I’m in the very early stages of a project so a lot of out time is spent coding and testing without redeploying – typically I redeploy 3-4 times per hour”
4. “We use JavaRebel and it’s awesome” – which led me to believe that I should have asked people if they use JavaRebel right up front, since that may bias the numbers somewhat.

Java EE Container Specific Productivity Information
For the next few container-specific charts, there is the potential for a slight error when it comes to Jetty, Oracle, and Caucho’s containers, for the simple reason that there were not a lot of people in our survey reporting numbers for them. Jetty was used by only 27 respondents, Oracle 20, and Resin had 10. With numbers like these it’s easy to sway results. Of course, the 207 results from Tomcat users isn’t a HUGE number, but at least averages are more accurate. Solution: more respondents. The survey is still live, here.

How long does container X take to redeploy?

Does container X affect incremental development?

We thought that containers that redeploy quickly would lead to more incremental development – and this was generally true, but there were exceptions.

Time spent on redeploys, per hour, with container X

Calculated like this:
Time spent redeploying in an average hour = Average number of redeploys per hour of coding x Average length of redeploy (see “How long is the average redeploy” chart).

Percentage of development time spent redeploying with container X

Calculated like this:
Percentage of coding time spent redeploying = Time spent redeploying in an average hour of coding divided by 60 (mins)

“Annually, How much time do Java EE developers spend redeploying containers & restarting apps?” (in hours)

We wanted to estimate this number quite conservatively, so we took the amount of time spent redeploying in an average hour of coding and added that up over a year, based on these assumptions:

1. A developer rarely actually codes for 8 full hours per day. We should account for non-coding days, meetings, coffee breaks, foosball, email, twitter, etc. We assumed an average of 4 hours of coding per day, 5 days per week.
2. We also assumed that some people get (and use) holidays and vacations, and have other reasons why they don’t code everyday. These reasons would a) reduce the amount of full weeks in the year, and b) reduce the average # of hours of coding per day. To account for these, we based a year on 40 work weeks instead of 52. Those 12 weeks should account for almost anything else you can throw in here to reduce avg weekly/daily coding hours. We figure that if you’re not coding 4 hours per day, 5 days per week, for at least 40 weeks a year, then you probably didn’t answer this survey. If we’re off here, or this is not conservative enough, let us know.

It would be interesting to know what this costs, in terms of development team budget. You can estimate it for your team here.

Survey Round-up: We were impressed to receive over 700 responses so quickly and are curious to know what you think of the results!  To start – we’re curious about the folks who spend an average of 81 to 309 hours per year redeploying… Is this something that is considered acceptable in terms of development time used?

I don’t want to do anything TOO “marketingy” here, but I do have to mention that JavaRebel eliminates the need to redeploy in most redeployment situations (see Container Support and the Comparison to HotSwap and Hot Redeploy).  From these survey results, that looks like an an extra 2 to 8 weeks of development time per year, or reducing the time spent coding on a project by 3.8% to 15.4%.    <cough> And it’s easy on the wallet. Download the Free 30 Day Eval <endcough> (see Pricing if interested)

Ok, I mentioned it.  Let me know if I can improve this survey in any way.

Dave