5.1.1 サーブレットおよびJSP実装時共通の注意事項

アプリケーションサーバ上で動作するアプリケーションのプログラムとして,サーブレットおよびJSPを実装するときの共通の注意事項を示します。

<この項の構成>
(1) Webアプリケーションの動作の前提となるJ2EEアプリケーションのバージョン
(2) Webアプリケーションのサポート範囲
(3) トランザクションとJDBCコネクション利用時の注意
(4) パッケージ名の指定に関する注意
(5) Cookie利用時の注意
(6) 特別な意味を持つ入力値の表示に関する注意
(7) コミット後のエラーページの表示に関する注意
(8) PrintWriter,JSPWriterクラス利用時の性能向上について
(9) javax.servlet.error.XXXXXによるエラー情報参照時の注意
(10) ファイルアクセス時の注意
(11) 例外発生時のエラーページの設定について
(12) クラスローダの取得に関する注意
(13) URLConnectionクラス使用時の注意
(14) ネイティブライブラリのロードに関する注意
(15) ユーザスレッドの使用方法
(16) セッション情報の永続化について
(17) initメソッドおよびdestroyメソッドをオーバーライドしていない場合に出力されるメッセージ
(18) javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について
(19) バイナリデータを含むWebアプリケーションの操作について
(20) レスポンスの文字エンコーディングに関する注意
(21) javax.serlvet.ServletRequestインタフェースのgetServerNameメソッドおよびgetServerPortメソッドの戻り値について
(22) javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について
(23) javax.servlet.ServletOutputStreamオブジェクトに対するflushメソッドの実行についての注意
(24) リクエストURIの正規化
(25) javax.servlet.http.HttpServletRequestインタフェースのgetRequestURIメソッドおよびgetRequestURLメソッドの戻り値について
(26) welcomeファイルにURLマッピングされたServletまたはJSPの指定
(27) Webアプリケーション開始時の初期化処理の順序

(1) Webアプリケーションの動作の前提となるJ2EEアプリケーションのバージョン

Webアプリケーションの動作の前提となるJ2EEアプリケーションが準拠するJ2EE仕様のバージョンについて,Webアプリケーションのバージョンごとに次の表に示します。

表5-2 J2EEアプリケーションが準拠するJ2EE仕様のバージョン

J2EEアプリケーションが準拠するJ2EE仕様のバージョンWebアプリケーションに対応するServlet仕様
2.52.42.32.2
Java EE 5
J2EE1.4×
J2EE1.3×
J2EE1.2×
(凡例)
○:使用できる
△:使用できる(J2EEアプリケーションのインポート時にJ2EE仕様のバージョンが1.4に更新されるため)
×:使用できない

(2) Webアプリケーションのサポート範囲

Webアプリケーションのバージョンは,web.xmlに記述するServlet仕様のバージョン情報で識別されます。上位のバージョンのWebアプリケーションは下位のバージョンの機能を使用できます。下位のバージョンのWebアプリケーションは上位のバージョンの機能を使用できません。

Webアプリケーションのバージョンごとに,使用できる機能範囲を次の表に示します。

表5-3 Webアプリケーションのサポート範囲

WebアプリケーションのバージョンServletJSPタグライブラリ
2.52.42.32.22.12.01.21.12.12.01.21.1
2.5
2.4×××
2.3××××××
2.2×××××××××

(凡例)○:使用できる ×:使用できない

注※
タグライブラリのバージョンとは,タブライブラリ・ディスクリプタ(TLDファイル)のバージョンを表します。

なお,下位のバージョンのWebアプリケーションから上位のバージョンの機能を使用した場合,エラーが発生することがあります。発生するエラーについてバージョンごとに次に示します。

表5-4 Servlet 2.2,2.3,または2.4仕様に対応するWebアプリケーションからServlet 2.5の機能を使用した場合のエラー

仕様使用する機能エラー時の処理
Servlet 2.5新規APIの呼び出しServlet 2.5仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。
新規アノテーションの使用アノテーションを使用してエラーとなった場合の処理については,マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「11. アノテーションの使用」を参照してください。
JSP 2.1新規ディレクティブの属性※1サーブレットログにKDJE39145-Eのメッセージ,メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2,トランスレーションエラーとなります。
TLD 2.1Webアプリケーション開始時に次に示すTLDファイルが存在した場合,メッセージログにKDJE39293-Wのメッセージが出力され,処理されません。
  • web.xmlの<taglib>要素内の<tablib-location>要素に指定されたTLDファイル
  • /WEB-INF/libディレクトリ以下のJarファイル内の/META-INFディレクトリ以下に配置されたTLDファイル
