In the instructions below, substitute your UW Net ID wherever you see
Last updated: 11 Jan 2008
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:
- 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"
- 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
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:
- Login to the repository server
- Create a base directory for your project (e.g., myproj) and change from
your current directory to it:
- Make sure the base directory is world-readable.
chmod o+rx .
- Create standard directory/file structure to allow use of a standard
build script (see $BUILD_HOME/build.xml) for compilation, installation,
distribution and cleanup:
- mkdir src -- source code (JavaBeans and servlets)
- mkdir docs -- documentation
- mkdir web -- static web content (HTML, JSP, XML)
- mkdir web/WEB-INF -- configuration and resource files (web.xml)
- 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
# Tomcat installation directory - do not change
and save your changes.
- Write the static web content and the Java code.
- Compile the code in the base project directory
Just enter ant -- its default action ("target") is to compile.
- Clean up compilation errors, and rebuild
using ant.. After a clean compile, proceed to the next step.
- Create or edit the deployment descriptor web/WEB-INF/web.xml
- 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
- When ready to test, enter ant install in the base directory.
- Test by using the application name (e.g., /tcss460_johndoe_myproj) as part
of the URI:
- 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
- To remove an installed servlet; from its base directory: ant remove
|11 Jan 2008
||Updated some links
|27 Dec 2005
||Changed references and operation related to build.properties and Tomcat 5.5
|12 Oct 2004
||Added Types of Tomcat Services
|5 Oct 2004
||Emphasized use of insttech.washington.edu, removed references to version level where possible.
|4 Dec 2002
||Removed need for chmod and umask commands via a change to build.xml
suggested by Greg Nance.
|31 Oct 2002
||Corrected instructions and added more Linux commands, with some
clarifications and content from Prof. Isabelle Bichindaritz
|17 Oct 2002