Unit III Servlet 10

3.1 Introduction of servlet: How servelet work, installation, model diagram

What are Servlets?
Java Servlets are programs that run on a Web or Application server and act as a
middle layer between a requests coming from a Web browser or other HTTP client
and databases or applications on the HTTP server.
Using Servlets, you can collect input from users through web page forms, present
records from a database or another source, and create web pages dynamically.
Java Servlets often serve the same purpose as programs implemented using the
Common Gateway Interface (CGI). But Servlets offer several advantages in
comparison with the CGI.

Performance is significantly better.

Servlets execute within the address space of a Web server. It is not

necessary to create a separate process to handle each client request.

Servlets are platform-independent because they are written in Java.

Java security manager on the server enforces a set of restrictions to protect

the resources on a server machine. So servlets are trusted.

The full functionality of the Java class libraries is available to a servlet. It can
communicate with applets, databases, or other software via the sockets and
RMI mechanisms that you have seen already.

Servlets Architecture
The following diagram shows the position of Servlets in a Web Application.

How Servlet works?

It is important to learn how servlet works for understanding the servlet well. Here,
we are going to get the internal detail about the first servlet program.
The server checks if the servlet is requested for the first time.
If yes, web container does the following tasks:

Loads the servlet class.

Instantiates the servlet class.

calls the init method passing the ServletConfig object

Else

calls the service method passing request and response objects

The web container calls the destroy method when it needs to remove the servlet
such as at time of stopping server or underlying the project.
How web container handles the servlet request?
The web container is responsible to handle the request. Let's see how it handles the
request.

maps the request with the servlet in the web.xml file.

creates request and response objects for this request

calls the service method on the thread

The public service method internally calls the protected service method

The protected service method calls the doGet method depending on the type
of request.

The doGet method generates the response and it is passed to the client.

After sending the response, the web container deletes the request and
response objects. The thread is contained in the thread pool or deleted
depends on the server implementation.

Advantage of Servlet: - There are many advantages of servlet over CGI. The
web container creates threads for handling the multiple requests to the servlet.
Threads have a lot of benefits over the Processes such as they share a common
memory area, lightweight, cost of communication between the threads are low. The
basic benefits of servlet are as follows:
1. Better performance: because it creates a thread for each request not
process.
2. Portability: because it uses java language.

3. Robust: Servlets are managed by JVM so we don't need to worry about

memory leak, garbage collection etc.
4. Secure: because it uses java language.

Setting UP
A development environment is where you would develop your Servlet, test them
and finally run them.
Like any other Java program, you need to compile a servlet by using the Java
compiler javac and after compilation the servlet application, it would be deployed
in a configured environment to test and run.
This development environment setup involves following steps:
Setting up Java Development Kit
This

step

involves

downloading

an

implementation

of

the

Java

Software

Development Kit (SDK) and setting up PATH environment variable appropriately.

You can download SDK from Oracle's Java site: Java SE Downloads.
Once you download your Java implementation, follow the given instructions to
install and configure the setup. Finally set PATH and JAVA_HOME environment
variables to refer to the directory that contains java and javac, typically
java_install_dir/bin and java_install_dir respectively.
If you are running Windows and installed the SDK in C:\jdk1.5.0_20, you would put
the following line in your C:\autoexec.bat file.
set PATH=C:\jdk1.5.0_20\bin;%PATH%
set JAVA_HOME=C:\jdk1.5.0_20
Alternatively, on Windows NT/2000/XP, you could also right-click on My Computer,
select Properties, then Advanced, then Environment Variables. Then, you would
update the PATH value and press the OK button.
On Unix (Solaris, Linux, etc.), if the SDK is installed in /usr/local/jdk1.5.0_20 and
you use the C shell, you would put the following into your .cshrc file.

setenv PATH /usr/local/jdk1.5.0_20/bin:$PATH

