Pro Apache Tomcat 5/5.5 (Experts Voice in Java)

You shouldn’t have many dealings with a Web application’s web.xml file, as it’s the realm of the application’s developer. However, certain aspects on the server are definitely your concern, so the following sections will go into the relevant sections in web.xml. They will be illustrated where possible by examples from Tomcat’s default web.xml file.

<distributable>

The <distributable> element, if present, declares that this Web application can be deployed in a distributed servlet container or servlet container executing across multiple JVMs either running on the same host or different hosts. This Boolean value is false by default.

<context-param>

The <context-param> element declares a context initialization parameter, much as the previous <Parameter> element does. It contains the following:

<filter>

The <filter> element declares a filter. A filter is a Java class that preprocesses the request data received from clients. This preprocessing may include decryption, formatting, or other processes. This element contains the following:

Each <init-param> element contains the following:

Listing 5-1.

Listing 5-1: An Entry for a Filter

<filter> <filter-name>requestFilter</filter-name> <filter-class>com.apress.admin.filters.RequestFilter</filter-class> <init-param> <param-name>allow</param-name> <param-value></param-value> </init-param> <init-param> <param-name>deny</param-name> <param-value>127.0.0.1</param-value> </init-param> <init-param> <param-name>blockPage</param-name> <param-value>/blocked.html</param-value> </init-param> </filter>

<filter-mapping>

The <filter-mapping> element maps a filter to a servlet or a set of URLs. It contains the following:

If the <dispatcher> element is omitted, the default value is REQUEST.

The previous filter would have the filter mapping as shown in Listing 5-2.

Listing 5-2: An Example Filter Mapping

<filter-mapping> <filter-name>requestFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

This maps all requests in the Web application to the filter.

<servlet>

Because you’ve already seen the <servlet> element in action, I won’t discuss it in detail here. It contains the following:

Each <init-param> element contains the following:

A <security-role-ref> element maps a role name called from within the servlet and maps the name of a security role defined for the Web application. It contains the following:

Tomcat’s default web.xml file contains many <servlet> entries. The first is for the default servlet, as shown in Listing 5-3.

Listing 5-3: The Default Servlet <servlet> Setting

<servlet> <servlet-name>default</servlet-name> <servlet-class> org.apache.catalina.servlets.DefaultServlet </servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>

<servlet-mapping>

The <servlet-mapping> element maps a servlet to a URL pattern. It contains the following:

The previous default servlet has a corresponding <servlet-mapping> entry, as shown in Listing 5-4.

Listing 5-4: The Default Servlet <servlet-mapping> Setting

<servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

<session-config>

An administrator should be aware of the session settings of a Web application because it can have performance and security implications. A huge number of long-lasting sessions may cause problems for performance, but a session that never expires means that a user is always recognized. The latter means that any user who has access to the original user’s machine can access the Web application as that user.

The <session-config> element contains the following:

Listing 5-5 shows the default session setting from Tomcat’s default web.xml file.

Listing 5-5: The Default Session Setting for Tomcat

<session-config> <session-timeout>30</session-timeout> </session-config>

<mime-mapping>

Browsers use MIME types to recognize the file type returned by the server so that the browser can handle the response correctly. That is, the browser chooses whether to display it (HTML, plain text, images), send it to a plug-in (such as Flash), or prompt the user to save it locally.

As you saw in Chapter 4, CATALINA_HOME/conf/web.xml comes with many MIME mappings set. However, you can configure additional MIME mappings in each Web application with the <mime-mapping> element.

The <mime-mapping> element contains the following:

Tomcat has many MIME mappings set, one of which is shown in Listing 5-6. This tells Tomcat to treat *.bmp files as the image/bmp type.

Listing 5-6: A Default Tomcat MIME Mapping

<mime-mapping> <extension>bmp</extension> <mime-type>image/bmp</mime-type> </mime-mapping>

<welcome-file-list>

The <welcome-file-list> element defines an ordered list of welcome files to display if no filename is specified. It contains the following:

Tomcat has a default setting for welcome files, as shown in Listing 5-7.

Listing 5-7: Tomcat’s Default Welcome Files

<welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list>

These files are checked in the order they appear.

<error-page>

Web application developers can configure error pages to provide a user-friendly mechanism for informing the users about any problems and allowing them to continue using the application. The errors are mapped to the HTTP specification error mappings: a code for a resource that can’t be found, a malfunctioning server, authentication issues, resource issues, and so on.

