7.6 Deploying Applications to tc Runtime Instances

Deployment refers to the process of installing a Web application into the tc Runtime instance. This section describes two ways to deploy Web applications to the tc Runtime instance.

It is assumed in this section that you have already created a Web application and want to deploy it to a tc Runtime instance so you can start using the application. If you do not have a Web application, see Tutorial: Very Simple Web Application Development for a tutorial that describes how to create a very simple HelloWorld application.

To deploy a Web application statically: Copy the WAR or exploded directory to the deployment directory, which by default is CATALINA_BASE/webapps. For example, if your CATALINA_BASE variable is /home/tcserver/vfabric-tc-server-standard/myserver, and your Web application is the exploded directory /home/apps/myApp, then you deploy it statically with the following command:

prompt$ cp /home/apps/myApp /home/tcserver/vfabric-tc-server-standard/myserver/webapps

If you want to use a different deployment directory than the default CATALINA_BASE/webapps, set the appBase attribute of the <Host> element that configures the virtual host for your tc Runtime instance. For additional details about static deployment, see Tomcat Web Application Deployment.

Deploying Applications Using Tomcat Manager (Developer Edition Only)

The tc Server Developer Edition includes Tomcat Manager, an Apache Web application that you can use to deploy your own Web applications and manage their lifecyle, such as starting, stopping, and undeploying them.

The default tc Server Developer Edition configuration does not automatically authorize any user to access Tomcat Manager. The following procedure describes how to authorize a user to access the application, and then how to invoke the Web application in your browser.

  1. Update the CATALINA_BASE/conf/tomcat-users.xml file in the tc Runtime instance by adding a manager role.

    The default tomcat-users.xml file does not include any roles or users, although examples are shown in comments.

    An entry for the manager role looks like this:

    <tomcat-users>
      <role rolename="manager" />
      ...
    </tomcat-users>
  2. In the same file, add a user with role manager. For example, to specify that the tomcat user (with password tomcat) have the manager role, add the <user> element to the tomcat-users.xml file, as follows:

    <tomcat-users>
      <role rolename="manager" />
      <user username="tomcat" password="tomcat" roles="manager" />
    </tomcat-users>
  3. Restart the tc Runtime instance for the changes to take effect.

  4. Invoke Tomcat Manager in your browser using the following URL:

    http://host:8080/manager/html

    where host refers to the computer running the tc Runtime instance.

  5. Enter the user and password you configured in the tomcat-users.xml file, in our example tomcat/tomcat.

The Applications table lists the currently deployed applications. Click the links in the Path column to actually invoke each application. The Commands column includes buttons for starting, stopping, reloading, and undeploying the applications.

From the Deploy section, you can deploy Web applications (either exploded or in a WAR format) from either the host where running the tc Runtime instance or from the local computer running your browser. When deploying from the host, you must specify the context path that users use to invoke the application.

For detailed information about Tomcat Manager, see the Manager App How-To on the Apache Tomcat Web site.

Deploying Multiple Versions of the Same Application

When you create an instance using tc Runtime 7, you can deploy multiple versions of the same web application. This makes it possible to upgrade applications without interruption. Users who have a session in process continue to use the existing version of the application, but new sessions use the latest version of the application.

To deploy a new version of an existing application using static deployment, append a version number to the context name, separated by two hash signs: contextName##version. For example, if you have already statically deployed a WAR file named myapp.war and you want to upgrade to version 2.0, you can deploy the new WAR file myapp##02.0.war.

If you use the Hyperic HQ user interface to deploy a new version, do not rename the WAR file. The tc Server HQ plug-in automatically appends the version number for you.

Users continue to use the same URL to access the application; they do not include the version number. New sessions use the highest version deployed. Existing sessions continue to use the version that is already managing their session. If tc Runtime cannot locate the session in the SessionManager of an earlier version, the newest version is used.

The version number is processed as a string, not as a number. This means that you can use letters in the version number, for example myapp##02b. It also means that you must be careful to ensure that your version numbers compare correctly. If the current version is myapp##9.0, deploying myapp##10.0 will not work as expected because the string "9.0" sorts higher than "10.0".

When all sessions using an earlier version of an application have ended, the older version can be undeployed.