Java Web Applications

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

• the definition of a web application,
• the directory structure of a web application,
• the web application deployment descriptor, and
• packaging a web application.

The definition of a web application

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:

• Servlets
• JavaServer Pages
• Utility Classes
• Static Documents including, XHTML, images, etc.
• Client side classes
• Meta information that describes the web application

Note: For this series we will be using the proposed Servlet SDK 2.3.

The Directory Structure

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 <SERVER_ROOT>, using Tomcat, would be /jakarta-tomcat-4.0/webapps.

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/classes and /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 /classes and /lib directories, the classes in the /classes directory will be used.

The Web application deployment descriptor

At the heart of all web applications is a deployment descriptor. The deployment descriptor is an XML file named web.xml located in the /<SERVER_ROOT>/applicationname/WEB-INF/ directory. It describes configuration information for the entire web application. For our application the location of the web.xml file is in the /<SERVER_ROOT>/onjava /WEB-INF/ directory. The information that is contained in the deployment descriptor includes the following elements:

• ServletContext Init Parameters
• Localized Content
• Session Configuration
• Servlet / JSP Definitions
• Servlet / JSP Mappings
• Mime Type Mappings
• Welcome File list
• Error Pages
• Security

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.

Packaging a Web application

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 following command:

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.