When using Servlet 3.0 web modules, keep in mind the following
features.
Java™ Servlet 3.0 has many, new 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 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 you 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.
You
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 you set com.ibm.websphere.servlet.temp.dir to /foo,
the application temp directory is /foo/node1/server1/fragmentTest/fragmentTest24.war.
If you want to change the value at an application level, use the scratchdir
JavaServer Pages (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. You 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. You must start the application
server, 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.