Home > Articles

Working with Servlets

This chapter is from the book

In yesterday's session you learned important concepts and technologies that form part of J2EE. You started the day with a brief introduction to J2EE and then moved on to understand the concepts of each of the J2EE technologies, such as Java servlets, JavaServer Pages, JDBC, JNDI, Enterprise JavaBeans, and Java Message Service API. In the final part of yesterday's session, you learned the problem statement of the Airline Ticket Booking System MVCapplication case study and then went on to design the class diagram and ER diagram for the application.

Before starting today's session, we recommend that you read Appendix B, which details the steps required to install BEA WebLogic Server 7.0, as provided in the CD-ROM. This will prepare the ground for the sample applications you will build during the next three weeks.

The next two days will cover the first server-side Java technology supported by WebLogic, the Java Servlet API 2.3 specification. You will study Java servlet concepts, the Java Servlet API, and different techniques for session handling; finally, you will write a sample Java servlet and deploy it in the WebLogic Server. In addition to the basics of Java servlets, in tomorrow's session, you will be studying the advanced concepts of Java servlets such as filters and listeners. At the end of tomorrow's session, you will be building the first element of the Airline Ticket Booking System MVC application case study, the Controller servlet.

Introduction to Servlets

A Java servlet is a server-side Java application to generate dynamic content for a Web application. Servlets are used to extend the server-side functionality of a Web server by enabling writing of powerful server-side applications. Since the Servlet API is a part of the J2EE framework, servlets are a Java extension to Web servers.

Servlets are Java components and, hence, platform-independent Java classes that are dynamically loaded by Java-enabled Web servers and application servers.

On its own, a Web server serves only static pages. This limits the usefulness of Web servers for enhancing the user experience via a browser. Consider what would happen if your favorite online shopping Web site were a set of static HTML pages. If the marketing department chose to offer a special price for a product, then their Web site administrator would have to edit the product file before you could see the price. Now, consider a scenario where the price change would have applied to a hundred products. It would be a nightmare for the Web site administrator!

To avoid these issues and keep the content of Web applications up to date, server-side Web applications are increasingly being introduced and deployed.

Servlets and CGI: A Comparison

Since dynamic content is generated by a server-side program executed by the Web server as a separate process, a consistent mechanism of interprocess communication between the Web server and the server-side program has had to be defined. This consistent interprocess communication mechanism is essentially a set of predefined environment variables that a Web server populates and that a server-side program, called a CGI program, expects. A Web server sets the values to these environment variables, which are then read by the separately spawned CGI program as input. The CGI program processes this input and returns the generated dynamic content to the Web server to be forwarded to the user's browser. CGI programs are primarily Unix shell scripts or programs written in the Perl language.

Even though CGI programs are the simplest ways to develop server-side Web applications, they have significant drawbacks. One of the major problems is the overhead for the Web server for executing the CGI programs for each browser request. The execution of a CGI program by the Web server for each browser request is essentially a new process that is spawned. This spawning of new processes per browser request adds a significant overhead to the Web server and the operating system in which the Web server is running. For a Web site with a lot of traffic, the Web server will end up giving a poor response because of this overhead. Moreover, there is a limited mechanism of communication between the CGI program and the Web server.

Java servlets address the problems associated with CGI. A servlet container provides the environment to execute Java servlets. A Web server forwards a request to execute a servlet to the servlet container. The servlet container then appropriately loads a servlet (if it is not loaded) and dispatches the request to the appropriate servlet running within the servlet container. Servlet containers that interact with Web servers are of three distinct types: in-process, out-of-process, and standalone. An in-process servlet container runs as a part of the overall Web server process. No separate process is launched to run the servlet container. WebLogic Server is a good example of an in-process servlet container. An out-of-process servlet container runs as a separate process from the Web server process. Such a servlet container is normally a third-party plug-in for Web servers. An example of this type is the JRun servlet engine. Interprocess communication between the Web server process and the servlet container process occurs using sockets. The third type of servlet container is a standalone servlet container. In this type, the servlet container is an all-inclusive application that contains the Web server within itself. Hence, no separate Web server is needed in this case. An example of this is the Tomcat servlet container. The important point to note here is that irrespective of the type of the servlet container, a servlet is not executed as a separate process but runs as a separate "thread" within the process boundaries of the servlet container. Hence, the new process overhead encountered in CGI programs is avoided.

