Introducing Tomcat

The Apache Jakarta Project creates and maintains open source solutions on the
Java platform for distribution to the public at no charge. Apache Jakarta Tomcator just Tomcat--is one of those projects
Tomcat is a container for servlets. Tomcat can act as a simple standalone
server for Web applications that use HTML, servlets, and JSP. Apache is an
industrial-strength, highly optimized server that can be extended with Tomcat
If you want to get Tomcat, one reasonable download site is
http://mirrors.xtria.com/apache/jakarta/tomcat-5/v5.0.29/bin/
A web application is basically a web site that:
- Knows who you are-it doesnt just give you static pages, it interacts with
you
- Can permanently change data (such as in a database)
- A web application can consist of multiple pieces
- Static web pages (possibly containing forms)
- Servlets
- JSP
- Tomcat organizes all these parts into a single directory structure for each
web application
To create servlets, you really should have two directory structures:
- Development directory, in which you can write and partially debug your code
- Deployment directory, in which you put live code
Tomcat requires a particular set of directories for your web application
Flow
1. The user submits an HTML form
2. Tomcat finds the servlet based on the URL and the deployment descriptor
(web.xml) and passes the request to the servlet
3. The servlet computes a response
4. Either: The servlet writes an HTML page containing the response
Or: The servlet forwards the response to the JSP
5. The JSP embeds the response in an HTML page
6. Tomcat returns the HTML page to the user
Alternatives to Tomcat
Suns Java Web Server
Old, no longer being developed, all in Java
Java Web Server Development Kit (JWSDK)
Official reference implementation
Difficult to install and configure
JBoss

