Handling the Client Request:Form Data

# When the user submits form, his information is sent to the corresponding servlet file because we've set the ACTION attribute to point to the servlet.
* The form can use the GET method or POST method.
* In GET method, if the user enter the name "Inigo Montoya," the request URL is http://server:8080/servlet/Hello?name=Inigo+Montoya in the form of querystring which is visible to the user.
* The space in the name is specially encoded as a plus sign by the browser because URLs cannot contain space.
* A servlet's HttpServletRequest object gives it access to form data in its query string.

Difference between GET and POST Method
When the user enters information in a form and clicks Submit , there are two ways the information can be sent from browser to server: in the URL, or within the body of the HTTP request.

The GET method, which was used in example earlier, appends name/value pairs to the URL. Unfortunately, the length of URL is limited, so this method only works if there are only a few parameters. The URL could be truncated if the form uses a large number of parameter or if the parameters contain large amounts of data. Also, parameters passed on URL are visible in the address field of the browsernot the best place for a password to be displayed.

The alternative to the GET method is POST method. This method packages the name/value pairs inside the body of HTTP request, which makes for a cleaner URL and imposes no size limitation on the forms output. It is more secure.


Overriding service, doGet, and doPost

When a request is made, Servlet Engine hands on the incoming data to the Servlet engine, which processes the request, including form data, cookies, session information, and URL name-value pairs, into an object of type HttpServletRequest called the request object. Client metadata is encapsulated as the object of type HttpServletResponse and is called the response object. The Servlet engine passes both objects as parameters to Servlets service() method.

The default service() method in an HTTP servlets routes the request to another method based on the HTTP transfer method (POST, GET, etc.) For example, HTTP POST requests are routed to doPost() method, HTTP GET requests are routed to the doGet() method, and so on. This enables the Servlet to perform different processing on request data depending on the transfer method. Since routing takes place in service(), you generally do not override service() in an HTTP Servlet. Instead, override doGet() and/or doPost(), etc., depending on type of request you expect.

The automatic routing in an HTTP Servlets is based simply on a call to request.getMethod(), which provides the HTTP transfer method. In Servlets Engine, request data is already preprocessed into a name-value list by the time the Servlet sees the data, so you could simply override the service() method in an HTTP Servlet without losing any functionality. However, this does make the Servlet less portable, since it is now dependent on preprocessed request data.

You must override service() method (for generic Servlets) or the doGet() and/or doPost() methods (for HTTP servlets) to perform the tasks needed to answer the request. Very often, this means accessing EJBs to perform the business transactions, collating the needed information (in the request object or in a JDBC ResultSet object), and then passing the newly generated content to the JSP for formatting and delivery back to the client.

Most operations that involve the forms use either a GET or a POST operation, so for most servlets you override either doGet() or doPost(). Note that you can implement both the methods to provide for both types of input, or simply pass the request object to a central processing method


Syntax of Using doGet
public void doGet (HttpServletRequest request,HttpServletResponse response)
throws ServletException, IOException
{
...servlet code goes here...
}


Syntax of Using doPost
public void doPost (HttpServletRequest request,HttpServletResponse response)
throws ServletException, IOException
{
...servlet code goes here...
}

All of the actual request-by-request traffic in an HTTP Servlets is handled in the appropriate doOperation() method, including session management, user authentication, dispatching EJBs and JSPs, and accessing iAS features.

If you have a Servlets that you intend to also call using a RequestDispatcher method include() or forward() , be aware that the request information is no longer sent as HTTP POST, GET, etc. RequestDispatcher methods always call the service(). In other words, if a servlet overrides doPost(), it may not process anything if another servlet calls it, if the calling servlet happens to have received its data via HTTP GET. For this reason, be sure to implement routines for all possible types of the input, as explained above.

Note Arbitrary binary data, like uploaded files or images, can be problematic, since web connector translates incoming data into name-value pairs by default. You can program web connector to properly handle this kind of data and package it correctly in the request object. Accessing Parameters and Storing the Data

Incoming data is encapsulated in the request object. For HTTP servlet, the request object is of type HttpServletRequest. For generic servlet, the request object is of type ServletRequest. The request object contains all the parameters in a request, and you can also set your own values in the request. The latter is called attribute.

You can access all the parameters in an incoming request by using getParameter() method.


The following example describe the use of getParameter()
String username = request.getParameter("accountNumber");
You can also set and retrieve values in the request object using setAttribute() and getAttribute(), respectively.
The following example describe the use of setAttribute()
request.setAttribute("accountNumber", "3284766");


A complete example showing the use of doGet Method in Servlets

Step1:Make the HTML form

