Servlets Are Pure Java Classes

Simply stated, a Java servlet is a pure Java class that implements the javax.servlet .Servlet interface. The application server creates an instance of the servlet class and uses it to handle incoming requests. The Servlet interface defines the set of methods that should be implemented to allow the application server to manage the servlet life cycle (discussed later in this chapter) and pass requests to the servlet instance for processing. Servlets intended for use as HTTP request/response mechanisms normally extend the javax.servlet.http.HttpServlet class, although they may implement and use the Servlet interface methods if desired. The HttpServlet class implements the Servlet interface and implements the init() , destroy() , and service() methods in a default manner. For example, the service() method in HttpServlet interrogates the incoming HttpServletRequest object and forwards the request to a series of individual methods defined in the HttpServlet class based on the type of request. These methods include the following:

• doGet() for handling GET , conditional GET , and HEAD requests

• doPost() for POST requests

• doPut() for PUT requests

• doDelete() for DELETE requests

• doOptions() for OPTIONS requests

• doTrace() for TRACE requests

The doGet() , doPost() , doPut() , and doDelete() methods in HttpServlet return a BAD_REQUEST (400) error as their default response. Servlets that extend HttpServlet typically override and implement one or more of these methods to generate the desired response. The doOptions() and doTrace() methods are typically not overridden in the servlet. Their implementations in the HttpServlet class are designed to generate the proper response, and they are usually sufficient.

A minimal HTTP servlet capable of responding to a GET request requires nothing more than extending the HttpServlet class and implementing the doGet() method.

WebLogic Server provides a number of useful sample servlets showing the basic approach for creating HTTP servlets. These sample servlets are located in the samples/server/examples/src/examples/servlets subdirectory beneath the Web-Logic Server home directory, a directory we refer to as $WL_HOME throughout the rest of the book. We will examine some additional example servlets in detail during the course of this chapter. These example servlets are available on the companion Web site for this book at http://www.wiley.com/compbooks/masteringweblogic.

Creating the HTML output within the servlet s service() or do XXX () method is very tedious . This deficiency was addressed in the J2EE specification by introducing a scripting technology, JavaServer Pages (JSP), discussed later in this chapter.

Servlets Have a Life Cycle

A servlet is an instance of the servlet class and has a life cycle similar to that of any other Java object. When the servlet is first required to process a request, the application server loads the servlet class, creates an instance of the class, initializes the instance, calls the servlet s init() method, and calls the service() method to process the request. In normal servlet operation, this same instance of the servlet class will be used for all subsequent requests.

Servlets may be preloaded during WebLogic Server startup by including the < load-on-startup > element in the web.xml file for the Web application. You can also provide initialization parameters in this file using < init-param > elements. WebLogic Server will preload and call init() on the servlet during startup, passing the specified initialization parameters to the init() method in the ServletConfig object.

An existing servlet instance is destroyed when the application server shuts down or intends to reload the servlet class and create a new instance. The server calls the destroy() method on the servlet prior to removing the servlet instance and unloading the class. This allows the servlet to clean up any resources it may have opened during initialization or operation.

Servlets Allow Multiple Parallel Requests

Servlets are normally configured to allow multiple requests to be processed simultaneously by a single servlet instance. In other words, the servlet s methods must be thread-safe. You must take care to avoid using class- or instance-level variables unless access is made thread-safe through synchronization logic. Typically, all variables and objects required to process the request are created within the service() or do XXX () method itself, making them local to the specific thread and request being processed.

Servlets may be configured to disallow multiple parallel requests by defining the servlet class as implementing the SingleThreadModel interface:

...
public class TrivialSingleThreadServlet 
    extends HttpServlet

implements SingleThreadModel

