WebSphere® Application Server traditionalバージョン 9.0 は Servlet 3.1 仕様をサポートします。
Servlet 3.1 のフィーチャーおよび動作の変更について説明します。

新フィーチャー:
この製品は、Servlet 3.0 の仕様で導入されたフィーチャーおよび動作変更を含め、Servlet 3.1 をサポートしています。詳しくは、『Servlet 3.1 フィーチャーの機能』を参照してください。Servlet 2.5 以前から Servlet 3.1 にマイグレーションする場合は、Servlet 3.0 の動作変更についても検討してください。newfeat
Java™ Servlet 3.1 には、数多くの強力なフィーチャーがあります。これらのフィーチャーの中には、Servlet 3.0 仕様で十分に説明されていなかったり、トレードオフを伴ったりするものもあります。新しいフィーチャーの使用を最適化できるように、以下のトピックを検討してください。
アノテーション
Servlet 2.5 Web モジュールでは、Java Servlet 3.0 のアノテーションが選択されます。これには、サーブレットの Web への公開が含まれる場合があります。古いアプリケーションの前提条件をアップグレードする場合は注意してください。新しいアノテーションが処理されて、適用しないアノテーションが前提条件の JAR ファイルに含まれる可能性があります。
ファイル・アップロード
Servlet 3.0 に新たに導入されたファイル・アップロード (マルチパート・フォーム) のサポートを使用する場合は、ファイルを書き込むデフォルトの場所が javax.servlet.context.tempdir サーブレット・コンテキスト属性の値と同じになります。例えば、次の属性を持つ構成に対しては
C:¥opt¥WAS¥profiles¥node1¥temp¥node1¥server1¥fragmentTest¥fragmentTest24.war が生成されます。
- プロファイルのホーム = C:¥opt¥WAS¥profiles¥node1
- サーバー名 = server1
- エンタープライズ・アプリケーション名 = fragmentTest
- Web モジュール名 = fragmentTest24.war
相対パスも、このデフォルトの場所が基準になります。
別のディレクトリーを基準にするために javax.servlet.context.tempdir サーブレット・コンテキスト属性の値を変更するには、com.ibm.websphere.servlet.temp.dir システム・プロパティーを設定します。このシステム・プロパティーは、サーバー全体のすべてのアプリケーションに影響します。例えば、com.ibm.websphere.servlet.temp.dir を /foo に
設定した場合、アプリケーションの一時ディレクトリーは /foo/node1/server1/fragmentTest/fragmentTest24.war となります。
アプリケーション・レベルで値を変更する場合は、scratchdir
JavaServer Pages (JSP) 属性を使用します。scratchdir 属性について詳しくは、『JSP エンジン構成パラメーター』トピックを参照してください。
プログラムまたは動的 HTTP セッション構成
プログラムによる HTTP セッション構成により、アプリケーションは、
web.xml ファイル構成または API メソッド呼び出しのどちらかを介して、使用中のセッション構成を変更することができます。アプリケーションの開始後は、動的に変更された Cookie 名は変更できません。セキュリティー上、管理者は、アプリケーション間で共有される可能性がある特定の Cookie についてのプログラムによるセッション構成を無効にすることができます。一般に、アプリケーションが固有の Cookie 名または Cookie パスを使用する場合は、Cookie 構成を変更すると安全です。アプリケーションごとにデフォルトの Cookie パスを変更することにより、セッション管理を介してコンテキスト・ルートを使用できるようになります。
重要: このパスを変更すると、1 つの Cookie を複数の
アプリケーションで使用することに依存する特定の IBM® 拡張機能 (セッション
共有や IBMSessionExt.invalidateAll メソッドなど) に影響を与える
可能性があります。
動的 Cookie には、中間サービスに対して以下の影響があります。
- エンタープライズ・プロキシーは、アプリケーションが開始されると動的 Cookie を自動的に検索し、セッション・アフィニティーにその Cookie を使用します。
- 低または中程度のセキュア・モードの DMZ プロキシーも、アプリケーションが開始されると、動的 Cookie を自動的に検索します。
高セキュア・モードの DMZ プロキシーの場合は、検索は自動的には行われません。ターゲット・ルーティング情報がエクスポートされるには、あらかじめアプリケーションが実行されている必要があります。
- Web サーバー・プラグインは、構成情報についてアプリケーション・サーバーと通信しないため、動的 Cookie を自動的に取得することはできません。プラグインで Cookie を取得するには、アプリケーションを開始し、プラグイン構成を生成し、プラグインに構成を伝搬してから、構成を再ロードする必要があります。
- クラスター環境では、各サーバーに生成された動的 Cookie 名は同じでなければなりません、同じでない場合は、フロントエンド中間サービスが要求をルーティングできなくなる可能性があります。