In this article we will look at how to setup the development environment to support unexploded development. We will take the Spring Framework sample named PetClinic. We will deploy this to JBoss as a WAR archive and then start modifying the classes in Eclipse IDE and see the changes on-the-fly from the browser.

Before we continue lets look how it works. Once an application is deployed to the container (in this case JBoss) it will start loading the application classes. JBoss is running the JavaRebel agent that will intercept the calls and load those classes from the preconfigured IDE output directory.

Note however, that this means that if a new class is added in the IDE but not present in the JAR files, the JAR files needs to be updated. Why? We are still talking about the classloaders of the container. Container only knows and looks for classes that are present in the EAR/WAR/JAR files and these zip archives are cached. So adding classes still requires the redeployment of the zip archives.

The normal development model in unexploded development looks like this:

1. Code modifications
2. Build the archives
3. Update the EAR/WAR/JAR in the container
4. Restart the container or redeploy the application
5. Check the modification

We will change this into:

1. Code modifications
2. Background compiling
3. Check the modification

We assume you have downloaded the Spring Framework (in this case the version number is 2.5.3) and created a Java project from the folder spring-framework/samples/petclinic. We have enabled the IDE to build automatically the source files. Eclipse will by default start building classes to the spring-framework/samples/petclinic/.classes folder.

Lets build the WAR archive. Open up a console and change directory to spring-framework/samples/petclinic. Issue the command ant warfile. It will produce a petclinic.war in spring-framework/samples/petclinic/dist. Copy this file to your JBoss’s deploy folder.

Start the database server for the application. Open up a console and change directory to spring-framework/samples/petclinic/db/hsqldb/ and issue the command server.sh (on Linux) or server.cmd (on Windows). This will start the database server. You should see something like this:

[Server@8813f2]: [Thread[main,5,main]]: checkRunning(false) entered
[Server@8813f2]: [Thread[main,5,main]]: checkRunning(false) exited
[Server@8813f2]: Startup sequence initiated from main() method
[Server@8813f2]: Initiating startup sequence...
[Server@8813f2]: Server socket opened successfully in 4 ms.
, alias=] opened successfully in 259 ms.0, db=file:petclinic
[Server@8813f2]: Startup sequence completed in 268 ms.
[Server@8813f2]: 2008-04-10 16:00:59.471 HSQLDB server 1.8.0 is online
[Server@8813f2]: To close normally, connect and execute SHUTDOWN SQL
[Server@8813f2]: From command line, use [Ctrl]+[C] to abort abruptly

Now lets add a configuration option to the JBoss startup script. We presume you have already installed JavaRebel. We will modify the JBoss/bin/run.sh (on Linux) or JBoss/bin/run.cmd (on Windows). First lets find the full path of the folder that your IDE is compiling the classes to. In my case it is /home/demo/projects/spring-framework/samples/petclinic/.classes. Lets add this as a Java -Drebel.dirs option to the JBoss startup script. So JBoss will have the flag -Drebel.dirs=/home/demo/projects/spring-framework/samples/petclinic/.classes on startup in addition to the usual JavaRebel flags. See JBoss installation for details on modifying the startup scripts.

Lets start the server. As the petclinic.war has been copied to the deploy folder, JBoss will deploy the application on startup. Depending on the server port visit http://localhost:PORT/petclinic. You should see the petclinic application homepage.

Now lets verify that everything got configured correctly. We’ll make a modification to a Petclinic class and see the output. We’ll test this by changing the validation of adding owners. In the browsers naviagate to “Find Owner” » “Add Owner”. Click “Add Owner” without filling any of the fields. You will see a page where it is stated that all fields are required.

Open the file org.springframework.samples.petclinic.validation.OwnerValidator in your just configured IDE project. We will modify the validate method. You will see validation rules:

Lets remove the last name, address and city validations. The method will look like this now:

Now when you click “Add Owner” button again you will see that the requirement for the last name, address and city are gone now.

