Servlets Parte III

Instituto Politcnico Nacional
Escuela Superior de Cmputo
THEMATIC UNIT I:
Introduction to Web Applications
M. en C. Hermes Francisco Montes Casiano

hermes.escom@gmail.com
Filtering Sessions Annotations and pluggability
ndice
1 Filtering
Introduction
2 Sessions
3 Annotations and pluggability
2/28
THEMATIC UNIT I: Introduction to Web Applications Hermes Francisco Montes Casiano
Introduction
Definition
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
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.
Filters can act on dynamic or static content.
3/28
Filtering
What is a filter?
Among the types of functionality available to the developer needing

to use filters are the following:
The accessing of a resource before a request to it is invoked.
The processing of the request for a resource before it is
invoked.
The modification of request headers and data by wrapping the
request in customized versions of the request object.
The modification of response headers and response data by
providing customized versions of the response object.
The interception of an invocation of a resource after its call.
Actions on a servlet, on groups of servlets, or static content by
zero, one, or more filters in a specifiable order.
4/28
Examples of Filtering Componets
Authentication filters.
Logging and auditing filters.
Image conversion filters.
Data compression filters.
Encryption filters.
Tokenizing filters.
Filters that trigger resource access events.
XSL/T filters that transform XML content.
MIME-type chain filters.
Caching filters.
5/28
Filter Lifecycle
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 .
The container must ensure that it has instantiated a filter of
the appropriate class for each filter in the list, and called its
init method.
The filter may throw an exception to indicate that it cannot
function properly.
Only one instance per <filter> declaration in the deployment
descriptor is instantiated per JVM of the container.
When the container receives an incoming request, it takes the
first filter instance in the list and calls its doFilter method.
6/28
Filter Lifecycle
doFilter method
1 The method examines the requests headers.
2 The method may wrap the request object.
3 The method may wrap the response object.
4 The filter may invoke the next entity in the filter chain.
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.
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.
7/28
Configuration of Filters
A filter is defined either via the @WebFilter annotation or in

the deployment descriptor using the <filter> element:
filter-name: used to map the filter to a servlet or URL.
filter-class: used by the container to identify the filter type.
init-params: initialization parameters for a filter.
The container must instantiate exactly one instance of the
Java class defining the filter per filter declaration in the
deployment descriptor.
8/28
Examples
9/28
Examples
10/28
Filters and the RequestDispatcher
By using the new <dispatcher> element in the deployment

descriptor, the developer can indicate for a filter-mapping whether
he would like the filter to be applied to requests when:
Description Type
The request comes directly from the client. REQUEST
The request is being processed under a request dispatcher represen- FORWARD
ting the Web component matching the <url-pattern> or <servlet-
name> using a forward() call.
The request is being processed under a request dispatcher represen- INCLUDE
ting the Web component matching the <url-pattern> or <servlet-
name> using an include() call
The request is being processed with the error page mechanism spe- ERROR
cified in Error Handling to an error resource matching the <url-
pattern>.
The request is being processed with the async context dispatch me- ASYNC
chanism specified in Asynchronous processing to a web component
using a dispatch call.
11/28
Filters and the RequestDispatcher

Examples
12/28
ndice
1 Filtering
2 Sessions
Introduction
13/28
Introduction
The Hypertext Transfer Protocol (HTTP) is by design a

stateless protocol.
To build effective Web applications, it is imperative that
requests from a particular client be associated with each other.
Many strategies for session tracking have evolved over time,
but all are difficult or troublesome for the programmer to use
directly.
14/28
Cookies
Session tracking through HTTP cookies is the most used

session tracking mechanism and is required to be supported by
all servlet containers.
The container sends a cookie to the client.
The client will then return the cookie on each subsequent
request to the server, unambiguously associating the request
with a session.
The standard name of the session tracking cookie must be
JSESSIONID.
All servlet containers MUST provide an ability to configure
whether or not the container marks the session tracking cookie
as HttpOnly.
15/28
Creating a Session
A session is considered new when it is only a prospective

session and has not been established.
The client does not yet know about the session.
The client chooses not to join a session.
These conditions define the situation where the servlet
container has no mechanism by which to associate a request
with a previous request.
16/28
Session Scope
HttpSession objects must be scoped at the application (or

servlet context) level.
The underlying mechanism, such as the cookie used to
establish the session.
17/28
Binding Attributes into a Session
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 same ServletContext and handles a
request identified as being a part of the same session.
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.
18/28
Session Timeouts
In the HTTP protocol, there is no explicit termination signal