Webアプリケーション開始時にこれら以外のTLDファイルが存在した場合は,JSPコンパイル時にメッセージログにKDJE39293-Wのメッセージが出力され,処理されません。
アプリケーションへの初回アクセス時などにJSPコンパイルが発生した場合は,サーブレットログにKDJE39145-Eのメッセージ,メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2,トランスレーションエラーとなります。
ELの追加機能
  • JSP 2.1で追加されたEnum型については,専用の処理は実施されないで,一般のクラスと同様に処理されます。
    ただし,JSP 2.1仕様で非推奨となったJSP 2.0仕様のELのAPIを使用した場合,Webアプリケーションのバージョンに関係なく,JSP 2.0仕様のELの機能範囲で処理されます。
  • #{}の書式のELは文字列として表示されます。
  • "¥#"はエスケープシーケンスとして扱われません。「"¥#"」という文字列として表示されます。
注※1
JSPページで<jsp:directive.XXX />形式でXXXにJSP仕様で未定義のディレクティブを指定した場合,または<jsp:XXX>形式でXXXにJSP仕様で未定義のスタンダードアクションを指定した場合,定義内容はそのまま出力されます。
注※2
KDJE39145-EにはJSPのコンパイルエラーの詳細,KDJE39186-Eにはトランスレーションエラーの発生通知が出力されます。

Servlet 2.2仕様,Servlet 2.3仕様およびServlet 2.4仕様から,Servlet 2.5仕様にWebアプリケーションのバージョンアップする場合の作業,および注意事項については,「5.1.8 既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点」を参照してください。

表5-5 Servlet 2.2または2.3仕様に対応するWebアプリケーションからServlet 2.4仕様の機能を使用した場合のエラー

仕様使用する機能エラー時の処理
Servlet 2.4新規APIの呼び出しServlet 2.4仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。
新規リスナ登録Webアプリケーションの開始時にKDJE39297-Wのメッセージがメッセージログに出力され,そのリスナ定義は無視されます。
JSP 2.0新規ディレクティブ新規スタンダードアクション※1サーブレットログにKDJE39145-Eのメッセージ,メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2,トランスレーションエラーとなります。
タグファイル
TLDを使用しない場合
taglibディレクティブで新規属性となるtagdir属性が不正として,サーブレットログにKDJE39145-Eのメッセージ,メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2,トランスレーションエラーとなります。
TLDを使用する場合
TLD 2.0を使用したエラーになります。
TLD 2.0次に示すTLDファイルは,Webアプリケーション開始時にチェックされます。該当する場合,メッセージログにKDJE39293-Wのメッセージが出力され,無視されます。
  • web.xmlの<taglib><tablib-location>に指定されたTLDファイル
  • /WEB-INF/lib下のJarファイル内の/META-INF以下に配置されたTLDファイル
これら以外のTLDファイルは,JSPコンパイル時にチェックされます。初回アクセス時など,JSPファイルのコンパイル時は,サーブレットログにKDJE 39145-Eのメッセージ,メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2,トランスレーションエラーとなります。
シンプル・タグ・ハンドラサーブレットログにKDJE39145-Eのメッセージを,メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2,トランスレーションエラーとなります。
注※1
JSPページで<jsp:directive.XXX />形式でXXXにJSP仕様で未定義のディレクティブを指定した場合,または<jsp:XXX>形式でXXXにJSP仕様で未定義のスタンダードアクションを指定した場合,定義内容はそのまま出力されます。
注※2
KDJE39145-EにはJSPのコンパイルエラーの詳細,KDJE39186-Eにはトランスレーションエラーの発生通知が出力されます。

Servlet 2.2仕様およびServlet 2.3仕様から,Servlet 2.4仕様にWebアプリケーションのバージョンアップする場合の作業,および注意事項については,「5.1.10 既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点」を参照してください。

なお,Servlet 2.2仕様に対応するWebアプリケーションからServlet 2.3の機能を使用しても,アプリケーションのインポート時にServlet 2.3仕様に準拠したWebアプリケーションに書き換えられるため,正常に処理され,エラーは通知されません。

