Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop web applications > Develop web applications > Develop servlets > Develop servlets with WAS extensions
Java Servlet 3.0 considerations
When using Servlet 3.0 web modules, keep in mind the following features.
New feature: 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 new features.New feature:
Annotations
New feature: New feature:
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.
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 you 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.
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.
Asynchronous servlet best practices
Cache with Servlet 3.0
Develop servlets with WAS extensions
Related
JSP engine configuration parameters