F.2 Web Application Deployment
Descriptor
A very important file is the
WEB-INF/web.xml file. It is the application deployment
descriptor that contains all configuration information for the
application. If your application consists only of JSP and HTML
files, you typically don't need to worry about this file at
all. But if the application also contains servlets or uses the
container provided security mechanisms, you often need to
define some configuration information in the web.xml
file.
The deployment descriptor is an XML file. A
standard XML Document Type Definition (DTD) defines the
elements it can contain and how they must be arranged. Example
F-1 shows a version of the
complete DTD but
without the comments. All elements are instead described after
the example.
Example F-1. Java Web
Application Descriptor DTD <!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<!ELEMENT web-app (icon?, display-name?, description?, distributable?,
context-param*, filter*, filter-mapping*, listener*, servlet*,
servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?,
error-page*, taglib*, resource-env-ref*, resource-ref*,
security-constraint*, login-config?, security-role*,
env-entry*, ejb-ref*, ejb-local-ref*)>
<!ELEMENT icon (small-icon?, large-icon?)>
<!ELEMENT small-icon (#PCDATA)>
<!ELEMENT large-icon (#PCDATA)>
<!ELEMENT display-name (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT distributable EMPTY>
<!ELEMENT context-param (param-name, param-value, description?)>
<!ELEMENT param-name (#PCDATA)>
<!ELEMENT param-value (#PCDATA)>
<!ELEMENT filter (icon?, filter-name, display-name?, description?,
filter-class, init-param*)>
<!ELEMENT filter-name (#PCDATA)>
<!ELEMENT filter-class (#PCDATA)>
<!ELEMENT init-param (param-name, param-value, description?)>
<!ELEMENT filter-mapping (filter-name, (url-pattern | servlet-name))>
<!ELEMENT url-pattern (#PCDATA)>
<!ELEMENT listener (listener-class)>
<!ELEMENT listener-class (#PCDATA)>
<!ELEMENT servlet (icon?, servlet-name, display-name?, description?,
(servlet-class|jsp-file), init-param*, load-on-startup?, run-as?, security-role-ref*)>
<!ELEMENT servlet-name (#PCDATA)>
<!ELEMENT servlet-class (#PCDATA)>
<!ELEMENT jsp-file (#PCDATA)>
<!ELEMENT load-on-startup (#PCDATA)>
<!ELEMENT run-as (description?, role-name)>
<!ELEMENT security-role-ref (description?, role-name, role-link?)>
<!ELEMENT role-link (#PCDATA)>
<!ELEMENT servlet-mapping (servlet-name, url-pattern)>
<!ELEMENT session-config (session-timeout?)>
<!ELEMENT session-timeout (#PCDATA)>
<!ELEMENT mime-mapping (extension, mime-type)>
<!ELEMENT extension (#PCDATA)>
<!ELEMENT mime-type (#PCDATA)>
<!ELEMENT welcome-file-list (welcome-file+)>
<!ELEMENT welcome-file (#PCDATA)>
<!ELEMENT error-page ((error-code | exception-type), location)>
<!ELEMENT error-code (#PCDATA)>
<!ELEMENT exception-type (#PCDATA)>
<!ELEMENT location (#PCDATA)>
<!ELEMENT taglib (taglib-uri, taglib-location)>
<!ELEMENT taglib-uri (#PCDATA)>
<!ELEMENT taglib-location (#PCDATA)>
<!ELEMENT resource-env-ref (description?, resource-env-ref-name,
resource-env-ref-type)>
<!ELEMENT resource-env-ref-name (#PCDATA)>
<!ELEMENT resource-env-ref-type (#PCDATA)>
<!ELEMENT resource-ref (description?, res-ref-name, res-type, res-auth,
res-sharing-scope?)>
<!ELEMENT res-ref-name (#PCDATA)>
<!ELEMENT res-type (#PCDATA)>
<!ELEMENT res-auth (#PCDATA)>
<!ELEMENT res-sharing-scope (#PCDATA)>
<!ELEMENT security-constraint (display-name?, web-resource-collection+,
auth-constraint?, user-data-constraint?)>
<!ELEMENT web-resource-collection (web-resource-name, description?,
url-pattern*, http-method*)>
<!ELEMENT auth-constraint (description?, role-name*)>
<!ELEMENT user-data-constraint (description?, transport-guarantee)>
<!ELEMENT web-resource-name (#PCDATA)>
<!ELEMENT http-method (#PCDATA)>
<!ELEMENT login-config (auth-method?, realm-name?, form-login-config?)>
<!ELEMENT auth-method (#PCDATA)>
<!ELEMENT realm-name (#PCDATA)>
<!ELEMENT form-login-config (form-login-page, form-error-page)>
<!ELEMENT form-login-page (#PCDATA)>
<!ELEMENT form-error-page (#PCDATA)>
<!ELEMENT security-role (description?, role-name)>
<!ELEMENT role-name (#PCDATA)>
<!ELEMENT transport-guarantee (#PCDATA)>
<!ELEMENT env-entry (description?, env-entry-name, env-entry-value?,
env-entry-type)>
<!ELEMENT env-entry-name (#PCDATA)>
<!ELEMENT env-entry-value (#PCDATA)>
<!ELEMENT env-entry-type (#PCDATA)>
<!ELEMENT ejb-ref (description?, ejb-ref-name, ejb-ref-type,
home, remote, ejb-link?)>
<!ELEMENT ejb-ref-name (#PCDATA)>
<!ELEMENT ejb-ref-type (#PCDATA)>
<!ELEMENT home (#PCDATA)>
<!ELEMENT remote (#PCDATA)>
<!ELEMENT ejb-link (#PCDATA)>
<!ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type,
local-home, local, ejb-link?)>
<!ELEMENT local-home (#PCDATA)>
<!ELEMENT local (#PCDATA)>
If you're not familiar with DTD syntax, don't
worry. This DTD contains only element declarations, and
the rules are simple. The <!ELEMENT ...>
declaration contains two parts: the element name and the
element syntax rules within parenthesis. The rule part in this
DTD contains the following types of rules:
-
A comma-separated list of elements. The
named elements must appear in the same order in the XML
document. For example, the taglib declaration says
that a <taglib> element must contain first a
<taglib-uri> element and then a
<taglib-location> element: <!ELEMENT taglib (taglib-uri, taglib-location)>
-
An element name followed by a question
mark. This means that the named element is optional. For
instance, an <init-param> element must
contain a <param-name> and a
<param-value> element, optionally followed by
a <description> element: <!ELEMENT init-param (param-name, param-value, description?)>
-
An element name followed by a plus sign
means that the named element can be used one or more times.
A <welcome-file-list> can contain one or more
<welcome-file> elements, for instance: <!ELEMENT welcome-file-list (welcome-file+)>
-
An element name followed by an asterisk.
This means the element can be used zero or more times.
That's the case for the <role-name> element
in an <auth-constraint> element: <!ELEMENT auth-constraint (description?, role-name*)>
-
Two element names separated by a vertical
bar means that one of the elements must be used but not
both. An example of this is found in the
<servlet> element declaration, which says it
must contain either a <servlet-class> element
or a <jsp-file> element: <!ELEMENT servlet (icon?, servlet-name, display-name?, description?,
(servlet-class|jsp-file), init-param*, load-on-startup?, run-as?,
security-role-ref*)>
-
The #PCDATA
keyword means parsed character
data, in other words, ordinary text as opposed to
nested subelements.
The first element declaration in the DTD,
shown in Example
F-1, is the main element for the web.xml file,
named the <web-app> element: <!ELEMENT web-app (icon?, display-name?, description?, distributable?,
context-param*, filter*, filter-mapping*, listener*, servlet*,
servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?,
error-page*, taglib*, resource-env-ref*, resource-ref*,
security-constraint*, login-config?, security-role*,
env-entry*, ejb-ref*, ejb-local-ref*)>
It contains a comma-separated list of all the
top-level elements that the <web-app> element can contain.
All of them are optional (marked with question marks or
asterisks). The rest of this section describes all these
elements in more detail.
| <icon>, <display-name>,
and <description> |
|
The first three elements provide
information a web container deployment tool can use to
describe the application. The <icon> element can contain
a <small-icon> and a
<large-icon> element, each with a
context-relative path to an image file (GIF and JPEG formats
are supported). The <display-name> element can specify
a name for the application, and the
<description> element for a longer description: <icon>
<small-icon>/images/small.gif</small-icon>
<large-icon>/images/large.gif</large-icon>
</icon>
<display-name>The application name</display-name>
<description>
A longer description of
the application.
</description>
The <distributable> element tells the
web container that the application is designed to run in a
distributed web container. This element doesn't contain a
body: <distributable/>
A distributable application doesn't rely on
servlet instance variables, static classes or variables,
servlet context attributes, or any other mechanism for shared
information that is restricted to one Java Virtual Machine
(JVM). It also means that all objects placed in the session
scope are serializable, so that the container can move the
session data from one JVM to another. For more information
about distributed applications, see Chapter
17.
Using the <context-param> element, you can
define context parameters that are available to all components
of the application (both servlets and JSP pages). The
<param-name> sub-element specifies the name and
the <param-value> element the value.
Optionally, the <description> element can be
used for a description that can be displayed by a deployment
tool: <context-param>
<param-name>jdbcURL</param-name>
<param-value>jdbc:idb:/usr/local/db/mydb.prp</param-value>
</context-param>
The <filter> element registers a
filter component, described in Chapter
19. Nested <icon>,
<display-name>, and
<description> elements can optionally define
icons and descriptions that can be used by a tool. The nested
<filter-name> element defines a unique logical
name for the filter, and the <filter-class>
element the class name. A set of initialization parameters can
optionally be defined by <init-param> elements:
<filter>
<filter-name>accessControl</filter-name>
<filter-class>com.mycomp.AccessControlFilter</filter-class>
<init-param>
<param-name>loginPage</param-name>
<param-value>/login.jsp</param-value>
</init-param>
</filter>
A filter is mapped to either a URI pattern or
a servlet using the <filter-mapping> element. The
<filter-name> subelement identifies the filter
using a name defined by a <filter> element. A
<url-pattern> or a
<servlet-name> defines when the filter shall be
invoked. If a URL mapping is used, the same values as for a
<servlet-mapping> element can be used. More
than one filter may match a specific request. If so, the
container chains them in the order the matching
<filter-mapping> elements appear in the
deployment descriptor: <filter-mapping>
<filter-name>accessControl</filter-name>
<url-pattern>/protected</url-pattern>
</filter-mapping>
All the listener types described in Chapter
19 must be registered with a <listener> element. The nested
<listener-class> element contains the listener
class name: <listener>
<listener-class>com.mycomp.AppInitListener</listener-class>
</listener>
The <servlet> element can describe
a servlet class or a JSP page, to give it a short name and to
specify initialization parameters: <servlet>
<servlet-name>
purchase
</servlet-name>
<servlet-class>
com.mycorp.servlets.PurchaseServlet
</servlet-class>
<init-param>
<param-name>maxAmount</param-name>
<param-value>500.00</param-value>
</init-param>
</servlet>
<servlet>
<servlet-name>
order-form
</servlet-name>
<jsp-file>
/po/orderform.jsp
</jsp-file>
<init-param>
<param-name>bgColor</param-name>
<param-value>blue</param-value>
</init-param>
</servlet>
The same servlet class (or JSP page) can be
defined with multiple names, typically with different
initialization parameters. The container creates one instance
of the class for each name.
The <load-on-startup>
subelement can tell the container to load the servlet when the
application is started. The value is a positive integer,
indicating when the servlet is to be loaded relative to other
servlets. A servlet with a low value is loaded before a
servlet with a higher value: <servlet>
<servlet-name>
controller
</servlet-name>
<servlet-class>
com.mycorp.servlets.ControllerServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
The <icon>,
<display-name>, and
<description> elements can describe the servlet
or JSP page the same way as these elements can describe the
application.
<security-role-ref> elements,
combined with <security-role> elements, can
link a security role name used in a servlet as the argument to
the HttpServletRequest.isUserInRole( ) method to a
role name known by the web container. <servlet>
<servlet-name>
controller
</servlet-name>
<servlet-class>
com.mycorp.servlets.ControllerServlet
</servlet-class>
<security-role-ref>
<role-name>administrator</role-name>
<role-link>admin</role-link>
</security-role-ref>
</servlet>
...
<security-role>
<role-name>admin</role-name>
</security-role>
All role names defined by
<security-role> elements must be mapped to
users and/or groups known by the web container. How this is
done is container-dependent. The
<security-role-ref> element allows you to use a
servlet that uses a role name in the isUserInRole( )
method not defined by a <security-role>
element. A typical scenario where this can be useful is when
you combine servlets from different sources in one
application, and the servlets use different role names for the
same logical role.
Finally, the <run-as> element
can define the security role that the servlet should be
presented as if it makes calls into an EJB container. The
nested <role-name> value must be defined by a
<security-role> elements: <servlet>
<servlet-name>
controller
</servlet-name>
<servlet-class>
com.mycorp.servlets.ControllerServlet
</servlet-class>
<run-as>
<role-name>admin</role-name>
</run-as>
</servlet>
...
<security-role>
<role-name>admin</role-name>
</security-role>
See the J2EE documentation for details about
how to use this element.
Most containers support a special URI prefix
(/servlet) that can invoke any servlet class the
container has access to, for instance the URI
/servlet/com.mycompany.MyServlet can be invoke the
servlet class com.mycomapany.MyServlet. This isn't
mandated by the specification, however, so to make sure the
application is portable, it's better to map a unique path to a
servlet instead. Explicit mapping also simplifies references
between servlets and JSP pages, as described in Chapter
18. The <servlet-mapping> element is used
for this purpose. The <servlet-name> subelement
contains a name defined by a <servlet> element,
and the <url-pattern> contains the pattern that
should be mapped to the servlet (or JSP page): <servlet-mapping>
<servlet-name>purchase</servlet-name>
<url-pattern>/po/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>sales-report</servlet-name>
<url-pattern>/report</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>XMLProcessor</servlet-name>
<url-pattern>*.xml</url-pattern>
</servlet-mapping>
A pattern can take one of four forms:
-
A path prefix
pattern starts with a slash (/) and ends
with /*, for instance /po/*.
-
An extension
mapping pattern starts with *., for instance
*.xml.
-
A default servlet
pattern consists of just the / character.
-
All other patterns are exact match patterns.
When the container receives a request, it
strips off the context path and then tries to find a pattern
that matches a servlet mapping. Exact match patterns are
analyzed first, then the path prefix patterns starting with
the longest one, and then the extension mapping patterns. If
none of these patterns match, the default servlet pattern is
used, if specified. As a last resort, the containers default
request processor handles the request.
With the mappings defined here, a URI such as
/po/supplies invokes the purchase servlet,
/report invokes the sales-report servlet (note that
/report/spring doesn't, because an exact match
pattern is used), and /eastcoast/forecast.xml invokes
the XMLProcessor servlet.
The <session-config> element contains
just one subelement: the <session-timeout>
element used to specify the default session timeout value in
minutes: <session-config>
<session-timeout>30</session-timeout>
</session-config>
A servlet may need to know which MIME type a file
extension corresponds to. The <mime-mapping> element can
define the mappings an application requires: <mime-mapping>
<extension>wml</extension>
<mime-type>text/vnd.wap.wml</mime-type>
</mime-mapping>
Most containers provide default mappings for
the most commonly used extensions, such as .html,
.htm, .gif, .jpg, and so on, but if
you need to be absolutely sure that a mapping is defined for
your application, put it in the web.xml file.
A welcome file is a file that the container serves
when it receives a request URI that identifies a directory as
opposed to a web page or a servlet. The
<welcome-file-list> element can define an
ordered list of files to look for in the directory and serve
if present: <welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
</welcome-file-list>
When a directory entry request is received
that doesn't match a servlet mapping, the container appends
each welcome filename in the order specified in the deployment
descriptor to the request URI and checks whether a resource in
the WAR is mapped to the new URI. If it is, the request is
forwarded to the resource. If no matching resource is found,
the behavior is container-dependent. The container may, for
instance, return a directory listing or an HTTP 404 status
code (Not Found).
The <error-page> element can define
pages that inform the user about various errors. A page can be
specified for an HTTP error status code, such as 404 (Not
Found), using the <error-code> subelement. As
an alternative, the <exception-type> subelement
can specify a Java exception class name, to use a special page
to handle exceptions thrown by servlets and JSP pages. The
<location> sub-element contains the
context-relative path for the error page: <error-page>
<error-code>404</error-code>
<location>/errors/404.html</location>
</error-page>
<error-page>
<exception-type>javax.servlet.ServletException</exception-type>
<location>/errors/exception.jsp</location>
</error-page>
The <taglib> element maps the
symbolic name for a tag library specified by the
taglib directive in a JSP page to the location of the
Tag Library Descriptor (TLD) file or JAR file that contains
the TLD file. The <taglib-uri> element value
must match the uri attribute value used in the JSP
page, and the <taglib-location> subelement
contains the context-relative path to the library file: <taglib>
<taglib-uri>orataglib</taglib-uri>
<taglib-location>/WEB-INF/lib/orataglib_1_0.jar</taglib-location>
</taglib>
With the introduction of the auto-discovery
feature in JSP 1.2, this element is rarely needed. For more
details, see Chapter
20.
In a complete J2EE-compliant container (i.e.,
one that supports other J2EE technologies besides servlets and
JSP), the container can provide access to so-called
administered objects through JNDI. Example of this type of
object are those used by the Java Messaging System (JMS) API.
The <resource-env-ref> elements declares the
JNDI path that accesses the object in the application and its
type, using nested <resource-env-ref-name> and
<resource-end-ref-type> elements: <resource-env-ref>
<resource-env-ref-name>jms/StockQueue</resource-env-ref-name>
<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>
Optionally, a description can be provided by
the <description> element.
A J2EE-compliant container (and some web containers that
support JNDI in addition to servlets and JSP) can also provide
access to resource factories that produce the objects used in
an application, such as a DataSource that produces
Connection objects for database access, as described
in Chapter
23. The <resource-ref> element defines
these factories using the <res-ref-name> to
specify the JNDI path used in the application, the
<res-type> for the type of the factory type,
and <res-auth> to define whether the
authentication is performed by the application (with the
Application value) or the container (with the
Container value). An optional
<res-sharing-scope> element can define if the
objects produced by the factory may be shared or not (with
Shareable and Unshareable, respectively, the
prior being the default): <resource-ref>
<res-ref-name>jdbc/Products</res-ref-name>
<res-ref-type>javax.sql.DataSource</res-ref-type>
<res-auth>Container</res-auth>
</resource-ref>
As for most elements, a
<description> element can also provide a
description to help the deployer.
The <security-constraint> element contains a
<web-resource-collection> subelement that
defines the resources to be protected and an
<auth-constraint> subelement that defines who
has access to the protected resources. It can also contain a
<user-data-constraint> subelement that
describes security requirements for the connection used to
access the resource: <security-constraint>
<web-resource-collection>
<web-resource-name>admin</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</ transport-guarantee>
</user-data-constraint>
</security-constraint>
Within the
<web-resource-collection> element, the resource
is given a name with the <web-resource-name>
subelement, and the URI patterns for the protected resources
are specified with <url-pattern> elements.
<http-method> sub-elements can also restrict
the types of accepted requests. This example protects all
resources accessed with URIs that start with /admin
and says that only the GET method can access these
resources.
The <role-name> subelements
within the <auth-constraint> element specify
the roles the current user must have to get access to the
resource. The value should be a role name defined by a
<security-role> element, but some containers
(such as Tomcat) accept role names that aren't defined by
<security-role> elements as well. In this
example, the user must belong to the admin role in
order to access resources under /admin. How the role
names are mapped to user and/or group names in the container's
security system is container-dependent.
A <transport-guarantee>
element can contain one of three values:
- NONE
-
No special requirements. This is the
default.
- INTEGRAL
-
Data must be sent between the client and
server so that it can't be changed in transit. Typically
this means that an SSL connection is required.
- CONFIDENTIAL
-
Data must be sent in such a way that it
can't observed by others. This is also typically satisfied
by an SSL connection.
For an application that uses the
<security-constraint> element to protect
resources, you must also define how to authenticate users with
a <login-config> element. It can contain three
subelements: <auth-method>,
<realm-name>, and
<form-login-config>: <login-config>
<auth-method>BASIC</auth-method>
<realm-name>Protected pages</realm-name>
</login-config>
The <auth-method> element can
have one of the values BASIC, DIGEST,
FORM. and CLIENT-CERT, corresponding to the
four container-provided authentication methods described in Chapter
12. The <realm-name> element can specify
the name shown by the browser when it prompts for a password
when BASIC and DIGEST authentication is
used.
If FORM authentication is used, the
<form-login-config> element defines the login
page and an error pages (used for invalid login attempts):
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Protected pages</realm-name>
<form-login-config>
<form-login-page>/login/login.html</form-login-page>
<form-error-page>/login/error.html</form-error-page>
</form-login-config>
</login-config>
For more about the FORM
authentication method, see Chapter
12.
<security-role> elements define the
role names the application uses in isUserInRole( )
calls, <security-role-ref> elements, and
<auth-constraint> elements: <security-role>
<role-name>admin</role-name>
</security-role>
Each role must be mapped to a user and/or
group in the container's security domain in a
container-dependent way.
The <env-entry> element defines
simple objects, such as a String or Boolean,
used by the application. The <env-entry-name>
defines the name and <env-entry-type> the type,
which must be one of java.lang.Boolean,
java.lang.Byte, java.lang.Character,
java.lang.String, java.lang.Short,
java.lang.Integer, java.lang.Long,
java.lang.Float, or java.lang.Double. The
value can optionally be defined statically, using the
<env-entry-value> element or be provided at
deployment. An optional <description> element
is also supported: <env-entry>
<env-entry-name>maxConnections</env-entry-name>
<env-entry-value>100</env-entry-value>
<env-entry-type>java.lang.Integer</env-entry-type>
</env-entry>
In a J2EE-compliant container, the
<ejb-ref> element declares EJB objects. The
name (JNDI path), type (Entity or Session),
home and remote interface class names must be specified with
the <ejb-ref-name>,
<ejb-ref-type>, <home>, and
<remote> elements: <ejb-ref>
<ejb-ref-name>ejb/Payroll</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.mycomp.PayrollHome</home>
<remote>com.mycomp.Payroll</remote>
</ejb-ref>
An optional <ejb-link> element
can uniquely identify a specific bean if more than one EJB has
the same name. In addition, an optional
<description> element can add a description of
the EJB.
The <ejb-local-ref> element serves the same purpose as the
<ejb-ref> element but for local beans. It
supports all the same nested elements, except that
<home> is replaced by
<local-home> and <remote> is
replaced by <local>: <ejb-local-ref>
<ejb-ref-name>ejb/Payroll</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home>com.mycomp.PayrollHome</local-home>
<local>com.mycomp.Payroll</local>
</ejb-local-ref>
| Example Application Deployment
Descriptor |
|
Example
F-2 shows an example of a deployment descriptor
(web.xml) file:
Example F-2. Example
deployment descriptor file <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>
purchase
</servlet-name>
<servlet-class>
com.mycomp.servlets.PurchaseServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>
purchase
</servlet-name>
<url-pattern>
/po/*
</url-pattern>
</servlet-mapping>
</web-app>
At the top of the file, you'll find a
standard XML declaration and a DOCTYPE declaration,
specifying the DTD for this file. The <web-app>
element then follows with a <servlet> element
that defines a servlet named purchase, and a
<servlet-mapping> element that maps the servlet
to the /po/* path prefix pattern.
|