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 MethodsThe 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.
The Servlet ContainerServlets 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 LifecycleWhen 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:
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 ThreadsAn 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. |