Alfresco development using JRebel – less restarting, more focus

JRebelA while ago I was pointed to JRebel, and recently had some time to fire it up. JRebel is a tool that can prevent restarts of your (web)application by dynamically loading  classes and classpath changes. This effectively means that the number of restarts during development can be dramatically reduced, having all kind of benefits. The most obvious is you loose less time waiting for the system to restart. Side effects I notice, is that I stay more focussed on developing and solving the problem at hand. I do not dive into distracting activities as email, webbrowsing, chats, getting/drinking coffee or beer to spend the time ‘effectively’, waiting for my application server to be back online again. I stay in the ‘flow’, stay focussed, and be productive.

What it does

“JRebel maps your project workspace directly to a running application, watches for the changes you make to classes and resources, and intelligently reflects them in your application.” In short, JRebel depends on a custom classloader, and some configuration files in the webapplication. The configuration files (rebel.xml) tell JRebel where to find the class files in your Eclipse project. These files will be dynamically reloaded and executed instead of the files in the webapp. Find the installable of choice on zro-turnaround’s  download page.

In order to work nice, JRebel needs a couple of configuration files, depending on what/how you develop. The first rebel.xml need to end-up in WEB-INF/classes, and it will basically tell JRebel the classpath. I also added specific jar’s to watch, since I deploy as much as possible all my code in 1 (or more) jar-files. Secondly I add a rebel.xml configuration file in each of the jar files I an developing. This tells JRebel where to find the class files and config files that are packaged in the jar in Eclipse.

Since hard coding all files and path’s in the rebel.xml files can be a pain when developing in a team, you can use system properties to configure the config’s accoring the currently running instance. See below or a real life sample. There are 3 area’s where you need to apply updates;

  • prevent Tomcat to lock the jar files (otherwise a ‘hot’ redeploy does not make sense)
  • in the script/batch file/service definition that starts Alfresco (add system properties, and specify the JRebel class loader logic),
  • in the Eclipse folder structure (where the additional rebel.xml files live)

Prevent Tomcat from locking jar files

Navigate to tomcat/config. Edit context.xml. Make sure the <Context element has te attribute antiJARLocking=”true” added and set. The entire line in my config file  looks like:
<Context useHttpOnly="false"  antiJARLocking="true">
...

How to tweak Alfresco

Usually, I start Alfresco from the command line (and Share from another). I have multiple Alfresco’s next to each other for various customers and in various versions. I try to concentrate all settings in alfresco.bat, but sometimes tomcat/bin/startup.bat contains similar settings (like JAVA_OPTS) , beware! So I modified the alfresco.bat, and added to the line starting with “set JAVA_OPTS”. In here, first I added a system property for the javaagent (pointing at the location where the installer stored the jar)

-javaagent:"C:\Program Files (x86)\ZeroTurnaround\JRebel\jrebel.jar"

Next to that I added system properties that vary per install (for the same project), and will be different on each of the development machines in the project:

-Dtomcat.root="c:/bin/alfresco345/tomcat" -Dworkspace.root="C:\Users\tpeelen\workspace"

These properties will be used in the rebel.xml files as ${tomcat.root} and ${workspace.root}. tomcat.root is used as a single definition of how to find the tomcat folder. The ${workspace.root} property is used for the mapping from the webapp back to the Ecplise structure.


rem Set any default JVM options
set JAVA_OPTS=-javaagent:"C:\Program Files (x86)\ZeroTurnaround\JRebel\jrebel.jar" -Dtomcat.root="c:/bin/alfresco345/tomcat" -Dworkspace.root="C:\Users\tpeelen\workspace" -Xms512m -Xmx1024m ...

How to tweak your Eclipse project

I currently use 2 JRebel config files. The first one I put in the /config folder in Eclipse. The content is:

<?xml version="1.0" encoding="UTF-8"?>
<application
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://www.zeroturnaround.com"
    xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
    <classpath>
        <dir name="${workspace.root}/myProjectInEclipse/build" />
        <dir name="${tomcat.root}/shared/classes" />
        <dir name="${tomcat.root}/shared/classes/alfresco/extension" />
     </classpath>

</application>

This file basically tells JRebel where to find class files it needs to replace. It points to the compiled class files in the Eclipse structure, but also to the Alfresco’s extended classpath in tomcat/shared.

I tweaked/validated my build.xml to make sure this rebel.xml was properly packaged and copied into the webapp

The second rebel.xml is the one inside the myApplication.jar.

<?xml version="1.0" encoding="UTF-8"?>

<application
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://www.zeroturnaround.com"
    xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
    <classpath>
        <dir name="${workspace.root}/myProjectInEclipse/build"/>
    </classpath>
</application>

This config tells JRebel where to find the modified class files that make up this jar. These files can potentially come from a totally different Eclipse project.

Troubleshooting

There is a nice documentation page on the website, with a troubleshooting section. If you’re lost or things don’ work out as expected, remind there is a jrebel.log file in the binary distribution (“C:\Program Files (x86)\ZeroTurnaround\JRebel” on my laptop)!

I ran into the problem that JRebel did not kick in on another Alfresco instance. This had to do with the chain of scripts calling each other when starting tomcat. I usually move/have all memory settings etc. in alfresco.bat. However, there are versions out there containing tomcat/bin/startup.bat files that override the JAVA_OPTS. Once Alfresco starts, you should see (in console or alfresco.log):

Using CLASSPATH: "c:\bin\alfresco345\tomcat\bin\bootstrap.jar"
JRebel: Starting logging to file: C:\Program Files (x86)\ZeroTurnaround\JRebel\jrebel.log
#############################################################
 JRebel 4.6.2 (201205021440)
 (c) Copyright ZeroTurnaround OU, Estonia, Tartu.
 Over the last 6 days JRebel prevented at least 26 redeploys/restarts saving you about 0,4 hours.
 This product is licensed to Tjarda Peelen until July 3, 2012
*************************************************************
 Your license is about to EXPIRE!
*************************************************************
 This license will expire in 23 days and JRebel will
 stop working after that. 
...
...
#############################################################

These are my first experiments using JRebel.  I bet things can be configured more effective (suggestions welcome!). Currently I am running the 30 day evaluation version.

Tooling within Eclipse

I manually crafted my rebel.xml files, based on their clear online manual. You can also use:
http://manuals.zeroturnaround.com/jrebel-reference-manual/ide.html#ide-2.1

 

Feature Comparison Matrix

Find a comparison matrix of JRebel, Javeleon and DCEVM here.

[update june 11: added link to comparison matrix]

Advertisements

2 Responses to “Alfresco development using JRebel – less restarting, more focus”


  1. 1 Michał Wróbel June 11, 2012 at 11:36

    Hi, that’s really interesting.. Does JRebel also cope with dynamic reloading Alfresco xml resources like: data model, share form definitions, etc. ?

    • 2 Tjarda Peelen June 13, 2012 at 22:16

      I haven’t got model changes working yet. (But then, you could develop those in the data dictionary, and once stable move them to the classpath.)

      I guess Share forms are cached by the Spring-Surf framework.

      I am still twiddling with my settings. At this point in time class files and spring context files are under control, as well as log4j.props. So most of my stuff is ‘safe’…


Comments are currently closed.