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.