The most common ways of deploying a web application to Tomcat are either straightaway copy the exploded war file structure to $CATALINA_HOME/webapps or to do the more cumbersome task of compiling the web application to a war file and then using the tomcat manager to upload it. Both ways are the most used ones. But did you know there are other ways to deploy a web application to Tomcat. If you consider production environments, then applications are deployed using the deployment commands, if at all Tomcat is used. They can be made more simpler using the ant tasks.

But I am not going to discuss the production environment over here. The topic under scrutiny is how would you deploy your web application virtually to Tomcat. For that we have to know what is virtual deployment and learn about its advantages.

What is virtual deployment?

Virtual deployment in simple terms means deploying a web application from a different physical location. In this case, you are not required to put the web application in its exploded war structure to the webapps directory. Most of the beginners, tend to develop their web applications directly in the webapps directory itself. This technique might prove the most simplest and the quickest but it is the most hazardous. This is because the moment you Undeploy the web application from Tomcat’s manager the web application gets erased off completely from the webapps directory.

I had tried the same, for the very first time since I had not much information, and it proved fatal. All my work had vanished in an instant. From that day onwards I stuck to using a technique of using development structures and deployment structures and used with Ant. But I found this, too cumbersome, if I had to learn a framework or try out a small sample code. I was not willing to write an Ant build file each time I had to try a web application nor I wanted to develop the web application straightaway in the webapps directory which had earlier destroyed my work. IDE’s might be of great help but I don’t usually have them when needed. For example at a friend’s place.

Coming back to the topic which I have to discuss, I recently found a good workaround for the above problem. Although I believe it might be used quite commonly to deploy web applications I am writing this for people who are facing the same problem as mine. The solution lies in deploying the web application virtually.

How to virtually deploy a web application in Tomcat?

When you virtually deploy a web application you are just saying to Tomcat that you have developed a web application which is lying in some other location and that the server should run it from that location itself. This is done by using a configuring element called Context. In Tomcat lingo Context is nothing but the web application itself.

So here is the technique of virtual deployment done in Tomcat. I am using Tomcat 6 for this example.

  • Let’s assume that Tomcat is configured at the location C:/Tomcat6
  • Place the Web application at some other location. For example D:/workspace/WebApp
  • Start Tomcat. This is to test the hot deployment of our Context
  • Now go to the path C:/Tomcat6/conf/
  • Check if you have the directory Catalina and a subdirectory localhost within it
  • If you don’t have them then you must make the directories Catalina/localhost within C:/Tomcat6/conf/
  • Make a Context file and name it with any name, myapp.xml and place it within localhost
  • You have to put a single element within the myapp.xml as follows


  • The “reloadable” attribute is optional. The “docBase” attribute is required. It is used to specify the physical location of the web app.
  • That’s it. Now you can do any kind of tests with your web application and happily see the changes with just a browser refresh.
  • Try undeploying your web app now. The moment you undeploy, myapp.xml gets deleted from Catalina/localhost but your application will be intact. Isn’t that wonderful?
  • For redeploying you would just have to make myapp.xml once again.

If you want to learn more about configuring Contexts and look at its different attributes then go through the tomcat reference. But before that, you would want to know what are the advantages of this technique.

Advantages of Virtual Deployment

When a context is configured, Tomcat runs it from the location directly where the web application is placed and not by making a copy in its webapps directory. In this case if you try to Undeploy the web application, Tomcat simply removes the context file from its directory and does not touch the physical web application. This is most convenient and easy way to deploy a web application to Tomcat without the fear of losing your work.

The second advantage of virtual deployment is that you don’t have to change anything in the server.xml. Whenever any change is made in server.xml the server has to be restarted for the changes to be applied. In case of using contexts the server automatically deploys your application when it finds any context newly configured with it.

The third advantage is that contexts can be even used to make your web applications classes hot deployable too. It is done as above using the “reloadable” attribute. Tomcat picks up any changes done even to the classes if “reloadable” is set to “true“. This can be very helpful and a time savior if you don’t want to waste time in restarting Tomcat again and again. It is however heavy on resources but might be useful in simple tests.

The fourth advantage is that you can dynamically change the name of your application itself. For example change the name of “myapp.xml” to “BankApp.xml”. Go to Tomcat Manager URL and refresh it. You will see the application name as “BankApp” which earlier was “myapp”. It doesn’t matter what the folder name is where the actual application lies. In our case it was “WebApp”.

The fifth advantage is something I found it to be the best of all. Your application would run even if it actually present on a remote machine. What you need to do is to just share the application from one machine, set the docBase path as the network URI and then access it. It would run like a locally hosted application.

The last but not the least advantage is to test a sample code on multiple tomcat’s. Let’s assume you want to test a feature of servlets to find whether it is backward compatible or not. So you can have a new Tomcat and an old Tomcat running on different ports. Put the context in both Tomcat’s and simultaneously test it out. You would have to refer to the Tomcat documentation for configuring Context in the older versions.

Now that you know how the technique of virtual deployment try it out on different servers like Glassfish or JBoss and let me know how you went about it. Cheers!

Stumble Digg Technorati Subscribe Delicious