(3) トランザクションとJDBCコネクション利用時の注意

サーブレット,JSPでトランザクションを利用する場合,該当するサービスメソッドでJDBCコネクションを取得し,該当するサービスメソッドが終了する前に解放してください。トランザクションが開始しているサーブレットおよびJSPでは,次に示すJDBCコネクションの使用はサポートされません。

(4) パッケージ名の指定に関する注意

不正なパッケージ名が指定されたクラスをサーブレットおよびJSPで使用した場合,ブラウザからアクセスしたときにステータスコード500のエラーになります。例えば,作成したクラスファイルを正しく配置して,ブラウザからアクセスしても,パッケージ名の宣言に不正があった場合は,該当クラスが見つかりません。この場合,ステータスコード500のエラーが返されます。

(5) Cookie利用時の注意

(6) 特別な意味を持つ入力値の表示に関する注意

フォームなどで「<」や「>」などの特別な意味を持つ文字の入力値をそのまま表示した場合,悪意のあるユーザが<SCRIPT>,<OBJECT>,<APPLET>,<EMBED>のスクリプトなどを実行できるタグを使用して,重大なセキュリティ上の問題を引き起こすおそれがあります。アプリケーション開発者は,ユーザから入力されたデータに対して必ず検査をする処理を追加して,特別な意味を持つ文字を排除する必要があります。

(7) コミット後のエラーページの表示に関する注意

サーブレットまたはJSPでレスポンスがコミットされたあとは,例外などのエラーが発生したとしても,次に示すエラーページはブラウザに表示されません。

レスポンスのコミットは,ユーザがServletResponseクラスのflushBufferメソッドなどを明示的に呼び出してコミットする場合以外にも,レスポンスのバッファが満杯になって自動的にWebコンテナがコミットすることがあります。

サーブレットまたはJSPでコミットされているかどうかを調べるには,ServletResponseクラスのisCommittedメソッドを使用します。また,バッファサイズの変更は,サーブレットの場合はServletResponseクラスのsetBufferSizeメソッドで,JSPの場合はpageディレクティブのbuffer属性の指定で実施できます。

(8) PrintWriter,JSPWriterクラス利用時の性能向上について

PrintWriterクラスおよびJSPWriterクラスのprintメソッドとprintlnメソッドの呼び出し回数を少なくすることで,アクセス回数を減らし,性能を向上できます。例えば,StringBufferクラスを使用し,最後にprintlnメソッドを呼び出すようにして,printおよびprintlnメソッドの呼び出し回数を削減します。

(9) javax.servlet.error.XXXXXによるエラー情報参照時の注意

Servlet 2.3仕様で定義されているjavax.servlet.error.XXXXX属性は,web.xmlの<error-page>タグに指定されたサーブレットまたはJSP内でそのエラーページを実行する要因となったエラー情報を参照するためのものです。web.xmlの<error-page>タグに指定されたサーブレットまたはJSP以外からは,これらの属性を参照しないでください。

(10) ファイルアクセス時の注意

ファイルにアクセスする場合は,必ず絶対パスを指定してください。相対パスを指定すると,J2EEサーバはWebコンテナサーバの実行ディレクトリからの相対パスによって目的のパスを検索しようとします。ServletContextクラスのgetRealPathメソッドで相対パスを指定すると,WARファイルを展開したディレクトリでの相対パスが取得されます。

また,ファイルにアクセスする場合は,必ずファイルをクローズしてください。WARファイル展開ディレクトリでファイルにアクセスしてクローズしないと,J2EEサーバで正常にアンデプロイできなくなります。WARファイルの展開ディレクトリ下のパスを指定していない場合でもファイルをクローズしていないと,J2EEサーバの起動中にファイルを削除できないなどの現象が発生します。

(11) 例外発生時のエラーページの設定について

JSP,サーブレットへのアクセスで例外が発生した場合,Webコンテナのデフォルトの処理では例外のステータスコードをブラウザに返します。このデフォルトの処理を変える場合はJSPのerrorPageの指定やweb.xmlでエラーページを設定してください。

(12) クラスローダの取得に関する注意

J2EEアプリケーション内のコードからCosminexus Component Containerのクラスローダを取得して,次に示すメソッドを使用する場合に,java.net.JarURLConnectionクラスが使用されます。