when a client is no longer active.
This means that the only mechanism that can be used to
indicate when a client is no longer active is a time out period.
The default time out period for sessions is defined by the
servlet container and can be obtained via the
getMaxInactiveInterval method of the HttpSession interface.
This time out can be changed by the Developer using the
setMaxInactiveInterval method of the HttpSession interface.
19/28
ndice
1 Filtering
2 Sessions

Annotations
Pluggability
20/28
Annotations
Introduction
In a web application, classes using annotations will have their

annotations processed only if they are located in the
WEB-INF/classes directory.
If they are packaged in a jar file located in WEB-INF/lib
within the application.
The web application deployment descriptor contains a new
metadata-complete attribute on the web-app element.
The metadata-complete attribute
Defines whether the web descriptor is complete, or whether the
class files of the jar file should be examined for annotations and
web fragments at deployment time.
21/28
Annotations
Introduction
If metadata-complete is set to "true", the deployment tool

MUST ignore any servlet annotations present in the class files
of the application and web fragments.
If the metadata-complete attribute is not specified or is set to
"false", the deployment tool must examine the class files of
the application for annotations, and scan for web fragments.
21/28
Annotations
Following are the annotations that MUST be supported by a

Servlet 3.0 compliant web container.
1 @WebServlet
2 @WebFilter
3 @WebInitParam
4 @WebListener
5 @MultipartConfig
22/28
Modularity of web.xml
Using the annotations defined above makes the use of web.xml

optional.
However for overriding either the default values or the values
set via annotations, the deployment descriptor is used.
For better pluggability and less configuration for developers, in
Servlet 3.0 we are introducing the notion of web module
deployment descriptor fragments (web fragment).
Web fragment
A web fragment is a part or all of the web.xml that can be specified
and included in a library or framework jars META-INF directory.
A web fragment is a logical partitioning of the web application in
such a way that the frameworks being used within the web
application can define all the artifacts without asking developers to
edit or add information in the web.xml.
23/28
It can include almost all the same elements that the web.xml
descriptor uses.
However the top level element for the descriptor MUST be
web-fragment and the corresponding descriptor file MUST be
called web-fragment.xml.
If a framework is packaged as a jar file and has metadata
information in the form of deployment descriptor then the
web-fragment.xml descriptor must be in the META-INF/
directory of the jar file.
If a framework wants its META-INF/web-fragment.xml
honored in such a way that it augments a web applications
web.xml, the framework must be bundled within the web
applications WEB-INF/lib directory.
24/28
During deployment the container is responsible for scanning

the location specified above and discovering the
web-fragment.xml and processing them.
The requirements about name uniqueness that exist currently
for a single web.xml also apply to the union of a web.xml and
all applicable web-fragment.xml files.
25/28
Example
26/28
27/28
28/28

Servlets Parte III

Uploaded by

Copyright:

Available Formats

Servlets Parte III

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servlets Parte III

Uploaded by

Copyright:

Available Formats

Instituto Politcnico Nacional

Escuela Superior de Cmputo

M. en C. Hermes Francisco Montes Casiano

3 Annotations and pluggability

A filter is a reusable piece of code that can transform the

Among the types of functionality available to the developer needing

Examples of Filtering Componets

After deployment of the Web application, and before a request

A filter is defined either via the @WebFilter annotation or in

Filters and the RequestDispatcher

By using the new <dispatcher> element in the deployment

Filters and the RequestDispatcher

3 Annotations and pluggability

The Hypertext Transfer Protocol (HTTP) is by design a

Session tracking through HTTP cookies is the most used

A session is considered new when it is only a prospective

HttpSession objects must be scoped at the application (or

Binding Attributes into a Session

A servlet can bind an object attribute into an HttpSession

In the HTTP protocol, there is no explicit termination signal

3 Annotations and pluggability

In a web application, classes using annotations will have their

If metadata-complete is set to "true", the deployment tool

Following are the annotations that MUST be supported by a

Using the annotations defined above makes the use of web.xml

During deployment the container is responsible for scanning

You might also like