- Introduction
- The Servlet Story
- Servlet and JSP History
- Web Servers and Servlet Containers
- JSP
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
Web Servers and Servlet Containers
A servlet is a Java-coded Web component that runs in a container. It generates HTML content. It is pure Java, so the benefits and restrictions of regular Java classes apply. Servlets are compiled to platform-neutral bytecode. Upon request, this bytecode file is loaded into a container. Some containers (servlet engines) are integrated with the Web server, while others are plug-ins or extensions to Web servers that run inside the JVM. Servlets look the same as static Web pages (just a URL to the browser) to the client, but are really complete programs capable of complex operations.
The servlet container is an extension of a Web server in the same way CGI, ASP, and PHP are. A servlet functions like these, but the language is Java. The servlet doesn't talk to the client directly. The Web server does that. In a chain of processes, the client sends a request to the Web server, which hands it to the container, which hands it to the servlet (which sometimes hands it off yet again to a database or a JavaBean). The response retraces the course from the servlet to the container to the Web server to the client. Of course there are several other steps that happen too (JSP may need to be converted to servlet, and the TCP/IP packet hops from node to node). A snapshot of these steps is: Web server-> container-> servlet-> JavaBean-> DB.
The servlet architecture makes the container manage servlets through their lifecycle. The container invokes a servlet upon an HTTP request, providing that servlet with request information (stored in a request object) and the container configuration. The servlet goes about its deed. When finished, it hands back HTML and objects that hold information about the response. The container then forms an HTTP response and returns it to the client (see Figure 3.1).
){kind=link}
Figure 3.1 This is an example Web page.
The container itself is often written in Java, since the specification defines it as operating inside a JVM. Not surprisingly, vendors vary in their implementation, including writing their containers in other languages (C++ is popular) mimicking a Java environment. They argue the application server is faster that way.
Listing 3.1 is a template for your servlets. It won't compile as-is, but shows the main outline to get you started.
Listing 3.1 A Servlet Template
/*
* servlet name
*
* copyright notice
*
* author
* date
* version
*
* servlet description
*
*/
//package declaration
//import statements
public class MyServlet
extends HttpServlet {
{
//class member declarations
// Instance Variables
// Static Initializer
// Public Methods. Optional doHead, & other doXXX not shown.
/**
* Initialize this servlet. Called only once in lifetime
*/
public void init() throws ServletException
{
// handle initialization chores
}
/**
* This gets called with every request.
* It is called first. The parent class already has
* this method so you don't have to override it,
* but you can.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
*
* @exception IOException if input/output error occurs
* @exception ServletException if a servlet-specified
* error occurs
*/
protected void service(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
//bypass doGet and doPost by handling request here.
// perhaps:
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
StringBuffer html = new StringBuffer();
html.append("<html>\n");
html.append("<head><title>Servlet Example</title>" +
"</head>\n");
html.append("<body>\n");
html.append("Servlet Example");
html.append("</body>");
html.append("</html>");
out.print( html.toString() );
//you out.println() or use buffer as above.
}
/*The service method will process the request so the doGet
and doPost methods are never called in this class. They
are included to show you what they look like. You could
remove the service method (the one here actually
overrides the default one in the super class) and then
the doGet and doPost methods will get called.
*/
/**
* Process a GET request for the specified resource.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
*
* @exception IOException if input/output error occurs
* @exception ServletException if a servlet-specified
* error occurs
*/
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
// Serve the requested resource,
// including the data content.
}
/**
* Process a POST request for the specified resource.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
*
* @exception IOException if input/output error occurs
* @exception ServletException if a servlet-specified
* error occurs
*/
protected void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
//often just throw it at doGet()
doGet(request, response);
}
/**
* Process a PUT request for the specified resource.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
*
* @exception IOException if input/output error occurs
* @exception ServletException if a servlet-specified
* error occurs
*/
protected void doPut(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
//rarely used
}
/**
* A few more convenience methods
*/
/**
* last thing called in a servlet, a funeral method
*/
public void destroy()
{
// clean up what init starts like DB connection
}
}
The template is a useful blueprint for your servlet, but they can be as short as the program in Listing 3.2:
Listing 3.2 A Short Example of a Servlet Program
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import java.io.PrintWriter;
import java.io.IOException;
public class MyServlet extends HttpServlet
{
public void service(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head><title>Servlet Error Handling " +
"Example</title></head>");
out.println("<body>");
out.println("A skimpy, but complete servlet.");
out.println("</body>");
out.println("</html>");
//not necessary, but this is how you couldset the status
response.setStatus(HttpServletResponse.SC_OK);
}
}
All servlet containers must support HTTP/1.0 as a protocol for requests and responses. They are not required to support HTTPS (HTTP over SSL), but may do so. Most containers implement the HTTP/1.1 specification as well. The container provides one or more Java Virtual Machines to support servlet execution. The servlet container instantiates objects that encapsulate client requests and server responses. The servlet container manages the servlet life cycle from loading and initialization, through the processing of requests and responses, to the eventual unloading and finalization of the servlets.
The servlet interface is the central abstraction of the servlet API. All servlets implement this interface. Usually, a servlet extends the HttpServlet class that implements the interface. In addition, the servlet container creates the ServletContext object, through which a servlet can log events, set and store attributes at the application level (across browsers) or session level (across pages, but same browser), and grab file paths.