Download servlet-name

Aspiration- Beyond Expectation- 9374928879
MVC
The main aim of the MVC architecture is to separate the business logic and application data from the
presentation data to the user.
Here are the reasons why we should use the MVC design pattern.
1.
2.
They are resuable : When the problems recurs, there is no need to invent a new solution, we
just have to follow the pattern and adapt it as necessary.
They are expressive: By using the MVC design pattern our application becomes more
expressive.
Model
The model object knows about all the data that need to be displayed.
It is model who is aware about all the operations that can be applied to transform that object.
It only represents the data of an application. The model represents enterprise data and the business rules
that govern access to and updates of this data.
Model is not aware about the presentation data and how that data will be displayed to the browser.
View
The view represents the presentation of the application.
The view object refers to the model. It uses the query methods of the model to obtain the contents and
renders it. The view is not dependent on the application logic.
It remains same if there is any modification in the business logic. In other words, we can say that it is the
responsibility of the of the view's to maintain the consistency in its presentation when the model changes.
Controller
Whenever the user sends a request for something then it always go through the controller.
The controller is responsible for intercepting the requests from view and passes it to the model for the
appropriate action. After the action has been taken on the data, the controller is responsible for directing
the appropriate view to the user.
Difference between Model 1 and Model 2 architecture:
Features of MVC1:
1. Html or jsp files are used to code the presentation. To retrieve the data JavaBean can be used.
2. In mvc1 architecture all the view, control elements are implemented using Servlets or Jsp.
3. In MVC1 there is tight coupling between page and model as data access is usually done using
Custom tag or through java bean call.
Features of MVC2:
1. The MVC2 architecture removes the page centric property of MVC1 architecture by separating
Presentation, control logic and the application state.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
2. In MVC2 architecture there is only one controller which receives all the request for the application
and is responsible for taking appropriate action in response to each request.
Both servlets and JavaServer Pages.
In this approach, known as the Model View Controller (MVC) or Model 2 architecture, you let each
technology concentrate on what it excels at. The original request is handled by a servlet.
The servlet invokes the business-logic and data-access code and creates beans to represent the results
(that's the model).
Then, the servlet decides which JSP page is appropriate to present those particular results and forwards
the request there (the JSP page is the view). The servlet decides what business logic code applies and
which JSP page should present the results (the servlet is the controller).
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Implementing MVC with RequestDispatcher
1. Define beans to represent the data.
2. Use a servlet to handle requests.
3. Populate the beans. The servlet invokes business logic (application-specific code) or data-access
code to obtain the results.
4. Store the bean in the request, session, or servlet context. The servlet calls setAttribute on the
request, session, or servlet context objects to store a reference to the beans that represent the
results of the request.
5. Forward the request to a JSP page. The servlet determines which JSP page is appropriate to the
situation and uses the forward method of RequestDispatcher to transfer control to that page.
6. Extract the data from the beans. The JSP page accesses beans with jsp:useBean and a scope
matching the location of step 4. The page then uses jsp:getProperty to output the bean properties.
The JSP page does not create or modify the bean; it merely extracts and displays data that the
servlet created.
Defining Beans to Represent the Data
Writing Servlets to Handle Requests
Populating the Beans
Storing the Results
Storing data that the JSP page will use only in this request. First, the servlet would create and
store data as follows:
ValueObject value = new ValueObject(...);
request.setAttribute("key", value);
Next, the servlet would forward the request to a JSP page that uses the following to retrieve the
data.
<jsp:useBean id="key" type="somePackage.ValueObject" scope="request" />
The request attributes are independent of the information coming from the client; they are just
application-specific entries in a hash table that is attached to the request object. This table simply
stores data in a place that can be accessed by both the current servlet and JSP page, but not by
any other resource or request.
Storing data that the JSP page will use in this request and in later requests from the same client.
First, the servlet would create and store data as follows:
ValueObject value = new ValueObject(...);
HttpSession session = request.getSession();
session.setAttribute("key", value);
Next, the servlet would forward to a JSP page that uses the following to retrieve the data:
<jsp:useBean id="key" type="somePackage.ValueObject" scope="session" />
Storing data that the JSP page will use in this request and in later requests from any client. First,
the servlet would create and store data as follows:
ValueObject value = new ValueObject(...);
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
getServletContext().setAttribute("key", value);
Next, the servlet would forward to a JSP page that uses the following to retrieve the data:
<jsp:useBean id="key" type="somePackage.ValueObject" scope="application" />
the servlet code is normally synchronized to prevent the data changing between the servlet and
the JSP page.
Forwarding Requests to JSP Pages
You forward requests with the forward method of RequestDispatcher. You obtain a RequestDispatcher
by calling the getRequestDispatcher method of ServletRequest, supplying a relative address.
Forwarding to Static Resources
Redirecting Instead of Forwarding
The standard MVC approach is to use the forward method of RequestDispatcher to transfer control from
the servlet to the JSP page. However, when you are using session-based data sharing, it is sometimes
preferable to use response.sendRedirect.
Here is a summary of the behavior of forward.
Control is transferred entirely on the server. No network traffic is involved.
The user does not see the address of the destination JSP page and pages can be placed in WEB-INF
to prevent the user from accessing them without going through the servlet that sets up the data.
This is beneficial if the JSP page makes sense only in the context of servlet-generated data.
Here is a summary of sendRedirect.
Control is transferred by sending the client a 302 status code and a Location response header.
Transfer requires an additional network round trip.
The user sees the address of the destination page and can bookmark it and access it
independently. This is beneficial if the JSP is designed to use default values when data is missing.
For example, this approach would be used when redisplaying an incomplete HTML form or
summarizing the contents of a shopping cart. In both cases, previously created data would be
extracted from the user's session, so the JSP page makes sense even for requests that do not
involve the servlet.
Extracting Data from Beans
The JSP page never creates the objects. The servlet, not the JSP page, should create all the data
objects. So, to guarantee that the JSP page will not create objects, you should use


<jsp:useBean ... type="package.Class" />
instead of
<jsp:useBean ... class="package.Class" />.
The JSP page should not modify the objects. So, you should use jsp:getProperty but not
jsp:setProperty.
The scope you specify should match the storage location used by the servlet. For example, the following
three forms would be used for request-, session-, and application-based sharing, respectively.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
<jsp:useBean id="key" type="somePackage.SomeBeanClass" scope="request" />
<jsp:useBean id="key" type="somePackage.SomeBeanClass" scope="session" />
<jsp:useBean id="key" type="somePackage.SomeBeanClass" scope="application" />
This section summarizes the code that would be used for request-based, session-based, and
application-based MVC approaches.
Request-Based Data Sharing
With request-based sharing, the servlet stores the beans in the HttpServletRequest, where they are
accessible only to the destination JSP page.
Servlet
ValueObject value = new ValueObject(...);
request.setAttribute("key", value);
RequestDispatcher dispatcher =request.getRequestDispatcher("/WEB-INF/SomePage.jsp");
dispatcher.forward(request, response);
JSP Page
<jsp:useBean id="key" type="somePackage.ValueObject" scope="request" />
<jsp:getProperty name="key" property="someProperty" />
Session-Based Data Sharing
With session-based sharing, the servlet stores the beans in the HttpSession, where they are accessible to
the same client in the destination JSP page or in other pages.
Servlet
ValueObject value = new ValueObject(...);
HttpSession session = request.getSession();
session.setAttribute("key", value);
RequestDispatcher dispatcher = request.getRequestDispatcher("/WEB-INF/SomePage.jsp");
dispatcher.forward(request, response);
JSP Page
<jsp:useBean id="key" type="somePackage.ValueObject" scope="session" />
<jsp:getProperty name="key" property="someProperty" />
Application-Based Data Sharing
With application-based sharing, the servlet stores the beans in the ServletContext, where they are
accessible to any servlet or JSP page in the Web application. To guarantee that the JSP page extracts the
same data that the servlet inserted, you should synchronize your code as below.
Servlet
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
synchronized(this) {
ValueObject value = new ValueObject(...);
getServletContext().setAttribute("key", value);
RequestDispatcher dispatcher = request.getRequestDispatcher("/WEB-INF/SomePage.jsp");
dispatcher.forward(request, response);
}
JSP Page
<jsp:useBean id="key" type="somePackage.ValueObject" scope="application" />
<jsp:getProperty name="key" property="someProperty" />
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Expression Language
These tag libraries provide support for common, structural tasks, such as: iteration and conditionals,
processing XML documents, internationalization and database access using the Structured Query
Language (SQL).
The Expression Language introduced in JSTL 1.0 is now incorporated in JavaServer Pages specification(JSP
2.0). This articie gives some idea about what is Expression Language and how to simplify the maintenance
for JSP applications by avoiding scripting elements.
The pattern that identifies Expression Language is ${ }.
To deactivate the evaluation of EL expressions, we specify the isELIgnored attribute of the page directive:
<%@ page isELIgnored ="true|false" %>
The valid values of this attribute are true and false. If it is true, EL expressions are ignored when they
appear in static text or tag attributes. If it is false, EL expressions are evaluated by the container.
In particular, the expression language supports the following capabilities
Concise access to stored objects. To output a "scoped variable" (object stored with setAttribute
in the PageContext, HttpServletRequest, HttpSession, or ServletContext) named saleItem, you use
${saleItem}.
Shorthand notation for bean properties. To output the companyName property (i.e., result of
the getCompanyName method) of a scoped variable named company, you use
${company.companyName}. To access the firstName property of the president property of a
scoped variable named company, you use ${company.president.firstName}.
Simple access to collection elements. To access an element of an array, List, or Map, you use
${variable[indexOrKey]}. Provided that the index or key is in a form that is legal for Java variable
names, the dot notation for beans is interchangeable with the bracket notation for collections.
Succinct access to request parameters, cookies, and other request data. To access the
standard types of request data, you can use one of several predefined implicit objects.
A small but useful set of simple operators. To manipulate objects within EL expressions, you
can use any of several arithmetic, relational, logical, or empty-testing operators.
Conditional output. To choose among output options, you do not have to resort to Java scripting
elements. Instead, you can use ${test ? option1 : option2}.
Automatic type conversion. The expression language removes the need for most typecasts and
for much of the code that parses strings as numbers.
Empty values instead of error messages. In most cases, missing values or
NullPointerExceptions result in empty strings, not thrown exceptions.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Operators which can be used in EL expression
Operator
Description
.
Access a bean property or Map entry.
[]
Access an array or List element.
()
Grouping of a subexpression for evaluation order.
?:
Conditional test: condition ? ifTrue : ifFalse.
+
Addition.
Subtraction.
*
Multiplication.
/or div
Division.
% or mod M Modulo (remainder).
== or eq
equality.
!= or ne
inequality.
< or lt less than.
> or gt
greater than.
<= or le
less than or equal.
>= or ge
greater than or equal.
&& or and
logical AND.
|| or or
logical OR.
! or not
Unary Boolean complement.
empty
Test for null,empty String,array or Collection.
func(args)
A function call.
Example# EL basic 1 Arithmetic operator
Output View
Coding View of El2.jsp
<html>
<head>
<title>Basic Arithmetic</title>
</head>
<body>
<h3>Basic Arithmetic</h3>
<br>
<code>
<table border="1">
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
<thead>
<td><b>EL Expression</b></td>
<td><b>Result</b></td>
</thead>
<tr>
<td>\${2 + 2}</td>
<td>${2 + 2}</td>
</tr>
<tr>
<td>\${2.2 + 2.3}</td>
<td>${2.2 + 2.3}</td>
</tr>
<tr>
<td>\${12%4}</td>
<td>${12%4}</td>
</tr>
<tr>
<td>\${12 mod 4}</td>
<td>${12 mod 4}</td>
</tr>
<tr>
<td>\${(1==2) ? 3 : 4}</td>
<td>${(1==2) ? 3 : 4}</td>
</tr>
</table>
</code>
</body>
</html>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Example# EL basic 2 Comparison operator
Output View
Coding View of El3.jsp
<html>
<head>
<title>Basic Comparisons</title>
</head>
<body>
<h1>Basic Comparisons</h1>
<table border="1">
<thead>
<td><b>EL Expression</b></td>
<td><b>Result</b></td>
</thead>
<tr>
<td>\${5 &lt; 7}</td>
<td>${5 < 7}</td>
</tr>
<tr>
<td>\${5 lt 7}</td>
<td>${5 lt 7}</td>
</tr>
<tr>
<td>\${4 &gt; (6/2)}</td>
<td>${4 > (6/2)}</td>
</tr>
<tr>
<td>\${4 &gt; (6/2)}</td>
<td>${4 > (6/2)}</td>
</tr>
<tr>
<td>\${6.0 &gt;= 3}</td>
<td>${6.0 >= 3}</td>
</tr>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
<tr>
<td>\${6.0 ge 3}</td>
<td>${6.0 ge 3}</td>
</tr>
<tr>
<td>\${4 &lt;= 3}</td>
<td>${4 <= 3}</td>
</tr>
<tr>
<td>\${4 le 3}</td>
<td>${4 le 3}</td>
</tr>
<tr>
<td>\${2.0 == 2}</td>
<td>${2.0 == 2}</td>
</tr>
<tr>
<td>\${2.0 eq 2}</td>
<td>${2.0 eq 2}</td>
</tr>
<tr>
<td>\${(10*10) != 100}</td>
<td>${(10*10) != 100}</td>
</tr>
<tr>
<td>\${(10*10) ne 100}</td>
<td>${(10*10) ne 100}</td>
</tr>
</table>
</body>
</html>
EL implicit objects
Identifier
pageContext
pageScope
requestScope
sessionScope
applicationScope
parametersparam
paramValues
header
headerValues
cookie
initParam
Description
PageContext instance , servletContext , session, request ,response
Map-associates name and values of page-scoped attributes
Map-associates name and values of request-scoped attributes
Map-associates name and values of session-scoped attributes
Map-associates name and values of application-scoped attributes
Map-stores the primary values of the request parameters by name
Map-stores all values of the request parameters as String arrays
Map-stores the primary values of the request headers by name
Map-stores all values of the request headers as String arrays
Map-stores the cookies accompanying the request by name
Map-stores the context initialization params of the appln by name
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Example# EL basic 3
Output View
Coding View of El1.jsp
<html>
<head>
<title> Use of Expression Language in jsp</title></head>
<%pageContext.setAttribute("pageColor", "#FFFFDF");%>
<%pageContext.setAttribute("boSize", "5");%>
<body>
<table bgcolor="${pageScope.pageColor}" border="${pageScope.boSize}" width="50%">
<tr>
<td>
<b>hi welcome to aspiration</b></td>
</tr>
<tr>
<td>
You appear to be using the following browser:<br>${header["user-agent"]}
</td>
</tr>
</table>
</body>
</html>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Example# EL basic 4 Parameter
Output View
Coding View of El4.jsp
<%@page language="java"%>
<html>
<head>
<title>[]</title>
</head>
<body>
<form action="El5.jsp">
First Name:<input type='text' name='Name'/><br>
Address :<input type='text' name='Address'/>
<input type='submit' value='Submit'/>
</form>
</body>
</html>
Coding View of El5.jsp
<%@page language="java"%>
<html>
<head>
<title>[]</title>
</head>
<body>
<form>
Name is : ${param.Name} <br>
Address is : ${param.Address}
</form>
</body>
</html>
Example# EL basic 5 Cookie
Output View
Coding View of El6.jsp
<%@page language="java"%>
<html>
<head>
<title>Cookie</title>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
</head>
<body>
<form action="El7.jsp">
<%
Cookie c=new Cookie("name","Shyam Chawda");
response.addCookie(c);
%>
<input type='submit' value='Submit'/>
</form>
</body>
</html>
Coding View of El7.jsp
<%@page language="java"%>
<html>
<head>
</head>
<body>
<form>
Name : ${cookie["name"]} <br>
Value : ${cookie["name"].value}
</form>
</body>
</html>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Structure of Web Applications
Web application has a standardized format and is portable across all compliant Web or application servers.
The top-level directory of a Web application is simply a directory with a name of your choosing. Within
that directory, certain types of content go in designated locations.
Default WebApp/(Publicly available files, such as
| .jsp, .html, .jpg, .gif)
|
+WEB-INF/-+
|
+ classes/(directory containing
|
Java classes including
|
servlets used by the
|
Web Application)
|
+ lib/(directory containing
|
jar files used by the
|
Web Application)
|
+ web.xml
|
+ weblogic.xml
JSP Pages
JSP pages should be placed in the top-level Web application directory or in a subdirectory with any name
other than WEB-INF or META-INF. Servers are prohibited from serving files from WEB-INF or META-INF to
the user.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Once you register a prefix, JSP pages are then accessed with URLs of the form
http://host/webAppPrefix/filename.jsp (if the pages are in the top-level directory of the Web application)
or http://host/webAppPrefix/subdirectory/filename.jsp (if the pages are in a subdirectory).
It depends on the server whether a default file such as index.jsp can be accessed with a URL that specifies
only a directory (e.g., http://host/webAppPrefix/) without the developer first making an entry in the Web
app’s WEB-INF/web.xml file.
If you want index.jsp to be the default file name, we strongly recommend that you make an
explicit welcome-file-list entry in your Web app’s web.xml file.
For example, the following web.xml entry specifies that if a URL specifies a directory name but no file
name, the server should try index.jsp first and index.html second.
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
HTML Documents, Images, and Other Regular Web Content
They are placed in exactly the same locations and accessed with URLs of exactly the same form.
Individual Servlets, Beans, and Helper Classes
Servlets and other .class files are placed either in WEB-INF/classes or in a subdirectory of WEBINF/classes that matches their package name. To access one of these servlets, you need to designate the
specific URL for it by specifying the servlet-mapping element in the web.xml deployment descriptor file
that is located within the WEB-INF directory of the Web application.
There is a second way to access servlets without having to specify a custom URL. It is with URLs of the
form http://host/webAppPrefix/servlet/packageName.Servlet- Name. Using this way of accessing servlets
is fine if you want to try capabilities or make a quick test case. However, we recommend you do not use
this approach for real-world applications.
Deployment Descriptor
The deployment descriptor file, web.xml, should be placed in the WEB-INF subdirectory of the main Web
application directory.
Note that a few servers have a global web.xml file that applies to all Web applications. For example,
Tomcat uses tomcat_dir/conf/web.xml for global configuration settings.
Tag Library Descriptor Files
Tag Library Descriptor (TLD) files should be placed inside of the WEB-INF directory or any subdirectory of
WEB-INF.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Grouping them in a common directory (e.g., tlds) simplifies their management. JSP pages can access TLD
files that are in WEB-INF using a taglib directive as follows:
<%@ taglib uri="/WEB-INF/tlds/myTaglibFile.tld" ...%>
Because it is the server, not the client (e.g., Web browser), that accesses the TLD file, the prohibition that
content inside of WEB-INF is not Web accessible does not apply.
When deployed inside a JAR file, the .tld file should be placed inside the META-INF directory or any
subdirectory of META-INF. The switch in location from WEB-INF to META-INF is because JAR files are not
Web application archives and thus don’t contain a WEB-INF directory.
Tag Files
Tag files should be placed in the WEB-INF/tags directory or a subdirectory of WEB-INF/tags.
As with TLD files, tag files are still accessible to JSP pages even though they are located inside of the
protected WEB-INF directory. Tag files are also declared inside a JSP page through the taglib directive.
However, instead of uri, they use the tagdir attribute. For example, if we placed the myTagFile.tag file
inside of the WEB-INF/tags directory of our Web application, the taglib directive of a JSP page would look
something like this:
<%@ taglib tagdir="/WEB-INF/tags" ...%>
WAR Manifest File
When you create a WAR file, a MANIFEST.MF file is placed in the META-INF subdirectory. Normally, the jar
utility automatically creates MANIFEST.MF and places it into the META-INF directory, and you ignore it if
you unpack the WAR file. Occasionally, however, you modify MANIFEST.MF explicitly, so it is useful to
know where it is stored.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Web.XML
A deployment descriptor (DD) refers to a configuration file for an artifact that is deployed to some
container/engine.
The deployment descriptor, web.xml, is used to control many facets of a Web application.
Using web.xml, you can assign custom URLs for invoking servlets, specify initialization
parameters for the entire application as well as for specific servlets, control session
timeouts, declare filters, declare security roles, restrict access to Web resources based
on declared security roles, and so on.
It also enumerates enterprise beans referenced in the Web application.
The file goes into the WEB-INF directory under the document root of a web application.
The deployment descriptor is not part of the Java compilation process. Therefore,
changes in web.xml don’t force you to recompile your code.
In addition, the separation between the configuration mechanism, web.xml, and the Java code
allows for the division between the development and deployment roles within the development
process.
The Java developer is relieved of having to know about the specific operational environment while
writing code; this facilitates code reuse.
By editing web.xml, the person deploying the application has the power to affect application
behavior without ever having to deal with Java code. For example, a company might decide to
deploy the same Web application at several office locations.
Even within one company, different offices might have slightly different needs and therefore would
need to customize the application. The exact same compiled Java code could be shipped to all
locations.
The web.xml file would then be used to customize the behavior of the application based on the
particular office location.
Defining the Header and the Root Element
The deployment descriptor, like all XML files, must begin with an XML header. This header declares the
version of XML that is in effect, and gives the character encoding for the file.
The top-level (root) element for the deployment descriptor is web-app.
<web-app
xmlns=http://java.sun.com/xml/ns/j2ee
xmlns:xsi=http://www.w3.org/2001/XMLSchemainstance xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/webapp_2_4.xsd version="2.4">
<!-- Your entries go here. All are optional. -->
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
</web-app>
Note that http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd is the only URL that must actually exist,
pointing to the location of the XML Schema file.
The URLs in the declaration of web.xml are namespaces. Namespaces are just unique identifiers for
a particular Schema syntax and could be any unique string.
Version 2.4
The order of web-app subelements does not matter if you are using version 2.4. This is one of
the major differences between web.xml of version 2.4 and earlier versions.
legal elements
The following list shows all
that can appear directly within the web-app
element. Remember that all these elements are optional.
• servlet and servlet-mapping.
You use the servlet element for that purpose. Once you have declared a servlet (using the servlet
element), you can designate one or more URL patterns that allow the clients to invoke the servlet.
• context-param. The context-param element declares application-wide initialization parameters.
• filter and filter-mapping. The filter element associates a name with a class that implements the
javax.servlet.Filter interface. Once you have named a filter, you associate it with one or more servlets or
JSP pages by means of the filter-mapping element.
• welcome-file-list. The welcome-file-list element tells the server what file to use when the server
receives URLs that refer to a directory name but not a file name.
• error-page. The error-page element lets you designate the pages that will be displayed when certain
HTTP status codes are returned or when certain types of exceptions are thrown.
• security-constraint. The security-constraint element lets you designate URLs that should be protected
from unauthorized users. It goes hand-in-hand with the login-config element.
• login-config. You use the login-config element to specify how the server should authenticate users who
attempt to access protected pages. It goes hand-in-hand with the security-constraint element.
• security-role. The security-role element must declare explicit role names used in the role-name
subelements of the auth-constraint element inside every security-constraint element in web.xml. It could
also list security role names that will appear in the role-name subelements of the security-role-refelement
inside the servlet element.
• session-config. If a session has not been accessed for a certain
• icon. The icon element designates the location of either one or two image files that an IDE can use to
represent the Web application.
• display-name. The display-name element provides a name that graphical user interface (GUI) tools
might use to label the Web application.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
• description. The description element gives explanatory text about the Web application.
• mime-mapping. If your Web application has unusual files that you want to guarantee are assigned
certain MIME types, the mime-mapping element can provide this guarantee.
• jsp-config. The jsp-config element is used to provide configuration information for the JSP pages in a
Web application. It has two subelements, taglib and jsp-property-group. The taglib element assigns
aliases to Tag Library Descriptor (TLD) files.
This capability lets you change the location of the TLD files without editing the JSP pages that use those
files. The jsp-property-group element is used to configure property information for a group of files that
match a URL pattern.
• locale-encoding-mapping-list. This element sets the default locale character encodings using one or
more locale-encodingmapping elements.
• listener. The listener element designates an event listener class. Listener classes are notified when a
particular Web application life-cycle event occurs. For example, it can be notified when the ServletContext
or HttpSession is first initialized or destroyed.
• distributable. The distributable element tells the system that it is safe to distribute the Web application
across multiple servers in a cluster.
• env-entry. The env-entry element declares the Web application’s environment entry.
• ejb-ref. The ejb-ref element declares a reference to the home interface of an enterprise bean.
• ejb-local-ref. The ejb-local-ref element declares a reference to the local home interface of an
enterprise bean.
• service-ref. The service-ref element declares a reference to a Web service.
• resource-ref. The resource-ref element declares a reference to an external resource used with a
resource factory.
• resource-env-ref. The resource-env-ref element declares a reference to an administered object
associated with a resource.
• message-destination-ref. The message-destination-ref element declares a reference to a message
destination associated with a resource.
• message-destination. The message-destination element specifies a logical (e.g., portable) message
destination name.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Assigning Names
To provide initialization parameters, define a custom URL, or assign a logical (portable) security role to a
servlet or JSP page, you must first give the servlet or page a name.
You assign a name by means of the servlet element. The most common format includes servlet-name and
servlet-class subelements (inside the web-app element)
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>coreservlets.TestServlet</servlet-class>
</servlet>
This means that the servlet at WEB-INF/classes/coreservlets/TestServlet is now known by the
registered name Test. Giving a servlet a name has the following major implications: Initialization
parameters, custom URL patterns, and other customizations refer to the servlet by the registered name,
not by the class name.
Defining Custom URLs
To assign a custom URL, you use the servlet-mapping element along with its servlet-name and urlpattern subelements. The servlet-name element specifies the name that was assigned to the servlet
using the servlet-name subelement of the servlet element; url-pattern describes a URL relative to the Web
application root.
The value of the url-pattern element must begin with either a slash (/) or an asterisk and period
combination (*.).
<servlet>
<servlet-name>Test1</servlet-name>
<servlet-class>coreservlets.TestServlet1</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Test1</servlet-name>
<url-pattern>/UrlTest1</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>H1</servlet-name>
<servlet-class>HiHello</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>H1</servlet-name>
<url-pattern>/H1</url-pattern>
</servlet-mapping>
Above program is TestServlet1 invoked with http://localhost/deployDemo/UrlTest1.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
The specification allows you to map a servlet to a particular custom URL. For example, here is a simple
web.xml excerpt that lets you use the URL http://host/webApp- Prefix/UrlTest1 to invoke TestServlet1
declared with the name Test1.
Multimapping Patterns
In the majority of cases, you want to assign one URL to each servlet
There are two ways you can accomplish this multimapping:
By giving a url-pattern of /directoryName/*, you can specify that all URLs of the form
http://host/webAppPrefix/directoryName/ blah are handled by the designated servlet.
By giving a url-pattern of *.foo, you can specify that all URLs
http://host/webAppPrefix/.../blah.foo are handled by the designated servlet.
of
the
form
Here is an excerpt from web.xml showing a mapping that lets you use URLs like
http://host/webAppPrefix/UrlTest4, http://host/webAppPrefix/UrlTest4/ (note the slash at the end), h
ttp://host/webAppPrefix/UrlTest4/foo/bar to invoke TestServlet4 declared with the name Test4.
<servlet>
<servlet-name>Test4</servlet-name>
<servlet-class>coreservlets.TestServlet4</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Test4</servlet-name>
<url-pattern>/UrlTest4/*</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>H2</servlet-name>
<servlet-class>HiHello</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>H2</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
Likewise, you can use * if you want all URLs ending with a certain extension to invoke a particular servlet.
For
example,
here
is
an
excerpt
from
web.xml
that
lets
you
use
URLs
like
http://host/webAppPrefix/foo/bar/baz.urlTest5,
http://host/webAppPrefix/foo.urlTest5
to
invoke
TestServlet5 declared with the name
<servlet>
<servlet-name>Test5</servlet-name>
<servlet-class>coreservlets.TestServlet5</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Test5</servlet-name>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
<url-pattern>*.urlTest5</url-pattern>
</servlet-mapping>
Matching Overlapping Patterns
When mapping a servlet to a URL, the specification does not allow the same value of url-pattern to appear
twice within the same web.xml file.
Thus, there can never be an overlap between two patterns that map exact matches. However, if one or
more servlet mappings use “*”, an overlap could occur.
Compliant servers are required to use the following rules to resolve these overlaps.
• Exact matches are handled first. Thus, if /foo/bar and /foo/* were both url-pattern entries, the first
would take precedence for a request URL of http://host/webAppPrefix/foo/bar. Similarly, /foo/bar.html
would win over *.html for an incoming URL of http://host/webAppPrefix/foo/bar.html.
• Directory mappings are preferred over extension mappings.
Thus, if /foo/* and *.html were both url-pattern entries, the first would take precedence for a request URL
of http://host/webAppPrefix/foo/bar.html.
• For overlapping directory mappings, the longest path is preferred.
Thus, if /foo/bar/* and /foo/* were both url-pattern entries, the first would take precedence for a request
URL of http://host/webAppPrefix/foo/bar/baz.html.
JSP naming conventions
Generally, JSP pages do not need to be declared inside web.xml.
They can be invoked like any other static resource (e.g., somePage.html), provided you place them
outside of WEB-INF.
Declaring a name for a JSP page allows you to provide a name to use with customization settings (e.g.,
initialization parameters and security settings) and so that you can change the URL that invokes the JSP
page
<!-- Register the name "PageName" for TestPage.jsp -->
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/WEB-INF/jspPages/TestPage.jsp</jsp-file>
</servlet>
<!-- Use the URL http://host/webAppPrefix/UrlTest7/foo -->
<servlet-mapping>
<servlet-name>PageName</servlet-name>
<url-pattern>/UrlTest7/*</url-pattern>
</servlet-mapping>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Disabling the invoker serlvet
Disabling the invoker servlet, because most servers have a standard servlet that is registered with the
default servlet URLs and simply invokes the real servlet.
One reason for setting up a custom URL for a servlet or JSP page is so that you can register
initialization parameters to be read from the init (servlets) or jspInit (JSP pages) methods.
There are two main approaches for disabling the default URL:
• Remapping the /servlet/ pattern in each Web application.
• Globally turning off the invoker servlet.
Remapping the /servlet/ URL Pattern
It is quite straightforward to disable processing of URLs that begin with http://host/webAppPrefix/servlet/
in a particular Web application.
Simply use <url-pattern>/servlet/*</url-pattern> as the pattern within the servlet-mapping element.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Eight basic steps are required to set up your system to use this type of form-based security.
Set up usernames, passwords, and roles. In this step, you designate a list of users and associate each
with a password and one or more abstract roles (e.g., normal user or administrator). This is a completely
server-specific process.
Tell the server that you are using form-based authentication. Designate the locations of the
login and login-failure page.
This process uses the web.xml login-config element with an auth-method subelement of FORM and a
form-login-config subelement that gives the locations of the two pages.
Create a login page.
This page must have a form with an ACTION of j_security_check, a METHOD of POST, a text field named
j_username, and a password field named j_password.
Create a page to report failed login attempts.
This page can simply say something like “username and password not found” and perhaps give a link back
to the login page.
Specify which URLs should be password protected.
For this step, you use the security-constraint element of web.xml. This element, in turn, uses webresource-collection and auth-constraint subelements.
The first of these (web-resourcecollection) designates the URL patterns to which access should be
restricted, and the second (auth-constraint) specifies the abstract roles that should have access to the
resources at the given URLs.
List all possible abstract roles (types of users) that will be granted access to any resource.
Each abstract role is declared using the security-role element. The security-role element contains the
required role-name element, which contains the name of the abstract role.
Specify which URLs should be available only with SSL.
If your server supports SSL, you can stipulate that certain resources are available only through encrypted
HTTPS (SSL) connections. You use the user-data-constraint subelement of security-constraint for this
purpose.
Turn off the invoker servlet.
Security settings are based on URLs, so you protect servlets by listing their URLs within the webresourcecollection element. The servlet URLs, in turn, are normally defined with the url-pattern element of
servlet-mapping. However, many servers also have a default servlet URL of the form
http://host/webAppPrefix/servlet/ServletName. If you have this capability enabled, there are now two
URLs that can invoke each servlet: the URL registered in servlet-mapping and the default (invoker servlet)
URL. Remembering to protect both addresses is too hard. Instead, disable the invoker servlet, either
globally for your server, or by mapping the /servlet/* pattern within your Web application.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Servlet 3.0 specifies the following methods that enable you to access security information about the
component’s caller:
getRemoteUser, which determines the user name with which the client authenticated. The
getRemoteUser method returns the name of the remote user (the caller) associated by the container with
the request. If no user has been authenticated, this method returns null.
isUserInRole, which determines whether a remote user is in a specific security role. If no user has been
authenticated, this method returns false. This method expects a String user role-name parameter.
The security-role-ref element should be declared in the deployment descriptor with a role-name
subelement containing the role name to be passed to the method. Using security role references is
discussed in Declaring and Linking Role References.
getUserPrincipal, which determines the principal name of the current user and returns a
java.security.Principal object. If no user has been authenticated, this method returns null. Calling the
getName method on the Principal returned by getUserPrincipal returns the name of the remote user.
reventing unauthorized users from accessing sensitive data. This process involves access restriction
(identifying which resources need protection and who should have access to them) and authentication
(identifying users to determine if they are one of the authorized ones). Simple authentication involves the
user entering a username and password in an HTML form or a dialog box; stronger authentication involves
the use of X.509 certificates sent by the client to the server. The first aspect of Web security applies to
virtually all secure applications. Even intranets at locations with physical access controls usually require
some sort of user authentication.
Preventing attackers from stealing network data while it is in transit. This process involves the use of SSL
to encrypt the traffic between the browser and the server. This capability is generally reserved for
particularly sensitive applications or for particularly sensitive pages within a larger application. After all,
unless the attackers are on your local subnet, it is exceedingly difficult for them to gain access to your
network traffic.
There are two general strategies for implementing these security aspects: declarative security and
programmatic security.
Within the Web application framework, there are two general approaches to this type of security:
1. Declarative security. With declarative security, the topic of this chapter, none of the individual servlets
or JSP pages need any security-aware code. Instead, both of the major security aspects are handled by
the server.
To prevent unauthorized access, you use the Web application deployment descriptor (web.xml) to
declare that certain URLs need protection, and which categories of users should have access to them.
You also designate the authentication method that the server should use to identify users. At request
time, the server automatically prompts users for usernames and passwords when they try to access
restricted resources, automatically checks the results against a predefined set of usernames and
passwords, and automatically keeps track of which users have previously been authenticated. This
process is completely transparent to the servlets and JSP pages.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
To safeguard network data, you use the deployment descriptor to stipulate that certain URLs should only
be accessible with SSL. If users try to use a regular HTTP connection to access one of these URLs, the
server automatically redirects them to the HTTPS (SSL) equivalent.
With declarative security, the topic of the previous chapter, none of the individual servlets or JSP pages
need any security-aware code. Instead, both of the major security aspects are handled by the server. To
prevent unauthorized access, you use the Web application deployment descriptor (web.xml) to declare
that certain URLs need protection, and which categories of users should have access to them. You also
designate the authentication method that the server should use to identify users. At request time, the
server automatically prompts users for usernames and passwords when they try to access restricted
resources, automatically checks the results against a predefined set of usernames and passwords, and
automatically keeps track of which users have previously been authenticated. This process is completely
transparent to the servlets and JSP pages. To safeguard network data, you use the deployment descriptor
to stipulate that certain URLs should only be accessible with SSL. If users try to use a regular HTTP
connection to access one of these URLs, the server automatically redirects them to the HTTPS (SSL)
equivalent.
Declarative security is all well and good. In fact, it is by far the most common approach to Web application
security. But what if you want your servlets to be completely independent of any server-specific settings
such as password files? Or, what if you want to let users in various roles access a particular resource but
customize the data depending on the role that they are in? Or, what if you want to authenticate users
other than by requiring an exact match from a fixed set of usernames and passwords? That's where
programmatic security comes in.
With programmatic security, the topic of this chapter, protected servlets and JSP pages at least partially
manage their own security. To prevent unauthorized access, each servlet or JSP page must either
authenticate the user or verify that the user has been authenticated previously. Even after the servlet or
JSP page grants access to a user, it can still customize the results for different individual users or
categories of users. To safeguard network data, each servlet or JSP page has to check the network
protocol used to access it. If users try to use a regular HTTP connection to access one of these URLs, the
servlet or JSP page must manually redirect them to the HTTPS (SSL) equivalent.
1. Programmatic security. With programmatic security, the topic of the next chapter, protected servlets and
JSP pages at least partially manage their own security.
To prevent unauthorized access, each servlet or JSP page must either authenticate the user or verify that
the user has been authenticated previously.
To safeguard network data, each servlet or JSP page has to check the network protocol used to access it.
If users try to use a regular HTTP connection to access one of these URLs, the servlet or JSP page must
manually redirect them to the HTTPS (SSL) equivalent.
Declarative security is very convenient: you set up usernames, passwords, access mechanisms (HTML
forms vs. BASIC authentication) and transport-layer requirements (SSL vs. normal HTTP), all without
putting any security-related code in any of the individual servlets or JSP pages. However, declarative
security provides only two levels of access for each resource: allowed and denied. Declarative security
provides no options to permit resources to customize their output depending on the username or role of
the client that accesses them.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
It would be nice to provide this customization without giving up the convenience of container-managed
security for the usernames, passwords, and roles as would be required if a servlet or JSP page completely
managed its own security (as in Section 4.3). To support this type of hybrid security, the servlet
specification provides three methods in HttpServletRequest:
isUserInRole. This method determines if the currently authenticated user belongs to a specified role. For
example, given the usernames, passwords, and roles of Listing 4.1, if the client has successfully logged in
as user valjean, the following two expressions would return true:
request.isUserInRole("lowStatus")
request.isUserInRole("nobleSpirited")
Tests for all other roles would return false. If no user is currently authenticated (e.g., if authorization
failed or if isUserInRole is called from an unrestricted page and the user has not yet accessed a
restricted page), isUserInRole returns false. In addition to the standard security roles given in the
password file, you can use the security-role-ref element to define aliases for the standard roles. See
the next subsection for details.
getRemoteUser. This method returns the name of the current user. For example, if the client has
successfully logged in as user valjean, request.getRemoteUser() would return "valjean". If no user is
currently authenticated (e.g., if authorization failed or if isUserInRole is called from an unrestricted page
and the user has not yet accessed a restricted page), getRemoteUser returns null.
getUserPrincipal.
This
method
returns
the
current
username
wrapped
inside
a
java.security.Principal object. The Principal object contains little information beyond the username
(available with the getName method). So, the main reason for using getUserPrincipal in lieu of
getRemoteUser is to be compatible with preexisting security code (the Principal class is not specific to
the servlet and JSP API and has been part of the Java platform since version 1.1). If no user is currently
authenticated, getUserPrincipal returns null.
It is important to note that this type of programmatic security does not negate the benefits of containermanaged security. With this approach, you can still set up usernames, passwords, and roles by using your
server's mechanisms. You still use the login-config element to tell the server whether you are using
form-based or BASIC authentication. If you choose form-based authentication, you still use an HTML form
with an ACTION of j_security_check, a text field named j_username, and a password field named
j_password. Unauthenticated users are still automatically sent to the page containing this form, and the
server still automatically keeps track of which users have been authenticated. You still use the securityconstraint element to designate the URLs to which the access restrictions apply. You still use the userdata-constraint element to specify that certain URLs require SSL. For details on all of these topics, see
However, you also add code to some of your resources to customize their behavior based on who is
accessing them.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Often, declarative security is server based. Using the server's configuration, you provide protection to a
resource or set of resources. You use the container's authentication and authorization schemes to protect
that resource from unauthorized access.
The declarative approach to security casts a wide net. Declarative security is implemented as a separate
layer from the web components that it works with. You set up a security system, such as a set of file
permissions or users, groups, and roles, and then you plug your application's authentication mechanism
into that layer.
With declarative security, either a user gains access to the resource or they do not. Usually the content
cannot be customized based on roles. In an HTML-based application, the result is that users are denied
access to certain pages. However, in a Flex environment, the typical result of declarative security is that
the user is denied access to the entire application, since the application is seen as a single resource to the
container.
Declarative security lets programmers who write web applications ignore the environment in which they
write. Declarative security is typically set up and maintained by the deployer and not the developer of the
application. Also, updates to the web application do not generally require a refactoring of the security
model.
Programmatic security gives the developer of the application more control over access to the application
and its resources. Programmatic security can be much more detailed than declarative security. For
example, a developer using programmatic security can allow or deny a user access to a particular
component inside the application.
Although programmatic security is typically configured by the developer of the application, it usually
interacts with the same systems as declarative security, so the relationship between developer and
deployer of the application must be cooperative when implementing programmatic security.
Declarative security is recommended over programmatic security for most applications because the design
promotes code reuse, making it more maintainable. Furthermore, declarative security puts the
responsibility of security into the hands of the people who specialize in its implementation; application
programmers can concentrate on writing applications and people who deploy the applications in a specific
environment can concentrate on enforcing security policies and take advantage of that context.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
omcat implements security as specified in the Java servlet specification. This document primarily addresses
Tomcat 4.x security, which is compliant with the 2.3 servlet specification. Some information is also provided
regarding the forthcoming Tomcat 5.x release, which implements the servlet 2.4 specification. Also, there is
some overlap between security requirements defined in the servlet and J2EE specifications. In general, the J2EE
specification includes all servlet specification requirements and makes some optional requirements mandatory
for a web container to be "J2EE compliant". Tomcat implements most optional servlet specification features
but, as an open source project, has not been able to pass the J2EE compliance tests due to J2EE licensing policy
(recent changes by Sun may allow this in the near future).
Tomcat Security Scope
As stated in the servlet specification, Tomcat security is primarily concerned with:




Authentication - The means by which communicating entities prove their identities to one another.
Access control - The means by which requests for resources are limited to users or programs.
Integrity - The means used to prove that information has not been modified while in transit.
Confidentiality - The means used to ensure that information is understandable only by authorized users.
As defined in the servlet specification, Tomcat security is user role-based and web container (somewhat web
application) centric. Hence, Tomcat security scope, by definition in the servlet specification, does not address
issues of security integration with other web and application servers.
Declarative and Programmatic Security
The servlet specification classifies Tomcat security into two broad categories:


Declarative security is the expression of application security external to the application and is preferred when
sufficient as it allows runtime configuration of application security without recoding the application.
Programmatic security is used to implement fine-grained access control, enabling application components to
become security aware.
It may be easier to think in terms of security you configure in the web application environment (declarative) and
security you define within the web application code (programmatic). Each web application configures
declarative security in its unique deployment descriptor, web.xml. This is a required XML-formatted
configuration file (also called the deployment descriptor) found in each web application's WEB-INF directory.
Programmatic security involves using HttpServletRequest API method calls to make business logic decisions
within the web application context. For example, you may want to make combo box values dynamic based on a
user's identity. The servlet API calls you use are:



getRemoteUser - Returns the user name the client used for authentication.
isUserInRole - Determines if a remote user is in a specified security role.
getUserPrincipal - Returns a java.security.Principal object, which contains the principals name and roles.
Tomcat uses role-based authorization to manage access. With this model, access permissions are granted to an
abstract entity called a security role, and access is allowed only to users or groups of users who have that role.
For example, the Tomcat distribution includes two administrative web applications that only grant access to
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
users with the "manager" role. The deployment descriptor specifies the type of access granted to each role, but
does not specify the role to user or group mappings. That's done in the user repository, which is typically a
relational database or LDAP server in production environments, but is another XML-formatted file named
tomcat-users.xml by default.
<!-- Define a security constraint on this application -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Entire Application</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- This role is not in the default user directory -->
<role-name>manager</role-name>
</auth-constraint>
</security-constraint>
<!-- Define the login configuration for this application -->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Tomcat Manager Application</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<description>
The role that is required to log in to the Manager Application
</description>
<role-name>manager</role-name>
</security-role>
Figure 1 - Security snippet from Tomcat Manager's web.xml deployment descriptor
Figure 1.0 shows a security snippet from the Tomcat Manager web application's web.xml file. The security
contraint element defines the URL pattern to match for the constraint to apply (in this example the entire web
application) and an authentication constraint, which will force the user to authenticate. Access is granted only if
an authenticated user has the "manager" role. The login config element defines the type of authentication (more
on this next), in this case HTTP basic. And, the roles referenced by the web application.
Authentication
By default, you do not need to authenticate to access Tomcat resources. Authentication is needed only when
specified in the deployment descriptor with the auth-constrain element. You use a web client (typically a web
browser) to authenticate with Tomcat using one of the following mechanisms:




HTTP Basic Authentication
HTTP Digest Authentication
Form Based Authentication
HTTPS Client Authentication
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
HTTP Basic Authentication
When your browser prompts you for a username and password in a dialog box, you are using HTTP basic
authentication to logon to a web server. This is also know as browser-based authentication because the web
server requests the browser to authenticate you through the HTTP 1.0 protocol. In the dialog box, you also see
the name of a realm to which you will be authenticated. The realm does not necessarily reflect a security policy
domain, which is also referred to as a realm. Think of an HTTP basic authentication realm as a "database" of
usernames and passwords that identify valid users of a web application (or set of web applications), plus a list of
the roles associated with each valid user.
Once you enter your username and password, they are base64 encoded and sent by the browser to Tomcat (for
both secure and non-secure resources). Tomcat authenticates you, and then reauthenticates each subsequent
request against the specified realm. You cannot logout as your username and password remain in browser
memory until you exit. Hence, you must exit the browser to "logout".
Because the username and password are not encrypted, and the target server's identity is not authenticated by
the browser, basic authentication alone is not secure. You can improve security by using a secure transport
mechanism such as HTTPS, or security at the network level such as a VPN. However, if you switch to HTTP
(after authenticating with basic authentication and HTTPS), your browser continues to send your username and
password with each subsequent request in cleartext until you exit.
HTTP Digest Authentication
HTTP digest authentication is also performed by the browser upon request by the web server and based on a
username, password, and realm. However, in this case your password is digested with the secure MD5
algorithm before it is sent by the browser.
You can specify in Tomcat's <realm> element a digest attribute, which must be one of the digest algorithms
supported by the java.security.MessageDigest class (SHA, MD2, or MD5). When you select this option, the
contents of the password that is stored in the realm must be the digest version of the password. The client must
also digest the password using the same algorithm before it is sent. When the realm authenticate() method is
called, the password you input is compared with the value returned by the realm and, if equal, you are
authenticated.
Because your password is digested, HTTP digest authentication is more secure than basic. However, it does
suffer from the same security issues as basic authentication. As it is not supported by popular browsers, HTTP
digest authentication is not required by the servlet specification, but it is implemented by Tomcat. As with basic
authentication, your credentials are stored in the browser's memory until it is exited.
Form Based Authentication
This is the most popular web authentication mechanism in use. It provides the application developer with the
greatest control over the look and feel of the “login screen”, enables closing of user sessions without exiting the
browser, and is more secure than basic authentication.
The web application deployment descriptor contains elements to specify a "login form" and an "error page".
The HTML login form must contain fields for entering a username and a password, which must be named
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
"j_username" and "j_password", respectively. When you attempt to access a protected resource, Tomcat checks
if you are authenticated. If not, the following steps occur:
1.
2.
3.
4.
5.
6.
Tomcat saves the entire HTTP request, then redirects the browser to the configured login form.
You enter your username and password in the login form's "j_username" and "j_password" fields.
The browser posts the form back to the server using the "j_security_check" action.
The container attempts to authenticate the user using the configured security realm.
If authentication fails, the error page is returned with the status code of the response set to 401.
If authentication succeeds, the principal is checked to determine if you have a role authorized to access the
resource.
7. If you are authorized, Tomcat processes the original HTTP request. If authentication fails, or you are not
authorized to access the requested resource, the configured error page is returned.
Because your username and password are not encrypted and the target server is not authenticated, form-based
authentication using HTTP is not secure. If you are using form-based authentication, you should use a secure
transport mechanism such as HTTPS, or security at the network level such as a VPN. However, form-based
authentication is more secure than basic authentication when switching back and forth between HTTPS and
HTTP as your username and password are not sent with each request.
Another advantage of form-based over basic authentication is that the application can programmatically close
your authenticated session, enabling you to logout without restarting your browser. In this respect, calling the
HttpSession.invalidate method seems like it should work, but it does not because HTTP sessions are totally
independent of authentication (e.g., you can have an HTTP session without authenticating and authenticate
without having an HTTP session).
HTTPS Client Authentication
Authentication using HTTPS (HTTP over SSL) enables browsers and web servers to communicate over an
encrypted connection. This is a two-way process, meaning that both the server and the browser encrypt all
traffic before sending out data. Tomcat uses HTTPS for confidentiality (by encrypting the data) and integrity
(which is insured if the message can be decrypted).
Another important aspect of the SSL protocol is authentication. This means that during your initial attempt to
communicate with a web server over a secure connection, that server will present your web browser with a set
of credentials, in the form of a certificate chain, as proof the site is who and what it claims to be. Though
Tomcat supports HTTPS connections and server authentication, it is generally recommended that you off-load
SSL connections to a web server like Apache or IIS and use Tomcat as a plugin to process the servlet and JSP
requests.
The server may also request a client certificate from your browser, asking for proof that you are who you claim
to be. This practice is used more for business-to-business transactions than with individual internet users
because of the overhead required to manage certificates. Most SSL-enabled web servers do not request client
authentication but if you need it, Tomcat does support it.
Web Application Single Sign-on
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
As the underlying principals to which roles are mapped are environment specific rather than web application
specific, it is desirable to:
1. Make login mechanisms and policies a property of the web application environment.
2. Use the same authentication information to represent a principal to all applications in the same container, and
3. Require re-authentication of users only when a security policy domain boundary has been crossed.
Therefore, a J2EE compliant servlet container is required to track authentication information at the container
level (rather than at the web application level). Tomcat enables users authenticated for one web application to
access other web applications managed by the same container. However, login configurations must still be
specified for each web application, which, depending upon the number of web applications can be difficult to
manage (Tomcat also allows each web application to define its own realm). Additionally, Tomcat single sign-on
does not address multiple Tomcat servers, other web servers such as Apache, or an application server like
JBoss.
Specifying Security Constraints
Deployment descriptor <security-constraint> elements define the permissions and rules for the protected
Tomcat resources and include the following XML elements:



web-resource-collection - A set of URL patterns and HTTP methods that describe a set of resources to be
protected. All requests that contain a URL pattern matched in a web resource collection are subject to the
constraint.
auth-constraint - A set of security roles (one or more) to which a user must belong to be granted access to
resources matched by the web resource collection.
user-data-constraint - Describes integrity and confidentiality requirements for the transport layer of the client
server.
Hence, the web resource collection defines the resources, the authorization constraint defines the roles to which
a user can belong to access the resources, and the data constraints defines if HTTPS should be required.
Enhancing Tomcat Security with Cams
When you arrive at the boundary of Tomcat security, you'll discover that it is generally limited by the scope of
the servlet specification and J2EE security. Consequently, Tomcat will not meet the security needs of most
heterogenous, multi-server environments. The good news is that you have the Tomcat source and can write
security code and implement security in servlets to customize Tomcat. The bad news is that you probably don't
have the time, budget, expertise, or even desire to write security code. In addition, embedding low-level security
code within applications is considered to be bad practice.
The Cafésoft Access Management System is designed to pickup where Tomcat security stops. Cams flexibly
meets the needs of the enterprise by providing a complete web access managment system which spans servers
and tiers in a web farm. Cams provides the same security features Tomcat does and more.
From a high-level, you should consider using Cams with Tomcat when you have any of the following needs:
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879




You have a web server farm with more than one stand-alone Tomcat server
You are using Apache and Tomcat servers and desire integrated security
You need centralized security configuration, logging, and events
You need a flexible, easy-to-extend security system
Cams offers many unique features that might more closely adhear to your security needs. The following tables
show a feature by feature comparison of Tomcat security with and without Cams.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Two basic approaches to implementing security are programmatic security, in which you embed explicit
security calls directly into your code, and declarative security, in which you specify security policies using
deployment descriptors and configuration files.
When making use of programmatic security, you embed security enforcement within the application with
programmatic checks on policies, to determine what a user is allowed to do or see in the application, and then
react to this information appropriately. Programmatic security can be useful, even required in some situations,
especially in application contexts in which the expressive power of declarative security is insufficient. But
programmatic security should be used with care. If the design and implementation are not clever and the
developers are not careful, such checks become scattered and strewn throughout the application code. This
situation can become extremely difficult to maintain because of duplicated code and nonuniform
implementation styles. For example, a change in a particular piece of business logic might require changing
several pieces of code. This is expensive, because there is more code to update and test, and also error-prone,
because it's difficult to ensure that you've covered all the bases when the code is implemented and distributed in
an ad hoc fashion. So with programmatic security, the onus is on you to architect your security code in such a
way that it's contained and well encapsulated.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Filters
Filters are java components that you can use to intercept and process requests before they are sent to the
servlet or to process responses after the servlet has completed, but before the response goes back to the
client.
It works basis on the DD.
In the DD, the deployer maps which filters will be called for which request URL patterns.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Advantages
Encapsulate common behavior.
– Have 30 different servlets or JSP pages that need to compress their content to decrease download time?
Make 1 compression filter and apply it to all 30 resources.
Separate high-level access decisions from presentation code.
– Want to block access from certain sites without modifying the individual pages to which these access
restrictions apply? Create an access restriction filter and apply it to as many pages as you like.
Apply wholesale changes to many different resources.
– Have a bunch of existing resources that should remain unchanged except that the company name
should be changed? Make a string replacement filter and apply it wherever appropriate.
Servers load filters into memory when the Web app first comes up. So, if
that filter is not found, your entire Web app is disabled.
Creating a filter involves five basic steps:
Create a class that implements the Filter interface.
Your class will need three methods: doFilter, init, and destroy. The doFilter method contains the main
filtering code , the init method performs setup operations, and the destroy method does cleanup.
Put the filtering behavior in the doFilter method.
The first argument to the doFilter method is a ServletRequest object.
This object gives your filter full access to the incoming information, including form data, cookies, and
HTTP request headers. The second argument is a ServletResponse; it is mostly ignored in simple filters.
The final argument is a FilterChain; it is used to invoke the servlet, JSP page, or the next filter in the chain
as described in the next step.
Call the doFilter method of the FilterChain object.
The doFilter method of the Filter interface takes a FilterChain object as one of its arguments. When you
call the doFilter method of that object, the next associated filter is invoked. If no other filter is associated
with the servlet or JSP page, then the servlet or page itself is invoked.
Register the filter with the appropriate servlets and JSP pages.
Use the filter and filter-mapping elements in the deployment descriptor (web.xml).
Disable the invoker servlet.
Prevent users from bypassing filter settings by using default servlet URLs.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Example# Filter 1
Output View
Coding View of F11.java
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class F11 extends HttpServlet{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException,IOException{
response.setContentType("text/html");
PrintWriter pw = response.getWriter();
pw.println("<h1>Welcome, calling servlet successful</h1>");
}
}
Coding View of ResponseFilterExample.java
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ResponseFilterExample implements Filter{
private FilterConfig config = null;
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterchain)throws IOException, ServletException{
filterchain.doFilter(request, response);
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<b>Filter Received Your Message Successfully:</b>" +
config.getInitParameter("response"));
}
public void destroy() { }
public void init(FilterConfig config) {
this.config = config;
}
}
Coding View of Web.XML
<servlet>
<servlet-name>F11</servlet-name>
<servlet-class>F11</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>F11</servlet-name>
<url-pattern>/F11</url-pattern>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
</servlet-mapping>
<filter>
<filter-name>ResponseFilterExample</filter-name>
<filter-class>ResponseFilterExample</filter-class>
<init-param>
<param-name>response</param-name>
<param-value>Hello Response Filter Example!</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>ResponseFilterExample</filter-name>
<url-pattern>/F11</url-pattern>
</filter-mapping>
Example# Filter2
Output View
Coding View of IPFilterExample.java
import
import
import
import
import
java.io.*;
java.util.*;
javax.servlet.*;
java.io.IOException;
java.util.StringTokenizer;
import
import
import
import
import
import
import
javax.servlet.Filter;
javax.servlet.FilterChain;
javax.servlet.FilterConfig;
javax.servlet.ServletException;
javax.servlet.ServletRequest;
javax.servlet.ServletResponse;
javax.servlet.http.HttpServletResponse;
public class IPFilterExample implements Filter{
public IPFilterExample() {}
public final static String IP = "193.168.10.146";
private FilterConfig filterConfig;
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterchain) throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<html><head><title>IP Filter Example</title></head>");
String userip = request.getRemoteAddr();
String Ht="";
HttpServletResponse httpResponse = null;
if (response instanceof HttpServletResponse){
httpResponse = (HttpServletResponse) response;
}
if (IP.equals(userip)) {
out.println("you are not allowed");
} else {
filterchain.doFilter(request, response);
Ht="Passed successfully from IP Filter";
out.println(Ht);
}
}
public void destroy() {}
public void init(FilterConfig config) throws ServletException{
this.filterConfig = config;
}
}
Coding View of CallIpFilter.jsp
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class CallIpFilter extends HttpServlet{
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException,IOException{
response.setContentType("text/html");
PrintWriter pw = response.getWriter();
pw.println("<html>");
pw.println("<head><title>IP Filter Example</title></title>");
pw.println("<body>");
pw.println("<h1>Welcome, calling servlet successful</h1>");
pw.println("</body></html>");
}
}
Coding View of web.xml
<filter>
<filter-name>IPFilterExample</filter-name>
<filter-class>IPFilterExample</filter-class>
</filter>
<filter-mapping>
<filter-name>IPFilterExample</filter-name>
<url-pattern>/CallIpFilter</url-pattern>
</filter-mapping>
<servlet>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
<servlet-name>CallIpFilter</servlet-name>
<servlet-class>CallIpFilter</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>CallIpFilter</servlet-name>
<url-pattern>/CallIpFilter</url-pattern>
</servlet-mapping>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Listeners
Servlet context listeners. These listeners are notified when the servlet context (i.e., the Web
application) is initialized and destroyed.
Servlet context attribute listeners. These listeners are notified when attributes are added to, removed
from, or replaced in the servlet context.
Session listeners. These listeners are notified when session objects are created, invalidated, or timed
out.
Session attribute listeners. These listeners are notified when attributes are added to, removed from, or
replaced in any session.
Session migration listeners. These listeners are notified when the session objects are serialized and
deserialized by the container. Usually, the serialization and deserialization of session objects occurs when
the container migrates the session objects from one machine to another.
Session object binding listeners. These listeners are notified when the implementing object is added or
removed from the session object.
Request listeners. These listeners are notified when request objects are initialized and destroyed.
Using these listeners involves six basic steps. We'll give a general outline here, then provide listenerspecific details in the following sections.
1. Implement the appropriate interface. Use ServletContextListener, ServletContextAttributeListener,
HttpSessionListener,
HttpSessionAttributeListener,
HttpSessionActivationListener,
HttpSessionBindingListener,
ServletRequestListener,
or
ServletRequestAttributeListener.
The
interfaces without the Http prefix in their name reside in the javax.servlet package and the interfaces
with the Http prefix reside in the javax.servlet.http package.
2. Implement the methods needed to respond to the events of interest. Provide empty bodies for the
other methods in the interface. For example, the ServletContextListener interface defines two
methods: contextInitialized (the Web application was just loaded and the servlet context was
initialized) and contextDestroyed (the Web application is being shut down and the servlet context is
about to be destroyed). If you wanted to define an application-wide servlet context entry, you could
provide a real implementation for contextInitialized and an empty body for contextDestroyed.
3. Obtain access to the important Web application objects. There are nine important objects that you are
likely to use in your event-handling methods: the servlet context, the name of the servlet context
attribute that changed, the value of the servlet context attribute that changed, the session object, the
name of the session attribute that changed, the value of the session attribute that changed, the
request object, the name of the request attribute that changed, and the value of the request attribute
that changed.
4. Use these objects. This process is application specific, but there are some common themes. For
example, with the servlet context, you are most likely to read initialization parameters
(getInitParameter), store data for later access (setAttribute), and read previously stored data
(getAttribute).
5. Declare the listener. You do this with the listener and listener-class elements of the general Web
application deployment descriptor (web.xml) or of a TLD file.
6. Provide any needed initialization parameters. Servlet context listeners commonly read context
initialization parameters to use as the basis of data that is made available to all servlets and JSP
pages. You use the context-param web.xml element to provide the names and values of these
initialization parameters.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Note, however, that the ServletRequestListener and the ServletRequestAttributeListener are new additions
to version 2.4 of the servlet specification. If your Web application needs to support servers compliant only
with version 2.3, you cannot use the aforementioned listeners.
Core Warning
ServletRequestListener and ServletRequestAttribute-Listener fail in servers that are
compliant only with version 2.3 of the servlet specification.
6.1. Monitoring Creation and Destruction of the Servlet Context
The ServletContextListener class responds to the initialization and destruction of the servlet context.
These events correspond to the creation and shutdown of the Web application itself. The
ServletContextListener is most commonly used to set up application-wide resources like database
connection pools and to read the initial values of application-wide data that will be used by multiple
servlets and JSP pages. Using the listener involves the following six steps.
1. Implement the ServletContextListener interface. This interface is in the javax.servlet package.
2. Implement contextInitialized and contextDestroyed. The first of these (contextInitialized) is triggered
when the Web application is first loaded and the servlet context is created. The two most common
tasks performed by this method are creating application-wide data (often by reading context
initialization parameters) and storing that data in an easily accessible location (often in attributes of
the servlet context). The second method (contextDestroyed) is triggered when the Web application is
being shut down and the servlet context is about to be destroyed. The most common task performed
by this method is the releasing of resources. For example, contextDestroyed can be used to close
database connections associated with a now-obsolete connection pool. However, because the servlet
context will be destroyed (and garbage collected if the server itself continues to execute), there is no
need to use contextDestroyed to remove normal objects from servlet context attributes.
3. Obtain a reference to the servlet context. The contextInitialized and contextDestroyed methods each
take a ServletContextEvent as an argument. The ServletContextEvent class has a getServletContext
method that returns the servlet context.
4. Use the servlet context. You read initialization parameters with getInitParameter, store data with
setAttribute, and make log file entries with log.
5. Declare the listener. Use the listener and listener-class elements to simply list the fully qualified name
of the listener class, as shown here:
<listener>
<listener-class>somePackage.SomeListener</listener-class>
</listener>
For now, assume that this declaration goes in the web.xml file. However, keep in mind that if you
package listeners with tag libraries, you can use the identical declaration within the TLD file of the tag
library. This technique is discussed in Section 6.5 (Packaging Listeners with Tag Libraries).
6. Provide any needed initialization parameters. Once you have a reference to the servlet context (see
Step 3), you can use the getInitParameter method to read context initialization parameters as the
basis of data that will be made available to all servlets and JSP pages. You use the context-param
web.xml element to provide the names and values of these initialization parameters, as follows:
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
<context-param>
<param-name>name</param-name>
<param-value>value</param-value>
</context-param>
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
What is Request Dispatcher?
Request dispatcher is used to transfer the value attributes to servlets and jsps.
RequestDispatcher is used to connect to another webresource with in the same context.
RequestDispatcher is an interface,In a web application having multiple webcomponents to handle a
single request at time we go for RequestDispatcher.
When you want send your request to another servlet/jsp from your servlet, we can use
RequestDispatcher.
There are two ways to get reference of RequestDispatcher.
1. If you get requestdispatcher reference from ServletContext, you have to specify the absolute url as
argument in getRequestDispatcher method like below.
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher("/my_other_app/servlet/SomeServlet");
dispatcher.forward(request, response);
2. If you get requestdispatcher reference from ServletRequeset, you have to specify the relative url as
argument in getRequestDispatcher method like below.
RequestDispatcher dispatcher = request.getRequestDispatcher("SomeServlet");
dispatcher.forward(request, response);
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
JSTL
The difference between javabean and java custom tags was that, though both made use of java
classes, tags can be used by non-programmers also without knowledge of Java programming, just as
they would use html tags
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
What is new in Servlet 3.0?
Web framework pluggability
Servlet API is the building block of the Java web applications. Almost all the java web application
frameworks build on top of the Servlet API. Examples are Spring MVC, Struts, Struts 2, Stripes, and Rife
etc. In order to hook this frameworks into your web application, you either declare a filter or a servlet into
your web application and map URL patterns to that servlet/filter. There was no way that you can just put
the jar file into web application lib directory and ready to go.
Annotations
With servlet 3.0, web.xml deployment descriptor is totally optional. Servlets, Filters, Listeners, Init
parameters can be defined using annotations. Deployment descriptor can be used to override the
configuration. For example, you can define a servlet using @WebServlet annotation and put into WEBINF/classes directory. The servlet does not need to be defined into web.xml, at run time container will
process classes in WEB-INF/classes and lib directory and identify it based on the annotation.
@WebServlet
This annotation is used to define a Servlet component in a web application and defines the metadata
about the servlet being declared. Read this tutorial on how to define servlet using @webServlet annotation
Classes annotated with @WebServlet annotation must extend javax.servlet.http.HttpServlet class.
Example
@WebServlet(asyncSupported = true, name = "asyncServlet", urlPatterns = { "/async" })
public class AsyncServletExample extends HttpServlet {
@WebFilter
This
annotation
is
used
to
define
a
filter
in
web
application.
The classes annotated with @WebFilter annotation must implement javax.servlet.Filter interface.
Example
@WebFilter(filterName="samplefilter", urlPatterns={"/foo/*", "/bar"})
public class SampleFilter implements Filter {
@WebInitParam
This annotation is used to specify any init parameters that must be passed to the Servlet or the Filter.
Example
@WebInitParam(name="param1", value="foo")
@WebListner
This annotation is used to define a listener. Any type of listener like ServletContexListner,
ServletRequestListner or HttpSessionListner classes can be defined using this annotation.
Example
@WebListener()
public class SampleContextListner extends ServletContextListner {
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
@MultipartConfig
Servlet 3.0 specification comes with the built in file upload support. This annotation, when specified on a
Servlet, indicates that the request it expects is of type mime/multipart. The HttpServletRequest object of
the corresponding servlet makes available the mime attachments via the getParts and getPart methods to
iterate over the various mime attachments.
The @MultipartConfig annotation can be used to specify the location where the files can be stored,
maximum size of the file being uploaded, maximum request size and the size threshold after which the file
will be written to the disk.
There is any equivalent <multipart-config> element in web.xml that can be used for the same purpose.
File upload
Up to now Servlet API did not provide any built in support for handling file upload. we used various open
source libraries like Commons file upload and COS multipart parser. However supporting file upload is so
common requirement for any web application that Servlet 3.0 Specification supports it out of the box. Web
container itself can parse the multipart request and make mime attachments available through
HttpServletRequest object.
Two new methods have been introduced to HttpServletRequest interface
public Collection<Part> getParts()
public Part getPart(String name).
Each part provides access to the headers, content type related with it and also the content via the
getInputStream method.
The HTML form must specify multipart/form-data as encoding type and Servlet should be either annotated
with @MultiPartConfig or configured with element in deployment descriptor.
Modularization of web.xml
The annotations make the web.xml deployment descriptor optional, However web.xml can be used to
override the configuration values defined by the annotations. Currently before Servlet 3.0 specification
web.xml is a big fat file with all the configuration for entire application. However Servlet 3.0 introduces
notion of deployment descriptor fragments. The web.xml can be divided into parts called fragments and
bundled in jar file. The fragments must be located into META-INF directory of the jar file.
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. 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
Asynchronous Servlets and comet support.
Servlet 3.0 makes developing Comet applications very easier. If you don’t know what is comet, read this
Wikipedia article http://en.wikipedia.org/wiki/Comet_%28programming%29 Some time comet is referred
as reverse Ajax also.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Servlet 3.0 added new methods into HttpServletRequest class to support the asynchronous request
processing and response generation.
public AsyncContext startAsync(ServletRequest req, ServletResponse res)
This method puts the request into asynchronous mode and initializes it’s AsyncContext with the given
request and response objects.
It was just the basic introduction of the new features of servlet 3.0 specification. A lot more interesting
stuff is yet to come. Next,in this series, I will write tutorials on each of the new features mentioned above.
Ease of Development
Ease of development is one of the key success mantras of any technology. The Servlet 3.0 API focuses on
ease of development by making use of JSR 175 annotations to enable declarative-style programming. This
means that you can swiftly develop a servlet or a filter class by simply annotating the class with
appropriate annotations like @Servlet or @ServletFilter. Annotations not only make the coding of servlet,
filter, and listener classes easier, but also make deployment descriptors optional for a web application,
even though the application archive may have servlet, filter, or context listener classes. The web container
is responsible for processing the annotations located in classes in the WEB-INF/classes directory, in a .jar
file located in the WEB-INF/lib directory, or in classes found elsewhere in the application's classpath.
Annotations Vs. Deployment Descriptor
It is interesting to note that the deployment descriptor takes precedence over annotations. In other
words, the deployment descriptor overrides configuration information specified through the annotation
mechanism. Version 3.0 of the web deployment descriptor contains a new attribute called metadatacomplete on the web-app element. This attribute defines whether the web descriptor is complete, or
whether the class files of the web application should be examined for annotations that specify deployment
information. If the attribute is set to true, the deployment tool must ignore any servlet annotations
present in the class files and use only the configuration details mentioned in the descriptor. Otherwise, if
the value is not specified or set to false, the container must scan all class files of the application for
annotations. This provides a way to enable or disable scanning of the annotation and its processing during
the startup of the application.
All annotations introduced in Servlet 3.0 can be found under the packages javax.servlet.http.annotation
and javax.servlet.http.annotation.jaxrs. The following section explains the complete set of annotations in
Servlet 3.0 :
@Servlet:
javax.servlet.http.annotation.Servlet is a class-level annotation that affirms the annotated class as a
servlet and holds metadata about the declared servlet. The urlMappings attribute is a mandatory attribute
of @Servlet that specifies the URL pattern that invokes this servlet. When a request arrives, the container
matches the URL in the request with the servlet's urlMappings and if the URL pattern matches, the
corresponding servlet will be invoked to serve the request. All other attributes of this annotation are
optional, with reasonable defaults. There must be a method annotated with any one of the HttpMethod
annotations like GET, PUT, POST, HEAD, or DELETE in the servlet class. These methods should take the
HttpServletRequest and HttpServletResponse as method parameters. Version 3.0 servlets can be
implemented as Plain Old Java Objects (POJOs) as opposed to previous versions; i.e., servlets no longer
have to extend any of the basic servlet implementation classes like HTTPServlet or GenericServlet.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
For comparison, a code snippet for writing a Java servlet using the old Servlet 2.5 API is shown below. In
Servlet 2.5, the web container will initialize the servlet only if you configure the details of the servlet in
the deployment descriptor.
public class MyServlet extends HttpServlet {
public void doGet (HttpServletRequest req,
HttpServletResponse res) {
....
}
}
Deployment descriptor (web.xml)
<web-app>
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>samples.MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/MyApp</url-pattern>
</servlet-mapping>
...
</web-app>
Here is the much simplified version written to the Servlet 3.0 API. As MyServlet is annotated as a servlet
using the @Servlet annotation, it gets initialized during the startup of the web container. Note that the
deployment descriptor is optional in this case.
@Servlet(urlMappings={"/MyApp"})
public class MyServlet {
@GET
public void handleGet(HttpServletRequest req,
HttpServletResponse res) {
....
}
}
@ServletFilter and @FilterMapping:
You
can
easily
create
a
servlet
filter
by
annotating
the
filter
class
with
the
javax.servlet.http.annotation.ServletFilter annotation. This annotation encloses metadata about the filter
being declared. It is also mandatory to have the @FilterMapping annotation on the filter class. The
@FilterMapping annotation defines the URL pattern for the filter. All other attributes of @ServletFilter are
optional, with reasonable defaults. The v3.0 filter classes will now look as POJO classes and there will be
no Filter interface or no-argument public constructor required for these classes. Given below is the code
snippet of a filter class using the Servlet v2.5 API:
public class MyFilter implements Filter {
public void doFilter(ServletRequest req,
ServletResponse res,
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
FilterChain chain)
throws IOException, ServletException {
......
}
}
Deployment descriptor (web.xml)
<web-app>
<filter>
<filter-name>My Filter</filter-name>
<filter-class>samples.MyFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>My Filter</filter-name>
<url-pattern>/foo</url-pattern>
</filter-mapping>
...
</web-app>
A sample filter class written using Servlet 3.0 is shown below. The container marks MyFilter as a filter
class, as it is annotated with ServletFilter. MyFilter intercepts all incoming requests whose URL matches
the pattern /foo. Servlet 3.0 makes the deployment descriptor optional for filter configurations.
@ServletFilter
@FilterMapping("/foo")
public class MyFilter {
public void doFilter(HttpServletRequest req,
HttpServletResponse res) {
.....
}
}
@InitParam:
This annotation can be used to define any initialization parameters that must be passed to the servlet or
filter classes. It is an attribute of the @Servlet and @ServletFilter annotation. The following code sample
explains how to pass an initialization parameter named lang, having the value english, to a servlet class.
@Servlet(urlMappings={"/MyApp"}, initParams ={@InitParam(name="lang", value="english")})
public class MyServlet {
@GET
public void handleGet(HttpServletRequest req,
HttpServletResponse res) {
....
}
}
@ServletContextListener:
The javax.servlet.http.annotation.ServletContextListener annotation declares the class as a servlet context
listener. The context listener receives notifications when the web container creates or destroys the
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
ServletContext. The context listener will be a POJO class, and does not have to implement the
ServletContextListener interface. A listener class written using the Servlet 2.5 API is shown below. The
container will recognize the listener class if and only if you configure its details in deployment descriptor.
public class MyListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
}
.....
}
Deployment Descriptor (web.xml)
<web-app>
<listener>
<listener-class>samples.MyListener</listener-class>
</listener>
....
</web-app>
A much simplified listener class using the Servlet 3.0 API is shown below.
@ServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
}
.....
}
Deployment Descriptor (web.xml)
Pluggability and Extensibility
Nowadays, web frameworks such as Struts, JSF, and Spring are becoming widely accepted and
established techniques for building web applications. Integrating these frameworks into a web application
is not so easy, as it involves assimilating different pieces together and then editing a single descriptor file
that describes how all of these pieces fit together. Most of these frameworks mandate that you configure
the details of the framework like servlet classes (typically a Controller Servlet), filter classes, or listener
classes in your application's deployment descriptor file. The main reason for this configuration requisite is
that today's web applications support only a single monolithic deployment descriptor wherein we define all
deployment information. When the size of the application increases, the dependency on external
frameworks may also increase, resulting in complex deployment descriptor files. As you probably know,
maintenance of complex descriptors is always a hassle.
In order to resolve these issues, one of Servlet 3.0's most significant concepts is the idea of web
fragments or modular web.xml. The web fragment is a logical partitioning of a web application into
elements like servlet, servlet-mapping, servlet-filter, filter-mapping, servlet-listener, and their child
elements. The framework developers can leverage this feature to define their own web fragments that
reside within the framework, and developers can plug in more and more frameworks by just including the
library files in the application's classpath, without modifying the existing deployment descriptor. In short,
this feature is aimed at having zero configuration when working with frameworks or libraries.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
The deployment descriptor has been changed to include a new element called <web-fragment>, which
holds the details of a web fragment. If the fragment is packaged as a .jar file and has metadata
information in the form of a deployment descriptor, then the web.xml file must be included under the
META-INF directory of the .jar file. At deployment time, the container scans the application's classpath and
discovers all web fragments and processes them. The metadata-complete flag discussed earlier controls
the scanning of web fragments during the startup of the application. A sample web fragment is shown
below:
<web-fragment>
<servlet>
<servlet-name>myservlet</servlet-name>
<servlet-class>samples.MyServlet</servlet-class>
</servlet>
<listener>
<listener-class>samples.MyListener</listener-class>
</listener>
</web-fragment>
To provide enhanced pluggability, Servlet 3.0 provides much-needed support for the programmatic
addition of servlets and filter classes with the help of new APIs added to ServletContext. These new APIs
allows you to declare servlets, filter classes, and their URL mappings programmatically. These classes get
initialized during application startup time or runtime. Most importantly, you can call these APIs only from
the contextInitialized method of ServletContext. Refer to the Servlet 3.0 API docs for more details of these
APIs. A code sample for programmatically adding a servlet and a filter class is shown below:
@ServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
//Declare servlet and servlet mapping
sc.addServlet("myServlet", "Sample servlet", "samples.MyServlet", null, -1);
sc.addServletMapping("myServlet", new String[] {"/urlpattern/*"});
//Declare filter and filter mapping
sc.addFilter("myFilter", "Sample Filter", " samples.MyFilter", null);
sc.addFilterMapping("myFilter", new String[] {"/urlpattern/*"}, "myServlet",
DispatcherType.REQUEST, false);
}
}
Asynchronous Support
All of us have probably had deal with slow-serving servlets, particularly servlets that have to wait for a
response from a web service, a JDBC connection, a JMS message, and so on. In the current scenario, the
servlet has to wait for all long-running processes to complete before generating the response, resulting in
inefficient blocking operations that consume a thread or other limited resources of the container. Another
adverse effect is that in case of a JDBC connection, for example, the database may have many blocking
threads waiting for access. This kind of a scenario will ultimately lead to thread starvation and poor quality
of service for the entire web container.
In order to overcome the above-mentioned shortcomings, Servlet 3.0 adds support for suspending and
resuming request processing, which enables the servlet to service a request in an asynchronous, non-
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
blocking fashion (this is the Comet style of programming). When a request is suspended, the thread
handling the request will return to the container without generating any response and gets ready to
perform other tasks. The resume method on the request resumes the request processing. Whenever the
requested resource becomes available, the thread handling that event resumes the suspended request
and proceeds to generate the response. Listed below are some of the capabilities of asynchronous
servlets:
 The ability to receive data from a client without blocking even if the data is slow arriving (nonblocking input).
 The ability to send data to a client without blocking, even if the client or network is slow (nonblocking output).
 The ability to handle delayed requests. Delayed request handling is useful if a remote/slow
resource must be obtained before servicing the request or if access to a specific resource needs to
be throttled to prevent too many simultaneous accesses.
 The ability to handle delayed response close; i.e., the response will be held open to allow additional
data to be sent when asynchronous events occur.
 The ability to notify blocking or non-blocking events.
A set of new APIs are added to ServletRequest and ServletResponse for suspending, resuming, and
querying for the status of the request and enabling disabling and querying the status of the response. The
notification events for the resume, suspend, and complete methods of request are available for developers
through the requestSuspended(), requestResumed() and requestCompleted() methods, respectively. Refer
to the Servlet 3.0 API for detailed information about these methods. The sequence of events involved in
fetching data from a remote web service using asynchronous servlets is illustrated in Figure 1.
Figure 1. Request handling using an asynchronous servlet
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Security
This topic is not included in the early draft of the 3.0 specification, as it is still undergoing discussions
within the expert group. However, the proposal recommends providing the ability to log in and log out
programmatically. New APIs will be added to HTTPServletRequest to enable this. The login method of
HTTPServletRequest will allow the application or framework to force a container-mediated authentication.
The logout method of HTTPServletRequest and HTTPSession allows an application to reset the
authentication state of the request.
Other Miscellaneous Changes
Listed below are some of the enhancements made to the existing APIs for easy data retrieval and better
developer experience.
HttpOnly Cookies: The Servlet 3.0 specification allows cookies to be marked as HttpOnly cookies.
HttpOnly cookies are not exposed to client-side scripting code, thereby preventing certain kinds of crosssite scripting attacks. Most modern browsers support this feature. Listed below are the methods added to
the Cookie class to support HTTPOnly cookies:
void setHttpOnly(boolean isHttpOnly)
boolean isHttpOnly()
API changes: The following new convenience methods are added to ServletRequest to easily get
ServletResponse and ServletContext instances associated with a request object.
ServletResponse getServletResponse()
ServletContext getServletContext()
The Roadmap
The early draft review of the 3.0 specification was completed in June 2008. As Servlet 3.0 is targeted for
the Java EE 6 platform and higher, the proposed final release of the specification is also aligned with the
release of Java EE 6. However, the early bits of the specification will be made available through
GlassFish, which is the reference implementation for Java EE. The reference implementation of Servlet
3.0 is expected to be integrated into version 3 of GlassFish.
There are changes happening around the review draft of JSR, and new proposals are coming into the
picture to address suggestions and feedback from the community. The key changes in the new proposal
are listed below:
 @Servlet is renamed to @WebServlet and @ServletContextListener to @WebServletContextListener
.
 The new proposal suggests that @WebServlet must extend the HTTPServlet class. Therefore,
servlet classes might not be POJO classes, as described earlier.
 Similarly, the @ServletFilter class and @WebServletContextListener classes need to implement the
Filter and ServletContextListener interfaces, respectively.
 Providing an option for enabling and disabling a Servlet.
See the updated proposal provided in the Resources section of this article for more details. Also note that
these new features are subject to change, depending upon the final approval of this proposal.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Struts
Apache Struts is a free open-source framework for creating Java web applications.
Web applications differ from conventional websites in that web applications can create a dynamic
response. Many websites deliver only static pages. A web application can interact with databases and
business logic engines to customize a response.
Web applications based on JavaServer Pages sometimes commingle database code, page
design code, and control flow code. In practice, we find that unless these concerns are
separated, larger applications become difficult to maintain.
One way to separate concerns in a software application is to use a Model-View-Controller (MVC)
architecture. The Model represents the business or database code, the View represents the page design
code, and the Controller represents the navigational code. The Struts framework is designed to help
developers create web applications that utilize a MVC architecture.
The framework provides three key components:
A "request" handler provided by the application developer that is mapped to a standard URI.
A "response" handler that transfers control to another resource which completes the response.
A tag library that helps developers create interactive form-based applications with server pages.
What is Model-View-Controller (MVC) Architecture?
Model-View-Controller architecture is all about dividing application components into three different
categories Model, View and the Controller.
Components of the MVC architecture has unique responsibility and each component is independent of the
other component. Changes in one component will have no or less impact on other component.
Responsibilities of the components are: - Model: Model is responsible for providing the data from the database and saving the data into the data
store. All the business logic are implemented in the Model. Data entered by the user through View are
check in the model before saving into the database. Data access, Data validation and the data saving logic
are part of Model.
- View: View represents the user view of the application and is responsible for taking the input from the
user, dispatching the request to the controller and then receiving response from the controller and
displaying the result to the user. HTML, JSPs, Custom Tag Libraries and Resources files are the part of
view component.
- Controller: Controller is intermediary between Model and View. Controller is responsible for receiving
the request from client. Once request is received from client it executes the appropriate business logic
from the Model and then produce the output to the user using the View component. ActionServlet, Action,
ActionForm and struts-config.xml are the part of Controller.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
--
MVC Architecture
The main aim of the MVC architecture is to separate the business logic and application data from the
presentation data to the user.
Here are the reasons why we should use the MVC design pattern.
1. They are resuable : When the problems recurs, there is no need to invent a new solution, we just
have to follow the pattern and adapt it as necessary.
2. They are expressive: By using the MVC design pattern our application becomes more expressive.
1). Model: The model object knows about all the data that need to be displayed. It is model who is aware
about all the operations that can be applied to transform that object. It only represents the data of an
application. The model represents enterprise data and the business rules that govern access to and
updates of this data. Model is not aware about the presentation data and how that data will be displayed
to the browser.
2). View : The view represents the presentation of the application. The view object refers to the model. It
uses the query methods of the model to obtain the contents and renders it. The view is not dependent on
the application logic. It remains same if there is any modification in the business logic. In other words, we
can say that it is the responsibility of the of the view's to maintain the consistency in its presentation
when the model changes.
3). Controller: Whenever the user sends a request for something then it always go through the
controller. The controller is responsible for intercepting the requests from view and passes it to the model
for the appropriate action. After the action has been taken on the data, the controller is responsible for
directing the appropriate view to the user. In GUIs, the views and the controllers often work very closely
together.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Overview of the Struts Framework
The Struts framework is composed of approximately 300 classes and interfaces which are
organized in about 12 top level packages.
Along with the utility and helper classes framework also provides the classes and interfaces for working
with controller and presentation by the help of the custom tag libraries.
It is entirely on to us which model we want to choose. The view of the Struts architecture is given below:
The Struts Controller Components
Whenever a user request for something, then the request is handled by the Struts Action
Servlet.
When the ActionServlet receives the request, it intercepts the URL and based on the Struts
Configuration files, it gives the handling of the request to the Action class. Action class is a
part of the controller and is responsible for communicating with the model layer.
The Struts View Components
The view components are responsible for presenting information to the users and accepting
the input from them. They are responsible for displaying the information provided by the
model components.
Mostly we use the Java Server Pages (JSP) for the view presentation. To extend the
capability of the view we can use the Custom tags, java script etc.
The Struts model component
The model components provides a model of the business logic behind a Struts program.
It provides interfaces to databases or back- ends systems. Model components are generally
a java class. There is not any such defined format for a Model component, so it is possible
for us to reuse Javacode which are written for other projects. We should choose the model
according to our client requirement.
How Struts Works
The basic purpose of the Java Servlets in struts is to handle requests made by the client or by web
browsers. In struts JavaServerPages (JSP) are used to design the dynamic web pages. In struts, servlets
helps to route request which has been made by the web browsers to the appropriate ServerPage. The use
of servlet as a router helps to make the web applications easier to design, create, and maintain. Struts is
purely based on the Model- View- Contoller (MVC) design pattern. It is one of the best and most well
developed design patterns in use. By using the MVC architecture we break the processing in three sections
named Model, the View, and the Controller. Below we are describing the working of struts.
1. As we all are well aware of the fact that each application we develop has a deployment descriptor
i.e. WEB-INF/web.xml. This is the file which the container reads. This file has all the
configuration information which we have defined for our web application. The configuration
information includes the index file, the default welcome page, the mapping of our servlets including
path and the extension name, any init parameters, information related to the context elements.
In the file WEB-INF/web.xml of struts application we need to configure the Struts ActionServlet
which handles all the request made by the web browsers to a given mapping. ActionServlet is the
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
central component of the Struts controller. This servlet extends the HttpServlet. This servlet
basically performs two important things. First is : When the container gets start, it reads the
Struts Configuration files and loads it into memory in the init() method. You will know more about
the Struts Configuration files below. Second point is: It intercepts the HTTP request in the
doGet() and doPost() method and handles it appropriately.
2. In struts application we have another xml file which is a Struts configuration file named as
struts.config.xml. The name of this file can be changed. The name of the struts configuration file
can be configured in the web.xml file. This file is placed under the WEB-INF directory of the web
application. It is an XML document that describes all or part of Struts application. This file has all
the information about many types of Struts resources and configures their interaction. This file is
used to associate paths with the controller components of your application., known as Action
classes like <action path ="/login" type = "LoginAction">. This tag tells the Struts
ActionServlet that whenever the incoming request is http://myhost/myapp/login.do, then it
must invoke the controller component LoginAction. Above, you can see that we have written .do
in the URL. This mapping is done to tell the web application that whenever a request is received
with
the
.do
extension
then
it
should
be
appended
to
the
URL.
3. For each action we also have to configure Struts with the names of the resulting pages that will be
shown as a result of that action. In our application there can be more than one view which depends
on the result of an action. One can be for a success and the other for the failure. If the result
action is "success" then the action tells the ActionServlet that the action has been successfully
accomplished or vice- versa. The struts knows how to forward the specific page to the concerned
destination. The model which we want to use is entirely to you, the model is called from within the
controller components.
4. Action can also get associate with a JavaBean in our Struts configuration file. Java bean is nothing
but a class having getter and setter methods that can be used to communicate between the view
and the controller layer. These java beans are validated by invoking the validate() method on the
ActionForm by the help of the Struts system. The client sends the request by the normal form
submission by using Get or Post method, and the Struts system updates that data in the Bean
before calling the controller components.
5. The view we use in the struts can be either Jsp page, Velocity templates, XSLT pages etc. In struts
there are set of JSP tags which has been bundled with the struts distribution, but it is not
mandatory to use only Jsp tags, even plain HTML files can be used within our Struts application but
the disadvantage of using the html is that it can't take the full advantage of all the dynamic
features provided in the struts framework.
The framework includes a set of custom tag libraries that facilitate in creating the user interfaces
that can interact gracefully with ActionForm beans. The struts Jsp taglibs has a number of generic
and struts specific tags tags which helps you to use dynamic data in your view. These tags helps us
to interact with your controller without writing much java code inside your jsp. These tags are used
create forms, internally forward to other pages by interacting with the bean and helps us to invoke
other actions of the web application.
There are many tags provided to you in the struts frameworks which helps you in sending error
messages, internationalization etc.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
Note: The points we have described above will be in effect if and only if when the ActionServlet is handling
the request. When the request is submitted to the container which call the ActionServlet, make sure that
the extension of the file which we want to access should have the extension .do.
Struts working:
Process flow:
web.xml : Whenever the container gets start up the first work it does is to check the web.xml file and
determine what struts action Servlets exist. The container is responsible for mapping all the file request to
the correct action Servlet.
A Request : This is the second step performed by the container after checking the web.xml file. In this
the user submits a form within a browser and the request is intercepted by the controller.
The Controller : This is the heart of the container. Most Struts application will have only one controller
that is ActionServlet which is responsible for directing several Actions. The controller determines what
action is required and sends the information to be processed by an action Bean. The key advantage of
having a controller is its ability to control the flow of logic through the highly controlled, centralized
points.
www.shyamsir.com ,9374928879 , [email protected]
Aspiration- Beyond Expectation- 9374928879
struts.config.xml : Struts has a configuration file to store mappings of actions. By using this file there is
no need to hard code the module which will be called within a component. The one more responsibility of
the controller is to check the struts.config.xml file to determine which module to be called upon an action
request. Struts only reads the struts.config.xml file upon start up.
Model : The model is basically a business logic part which takes the response from the user and stores
the result for the duration of the process. This is a great place to perform the preprocessing of the data
received from request. It is possible to reuse the same model for many page requests. Struts provides the
ActionForm and the Action classes which can be extended to create the model objects.
View : The view in struts framework is mainly a jsp page which is responsible for producing the output to
the user.
Struts tag libraries : These are struts components helps us to integrate the struts framework within the
project's logic. These struts tag libraries are used within the JSP page. This means that the controller and
the model part can't make use of the tag library but instead use the struts class library for strut process
control.
Property file : It is used to store the messages that an object or page can use. Properties files can be
used to store the titles and other string data. We can create many property files to handle different
languages.
Business objects : It is the place where the rules of the actual project exists. These are the modules
which just regulate the day- to- day site activities.
The Response : This is the output of the View JSP object.
www.shyamsir.com ,9374928879 , [email protected]