Home > Articles > Programming > Java

This chapter is from the book

4.2 Structure of a Web Application

The process of registering a Web application is not standardized; it frequently involves server-specific configuration files or user interfaces. However, the Web application itself has a completely standardized format and is totally portable across all Web or application servers that support version 2.2 or later of the servlet specification. The top-level directory of a Web application is simply a directory with a name of your choosing. Within that directory, certain types of content go in designated locations. This section provides details on the type of content that is placed in various locations; it also gives a sample Web application layout.

Locations for Various File Types

Quick summary: JSP pages and other normal Web documents go in the top-level directory, unbundled Java classes go in the WEB-INF/classes directory, JAR files go in WEB-INF/lib, and the web.xml file goes in WEB-INF. Figure 4–9 shows a representative example. For details or a more explicit sample hierarchy, check out the following subsections.

Figure 4–9 A representative Web application

JSP Pages

JSP pages should be placed in the top-level Web application directory or in a subdirectory with any name other than WEB-INF or META-INF. Servers are prohibited from serving files from WEB-INF or META-INF to the user. When you register a Web application (see Section 4.1), you tell the server the URL prefix that designates the Web app and define where the Web app directory is located. It is common, but by no means mandatory, to use the name of the main Web application directory as the URL prefix. Once you register a prefix, JSP pages are then accessed with URLs of the form http://hostname/webAppPrefix/filename.jsp (if the pages are in the top-level directory of the Web application) or http://hostname/webAppPrefix/subdirectory/filename.jsp (if the pages are in a subdirectory).

