Using the HttpServletResponse interface, write code to set an HTTP response header,

set the content type of the response, acquire a text stream for the response, acquire a
binary stream for the response, redirect an HTTP request to another URL, or add cookies
to the response.

Headers.
A servlet can set headers of an HTTP response via the following methods of the HttpServletResponse interface:

• setHeader

Sets a response header with the given name and value. If the header had already been set, the new value OVERWRITES
the previous one. The containsHeader method can be used to test for the presence of a header before setting
its value.

• addHeader

Adds a response header with the given name and value. This method allows response headers to have multiple values.

public interface HttpServletResponse extends javax.servlet.ServletResponse {

public void setHeader(java.lang.String name, java.lang.String value);

public void addHeader(java.lang.String name, java.lang.String value);

The setHeader method sets a header with a given name and value. A previous header is replaced by the new header. Where
a set of header values exist for the name, the values are cleared and replaced with the new value.
The addHeader method adds a header value to the set with a given name. If there are no headers already associated with
the name, a new set is created.
int or a Date object. The following convenience methods of the
Headers may contain data that represents an
HttpServletResponse interface allow a servlet to set a header using the correct formatting for the appropriate data type:

• setIntHeader

Sets a response header with the given name and integer value. If the header had already been set, the new value
overwrites the previous one. The containsHeader method can be used to test for the presence of a header
before setting its value.

• setDateHeader

Sets a response header with the given name and date-value. The date is specified in terms of milliseconds since the
epoch. If the header had already been set, the new value overwrites the previous one. The containsHeader
method can be used to test for the presence of a header before setting its value.

• addIntHeader

Adds a response header with the given name and integer value. This method allows response headers to have multiple
values.

• addDateHeader

Adds a response header with the given name and date-value. The date is specified in terms of milliseconds since the
epoch. This method allows response headers to have multiple values.

public interface HttpServletResponse extends javax.servlet.ServletResponse {

public void setIntHeader(java.lang.String name, int value);

public void setDateHeader(java.lang.String name, long date);
public void addIntHeader(java.lang.String name, int value);
 public void addDateHeader(java.lang.String name, long date);

To be successfully transmitted back to the client, headers must be set before the response is committed. Headers set after the
response is committed will be IGNORED by the servlet container.
Content type.
The charset for the MIME body response can be specified explicitly using the setContentType(String) method. Explicit
specifications take precedence over implicit specifications. If no charset is specified, ISO-8859-1 will be used. The
setContentType method MUST be called BEFORE getWriter and BEFORE committing the response for the character
encoding to be used.
There are 2 ways to define content type:

• ServletResponse.setContentType(String);
• HttpServletResponse.setHeader("Content-Type", "text/html");

Acquire a text stream.

To send CHARACTER data, use the PrintWriter object returned by ServletResponse.getWriter()
public interface ServletResponse {

public java.io.PrintWriter getWriter() throws IOException;

Returns a PrintWriter object that can send character text to the client. The PrintWriter uses the character encoding
returned by getCharacterEncoding(). Calling flush() on the PrintWriter commits the response.
Either this method or getOutputStream() may be called to write the body, NOT BOTH.
Acquire a binary stream.
ServletResponse.getOutputStream() provides an output stream for sending BINARY data to the client. A
ServletOutputStream object is normally retrieved via this method.
public interface ServletResponse {

public ServletOutputStream getOutputStream() throws IOException;

The servlet container does NOT encode the binary data.

Calling flush() on the ServletOutputStream commits the response. Either this method or getWriter() may be
called to write the body, NOT BOTH.
Redirect an HTTP request to another URL.
The HttpServletResponse.sendRedirect method will set the appropriate headers and content body to redirect the
client to a different URL. It is legal to call this method with a relative URL path, however the underlying container must translate
the relative path to a fully qualified URL for transmission back to the client. If a partial URL is given and, for whatever reason,
cannot be converted into a valid URL, then this method must throw an IllegalArgumentException.
public interface HttpServletResponse extends javax.servlet.ServletResponse {

public void sendRedirect(java.lang.String location) throws IOException;

Sends a temporary redirect response to the client using the specified redirect location URL. This method can accept relative URLs;
the servlet container must convert the relative URL to an absolute URL before sending the response to the client. If the location is
relative without a leading ’/’ the container interprets it as relative to the current request URI. If the location is relative with a
leading ’/’ the container interprets it as relative to the servlet container root.
If the response has already been committed, this method throws an IllegalStateException. After using this method, the
response should be considered to be committed and should not be written to.
This method will have the side effect of committing the response, if it has not already been committed, and terminating it. No
further output to the client should be made by the servlet after these methods are called. If data is written to the response after
this method are called, the data is ignored.
If data has been written to the response buffer, but not returned to the client (i.e. the response is not committed), the data in the
response buffer must be cleared and replaced with the data set by these methods. If the response is committed, this method must
throw an IllegalStateException.
Add cookies to the response.
The servlet sends cookies to the browser by using the HttpServletResponse.addCookie(Cookie) method,
which adds fields to HTTP response headers to send cookies to the browser, one at a time. The browser is expected to support 20
cookies for each Web server, 300 cookies total, and may limit cookie size to 4 KB each.
public interface HttpServletResponse extends javax.servlet.ServletResponse {
 public void addCookie(Cookie cookie);

Adds the specified cookie to the response. This method can be called multiple times to set more than one cookie.

Describe the purpose and event sequence of the servlet life cycle: (1) servlet class
loading, (2) servlet instantiation, (3) call the init method, (4) call the service method,
and (5) call destroy method.

A servlet is managed through a well defined life cycle that defines how it is loaded and instantiated, is initialized, handles requests
init, service, and destroy methods
from clients, and is taken out of service. This life cycle is expressed in the API by the
javax.servlet.Servlet interface that all servlets must implement directly or indirectly through the
of the
GenericServlet or HttpServlet abstract classes.
Servlet class loading and instantiation.
The servlet container is responsible for loading and instantiating servlets. The loading and instantiation can occur when the
container is started, or delayed until the container determines the servlet is needed to service a request.
When the servlet engine is started, needed servlet classes must be located by the servlet container. The servlet container loads the
servlet class using normal Java class loading facilities. The loading may be from a local file system, a remote file system, or other
network services.
After loading the Servlet class, the container instantiates it for use.
Servlet class initialization.
After the servlet object is instantiated, the container must initialize the servlet before it can handle requests from clients.
Initialization is provided so that a servlet can read persistent configuration data, initialize costly resources (such as JDBC
init method of the
connections), and perform other one-time activities. The container initializes the servlet instance by calling the
Servlet interface with a unique (per servlet declaration) object implementing the ServletConfig interface.
public interface Servlet {

public void init(ServletConfig config) throws ServletException;

This configuration object allows the servlet to access name-value initialization parameters from theWeb application's configuration
information. The configuration object also gives the servlet access to an object (implementing the ServletContext interface)
that describes the servlet's runtime environment.
During initialization, the servlet instance can throw an UnavailableException or a ServletException. In this
case, the servlet must not be placed into active service and must be released by the servlet container. The destroy method is
not called as it is considered unsuccessful initialization.
A new instance may be instantiated and initialized by the container after a failed initialization. The exception to this rule is when an
UnavailableException indicates a minimum time of unavailability, and the container must wait for the period to pass
before creating and initializing a new servlet instance.
Request handling.
After a servlet is properly initialized, the servlet container may use it to handle client requests. Requests are represented by
ServletRequest. The servlet fills out response to requests by calling methods of a provided object of
request objects of type
type ServletResponse. These objects are passed as parameters to the service method of the Servlet interface.
public interface Servlet {

public void service(ServletRequest req, ServletResponse res)

throws ServletException, IOException;

In the case of an HTTP request, the objects provided by the container are of types HttpServletRequest and
HttpServletResponse.
public abstract class HttpServlet extends javax.servlet.GenericServlet
implements java.io.Serializable {

protected void service(HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException;

Note that a servlet instance placed into service by a servlet container may handle NO requests during its lifetime.
End of service.
The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept
active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a number of days,
months, or years), or any amount of time in between.
When the servlet container determines that a servlet should be removed from service, it calls thedestroy method of the
Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the
container may do this when it wants to conserve memory resources, or when it is being shut down.
public interface Servlet {

public void destroy();

Before the servlet container calls the destroy method, it must allow any threads that are currently running in the service
method of the servlet to complete execution, or exceed a server-defined time limit.
Once the destroy method is called on a servlet instance, the container may not route other requests to that instance of the
servlet. If the container needs to enable the servlet again, it must do so with a new instance of the servlet's class.
After the destroy method completes, the servlet container must release the servlet instance so that it is eligible for garbage
collection.

Chapter 3. The Web Container Model

For the ServletContext initialization parameters: write servlet code to access

initialization parameters; and create the deployment descriptor elements for declaring
initialization parameters.

The following methods of the ServletContext interface allow the servlet access to context initialization parameters
associated with a Web application as specified by the Application Developer in the deployment descriptor:

• getInitParameter

Returns a String containing the value of the named context-wide initialization parameter, or null if the parameter
does not exist. This method can make available configuration information useful to an entire "web application". For
example, it can provide a webmaster’s email address or the name of a system that holds critical data.

• getInitParameterNames

Enumeration of String objects, or an EMPTY

Returns the names of the context's initialization parameters as an
Enumeration if the context has NO initialization parameters.

Initialization parameters are used by an Application Developer to convey setup information. Typical examples are a Webmaster’s e-
mail address, or the name of a system that holds critical data.
public interface ServletContext {

public java.lang.String getInitParameter(java.lang.String name);

public java.util.Enumeration getInitParameterNames();

Context initialization parameters that define shared String constants used within your application, which can be customized by
the system administrator who is installing your application. The values actually assigned to these parameters can be retrieved in a
servlet or JSP page by calling:
javax.servlet.ServletContext context = getServletContext();
String value = context.getInitParameter("webmaster");

where "webmaster" matches the param-name element of one of these initialization parameters.
You can define any number of context initialization parameters, including zero:

<web-app>
...
<context-param>
<param-name>webmaster</param-name>
<param-value>myaddress@mycompany.com</param-value>
<description>
 The EMAIL address of the administrator to whom questions
and comments about this application should be addressed.
</description>
</context-param>
...
</web-app>

<!--
The context-param element contains the declaration of a web
application’s servlet context initialization parameters.
-->

<!ELEMENT context-param (param-name, param-value, description?)>

For the fundamental servlet attribute scopes (request, session, and context): write
servlet code to add, retrieve, and remove attributes; given a usage scenario, identify the
proper scope for an attribute; and identify multi-threading issues associated with each
scope.

Request Attributes.
Attributes are objects associated with a request. Attributes may be set by the container to express information that otherwise
could not be expressed via the API, or may be set by a servlet to communicate information to another servlet (via the
RequestDispatcher). Attributes are accessed with the following methods of the ServletRequest interface:

• getAttribute

Returns the value of the named attribute as an Object, or null if no attribute of the given name exists. Attributes
can be set two ways. The servlet container may set attributes to make available custom information about a request.
setAttribute(String, Object). This allows information to be
Attributes can also be set programatically using
embedded into a request before aRequestDispatcher call. Attribute names should follow the same
conventions as package names. This specification reserves names matching java.*, javax.*, and sun.*.

• getAttributeNames

Returns anEnumeration containing the names of the attributes available to this request. This method returns an
EMPTY Enumeration if the request has no attributes available to it.

• setAttribute

Stores an attribute in this request. Attributes are reset between requests. This method is most often used in conjunction
withRequestDispatcher. Attribute names should follow the same conventions as package names. Names
beginning with java.*, javax.*, and com.sun.*, are reserved for use by Sun Microsystems. If the object
passed in is null, the effect is the same as calling removeAttribute(String).

• removeAttribute

Removes an attribute from this request. This method is not generally needed as attributes only persist as long as the
request is being handled.

Only ONE attribute value may be associated with an attribute name.

package javax.servlet;

public interface ServletRequest {

 public java.lang.Object getAttribute(java.lang.String name);
public java.util.Enumeration getAttributeNames();
public void setAttribute(java.lang.String name, java.lang.Object o);
public void removeAttribute(java.lang.String name);

Attribute names beginning with the prefixes of "java." and "javax." are RESERVED for definition by this specification. Similarly,
attribute names beginning with the prefixes of "sun.", and "com.sun." are reserved for definition by Sun Microsystems. It is
suggested that all attributes placed in the attribute set be named in accordance with the reverse domain name convention
suggested by the Java Programming Language Specification for package naming.
Session Attributes.
A servlet can bind an object attribute into an HttpSession implementation by name. Any object bound into a session is
available to any other servlet that belongs to the sameServletContext and handles a request identified as being a part of
the same session.

• getAttribute

Returns the object bound with the specified name in this session, or null if no object is bound under the name.

• getAttributeNames

Returns an Enumeration of String objects containing the names of all the objects bound to this session.

• setAttribute

Binds an object to this session, using the name specified. If an object of the same name is already bound to the session,
the object is replaced. After this method executes, and if the new object implements
HttpSessionBindingListener, the container calls
HttpSessionBindingListener.valueBound. The container then notifies any
HttpSessionAttributeListeners in the web application. If an object was already bound to this session of
this name that implements HttpSessionBindingListener, its
HttpSessionBindingListener.valueUnbound method is called. If the value passed in is null, this
has the same effect as calling removeAttribute().

• removeAttribute

Removes the object bound with the specified name from this session. If the session does not have an object bound with
the specified name, this method does nothing. After this method executes, and if the object implements
HttpSessionBindingListener, the container calls
HttpSessionBindingListener.valueUnbound. The container then notifies any
HttpSessionAttributeListeners in the web application.

package javax.servlet.http;

public interface HttpSession {

public java.lang.Object getAttribute(java.lang.String name);

public java.util.Enumeration getAttributeNames();
public void setAttribute(java.lang.String name, java.lang.Object value);
public void removeAttribute(java.lang.String name);

Some objects may require notification when they are placed into, or removed from, a session. This information can be obtained by
having the object implement the HttpSessionBindingListener interface. This interface defines the following methods
that will signal an object being bound into, or being unbound from, a session

• valueBound
• valueUnbound
ThevalueBound method must be called BEFORE the object is made available via the getAttribute method of the
HttpSession interface. The valueUnbound method must be called AFTER the object is no longer available via the
getAttribute method of the HttpSession interface.
Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has
the responsibility for synchronizing access to session resources as appropriate.
Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine
HttpSession class using the
(JVM) at a time. The container must be able to handle all objects placed into instances of the
setAttribute or putValue methods appropriately. The following restrictions are imposed to meet these conditions:

• The container must accept objects that implement the Serializable interface.
• The container may choose to support storage of other designated objects in the HttpSession, such as references
to Enterprise JavaBeans components and transactions.
• Migration of sessions will be handled by container-specific facilities.

The distributed servlet container must throw an IllegalArgumentException for objects where the container cannot
support the mechanism necessary for migration of the session storing them.
Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a
session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a
session.
Application Developers writing distributed applications should be aware that since the container may run in more than one Java
virtual machine, the developer cannot depend on static variables for storing an application state. They should store such states
using an enterprise bean or a database.
Context Attributes.
A servlet can bind an object attribute into the context by name. Any attribute bound into a context is available to any other servlet
that is part of the same Web application. The following methods of ServletContext interface allow access to this
functionality:

• setAttribute

Binds an object to a given attribute name in this servlet context. If the name specified is already used for an attribute,
this method will REPLACE the attribute with the new to the new attribute. If listeners are configured on the
ServletContext the container notifies them accordingly. If a null value is passed, the effect is the same as
calling removeAttribute(). Attribute names should follow the same convention as package names. The Java
Servlet API specification reserves names matching java.*, javax.*, and sun.*.

• getAttribute

Returns the servlet container attribute with the given name, or null if there is no attribute by that name. An attribute
allows a servlet container to give the servlet additional information not already provided by this interface. See your
server documentation for information about its attributes. A list of supported attributes can be retrieved using
getAttributeNames. The attribute is returned as a java.lang.Object or some subclass. Attribute names
should follow the same convention as package names. The Java Servlet API specification reserves names matching
java.*, javax.*, and sun.*.

• getAttributeNames

Enumeration containing the attribute names available within this servlet context. Use the
Returns an
getAttribute(String) method with an attribute name to get the value of an attribute.

• removeAttribute

Removes the attribute with the given name from the servlet context. After removal, subsequent calls to
getAttribute(String) to retrieve the attribute’s value will return null. If listeners are configured on the
ServletContext the container notifies them accordingly.

package javax.servlet;

public interface ServletContext {

 public void setAttribute(java.lang.String name, java.lang.Object object);
public java.lang.Object getAttribute(java.lang.String name);
public java.util.Enumeration getAttributeNames();
public void removeAttribute(java.lang.String name);

Context attributes are LOCAL to the JVM in which they were created. This prevents ServletContext attributes from being a
shared memory store in a distributed container. When information needs to be shared between servlets running in a distributed
environment, the information should be placed into a session, stored in a database, or set in an Enterprise JavaBeans component.

Describe the Web container request processing model; write and configure a filter; create
a request or response wrapper; and given a design problem, describe how to apply a filter
or a wrapper.

Request processing model.

The container, when receiving an incoming request, processes the request as follows:

• Identifies the target Web resource according to the rules of mappings.

• If there are filters matched by servlet name and the Web resource has a <servlet-name>, the container builds
the chain of filters matching in the order declared in the deployment descriptor. The last filter in this chain corresponds
to the last<servlet-name> matching filter and is the filter that invokes the target Web resource.
• <url-pattern> matching and the <url-pattern> matches the request URI
If there are filters using
according to the rules of mappings, the container builds the chain of <url-pattern> matched filters in the same
order as declared in the deployment descriptor. The last filter in this chain is the last <url-pattern> matching
filter in the deployment descriptor for this request URI. The last filter in this chain is the filter that invokes the first filter
in the <servlet-name> matching chain, or invokes the target Web resource if there are none.

The order the container uses in building the chain of filters to be applied for a particular request URI is as follows:

1. First, the <url-pattern> matching filter mappings in the same order that these elements appear in the
deployment descriptor.
2. Next, the <servlet-name> matching filter mappings in the same order that these elements appear in the
deployment descriptor.

Writing and configuring a filter.

Filters are Java components that allow on the fly transformations of payload and header information in both the request into a
resource and the response from a resource. Filters differ from Web components in that they usually do not themselves create a
response. Instead, a filter provides functionality that can be "attached" to any kind of Web resource. As a consequence, a filter
should not have any dependencies on a Web resource for which it is acting as a filter, so that it can be composable with more than
one type of Web resource.
A filter is a reusable piece of code that can transform the content of HTTP requests, responses, and header information. Filters do
not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource,
and modify or adapt responses from a resource. Filters can act on dynamic or static content.
The main tasks that a filter can perform are as follows:

• Query the request and act accordingly.

• Block the request-and-response pair from passing any further.

• Modify the request headers and data. You do this by providing a customized version of the request.

• Modify the response headers and data. You do this by providing a customized version of the response.

• Interact with external resources.

You can configure a Web resource to be filtered by a chain of zero, one, or more filters in a specific order. This chain is specified
when the Web application containing the component is deployed and is instantiated when a Web container loads the component.
The filtering API is defined by the Filter, FilterChain, and FilterConfig interfaces in the javax.servlet package.
The application developer creates a filter by implementing the javax.servlet.Filter interface and providing a public
constructor taking NO arguments. The class is packaged in the Web Archive along with the static content and servlets that make
up the Web application. A filter is declared using the <filter> element in the deployment descriptor. A filter or collection of
filters can be configured for invocation by defining <filter-mapping> elements in the deployment descriptor. This is done
by mapping filters to a particular servlet by the servlet's logical name, or mapping to a group of servlets and static content
resources by mapping a filter to a URL pattern.
package javax.servlet;

public interface Filter {

public void init(FilterConfig filterConfig) throws ServletException;
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws java.io.IOException, ServletException;
public void destroy();

The most important method in this interface is the doFilter method, which is passed request, response, and filter chain objects.
This method can perform the following actions:

• Examine the request headers.

• Customize the request object if it wishes to modify request headers or data.

• Customize the response object if it wishes to modify response headers or data.

• Invoke the next entity in the filter chain. If the current filter is the last filter in the chain that ends with the target Web
component or static resource, the next entity is the resource at the end of the chain; otherwise, it is the next filter that
was configured in the WAR. It invokes the next entity by calling the doFilter method on the chain object (passing in
the request and response it was called with, or the wrapped versions it may have created). Alternatively, it can choose
to block the request by not making the call to invoke the next entity. In the latter case, the filter is responsible for filling
out the response.
• Examine response headers after it has invoked the next filter in the chain.

• Throw an exception to indicate an error in processing.

In addition to doFilter, you must implement the init and destroy methods. The init method is called by the container
when the filter is instantiated. If you wish to pass initialization parameters to the filter, you retrieve them from the
FilterConfig object passed to init.
After deployment of the Web application, and before a request causes the container to access a Web resource, the container must
locate the list of filters that must be applied to the Web resource as described below. The container must ensure that it has
instantiated a filter of the appropriate class for each filter in the list, and called its init(FilterConfig config) method. The
filter may throw an exception to indicate that it cannot function properly. If the exception is of type
UnavailableException, the container may examine the isPermanent attribute of the exception and may choose to
retry the filter at some later time.
Only ONE instance per <filter> declaration in the deployment descriptor is instantiated per Java Virtual Machine (JVM) of the
container. The container provides the filter config as declared in the filter's deployment descriptor, the reference to the
ServletContext for the Web application, and the set of initialization parameters.
doFilter method,
When the container receives an incoming request, it takes the first filter instance in the list and calls its
ServletRequest and ServletResponse, and a reference to the FilterChain object it will use.
passing in the
The doFilter method of a filter will typically be implemented following this or some subset of the following pattern:

1. The method examines the request's headers.

2. ServletRequest or
The method may wrap the request object with a customized implementation of
HttpServletRequest in order to modify request headers or data.
3. The method may wrap the response object passed in to its doFilter method with a customized implementation of
ServletResponse or HttpServletResponse to modify response headers or data.
4. The filter may invoke the next entity in the filter chain. The next entity may be another filter, or if the filter making the
invocation is the last filter configured in the deployment descriptor for this chain, the next entity is the target Web
resource. The invocation of the next entity is effected by calling the doFilter method on the FilterChain object,
and passing in the request and response with which it was called or passing in wrapped versions it may have created.

The filter chain's implementation of the doFilter method, provided by the container, must locate the next entity in
the filter chain and invoke its doFilter method, passing in the appropriate request and response objects.

Alternatively, the filter chain can block the request by not making the call to invoke the next entity, leaving the filter
responsible for filling out the response object.

5. After invocation of the next filter in the chain, the filter may examine response headers.
 6. Alternatively, the filter may have thrown an exception to indicate an error in processing. If the filter throws an
UnavailableException during its doFilter processing, the container must not attempt continued
processing down the filter chain. It may choose to retry the whole chain at a later time if the exception is not marked
permanent.
7. When the last filter in the chain has been invoked, the next entity accessed is the target servlet or resource at the end
of the chain.
8. Before a filter instance can be removed from service by the container, the container must first call the destroy
method on the filter to enable the filter to release any resources and perform other cleanup operations.

public final class ExampleFilter implements Filter {

private String attribute = null;
private FilterConfig filterConfig = null;

public void init(FilterConfig filterConfig) throws ServletException {

this.filterConfig = filterConfig;
this.attribute = filterConfig.getInitParameter("attribute");
}

public void doFilter(ServletRequest request, ServletResponse response,

FilterChain chain) throws IOException, ServletException {

// Store ourselves as a request attribute (if requested)

if (attribute != null) {
request.setAttribute(attribute, this);
}

// Time and log the subsequent processing

long startTime = System.currentTimeMillis();
chain.doFilter(request, response);
long stopTime = System.currentTimeMillis();
filterConfig.getServletContext().log
(this.toString() + ": " + (stopTime - startTime) +
" milliseconds");
}

public void destroy() {

this.attribute = null;
this.filterConfig = null;
}

<web-app>
...
<!-- Define servlet-mapped and path-mapped example filters -->
<filter>
<filter-name>Servlet Mapped Filter</filter-name>
<filter-class>filters.ExampleFilter</filter-class>
<init-param>
<param-name>attribute</param-name>
<param-value>filters.ExampleFilter.SERVLET_MAPPED</param-value>
</init-param>
</filter>

<filter>
<filter-name>Path Mapped Filter</filter-name>
<filter-class>filters.ExampleFilter</filter-class>
<init-param>
<param-name>attribute</param-name>
<param-value>filters.ExampleFilter.PATH_MAPPED</param-value>
</init-param>
</filter>

<!-- Define filter mappings for the defined filters -->

<filter-mapping>
<filter-name>Servlet Mapped Filter</filter-name>
<servlet-name>invoker</servlet-name>
</filter-mapping>

<filter-mapping>
<filter-name>Path Mapped Filter</filter-name>
<url-pattern>/servlet/*</url-pattern>
</filter-mapping>
...
 </web-app>

Here is another example of a filter declaration:

<filter>
<filter-name>Image Filter</filter-name>
<filter-class>com.acme.ImageServlet</filter-class>
</filter>

Once a filter has been declared in the deployment descriptor, the assembler uses the filter-mapping element to define
servlets and static resources in the Web application to which the filter is to be applied. Filters can be associated with a servlet using
servlet-name element. For example, the following code example maps the Image Filter filter to the
the
ImageServlet servlet:

<filter-mapping>
<filter-name>Image Filter</filter-name>
<servlet-name>ImageServlet</servlet-name>
</filter-mapping>

Filters can be associated with groups of servlets and static content using the url-pattern style of filter mapping:

<filter-mapping>
<filter-name>Logging Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Here theLogging Filter is applied to all the servlets and static content pages in the Web application, because every request
'/*' URL pattern.
URI matches the
The url-pattern matching takes precedence (is applied first) over the servlet-name matching (is applied next).

<!--
Declares a filter in the web application. The filter is mapped to
either a servlet or a URL pattern in the filter-mapping element,
using the filter-name value to reference. Filters can access the
initialization parameters declared in the deployment descriptor at
runtime via the FilterConfig interface.

Used in: web-app

-->

<!ELEMENT filter (icon?, filter-name, display-name?, description?,

filter-class, init-param*)>

<!--
Declaration of the filter mappings in this web application. The
container uses the filter-mapping declarations to decide which
filters to apply to a request, and in what order. The container
matches the request URI to a Servlet in the normal way. To determine
which filters to apply it matches filter-mapping declarations either
on servlet-name, or on url-pattern for each filter-mapping element,
depending on which style is used. The order in which filters are
invoked is the order in which filter-mapping declarations that match
a request URI for a servlet appear in the list of filter-mapping
elements.The filter-name value must be the value of the <filter-name>
sub-elements of one of the <filter> declarations in the deployment
descriptor.

Used in: web-app

-->

<!ELEMENT filter-mapping (filter-name, (url-pattern | servlet-name), dispatcher*)>

The dispatcher has four legal values: FORWARD, REQUEST, INCLUDE, and ERROR. A value of
FORWARD means the Filter will be applied under RequestDispatcher.forward() calls. A value of
REQUEST means the Filter will be applied under ordinary client calls to the PATH or SERVLET. A value of INCLUDE
means the Filter will be applied under RequestDispatcher.include() calls. A value of ERROR means the Filter
will be applied under the error page mechanism. The absence of any dispatcher elements in a filter-mapping indicates a
default of applying filters only under ordinary client calls to the PATH or SERVLET (REQUEST).

<filter-mapping>
<filter-name>Logging Filter</filter-name>
<url-pattern>/products/*</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

This example would result in the Logging Filter being invoked by client requests starting /products/... and underneath
a request dispatcher forward() call where the request dispatcher has path commencing /products/....
Wrapping request and response objects.
As well as performing basic pre and post processing operations a filter can also wrap up the request or response objects in a
custom wrapper. Such custom wrappers can then modify the information provided to the servlet via a request object or process
information generated by the servlet via the response object. There are four classes that make up the Wrapping API. These are the
javax.servlet.ServletRequestWrapper, javax.servlet.ServletResponseWrapper,
javax.servlet.http.HttpServletRequestWrapper and
javax.servlet.http.HttpServletResponseWrapper. These classes implement the respective interfaces (e.g.
ServletRequest, ServletResponse, HttpServletRequest and HttpServletResponse) and can
thus be used anywhere that these interfaces are specified. Most notably they can therefore be used inside a Filter to wrap the
actual request or response object up so that the filter can control either the data accessed by the Servlet (or JSP) or generated
by the Servlet or JSP. A particular use of these wrappers is to perform some pre or post processing of the data being used or
generated by the Servlet so that the Servlet does not need to know about this processing.
A filter that modifies a response must usually capture the response before it is returned to the client. The way to do this is to pass
a stand-in stream to the servlet that generates the response. The stand-in stream prevents the servlet from closing the original
response stream when it completes and allows the filter to modify the servlet's response.
getWriter or
To pass this stand-in stream to the servlet, the filter creates a response wrapper that overrides the
getOutputStream method to return this stand-in stream. The wrapper is passed to the doFilter method of the filter
chain. Wrapper methods default to calling through to the wrapped request or response object. This approach follows the well-
known Wrapper or Decorator pattern described in 'Design Patterns: Elements of Reusable Object-Oriented Software (Addison-
Wesley, 1995)'.
ServletRequestWrapper or
To override request methods, you wrap the request in an object that extends
HttpServletRequestWrapper. To override response methods, you wrap the response in an object that extends
ServletResponseWrapper or HttpServletResponseWrapper.
Example of filter with wrapper (post processing of servlet's output):

public final class HitCounterFilter implements Filter {

private FilterConfig filterConfig = null;

public void init(FilterConfig filterConfig)

throws ServletException {
this.filterConfig = filterConfig;
}

public void doFilter(ServletRequest request, ServletResponse response,

FilterChain chain) throws IOException, ServletException {
StringWriter sw = new StringWriter();
PrintWriter writer = new PrintWriter(sw);
Counter counter = (Counter)filterConfig.getServletContext().
getAttribute("hitCounter");
writer.println();
writer.println("===============");
writer.println("The number of hits is: " + counter.incCounter());
writer.println("===============");
// Log the resulting string
writer.flush();
filterConfig.getServletContext().log(sw.getBuffer().toString());

PrintWriter out = response.getWriter();

CharResponseWrapper wrapper =
new CharResponseWrapper((HttpServletResponse)response);
chain.doFilter(request, wrapper);
CharArrayWriter caw = new CharArrayWriter();
 caw.write(wrapper.toString().
substring(0, wrapper.toString().indexOf("</body>")-1));
caw.write("<p>\n<center><center>" +
messages.getString("Visitor") +
"<font color='red'>" + counter.getCounter() +
"</font><center>");
caw.write("\n</body></html>");
response.setContentLength(caw.toString().length());
out.write(caw.toString());
out.close();
}

public void destroy() {

this.filterConfig = null;
}
}

public class CharResponseWrapper extends HttpServletResponseWrapper {

private CharArrayWriter output;

public String toString() {

return output.toString();
}

public CharResponseWrapper(HttpServletResponse response) {

super(response);
output = new CharArrayWriter();
}

public PrintWriter getWriter() {

return new PrintWriter(output);
}
}

HitCounterFilter wraps the response in a CharResponseWrapper. The wrapped response is passed to the next
object in the filter chain. Next servlet writes (buffers) its response into the stream created by CharResponseWrapper.
When chain.doFilter returns, HitCounterFilter retrieves the servlet's response from PrintWriter and writes it to
a buffer (CharArrayWriter). The filter inserts the value of the counter into the buffer, resets the content length header of
the response, and finally writes the contents of the buffer to the response stream.

Describe the Web container life cycle event model for requests, sessions, and web
applications; create and configure listener classes for each scope life cycle; create and
configure scope attribute listener classes; and given a scenario, identify the proper
attribute listener to use.

The application events facility gives the Web Application Developer greater control over the lifecycle of the ServletContext
and HttpSession and ServletRequest, allows for better code factorization, and increases efficiency in managing the
resources that the Web application uses.
Application event listeners are classes that implement one or more of the servlet event listener interfaces. They are instantiated
and registered in the Web container at the time of the deployment of the Web application. They are provided by the Developer in
the WAR.
ServletContext, HttpSession and
Servlet event listeners support event notifications for state changes in the
ServletRequest objects. Servlet context listeners are used to manage resources or state held at a JVM level for the
application. HTTP session listeners are used to manage state or resources associated with a series of requests made into a Web
application from the same client or user. Servlet request listeners are used to manage state across the lifecycle of servlet requests.
There may be multiple listener classes listening to each event type, and the Developer may specify the order in which the container
invokes the listener beans for each event type.
Servlet Context Events and Listeners.
Implementations of the following interface receive notifications about changes to the servlet context of the web application they
are part of. To receive notification events, the implementation class must be configured in the deployment descriptor for the web
application. All ServletContextListeners are notified of context initialization before any filter or servlet in the web
ServletContextListeners are notified of
application is initialized. All servlets and filters have been destroyed before any
context destruction.
package javax.servlet;

public interface ServletContextListener extends java.util.EventListener {

public void contextDestroyed(ServletContextEvent sce);

public void contextInitialized(ServletContextEvent sce);
 }

This is the event class for notifications about changes to the servlet context of a web application:
package javax.servlet;

public class ServletContextEvent extends java.util.EventObject {

public ServletContext getServletContext();

Implementations of the following interface receive notifications of changes to the attribute list on the servlet context of a web
application. To receive notification events, the implementation class must be configured in the deployment descriptor for the web
application.

• attributeAdded notifies that a new attribute was added to the servlet context. Called after the attribute is
added.
• attributeRemoved notifies that an existing attribute has been removed from the servlet context. Called after
the attribute is removed.
• attributeReplaced( notifies that an attribute on the servlet context has been replaced. Called after the
attribute is replaced.

package javax.servlet;

public interface ServletContextAttributeListener extends java.util.EventListener {

public void attributeAdded(ServletContextAttributeEvent scae);

public void attributeRemoved(ServletContextAttributeEvent scae);
public void attributeReplaced(ServletContextAttributeEvent scae);

This is the event class for notifications about changes to the attributes of the servlet context of a web application:
package javax.servlet;

public class ServletContextAttributeEvent extends javax.servlet.ServletContextEvent {

public java.lang.String getName();

public java.lang.Object getValue();

HTTP Session Events and Listeners.

Implementations of the following interface are notified of changes to the list of active sessions in a web application. To receive
notification events, the implementation class must be configured in the deployment descriptor for the web application.
package javax.servlet.http;

public interface HttpSessionListener extends java.util.EventListener {

public void sessionCreated(HttpSessionEvent hse);

public void sessionDestroyed(HttpSessionEvent hse);

This is the class representing event notifications for changes to sessions within a web application:
package javax.servlet.http;

public class HttpSessionEvent extends java.util.EventObject {

public HttpSession getSession();

Following listener interface can be implemented in order to get notifications of changes to the attribute lists of sessions within this
web application:

• attributeAdded notifies that a new attribute was added to the session. Called after the attribute is added.
• attributeRemoved notifies that an existing attribute has been removed from the session. Called after the
attribute is removed.
 • attributeReplaced notifies that an attribute has been replaced in the session. Called after the attribute is
replaced.

package javax.servlet.http;

public interface HttpSessionAttributeListener extends java.util.EventListener {

public void attributeAdded(HttpSessionBindingEvent hsbe);

public void attributeRemoved(HttpSessionBindingEvent hsbe);
public void attributeReplaced(HttpSessionBindingEvent hsbe);

Events of the following type are either sent to an object that implements HttpSessionBindingListener when it is
bound or unbound from a session, or to a HttpSessionAttributeListener that has been configured in the deployment
descriptor when any attribute is bound, unbound or replaced in a session. The session binds the object by a call to
HttpSession.setAttribute and unbinds the object by a call to HttpSession.removeAttribute. The
getValue function returns the value of the attribute that has been added, removed or replaced. If the attribute was added (or
bound), this is the value of the attribute. If the attribute was removed (or unbound), this is the value of the removed attribute. If
the attribute was replaced, this is the OLD value of the attribute.
package javax.servlet.http;

public class HttpSessionBindingEvent extends javax.servlet.http.HttpSessionEvent {

public java.lang.String getName();

public HttpSession getSession();
public java.lang.Object getValue(); // returns :
// new value for added (bounded) attributes,
// old value for replaced and removed (unbounded) attributes

When container migrates a session between VMs in a distributed container setting, all session attributes implementing the
HttpSessionActivationListener interface are notified.
Objects that are bound to a session may listen to container events notifying them that sessions will be passivated and that session
will be activated. A container that migrates session between VMs or persists sessions is required to notify all attributes bound to
sessions implementing HttpSessionActivationListener.
package javax.servlet.http;

public interface HttpSessionActivationListener extends java.util.EventListener {

public void sessionDidActivate(HttpSessionEvent hse);

public void sessionWillPassivate(HttpSessionEvent hse);

The following interface causes an OBJECT to be notified when it is bound to or unbound from a session. The object is notified by an
HttpSessionBindingEvent object. This may be as a result of a servlet programmer explicitly unbinding an attribute
from a session, due to a session being invalidated, or due to a session timing out.
package javax.servlet.http;

public interface HttpSessionBindingListener extends java.util.EventListener {

public void valueBound(HttpSessionBindingEvent hsbe);

public void valueUnbound(HttpSessionBindingEvent hsbe);

Servlet Request Events and Listeners.

A ServletRequestListener can be implemented by the developer interested in being notified of requests coming in and
out of scope in a web component. A request is defined as coming into scope when it is about to enter the first servlet or filter in
each web application, as going out of scope when it exits the last servlet or the first filter in the chain.
package javax.servlet;

public interface ServletRequestListener {

requestInitialized(ServletRequestEvent sre);
requestDestroyed(ServletRequestEvent sre);

}
Events of this kind indicate lifecycle events for a ServletRequest. The source of the event is the ServletContext of
this web application.
package javax.servlet;

public class ServletRequestEvent extends java.util.EventObject {

public ServletRequest getServletRequest();

public ServletContext getServletContext();

A ServletRequestAttributeListener can be implemented by the developer interested in being notified of request

attribute changes. Notifications will be generated while the request is within the scope of the web application in which the listener
is registered. A request is defined as coming into scope when it is about to enter the first servlet or filter in each web application,
as going out of scope when it exits the last servlet or the first filter in the chain.
package javax.servlet;

public interface ServletRequestAttributeListener {

public void attributeAdded(ServletRequestAttributeEvent srae);
public void attributeRemoved(ServletRequestAttributeEvent srae);
public void attributeReplaced(ServletRequestAttributeEvent srae);

ServletRequest in an application. The

The following is the event class for notifications of changes to the attributes of
getValue() function returns the value of the attribute that has been added, removed or replaced. If the attribute was added,
this is the value of the attribute. If the attribute was removed, this is the value of the REMOVED attribute. If the attribute was
replaced, this is the OLD value of the attribute.
package javax.servlet;

public class ServletRequestAttributeEvent extends ServletRequestEvent {

public java.lang.String getName();

public java.lang.Object getValue();

Table 3.1. Events and Listener Interfaces

Scope Event Listener Interface and Event Class

Initialization and
destruction ServletContextListener, ServletContextEvent
Servlet
Context
Attribute added, ServletContextAttributeListener,
removed, or replaced ServletContextAttributeEvent

Created and destroyed HttpSessionListener, HttpSessionEvent

Activated and
passivated (migrated) HttpSessionActivationListener, HttpSessionEvent
HTTP
Session Attribute added, HttpSessionAttributeListener,
removed, or replaced HttpSessionBindingEvent (note the class name !)

Object bound or HttpSessionBindingListener (note, interface must be

unbound implemented by attribute class !), HttpSessionBindingEvent

Initialized and
destroyed ServletRequestListener, ServletRequestEvent
Servlet
Request
Attribute added, ServletRequestAttributeListener,
removed, or replaced ServletRequestAttributeEvent
The Developer of the Web application provides listener classes implementing one or more of the listener classes in the servlet API.
Each listener class must have a public constructor taking NO arguments. The listener classes are packaged into the WAR, either
under the WEB-INF/classes archive entry, or inside a JAR in the WEB-INF/lib directory.
Listener classes are declared in the Web application deployment descriptor using the listener element. They are listed by class
name in the order in which they are to be invoked. During Web application execution, listeners are invoked in the order of their
registration.
On application shutdown, listeners are notified in REVERSE order to their declarations with notifications to session listeners
preceeding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners
being notified of application shutdown.

<web-app>
...
<listener>
<listener-class>listeners.ContextListener</listener-class>
</listener>
...
</web-app>

HttpSession instances are scoped to the particular JVM servicing session requests, and the
In distributed Web containers,
ServletContext object is scoped to the Web container's JVM. Distributed containers are not required to propagate either
servlet context events or HttpSession events to other JVMs. Listener class instances are scoped to one per deployment
descriptor declaration per Java Virtual Machine.

Describe the RequestDispatcher mechanism; write servlet code to create a request

dispatcher; write servlet code to forward or include the target resource; and identify and
describe the additional request-scoped attributes provided by the container to the target
resource.

RequestDispatcher description.
RequestDispatcher defines an object that receives requests from the client and sends them to any resource (such as a
servlet, HTML file, or JSP file) on the server. The servlet container creates the RequestDispatcher object, which is used as
a wrapper around a server resource located at a particular path or given by a particular name.
An object implementing the RequestDispatcher interface may be obtained via the following methods:

• ServletContext.getRequestDispatcher(String path)
• ServletContext.getNamedDispatcher(String name)
• ServletRequest.getRequestDispatcher(String path)

The ServletContext.getRequestDispatcher method takes a String argument describing a path within the
scope of the ServletContext. This path must be relative to the root of the ServletContext and begin with a '/'. The
method uses the path to look up a servlet, using the servlet path matching rules, wraps it with a RequestDispatcher
object, and returns the resulting object. If no servlet can be resolved based on the given path, a RequestDispatcher is
provided that returns the content for that path.
The ServletContext.getNamedDispatcher method takes a String argument indicating the NAME of a servlet
known to the ServletContext. If a servlet is found, it is wrapped with a RequestDispatcher object and the object
is returned. If no servlet is associated with the given name, the method must return null.
To allow RequestDispatcher objects to be obtained using relative paths that are relative to the path of the current
request (not relative to the root of the ServletContext), the ServletRequest.getRequestDispatcher
method is provided in the ServletRequest interface. The behavior of this method is similar to the method of the same name
in the ServletContext. The servlet container uses information in the request object to transform the given relative path
against the current servlet to a complete path. For example, in a context rooted at '/' and a request to
/garden/tools.html, a request dispatcher obtained via
ServletRequest.getRequestDispatcher("header.html") will behave exactly like a call to
ServletContext.getRequestDispatcher("/garden/header.html").
RequestDispatcher creation and using.
public class Dispatcher extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res) {
RequestDispatcher dispatcher =
request.getRequestDispatcher("/template.jsp");
if (dispatcher != null) dispatcher.forward(request, response);
}
}
forward should be called before the response has been committed to the client (before response body output has been
flushed). If the response already has been committed, this method throws an IllegalStateException. Uncommitted
output in the response buffer is automatically cleared before the forward.
public class Dispatcher extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res) {
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher("/banner");
if (dispatcher != null) dispatcher.include(request, response);
}
}

Includes the content of a resource (servlet, JSP page, HTML file) in the response. In essence, this method enables programmatic
server-side includes. The ServletResponse object has its path elements and parameters remain unchanged from the
caller's. The included servlet cannot change the response status code or set headers; any attempt to make a change is ignored.
package javax.servlet;

public interface RequestDispatcher {

public void forward(ServletRequest request, ServletResponse response)

throws ServletException, java.io.IOException;
public void include(ServletRequest request, ServletResponse response)
throws ServletException, java.io.IOException;

The include method of the RequestDispatcher interface may be called at ANY time. The target servlet of the include
method has access to all aspects of the request object, but its use of the response object is more limited. It can only write
information to the ServletOutputStream or Writer of the response object and commit a response by writing content
past the end of the response buffer, or by explicitly calling the flushBuffer method of the ServletResponse interface.
It CANNOT set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored.
The forward method of the RequestDispatcher interface may be called by the calling servlet ONLY when NO output
has been committed to the client. If output data exists in the response buffer that has not been committed, the content must be
cleared before the target servlet's service method is called. If the response has been committed, an
IllegalStateException must be thrown.
The path elements of the request object exposed to the target servlet must reflect the path used to obtain the
RequestDispatcher. The only exception to this is if the RequestDispatcher was obtained via the
getNamedDispatcher method. In this case, the path elements of the request object must reflect those of the original
request. Before the forward method of the RequestDispatcher interface returns, the response content MUST be sent
and committed, and closed by the servlet container.
The ServletContext and ServletRequest methods that create RequestDispatcher objects using path
information allow the optional attachment of query string information to the path. For example, a Developer may obtain a
RequestDispatcher by using the following code:

String path = "/raisins.jsp?orderno=5";

RequestDispatcher rd = context.getRequestDispatcher(path);
rd.include(request, response);

Parameters specified in the query string used to create the RequestDispatcher take precedence over other parameters of
RequestDispatcher are scoped to apply
the same name passed to the included servlet. The parameters associated with a
only for the duration of the include or forward call.
Additional request-scoped attributes.
Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another
servlet using the include method of RequestDispatcher has access to the path by which it was invoked.
The following request attributes must be set:

• javax.servlet.include.request_uri
• javax.servlet.include.context_path
• javax.servlet.include.servlet_path
• javax.servlet.include.path_info
• javax.servlet.include.query_string
These attributes are accessible from the included servlet via the getAttribute method on the request object and their values
must be equal to the request URI, context path, servlet path, path info, and query string of the INCLUDED servlet, respectively. If
the request is subsequently included, these attributes are replaced for that include.
getNamedDispatcher method, these attributes MUST NOT be set.
If the included servlet was obtained by using the
getNamedDispatcher method, a servlet that has been invoked by another
Except for servlets obtained by using the
servlet using the forward method of RequestDispatcher has access to the path of the ORIGINAL request.
The following request attributes must be set:

• javax.servlet.forward.request_uri
• javax.servlet.forward.context_path
• javax.servlet.forward.servlet_path
• javax.servlet.forward.path_info
• javax.servlet.forward.query_string

HttpServletRequest methods
The values of these attributes must be equal to the return values of the
getRequestURI, getContextPath, getServletPath, getPathInfo, getQueryString respectively,
invoked on the request object passed to the first servlet object in the call chain that received the request from the client.
These attributes are accessible from the forwarded servlet via the getAttribute method on the request object. Note that
these attributes must always reflect the information in the original request even under the situation that multiple forwards and
subsequent includes are called.
If the forwarded servlet was obtained by using the getNamedDispatcher method, these attributes must not be set.