Mapping requests to servlets

This is a good time to digress for a moment and discuss how the URLs that a user types into a browser are mapped to the correct web application and servlet. When a web application is installed in a container, the container is responsible for assigning a ServletContext to it. There is a single instance of a ServletContext object for each web application deployed in a container.

If the container is distributable and uses more than one JVM, the web application may have a separate ServletContext instance for each JVM.

The ServletContext provides an external view of the web container environment for a servlet. A servlet can use the ServletContext object to gain access to external resources, log events, and store attributes and objects that other servlet instances in the same context can access. It's essentially an application-scope shared resource.

Because a servlet is associated with a specific web application, all requests that begin with a specific request path (known as the context path) are routed to the web application associated with that servlet. Servlets associated with the default application have an empty string (" ") as the context path.

When a web container receives a client request, it must determine the correct web application to forward it to. The web container determines this by matching the URL with the longest context path that matches an installed web application.

For example, suppose that there are two web applications installed in a container. One web application is given the name Storefront and is located off the root directory of the container at /storefront. The second web application is called Storefront_ demo and is located off the root directory at /storefront_demo.

If a client request arrives at the server with a URL of http://www.somehost.com/ storefront_demo/login.do, the server will match it to the web application that has the closest match, which in this case would be the Storefront_demo application. Once the container determines the correct context or web application, it must determine which servlet in the web application should process the request. The web container uses the request URL, minus the context path, to determine the path that will be used to map the request to the correct servlet.

The web container uses the following guidelines to find the first successful match:

1. The container attempts to locate an exact match of the request path to the path of a servlet.

2. The container recursively tries to match the longest path prefix. The servlet that contains the longest match, if any, is selected.

3. If the URL path contains an extension—for example, .do—the servlet container tries to match a servlet that handles requests for that extension. The extension is defined as the part of the segment after the last dot (.).

4. If none of the previous rules produces a match, the container attempts to use a default servlet, if one is configured. Otherwise, the request returns an error response.

The web container uses case-sensitive string comparisons when checking for a match.

The concept of extension mappings was mentioned in Step 3 of the matching guidelines. There is another type of mapping that can be used, known as path mapping. A servlet-mapping that uses path mapping allows a URL that doesn't contain an extension to match to the servlet. Using the earlier Storefront servlet mapping, the following partial web.xml file illustrates how path mapping is configured:

<web-app>  

 <servlet>

  <servlet-name>storefront</servlet-name>

  <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>

 </servlet>

 <servlet-mapping>

  <servlet-name>storefront</servlet-name>

  <url-pattern>/action/*</url-pattern>

 </servlet-mapping>

</web-app>

Using path mapping, all requests mapped to this web application that contain the string "/action" in the request URL will be serviced by the Storefront servlet, regardless of what is in place of the * character.