Java Servlet に関する考慮事項

WebSphere® Application Server traditionalバージョン 9.0 は、Servlet 3.1 仕様をサポートします。これには、Servlet 3.0 仕様で導入されたフィーチャーおよび動作の変更が含まれます。 Servlet 3.1 でのフィーチャーと動作変更について説明します。

この製品は、 Servlet 3.1をサポートしています。これには、Servlet 3.0 仕様で導入されたフィーチャーおよび振る舞いの変更が含まれています。

詳しくは、『Servlet 3.1 フィーチャーの機能 (Servlet 3.1 feature functions)』を参照してください。 Servlet 2.5 以前から Servlet 3.1にマイグレーションする場合は、Servlet 3.0の動作の変更も考慮してください。

Java™ Servlet 3.1 には多くの強力なフィーチャーがあります。 これらのフィーチャーの中には、Servlet 3.0 仕様で十分に説明されていなかったり、トレードオフを伴ったりするものもあります。 新しいフィーチャーの使用を最適化できるように、以下のトピックを検討してください。

アノテーション

Java Servlet 3.0 アノテーションは、Servlet 2.5 Web モジュールで取得されます。これには、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 のパスを変更することができます。
重要: パスを変更すると、セッション共有や IBMSessionExt.invalidateAll メソッドなど、1つのクッキーを複数のアプリケーショ ンに使用することに依存する、特定の IBM® 拡張に影響する可能性があります。
動的 Cookie は、仲介サービスに対して以下の影響を与えます。
  • エンタープライズ・プロキシーは、アプリケーションが開始してセッション・アフィニティーで Cookie を使用する際に動的な Cookie を自動的に取得します。
  • 低いセキュア・モードまたは中間セキュア・モードの DMZ プロキシーも、アプリケーションの開始時に動的な Cookie を自動的に取得します。 高いセキュア・モードの DMZ プロキシーの場合、取得は自動的に行われず、ターゲットのルーティング情報がエクスポートされる前にアプリケーションを実行する必要があります。
  • Web サーバー・プラグインは、構成情報についてアプリケーション・サーバーと通信しないため、動的 Cookie を自動的に取得することはできません。 プラグインで Cookie を取得するには、アプリケーション・サーバーを開始し、プラグイン構成を生成し、プラグインに構成を伝搬してから、構成を再ロードする必要があります。