Home | Download | PDF | API | FAQ | Search | Feedback | History

> ## Configuring Web Applications

> Web applications are configured via elements contained in the web application deployment descriptor.

> The following sections give a brief introduction to the web application features you will usually want to configure. A number of security parameters can be specified; these are covered in Securing Web Applications (page 945).

> In the following sections, examples demonstrate procedures for configuring the Hello, World application. If Hello, World does not use a specific configuration feature, the section gives references to other examples that illustrate how to specify the deployment descriptor element.

> ### Mapping URLs to Web Components

> When a request is received by the web container it must determine which web component should handle the request. It does so by mapping the URL path contained in the request to a web application and a web component. A URL path contains the context root and an alias:

>     http://host:port/context_root/alias

> #### Setting the Component Alias

> The alias identifies the web component that should handle a request. The alias path must start with a forward slash (`/`) and end with a string or a wildcard expression with an extension (for example, `*.jsp`). Since web containers automatically map an alias that ends with `*.jsp`, you do not have to specify an alias for a JSP page unless you wish to refer to the page by a name other than its file name. To set up the mappings for the servlet version of the `hello` application, first package it, as described in the following steps.

> 1. In a terminal window, go to `<``INSTALL``>/javaeetutorial5/examples/web/hello2/`.
> 2. Run `ant`. This target will build the WAR file and copy it to the `<``INSTALL``>/javaeetutorial5/examples/web/hello2/dist/` directory.

> To deploy the example using `ant`, run `ant` `deploy`. The deploy target in this case gives you an incorrect URL to run the application. To run the application, please use the URL shown at the end of this section.

> To configure this example, the `web.xml` file must contain the following:

> - A `display-name` element set to `hello2`
> - Two `servlet` elements to add the `GreetingServlet` and `ResponseServlet` servlets to the WAR file
> - A `servlet-mapping` element to map `GreetingServlet` to the `/greeting` URL pattern
> - Another `servlet-mapping` element to map `ResponseServlet` to the `/response` URL pattern

> The `sun-web.xml` file needs a `context-root` element set to `/hello2`.

> To run the application, first deploy the web module, and then open the URL `http://localhost:8080/hello2/greeting` in a browser.

> ### Declaring Welcome Files

> The welcome files mechanism allows you to specify a list of files that the web container will use for appending to a request for a URL (called a valid partial request) that is not mapped to a web component.

> For example, suppose you define a welcome file `welcome.html`. When a client requests a URL such as `host:port/webapp/directory`, where `directory` is not mapped to a servlet or JSP page, the file `host:port/webapp/directory``/welcome.html` is returned to the client.

> If a web container receives a valid partial request, the web container examines the welcome file list and appends to the partial request each welcome file in the order specified and checks whether a static resource or servlet in the WAR is mapped to that request URL. The web container then sends the request to the first resource in the WAR that matches.

> If no welcome file is specified, the Application Server will use a file named `index.``XXX`, where `XXX` can be `html` or `jsp`, as the default welcome file. If there is no welcome file and no file named `index.``XXX`, the Application Server returns a directory listing.

> To specify a welcome file in the web application deployment descriptor, you need to nest a `welcome-file` element inside a `welcome-file-list` element. The `welcome-file` element defines the JSP page to be used as the welcome page. Make sure this JSP page is actually included in your WAR file.

> The example discussed in Encapsulating Reusable Content Using Tag Files (page 204) has a welcome file.

> ### Setting Initialization Parameters

> The web components in a web module share an object that represents their application context (see Accessing the Web Context, page 85). You can pass initialization parameters to the context or to a web component.

> To add a context parameter you need the following in the example's web.xml file:

> - A `param-name` element that specifies the context object
> - A `param-value` element that specifies the parameter to pass to the context object.
> - A `context-param` element that encloses the previous two elements.

> For a sample context parameter, see the example discussed in The Example JSP Pages (page 97).

> To add a web component initialization parameter you need the following in the example's web.xml file:

> - A `param-name` element that specifies the name of the initialization parameter
> - A `param-value` element that specifies the value of the initialization parameter
> - An `init-param` element that encloses the previous two elements

> ### Mapping Errors to Error Screens

> When an error occurs during execution of a web application, you can have the application display a specific error screen according to the type of error. In particular, you can specify a mapping between the status code returned in an HTTP response or a Java programming language exception returned by any web component (see Handling Errors, page 64) and any type of error screen. To set up error mappings, add the following elements in the example's `web.xml` file:

