JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Application Development Guide
search filter icon
search icon

Document Information


Part I Development Tasks and Tools

1.  Setting Up a Development Environment

2.  Class Loaders

3.  Debugging Applications

Part II Developing Applications and Application Components

4.  Securing Applications

5.  Developing Web Services

6.  Using the Java Persistence API

7.  Developing Web Applications

Using Servlets

Caching Servlet Results

Caching Features

Default Cache Configuration

Caching Example

The CacheKeyGenerator Interface

About the Servlet Engine

Instantiating and Removing Servlets

Request Handling

Using JavaServer Pages

JSP Tag Libraries and Standard Portable Tags

JSP Caching

Enabling JSP Caching

Caching Scope

The cache Tag

The flush Tag

Options for Compiling JSP Files

Creating and Managing Sessions

Configuring Sessions

HTTP Sessions, Cookies, and URL Rewriting

Coordinating Session Access

Saving Sessions During Redeployment

Logging Session Attributes

Distributed Sessions and Persistence

Session Managers

The memory Persistence Type

The file Persistence Type

The replicated Persistence Type

The coherence-web Persistence Type

Using Comet

Introduction to Comet

The Grizzly Implementation of Comet

Client Technologies to Use With Comet

Types of Comet Connections

Grizzly Comet

The Grizzly Comet API

The Hidden Frame Example

Creating a Comet-Enabled Application

Developing the Web Component

Creating the Client Pages

Creating the Deployment Descriptor

Deploying and Running a Comet-Enabled Application

Bayeux Protocol

Enabling Comet

To Configure the web.xml File

To Write, Deploy, and Run the Client

Advanced Web Application Features

Internationalization Issues

The Server's Default Locale

Servlet Character Encoding

Virtual Server Properties

Class Loader Delegation

Using the default-web.xml File

To Use the default-web.xml File

Configuring Logging and Monitoring in the Web Container

Configuring Idempotent URL Requests

Specifying an Idempotent URL

Characteristics of an Idempotent URL

Header Management

Configuring Valves and Catalina Listeners

Alternate Document Roots

Using a context.xml File

Enabling WebDav

Using SSI

Using CGI

8.  Using Enterprise JavaBeans Technology

9.  Using Container-Managed Persistence

10.  Developing Java Clients

11.  Developing Connectors

12.  Developing Lifecycle Listeners

13.  Developing OSGi-enabled Java EE Applications

Part III Using Services and APIs

14.  Using the JDBC API for Database Access

15.  Using the Transaction Service

16.  Using the Java Naming and Directory Interface

17.  Using the Java Message Service

18.  Using the JavaMail API


Using Servlets

GlassFish Server supports the Java Servlet Specification version 3.0.

Note - Servlet API version 3.0 is fully backward compatible with versions 2.3, 2.4, and 2.5, so all existing servlets should work without modification or recompilation.

To develop servlets, use the Java Servlet API. For information about using the Java Servlet API, see the documentation at

The GlassFish Server provides the wscompile and wsdeploy tools to help you implement a web service endpoint as a servlet. For more information about these tools, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

This section describes how to create effective servlets to control application interactions running on a GlassFish Server, including standard-based servlets. In addition, this section describes the GlassFish Server features to use to augment the standards.

The following topics are addressed here:

Caching Servlet Results

The GlassFish Server can cache the results of invoking a servlet, a JSP, or any URL pattern to make subsequent invocations of the same servlet, JSP, or URL pattern faster. The GlassFish Server caches the request results for a specific amount of time. In this way, if another data call occurs, the GlassFish Server can return the cached data instead of performing the operation again. For example, if your servlet returns a stock quote that updates every 5 minutes, you set the cache to expire after 300 seconds.

Whether to cache results and how to cache them depends on the data involved. For example, it makes no sense to cache the results of a quiz submission, because the input to the servlet is different each time. However, it makes sense to cache a high level report showing demographic data taken from quiz results that is updated once an hour.

To define how a GlassFish Server web application handles response caching, you edit specific fields in the glassfish-web.xml file.

