Servlet Technologies

The servlet classes all exist under the javax.servlet package, part of a standard J2EE distribution. For WebLogic 7.0 this package is in the weblogic.jar file. The servlet class hierarchy is straightforward having just three main classes or interfaces. Figure 17.1 shows the hierarchy and the methods within the classes and interfaces.

Figure 17.1. The Servlet class hierarchy through the HttpServlet class.

The Servlet API ”Commonly Used Methods

The most common way to use the servlet package is by extending HttpServlet . You then override one or more of the following methods as needed by your application.

Note

Commonly a HttpServlet only overrides init() , destroy() , and either doPost() or doGet() : If you have one servlet that is handling multiple HTTP actions (such as GET and POST), you may want to consider separating the functionality of the servlet into multiple different servlets. Alternatively, you should look closely at how the servlet is being used. Is there really a need for both a doPost() and a doGet() method? Often you just want one or the other.

• init() ” Called once when a servlet is initialized . It is used to initialize any variables in the servlet that will be used by other methods. Additionally, this is usually the place to read any servlet configuration information. We will examine how to do that later.

• service() ” Called by the J2EE server when a request directed at the servlet is received. This allows the servlet to respond to the request. When used in an HttpServlet , the service() method automatically calls the appropriate service method (such as doGet() ) depending on the type of HTTP request received. As HttpServlet defines methods for all of the HTTP actions, you commonly don't override this method.

  Tip

  If your application requires that multiple service methods do the same thing it is better to have them each call a common method rather than override this method. Different servlet containers may do bookkeeping or other work within the service() method and, by overriding it, you lose some of that functionality.

  
  

• destroy() ” Called when a servlet is being taken from the J2EE server. This can happen automatically if the server chooses or it can happen because of an administrative user removing the servlet manually. The server may choose to remove the servlet for a variety of reasons including lack of use of the servlet (that is, no clients are requesting it and haven't for a long time) or to try to recover memory.

• doGet() ” Called for HTTP GET messages. This is the most common form of HTTP requests . HTTP GET requests are sent, for example, from a browser requesting a particular URL.

• doPost() ” Handles HTTP POST messages. A message of this type is commonly sent from an HTML form. Additionally, Web services often use the POST method to communicate with a service provider (see Chapter 29, "Web Services and the WebLogic Platform," for more information).

The Servlet Container

Servlets are executed in a servlet container . A servlet container manages the life cycle of the servlet from its creation through its destruction. Unlike normal Java classes, you will never directly create a servlet class; it is created for you by the container on an event-driven model. This simplifies development, as the servlet author does not have to be concerned about creating and managing a servlet. Its lifecycle is taken care of by the servlet container.

The Servlet Lifecycle

When the servlet container needs to create a servlet, it first invokes the init() method on the servlet. This is where you would set up any resources that may be shared across multiple invocations of the service methods for your servlet. For example, we may initialize a database connection pool in the init() method so that other methods are able to use it.

After a servlet is initialized, it is ready to serve client requests. The servlet container automatically calls the service() method of a servlet when the URL requested matches the URL that the servlet has been registered to handle. The service() method is overridden in the HttpServlet and in turn , it calls the appropriate service method on the servlet based on the type of HTTP request. If your servlet has overridden the method, your method is called instead. As long as the servlet is still in the servlet container, the service() method will be called for each request.

Servlets can be removed for a variety of reasons:

• They can be removed manually by an administrator.

• The servlet container itself might remove them if the server is running low on resources.

• A method within the servlet throws an UnavailableException . The container has the option of removing the servlet at that time.

• They are removed when a container is shutting down.

When any of these events occur, the destroy() method is called on the servlet. This is where the servlet should release any resources it has acquired , such as database connections.

Caution

Use the init()/destroy() method pair with caution. A servlet may never be removed from the container. If the application server is not running low on memory and doesn't have a facility to remove rarely used servlets, (most don't including WebLogic 7.0), the destroy() method will never be called during normal operation. For example, if a servlet gets a database connection at init() time and does not release it until the destroy() method is called, it probably will not release the connection as long as the server is running. Database connection pooling is one way to handle this situation so that you do not take up shared resources for as long.

Servlets and Threads

An important advantage of servlets over CGI programs is that servlets are, by default, multi-threaded. This means that regardless of how many clients are attempting to access the servlet there is only one instance of the servlet class in the container. In CGI, a new process is spawned for each request. Although it is important to keep in mind threading issues when developing a servlet, the reuse of a single servlet greatly expands the scalability of a servlet-based server.

If a particular servlet cannot have multiple simultaneous accesses to it, the developer can have it implement the SingleThreadModel . This is a flag to the servlet container that tells it to serialize access to the servlet so that only one thread at a time uses it. The container is also allowed to create a pool of the single threaded servlets to help with scalability.

Why would you ever need a single-threaded servlet? The biggest reason would be if the servlet was a facade on a resource that itself could not handle multiple simultaneous client requests. For example, consider that you created a print servlet that sends whatever you have in your browser over a parallel port to a printer. In this case, you would want only one client accessing that servlet at a time. If you did not you might get parts of one printout intermixed with another. However, even this may not work as the container is allowed to create a pool of these servlets and dispatch client requests to one of the instances. The WebLogic 7.0 servlet container does just this with SingleThreadModel servlets and so you would need additional synchronization outside of the servlet itself.