Understanding Web Application Structure

A Web application is a collection of Web resources, such as JSP pages, HTML pages, servlets, and configuration files, organized into a hierarchy as specified in the Servlet specification. You have two ways in which to organize a Web application: packed and unpacked. The packed form is called a Web archive (WAR) file, and the unpacked form is a collection of directories stored on the file system.

The unpackaged format is convenient for Web application developers, as it allows them to replace individual files while the application is being developed and debugged.

However, in a deployment environment, it’s often more convenient to provide a single file that can be automatically deployed. This reduces the deployment process to placing the file and setting up system resources. Tomcat can also automatically expand a Web application once the server has booted. The automatic expansion of WAR files is configured in the server.xml file as part of the <Host> element that configures hosts.

Web Application Context

Each Web application corresponds to a context component, as discussed in Chapter 1, and you assign a context path to each. The default context is called ROOT and corresponds to the name of the server with no other context information. For example, the ROOT Web application on your local machine will correspond to http://localhost:8080. If you’ve configured Domain Name System (DNS) settings for your server, it may also be accessible from a location such as http://www.companyname.com/.

Users access other Web applications by requesting a context relative to the server. For example, users can access Tomcat’s manager Web application with the following URL: http://localhost:8080/manager/.

Applications that you place in the webapps folder are named after the directory they’re in. So, you can access the Web application in the tomcat-docs directory with the following: http://localhost:8080/tomcat-docs/. Each application on the server is known by its name, and users can access resources according to the remainder of the uniform resource locator (URL) after the Web application’s name.

This setup has a slight problem, however. If the ROOT Web application contains a subdirectory that has the same name as a Web application, and that Web application and that subfolder have filenames in common, then the applications won’t work as expected. For example, the following are two Web applications that could cause confusion:

 webapps/          ROOT/               tomcatBook/                          index.html          tomcatBook/                     index.html 

In this case http://localhost:8080/tomcatBook/ could map to both files and could cause confusion. Tomcat will display the index.html page from the tomcatBook Web application and will ignore the folder in the ROOT Web application. If your users are expecting the ROOT version, then they will be disappointed.

The WEB-INF Directory

The Servlet specification sets out how you partition Web applications into public and private areas. You store the private resources in a directory called WEB-INF in the root of the Web application. This is where you store all the Web application–specific configuration files, application classes, and application-specific utilities. Users may only access these resources indirectly (for example, through servlet mappings).

WEB-INF has a number of specialized subdirectories, where you store specific files, such as tag files and tag library descriptors (TLDs). These are defined in the appropriate specification, be it for servlets or JSP pages. You’ll deal with them in detail in Chapter 5 when you configure a Web application, but here’s a quick rundown:

 webAppX/          WEB-INF/                  classes/                  lib/                  tags/ 

The classes and lib directory follow the usual pattern in Tomcat; you place class files in classes and JAR files in lib. tags is a special directory for tag files, which are a new part of the JSP 2.0 specification.

The META-INF Directory

The META-INF directory is placed at the root of a Web application when it’s deployed as a WAR file. This is where you place tag TLDs and tag files so that they can be found using a unique uniform resource indicator (URI). If no context XML files for this WAR file exist, then you can also place one in this directory. You’ll find more details of this directory in Chapter 5.