> - An exception-type element specifying either the exception or the HTTP status code that will cause the error page to be opened
> - A location element that specifies the name of a web resource to be invoked when the status code or exception is returned. The name should have a leading forward slash (`/).`
> - An error-page element that encloses the previous two elements

> You can have multiple `error-page` elements in your deployment descriptor. Each one of the elements identifies a different error that causes an error page to open. This error page can be the same for any number of error-page elements.

> Note: You can also define error screens for a JSP page contained in a WAR. If error screens are defined for both the WAR and a JSP page, the JSP page's error page takes precedence. See Handling Errors (page 104).

> For a sample error page mapping, see the example discussed in The Example Servlets (page 58).

> ### Declaring Resource References

> If your web component uses objects such as enterprise beans, data sources, or web services, you use Java EE annotations to inject these resources into your application. Annotations eliminate a lot of the boilerplate lookup code and configuration elements that previous versions of Java EE required.

> Although resource injection using annotations can be more convenient for the developer, there are some restrictions from using it in web applications. First, you can only inject resources into container-managed objects. This is because a container must have control over the creation of a component so that it can perform the injection into a component. As a result, you cannot inject resources into objects such as simple JavaBeans components. However, JavaServer Faces managed beans are managed by the container; therefore, they can accept resource injections.

> Additionally, JSP pages cannot accept resource injections. This is because the information represented by annotations must be available at deployment time, but the JSP page is compiled after that; therefore, the annotation will not be seen when it is needed. Those components that can accept resource injections are listed in Table 2-1.

> Table 2-1 Web Components That Accept Resource Injections
> Component | Interface/Class
> --- | ---
> Servlets | `javax.servlet.Servlet`
> Servlet Filters | javax.servlet.ServletFilter
> Event Listeners | `javax.servlet.ServletContextListener` `javax.servlet.ServletContextAttributeListener` `javax.servlet.ServletRequestListener` `javax.servlet.ServletRequestAttributeListener` `javax.servlet.http.HttpSessionListener` `javax.servlet.http.HttpSessionAttributeListener` `javax.servlet.http.HttpSessionBindingListener`
> Taglib Listeners | same as above
> Taglib Tag Handlers | `javax.servlet.jsp.tagext.JspTag`
> Managed Beans | Plain Old Java Objects

> This section describes how to use a couple of the annotations supported by a servlet container to inject resources. Chapter 25 describes how web applications use annotations supported by the Java Persistence API. Chapter 30 describes how to use annotations to specify information about securing web applications.

> #### Declaring a Reference to a Resource

> The `Resource` annotation is used to declare a reference to a resource such as a data source, an enterprise bean, or an environment entry. This annotation is equivalent to declaring a `resource-ref` element in the deployment descriptor.

> The `Resource` annotation is specified on a class, method or field. The container is responsible for injecting references to resources declared by the `Resource` annotation and mapping it to the proper JNDI resources. In the following example, the `Resource` annotation is used to inject a data source into a component that needs to make a connection to the data source, as is done when using JDBC technology to access a relational database:

>     @Resource javax.sql.DataSource catalogDS;
>     public getProductsByCategory() {
>       // get a connection and execute the query
>       Connection conn = catalogDS.getConnection();
>       ..
>     }

> The container injects this data source prior to the component being made available to the application. The data source JNDI mapping is inferred from the field name `catalogDS` and the type, `javax.sql.DataSource`.

> If you have multiple resources that you need to inject into one component, you need to use the `Resources` annotation to contain them, as shown by the following example:

>     @Resources ({
>       @Resource (name="myDB" type=java.sql.DataSource),
>       @Resource(name="myMQ" type=javax.jms.ConnectionFactory)
>     })

> The web application examples in this tutorial use the Java Persistence API to access relational databases. This API does not require you to explicitly create a connection to a data source. Therefore, the examples do not use the `Resource` annotation to inject a data source. However, this API supports the `PersistenceUnit` and `PersistenceContext` annotations for injecting `EntityManagerFactory` and `EntityManager` instances, respectively. Chapter 25 describes these annotations and the use of the Java Persistence API in web applications.

> #### Declaring a Reference to a Web Service

> The `WebServiceRef` annotation provides a reference to a web service. The following example shows uses the `WebServiceRef` annotation to declare a reference to a web service. `WebServiceRef` uses the `wsdlLocation` element to specify the URI of the deployed service's WSDL file:

>     ...
>     import javax.xml.ws.WebServiceRef;
>     ...
>     public class ResponseServlet extends HTTPServlet {
>     @WebServiceRef(wsdlLocation=
>       "http://localhost:8080/helloservice/hello?wsdl")
>     static HelloService service;