We’ve started to stabilize the long list of added features and fixes of the milestone releases of the JRebel 3.0 branch. Today we’re happy to bring you the Release Candidate 1. For a full list of changes coming up in the 3.0 release check the full changelog, RC1 changes follow:
Added OpenJPA plugin; reloads the EntityManagerFactory on configuration changes (disabled by default)
Added support for load time weaving with spring-agent
Fixed potential Classloader deadlock on Tomcat 6.0.26
Fixed NoSuchMethodError for early Spring 2 versions
This post serves as a quick introduction to the open source projects that we develop and host on our site. They are either accompanying QA software, integrations with different frameworks or our IDE plugins. All described projects are hosted at http://repos.zeroturnaround.com/svn/.
If you’ve written plugins that you would like us to host just contact support@zeroturnaround.com. If you have patches to current projects just let us know and we’ll take a look and try to get them integrated.
jr-autotest/
JRebel testing is not that simple. For example, say we want to test changing a protected field to a private static. We need to have a test that first compiles a source file with a protected field and then lets a JVM load it. Then we need to make the changes to the source, compile and make JRebel reload it. Then asserts follow :) It sounds easier said than done. This sub project hosts all the tests and a groovy script to control them all.
jr-servlettest/
See jr-autotest and think of servlets. These tests run on arbitary containers and besides testing JRebel functionality it tests the integration with different containers. The control script this time makes requests to URLs and compares the output to some predefined output.
jr-autotest-hudsonplugin/
Legacy. A year ago we were so dumb that we wrote a Hudson plugin that was able to read the output of the ANT script of the autotest and produce nice red/green buttons about which test failed/passed. Now this is quite obsolete as we have moved on to JUnit output instead.
jr-ide-support/
idea-old-plugin – source code for the Intellij debugger plugin for IDEA ver < 8 idea-plugin – our current up-to date plugin for IDEA 8+ eclipse – all eclipse plugins/features nb-6.5-plugin – NetBeans 6.5 specific plugin nb-6.7-plugin – NetBeans 6.7 specific plugin
jr-javassist/
We bundle javassist to javarebel.jar. This is so that we don’t have it in the classpath as an external dependency. This project generates a javassist archive for us where all the classes are in packages with a predefined prefix.
jr-root/
Here are all our integrations with different frameworks and our plugin architecture. You can see the whole list under trunk.
The IBM WebSphere application container features one of the longest startup and redeploy times in J2EE development. In a survey we conducted (with 1100+ developer-respondents), WebSphere users estimated spending approximately 23% of their coding time (approximately 276 hours per year — or 6.9 full, 40-hour workweeks) waiting for applications to redeploy. JRebel eliminates 80% of redeploy 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 (formerly JavaRebel).
This guide assumes that you are using Eclipse 3.x or Rational Application Developer 7.x with WebSphere 6.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.
The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.
It is useful to define an environment variable called REBEL_HOME pointing to the directory you choose. In Windows you can do this by going to Control Panel » System » Advanced » Environment Variables » System Variable » New.
Now navigate to the directory where Java is bundled with IBM WebSphere. If you have a standalone installation it’s %IBM_HOME%\WebSphere\AppServer\java\bin. If you have it installed as part of RAD7 it should be %IBM_HOME%\SDP\runtimes\base_v61\java\bin. Run the following line in the console:
java -jar %REBEL_HOME%\jrebel.jar
STEP 2: Installing JRebel Eclipse/RAD 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, JRebel 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 JRebel 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, people tend to use one module per project. In these cases, the JRebel 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
Done.
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. JRebel 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 IBM Rational Application Developer
You may skip this step if you use the Eclipse IDE or run IBM WebSphere outside the RAD IDE.
Open the Servers View and double click the WebSphere Application 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.
Open Publishing settings for WebSphere Application Server and choose Run server with resources on server.
It may seem wrong to disable automatic publishing, but as JRebel will take care of updates from now on it would just slow you down.
STEP 5: Configuring Eclipse/RAD IDE
Go to Window » Preferences and from there to Java » Debug » Step Filtering. Check Use Step Filters and 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).
JRebel (formerly Javarebel) uses reflection, byte code modification and other clever approaches to remove turnaround time from a developers’ daily life. When combined with an IDE, these approaches need a little tweaking, so — The JRebel Plugin for IntelliJ IDEA focuses on improving JRebel in IntelliJ IDEA, handling debugging issues, and making it easy for you to configure JRebel, directly from the IDE interface.
Debuggers are quite happy when code does not change during your debug sessions (with the exception of hotswap) and they are a great aid for solving difficult bugs. Once JavaRebel enters the scene they can get cranky about app state, and say things like,
“What? You renamed a method? Come on, you can’t do that!”
This plugin solves debugging issues with IntelliJ. It also improves JRebel usability significantly — Although JRebel is easy to configure, it would sure be nice to configure it from a checkbox instead of adding JVM arguments somewhere. Now you’ll never say,
“Why do I have to write XML when I’ve actually configured my project inside the IDE already?”
This plugin allows you to skip writing the XML yourself, and generate a rebel.xml based on your IDE project configuration.
Oh – and one more thing… Instead of tweaking JVM arguments with the javaagent or noverify flags, you can now press the JRebel launch button. It will use your regular container startup but will add the parameters itself, based on the javarebel.jar, which is specified in your settings. For a complete list of features check out the new JRebel IntelliJ tutorial.
This plugin is compatible with IntelliJ 8.x releases. To support debugging with older IDEA versions we’re still maintaining the old plugin.
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.
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).
JavaONE 2009 raffle licenses have been sent out. All license winners be sure to check your SPAM folder if you don’t have the license email in your inbox. The lucky winners were:
Cliff Janson
Mahesh Purushothaman
Ashok Mudgapalli
Kartik Lakshminarayanan
Ove Scheel
Jordan Laughlin
Jesper Hasselström
Dewayne Johnson
Jonathan Hair
Prasanna Gopinath
The raffled license is a personal unrestricted annual license, meaning that you may use JavaRebel on as many machines as you’d like, but you may not share/transfer the license with/to anyone else. You can check out the license terms at http://www.zeroturnaround.com/javarebel-license/
JavaOne 2009 has been going great for us so far. We have a booth at the pavilion, we’re doing demos, talking to current and new customers and having a blast. We also have a raffle for JavaRebel licenses. The first 5 winners of the JavaONE JavaRebel license are:
Cliff Janson
Mahesh Purushothaman
Ashok Mudgapalli
Kartik Lakshminarayanan
Ove Scheel
We will contact all the lucky winners during next week after the conference. The licenses are personal 1 year licenses of JavaRebel.
If you’re interested in winning a license or just chatting with the developers drop by our booth 221 in the exhibition area of Moscone North.
We’re happy to announce the JavaRebel 2.0.1 release. It is a maintenance release incorporating all the bugfixes that have accumulated during the past two months. It also updates the bundled plugins to the latest versions.
Changes include:
Fixed a deadlock that caused infinite startup.
Fixed new method parameter annotations not parsed correctly.
Fixed “this” not resolving in debugger.
Fixed Spring plugin trying to reconfigure beans created by a FactoryBean.
Fixed AspectJ plugin with Spring reparsing aop.xml.
Fixed EJB modules not-reloading in JBoss and WL when configured with rebel.xml.
Fixed NullPointerException on WL startup.
Fixed Velocity engine startup.
Improved Servlet Context perfomance when configured with rebel.xml.
Spring plugin now autowires changed beans that don’t have BeanDefinition.
Added Wicket @SpringBean plugin.
You can grab the latest copy of JavaRebel from the download page. For more information on JavaRebel see the product page.
The JavaRebel Eclipse plugin was released into the wild today. Though JavaRebel does not depend on any IDE, it’s awesome when you can setup and configure JavaRebel with a single click. This plugin also includes better support for debugging JavaRebel enabled applications.
The plugin depends on Eclipse 3.4 and is available from the update site at http://www.zeroturnaround.com/update-site/ If you’re a not WTP user be sure not to include WTP support as it has a lot of dependencies.
JRebel testing is not that simple. For example, say we want to test changing a protected field to a private static. We need to have a test that first compiles a source file with a protected field and then lets a JVM load it. Then we need to make the changes to the source, compile and make JRebel reload it. Then asserts follow :) It sounds easier said than done. This sub project hosts all the tests and a groovy script to control them all.
