To be a servlet, a class should extend HttpServlet and override doGet or doPost, depending on whether the data is being sent by GET or by POST. If you want the same servlet to handle both GET and POST and to take the same ction for each, you can simply have doGet call doPost, or vice versa.

Both of these methods take two arguments: an HttpServletRequest and an HttpServletResponse. The HttpServletRequest has methods by which you can find out about incoming information such as form data, HTTP request headers, and the client's hostname. The HttpServletResponse lets you specify outgoing information such as HTTP status codes (200, 404, etc.), response headers (Content-Type, Set-Cookie, etc.), and, most importantly, lets you obtain a PrintWriter used to send the document content back to the client. For simple servlets, most of the effort is spent in println statements that generate the desired page. Form data, HTTP request headers, HTTP responses, and cookies will all be discussed in detail in the following chapters.

Since doGet and doPost throw two exceptions, you are required to include them in the declaration. Finally, you have to import classes in java.io (for PrintWriter, etc.), javax.servlet (for HttpServlet, etc.), and javax.servlet.http (for HttpServletRequest and HttpServletResponse). Strictly speaking, HttpServlet is not the only starting point for servlets, since servlets could, in principle, extend mail, FTP, or other types of servers. Servlets for these environments would extend a custom class derived from Generic servlet, the parent class of HttpServlet. In practice, however, servlets are used almost exclusively for servers that communicate via HTTP (i.e., Web and pplication servers), and the discussion in this book will be limited to this usage.

The Servlet Life Cycle
When the servlet is first created, its init method is invoked, so that is where you put one-time setup code. The service method (upon client requests) then calls doGet, doPost, or another doXxx method, depending on the type of HTTP request it received. Finally, when the server decides to unload a servlet,it first calls the servlet's destroy method.

The init method is called when the servlet is first created and is not called gain for each user request. So, it is used for one-time initializations, just as with the init method of applets. The servlet can be created when a user first invokes a URL corresponding to the servlet or when the server is first started, depending on how you have registered the servlet with the Web server.

There are two versions of init:

one that takes no arguments and one that takes a ServletConfig object as an argument. The first version is used when the servlet does not need to read any settings that vary from server to server. The method definition looks like this:

public void init() throws ServletException {

// Initialization code...

}

The second version of init is used when the servlet needs to read server-specific settings before it can complete the initialization. For example, the servlet might need to know about database settings, password files, server-specific performance parameters, hit count files, or serialized cookie data from previous requests. The second version of init looks like this:

public void init(ServletConfig config) throws ServletException {

super.init(config);
// Initialization code...

}

Notice two things about this code. First, the init method takes a ServletConfig as an argument. ServletConfig has a getInitParameter method with which you can look up initialization parameters associated with the servlet. Just as with the getParameter method used in the init method of applets, both the input (the parameter name) and the output (the parameter value) are

The second thing to note about the second version of init is that the first line of the method body is a call to super.init. This call is critical! The ServletConfig object is used elsewhere in the servlet, and the init method of the superclass registers it where the servlet can find it later. So, you can cause yourself huge headaches later if you omit the super.init call.

If you write an init method that takes a ServletConfig as an argument, always call super.init on the first line.

The service Method
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., as appropriate. Now, if you have a servlet that needs to handle both POST and GET requests identically, you may be tempted to override service directly as below, rather than implementing both doGet and doPost.

public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// Servlet Code

}

This is not a good idea. Instead, just have doPost call doGet (or viceversa), as below.

public void doGet(HttpServletRequest request,

HttpServletResponse response)
throws ServletException, IOException {
// Servlet Code

}

public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

doGet(request, response);

}

Although this approach takes a couple of extra lines of code, it has five advantages over directly overriding service:

1. You can add support for other services later by adding doPut, doTrace, etc., perhaps in a subclass. Overriding service directly precludes this possibility.

2. You can add support for modification dates by adding a getLastModified method. If you use doGet, the standard service method uses the getLastModified method to set Last-Modified headers and to respond properly to conditional GET requests (those containing an If-Modified-Since header).

3. You get automatic support for HEAD requests. The system just returns whatever headers and status codes doGet sets, but omits the page body. HEAD is a useful request method for custom HTTP clients. For example, link validators that check a page for dead hypertext links often use HEAD instead of GET in order to reduce server load.

4. You get automatic support for OPTIONS requests. If a doGet method exists, the standard service method answers OPTIONS requests by returning an Allow header indicating that GET, HEAD, OPTIONS, and TRACE are supported.

5. You get automatic support for TRACE requests. TRACE is a request method used for client debugging: it just returns the HTTP request headers back to the client.

The SingleThreadModel Interface
Normally, the system makes a single instance of your servlet and then createsa new thread for each user request, with multiple simultaneous threads running if a new request comes in while a previous request is still executing. This means that your doGet and doPost methods must be careful to synchronize access to fields and other shared data, since multiple threads may be trying to access the data simultaneously. See Section 7.3 (Persistent Servlet State and Auto-Reloading Pages) for more discussion of this. If you want to prevent this multithreaded access, you can have your servlet implement the SingleThreadModel interface, as below.