これらのメソッドが呼び出される過程でjava.net.JarURLConnectionクラスのopenConnectionメソッドが呼び出され,該当するURLに指定されたJARファイルがオープンされます。このJARファイルはcloseメソッドを明示的に呼ばないかぎり,オープンされたままになり削除できません。これらのメソッドはJ2EEアプリケーション内で使用しないでください。また,JARファイルに対する操作が必要でjava.net.JarURLConnectionクラスのopenConnectionメソッドを使用する場合には,該当するJARファイルに対してcloseメソッドを必ず呼び出すようにしてください。

(13) URLConnectionクラス使用時の注意

java.net.URLConnectionクラスはsetUseCaches(boolean)メソッドを使用して,指定されたURLに対してコネクションを取得するときにキャッシュの情報を利用するかどうかを指定できます。URLConnectionクラスに対してsetUseCaches(false)メソッドを指定した場合に,コネクションごとに対象のオブジェクトが生成されます。J2EEアプリケーション内のコードから使用する場合には,J2EEサーバのJavaVMがメモリ不足となるおそれがあります。

(14) ネイティブライブラリのロードに関する注意

System.loadLibraryメソッドを使用して,サーブレットおよびJSPからネイティブライブラリをロードしないでください。サーブレットおよびJSPでネイティブライブラリをロードすると,JNI仕様の制約によって,java.lang.UnsatisfiedLinkErrorが発生することがあります。ネイティブライブラリのロードが必要な場合は,System.loadLibraryメソッドを呼び出すコンテナ拡張ライブラリを作成し,サーブレットおよびJSPからコンテナ拡張ライブラリを参照するように実装してください。コンテナ拡張ライブラリの作成については,マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「13. コンテナ拡張ライブラリ」を参照してください。

(15) ユーザスレッドの使用方法

アプリケーションを構成するサーブレットおよびJSPからスレッドを生成して,使用できます。ユーザがプログラムの中で明示して生成するスレッドのことを,ユーザスレッドといいます。

ユーザスレッドは,生成後の動作のしかた(ライフサイクル)によって,次の二つに分けられます。

ユーザスレッドの使用条件
  • ユーザスレッドは,Enterprise Beanでは使用できません(EJB仕様で,Enterprise Beanからのスレッドの生成が禁止されているため)。
  • ユーザスレッドが使用できるアプリケーションサーバのサーバモードを次に示します。

    表5-6 ユーザスレッドの前提条件(サーバモード)

    サーバモード使用可否
    J2EEサーバモード1.4モード
    ベーシックモード
    サーブレットエンジンモード
    (凡例)
    ○:使用できる
    △:サーバモード(ベーシックモードまたはサーブレットエンジンモード)でサポートされている範囲で機能を使用できます。ただし,コネクションプールは使用できません。

ユーザスレッドを使用する場合のライフサイクルについて説明します。

(a) サービスメソッドやinitメソッドの範囲内で動作させる場合

サービスメソッドやinitメソッドでユーザスレッドの処理を完了させるモデルです。このモデルの処理の流れを次の図に示します。

図5-1 サービスメソッドやinitメソッドの範囲内で動作させる場合の処理

[図データ]

サービスメソッドやinitメソッドの呼び出しの範囲内で,ユーザスレッドを生成します。サービスメソッドやinitメソッドでは,joinメソッドによってユーザスレッドの処理が完了するのを待ってから,リターンします。

(b) サービスメソッドやinitメソッドのバックグラウンドで動作させる場合

サービスメソッドやinitメソッドでユーザスレッドを生成し,その後ユーザスレッドをバックグラウンドで動作させるモデルです。このモデルの処理の流れを次の図に示します。

図5-2 サービスメソッドやinitメソッドのバックグラウンドで動作させる場合の処理

[図データ]

ユーザスレッドを生成したサービスメソッドやinitメソッドは,ユーザスレッドを生成したあと,処理の完了を待たないでリターンします。ただし,アプリケーションを停止したあとは,ユーザスレッドからJ2EEサービスを利用できなくなります。したがって,アプリケーションの停止によってサーブレットやJSPのdestroyメソッドが呼ばれる前に,ユーザスレッドの処理を完了しておく必要があります。

(16) セッション情報の永続化について

