Developing and Deploying Java-Tomcat apps into Windows Azure

Cesar De la Torre

September 12th, 20100 0

As you may know, Windows Azure is a multi-platform environment, so we can run many other languages/platforms other than .NET, like Java, PHP, Ruby, etc., and even using a whole Web-AppServer like Apache Tomcat, a DBMS like MySQL, and using IDEs like ECLIPSE. You can get more info about this here:

http://www.microsoft.com/windowsazure/interop/

So, in this case, what I wanna show in this post is how you can develop and deploy a simple JAVA app (.JSP and SERVLET app) into Windows Azure (I’ll show it into the Windows Azure local Dev-Fabric but also into the real Windows Azure cloud in the Internet).

There are a few steps we need to accomplish, like installing Java SDK, Tomcat, etc. This is the software I installed in my dev machine (a Windows 7 machine):

SOFTWARE INSTALLATION

Regarding base software installation (Java, Tomcat & Eclipse), it is critical that you install versions that match each other, especially talking about the processor version (x86 or x64). In my case, all versions that I installed are x86 (Even though my Windows 7 is a x64 version, there’s no problem with that).

So, I installed the following software versions:

JDK 6 Update 21 (STANDARD) Windows x86

https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=jdk-6u21-oth-JPR@CDS-CDS_Developer

Eclipse IDE for Java EE Developers (GALILEO SR2)

http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/galileosr2

Apache Tomcat 6.0.29

IMPORTANT: Download the Windows zipversion. In my case, the ‘32-bit Windows zip’ version, from the following URL:

http://tomcat.apache.org/download-60.cgi

Do not install the ‘32-bit/64-bit Windows Service Installer’, as this is the TomCat Windows Service version, and you won’t be able to deploy a Windows/NT Service in Windows Azure PaaS. We need the ‘process/command’ version of Apache Tomcat.

Then, just unzip Tomcat in your selected directory.

In order to run Tomcat, we also need to set the JRE_HOME environment Variable to the JAVA SDK directory. In my case, “C:\Program Files (x86)\Java\jdk1.6.0_21”:

Install the Windows Azure Tools for ECLIPSE:

Once you have Eclipse already installed, run Eclipse and install the ‘Windows Azure Tools for ECLIPSE’ from Eclipse itself:

–> Eclipse–>Help–>Install New Software –> Download Windows Azure Tools for ECLIPSE by clicking on Add, giving a name ‘Windows Azure Tools for Eclipse’ –> Location: http://www.windowsazure4e.org/update –> Select Windows Azure Java SDK, like you can see down-below:

Then, almost “Next-Next-Next”…

Windows Azure Tomcat Solution Accelerator

Download and unpack the ‘Windows Azure Tomcat Solution Accelerator’. You can get it from here (in my case, I used the x86 version, to match the other x86 versions):

http://code.msdn.microsoft.com/winazuretomcat/Release/ProjectReleases.aspx?ReleaseId=3550

Java Demo-App creation

– Create a New Project in Eclipse: File–>New–>Other–>Web–>Dynamic Web Project –> Set a name –> “HelloWorld” –> Create

– Then we need to add the external JARs for JSP and Servlets support:

– Project Properties –> Java Build Path –> Libraries –> Add External JARs –> My Compurtes-HardDrive–> Eclipse folders–> C:\JavaEnv\eclipse\plugins –>javax.servlet.jsp_2.0.0.v200806031607.jar AND javax.servlet_2.5.0.v200910301333.jar files:

–

– If we would want to access Windows Azure storage (Blobs/Queues/Tables) from Java we’d need to add the following JAR: org.soyatec.windows.azure.java_1.0.0.201002091324

– But in this case I just want to run a standard and simple JSP and SERVLET App.

– Then, OK–>OK.

– Now, we add a simple .JSP page:

– Expand Project –> New –> .JSP –> Name: “index.jsp” –>

– We add its code, very simple HTML form code that will call/execute our future SERVLET:

– Now, we créate our SERVLET project:

– From Eclipse, New–>Other–>Web–>Servlet

– Dialogo SERVLET –>

o Java Package –> Specify a selected name for your Java Package, like “MyJavaPackage”

o Class Name: –> Specify “HelloWorldServlet”

– Next

– Add description –> “Simple demo Servlet App”

– Next

– Methods –> DoPost & DoGet

– –> Click FINISH

– Now, within the doPost() method we introduce our ‘process’ code. We could put it in a different method, but for this short demo, we can directly put it there, within the doPost():

package MyJavaPackage;

import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