public class YourServlet extends HttpServletimplements SingleThreadModel {
...
}

If you implement this interface, the system guarantees that there is never more than one request thread accessing a single instance of your servlet. It does so either by queuing up all the requests and passing them one at a time to a single servlet instance, or by creating a pool of multiple instances, each of which handles one request at a time. This means that you don't have to worry about simultaneous access to regular fields (instance variables) of the servlet. You do, however, still have to synchronize access to class variables (static fields) or shared data stored outside the servlet. Synchronous access to your servlets can significantly hurt performance (latency) if your servlet is accessed extremely frequently. So think twice before using the SingleThreadModel approach.

The destroy Method
The server may decide to remove a previously loaded servlet instance, perhaps because it is explicitly asked to do so by the server administrator, or perhaps because the servlet is idle for a long time. Before it does, however, it calls the servlet's destroy method. 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. Be aware, however, that it is possible for the Web server to crash.

Example web.xml using init-param

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
<web-app>
<servlet>
<servlet-name>
ShowMsg
</servlet-name>
<servlet-class>
coreservlets.ShowMessage
</servlet-class>
<init-param>
<param-name>
message
</param-name>
<param-value>
Shibboleth
</param-value>
</init-param>
<init-param>
<param-name>
repeats
</param-name>
<param-value>
5
</param-value>
</init-param>
</servlet>
</web-app>

Example Using Conditional GET:

/** The standard service method compares this date
* against any date specified in the If-Modified-Since
* request header. If the getLastModified date is
* later, or if there is no If-Modified-Since header,
* the doGet method is called normally. But if the
* getLastModified date is the same or earlier,
* the service method sends back a 304 (Not Modified)
* response, and does <B>not</B> call doGet.
* The browser should use its cached version of
* the page in such a case.
*/
public long getLastModified(HttpServletRequest request) {
return(modTime);
}

Debugging Servlets:

• Look at generated HTML source (Can use some HTML validator).
• Return Error Pages to the client.
• start the server from command line
• look at log file.
• look at request data separately
• look at response data separately.
• stop and restart the server.

• Use web.xml servlet element to give a name to your servlet.
• Use web.xml servlet-mapping element to assign a custom URL to servlet.
• Add init-param subelements to the web.xml servlet element to assign names and values of initialization parameters.
• From with-in your sevlet's init method, call getServiceConfig to obtain a reference to ServletConfig object.
• Call getInitparameter method ServletConfig with the name of the init parameter. The return value is the value of the init parameter or null,
  If no such parameter is found in the web.xml file.

• Identifying a user during e-commerse session.
• Avoiding username and password.
• Customising a site.
• Focusing Advertising.

1. Create a cookie Object (Call cookie ctor with name and value, both are string)
2. Setting the Maximun age (setMaxAge )
3. Placing the cookie to response header (response.addCookie )

1. request.getCookies() : returns array of Cookies.
2. Loop down the array calling getName() on each one until you find the one you want.

1. Bean class must have zero argument constructor.
2. Bean Class should have no public instance variables.
3. Persistent values should be accessed through methods called getXXX and setXxx.

Q. What is the difference between the getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface and javax.servlet.ServletContext interface?

A declaration must contain at least one complete declarative statement. You can declare any number of variables or methods within one declaration tag, as long as they are separated by semicolons. The declaration must be valid in the scripting language used in the JSP file.

<%! somedeclarations %>
<%! int i = 0; %>
<%! int a, b, c; %>

What is a Scriptlet?

A scriptlet can contain any number of language statements, variable or method declarations, or expressions that are valid in the page scripting language.Within scriptlet tags, you can

1.Declare variables or methods to use later in the file (see also Declaration).

2.Write expressions valid in the page scripting language (see also Expression).

3.Use any of the JSP implicit objects or any object declared with a <jsp:useBean> tag.
You must write plain text, HTML-encoded text, or other JSP tags outside the scriptlet.

Scriptlets are executed at request time, when the JSP engine processes the client request. If the scriptlet produces output, the output is stored in the out object, from which you can display it.

What are implicit objects? List them?

Certain objects that are available for the use in JSP documents without being declared first. These objects are parsed by the JSP engine and inserted into the generated servlet. The implicit objects re listed below

• request
• response
• pageContext
• session
• application
• out
• config
• page
• exception

The different scope values for <jsp:useBean> are

http://www.javaprepare.com/scwd/quests/servlet.html

1. Difference between GET and POST

In GET your entire form submission can be encapsulated in one URL, like a hyperlink. query length is limited to 260 characters, not secure, faster, quick and easy.

In POST Your name/value pairs inside the body of the HTTP request, which makes for a cleaner URL and imposes no size limitations on the form's output. It is used to send a chunk of data to the server to be processed, more versatile, most secure.

1. What is servlet mapping?

The servlet mapping defines an association between a URL pattern and a servlet. The mapping is used to map requests to servlets.

1. What's the difference between servlets and applets?

Servlets are to servers; applets are to browsers. Unlike applets, however, servlets have no graphical user interface.