setenv JAVA_HOME /usr/local/jdk1.5.0_20
Alternatively, if you use an Integrated Development Environment (IDE) like Borland
JBuilder, Eclipse, IntelliJ IDEA, or Sun ONE Studio, compile and run a simple
program to confirm that the IDE knows where you installed Java.
Setting up Web Server: Tomcat
A number of Web Servers that support servlets are available in the market. Some
web servers are freely downloadable and Tomcat is one of them.
Apache Tomcat is an open source software implementation of the Java Servlet and
JavaServer Pages technologies and can act as a standalone server for testing
servlets and can be integrated with the Apache Web Server. Here are the steps to
setup Tomcat on your machine:

Download latest version of Tomcat from http://tomcat.apache.org/.

Once you downloaded the installation, unpack the binary distribution into a
convenient location. For example in C:\apache-tomcat-5.5.29 on windows,
or /usr/local/apache-tomcat-5.5.29 on Linux/Unix and create CATALINA_HOME
environment variable pointing to these locations.

Tomcat can be started by executing the following commands on windows machine:

%CATALINA_HOME%\bin\startup.bat

or

C:\apache-tomcat-5.5.29\bin\startup.bat
Tomcat can be started by executing the following commands on Unix (Solaris,
Linux, etc.) machine:
$CATALINA_HOME/bin/startup.sh

or

/usr/local/apache-tomcat-5.5.29/bin/startup.sh
After startup, the default web applications included with Tomcat will be available by
visiting http://localhost:8080/. If everything is fine then it should display
following result:

Further information about configuring and running Tomcat can be found in the
documentation

included

here,

as

well

as

on

the

Tomcat

web

site:

http://tomcat.apache.org
Tomcat can be stopped by executing the following commands on windows
machine:
C:\apache-tomcat-5.5.29\bin\shutdown
Tomcat can be stopped by executing the following commands on Unix (Solaris,
Linux, etc.) machine:
/usr/local/apache-tomcat-5.5.29/bin/shutdown.sh
Setting up CLASSPATH

Since servlets are not part of the Java Platform, Standard Edition, you must identify
the servlet classes to the compiler.
If you are running Windows, you need to put the following lines in your
C:\autoexec.bat file.
set CATALINA=C:\apache-tomcat-5.5.29
set CLASSPATH=%CATALINA%\common\lib\servlet-api.jar;%CLASSPATH%
Alternatively, on Windows NT/2000/XP, you could also right-click on My Computer,
select Properties, then Advanced, then Environment Variables. Then, you would
update the CLASSPATH value and press the OK button.
On Unix (Solaris, Linux, etc.), if you are using the C shell, you would put the
following lines into your .cshrc file.
setenv CATALINA=/usr/local/apache-tomcat-5.5.29
setenv CLASSPATH $CATALINA/common/lib/servlet-api.jar:$CLASSPATH
NOTE: Assuming that your development directory is C:\ServletDevel (Windows)
or /usr/ServletDevel (Unix) then you would need to add these directories as well in
CLASSPATH in similar way as you have added above .

3.2 Uses of servlet

3.3 Life cycle of servlet

3. Servlets Life Cycle

A servlet life cycle can be defined as the entire process from its creation till the
destruction. The following are the paths followed by a servlet
The servlet is initialized by calling the init () method.
The servlet calls service() method to process a client's request.
The servlet is terminated by calling the destroy() method.
Finally, servlet is garbage collected by the garbage collector of the JVM.
Now let us discuss the life cycle methods in detail.

The init() Method

The init method is called only once. It is called only when the servlet is created, and
not called for any user requests afterwards. So, it is used for one-time initializations,
just as with the init method of applets.
The servlet is normally created when a user first invokes a URL corresponding to the
servlet, but you can also specify that the servlet be loaded when the server is first
started.
When a user invokes a servlet, a single instance of each servlet gets created, with
each user request resulting in a new thread that is handed off to doGet or doPost as
appropriate. The init() method simply creates or loads some data that will be used
throughout the life of the servlet.
The init method definition looks like this:
public void init() throws ServletException {
// Initialization code...
}
The service() Method
The service() method is the main method to perform the actual task. The servlet
container (i.e. web server) calls the service() method to handle requests coming
from the client( browsers) and to write the formatted response back to the client.
Each time the server receives a request for a servlet, the server spawns a new
thread and calls service. The service() method checks the HTTP request type (GET,
POST, PUT, DELETE, etc.) and calls doGet, doPost, doPut, doDelete, etc. methods as
appropriate. Java Servlets
Here is the signature of this method:
public void service(ServletRequest request,
ServletResponse response)
throws ServletException, IOException{
}
The service () method is called by the container and service method invokes doGe,
doPost, doPut, doDelete, etc. methods as appropriate. So you have nothing to do
with service() method but you override either doGet() or doPost() depending on
what type of request you receive from the client.
The doGet() and doPost() are most frequently used methods with in each service
request. Here is the signature of these two methods.
The doGet() Method

