Interstage Application Server/Interstage Web Server Java EE運用ガイド

C.2.8 Servletの機能差異について

IJServerクラスタとIJServer(J2EE)の機能差について下表に示します。

機能名	IJServerクラスタ	IJServer(J2EE)
セションリカバリ	×	○
マッピングがなくてもサーブレットが動作する	×	○
カスタムタグプーリングの使用	○	○
ファイルの一覧表示	△ (注1)	○
コネクタとWebコンテナ間のKeepAlive	○	○
要求を受け付けるWebサーバのIPアドレス	○	○
接続数	○	○
タイムアウト	○	○
同時処理数	○	○
JSP事前コンパイル	△ (注2)	○
JSPのオートリロード	○	○
コンテキストの共有	○	○
Webブラウザでセッションを保存する	△ (注3)	○
セションIDをcookieに設定する	○	○
セションの追跡に使用するcookieにSecure属性を常に付加する	○	○
静的リソースへのアクセス監視	○	○
リクエストURIのエンコーディング指定	△ (注4)	○
リクエストボディ処理のエンコーディングをクエリパラメタに使用	× (注5)	○
静的リソースにディスパッチ時のエンコーディング	○	○
リクエストのパラメタ解析やボディの処理に使用するエンコーディング	○	○
HTTPアクセスログ	○	×

○: サポート  ×: 非サポート
注1) マルチバイト文字を含むファイルまたはディレクトリの参照ができない場合があります。詳細は、「ファイルの一覧表示」を参照してください。
注2) 配備時のコンパイルだけ対応しています。
注3) セッションの追跡に使用するcookieを破棄しません。詳細は、「セションの追跡に使用するcookieの破棄」を参照してください。
セッションのタイムアウト時間と連動しません。詳細は、「Webブラウザでセッションを保存する」を参照してください。
注4) クエリパラメタの解析に使用されません。詳細は、「リクエストのクエリパラメタの解析に使用するエンコーディング」を参照してください。
注5) 常にリクエストボディ処理のエンコーディングをクエリパラメタに使用します。詳細は、「リクエストのクエリパラメタの解析に使用するエンコーディング」を参照してください。

非互換となる項目について、以下に説明します。

• ディレクトリ指定によるWebアプリケーションの配備

• セションリカバリ

• リクエストのクエリパラメタの解析に使用するエンコーディング

• Webアプリケーションで一時的な作業ディレクトリを使用

• 初回リクエスト時のJSPコンパイル

• JSP事前コンパイル

• 要求を受け付けるWebサーバのIPアドレス

• JREによるJSPの運用

• Webブラウザでセッションを保存する

• セションの追跡に使用するcookieの破棄

• マッピングがなくてもサーブレットが動作する

• ファイルの一覧表示

ディレクトリ指定によるWebアプリケーションの配備

IJServerクラスタでは、以下の機能は使用できません。

• サーバ上の任意の位置で実行するWebアプリケーションを配備する

IJServer(J2EE)において上記を使用していた場合、以下のいずれかによって対処してください。

• ディレクトリ指定による配備をサポートしているIJServer(J2EE)での運用を検討してください。

• 指定していたディレクトリをWebアプリケーションとしてアーカイブした上で「ファイルをアップロードして配備する」または「サーバ上に格納されているファイルを配備する」を選択して、配備してください。

セションリカバリ

IJServerクラスタでは、以下の機能は使用できません。

• セションレジストリクライアントおよびセションレジストリサーバを使用したセションリカバリ

上記を使用して高信頼性を目的とした運用をしたい場合、以下によって対処してください。

• セションリカバリ機能をサポートしているIJServer(J2EE)での運用を検討してください。

リクエストのクエリパラメタの解析に使用するエンコーディング

IJServer(J2EE)ではリクエストのクエリパラメタの解析に使用するエンコーディングを以下から選択可能でした。

• リクエストURIのエンコーディング

• リクエストボディ処理のエンコーディング

IJServerクラスタでは「リクエストボディ処理のエンコーディング」選択による動作固定となります。
「リクエストURIのエンコーディング」で指定したエンコーディングはリクエストURIの解析だけに使用され、クエリパラメタの解析には、「Interstage Web application deployment descriptor (sun-web.xml)」のparameter-encoding (親タグ:sun-web-app)タグの属性default-charsetに指定したエンコーディングがリクエストボディ処理と共通で使用されます。

Webアプリケーションで一時的な作業ディレクトリを使用

Webアプリケーションで、javax.servlet.ServletContext#getAttribute(String)の引数に文字列「javax.servlet.context.tempdir」を渡すことで、一時的な作業ディレクトリにアクセスするためのFileオブジェクトを取得することができます。

IJServer(J2EE)では再起動を行っても、一時的な作業ディレクトリ配下に出力した資源は残りました。
IJServerクラスタでは起動時に、一時的な作業ディレクトリ配下の資源をすべて削除します。このため、Webアプリケーションでは、一時的に資源を管理するディレクトリとして、一時的な作業ディレクトリを使用してください。

初回リクエスト時のJSPコンパイル

