Develop servlets with extensions

Use this task to provide a summary of the WebSphere Application Server extensions we can use to develop servlets.

Several WAS extensions are provided for enhancing your servlets. This task provides a summary of the extensions that we can utilize.

Tasks

1. Review the supported specifications.

   Create Java components, referring to the Servlet specifications.

   The application server includes its own packages that extend and add to the Java Servlet API. These extensions and additions make it easier to manage session states, create personalized Web pages, generate better servlet error reports, and access databases. Locate the API documentation for the application server APIs in the (Dist) (ZOS) install_root\web\apidocs (iSeries) app_server_root/web/apidocs directory for the default installation. All of the public Application Server APIs are located in the com.ibm.websphere packages, however, com.ibm.websphere.servlet package is specific to the product servlet APIs.

2. Use your favorite integrated development environment (IDE), or a text editor, to develop or migrate code artifacts that meet the specifications.
3. Test the code artifacts.

What to do next

Assemble your code artifacts into a web module using assembly tools as a prerequisite to deploying the code to the application server.

Subtopics

• Configure page list servlet client configurations
  We can define PageListServlet configuration information in the IBM Web Extensions file. The IBM Web Extensions file is created and stored in the web applications archive (WAR) file by an assembly tool.
• The client_types.xml file
  The client_types.xml file provides client type detection support for servlets extending PageListServlet. Using the configuration data in the client_types.xml file, servlets can determine the language type that calling clients require for the response.
• Java Servlet considerations
  WAS traditionalv9.0 supports the Servlet 3.1 specification. Learn about the features and behavior changes for Servlet 3.1.
• Programmatic configuration of listeners, filters, and servlets
  Learn about the configuration methods, addListener, addFilter, and addServlet, which were introduced in the Servlet 3.0 specification. We can call these methods, which are part of the ServletContext interface, from a ServletContainerInitializer or a ServletContextListener.
• Initial parameters for servlets settings
  Specify initial parameters passed to the init method of web module servlet filters. We can specify initial parameter values for servlets in web modules during or after installation of an application onto a WAS deployment target. The <param-value> values specified in <init-param> statements in the web.xml file of web modules are used by default.
• Servlet filtering
  Servlet filtering provides a new type of object called a filter that can transform a request or modify a response.
• autoRequestEncoding and autoResponseEncoding
  Starting with WAS v5, the web container no longer automatically sets request and response encodings, and response content types. Programmers are expected to set these values using available methods in the Servlet 2.3 specification or later. If programmers choose not to use the character encoding methods, they can specify the autoRequestEncoding and autoResponseEncoding extensions, which enable the application server to set the encoding values and content type.
• Application life cycle listeners and events
  With application life cycle listeners and events, which are now part of the Servlet API, we can notify interested listeners when servlet contexts and sessions change. For example, we can notify users when attributes change and if sessions or servlet contexts are created or destroyed.

Related:

Asynchronous request dispatcher

Remote request dispatcher

Development and assembly tools

Task overview: Using the dynamic cache service to improve performance

Task overview: Managing HTTP sessions