The Adventure Begins

Azure offers many interesting opportunities. For a longest time, I had no reason or time to explore different stacks. Over time, Azure has changed the way I play the game, now it’s all about using the best tool for the right reasons.

Azure is a rich ecosystem of services (a.k.a. Lego Blocks), technology stacks and standards. If something is missing, we can usually overcome the challenge by bring our dependencies with us. Infrastructure as a Service (IaaS) allows us to work in a familiar environment. And Platform as a Service (PaaS) offerings, like Azure App Service, allow us to focus more on delivering business value at a faster pace.

This adventure marks the first of many, where I will explore how I can use multiple stacks on Azure App Service. Let’s start with JSP. Azure Web App has supported Java for a while, and this post is all deploying that first workload. Let’s dive in!

Helpful Resources

Deploying a JSP Web App to Azure App Service

Azure App Service supports Tomcat, Jetty, Hudson and Liferay. You can configure the App Service httpPlatform through the portal or by providing its configuration through the web.config.

Custom Configuration Guidelines

The following describes the settings expected for custom Java web apps on Azure.

  • The HTTP port used by the Java process is dynamically assigned. The process must use the port from the environment variable HTTP_PLATFORM_PORT.
  • All listen ports other than the single HTTP listener should be disabled. In Tomcat, that includes the shutdown, HTTPS, and AJP ports.
  • The container needs to be configured for IPv4 traffic only.
  • The startup command for the application needs to be set in the configuration.
  • Applications that require directories with write permission need to be located in the Azure web app’s content directory, which is D:\home. The environmental variable HOME refers to D:\home.

You can set environment variables as required in the web.config file.

For the purpose of this post, we will configure Azure Web App to use Tomcat through the Application Settings blade.


Saving these configurations will create a webapps folder in the wwwroot.


The webapps folder is important. This is where the WAR file is uploaded in order to deploy the JSP Web App. When a new version of the WAR file is placed in the folder it will get reloaded by the configured httpPlatform (Tomcat or Jetty)

Once the Web App is successfully configured, a place holder JSP Web App is provisioned. It then allows us to validate that everything is working as expected from our favorite browsers.


To replace the place holder JSP Web App with our own, rename the WAR file to ROOT.war and place it in the webapps folder.

Next Steps

Initially, walking through this example, I used an FTP client to upload my WAR file to the webapps folder. Doing so is quite practical and also quite limited. When we work with Azure, we rapidly understand that we must automate everything.


Fortunately we can Automate JSP Web App deployments by configuring Continuous Deployments from DropBox.

Note: I’m using DropBox, because WAR files are binary files. If I were deploying from source code, I would choose to deploy from Source Control solutions like BitBucket, CodePlex, Dropbox, GitHub, or Mercurial.

This is quite useful, because Azure Web App keeps a historical archive of previous deployments.


And it gives us the ability to redeploy previous versions when things goes horribly wrong.


When Azure Web App Continuous Deployment is connected to our DropBox account, it creates a folder hierarchy under the Apps folder.


By placing the WAR files in the webapps folder, which is a child of the Web App folder, the files get copied to the corresponding webapps folder in the Azure Web App. This then kicks off the automated deployment of the App.

Closing Notes

Some applications built using this technology stack can require significant memory, the Web App needs to run on a medium or large dedicated worker pool (VMs), which can provide enough memory. Depending on the application and frameworks, it may also takes several minutes to start-up. For that reason, it is recommended that you set the Web App to Always On.

Please share your questions and observations in the comments below.

5 responses to Azure Adventures – Deploying a JSP Web App to Azure App Service


    The information was useful.

    Could you please suggest, how to package a .property file, that I use in my application, and refer to it using a relative path …. so as not to get a FileNotFoundException.

    In code, I am referring to the file, only by its name – no path.

    So locally in my DEV in Eclipse + WTP, the file is expected to be in the same folder as eclipse.exe.

    When deployed in a local Tomcat installation – it is expected in the \bin (C:\apache-tomcat-7.0.65\bin)

    When deployed in an Azure AppService, the file was expected in D:\home\site\wwwroot


    PS: Snippet of my code, which ends an – FNFE

         Hashtable<String, String> env = new Hashtable<String, String>();
         env.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.qpid.amqp_1_0.jms.jndi.PropertiesFileInitialContextFactory");
         env.put(Context.PROVIDER_URL, "");
         Context context = new InitialContext(env);
         // Lookup ConnectionFactory and Queue
         ConnectionFactory cf = (ConnectionFactory) context.lookup("SBCF");
         Destination queue = (Destination) context.lookup("MYQUEUE");



    Can you please tell me how can I set tomcat environment variables? (i.e) org.apache.catalina.session. StandardSession.ACTIVITY_CHECK



    Nicely done, very helpful.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.