It depends on the server whether a default file such as index.jsp can be accessed with a URL that specifies only a directory (e.g., http://hostname/webAppPrefix/) without the developer first making an entry in the Web app's WEB-INF/web.xml file. If you want index.jsp to be the default filename, I strongly recommend that you make an explicit welcome-file-list entry in your Web app's web.xml file. For example, the following web.xml entry specifies that if a URL gives a directory name but no filename, the server should try index.jsp first and index.html second. If neither is found, the result is server specific (e.g., a directory listing).


For details, see Section 5.7 (Specifying Welcome Pages).

HTML Documents, Images, and Other Regular Web Content

As far as the servlet and JSP engine is concerned, HTML files, GIF and JPEG images, style sheets, and other Web documents follow exactly the same rules as do JSP pages. They are placed in exactly the same locations and accessed with URLs of exactly the same form. In deployment scenarios, however, a servlet or JSP engine such as JRun, ServletExec, Tomcat, or Resin is often plugged into a regular Web server like Microsoft IIS, Apache, or older versions of the Netscape Web server. In such a case, the regular Web server usually serves regular Web pages more quickly than does the servlet and JSP engine. So, if your static Web documents are accessed extremely frequently, you are faced with a portability vs. performance trade-off. Putting the static documents in the Web application hierarchy lets you move the servlets, the JSP pages, and the static documents from server to server with a minimum of changes. Putting the static resources in the regular Web server's hierarchy increases performance but requires server-specific changes when you move the Web app to another server. Fortunately, this issue is important only for the highest-traffic pages.

It depends on the server whether a default file such as index.html can be accessed with a URL that specifies only a directory (e.g., http://hostname/webAppPrefix/) without the developer first making an entry in the Web app's WEB-INF/web.xml file. If you want index.html to be the default filename, I recommend that you make an explicit welcome-file-list entry in web.xml. For details, see Section 5.7 (Specifying Welcome Pages).

Servlets, Beans, and Helper Classes (Unbundled)

Servlets and other .class files are placed either in WEB-INF/classes or in a subdirectory of WEB-INF/classes that matches their package name. During development, don't forget that your CLASSPATH should include the classes directory. The server already knows about this location, but your development environment does not. In order to compile servlets that are in packages, the compiler needs to know the location of the top-level directory of your package hierarchy. See Section 1.6 (Set Up Your Development Environment) for details.

The default way to access servlets is with URLs of the form http://hostname/web-AppPrefix/servlet/ServletName or http://hostname/webAppPrefix/servlet/package-Name.ServletName. To designate a different URL, you use the servlet-mapping element in the web.xml deployment descriptor file that is located within the WEB-INF directory of the Web application. See Section 5.3 (Assigning Names and Custom URLs) for details.

Servlets, Beans, and Helper Classes (Bundled in JAR Files)

If the servlets or other .class files are bundled inside JAR files, then the JAR files should be placed in WEB-INF/lib. If the classes are in packages, then within the JAR file they should be in a directory that matches their package name.

Deployment Descriptor

The deployment descriptor file, web.xml, should be placed in the WEB-INF subdirectory of the main Web application directory. For details on using web.xml, see Chapter 5 (Controlling Web Application Behavior with web.xml). Note that a few servers (e.g., Tomcat) have a global web.xml file that applies to all Web applications. That file is entirely server specific; the only standard web.xml file is the per-application one that is placed within the WEB-INF directory of the Web app.

Tag Library Descriptor Files

TLD files can be placed almost anywhere within the Web application. However, I recommend that you put them in a tlds directory within WEB-INF. Grouping them in a common directory (e.g., tlds) simplifies their management. Placing that directory within WEB-INF prevents end users from retrieving them. JSP pages, however, can access TLD files that are in WEB-INF. They just use a taglib element as follows

<%@ taglib uri="/WEB-INF/tlds/myTaglibFile.tld" ...%> 

Since it is the server, not the client, that accesses the TLD file in this case, the prohibition that content inside of WEB-INF is not Web accessible does not apply.

WAR Manifest File

When you create a WAR file (see Section 4.3), a MANIFEST.MF file is placed in the META-INF subdirectory. Normally, the jar utility automatically creates MANI-FEST.MF and places it in the META-INF directory, and you ignore it if you unpack the WAR file. Occasionally, however, you modify MANIFEST.MF explicitly (see Section 4.4), so it is useful to know where it is stored.

Sample Hierarchy

Suppose you have a Web application that is in a directory named widgetStore and is registered (see Section 4.1) with the URL prefix /widgetStore. Following is one possible structure for the Web app.


These files would be accessed with the URLs http://hostname/widget-Store/orders.jsp and http://hostname/widgetStore/specials.html, respectively.


These files would be accessed with the URLs http://hostname/widget-Store/info/company-profile.jsp and http://hostname/widgetStore/ info/contacts.html, respectively.

Since the orders.jsp and specials.html files are in the same directory as this file, they would use a simple relative URL to refer to the image, as below.

<IMG SRC="founder.jpg" ...> 

Since company-profile.jsp and contacts.html are in a lower-level directory, they would use a relative URL that contains "..", as below.

<IMG SRC="../founder.jpg" ...> 

But what if you want to support the flexibility of moving a JSP page to a different directory without changing the URL that refers to the image? Or what if a servlet wants to refer to this image? This is slightly more complicated; see Section 4.5 (Handling Relative URLs in Web Applications) for a discussion of the problem and its solutions.

Since the orders.jsp and specials.html files are in the parent directory of this file, they would refer to the image by using a relative URL that contains the directory name, as below.

<IMG SRC="images/button1.gif" ...> 

Since company-profile.jsp and contacts.html are in a sibling directory, they would use a relative URL that contains ".." and the directory name, as below.

<IMG SRC="../images/founder.gif" ...> 

Again, if you want to be able to move the JSP page without changing the image URL or if you want to refer to the image from a servlet, things are a bit complicated. See Section 4.5 (Handling Relative URLs in Web Applications) for a discussion of the problem and its solutions.

This tag library descriptor file would be referenced from a JSP page by use of a taglib element as follows.

<%@ taglib uri="/WEB-INF/tlds/widget-taglib.tld" ...%> 

Note that the JSP page that uses this TLD file can be located anywhere within the widgetStore Web app directory. Note, too, that there is no potential problem regarding relative URLs as there is with images (as mentioned in the previous two subsections). Also note that it is legal (recommended, in fact) to place the tlds directory within the WEB-INF directory, even though the WEB-INF directory is not accessible to Web clients. It is legal because the server, not the client, retrieves the TLD file.

This is the deployment descriptor. It is not accessible by Web clients; it is used only by the server itself. See Chapter 5 (Controlling Web Application Behavior with web.xml) for details on its use.

This packageless servlet would be accessed either with the URL http://hostname/widgetStore/servlet/CheckoutServlet or with a custom URL that starts with http://hostname/widgetStore/. The web.xml file would define the custom URL; see Section 5.3 (Assigning Names and Custom URLs) for details.

This servlet from the cart package would be accessed either with the URL http://hostname/widgetStore/servlet/cart.ShowCart or with a custom URL that starts with http://hostname/widgetStore/. Again, the web.xml file would define the custom URL. Remember that dots, not slashes, separate package names from class names in URLs that refer to servlets. So be sure to use http://hostname/widgetStore/servlet/cart.ShowCart, not http://hostname/widgetStore/servlet/cart/ShowCart.

The Utils.jar file could contain utility classes used by the servlets and by various JSP pages. If the classes are in packages, they should be in subdirectories within the JAR file, and the servlets or JSP pages that use them must utilize import statements.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020