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

Invoking a Servlet With a URL

You can call a servlet deployed to the Application Server by using
a URL in a browser or embedded as a link in an HTML or JSP file. The
format of a servlet invocation URL is as follows:

http://server:port/context-root/servlet-mapping?name=value

The following table describes each URL section.

Table 8–1 URL Fields
for Servlets Within an Application

URL element

Description

server:port

The IP address (or host name) and optional port number.

To access the default web module for a virtual server, specify
only this URL section. You do not need to specify the context-root or servlet-name unless you also
wish to specify name-value parameters.

context-root

For an application, the context root is defined in the context-root element
of the application.xml or sun-application.xml file. For an individually deployed web module, the context
root is specified during deployment.

For both applications and individually deployed web modules,
the default context root is the name of the WAR file minus the .war suffix.

servlet-mapping

The servlet-mapping as configured in the web.xml file.

?name=value...

Optional request parameters.

In this example, localhost is the host name, MortPages is the context root, and calcMortgage is
the servlet mapping:

When invoking a servlet from within a JSP file, you can use
a relative path. For example:

<jsp:forward page="TestServlet"/>
<jsp:include page="TestServlet"/>

Servlet Output

ServletContext.log messages are sent
to the server log.

By default, the System.out and System.err output of servlets are sent to the server log, and during
startup, server log messages are echoed to the System.err output.
Also by default, there is no Windows-only console for the System.err output.

You can change these
defaults using the Admin Console. In the developer profile, select
the Application Server component and the Logging tab. In the cluster profile, select the
Logger Settings component under the relevant configuration.
Then check or uncheck Write to System Log. If this box is checked, System.out output is sent to the server log. If it is unchecked, System.out output is sent to the system default location
only.

For more information, click the Help button in the Admin Console from
the Logging page.

Caching Servlet Results

The Application 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 Application Server caches the
request results for a specific amount of time. In this way, if another
data call occurs, the Application 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 an Application Server web application handles response
caching, you edit specific fields in the sun-web.xml file.

Caching Features

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

Caching is configurable based on the servlet name
or the URI.

When caching is based on the URI, this includes user
specified parameters in the query string. For example, a response
from /garden/catalog?category=roses is different
from a response from /garden/catalog?category=lilies.
These responses are stored under different keys in the cache.

Cache size, entry timeout, and other caching behaviors
are configurable.

Entry timeout is measured from the time an entry is
created or refreshed. To override this timeout for an individual cache
mapping, specify the cache-mapping subelement timeout.

To determine caching criteria programmatically, write
a class that implements the com.sun.appserv.web.cache.CacheHelper interface. For example, if only a servlet knows when a
back end data source was last modified, you can write a helper class
to retrieve the last modified timestamp from the data source and decide
whether to cache the response based on that timestamp.

To determine cache key generation programmatically,
write a class that implements the com.sun.appserv.web.cache.CacheKeyGenerator interface. See The CacheKeyGenerator Interface.

All non-ASCII request parameter values specified in
cache key elements must be URL encoded. The caching subsystem attempts
to match the raw parameter values in the request query string.

Since newly updated classes impact what gets cached,
the web container clears the cache during dynamic deployment or reloading
of classes.

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.

About the Servlet Engine

Servlets exist in and are managed by the servlet engine
in the Application 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. This section covers the following topics:

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 Application 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.