A GET request results from a normal request for a URL or from an HTML form that
has no METHOD specified and it should be handled by doGet() method.
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
// Servlet code
}
The doPost() Method
A POST request results from an HTML form that specifically lists POST as the
METHOD and it should be handled by doPost() method.
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
// Servlet code
}
The destroy() Method
The destroy() method is called only once at the end of the life cycle of a servlet.
This method gives your servlet a chance to close database connections, halt
background threads, write cookie lists or hit counts to disk, and perform other such
cleanup activities.
After the destroy() method is called, the servlet object is marked for garbage
collection. The destroy method definition looks like this: Java Servlets
public void destroy() {
// Finalization code...
}

3.4 Servlet API: packages- javax.servlet and javax.servlet.http

Now that you have a basic understanding of HTTP, we can move on and talk about
the Servlet API that you'll be using to create HTTP servlets, or any kind of servlets,
for that matter. Servlets use classes and interfaces from two
packages: javax.servlet and javax.servlet.http . The javax.servlet package contains
classes to support generic, protocol-independent servlets. These classes are
extended by the classes in the javax.servlet.http package to add HTTP-specific
functionality. The top-level package name is javax instead of the familiar java, to
indicate that the Servlet API is a standard extension.

Every servlet must implement the javax.servlet.Servlet interface. Most servlets

implement it by extending one of two special classes: javax.
servlet.GenericServlet or javax.servlet.http.HttpServlet . A protocol-independent
servlet should subclass GenericServlet, while an HTTP servlet should
subclass HttpServlet, which is itself a subclass of GenericServlet with added HTTPspecific functionality.
Unlike a regular Java program, and just like an applet, a servlet does not have
a main() method. Instead, certain methods of a servlet are invoked by the server in
the process of handling requests. Each time the server dispatches a request to a
servlet, it invokes the servlet's service() method.

Interfaces in javax.servlet package

There are many interfaces in javax.servlet package. They are as follows:

1. Servlet
2. ServletRequest
3. ServletResponse
4. RequestDispatcher
5. ServletConfig
6. ServletContext
7. SingleThreadModel
8. Filter
9. FilterConfig
10.FilterChain
11.ServletRequestListener
12.ServletRequestAttributeListener
13.ServletContextListener
14.ServletContextAttributeListener
Classes in javax.servlet package
There are many classes in javax.servlet package. They are as follows:

1. GenericServlet
2. ServletInputStream
3. ServletOutputStream
4. ServletRequestWrapper
5. ServletResponseWrapper
6. ServletRequestEvent
7. ServletContextEvent
8. ServletRequestAttributeEvent
9. ServletContextAttributeEvent
10.ServletException
11.UnavailableException

Interfaces in javax.servlet.http package

There are many interfaces in javax.servlet.http package. They are as follows:
1. HttpServletRequest
2. HttpServletResponse
3. HttpSession
4. HttpSessionListener
5. HttpSessionAttributeListener
6. HttpSessionBindingListener
7. HttpSessionActivationListener
8. HttpSessionContext (deprecated now)
Classes in javax.servlet.http package
There are many classes in javax.servlet.http package. They are as follows:
1. HttpServlet
2. Cookie
3. HttpServletRequestWrapper
4. HttpServletResponseWrapper
5. HttpSessionEvent
6. HttpSessionBindingEvent

7. HttpUtils (deprecated now)

