Tomcat – Getting Started

Requesting a Site

Please see the Tomcat Service page for information about how to request a Tomcat instance.

Accessing the Service

SSH/SFTP Access to Development

All developers require an account on the development system. Accounts can be requested by filling out an account request form. Developers can access the development server using any standard SSH/SFTP client they choose. However, they must be connected to the Purdue University network either directly or via VPN services. Connections should be made to ldvwebtom03.www.purdue.edu on port 22 (the standard for SSH/SFTP) using the developer’s Career Account credentials. Once connected, the developer will be in their home directory on the server. They should change to /opt/tomcat7-instance/<instance-name> to find the files for their instance.

Web Access

Web browsers access the systems using the standard HTTPS protocol. How specifically the instance is addressed depends on whether Web Services has been informed of the application name and has configured the F5 load balancers with that knowledge or not. If the application is known, the application can be accessed by:

• https://dev.tomcat.www.purdue.edu/<application>
• https://qa.tomcat.www.purdue.edu/<application>
• https://tomcat.www.purdue.edu/<application>

Note that development and qa are restricted to the Purdue network IP addresses to prevent the exposure of security issues that might exist in applications being developed and to prevent search engines from crawling these non-production servers.

If the application is not known to Web Services, the application can be accessed by:

• https://dev.tomcat.www.purdue.edu:<port>/<application>
• https://qa.tomcat.www.purdue.edu:<port>/<application>
• https://tomcat.www.purdue.edu:<port>/<application>

where <port> depends on the Tomcat instance:

In general, the HTTP port number is 8080 + the numeric part of the instance name and the HTTPS port number is 8443 + the numeric part of the instance name.

You may test connectivity to your Tomcat instance using the Monitor application. For example:

https://qa.tomcat.www.purdue.edu:8444/Monitor/

Deploying Applications

Most applications can be deployed in DEV by simply placing the WAR file in $CATALINA_BASE/webapps. Within a short time (15-30 seconds), Tomcat will notice the WAR file, will unpack it, and will deploy the application. If the application has already been deployed and a newer WAR file is dropped in, Tomcat will remove the old deployed application and unpacked files, and will redeploy the new version. Tomcat should not need to be restarted.

The exception to this is when your application does not have a context fragment defined in its META-INF directory. This context fragment is a small file name context.xml and is specific to Tomcat installations. By putting this file into your WAR file, you prevent Tomcat from creating a default entry for your application in its server.xml file. It is these default entries that can prevent your application from correctly auto-deploying without a restart. A minimal context.xml file contains:

<?xml version="1.0" encoding="UTF-8"?>

<Context>
</Context>

To deploy your application to qa and production, please use the Web Services Deploy Tool. The Deploy Tool will allow you to roll back your deployment to the previous version if you request that before leaving the final window.

Restarting Tomcat

Developers should not have to restart their Tomcat instance often, but if necessary, they may do so on the development systems using the following commands:

Start Tomcat

sudo systemctl start tomcat@<INSTANCE>

Stop Tomcat

sudo systemctl stop tomcat@<INSTANCE>

Restart (stop then start) Tomcat

sudo systemctl restart tomcat@<INSTANCE>

Get Tomcat’s status

sudo systemctl status tomcat@<INSTANCE>

Replace “<INSTANCE>” with the name of your instance.

For example, to restart the 2.elt instance:

sudo systemctl restart tomcat@2.elt

To restart your Tomcat instance on qa or production, please contact Web Services.

Accessing Logs

The logs for the development Tomcat instances should be directly available on the servers in the directory /opt/tomcat7-instance/<instance-name>/logs. This can be useful when troubleshooting a new application in development as the normal Linux tools (less, grep, etc.) are available. For qa and production (and for development), you can use the Unified Log Viewer application. The Log Viewer first breaks all Web Services systems out into Dev, QA, and Prod tiers, and then by a friendly system name within each tier. For Tomcat, the service is “Shared Tomcat 2020”. From there, you select the instance and then the log you wish to review. The Log Viewer understands gzip compressed log files, has pagination, download, and some search capabilities.