You should also see the line JavaRebel: Reloading class 'org.springframework.samples.petclinic.validation.OwnerValidator'. in JBoss server log.

If the validation rules have been reloaded, you have successfully configured the unexploded development format. You have deployed a WAR file and made the container aware of the location from where to find the modified classes.

If you have multiple locations to look for the classes you can specify a comma separated list of location to the -Drebel.dirs option.

If you have any comments, suggestions or questions don’t hesitate to ask either in the comments section or via support at zeroturnaround dot com

We have had quite many support requests on how to use JavaRebel in different configurations. Either users have one Eclipse project from which they deploy three applications or the other way around, generating one project from multiple projects. Standard approaches (at one point copying or zipping into one archive and deploying) are quite slow in these circumstances and only provide a way to distribute the application and do not concentrate on how to make the developers’ work hours more productive.

In this article we will look at different configurations and see how to configure projects so that we do not spend too much time on building and deploying but developing the applications.

Sample Configuration

We will be developing a web application named WebApp and an accompanying library called OurLib. The WebApp depends on OurLib and we want to take advantage of exploded format in development.

Folder structure

WebApp/

• src/ - Source files with top level package com
• bin/ - Eclipse build folder
• lib/ - Buildtime & runtime libraries
• tests/ - Tests’ source files
• etc/ - Configuration files
• dist/WebApp.war - Distributable artefact generated by build cycle.
• dist/WebApp/ - Distributable artefact before packing generated by build cycle.

It is better to use a more logical folder structure for web applications. One that has an application folder that can be deployed straight to a container. Then it is easier to separate buildtime and runtime dependencies and limits the need of constructing a special distributable folder during build. In this article will use the given structure though.

OurLib/

• src/ - Source files with top level package org
• bin/ - Eclipse build folder
• lib/ - Buildtime & runtime libraries
• etc/ - Configuration files
• dist/OurLib.jar - Distributable artefact

Configuration

We will be deploying the WebApp to a Tomcat web container and Weblogic Server 9.2 . OurLib has to be accessible from the WebApp . We will be using Eclipse for development, Apache Ant as a standard building tool and the developers will be using either Linux or Windows (NTFS filesystem) environment. Eclipse is configured to build files automatically (from the Eclipse menu Project » Build Automatically is checked).

Typical Building

OurLib has a build.xml with target dist. It will produce a single JAR file in the dist folder. The target compiles the source files with the necessary flags, attaches the configuration files and archives into a JAR file.

WebApp has a build.xml with target dist. It will produce a single archive, in this case a WAR file. Consisting of the compiled class files, configuration files, static pages and so forth.

The OurLib.jar ends up in dist/WebApp/WEB-INF/lib either by WebApp’s dist target (has configured the OurLib location) or by OurLib dist target.

The WebApp.war ends up deployed in both application servers. This can be achieved manually (in WebLogic it is dozen of clicks) or automatically through the WebApp build script.

Developers perspective

On every deployment the following tasks happen:

• Source files are built
  • Longer approach but universal: javac task is invoked to compile the source files
  • Usually quicker: IDE’s output folder is used
• Built files are aggregated into an archive
  • Involves copying of files
  • Files are zipped into a single archive
• WAR archive is deployed
  • Archive is copied to the container’s folder
  • Archive is unpacked to a temporary folder
  • Deployment of the temporary folder.

As we can see there is just too much overhead from doing repetitive tasks that we can avoid. I did not include the steps that need to be taken to build the OurLib project or deployment to the other container too. We are compiling code twice, we are packing and unpacking an archive, we are copying files from one location to another, we are losing the session in the web application. Hopefully the deployment cycle is done through the build script. We would otherwise be clicking our way through endless dialogs to make the container understand how certain we are about the redeployment.

How long does it take? Depends on the size of the application. Probably from 30 seconds to some tens of minutes. Even 30 seconds stack up to a lot.

Exploded format

We can lose copying, packing, unpacking from the cycle in different ways. The main difference will be that we will start deploying an application as a folder instead of a WAR archive. To redeploy, one has to touch web.xml or hit Redeploy/Reload in the respected web interface.