Note - A servlet that uses caching is not portable.

For Javadoc tool pages relevant to caching servlet results, go to and click on the com.sun.appserv.web.cache package.

For information about JSP caching, see JSP Caching.

The following topics are addressed here:

Caching Features

The GlassFish Server has the following web application response caching capabilities:

Default Cache Configuration

If you enable caching but do not provide any special configuration for a servlet or JSP, the default cache configuration is as follows:

Caching Example

Here is an example cache element in the glassfish-web.xml file:

<cache max-capacity="8192" timeout="60">
<cache-helper name="myHelper" class-name="MyCacheHelper"/>
    <timeout name="timefield">120</timeout>
    <url-pattern> /catalog/* </url-pattern>
    <!-- cache the best selling category; cache the responses to
       -- this resource only when the given parameters exist. Cache
       -- only when the catalog parameter has 'lilies' or 'roses'
       -- but no other catalog varieties:
      -- /orchard/catalog?best&category='lilies'
      -- /orchard/catalog?best&category='roses'
      -- but not the result of
       -- /orchard/catalog?best&category='wild'
    <constraint-field name='best' scope='request.parameter'/>
    <constraint-field name='category' scope='request.parameter'>
        <value> roses </value>
        <value> lilies </value>
     <!-- Specify that a particular field is of given range but the
       -- field doesn't need to be present in all the requests -->
    <constraint-field name='SKUnum' scope='request.parameter'>
        <value match-expr='in-range'> 1000 - 2000 </value>
    <!-- cache when the category matches with any value other than
       -- a specific value -->
    <constraint-field name="category" scope="request.parameter>
        <value match-expr="equals" cache-on-match-failure="true">
    <servlet-name> InfoServlet </servlet-name>

For more information about the glassfish-web.xml caching settings, see cache in Oracle GlassFish Server 3.1 Application Deployment Guide.

The CacheKeyGenerator Interface

The built-in default CacheHelper implementation allows web applications to customize the key generation. An application component (in a servlet or JSP) can set up a custom CacheKeyGenerator implementation as an attribute in the ServletContext.

The name of the context attribute is configurable as the value of the cacheKeyGeneratorAttrName property in the default-helper element of the glassfish-web.xml deployment descriptor. For more information, see default-helper in Oracle GlassFish Server 3.1 Application Deployment Guide.

About the Servlet Engine

Servlets exist in and are managed by the servlet engine in the GlassFish Server. The servlet engine is an internal object that handles all servlet meta functions. These functions include instantiation, initialization, destruction, access from other components, and configuration management.

The following topics are addressed here:

Instantiating and Removing Servlets

After the servlet engine instantiates the servlet, the servlet engine calls the servlet’s init method to perform any necessary initialization. You can override this method to perform an initialization function for the servlet’s life, such as initializing a counter.

When a servlet is removed from service, the servlet engine calls the destroy method in the servlet so that the servlet can perform any final tasks and deallocate resources. You can override this method to write log messages or clean up any lingering connections that won’t be caught in garbage collection.

Request Handling

When a request is made, the GlassFish Server hands the incoming data to the servlet engine. The servlet engine processes the request’s input data, such as form data, cookies, session information, and URL name-value pairs, into an HttpServletRequest request object type.

The servlet engine also creates an HttpServletResponse response object type. The engine then passes both as parameters to the servlet’s service method.

In an HTTP servlet, the default service method routes requests to another method based on the HTTP transfer method: POST, GET, DELETE, HEAD, OPTIONS, PUT, or TRACE. For example, HTTP POST requests are sent to the doPost method, HTTP GET requests are sent to the doGet method, and so on. This enables the servlet to process request data differently, depending on which transfer method is used. Since the routing takes place in the service method, you generally do not override service in an HTTP servlet. Instead, override doGet, doPost, and so on, depending on the request type you expect.

To perform the tasks to answer a request, override the service method for generic servlets, and the doGet or doPost methods for HTTP servlets. Very often, this means accessing EJB components to perform business transactions, then collating the information in the request object or in a JDBC ResultSet object.