IJServer(J2EE)ではWebアプリケーション配備後の初回リクエスト時にJSPのコンパイルが行われるだけで、JSPファイルの更新およびコンパイル結果の更新、削除を行わない限りは再度JSPのコンパイルが行われることはありませんでした。IJServerクラスタではIJServerクラスタを起動した後の初回リクエスト時に毎回JSPのコンパイルを実施します。JSPのコンパイルが行われることによる運用環境での一時的な負荷を減らす場合には、「3.5.5 JSP事前コンパイル」を利用して、事前にコンパイル結果を生成した状態で運用を行ってください。

JSP事前コンパイル

IJServerクラスタでは、以下の機能は使用できません。

• ijscompileコマンドを使用してIJServer(J2EE)に配備済みのWebアプリケーションに対して任意のタイミングでコンパイルを行う

IJServerクラスタでは配備時にJSPをコンパイルすることができるようになりました。
配備後にJSPの入替えを行う場合には、以下のいずれかの運用を行ってください。

• JSPのオートリロード機能を使用してください。
  リクエストごと、および一定間隔ごとにJSPの更新チェックを行います。JSPの更新が行われた場合、一時的にJSPコンパイルによる負荷がかかります。

• Webアプリケーションを新たに配備し直してください。
  JSP事前コンパイル済みのWebアプリケーションに関しては配備解除を行い、更新したJSPを含めたWebアプリケーションを再度、JSP事前コンパイルを有効にして配備します。

• 開発環境でコンパイルした結果を本番環境へコピーしてください。
  運用環境とは別の環境で配備とJSP事前コンパイルを行い、出力結果を運用環境へコピーします。詳細は、「3.5.5 JSP事前コンパイル」を参照してください。

要求を受け付けるWebサーバのIPアドレス

IJServerクラスタの環境設定画面はシステムの環境設定「Webサーバとワークユニットを同一のマシンで運用する」の設定の影響を受けません。
Webコンテナが要求を受け付けるWebサーバを制限する必要がある場合には、運用環境に合わせて要求を受け付けるWebサーバのIPアドレスを設定する必要があります。なお、デフォルトの動作は要求を受け付けるWebサーバのIPアドレスが指定されていない状態となります。この場合、WebコンテナはすべてのWebサーバからのリクエストを受け付けます。

指定方法については、以下のマニュアルを参照してください。

• Interstage Java EE管理コンソールのヘルプ

• get/set/listサブコマンド

• 「11.18.3.2 configs.config.http-serviceの定義項目」の仮想サーバの追加プロパティ
  allowRemoteAddress(要求を受け付けるWebサーバのIPアドレス)

例

以下に、運用環境に合わせた要求を受け付けるWebサーバのIPアドレスを指定する方法を説明します。

Webサーバを同一マシンで運用している場合(ループバックアドレスを指定)

127\.0\.0\.0\.1

Webサーバを同一マシンで運用していない場合

192\.168\.10\.5

JREによるJSPの運用

IJServer(J2EE)では、Java Runtime Environment(以降、JREとする)でJSPを含むWebアプリケーションを実行できました。IJServerクラスタでは、JREを使用できません。JREで運用を行いたい場合、IJServer(J2EE)での運用を検討してください。

Webブラウザでセッションを保存する

Interstage Deployment Descriptor(sun-web.xml)のcookieプロパティ「cookieMaxAgeSeconds」を使用すると、Webブラウザを一度終了しても、サーバでセションが有効な間はWebブラウザを再起動することでセションを継続できます。ただし、IJServer(J2EE)と比較して次の違いがあります。

IJServer(J2EE)では、サーバ上にあるセッションのセッションタイムアウト時間と、Webブラウザ上で保持するセッションの追跡に使用するcookieの有効時間は連動していました。そのため、サーバ上のセッションがセッションタイムアウトした時点で、Webブラウザが保持するセッションの追跡に使用するcookieは無効となり、Webブラウザからの次のリクエストは最も負荷の少ないWebコンテナ(IJServerプロセス)で処理されました。

IJServerクラスタでは、連動しません。サーバ上に存在するセッションの状態にかかわらず、cookieプロパティ「cookieMaxAgeSeconds」で指定した時間の間、Webブラウザはセッションを継続するようにリクエストします。
そのため、サーバ上のセッションがセッションタイムアウトしていても、Webブラウザはセッションを継続するようリクエストし、常に同じWebコンテナ(IJServerプロセス)で処理されます。

本機能を使用する場合には、以下の点に注意してください。

• cookieプロパティ「cookieMaxAgeSeconds」の設定値について
  セッションタイムアウト時間よりcookieMaxAgeSecondsの方が短い場合、サーバ上にあるセッションのセッションタイムアウトよりも先に、Webブラウザが保存するセッションの追跡に使用するcookieが無効となってしまうため、サーバ上に不要なセッションが残存してしまう可能性があります。
  以下の何れかで設定しているセッションタイムアウト時間の最大値をcookieMaxAgeSecondsに設定してください。

  • デフォルト値(30分)

  • Deployment Descriptor(web.xml)の<session-timeout>タグで指定した値

  • アプリケーション内でjavax.servlet.http.HttpSession#setMaxInactiveInternal(…)の引数で指定した値

