+

Search Tips   |   Advanced Search

Java Servlet considerations

WebSphere Application Server traditionalv9.0 supports the Servlet 3.1 specification. Learn about the features and behavior changes for Servlet 3.1.

New feature:

The product supports Servlet 3.1, which includes features and behavior changes that were introduced in the Servlet 3.0 specification. See Servlet 3.1 feature functions for more information. If we are migrating from Servlet 2.5 or earlier to Servlet 3.1, consider the behavior changes for Servlet 3.0, as well.newfeat

Java Servlet 3.1 has many powerful features. Some of these features are not fully documented in the Servlet 3.0 specification or they entail trade-offs. Consider the following topics to make best use of the new features.


Annotations

Java Servlet 3.0 annotations are picked up in Servlet 2.5 web modules, which can include exposing a servlet on the web. Use caution when upgrading prerequisites of an older application, because the new annotations are processed and the prerequisites JAR file might include annotations that we do not want applied.


File upload

When using the file upload (multipart forms) support that is new to Servlet 3.0, the default location for writing files is the same as the value of the javax.servlet.context.tempdir servlet context attribute. For example, C:\opt\WAS\profiles\node1\temp\node1\server1\fragmentTest\fragmentTest24.war is produced for a configuration with the following attributes:

Relative paths are also relative to this default location.

We can change the value of the javax.servlet.context.tempdir servlet context attribute to be relative to a different directory by setting the com.ibm.websphere.servlet.temp.dir system property. This system property affects all applications on a server-wide basis. For example, if we set com.ibm.websphere.servlet.temp.dir to /foo, the application temp directory is /foo/node1/server1/fragmentTest/fragmentTest24.war. To change the value at an application level, use the scratchdir JSP attribute. View the JSP engine configuration parameters topic for more information about the scratchdir attribute.


Programmatic or dynamic HTTP session configuration

Programmatic HTTP session configuration enables an application to modify the session configuration in use, either through web.xml file configuration or through API method calls. After the application starts, a dynamically modified cookie name cannot be changed. For security purposes, administrators can disable programmatic session configuration for particular cookies that can be shared between applications. Generally, it is safe to modify the cookie configuration, if the application uses a unique cookie name or path. We can change the default cookie path for each application to use the context root through the session management.

Important: Changing the path can affect certain IBM extensions, such as session sharing or the IBMSessionExt.invalidateAll method that rely on using one cookie for multiple applications.

Dynamic cookies have the following impact on intermediary services:


Related:

  • Servlet 3.1 feature functions
  • Asynchronous servlet best practices
  • Caching with Servlet 3.0
  • Developing servlets with extensions
  • JSP engine configuration parameters