The Java Servlet API is an extension to the standard Java packages and marks the first move of Java from the standard application domain to the server side.


Proprietary extensions to the popular Web servers such as Netscape Web Server and the Microsoft Internet Information Server (IIS) have been defined to enable integration of server-side Web applications with the respective Web server. These extensions are NSAPI and ISAPI for the Netscape and Microsoft Web servers, respectively. The problem with these extensions is that they are proprietary, thus inhibiting developers from writing Web applications compatible with both the servers.

The Java Servlet API, on the other hand, relies on the platform-independent nature of Java. Since Java servlet engines are available for both of these Web servers, as well as the Open Source Web servers (such as Apache), this extends the platform independence of Java to server independence.

WebLogic's Support for HTTP Servlets

Now that you have an idea of what Java servlets are all about, you can take a look at the support for Java servlets provided by WebLogic Server.

Figure 3.1 WebLogic Server and its components.

From Figure 3.1 you can see that WebLogic Server contains the servlet engine to support the execution and deployment of servlets. The servlet engine in WebLogic Server version 7.0 supports the Java Servlet API version 2.3 specification. Part of this support includes support of the following important features:

  • Filters—Filters are intermediate preprocessors of a servlet request and response. A filter is a Java class registered with the WebLogic Server as a "filter" for URLs or servlets. On receiving a request for the registered URLs or servlets, the server intercepts the request or response and forwards it to the filter class. The filter class preprocesses the request or response contents and passes this on to the servlet.

  • Listeners and events—Listeners are modeled on the Java AWT event listener model. Listeners are special classes registered with the WebLogic Server that are invoked on every life-cycle stage of the servlet being monitored. For example, a listener listening for the initialization event of a servlet can perform logging of the initialization stage of the servlet.

Apart from these features, the Servlet 2.3 specification has also simplified and standardized the deployment process, allowing the registering of files to be deployed in a manifest file while creating the deployment .war file.

Life Cycle of Servlets

Since servlets are special Java programs executed by the Java-enabled Web server, there is a life cycle associated with servlets. As you can see in Figure 3.2, there are three stages in the life cycle of a servlet: initialization, managing request/response, and termination.

Figure 3.2 Life cycle of a servlet.


The servlet is initialized by the WebLogic Server when the WebLogic Server is started. During initialization, any parameters required for the servlet initialization are passed to the servlet. Initialization in servlets can be performed in a declarative or programmatic fashion:

  • Declarative initialization—In declarative initialization, the initialization parameters and their values for a servlet are defined in the deployment descriptor file web.xml. The servlet can access these initialization parameters by calling the getInitParameter(String paramName) method of the GenericServlet base class.

  • Programmatic initialization—In programmatic initialization, the initialization code for the servlet is defined in the init() method. The WebLogic Server executes the init() method only once during initialization.


If you need to set any initialization parameters for your servlet, for example, opening a database connection for use in the servlet, do this in the init() method. Also, any initialization parameters or global properties for the servlet can be defined in the deployment descriptor file for the servlet (web.xml).

Manage Request and Response

Any requests received by the Web server are forwarded to the servlet to handle. The servlet contains a service() method to manage the request, process it, and send back the response. You will write your server-side application code in this method. The service() method contains a request object and response object as parameters. These are used by the servlet to process the request and send the response. The Web server packages the request data in the request object and uses the response object to send the response to the client application. The service() method is used throughout the life cycle of the servlet.


At the end of the life cycle of the servlet, the server shuts down the servlet and frees up resources. You as a developer can use the destroy() method to do any cleanup before the servlet is removed from the WebLogic Server's memory.