• セキュリティについて
  Webブラウザを再起動してもセッションを継続できるため、共通端末にあるWebブラウザからリクエストする運用環境では、セッションの情報をユーザ間で共有してしまう恐れがあります。十分に注意してください。

セションの追跡に使用するcookieの破棄

IJServer(J2EE)では、以下の場合にWebブラウザにセションの追跡に使用するcookieの破棄を促すヘッダをレスポンスに付加していました。

• IJServerでセションの追跡にcookieを使用しない設定(Interstage管理コンソールの[Webアプリケーションの環境設定] > [コンテキスト設定] > [セション]が[クッキーに設定しない])の場合、かつ、Webブラウザからのリクエストにセションの追跡に使用するcookieが付加されている場合(セションを使用するアプリケーションを運用中に該当の設定を切り替えた場合に発生)

• Webブラウザからのリクエストにセションの追跡に使用するcookieが付加されてきたが、レスポンス時にサーバ上でセションが無効な場合(セションのタイムアウト後またはセション破棄済みである場合)

これにより、セションを破棄(ログアウトなど)またはセションタイムアウトした後のリクエストは以前と同じWebコンテナ(IJServerプロセス)ではなく、リクエスト時点で負荷(リクエスト処理多重度)のもっとも小さいWebコンテナで処理されました。

IJServerクラスタでは、セションの破棄cookieはレスポンスに付加されません。
そのため、セションを破棄した後に同じWebブラウザから(Webブラウザの再起動なしに)リクエストした場合、以前と同じWebコンテナでリクエストが処理されます。
Webブラウザで保持しているセッションの追跡に使用するcookieを削除するためには、Webブラウザを再起動してください。
ただし、「Webブラウザでセッションを保存する」を有効にしている場合、Webブラウザの再起動では削除されません。Webブラウザの設定に従って、手動でセッションの追跡に使用するcookieを削除してください。

マッピングがなくてもサーブレットが動作する

IJServerクラスタでは、以下の機能は使用できません。

• マッピングがなくてもサーブレットが動作する
  deployment descriptor(web.xml)にマッピングを記述しなくても、サーブレットを実行させる機能です。

IJServer(J2EE)において上記を使用していた場合、以下のいずれかによって対処してください。

• 「マッピングがなくてもサーブレットが動作する」機能をサポートしているIJServer(J2EE)での運用を検討してください。

• deployment descriptor(web.xml)にマッピングを記述してください。
  「/servlet/サーブレットクラス名」または「/servlet/サーブレット名」にマッピングすることによって、Webアプリケーションのプログラム修正を行わずに移行することが可能です。以下に、修正方法を説明します。

  例1: サーブレットクラス名で運用していた場合  deployment descriptor(web.xml)

    <servlet>
      <servlet-name>TestServlet</servlet-name>
      <servlet-class>com.fujitsu.interstage.NonMappingServlet</servlet-class>
    </servlet>
  
    <servlet-mapping>
      <servlet-name>TestServlet</servlet-name>
      <url-pattern>/servlet/com.fujitsu.interstage.NonMappingServlet</url-pattern>
    </servlet-mapping>

  例2: サーブレット名で運用していた場合  deployment descriptor(web.xml)

    <servlet>
      <servlet-name>TestServlet</servlet-name>
      <servlet-class>com.fujitsu.interstage.NonMappingServlet</servlet-class>
    </servlet>
  
    <servlet-mapping>
      <servlet-name>TestServlet</servlet-name>
      <url-pattern>/servlet/TestServlet</url-pattern>
    </servlet-mapping>

注意

以下の理由によりセキュリティ上の問題があるため、本製品では「マッピングがなくてもサーブレットが動作する」の使用を推奨していません。

• deployment descriptor(web.xml)の定義がなくてもすべてのサーブレットが呼び出し可能となってしまう。

• Webアプリケーション内で使用しているクラスなど、内部構造が外部に漏れてしまう。

サーブレットはdeployment descriptor(web.xml)にマッピングを記述して呼び出してください。

ファイルの一覧表示

IJServer(J2EE)ではファイルの一覧表示のリンクに「リクエストURIのエンコーディング」で指定したエンコーディングを使用していました。
IJServerクラスタではファイルの一覧表示のリンクに使用するエンコーディングはUTF-8固定となります。このため、「リクエストURIのエンコーディング」でUTF-8以外のエンコーディングを指定した場合、ファイルの一覧表示画面でマルチバイト文字を含むリンクをクリックしても、ステータスコード404で復帰し、該当のファイルまたはディレクトリを参照できません。
参照できるようにするには以下の対応を行ってください。

• IJServer(J2EE)での運用を検討してください。

• 「リクエストURIのエンコーディング」にUTF-8を指定してください。

注意

以下の理由によりセキュリティ上の問題があるため、本製品では「ファイルの一覧表示」の使用を推奨していません。

• Webアプリケーション内にあるファイルやディレクトリ構成など、内部構造が外部に漏れてしまう。