Directory Structure
A Web application exists as a structured hierarchy of directories. The root of this
hierarchy serves as the document root for files that are part of the application. For
example, for a Web application with the context path /catalog in a Web container,
the index.html file at the base of the Web application hierarchy or in a JAR file
inside WEB-INF/lib that includes the index.html under META-INF/resources
directory can be served to satisfy a request from /catalog/index.html. If an
index.html is present both in the root context and in the META-INF/resources
directory of a JAR file in the WEB-INF/lib directory of the application, then the file
that is available in the root context MUST be used. The rules for matching URLs to
context path are laid out in Chapter 12, “Mapping Requests to Servlets”. Since the
context path of an application determines the URL namespace of the contents of the
Web application, Web containers must reject Web applications defining a context
path that could cause potential conflicts in this URL namespace. This may occur, for
example, by attempting to deploy a second Web application with the same context
path. Since requests are matched to resources in a case-sensitive manner, this
determination of potential conflict must be performed in a case-sensitive manner as
well.
A special directory exists within the application hierarchy named “WEB-INF”. This
directory contains all things related to the application that aren’t in the document
root of the application. Most of the WEB-INF node is not part of the public document
tree of the application. Except for static resources and JSPs packaged in the METAINF/
resources of a JAR file that resides in the WEB-INF/lib directory, no other
files contained in the WEB-INF directory may be served directly to a client by the
container. However, the contents of the WEB-INF directory are visible to servlet code
using the getResource and getResourceAsStream method calls on the
ServletContext, and may be exposed using the RequestDispatcher calls. Hence, if
the Application Developer needs access, from servlet code, to application specific
configuration information that he does not wish to be exposed directly to the Web
client, he may place it under this directory. Since requests are matched to resource
mappings in a case-sensitive manner, client requests for ‘/WEB-INF/foo’, ‘/WEbiNf/
foo’, for example, should not result in contents of the Web application located
under /WEB-INF being returned, nor any form of directory listing thereof.
The contents of the WEB-INF directory are:
■ The /WEB-INF/web.xml deployment descriptor.
■ The /WEB-INF/classes/ directory for servlet and utility classes. The classes in
this directory must be available to the application class loader.
■ The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets,
beans, static resources and JSPs packaged in a JAR file and other utility classes
useful to the Web application. The Web application class loader must be able to
load classes from any of these archive files.
The Web application class loader must load classes from the WEB-INF/classes
directory first, and then from library JARs in the WEB-INF/lib directory. Also, except
for the case where static resources are packaged in JAR files, any requests from the
client to access the resources in WEB-INF/ directory must be returned with a
SC_NOT_FOUND(404) response.