If you need to free up any resources, for example, closing a database connection (or any other open file such as a trace or log file) that has been used in the servlet, do this in the destroy() method.

Multithreaded and Single-Threaded Models of Servlets

Java is one of the few languages that support multithreading across different operating systems as long as the underlying operating system supports multithreading. Multithreaded support in the Java language means that you can develop pieces of code that can be executed concurrently by the Java interpreter (Java Virtual Machine, or JVM) as separate "threads" of execution within a single process. One example of writing a program with explicit separate threads of execution is using the java.lang.Thread class in the standard edition Java Development Kit (JDK). The enterprise edition of Java takes this support for multithreading further and incorporates the same multithreaded behavior in all the J2EE technologies. WebLogic Server 7 provides this support for multithreaded behavior in servlets.

What this implies is that when a Java servlet is loaded by the WebLogic Server's servlet engine, the Java servlet can potentially service concurrent user requests. The servlet container in WebLogic Server accomplishes this by creating and executing copies of a method of the servlet in separate threads. The implication for a developer is that any variables that have scope of the servlet class, that is, instance variables of the servlet, can be potentially modified by any of the different threads in which the copies of a method execute. Hence, you must be careful while designing the scope of variables for a servlet. This behavior of the servlet is called the multithreaded model and is the default behavior for all servlets.

If there are class variables that need to be kept safe in a concurrent-processing scenario, the Servlet API defines a thread-safe model called the single-threaded model. When a servlet is used in a single-threaded model, the WebLogic Server creates multiple instances of the servlet for each new user request. Once a servlet is associated with a browser, the WebLogic Server maintains this association and reuses the same servlet to process the request.

In order to make a servlet work in a single-threaded model, the servlet must implement the SingleThreadModel interface, as follows:

public class MyTestSingleThreadedServlet extends HttpServlet
                    implements SingleThreadModel

There are no methods in the SingleThreadModel interface for you to implement. Once the servlet is declared to implement the SingleThreadModel interface, the servlet container in the WebLogic Server guarantees that the service() method of the servlet is not executed concurrently by two separate threads. The servlet container ensures that concurrency is maintained by either synchronizing access to the servlet's instance or by creating a separate instance of the servlet for each new user request.


WebLogic Server provides support for defining a pool of the instances for the servlet. This pool is initialized when the servlet is initialized for the first time by the server. If the pool size is less than the average number of concurrent requests received for the servlet, the WebLogic Server increases the pool count. This setting of the pool size can be done by setting the value for the SingleThreadedServletPoolSize parameter in the WebLogic Server using the server administration console.

Flowchart for Developing Servlets

You will be following the steps listed in the flowchart in Figure 3.3 for developing your sample servlets throughout Day 3 and Day 4, "Advanced Servlet Techniques."

Figure 3.3 Flowchart for developing servlets.

In step 1, you define the requirements for your sample application. This is essentially the problem statement for developing the servlet.

In step 2, you design the static and dynamic behavior of the servlet. The static design consists of the class diagram and the package diagram for the servlet. The dynamic behavior is modeled by the sequence diagram.

In step 3, you set up the deployment environment for the servlet. Since servlets are Web applications, they are deployed in the applications directory as a separate Web application. The actual components of the Web application, including the classes, static HTML files, images, and so on, are kept in the WEB-INF directory. Apart from this, you need to have the environment consisting of the PATH and CLASSPATH variables set up in the MS-DOS prompt, where you perform the next step.

In step 4, you compile the servlet and the support classes using the javac compiler. This step assumes that the relevant CLASSPATH is correctly set.

In step 5, you create the Web archive file, which contains all the components of this servlet application, including the servlet classes, static HTML pages, and images. The Web archive file is essentially a Java archive file renamed with the .war extension.

The final stage of deployment for the servlet application is copying this Web archive .war file in the target deployment directory, which is the applications directory in your WebLogic instance domain.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020