This article is the first in a series of articles on Apache's Jakarta-Tomcat server. The Tomcat server is a Java-based Web Application container that was created to run Servlet and JavaServer Page web applications. It has become the reference implementation for both the Servlet and JSP specifications. The purpose of this first article is to give you a basic understanding of web applications. Once we have this basic understanding, we will be able to move on to discussions of Tomcat. This article assumes that you have a basic understanding of Servlets and JSPs.
In this article we will discuss
With the release of the Java Servlet Specification 2.2, the concept of a web application was introduced. According to this specification, a "Web Application is a collection of servlets, html pages, classes, and other resources that can be bundled and run on multiple containers from multiple vendors." To you and me, a web application is anything that resides in the web layer of an application.
One of the main characteristics of a web application is its relationship to the ServletContext. Each web application has one and only one ServletContext. This relationship is controlled by the servlet container and guarantees that web applications will not clash when storing objects in the ServletContext.
The following items can exist in a web application:
Note: For this series we will be using the proposed Servlet SDK 2.3.
The container that holds the components of a web application is the
directory structure in which it exists. The first step in creating a
web application is creating this structure. The following table
contains a sample web application, named
onjava, and what
each of its directories should contain. Each one of these directories
should be created from the
<SERVER_ROOT> of the
servlet container. An example of a
using Tomcat, would be
Table 1. The Web Application Directory Structure
This is the root directory of the web application. All JSP and XHTML files are stored here.
This directory contains all resources related to the application that are not in the document root of the application. This is where your web application deployment descriptor is located. Note that the WEB-INF directory is not part of the public document. No files contained in this directory can be served directly to a client.
This directory is where servlet and utility classes are located.
This directory contains Java Archive files that the web application depends upon. For example, this is where you would place a JAR file that contained a JDBC driver.
As you look over the contents of the web application's directory
structure, you will notice that web applications allow for classes to
be stored in both the
/WEB-INF/lib directories. Of these two, the class loader
will load classes from the
/classes directory first
followed by the JARs in the
/lib directory. If you have
duplicate classes in both the
/lib directories, the classes in the
/classes directory will be used.
At the heart of all web applications is a deployment
descriptor. The deployment descriptor is an XML file named web.xml
located in the
directory. It describes configuration information for the entire web
application. For our application the location of the
web.xml file is in the
/WEB-INF/ directory. The information that is contained in the
deployment descriptor includes the following elements:
The following code snippet contains a limited example of a web
application deployment descriptor. As we progress through this
series, we will be looking at the
web.xml file and its
elements in much more detail.
<web-app> <display-name>The OnJava App</display-name> <session-timeout>30</session-timeout> <servlet> <servlet-name>TestServlet</servlet-name> <servlet-class>com.onjava.TestServlet</servlet-class> <load-on-startup>1</load-on-startup> <init-param> <param-name>name</param-name> <param-value>value</param-value> </init-param> </servlet> </web-app>
In this example we are setting three application level
elements. The first of the application level elements is the
<display-name>. This element simply describes the
name of the web application. It is functionally inoperative.
The second web application level element is the
<session-timeout> element. This element controls
the lifetime of the application's HttpSession object. The
<session-timeout> value that we have used above
tells the JSP/Servlet container that the HttpSession object will
become invalid after 30 minutes of inactivity.
The last application level element that we have defined is the
<servlet> element. This element defines a servlet
and its properties. We will further define the
<servlet> elements when we discuss deploying
Servlets and JSPs to Tomcat in a subsequent article.
Now that we know what a web application is, we can package it for
deployment. The standard method for packaging web applications is to
use a Web ARchive file (WAR). You can create a WAR file by using
Java's archiving tool
jar. An example of this would be to
change to the root directory of your web application and type the
jar cvf onjava.war .
This command will produce an archive file named
onjava.war that will contain your entire web
application. Now you can deploy your web application by simply
distributing this file, which we will cover in the next article,
"Installing and Configuring Tomcat."
James Goodwill is the co-Founder of Virtuas Solutions, LLC, a Colorado-based software consultancy.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.