In the instructions below, substitute your UW Net ID wherever you see "uwnetid".

Last updated: 11 Jan 2008

Tomcat

Tomcat is an open-source project which provides the official reference implementation of the Java Server Pages (JSP) and Java Servlets technologies. In other words, Tomcat serves dynamic web content based on Java technology, and the way it does it is the way it should be done (for Java).

Tomcat is just one of many tools in the Apache Software Foundation. Other useful tools are:

• ant -- a Java-based software-build tool
• cactus -- a test framework for unit testing server-side code

Tomcat provides an environment for Java-based dynamic web content; in other words, a container for servlets. You create your JSP code or servlets, write some web pages in HTML to reference them, compile everything, deploy it to Tomcat (which encapsulates it in a container), and test it via a web browser.

For general servlet development information, see the Application Developer's Guide.

In a typical production environment for web serving, a web administrator would add new servlets to the proper location and configure Tomcat's files appropriately. In a lab environment such as ours, it is more convenient to have each person administer their own files.

Types of Tomcat Services

We support these types of tomcat services:

1. Tomcat Shared Service

   This is the kind of service exemplified in this web page. It means that there is a system service running on cssgate/repos that allows you to install your web applications on it -- it is represented by port 8080. We hope that you only install well-tested applications on it, because your application shares a Java virtual machine with other applications. We consider this service to be more like a production service. While you are developing and testing your web application, please use the "Tomcat Development Service" mentioned below.

2. Tomcat Development Service

   The way to setup and run this service is described in detail in Using Tomcat Development Service. Basically, you are running your own tomcat service with a unique port number. Anything that you do incorrectly doesn't affect anyone else, and vice versa -- if you understand multitasking, you know that isn't really correct, but at least the impact isn't as bad as when you share a tomcat service.

   We recommend that you use this kind of service unless you need to put your web application into production -- after it is fully tested using the development service.

Workflow for Creating JSP and Servlets

The instructions below reflect the mechanism IT Lab staff have used to allow faculty and students to manage their own environment using built-in features of Tomcat.

Here is the workflow for a typical new project:

1. Login to the repository server

2. Create a base directory for your project (e.g., myproj) and change from your current directory to it:

   mkdir ~/myproj
   cd ~/myproj
   

3. Make sure the base directory is world-readable.

   chmod o+rx .
   

4. Create standard directory/file structure to allow use of a standard build script (see $BUILD_HOME/build.xml) for compilation, installation, distribution and cleanup:
   1. mkdir src -- source code (JavaBeans and servlets)

   2. mkdir docs -- documentation

   3. mkdir web -- static web content (HTML, JSP, XML)

   4. mkdir web/WEB-INF -- configuration and resource files (web.xml)

5. Configure build information in build.xml and build.properties on the base directory.

   Copy these files for easier build script creation:

   cp $BUILD_HOME/build.* .

   You should not need to change build.xml. However, build.properties should be changed to match the new application path (app.path) and name (app.name). For example, for course "tcss460" and UW Net ID "johndoe" and project name "myproj", build.properties should be changed (use pico build.properties or vi build.properties to read:

   # Context path to install this application on app.name=myproj app.path=/tcss460_johndoe_${app.name} # Tomcat installation directory - do not change catalina.home=/usr/java/tomcat

   and save your changes.

6. Write the static web content and the Java code.

7. Compile the code in the base project directory using ant.

   Just enter ant -- its default action ("target") is to compile.

8. Clean up compilation errors, and rebuild using ant.. After a clean compile, proceed to the next step.

9. Create or edit the deployment descriptor web/WEB-INF/web.xml

10. If you are using the latest $BUILD_HOME/build.xml file, all files and directories in myproj/build will be world-readable after using ant.

    If, for some reason, they aren't, use this command:

    chmod -R o+rx build
    

11. When ready to test, enter ant install in the base directory.

12. Test by using the application name (e.g., /tcss460_johndoe_myproj) as part of the URI:

    http://cssgate.insttech.washington.edu:8080/tcss460_johndoe_myproj

13. If you need to change the source code or static content, change them, recompile (if needed) and do ant reload to refresh the servelt container's contents.

14. To remove an installed servlet; from its base directory: ant remove

Change Log