3.5 Session
Session simply means a particular interval of time.
Session Tracking is a way to maintain state (data) of an user. It is also known
as session management in servlet.
Http protocol is a stateless so we need to maintain state using session tracking
techniques. Each time user requests to the server, server treats the request as the
new request. So we need to maintain the state of an user to recognize to particular
user.
HTTP is stateless that means each request is considered as the new request. It is
shown in the figure given below:

Why use Session Tracking?

To recognize the user it is used to recognize the particular user.
Session Tracking Techniques
There are four techniques used in Session tracking:
1. Cookies
2. Hidden Form Field
3. URL Rewriting
4. HttpSession
Cookies:

A webserver can assign a unique session ID as a cookie to each web client and for
subsequent requests from the client they can be recognized using the recieved
cookie.
This may not be an effective way because many time browser does not support a
cookie, so I would not recommend to use this procedure to maintain the sessions.
Hidden Form Fields:
A web server can send a hidden HTML form field along with a unique session ID as
follows:
<input type="hidden" name="sessionid" value="12345">
This entry means that, when the form is submitted, the specified name and value
are automatically included in the GET or POST data. Each time when web browser
sends request back, then session_id value can be used to keep the track of different
web browsers.
This could be an effective way of keeping track of the session but clicking on a
regular (<A HREF...>) hypertext link does not result in a form submission, so hidden
form fields also cannot support general session tracking.
URL Rewriting:
You can append some extra data on the end of each URL that identifies the session,
and the server can associate that session identifier with data it has stored about
that session.
For example, with http://tutorialspoint.com/file.htm;sessionid=12345, the session
identifier is attached as sessionid=12345 which can be accessed at the web server
to identify the client.
URL rewriting is a better way to maintain sessions and works for the browsers when
they don't support cookies but here drawback is that you would have generate
every URL dynamically to assign a session ID though page is simple static HTML
page.
The HttpSession Object:
Apart from the above mentioned three ways, servlet provides HttpSession Interface
which provides a way to identify a user across more than one page request or visit
to a Web site and to store information about that user.
The servlet container uses this interface to create a session between an HTTP client
and an HTTP server. The session persists for a specified time period, across more
than one connection or page request from the user.

Cookies: types, advantages and disadvantages

3.6 Cookies in Servlet

A cookie is a small piece of information that is persisted between the multiple

client requests.
A cookie has a name, a single value, and optional attributes such as a comment,
path and domain qualifiers, a maximum age, and a version number.
How Cookie works
By default, each request is considered as a new request. In cookies technique, we
add cookie with response from the servlet. So cookie is stored in the cache of the
browser. After that if request is sent by the user, cookie is added with request by
default. Thus, we recognize the user as the old user.

Types of Cookie
There are 2 types of cookies in servlets.
1. Non-persistent cookie
2. Persistent cookie
Non-persistent cookie
It is valid for single session only. It is removed each time when user closes the
browser.
Persistent cookie
It is valid for multiple session . It is not removed each time when user closes the
browser. It is removed only if user logout or signout.
Advantage of Cookies
1. Simplest technique of maintaining the state.
2. Cookies are maintained at client side.
Disadvantage of Cookies
1. It will not work if cookie is disabled from the browser.

2. Only textual information can be set in Cookie object.

Note: Gmail uses cookie technique for login. If you disable the cookie,
gmail won't work.
Cookie class
javax.servlet.http.Cookie class provides the functionality of using cookies. It
provides a lot of useful methods for cookies.
Constructor of Cookie class
Constructor

Description

Cookie()

constructs a cookie.

Cookie(String name, String value)

constructs a cookie with a specified name and value

Useful Methods of Cookie class

There are given some commonly used methods of the Cookie class.
Method

Description

public void setMaxAge(int expiry)

Sets the maximum age of the cookie in seconds.

public String getName()

Returns the name of the cookie. The name cannot be changed

public String getValue()

Returns the value of the cookie.

public void setName(String name) changes the name of the cookie.

public void setValue(String value)

3.7 servlet jdbc

changes the value of the cookie.