With Weblogic deploying in exploded format is done the same way as deploying an archive. Instead of the WAR file you specify a folder. Weblogic will highlight a folder deployable if it has the WAR or EAR folder structure.

With Tomcat it is done by copying the folder to TOMCAT_HOME/webapps.

Application configuration

We need to produce the deployable folder from our project. The structure must be as follows:

• WEB-INF/
  classes/ - compiled class files
  lib/ - runtime libraries
• web.xml

This can be achieved by making the build script create the folder structure, copy runtime libraries, compile source files and copy configuration files. The folder can then be deployed to a container. We could have structured the project to include such a folder
and keep the runtime libraries and configuration in such a folder structure already. This time we did not.

Next we will look at some examples of how we can configure the project so that seeing changes made to the source files will not require other operations than just hitting refresh in the browser.

Example

Eclipse is building class files to folder bin. We use dist/WebApp as the folder we deploy to Tomcat or Weblogic. We will use an ANT target that will makes the folder structure of the application (copying the class files from the IDE output location, lib files and configuration files to dist/WebApp respective folders). The very same target can be later used to zip the folder into a WAR file.

On every deploy we save the time of zipping and unzipping our project and depending on the configuration even the compiling. To deploy the application we click reload/redeploy in the application server.

Example With a Twist

We use a set of symlinks to completely lose the copying part and even invoking ANT. We will symlink the IDE’s output folder to dist/WebApp/WEB-INF/classes. The libraries will end up in dist/WebApp/WEB-INF/lib. Either the whole folder or just a subset of the libraries.

Now we have a configuration that requires no copying or invoking ANT. If we need to see the output in the browser we just have to redeploy the application. Now we are only losing the session in the application.

Example Without Redeploy

We will add JavaRebel to the equation and lose the redeployment part. As we are deploying everything as class files we can configure the server to use JavaRebel. See the installation documents for different containers.

Now we have a configuration that requires only a refresh in the browser to see any results.

What about OurLib?

OurLib can be deployed without zipping it into a JAR archive. The easiest way is to just symlink the IDE’s output folder to the WebApp’s deployment folder’s WEB-INF/classes. As we are probably already using a symlink for the WEB-INF/classes we have to make it a bit more granular. So for the WebApp we actually symlink, lets say, the toplevel package. So Webapp’s bin/com gets symlinked to dist/WebApp/WEB-INF/classes/com and OurLib’s bin/org gets symlinked to dist/WebApp/WEB-INF/classes/org.

Now if we want to see changes made to the library that we are using in our WebApp we just make a change, save the file (Eclipse is compiling in the background) and hit refresh in the browser.

Summary

Achieving shorter turnaround requires the developers to know the tools available to them. Projects use very different folder structures, build scripts and have different type of dependencies. Still developers can make their life easier with a set of tools and a bit of imagination.

Eclipse

Compiling can be done in the background and the resulted class files can be used for deployment. This is a real time saver.

Custom builders can be defined that run before or after every build. They can be made to copy some deltas or touch configuration files or actually everything. Here is how you create a project builder Ant buildfile.

Different source folder can have different output folders. E.g. the project has different folders for source files and unit tests. They can be compiled into different folders. Project properties » Java Build Path » Source Tab » Allow output folders for source folders checkbox.

Symbolic Links under Linux & Windows

Projects’ location and structure differ from the deployment counterparts. They can even be in a 1-n relationship. This is where symbolic links come into play. One can link directories or files to other places on the filesystem thus keeping the data in one place but available to different applications. Creating and managing links differ for operating systems, they are even named differently. See Similar Concepts from Wikipedia symlink article for more information. Mind that symbolic links are not something that only Linux users have, Windows has them too (comfortable and secure managing of them requires a freeware application though).

JavaRebel

Developers don’t have to restart a container or redeploy an application to see their code change in action. Make a change, compile the code and JavaRebel will pickup the changes. See the screencast for more information.