Step2:Make the corresponding Servlets Page
Step1:Make the HTML form
Here we are make a HTML form called form.html which is given below:


Step2:Make the corresponding Servlets Page
Here we are make a Servlets filr called name.java as we have given in the action attribute path in the form.html as name which is given below:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class name extends HttpServlet
{

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
{
res.setContentType("text/html");
PrintWriter out = res.getWriter();

String name = req.getParameter("name");
out.println("");
}

public String getServletInfo()
{
return "A servlet that knows the name of the person to whom it's" +
"saying hello";
}
}

Life Cycle of Servlets

Servlets Life Cycle
have the following Components:

* Handled by the servlets container.
* Create and initialize the servlets.
* Handle zero or more service call.
* Destroy and garbage collect the servlets.
* A single servlets instance to handle every request

The Basic Servlet Architecture or Life Cycle



Servlet container create only one instance of each servlet but the request of each user is handled with a separate thread. Each thread then calls the doGet or doPost methods. This idea is shown in the above Figure-5.

1.The init method of the servlets is called when the servlets is first created and each time the server receives a request for a servlets, the server spawns a new thread calls service method.

2.The service method check the HTTP request type (GET,SET, PUT, DELETE, etc.) and calls doGet, doPost, doPut,doDelete, etc. method as appropriate.

3.Finally, the server may decide to remove a previous loaded servlet. In this case, the server calls destroy method of the servlets.

HTTP

Before we can start writing the first Servlets, we need to know some basics of HTTP ("HyperText Transfer Protocol"), the protocol which is used by a WWW client (e.g. a browser) to send a request to a Web Server.

HTTP is the request-response oriented protocol. An HTTP request consist of a request method, a URI, header fields and a body (which can be empty). An HTTP response contain a result and again header fields and a body.

The service method of HttpServlet dispatch a request to different Java methods for different HTTP request methods. It recognize the standard HTTP/1.1 methods and should not be overridden in subclasses unless you need to implement additional methods. The recognized methods are GET, PUT,HEAD, POST, DELETE, OPTIONS and TRACE. Other methods are answered with a Bad Request HTTP error. An HTTP method XXX is dispatched to the Java method doXxx, e.g. GET -> doGet. All these method expect the parameters "(HttpServletRequest req, HttpServletResponse res)". The method doOptions and doTrace have suitable default implementations and are usually not overridden. The HEAD method (which is supposed to return the same header lines that a GET method would return, but doesn't include a body) is performed by calling the doGet and ignoring any output that is written by this method. That leaves us with the method doGet doPut doPost and doDelete whose default implementations in HttpServlet return a Bad Request HTTP error. A subclass of HttpServlet overrides one or more of these method to provide a meaningful implementation.

The request data is passed to all the methods through the first argument of type HttpServletRequest (which is a subclass of the more general ServletRequest class). The response can be created with the methods of the second argument of type HttpServletResponse (a subclass of ServletResponse).

When you request a URL in the Web Browser, the GET method is used for the request. A GET request does not have the body (i.e. the body is empty). The response should contain the body with the response data and header fields which describe the body (especially Content-Type and Content-Encoding). When you send an HTML form, either GET or POST action can be used. With the GET request the parameters are end in the URL, with a POST request they are transmited in the body. HTML editors and upload tools use PUT requests to the upload resources to a Web Server and DELETE requests to delete resources.


Servlet Types
# Classic Servlets-service() Method
# JSP's-Java Embeded in HTML Templates
# Http Servlets-doGet & doPost()
# Visual Servlets-Generated by Visual Age

Packages in Servlets
There are two types of package available in servlets which are as follows:

1.javax.servlet.*

2.javax.servlet.http.*

Interfaces in javax.servlet.*

# RequestDispatcher
# Servlet
# ServletRequest
# ServletResponse
# ServletConfig
# ServletContext
# SingleThreadModel

classes in javax.servlet.*

# GenericServlet
# ServletInputStream
# ServletOutputStream
# ServletException
# UnavailableException



Interfaces in javax.servlet.http.*

# HttpServletRequest
# HttpServletResponse
# HttpSessionBindingListener
# HttpSessionContext
# HttpSession



classes in javax.servlet.http.*

# Cookie
# HttpServlet
# HttpUtils
# HttpSessionBindingEvent



Servlet Scope Objects

The indicator specify the minimum number of time an element can occur:

There are four scope objects in servlets which enables the sharing information between web components. The scope objects and their corresponding Java classes are listed below:

# Web Context javax.servlet.ServletContext
# Request javax.servlet.HttpServletRequest
# Session javax.servlet.http.HttpSession
# Page javax.servlet.jsp.PageContext

You can get the attribute values from servlet scope objects using getAttribute method and set new values of attributes using setAttribute method. For example, you can get the client’s IP address by calling the getRemoteAddr method of HttpServletRequest class.


Following Examples prints the Hello World in the browser

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class HelloWorld extends HttpServlet
{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
PrintWriter out = response.getWriter();
out.println("Hello World");
}
}