In addition, since there are no one-to-one correspondences between HTTP errors and Java exceptions, the exception class type may be specified; this allows error pages that are generic and follows good programming practice. Someone without an understanding of the application’s internals can configure them.

The <error-page> element contains the following:

Listing 5-8 shows an example of an error page setting. In this case any 404 errors generated by Tomcat will return the myError.jsp page to the client.

Listing 5-8: An Error Page Configuration

<error-page> <error-code>404</error-code> <location>/myError.jsp</location> </error-page>

<resource-env-ref>

The <resource-env-ref> element declares that the Web application references an administered object such as a user database. This is defined in the <GlobalNamingResources> element of the server component. It contains the following:

The manager application configures a reference to a global resource, as shown in Listing 5-9.

Listing 5-9: The Manager Web Application’s <resource-env-ref> Setting

<resource-env-ref> <description> Link to the UserDatabase instance from which we request lists of defined role names. Typically, this will be connected to the global user database with a ResourceLink element in server.xml or the context configuration file for the manager Web application. </description> <resource-env-ref-name>users</resource-env-ref-name> <resource-env-ref-type> org.apache.catalina.UserDatabase </resource-env-ref-type> </resource-env-ref>

<resource-ref>

The <resource-ref> element declares that the Web application references an external resource such as a data source reference. This is typically configured in a context entry using the <Resource> element. It contains the following:

Listing 5-10 shows an example.

Listing 5-10: A Reference to a JDBC Data Source

<resource-ref> <description> Resource reference to a factory for java.sql.Connection instances that may be used for talking to a particular database that is configured in the tomcatBook.xml file. </description> <res-ref-name> jdbc/CatalogDB </res-ref-name> <res-type> javax.sql.DataSource </res-type> <res-auth> SERVLET </res-auth> </resource-ref>

<security-constraint>

Web resources may be associated with some security constraints for user authentication and access control. The constraints limit access to the resource according to user roles, such as manager, administrator, user, and guest, and by transport guarantee, which can include SSL secure data transmission, guaranteeing delivery and noninterference.

The <security-constraint> element contains the following:

A <web-resource-collection> element identifies a set of resources within the application; it can be qualified by specifying particular HTTP method(s) such as GET or POST. (By default, the security constraint applies to all HTTP methods.) It contains the following:

An <auth-constraint> element indicates that certain user roles should be permitted to access these Web resources. It contains the following:

A <user-data-constraint> element indicates how data transmitted between the client and the application should be protected. It contains the following:

Table 5-6: <transport-guarantee> Values

Value

Description

NONE

No transport guarantee is required.

INTEGRAL

The data must not be changed in transit.

CONFIDENTIAL

Others may not view the data en route.

The manager Web application contains a security constraint on all its resources, as shown in Listing 5-11.

Listing 5-11: The Manager Web Application’s Security Constraint

<security-constraint> <web-resource-collection> <web-resource-name>HTMLManager and Manager command</web-resource-name> <url-pattern>/jmxproxy/*</url-pattern> <url-pattern>/html/*</url-pattern> <url-pattern>/list</url-pattern> <url-pattern>/sessions</url-pattern> <url-pattern>/start</url-pattern> <url-pattern>/stop</url-pattern> <url-pattern>/install</url-pattern> <url-pattern>/remove</url-pattern> <url-pattern>/deploy</url-pattern> <url-pattern>/undeploy</url-pattern> <url-pattern>/reload</url-pattern> <url-pattern>/save</url-pattern> <url-pattern>/serverinfo</url-pattern> <url-pattern>/status/*</url-pattern> <url-pattern>/roles</url-pattern> <url-pattern>/resources</url-pattern> </web-resource-collection> <auth-constraint> <!-- NOTE: This role isn't present in the default users' file --> <role-name>manager</role-name> </auth-constraint> </security-constraint>

<login-config>

The <login-config> element configures the authentication mechanism for this application. It contains the following:

The manager application defines a <login-config> to go along with the security constraint described previously (see Listing 5-12).

Listing 5-12: The Manager Web Application’s Login Configuration

<login-config> <auth-method>BASIC</auth-method> <realm-name>Tomcat Manager Application</realm-name> </login-config>

<security-role>

The <security-role> element declares a security role used in the Web application’s security-constraints. It contains the following:

The manager application defines a security role to go along with the security constraint described previously (see Listing 5-13).

Listing 5-13: The Manager Web Application’s Security Role

<security-role> <description> The role that is required to log in to the Manager Application </description> <role-name>manager</role-name> </security-role>

Категории