Introduction to Tomcat 5.0 --- the Open-Source servlet container of choice

Saikat Goswami's picture

Tomcat is the de-facto web server of choice. Written entirely in Java, you have access to the entire code (if you want to make changes). Read to get an introduction to Tomcat, where to download, how to install it on your machine and know about the xml files of importance.


Tomcat is an official Reference Implementation of the JSP 2.0 and Servlet 2.4 specifications. The homepage of Tomcat is You can download binaries or source for all three major operating systems, namely, Windows, Unix and Macintosh. (To get a hold of the basics of web server, servlet container, the concept of 'specifications', you can refer my February article at The title is 'HTTP Basics, Web Server, Servlet Container and the Java Servlet API').

Downloading and Installing

While the step of downloading is familiar, what to download is more tricky. Jakarta maintains a site solely for downloading all its products. It is important to understand different kinds of builds. As an application developer, I would download the 'Milestone' build. There are other builds meant for developers who are working on adding features to their software. The URL for downloading Tomcat 5.0.25 is There are various flavors of Tomcat. What we need, as an application developer, is the file called

You have to set your TOMCAT_HOME. This is going to be a 'system' variable. In Windows 2000 and XP, you can go to Control Panel, System, Advanced tab and then click on 'Environment Variables', and then click on the 'New' button. Add 'TOMCAT_HOME' as the name of the variable, and the bin directory of Tomcat installation as the value. In order for you to run Tomcat, you will need an environment variable, and that is our 'JAVA_HOME'. This will be set to the Java SDK (Software Development Kit) bin directory. 'bin' directory is usually the folder which has the binary files. You can download JDK 1.4 from and follow links. You can start Tomcat by double-clicking the startup.bat in the 'bin' folder, or run on a LINUX/UNIX environment.

XML files of interest


This has entries for port in which the server is going to run, database realms and other cluster related information. A sample file looks like:

<Server port="8005" shutdown="SHUTDOWN" debug="0">


<Environment name="simpleValue" type="java.lang.Integer" value="30"/>

<Resource name="UserDatabase" auth="Container"
description="User database that can be updated and saved">

<ResourceParams name="UserDatabase">


<!-- Define the Tomcat Stand-Alone Service -->
<Service name="Catalina">
<Connector port="8080" maxThreads="150" minSpareThreads="25"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
connectionName="scott" connectionPassword="tiger"
userTable="users" userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name" />
<Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">


This is a standard file for any web application. It is called the 'deployment descriptor'. It has entries for all servlets, their initial parameters (if any), servlet mappings, MIME-mappings, etc. Each web application will have one and only one web.xml file. A typical deployment descriptor would look like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"




Explanation of the above deployment descriptor:

The above file is an XML document. An XML document is a document written against some specifications. Those specifications can be a 'DTD' (Document Type Definition) or a 'schema'. In this case, the file is validated against a DTD. The DTD is located at as seen in the second line of the file. The first line is a mandatory line that has to be written, in order for a XML document to be a proper document. It specifies the version of XML used, and also the character set. In this case, the character set is "ISO-8859-1". The root element is 'web-app'. There can be one and only one root element.

The child elements are servlet, servlet-mapping, mime-mapping, etc. You can see the DTD at the address mentioned above. The DTD is standard for any web application. The 'servlet-element' declares a servlet whose name is 'Fine'. The actual package and the name of the Servlet class is also declared. When the web container starts it instantiates a servlet of this kind and associates it with the name. The initial parameters are set to the ServletConfig class, and thus can be retrieved at runtime. This is a neat way of setting values to variables declaratively. You do not have to find a class and change code. Servlet mapping elements are used by the web container to determine which servlet to serve, depending on the URL sent from the browser. If the URL ends with a '/', in this case, servlet 'Fine' is offered for service. When the client requests a document other than the usual HTML (maybe a Microsoft Word document, might be an audio, video file, etc.), then the container checks for the mime-mapping element. The extension of such files and corresponding mime-type is documented in the descriptor.

The <load-on-startup> is used for pre-loading servlets. Servlets are usually thought to be instantiated when the first request comes in. However, we can have the servlet instantiated and left in the container right when the server starts. This element tells us the order in which it should be instantiated. In this case, there is only one servlet, hence the value is 1. Had there been two, we could have given the second servlet a value of '2' for the same element. This means Fine servlet will be instantiated and then the next one.


Simple file to configure usernames, passwords for different roles. A sample file would look like:

    <user name="adam" password="toyota" roles="admin" />
    <user name="dev"  password="web" roles="developer"  />
    <user name="dev"   password="web" roles="admin, developer" />

Role-based security revolves around declarations in xml files. You specify a 'role' and then you can assign users to those roles. An easy role to imagine would be an 'admin' role for someone who is going to have administrative rights. Another role would be a user. This is the sole purpose of this file.


Tomcat automatically puts all its log information in a file called 'catalina.out' in <Tomcat_Install_Dir>\jakarta-tomcat-5.0.25\logs.


This article tries to introduce the inquisitive to Tomcat servlet engine. For those really new is strongly encouraged to read my February article, and also strongly urged to post questions, comments on this site, for open discussion. There are many related technologies that you need to understand. For example, understanding the basics of a XML document, and what a XML Parser does. Covering XML parsers and XML DTD's were outside the scope of this article.

Prepared by Saikat Goswami, Boston, Massachussets,


Hello, Sai, I have red your article and it is simply superb. You have portrayed the whole scenario in such a way that any lay man can understand, please keep writing this sort of articles which are very helpful for us. Many thanks once again, regards, shabeer

Hi Raghubir,

Deploying through a *.war file is simple: place the file under the application root, and re-start Tomcat. That's all you have to do.

When Tomcat re-starts, it will automatically unzip the archive file and place it in the right directories.

Say, your application is named "myApp". So, you have a directory under "webapps" called "myApp". This is the root directory of the application. You can have HTML's, JSP's here.

Beneath this is the "WEB-INF" directory. Everything under "WEB-INF" is private. No HTML, JSP or any file beneath here can be served directly by the server. The deployment descriptor resides here.

Below "WEB-INF", you have two directories, "classes" and "lib".

"classes" hold the servlet/other helper classes.

"lib" holds the "jar" and other utility archive files like maybe, tools.jar or a jar file for a JDBC driver.

Long answer to a quick question,