To be a servlet, a class should extend the HttpServlet and override doGet or doPost (or both), depending on whether the data is being sent by GET or by POST. These methods take two arguments: an HttpServletRequest and an HttpServletResponse. The HttpServletRequest has methods that let you find out about the incoming information such as FORM data, HTTP request headers, and the like.

The HttpServletResponse has method that lets you specify the HTTP response line (200, 404, etc.), response headers (Content-Type, Set-Cookie, etc.), and, most importantly, lets you obtain a PrintWriter used to send output back to the client. For simple servlet, most of the effort is spent in println statements that generate the desired page. Note that doGet and doPost throw two exception, so you are required to include them in the declaration. Also note that you have to import classes in the java.io (for PrintWriter, etc.), javax.servlet (for HttpServlet, etc.), and javax.servlet.http (for HttpServletRequest and HttpServletResponse). Finally, note that doGet and doPost are called by service method, and sometimes you may want to override service directly, e.g. for a servlet that handles both GET and POST request.

Compiling and Installing the Servlet
Note that the specific details for installing servlet vary from Web server to Web server. Please refer to your Web server documentation for the definitive directions. The on-line examples are running on Java Web Server (JWS) 2.0, where servlet are expected to be in a directory called servlets in the JWS installation hierarchy. However, I placed this servlets in a separate package (hall) to avoid conflicts with other servlets on this server; you'll want to do the same if you are using a Web server that is used by other people and doesn't have a good infrastructure for the "virtual servers" to prevent these conflicts automatically. Thus, HelloWorld.java actually goes in a subdirectory called hall in the servlets directory.

Note that setup on most other servers is similar, and the servlets and JSP examples in the tutorial have also been tested using BEA WebLogic and IBM WebSphere 3.0. WebSphere has an excellent mechanism for virtual servers, and it is not necessary to use packages solely to prevent name conflicts with other users.

If you've never used the packages before, there are two main ways to compile classes that are in packages.

One way is to set your CLASSPATH to point to directory above the one actually containing your servlets. You can them compile normally from within the directory. For example, if your base directory is C:\JavaWebServer\servlets and your package name (and thus subdirectory name) is the hall, and you were on Windows, you'd do:

DOS> set CLASSPATH=C:\JavaWebServer\servlets;%CLASSPATH%
DOS> cd C:\JavaWebServer\servlets\hall
DOS> javac YourServlet.java

The first part, setting CLASSPATH, you probably want to do permanently, rather than each time you start a new DOS window. On Windows 95/98 you'd typically put the "set CLASSPATH=..." statement in your autoexec.bat file somewhere after the line that set CLASSPATH to point to servlet.jar and jsp.jar. On Windows NT, you'd go to Start menu, select Settings, select Control Panel, select System, select Environment, then enter the variable and value. Note also that if your package were of the form name1.name2.name3 rather than simply name1 as here, you'd still have the CLASSPATH point to the top-level directory of your package hierarchy (the one containing name1).

A second way to compile classes that are in packages is to go to directory above the one containing your servlets, and then do "javac directory\YourServlet.java" (Windows; note the backslash) or "javac directory/YourServlet.java" (Unix; note the forward slash). For example, suppose again that your base directory is C:\JavaWebServer\servlets and your package name (and thus subdirectory name) is hall, and you were on Windows. In that case, you'd do following:

DOS> cd C:\JavaWebServer\servlets
DOS> javac hall\YourServlet.java

Note that, on Windows, most JDK 1.1 versions of javac require a backslash, not a forward slash, after directory name. This is fixed in JDK 1.2, but since many Web servers are configured to use the JDK 1.1, many servlet authors stick with JDK 1.1 for portability.

Finally, another advanced option is to keep source code in a location distinct from the .class files, and use javac's "-d" option to install them in the location the Web server expects.

Running the Servlet
With the Java Web Server, servlet are placed in the servlets directory within the main JWS installation directory, and are invoked via http://host/servlet/ServletName. Note that the directory is servlets plural, while URL refers to servlet, singular. Since this example was placed in the hall package, it would be invoked via http://host/servlet/hall.HelloWorld. Other Web servers may have slightly different conventions on where to install servlets and how to invoke them. Most server also let you define aliases for servlets, so that a servlet can be invoked via http://host/any-path/any-file.html. The process for doing this is completely server-specific; check your server's documentation for the details.


A Servlet that Generates HTML

