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:
- profile home=C:\opt\WAS\profiles\node1
- server name=server1
- enterprise application name=fragmentTest
- web module name=fragmentTest24.war
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:
- An enterprise proxy automatically retrieves a dynamic cookie when an application starts and uses the cookie for session affinity.
- A DMZ proxy in low or medium secure mode also automatically retrieves a dynamic cookie when an application starts. For a DMZ proxy in high secure mode, the retrieval is not automatic; the application must be running before the target routing information is exported.
- A web server plug-in cannot obtain the dynamic cookie automatically because it does not communicate with application servers for configuration information. We must start the application, generate the plug-in configuration, propagate the configuration to the plug-in, and then reload the configuration for the plug-in to obtain the cookie.
- In the cluster environment, the generated dynamic cookie name on each server must be the same, otherwise the front-end intermediary services might not be able to route requests.
Related:
Servlet 3.1 feature functions Asynchronous servlet best practices Caching with Servlet 3.0 Developing servlets with extensions JSP engine configuration parameters