Unit III

Chapter 1 :Java Servlets:

Java servlets allow users to run Java code on the server and send HTML pages to a browser.
The Java Servlet API allows a software developer to add dynamic content to a web server using the Java platform.
The generated content is commonly HTML, but may be other data such as XML.

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 theCGI 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

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 callsdestroy 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 <minOccurs> 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 asubdirectory 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 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 Other Web servers may have slightly different conventions on where to install servlets and how to invoke them. Most serveralso let you define aliases for servlets, so that a servlet can be invoked via 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 Hello 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("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +
"Transitional//EN\">\n" +
"<HTML>\n" +
"<HEAD<TITLE&ht;Hello WWW</TITLE</HEAD>\n" +
"<BODY>\n" +
"<H1>Hello WWW</H1>\n" +
"</BODY</HTML>");
}
}