Most servlet generate HTML, not plain text as in the previous example. To do that, you need two additional steps: tell the browser that you're sending back HTML, and modify the println statements to build a legal Web page. The first step is done by setting Content-Type response header. In general, headers can be set via the setHeader method of HttpServletResponse, but setting the content type is such a common task that there is also a special setContentType method just for this purpose. Note that you need to set the response headers before actually returning any of the content via the PrintWriter. Here's an example:

The following program called HelloWWW.java will print Hellow WWW in the browser in the HTML format.
package hall;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class HelloWWW extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println(""Transitional//EN\">\n" +
"\n" +
"\n" +
"\n" +
"

Hello WWW

\n" +
"");
}
}

Introduction To servlets

*Servlets are Java programs running on a web server that produce results viewed remotely on web server.

*Servlets has the same purpose that PHP or CGI had in the past.

*We shall describe how Servlet works with some examples.

*You will also learn about Servlet Response and Request Model, Servlet Life Cycle, Servlet Scope Objects and Error Handling.

What are Java Servlets?

Servlets are Java technology's answer to the CGI programming. They are programs that run on a Web server and build Web page. Building Web pages on the fly is useful (and commonly done) for a number of reason:

* The Web page is based on the data submitted by the user. For example the result pages from search engines are generated this way, and programs that process orders for e-commerce sites do this as well.
* The data alsp changes frequently. For example, a weather-report or news headlines page might build the page dynamically, perhaps returning a previously built page if it is still up to the date.
* The Web page uses information from corporate databases or other such source. For example, you would use this for making a Web page at an on-line store that lists current prices and number of items in the stock.

What are the Advantage of Servlets Over "Traditional" CGI?

Java servlets are more efficient, easier to use, more powerful, more portable, and cheaper than traditional CGI and than many alternative CGI-like technology. (More importantly, servlet developers get paid more than Perl programmers :-).

* Efficient. With traditional CGI, a new process is started for the each HTTP request. If the CGI program does a relatively fast operation, the overhead of starting the process can dominate the execution of time. With servlets, the Java Virtual Machine stays up, and each request is handled by a lightweight Java thread, not the heavyweight operating system process. Similarly, in traditional CGI, if there are N simultaneous request to the same CGI program, then the for the CGI program is loaded into memory N time. With servlets, however, there are N threads but only a single copy of the servlets class. Servlets also have more alternatives than do regular CGI programs for optimizations such as caching previous computations, keeping the database connections open, and the like.

* Convenient. Hey, you already know Java. Why learn Perl too? Besides the convenience of being able to use a familiar language, servlets have an extensive infrastructure for automatically parsing and decoding the HTML form data, reading and setting HTTP headers, handling cookies, tracking sessions, and many other such utilities.

* Powerful. Java servlets let you easily do several things that are difficult or impossible with the regular CGI. For one thing, servlets can talk directly to Web server (regular CGI programs can't). This simplifies operations that need to look up images and other data stored in the standard places. Servlets can also share data among each other, making the useful things like database connection pools easy to implement. They can also maintain information from request to request, simplifying things like session tracking and caching of previous computation.

* Portable. Servlets are written in Java and followsss a well-standardized API. Consequently, servlets written for, say I-Planet Enterprise Server can alsp run virtually unchanged on Apache, Microsoft IIS, or WebStar. Servlets are supported directly or via a plugin on the almost every major Web server.

* Inexpensive. There are also a number of free or very inexpensive Web servers available that are good for "personal" use or low-volume Web sites. However, with major exception of Apache, which is free, most commercial-quality Web servers are relatively expensive. Nevertheless, once you have a Web server, no matter the cost of that server, adding servlets support to it (if it doesn't come preconfigured to support servlets) is generally free or cheap.

Advantages of servlets over CGI processes

Servlets:
# have significantly less overhead than CGI
# can inherit processing state between invocation
# can use concurrency control in the Java to share state at server.


# Servlets compared to CGI programs: are slower only when being initially it is loaded
# rather faster to run when it is loaded.


# Servlets can: open a database connection when initially it is loaded
# share open DB connection with successive invocation
# CGI programs have to renew the DB connection each time they're run.


# Servlets can: store state information in the static variables in servlet
# share access to the state data each time servlet is run
# control concurrent access to the shared state easily
# CGI programs lack the common address space to share state easily.

Disadvantages of servlets over CGI processes

# cruder model of concurrency
# less robust - share common address space in the JVM process
# more complex to handle, write and configure



What You Should Already Know?

Before you goes to this tutorial you should have a basic understanding of the following:

* HTML
* A basic understanding of JAVA

If you are going to study these subjects first, find the tutorial on our Home page