#Tomcat 7.0 install
#Tomcat 7.0 zip file
#Tomcat 7.0 code

The Connector element should use the port provided in the JAVA_OPTS environment variable, which we have set previously in the catalina.sh script. Since Cloud Foundry handles the load balancing for you without using the AJP connector, you should disable the AJP connector to ensure we do not get a port conflict by commenting out the section shown below. We want to avoid any potential port conflicts with other applications that are running on the same Droplet Execution Agent (DEA), so only using a single http port is the current recommendation for standalone applications running on Cloud Foundry. Cloud Foundry does not use the shutdown port because it issues a “ kill -9 PID” command to stop any standalone app instance. Set the port attribute of the Server element to -1, which disables the Tomcat shutdown port. # USE VCAP PORT IF IT EXISTS, OTHERWISE DEFAULT TO 8080Įxport JAVA_OPTS='=$VCAP_APP_PORT $JAVA_OPTS'

#Tomcat 7.0 code

Just so that we can run this locally as well without modifying the code, this code will assign a static port number of 8080 if the dynamic port is not available as an environment variable. Place the following bash code near the top of catalina.sh after the initial comments. In order for Tomcat to use the same shell that invokes startup.sh instead of spawning a new shell, change the execution argument in the last line of startup.sh from “ start” to “ run“: exec '$PRGDIR'/'$EXECUTABLE' start exec '$PRGDIR'/'$EXECUTABLE' run of using a pre-defined static port, we would like Tomcat 7 to use the port assigned by Cloud Foundry, which will be stored in the VCAP_APP_PORT environment variable when deployed. Tomcat is typically started with the bin/startup.sh script. Unfortunately, Windows users cannot test the bin/startup.sh script changes locally first, but the modifications are really quite simple. Linux and OSX users should be able to test the scripts on their local systems before pushing them to Cloud Foundry’s Ubuntu-based server environment. I changed the permissions of the bin/*.sh scripts to have executable permissions.

#Tomcat 7.0 zip file

Step 2 – Extract Tomcat and Update PermissionsĮxtract the tomcat zip file to a local directory. All of the commands throughout this tutorial will assume that the present working directory is the Tomcat 7 base directory. I downloaded Apache 7.0.27, which is currently the latest version 7.0 release and the file name is apache-tomcat-7.0.27.zip.

#Tomcat 7.0 install

If you do not have vmc, then follow these instructions to install it. Step 1 – Download Apache Tomcatĭownload Apache Tomcat 7 to the location where you will use the vmc command line tool. The basic outline involves installing your application into a local Tomcat 7 instance, making minor modifications to the configuration and pushing the entire contents of Tomcat 7 and your application to Cloud Foundry as a standalone application. While the team is working to support Tomcat 7 as a first-class container, it is very straightforward to use the standalone application support to run Tomcat 7 in the meantime, which is particularly useful for applications that leverage Servlet 3.0.

Currently, Cloud Foundry leverages Tomcat 6 to host Java web applications. This tutorial will walk you through the steps to deploy a “hello world” application in a Tomcat 7 container on Cloud Foundry. The new standalone framework support greatly increases the number of different types of non-Web applications that can run on Cloud Foundry, including application servers.