/**

* Servlet implementation class HelloWorldServlet

public class HelloWorldServlet extends HttpServlet {

private static final long serialVersionUID = 1L;

public HelloWorldServlet() {

// TODO Auto-generated constructor stub

}

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// TODO Auto-generated method stub

}

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType(“text/html;charset=UTF-8”);

PrintWriter out = response.getWriter();

String fullName = request.getParameter(“fullname”).toString();

out.println(“<html>”);

out.println(“<head>”);

out.println(“<title>Bienvenido</title>”);

out.println(“</head>”);

out.println(“<body>”);

out.println(“<p>Hi ” + fullName + “, greetings from JAVA Server environment!! </p>”);

out.println(“</body>”);

out.println(“</html>”);

out.close();

}

– You can see similar code in Eclipse:

–

– Import PrintWriter option using the rightClick mouse context.

– START Aapche TomCat up:

– From the Command-Prompt, within the Tomcat’s directory, just type ”startup.bat”:

– From ECLIPSE, I EXPORT my Project as a WAR FILE:

– RightClick on Project–>Export–>WAR FILE

o Destination, in my case: E:\JavaEnv\apache-tomcat-6.0.29-windows-x86\webapps –> and ROOT.WAR as my filename, so it will run as default webapp.

o Check Overwrite Existing Files

– And finally, test the default page (my .JSP page should be executed):

–

– Write any name and submit to the SERVLET, and see results:

–

– OK, so our Java app is running now on a regular Apache TomCat (In a Apache Command process).

Deploying the App to Windows Azure local Development-Fabric

– Open CMD from Windows Azure SDK (Programs–> Windows Azure SDK v1.2–> Windows Azure SDK Command Prompt)

– Move to the directory where I have unpacked the Windows Azure Tomcat Solution Accelerator. In my case:

– cd E:\JavaEnv\WATomcatAccelerator_x86\Tomcat

–

– We have 3 Command files (Buildme.cmd, Packme.cmd and Runme.cmd):

–

– Buildme.cmd creates/builds our solution. In this step we’ll need to provide the Apache-tomcat path, and the Java runtime path. It gives us complete control as we can deploy any particular Tomcat or Java runtime version.

– The Runme.cmd command deploys and runs our app and base software into Windows Azure DEVELOPMENT fabric. It moves Tomcat and Java runtime into WA dev-fabric local storage, and also, our app.

– Next thing we need to to is to configure TomCat to listen in the right TCP port. In WA we have a load-balancer for all our VM instances, but we need to run Tomcat in any other port than port 80. We need to configure it so the Load-Balancer can ‘talk’ to TomCat.

– Next thing we need to do is to start TomCat Service.

– And finally it’s going to monitor TomCat, so if for some reason TomCat crashes, then WA will be notified and we can re-start a WE node, etc.

STEP 1: Building the solution: Run the BUILDME.CMD

– The Buildme.cmd batch file which is available in the root folder of the solution generates the CSX folder. This batch file should be executed only from the Windows Azure SDK command prompt. On executing this, it checks if the Tomcat and Java binaries are present in the required directories. If not, it prompts for the path to the binaries and the user needs to give the path to the binaries folder (for e.g. E:\Binaries\Tomcat). On a successful build, it generates the CSX folder under the root folder of the solution. This is required to run the solution in development fabric.

– It first asks for the tomcat binaries, so we provide it (E:\JavaEnv\apache-tomcat-6.0.29-windows-x86):

–

– Then, it asks for the Java runtime binaries path, in my case “C:\Program Files (x86)\Java\jre6”:

STEP 2: Running the solution (WA development fabric): Run the RUNME.CMD

– Now we build the app with the Runme.cmd command file:

–

– It deploys JRE, Tomcat and our App into the WA Dev-Fabric, and finally it starts TomCat:

–

– Now we go to the App-Dev-Fabric where we can see it running:

–

– Then we can go and use any Browser to run our app. We need to specify the IP address and TCP port where WA-Dev-Fabric started TomCat, that in my case is, http://127.0.0.1:81:

–

– So finally we can see our Java app running on TomCat and Windows Azure local Development Fabric:

–

– Next step would be uploading our app to Windows Azure cloud in the Internet.

STEP 3: Uploading the solution to Windows Azure cloud in the Internet

– The Packme.cmd batch file which is available in the root folder of the solution generates the Tomcat.cspkg for the solution under the root folder itself. This batch file should be executed only from the Windows Azure SDK command prompt. . This package along with the service configuration file (.cscfg) is used for deploying the solution on the cloud. The package file and service configuration file are required to deploy the solution on cloud. Once the package is deployed on cloud, the application can be accessed via the following URLs.

Application	Staging URL	Production URL
Admin page	http://<deploymentid>.cloudapp.net	http://<servicename>.cloudapp.net

– NOTE: The ServiceDefinition.csdef and ServiceConfiguration.cscfg files should be kept under the root folder of solution for the Buildme.cmd, Packme.cmd and Runme.cmd to execute properly. So if any change has been done to these files in the solution, the latest should be copied to the root folder too.

– So, when we run the Packme.cmd, we generate the WA package needed to upload it:

–

– We can see in our directory that there’s been a new .cspkg Windows Azure file generated for us:

–

– Take into account that because of we need to upload JRE & TomCat, our app’s package is quite heavy (around 56 Mb), and therefore, deployment upload will take long. One workaround for that is uploading it just once to a Windows Azure BLOB and then we can deploy it from there much faster (in case we delete/upload same app’s version many times).

– So now, we just need to upload it to the Production or staging environment in WA cloud through the WA dev portal:

–

– But, I really recommend uploading it first to a Windows Azure BLOB, for instance, using the Azure Storage Explorer:

–

– Then, in this other way, the deployment would be like the following:

–

– And selecting the files from within a BLOB container instead of my local PC:

– Then, we can see it uploading it (from local or from Blob container):

–

– And after a few minutes (after uploading the package, which would be much faster from Azure Blob), we’ll see it deploying:

–

– Once it is deployed, we need to start the node/virtual machine:

–

– And finally, after some more minutes (wait until it reaches the ‘Ready’ state, starting on ‘Initializing’ state, then ‘Busy’ state and finally ‘Ready’ state), it will be up & running in our Windows Azure cloud:

–