Webコンテナではセッション情報の永続化はサポートされません。Webコンテナではセッション情報は,正常,異常に関係なくWebコンテナが終了すると失われます。セッション情報を保持したい場合は,セッションフェイルオーバ機能を使用してください。

また,web.xmlで<distributable>タグを指定した場合,およびSerializableでないオブジェクトをセッション情報として登録した場合もIllegalArgumentExceptionは発生しません。

(17) initメソッドおよびdestroyメソッドをオーバーライドしていない場合に出力されるメッセージ

initメソッドおよびdestroyメソッドをオーバーライドしていないサーブレットを初期化または終了すると,次の形式のログがサーブレットログに出力されます。

また,JSPの場合は,pageディレクティブのextends属性で指定するJSPの基底クラスでinitメソッドおよびdestroyメソッドをオーバーライドしなかった場合,同様のメッセージが出力されます。その場合,サーブレット名は"com.hitachi.software.web.servlet-name.jsp"となります。JSPでpageディレクティブのextends属性を指定しなかった場合は,initメソッドのログだけが出力され,destroyメソッドのログは出力されません。

ただし,サーブレットの場合もJSPの場合も,initメソッドおよびdestroyメソッドをオーバーライドしてスーパークラスのinitメソッドおよびdestroyメソッドを呼ぶときは,このメッセージを出力します。

(18) javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について,Servletで例外をスローした場合とJSPファイルで例外をスローした場合の二つに分けて説明します。

(a) Servletで例外をスローした場合
Servletでスローした例外クラスがjava.lang.Error,またはその派生クラスの場合
javax.servlet.ServletExceptionクラスの例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。Servletでスローした例外は,javax.servlet.ServletExceptionクラスのgetRootCauseメソッドで取得できます。
Servletでスローした例外クラスがjava.lang.Error,またはその派生クラス以外のクラスの場合
Servletでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。
(b) JSPファイルで例外をスローした場合
●エラーページがJSPファイルの場合
web.xmlの<error-page>タグでエラーページを指定した場合
web.xmlの<error-page>タグでエラーページを指定した場合について,JSP 2.0以降とJSP 1.2に分けて示します。
JSP 2.0以降
JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。
JSP 1.2
JSPファイルでスローした例外クラスが次のクラスのどれかであれば,JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。
  • java.io.IOException,またはその派生クラス
  • java.lang.RuntimeException,またはその派生クラス
  • javax.servlet.ServletException,またはその派生クラス
JSPファイルでスローした例外クラスがこれら以外の場合,javax.servlet.ServletExceptionクラスの例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。JSPファイルでスローした例外は,javax.servlet.ServletExceptionクラスのgetRootCauseメソッドで取得できます。
pageディレクティブのerrorPage属性でエラーページを指定した場合
pageディレクティブのerrorPage属性でエラーページを指定した場合について,エラーページでpageディレクティブのisErrorPage属性にtrueを指定した場合とfalseを指定した場合に分けて示します。
エラーページでpageディレクティブのisErrorPage属性にtrueを指定した場合
JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。
エラーページでpageディレクティブのisErrorPage属性にfalseを指定した場合
javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に値は設定されません。
●エラーページがServletの場合
web.xmlの<error-page>タグでエラーページを指定した場合
エラーページがJSPファイルの場合の,web.xmlの<error-page>タグでエラーページを指定した場合と同様です。
pageディレクティブのerrorPage属性でエラーページを指定した場合
javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に値は設定されません。

(19) バイナリデータを含むWebアプリケーションの操作について

バイナリデータを含むWebアプリケーションでは,次のことに注意してください。

(20) レスポンスの文字エンコーディングに関する注意

JSPまたはサーブレットのレスポンスボディの文字エンコーディングが,UTF-16(16ビットUCS変換形式)の場合,ブラウザによって正しく表示できない場合があります。その場合は,JSPまたはサーブレットの文字エンコーディングに,UTF-16BE(16ビットUCS変換形式のビッグエンディアンバイト順),またはUTF-16LE(16ビットUCS変換形式のリトルエンディアンバイト順)を使用してください。

(21) javax.serlvet.ServletRequestインタフェースのgetServerNameメソッドおよびgetServerPortメソッドの戻り値について

getServerNameメソッド,およびgetServerPortメソッドの戻り値について説明します。

