以下の項目のJ2EEとJava EEでの機能差異について説明します。
Webアプリケーションで一時的な作業ディレクトリを使用
Webアプリケーションで、javax.servlet.ServletContext#getAttribute(String)の引数に文字列「javax.servlet.context.tempdir」を渡すことで、一時的な作業ディレクトリにアクセスするためのFileオブジェクトを取得することができます。
J2EE機能の場合は、IJServerワークユニットの再起動を行っても、一時的な作業ディレクトリ配下に出力した資源は残りました。
Java EE機能の場合は、IJServerクラスタ起動時に、一時的な作業ディレクトリ配下の資源をすべて削除します。このため、Webアプリケーションでは、一時的に資源を管理するディレクトリとして、一時的な作業ディレクトリを使用してください。
初回リクエスト時のJSPコンパイル
J2EE機能の場合は、Webアプリケーション配備後の初回リクエスト時にJSPのコンパイルが行われるだけで、JSPファイルの更新およびコンパイル結果の更新、削除を行わない限りは再度JSPのコンパイルが行われることはありませんでした。
Java EE機能の場合は、IJServerクラスタを起動した後の初回リクエスト時に毎回JSPのコンパイルを実施します。
JSPのコンパイルが行われることによる運用環境での一時的な負荷を減らす場合には、JSP事前コンパイル機能を利用して、事前にコンパイル結果を生成した状態で運用を行ってください。
JSP事前コンパイル
Java EE機能では、配備時にのみJSPをコンパイルすることができます。
配備後にJSPの入替えを行う場合には、以下のいずれかの運用を行ってください。
JSPのオートリロード機能を使用してください。
リクエストごと、および一定間隔ごとにJSPの更新チェックを行います。JSPの更新が行われた場合、一時的にJSPコンパイルによる負荷がかかります。
Webアプリケーションを新たに配備し直してください。
JSP事前コンパイル済みのWebアプリケーションに関しては配備解除を行い、更新したJSPを含めたWebアプリケーションを再度、JSP事前コンパイルを有効にして配備します。
開発環境でコンパイルした結果を本番環境へコピーしてください。
運用環境とは別の環境で配備とJSP事前コンパイルを行い、出力結果を運用環境へコピーします。
詳細は、「Java EE運用ガイド」の「JSP事前コンパイル」を参照してください。
要求を受け付けるWebサーバのIPアドレス
Java EE機能の環境設定画面は、システムの環境設定「Webサーバとワークユニットを同一のマシンで運用する」の設定の影響を受けません。
Webコンテナが要求を受け付けるWebサーバを制限する必要がある場合には、運用環境に合わせて要求を受け付けるWebサーバのIPアドレスを設定する必要があります。なお、デフォルトの動作は要求を受け付けるサーバのIPアドレスが指定されていない状態となります。この場合、WebコンテナはすべてのWebサーバからのリクエストを受け付けます。
例
以下に、運用環境に合わせた要求を受け付けるWebサーバのIPアドレスを指定する方法を説明します。
Webサーバを同一マシンで運用している場合(ループバックアドレスを指定)
127\.0\.0\.0\.1 |
Webサーバを同一マシンで運用していない場合
192\.168\.10\.5 |
JREによるJSPの運用
J2EE機能の場合は、Java Runtime Environment(以降、JREとする)でJSPを含むWebアプリケーションを実行できました。
Java EE機能の場合は、JREを使用できません。
Webブラウザでセッションを保存する
J2EE機能の場合は、サーバ上にあるセッションのセッションタイムアウト時間と、Webブラウザ上で保持するセッションの追跡に使用するcookieの有効時間は連動していました。そのため、サーバ上のセッションがセッションタイムアウトした時点で、Webブラウザが保持するセッションの追跡に使用するcookieは無効となり、Webブラウザからの次のリクエストは最も負荷の少ないWebコンテナ(IJServerプロセス)で処理されました。
Java EE機能の場合は、連動しません。サーバ上に存在するセッションの状態にかかわらず、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の破棄
J2EE機能では、以下の場合にWebブラウザにセションの追跡に使用するcookieの破棄を促すヘッダをレスポンスに付加していました。
IJServerでセションの追跡にcookieを使用しない設定(Interstage管理コンソールの[Webアプリケーションの環境設定] > [コンテキスト設定] > [セション]が[クッキーに設定しない])の場合、かつ、Webブラウザからのリクエストにセションの追跡に使用するcookieが付加されている場合(セションを使用するアプリケーションを運用中に該当の設定を切り替えた場合に発生)
Webブラウザからのリクエストにセションの追跡に使用するcookieが付加されてきたが、レスポンス時にサーバ上でセションが無効な場合(セションのタイムアウト後またはセション破棄済みである場合)
これにより、セションを破棄(ログアウトなど)またはセションタイムアウトした後のリクエストは以前と同じWebコンテナ(IJServerプロセス)ではなく、リクエスト時点で負荷(リクエスト処理多重度)のもっとも小さいWebコンテナで処理されました。
Java EE機能では、セションの破棄cookieはレスポンスに付加されません。
そのため、セションを破棄した後に同じWebブラウザから(Webブラウザの再起動なしに)リクエストした場合、以前と同じWebコンテナでリクエストが処理されます。
Webブラウザで保持しているセッションの追跡に使用するcookieを削除するためには、Webブラウザを再起動してください。
ただし、「Webブラウザでセッションを保存する」を有効にしている場合、"Webブラウザの再起動では削除されません。Webブラウザの設定に従って、手動でセッションの追跡に使用するcookieを削除してください。
マッピングがなくてもサーブレットが動作する
Java EE機能では、本機能は使用できません。
J2EE機能で本機能を使用していた場合、deployment descriptor(web.xml)にマッピングを記述してください。
「/servlet/サーブレットクラス名」または「/servlet/サーブレット名」にマッピングすることによって、Webアプリケーションのプログラム修正を行わずに移行することが可能です。以下に、修正方法を説明します。
例
サーブレットクラス名で運用していた場合 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> |
サーブレット名で運用していた場合 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)にマッピングを記述して呼び出してください。
ファイルの一覧表示
J2EE機能の場合は、ファイルの一覧表示のリンクに「リクエストURIのエンコーディング」で指定したエンコーディングを使用していました。
Java EE機能の場合は、ファイルの一覧表示のリンクに使用するエンコーディングはUTF-8固定となります。このため、「リクエストURIの解析に使用するエンコーディング」でUTF-8以外のエンコーディングを指定した場合、ファイルの一覧表示画面でマルチバイト文字を含むリンクをクリックしても、ステータスコード404で復帰し、該当のファイルまたはディレクトリを参照できません。
参照できるようにするには、「リクエストURIの解析に使用するエンコーディング」にUTF-8を指定してください。
注意
以下の理由によりセキュリティ上の問題があるため、本製品では「ファイルの一覧表示」の使用を推奨していません。
Webアプリケーション内にあるファイルやディレクトリ構成など、内部構造が外部に漏れてしまう。
Interstage HTTP ServerがBASIC認証した情報の取得について
IJServer(J2EE)では、デフォルトではInterstage HTTP ServerがBASIC認証した情報を使用できません。
Interstage管理コンソールの[システム] > [ワークユニット] > [IJServer] > [配備] > [詳細設定]画面で、設定できます。
Java EEのサーブレットでは、デフォルトでInterstage HTTP ServerがBASIC認証した情報を使用できます。ただし、上記のような設定項目はなく、使用不可にはできません。そのため、Interstage HTTP ServerがBASIC認証した情報を取得できないようにしたい場合はInterstage HTTP Serverを使用するのをやめて、Java EE側でBASIC認証してください。