{
    public void init(ServletConfig config) throws ServletException
    {
        super.init(config);
        System.out.println("Here!");
    }
...

This simple change informs the application server that it may not process multiple requests through the same servlet instance simultaneously. The application server can honor this restriction in multiple ways: It may block and queue up requests for processing through a single instance, or it may create multiple servlet instances as needed to fulfill parallel requests. The servlet specification does not dictate how application servers should avoid parallel processing in the same instance.

WebLogic Server satisfies the single-threaded requirement by creating a small pool of servlet instances (the default pool size is five) that are used to process multiple requests. In older versions of WebLogic Server, multiple parallel requests in excess of the pool size would block waiting for the first available servlet instance. This behavior changed in WebLogic Server 7.0. The server now creates, initializes, and discards a new instance of the servlet for each request rather than blocking an execute thread under these conditions. Set the pool size properly to avoid this extra servlet creation and initialization overhead.

You can configure the size of the pool at the Web application level using the single-threaded-servlet-pool-size element in the weblogic.xml deployment descriptor. If you choose to employ single-threaded servlets in high-volume applications, consider increasing the pool size to a level comparable to the number of execute threads in the server to eliminate the potential overhead required to create extra servlet instances on the fly to process requests.

Although instance variables are safe to use in single-threaded servlets, class-level static variables are shared between these instances, so access to this type of static data must be thread-safe even when using the SingleThreadModel technique. Deploying and executing this TrivialSingleThreadServlet example verifies this pooling behavior in WebLogic Server. The first servlet request causes WebLogic Server to create five instances of the servlet, as evidenced by five separate invocations of the init() method and the subsequent writing of five Here! messages in the log.

Servlets May Access Request Data

The HttpServletRequest parameter passed in to the service() or do XXX () method contains a wealth of information available to the servlet during the processing of the request. Useful data in the HttpServletRequest is summarized in Table 1.1.

This is not an exhaustive list of the methods available on the HttpServletRequest class or its superclass, ServletRequest . Refer to the servlet javadocs at http://java.sun.com/products/servlet/2.3/javadoc/index.html or a good reference book on servlets for a complete list including parameter types, return types, and other details.

A useful servlet packaged with the WebLogic Server examples, SnoopServlet , illustrates the use of many of the methods available on the HttpServletRequest object. For example, this section of SnoopServlet illustrates how to retrieve and display the names and values of all parameters passed to the servlet:

...
Enumeration e = req.getParameterNames();
if (e.hasMoreElements()) {
    out.println(<h1>Servlet parameters (Single Value style):</h1>);
    out.println(<pre>);
    while (e.hasMoreElements()) {
        String name = (String)e.nextElement();
        out.println(+ name +  =  + req.getParameter(name));
    }
    out.println(</pre>);
}
...

This servlet can be very useful for debugging HTML forms during development. Specify SnoopServlet as the action for an HTML form to view all of the parameters, cookies, and headers sent by the browser during submission of the form. Nothing is more frustrating than spending time debugging a servlet only to find that the HTML form had an improperly named input item.

Note that SnoopFilter , a servlet filter discussed later in this chapter, provides a superior mechanism for viewing request information for some or all pages in the Web application.

Servlets Use Session Tracking

A servlet is a request/response mechanism that treats each incoming request as an independent processing event with no relationship to past or future requests. In other words, the processing is stateless. The HTTP protocol is also a stateless protocol: Each request from the Web browser is independent of previous or subsequent requests. Linking current requests to previous requests from the same client requires a mechanism for preserving context or state information from request to request. There are a number of HTML-based techniques for preserving context or state information:

• Cookies may be set in previous requests and passed back to the server on subsequent requests.

• URL-rewriting may be used to encode small amounts of context information on every hyperlink on the generated page.

• Hidden form fields containing context information may be included in forms.

These techniques all have limitations, and none provides the robust data types and flexibility needed to implement true state management. Fortunately, the session tracking capability defined in the J2EE servlet model provides an excellent solution.

Session tracking provides a flexible hash-table-like structure called an HttpSession that can be used to store any serializable Java object and make it available in subsequent requests. To identify the specific client making the request and look up its session information, session tracking uses a cookie or URL-encoded session ID passed to the server on subsequent requests. In WebLogic Server, this session ID has the name JSESSIONID by default and consists of a long hash identifying the client plus creation-time and cluster information. The format of the session ID is

JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!SECONDARY_JVM_HASH!CREATION_TIME

WebLogic Server uses exclamation marks to separate portions of the session ID. The first portion is used by the session tracking implementation in WebLogic Server to look up the client s HttpSession object in the Web application context. Subsequent portions of the session ID are used to identify primary and secondary servers for this client in a WebLogic Server cluster and to track the creation time for this session. Chapter 11 will discuss WebLogic Server clustering in detail as part of the discussion of administration best practices.

Using session tracking in a servlet is as simple as calling the getSession() method to retrieve or create the HttpSession object for this client and then utilizing the HttpSession interface to get and set attributes in the session. For a good example, see the SessionServlet example provided in the WebLogic Server examples.

WebLogic Server supports several forms of session persistence, a mechanism for providing session failover. The two most commonly used forms are in-memory replication and JDBC persistence. When using these types of session persistence, be careful not to place very large objects in the HttpSession . WebLogic Server tracks changes to the session object through calls to the setAttribute() method. At the end of each request, the server will serialize each new or modified attribute, as determined by the arguments to any setAttribute() calls, and persist them accordingly .

Recognize that persisting a session attribute will result in WebLogic Server serializing the entire object graph, starting at the root object placed in the HttpSession . This can be a significant amount of data if the application stores large, coarse-grained objects in the session. Multiple fine-grained objects can provide superior performance, provided that your application code updates only a subset of the fine-grained objects (using setAttribute ) in most cases. We will talk more about in-memory session replication and clustering in Chapter 11.

To summarize, servlets are a reliable pure-Java mechanism for processing HTTP requests. It can be tedious to generate the HTML response through the simple println() methods available on the response Writer object, however. As we will discuss in Chapter 2, servlets are better suited for processing incoming requests and interacting with business objects and services than for the generation of HTTP responses.

If servlets are a tedious way to create HTML, what is available in the J2EE specification for efficiently creating HTML responses? JavaServer Pages technology, the subject of the next section of this chapter, is specifically design to be a powerful tool for creating HTML.

Characteristics of JavaServer Pages

JavaServer Pages (JSP) technology was introduced in the J2EE platform to provide an alternative to servlets for the generation of server-side HTML content. Although a detailed discussion of JSP technology is beyond the scope of this book, some key concepts and characteristics are worth a brief review.

JSP Is a Scripting Technology

Recall that one of the important characteristics of servlets is their pure Java nature. Servlets are Java classes that are written, compiled, and debugged much like any Java class. JavaServer Pages, on the other hand, are a script-based technology similar to Microsoft s Active Server Pages (ASP) technology or Allaire s Cold Fusion scripting language. Like these scripting languages, special tags and script elements are added to a file containing HTML to produce a combination of static and dynamic content. In the case of JSP, these added elements are Java code or special JSP tags that interact with Java beans and other J2EE components in the application.

JSP Pages Are Converted to Servlets

The key to understanding JSP pages is to recognize that the JSP file itself is simply the input for a multistep process yielding a servlet. In the key processing step, the JSP page is parsed by the application server and converted to the equivalent pure- Java servlet code. All text that is not part of JSP tags and scripting elements is assumed to be part of the HTTP response. This text is placed in out.print() calls within the generated servlet request-processing method. All Java scripting elements and tags become additional Java code in the servlet. The generated servlet is then compiled, loaded, and used to process the HTTP request in a manner identical to a normal servlet.

Figure 1.1 depicts this process for a trivial sample JSP page with a small amount of scripted Java code embedded on the page. The sample.jsp page is converted to the equivalent pure-Java servlet code, compiled into a servlet class, and used to respond to the original and subsequent HTTP requests.

Figure 1.1:  JSP page is converted to a servlet.

The parsing, conversion, compiling, and classloading steps required to accomplish this transformation are handled by the application server. You don t have to perform any of these steps ahead of time or register the resulting servlet ”all of this is done automatically by the server. Note that the processing and compiling can be done prior to deployment using utilities provided by WebLogic Server, a technique known as precompiling the JSP pages. We will discuss this technique in detail later in this chapter.

In WebLogic Server, the resulting servlet is a subclass of weblogic.servlet .jsp.JspBase by default. JspBase is a WebLogic-provided class that extends HttpServlet and forwards service() calls to a method called _ jspService() . You may also create a custom base class for JSP-generated servlets to replace the default JspBase class, a technique discussed at end of this chapter.

Many Tags and Scripting Elements Are Available

JSP technology provides a rich set of scripting elements and tags for creating dynamic content. Table 1.2 lists some of the important elements available.

Many more elements and tags are available. A detailed discussion of these elements is beyond the scope of this book. Consult one of the books listed at the beginning of this chapter for a complete list of JSP elements and tags, or browse Sun s JSP area at http://java.sun.com/products/jsp/ for more information.

All Servlet Capabilities Are Available

Because JSP pages are converted to servlets, all of the capabilities and techniques available in servlets are also available in JSP pages. The HttpServletRequest and HttpServletResponse parameters are available, along with a number of predefined variables available in the JSP page, as listed in Table 1.3.

JSP scriptlet code may make use of all implicit objects because scriptlet code is placed in the generated _jspService() method after these objects are defined, as shown in this partial listing:

...
public void _jspService(javax.servlet.http.HttpServletRequest request,
                        javax.servlet.http.HttpServletResponse response)
         throws java.io.IOException, javax.servlet.ServletException 
{  
    // declare and set well-known variables:
    javax.servlet.ServletConfig config = getServletConfig();
    javax.servlet.ServletContext application =
       config.getServletContext();
    Object page = this;
    javax.servlet.jsp.JspWriter out;
    javax.servlet.jsp.PageContext pageContext =
       javax.servlet.jsp.JspFactory.getDefaultFactory().getPageContext(this, request, response, null, true, 8192, true);
    
    out = pageContext.getOut();
    
    javax.servlet.http.HttpSession session = request.getSession(true);
    ...

// scriptlet code and generated out.print() statements go here

...
}

You should recognize that these implicit objects are available in scriptlet code but are not automatically available in methods defined using the < %! ... % > declaration scripting element or in methods in a custom base class used for the JSP page. It is common to pass the necessary implicit objects to these methods as parameters.

Session tracking is available by default in JSP pages, providing the session implicit object throughout the scriptlet code. If your application is not using session tracking, you should disable it to avoid unnecessary session persistence. Although there is no explicit way to disable session tracking for the entire Web application, servlets will not create sessions unless the servlet code calls the getSession() method. JSP pages may disable sessions using the page directive:

<%@ page session=false %>

Even if your JSP does nothing with the session information, WebLogic Server must persist the last access time for the session at the end of the request processing. It is best to explicitly disable session tracking in JSP pages that do not use it.

Like servlets, JSP pages are normally multithreaded and may process multiple requests simultaneously. The same thread-safety restrictions that apply to servlets also apply to JSP pages unless the JSP is configured to be single threaded. In a JSP page a special page directive is used to configure this attribute:

<%@ page isThreadSafe=false %>

If the isThreadSafe attribute is set to false , the resulting servlet will implement the SingleThreadModel interface, and WebLogic Server will create a pool of servlet instances and synchronize access to them in the same manner it uses for a pure-Java servlet that implements this interface.

JSP Response Is Buffered

As we said, servlets and JSP pages are request/response mechanisms: An HTTP request is made by the browser, and an HTML response is generated by the servlet or JSP page. In both cases, this response is normally buffered , or held in memory on the server temporarily, and sent back to the calling browser at the end of the processing.

By default, output created using the print() and println() methods on the implicit JspWriter object ( out ) are buffered, along with HTTP headers, cookies, and status codes set by the page. Buffering provides you with these important benefits:

• Buffered content may be discarded completely and replaced with new content. The jsp:forward element relies on this capability to discard the current response and forward the HTTP request to a new page for processing. Note that the errorPage directive uses jsp:forward to send the processing to the error page if an error is caught in the JSP page, so buffering is also required for proper error-page handling.

• Buffering allows the page to add or change HTTP headers, cookies, and status codes after the page has begun placing HTML content in the response. Without buffering, it would be impossible to add a cookie in the body of the JSP page or change the response to be a redirect (302) to a different page once print() or println() has been called because the headers and cookies have already been sent.

When the buffer fills, the response is committed, and the first chunk of information is sent to the browser. Once this commit occurs, the server will no longer honor jsp:forward , HTTP header changes (such as redirects), or additional cookies. The server will generate an IllegalStateException if any of these operations is attempted after the buffer fills and the response is committed.

The default size of the JSP output buffer is 8KB in WebLogic Server, which you can control using the page directive in each JSP page:

<%@ page buffer=32kb %>

Output buffering may also be turned off using this directive by specifying none for a size, but this practice is not recommended.

Output buffers should be set to at least 32KB in most applications to avoid filling the buffer and committing the response before the page is complete. The minor additional memory requirement (32KB times the number of threads) is a small price to pay for correct error-page handling and the ability to add cookies and response headers at any point in large pages.