Servlet 2.4仕様以降では,Hostヘッダの有無によって,getServerNameメソッド,およびgetServerPortメソッドの戻り値が異なります。Servlet 2.4仕様以降でのgetServerNameメソッド,およびgetServerPortメソッドの戻り値を次の表に示します。

表5-7 getServerNameメソッド,およびgetServerPortメソッドの戻り値(Servlet 2.4仕様以降の場合)

Hostヘッダの有無getServerNameメソッドの戻り値getServerPortメソッドの戻り値
ありHostヘッダの「:」より前の部分Hostヘッダの「:」よりあとの部分
なし解決されたサーバ名またはIPアドレスクライアントとの接続を受け付けたサーバのポート番号

アプリケーションサーバでは,getServerNameメソッド,およびgetServerPortメソッドの戻り値は,HTTPリクエストと,使用する機能の組み合わせによって得られます。なお,HTTP 1.1のリクエストにHostヘッダが含まれない場合,HTTP 1.1仕様に従って,400エラーとなります。また,HTTP 1.1仕様では,リクエストラインのリクエストURIが絶対URIの場合,ホストにはリクエストURIのホストを使用して,Hostヘッダの内容は無視するように定義されています。なお,Servlet仕様では明記されていませんが,HTTP仕様に従って,リクエストラインのURIに含まれるホスト名を優先するようになっています。

HTTPリクエストと,使用する機能の組み合わせによって得られる,getServerNameメソッド,およびgetServerPortメソッドの戻り値を次の表に示します。なお,ゲートウェイ指定機能を使用している場合の,getServerNameメソッド,およびgetServerPortメソッドの戻り値については,表5-8を参照してください。

表5-8 getServerNameメソッド,およびgetServerPortメソッドの戻り値(アプリケーションサーバの場合)

HTTPリクエスト使用する機能getServerNameメソッドの戻り値getServerPortメソッドの戻り値
Hostヘッダの有無リクエストラインのURIの種類
あり絶対URIWebサーバ連携リクエストラインのホスト名リクエストラインのポート番号
インプロセスHTTPサーバリクエストラインのホスト名リクエストラインのポート番号
簡易WebサーバHostヘッダのホスト名Hostヘッダのポート番号
相対URIWebサーバ連携Hostヘッダのホスト名Hostヘッダのポート番号
インプロセスHTTPサーバHostヘッダのホスト名Hostヘッダのポート番号
簡易WebサーバHostヘッダのホスト名Hostヘッダのポート番号
なし絶対URIWebサーバ連携リクエストラインのホスト名リクエストラインのポート番号
インプロセスHTTPサーバリクエストラインのホスト名リクエストラインのポート番号
簡易WebサーバJ2EEサーバのホスト名またはIPアドレス※1簡易Webサーバのポート番号
相対URIWebサーバ連携Webサーバのホスト名またはIPアドレス※2Webサーバのポート番号
インプロセスHTTPサーバJ2EEサーバのホスト名またはIPアドレス※1インプロセスHTTPサーバのポート番号
簡易WebサーバJ2EEサーバのホスト名またはIPアドレス※1簡易Webサーバのポート番号

注※1 java.net.InetAddress.getLocalHostメソッド,またはgetHostNameメソッドの戻り値となります。

注※2 Hitachi Web Serverを使用する場合,ServerNameディレクティブに指定した値となります。ServerNameディレクティブについては,マニュアル「Hitachi Web Server」を参照してください。


ゲートウェイ指定機能使用時のgetServerNameメソッド,およびgetServerPortメソッドの戻り値を次の表に示します。

表5-9 ゲートウェイ指定機能使用時のgetServerNameメソッド,およびgetServerPortメソッドの戻り値(アプリケーションサーバの場合)

HTTPリクエスト使用する機能getServerNameメソッドの戻り値getServerPortメソッドの戻り値
Hostヘッダの有無リクエストラインのURIの種類
あり絶対URIWebサーバ連携リクエストラインのホスト名リクエストラインのポート番号
インプロセスHTTPサーバリクエストラインのホスト名リクエストラインのポート番号
相対URIWebサーバ連携Hostヘッダのホスト名Hostヘッダのポート番号
インプロセスHTTPサーバHostヘッダのホスト名Hostヘッダのポート番号
なし絶対URIWebサーバ連携ゲートウェイ指定機能で指定したホスト名ゲートウェイ指定機能で指定したポート番号
インプロセスHTTPサーバリクエストラインのホスト名リクエストラインのポート番号
相対URIWebサーバ連携ゲートウェイ指定機能で指定したホスト名ゲートウェイ指定機能で指定したポート番号
インプロセスHTTPサーバゲートウェイ指定機能で指定したホスト名ゲートウェイ指定機能で指定したポート番号

