Section 3.3. Web Applications

3.3. Web Applications

Now that we've seen a basic servlet, we can step back for a moment and talk about how servlets are integrated into the servlet container. A web application consists of a set of resources, including servlets, static content, JSP files, and class libraries, installed in a particular path on a web server. This path is called the servlet context, and all servlets installed within the context are given an isolated, protected environment to operate in, without interference from (or the ability to interfere with) other software running on the server.

A servlet context directory tree contains several different types of resources. These include class files and jar files (which aren't exposed to clients connecting via web browsers), JSP files (which are processed by the JSP servlet before being fed back to the client), and static files, such as HTML documents and JPEG images, which are served directly to the browser by the web server.

The context has a virtual component, too. For each context, the servlet container will instantiate separate copies of servlets and will create a private address space that can be accessed via the ServletContext class. Servlets running in the same context can use this class to communicate with each other. We'll discuss this more later.

The simplest servlet installations create just a single context, rooted at /, which is the top of the web server path tree. Servlets and static content are installed within this context. Most of the time, you'll create multiple servlet contexts , rooted lower down on the directory tree. A catalog application, for example, could be rooted at /catalog, with all of the application paths below the context root.

If you write a web application that will be installed on multiple web servers, it isn't safe to assume the context root will be fixed. If the path of a resource within your application is /servlet/CatalogServlet, and it's installed within the /catalog context, rather than writing:

 out.println("<a href=\"/catalog/servlet/CatalogServlet\">");

you should write:

 out.println(   "<a href=\"" + request.getContextPath(  ) + "/servlet/CatalogServlet\">");

This approach works regardless of the context path installed within the web server. Of course, in most cases, you shouldn't be writing HTML directly out of the servlet anywaysee Chapters 4, 5, and 19 on JSP, JSF, and Struts for more on the separation of content and business logic in web applications.

3.3.1. Structure of Web Applications

On disk, a web application consists of a directory. The directory contains a subdirectory called WEB-INF and whatever other content is required for the application. The WEB-INF directory contains a classes directory (containing application code), a lib directory (containing application jar files), and a file called web.xml. The web.xml file contains all of the configuration information for the servlets within the context, including names, path mappings, initialization parameters, and context-level configuration information.

The procedure for installing a web application into a servlet container varies from product to product, but it generally consists of selecting a context root and pointing the server to the directory containing the web application.^[*]

^[*] Web applications can be packaged into jar file equivalents called war files. Just use the jar utility that comes with the JDK to pack up the web application directory (including the WEB-INF subdirectory) and give the resulting file a .war extension, or use the war target in an Ant script.

3.3.2. Mapping Requests with a Context

Servlets are installed within the servlet container and mapped to URIs. This is done either via global properties that apply to all servlets or by specific, servlet-by-servlet mappings. In the first case, a client invokes a servlet by requesting it by name. Some servers map servlets to a /servlet/ or /servlets/ URL. If a servlet is installed as PageServlet, a request to /servlet/PageServlet would invoke it. Servlets can also be individually mapped to other URIs or to file extensions. PageServlet might be mapped to /pages/page1 or to all files with a .page extension (using *.page).

All of these mappings exist below the context level. If the web application is installed at /app, the paths entered into the browser for the examples earlier would be /app/servlet/PageServlet, /app/pages/page1, or /app/file.page. Of course, if they are entered into a browser, these paths represent only the end of the full URL, which must also include the protocol, host, and port information (e.g., http://myserver.org:8080).

To illustrate, imagine the servlet mappings (all are below the context root) in Table 3-1.

Table 3-1. Example servlet mappings

Mapping	Servlet
/store/furniture/*	FurnitureServlet
/store/furniture/tables/*	TableServlet
/store/furniture/chairs	ChairServlet
*.page	PageServlet

The asterisk serves as a wildcard. URIs matching the pattern are mapped to the specified servlet, provided that another mapping hasn't already been used to deal with the URL. This can get a little tricky when building complex mapping relationships, but the Servlet API does require servers to deal with mappings consistently. When the servlet container receives a request, it always maps it to the appropriate servlet in the following order:

1. Exact path matching

   A request to /store/furniture/chairs is served by ChairServlet.

2. Prefix mapping

   A request to /store/furniture/sofas is served by FurnitureServlet. The longest matching prefix is used. A request to /store/furniture/tables/dining is served by TableServlet.

3. Extension

   Requests for /info/contact.page are served by PageServlet. However, requests for /store/furniture/chairs/about.page is served by FurnitureServlet (since prefix mappings are checked first, and ChairServlet is available only for exact matches).

If no appropriate servlet is found, the server returns an error message or attempts to serve content on its own. If a servlet is mapped to the / path, it becomes the default servlet for the application and is invoked when no other servlet is found.

3.3.3. Context Methods

Resources within a servlet context (such as HTML files, images, and other data) can be accessed directly via the web server. If a file called index.html is stored at the root of the /app context, then it can be accessed with a request to /app/index.html. Context resources can also be accessed via the ServletContext object, which is accessed via the getresource( ) and getresourceAsStream( ) methods . A full list of available resources can be accessed via the getresourcePaths( ) method. In this case, an InputStream containing the contents of the index.html file can be retrieved by calling getresourceAsStream("/index.html") on the ServletContext object associated with the /app context.

The ServletContext interface provides servlets with access to a range of information about the local environment. The getInitParameter( ) and getInitParameterNames( ) methods allow servlets to retrieve context-wide initialization parameters. ServletContext also includes a number of methods that allow servlets to share attributes. The setAttribute( ) method allows a servlet to set an attribute that can be shared by any other servlets that live in its ServletContext, and removeAttribute( ) allows a servlet to remove an attribute from the application context. The getAttribute( ) method, which previously allowed servlets to retrieve hardcoded server attributes, provides access to attribute values, while getAttributeNames( ) returns an Enumeration of all the shared attribute names.

The servlet container is required to maintain a temporary working directory on disk for each servlet context. This directory is accessed by retrieving the javax.servlet.context.tempdir attribute, which consists of a java.io.File object pointing to the temporary directory. Each servlet must have its own temporary directory. The servlet container is not required to maintain its contents across restarts, so if you store something there, it may not be there if the servlet container restarts.