Open source
Opinions vary on how easy it is to install
Comes with built-in database
Many CGI replacements have been built on top of the Apache Web server
(http://www.apache.org) because of Apache's popular modular API. This
allows developers to extend Apache's functionality with persistent programs
and thus is ideal for creating programs for handling dynamic content. Apache
loads modules into its memory when it starts and passes the appropriate
HTTP requests to them as appropriate. It then passes the HTTP responses
back out to the browser once the modules have processed the requests. As
the modules are already in the server's memory, the cost of loading an
interpreter is removed and scripts can execute faster.
Microsoft provides an interface to its Internet Information Server (IIS) Web
server, called the Internet Server Application Programming Interface (ISAPI).
This hasn't got the following that Apache's API has because of its complexity,
but it's nevertheless a high-performance API. However, the IIS Web server is
used widely, mainly because it comes as part of many versions of Windows.
Later in the book you will configure Tomcat to work with IIS to combine the
best features of both.
Microsoft also developed the Active Server Pages (ASP) technology, which
lets you embed scripts, typically VBScript, into standard HTML pages. This
model has proved extremely successful and was the catalyst for Java Web
technology, which we'll discuss shortly.To the reviewer: is this still the case for
ASP? Not sure what ASP.Net has added.
Introducing Java on the Web
Java applets never really caught on to any degree and other technologies,
such as Macromedia Flash, became more popular ways of creating interactive
Web sites. However, Java isn't just for writing applets: you can also use it to
create stand-alone platform-independent applications. Java applications
haven't really caught on yet either probably because Java's support for
creating GUI applications has until recently been quite poor. This situation is
changing, and in fact today's versions of Java do enable developers to create
cutting-edge GUI applications.
The main contribution of Java to the Web is servlets, which are another
alternative technology to CGI. Just as CGI and its other alternatives are not
stand-alone programs, a web server, in this case it is called a servlet
container, must load servlets into memory. The servlet container then receives
HTTP requests from browsers and passes them to servlets that generate the
response. The servlet container can also integrate with other Web servers to
use their more efficient static file abilities while continuing to produce the
dynamic content. An example of this is found later in the book when you will
integrate Tomcat with Apache.
One major practical difference between servlets and JSP pages is that
servlets are provided in compiled form and JSP pages are often not (although

pre-compilation is possible). What this means for a system administrator is

that servlet files are held in the private resources section of the server, while
JSP files are mixed in with static HTML pages, images, and other resources in
the public section.

Servlet Containers
JSP and servlets require a servlet container to operate at all it is the
reference implementation (RI) servlet container, which means that Tomcat's
first priority is to be fully compliant with the Servlet and JSP Specifications
published by Sun. However, this isn't to say that it's not worthy of use in
production systems. Indeed, many commercial installations use Tomcat.
Looking at Tomcat
Tomcat has its origins in the earliest days of the servlet technology. Sun
created the first servlet container, called the Java Web Server, which
demonstrated the technology but it wasn't terribly robust. At the same time,
the Apache Software Foundation (ASF) created JServ, a servlet engine that
integrated with the Apache web server.
In 1999, Sun donated the Java Web Server code to the ASF and the two
projects were merged to create Tomcat. Version 3.x was the first version of
Tomcat and was directly descended from the original code that Sun provided
to the ASF. It is still available and is the RI of the Servlet 2.2 and JSP 1.1
Specifications.
Tomcat 5.0.x is the current Tomcat version and is the RI of the Servlet 2.4
and JSP 2.0 Specifications. As such, this is the version of Tomcat that we will
use in this book.
Tomcat's Architecture
The ASF completely remodeled Tomcat's architecture in Tomcat 4.x and
rebuilt it from the ground up. As a result, a heated discussion about whether
this was actually necessary began. Those who disagreed took the 3.3 code
base and branched it from the main development tree to continue refactoring
the old code base. Tomcat 3.3 supports Servlet 2.2 and JSP 1.1. This left
Tomcat 4.x to become the main focus of the project. However, Tomcat 4.0.x is
now only receiving security fixes and Tomcat 4.1.x is only receiving new
enhancements periodically. Tomcat 4.x supports the Servlet 2.3 and JSP 1.2
Specifications.
The latest version of Tomcat is 5.0.x, which supports the Servlet 2.4 and
JSP 2.0 specifications. It consists of a nested hierarchy of components:
a. Top-level components exist at the top of the configuration
hierarchy in a rigid relationship with one another
b. Connectors connect the servlet container to the Web browser
making requests
c. Container components contain a collection of other components
d. Nested components can reside in containers, but cannot contain
other components
When configuring Tomcat, some of these objects may be removed without
affecting the server. Notably, the engine and host may be unnecessary if you
are using a web server such as Apache.

Separate servers configured to different ports can be set up on a single

server to separate applications so that they can be restarted independently.
So, if a given JVM crashes, the other applications will be safe in another
instance of the server. This is sometimes done in hosting environments where
each customer has a separate instance of a JVM, so a badly written
application will not cause others to crash.
The Service Component
A service component groups an engine component with its connectors. An
engine is a request-processing component that represents the servlet engine.
It examines the HTTP headers to determine which host or context (that is,
web application) it should pass the pass the request to. Each service is
named so that administrators can easily identify log messages sent from each
service.
So, this component accepts requests, routes them to the appropriate web
application, and returns the result of the request processing.
The Connector Components
Connectors connect web applications to clients. They are the point where
requests are received from clients and each has a unique port on the server.
Tomcat's default HTTP port is 8080 to avoid interference with any web server
running on the standard HTTP port. However, this can be changed as long as
the new port does not already have a service associated with it.
The default connector implements HTTP 1.1. The alternative is the AJP
connector, which is a connector for linking with Apache to make use of its SSL
and static content processing capabilities. We will discuss each of these later
in the book.
The Container Components
The container components receive the requests from the top-level
components as appropriate. They then deal with the request process and
return the response to the component that sent it to them.
The Engine Component
The engine component is the top-level container and cannot be contained
by another container component. Only one may be contained in each service
component.
If Tomcat is used as a standalone server the defined engine is the default.
However, if Tomcat is configured to provide servlet support with a web server
providing the static pages, the default engine is overridden as the web server has
normally determined the correct destination for the request.
The host name of the server is set in the engine component if required. An
engine may contain hosts representing a group of web applications and contexts,
each representing a single web application.

The Host Component

A host component is analogous to the Apache virtual host functionality.
This allows multiple servers to be configured on the same physical machine
and be identified by separate IP addresses or hostnames. In Tomcat's case,
the virtual hosts are differentiated by a fully qualified host name. Thus we can
have http://www.apress.com and http://www.moodie.com on the same server.
In this case, the servlet container routes requests to the different groups of
web applications.
The Context Component
The final container component, and the one at the lowest level, is the
context, also known as the web application. When you configure a context
you inform the servlet container of the location of the root folder of the
application so that components that contain this component can route
requests effectively
A context component may also include error pages, which will allow you to
configure error messages consistent with the look and feel of the application.
The Nested Components
The nested components are nested within container components and
provide a number of administrative services. You cannot nest all of them in
every container component but many of them can be nested this way. The
exception to the container component rule is the global resources component,
which you can only nest within a server component.
The Global Resources Component
As already mentioned, this component may only be nested within a server
component. You use this component to configure global JNDI resources that
all the other components in the server can make use of. Typically these could
be datasources for database access or server-wide constants for use in
application code.
The Loader Component
The loader component may only be nested within a context component.
You use a loader to specify a web application's classloader, which will load the
application's classes and resources into memory. The classloader you specify
must follow the Servlet Specification. It is unlikely that you will find it
necessary to use this component as the default classloader works perfectly
well.
The Logger Component
A logger component reports on the internal state of its parent component.
You can include a logger in any of the container components. Logging
behavior is inherited so a logger set at the engine level is assigned to every
child object unless overridden by the child. The configuration of loggers at this
level can be a convenient way to decide the default logging behavior for the
server.

This allows you to configure a convenient destination for all logging events
for those components that are not configured to generate their own logs.
The Manager Component
The manager component represents a session manager for working with
user sessions in a web application. As such, it can only be included in a
context container. A default manager component is used if you do not specify
an alternative and, like the loader component above, you will find that the
default is perfectly good.
The Realm Component
The realm for an engine manages user authentication and authorization.
As part of the configuration of an application you set the roles that are allowed
for each resource or group of resources and the realm is used to enforce this
policy.
Realms can authenticate against text files, database tables, LDAP servers,
and the Windows network identity of the user.
A realm applies across the entire container component in which it is
included and so applications within a container share authentication
resources. By default, a user must still authenticate separately to each web
application on the server (this is called single sign-on). We will see how this
can be changed later in the book.
The Resources Component
The resources component can be added to a context component. It
represents the static resources in a web application and allows them to be
stored in alternative formats such as compressed files. The default is more
than sufficient for most needs.
The Valve Component
You can use valve components to intercept a request and process it before
it reaches its destination. Valves are analogous to filters as defined in the
Servlet Specification, without the response post-processing abilities. They
aren't in the JSP or Servlet Specifications. You may place valve components
in any container component.
Valves are commonly used to log requests, client IP addresses, and server
usage. This technique is known as request dumping and a request dumper
valve records the HTTP header information and any cookies sent with the
request. Response dumping logs the response headers and cookies (if set) to
a file.
There are other useful facilities, such as listeners, that you can use when
configuring Tomcat. However, they are not defined as components. We will
deal with them later in the chapter.

Installing and Running Tomcat

INTRODUCTION
Tomcat is a servlet container and JavaServer Pages(tm) implementation. It may
e used stand alone, or in conjunction with several popular web servers:
i. Apache, version 1.3 or later
ii. Microsoft Internet Information Server, version 4.0 or later
iii. Microsoft Personal Web Server, version 4.0 or later
iv. Netscape Enterprise Server, version 3.0 or later
Tomcat requires a Java Runtime Environment conformant to JRE 1.1 or
later, including any Java2 platform system. If you wish to develop applications,
you will need a Java compiler, such as the one included in a Java Development
Kit 1.1 or later environment, including JDKs conformant with Java2.
Tomcat 3.3 shell and batch files ignore your CLASSPATH environment variable.
Tomcat directory structure
The directory containing the Tomcat system is referred to as CATALINA_HOME
below.
bin/
Binary executables and scripts
common/
Classes available to both Catalina internal classes and web
applications:
classes/
Unpacked common classes
lib/
Common classes in JAR files
conf/
Configuration files
logs/
Destination directory for log files
server/
Internal Catalina classes and their dependencies
classes/
Unpacked classes (internal only)
lib/
Classes packed in JAR files (internal only)
shared/
Classes shared by all web applications
classes/
Unpacked shared classes
lib/
Shared classes in JAR files
webapps/
Base directory containing web applications included
the Tomcat 4.1
work/
Scratch directory used by Tomcat for holding temporary
les and directories
temp/
Directory used by JVM for temporary files
(java.io.tmpdir)

Starting the Tomcat server

Run the CATALINA_HOME\bin\startup.bat file to start the server. The default
Tomcat website should now be available at http://localhost:8080.
Stopping the Tomcat server
Run the CATALINA_HOME\bin\shutdown.bat file to start the server.
The directory structure of a web application
Create a new directory in CATALINA_HOME\webapps\myapp. All new
servlet directories must have the following subdirectory structure:
myapp/
contains auxiliary files (e.g. HTML, GIF, CSS,JSP files).
WEB-INF/
contains deployment descriptor, web.xml classes/ contains
Servlet class files (in subdirectories according to packages)
lib/
contains extra jar files
Using the normal jar-tool, a complete Web application can be wrapped into a
portable Web Archive (.war).