(22) javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について

アプリケーションサーバでは,コンストラクタServletException(String, Throwable)またはServletException(Throwable)で指定した根本原因の例外をgetCauseメソッドで取得できます。なお,getRootCauseメソッドでも取得できます。ただし,07-60以前のバージョンではgetCauseメソッドにはnullを返します。

javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について,互換用のパラメタおよび注意事項について説明します。

(23) javax.servlet.ServletOutputStreamオブジェクトに対するflushメソッドの実行についての注意

アプリケーションサーバでは,javax.serlvet.ServletResponseオブジェクトから取得するjavax.servlet.ServletOutputStreamオブジェクトに対して,closeメソッドを実行したあとでflushメソッドを実行しても,java.io.IOException例外をスローしません。

(24) リクエストURIの正規化

アプリケーションサーバでは,リクエストURIに含まれる文字列は,正規化されたあと,次に示すマッチング処理で使用されます。

(25) javax.servlet.http.HttpServletRequestインタフェースのgetRequestURIメソッドおよびgetRequestURLメソッドの戻り値について

javax.servlet.http.HttpServletRequestインタフェースのgetRequestURIメソッドおよびgetRequestURLメソッドでは,正規化されたURLが戻り値となります。

(26) welcomeファイルにURLマッピングされたServletまたはJSPの指定

リクエストURLがURLマッピングされたServletまたはJSPと一致しないで,welcomeファイルに転送される必要がある場合,Webコンテナでは次のように転送先のwelcomeファイルが選択されます。

まず,指定されたwelcomeファイル名から静的コンテンツやJSPファイルの候補が優先して選択されます。該当するものがない場合,URLマッピングされたServletまたはJSPの候補が選択されます。

welcomeファイルに関する注意事項について説明します。

●welcomeファイル転送方式による制約

welcomeファイルの転送は,HTTPリダイレクト(HTTPステータスコード302でブラウザがリダイレクトする)によって実現しています。この転送方式には制約があるため,URL設計の際に次のことに注意してください。

●JSP事前コンパイル済み環境でのwelcomeファイルの追加

JSP事前コンパイル済みのWebアプリケーションに,welcomeファイルに指定したJSPファイルを追加する場合,JSPファイルの追加後にJSP事前コンパイルを再度実行する必要があります。JSP事前コンパイルを再度実行しなかった場合,正しくwelcomeファイル転送処理が実行されません。

●サーブレットクラスが参照できないサーブレットのwelcomeファイルの指定

サーブレットクラスが参照できないサーブレットをwelcomeファイルに指定しないでください。サーブレットクラスが参照できないサーブレットを指定した場合,正しくwelcomeファイル転送処理が実行されません。

●ディレクトリが存在しないパスへのwelcomeファイル要求

Webアプリケーション内のリソースとして存在しないディレクトリのパスに対するリクエストの場合,リクエストURLの末尾が「/」であってもwelcomeファイル転送処理は実行されません。

(27) Webアプリケーション開始時の初期化処理の順序

Webアプリケーションを開始すると,リクエストの受付を開始する前に次の順序で初期化処理をすることがServlet 2.4仕様で明確化されました。Cosminexusでは,Servlet2.3以前のWebアプリケーションでも同じ順序で初期化処理をします。初期化処理の順序を次に示します。

  1. web.xmlの<listener>要素に定義されたそれぞれのイベントリスナのインスタンスを作成します。
  2. ServletContextListenerを実装しているリスナのインスタンスに対して,contextInitialized()メソッドを呼び出します
  3. web.xmlの<filter>要素に指定したフィルタのインスタンスを作成し,フィルタの init()メソッドを呼び出します。
  4. web.xmlの<servlet>要素に<load-on-startup>要素を含むサーブレットについて,<load-on-startup>要素の値で定義された順番でサーブレットのインスタンスを作成し,サーブレットのinit()メソッドを呼び出します。
注※
リスナのcontextInitialized()メソッドの呼び出しで例外が発生しても,KDJE39103-Eのメッセージを出力してWebアプリケーションの開始処理を継続します。