Cosminexus アプリケーションサーバ V8

機能解説 基本・開発編(Webコンテナ)

解説書

3020-3-U05-40

目　　次

前書き

変更内容

はじめに

1.　アプリケーションサーバの機能

1.1　機能の分類

1.1.1　アプリケーションの実行基盤としての機能

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

1.1.3　機能とマニュアルの対応

1.2　システムの目的と機能の対応

1.2.1　Webコンテナの機能

1.2.2　Webサーバ連携の機能

1.2.3　インプロセスHTTPサーバの機能

1.3　このマニュアルに記載している機能の説明

1.3.1　分類の意味

1.3.2　分類を示す表の例

1.4　アプリケーションサーバ 08-70での主な機能変更

2.　Webコンテナ

2.1　この章の構成

2.2　Webアプリケーションの実行機能

2.2.1　Webアプリケーションのデプロイとアンデプロイ

2.2.2　Webアプリケーションのデプロイとアンデプロイの注意事項

2.3　JSPの実行機能

2.3.1　JSPの実行機能の概要

2.3.2　タグファイルの実行

2.3.3　JSP ELの実行

2.3.4　タグライブラリのJ2EEアプリケーションへの格納

2.3.5　カスタムタグの属性名チェック

2.3.6　<jsp:useBean>タグのid属性重複チェック

2.3.7　page/tagディレクティブのimport属性暗黙インポート

2.4　JSPデバッグ機能

2.4.1　JSPデバッグ機能の仕組み

2.4.2　JSPデバッグ機能の使用手順

2.4.3　実行環境での設定（J2EEサーバの設定）

2.4.4　JSPデバッグ機能使用時の注意事項

2.5　JSP事前コンパイル機能とコンパイル結果の保持

2.5.1　JSP事前コンパイル機能の概要

2.5.2　JSP事前コンパイルの方法

2.5.3　JSP事前コンパイルの適用例

2.5.4　JSP事前コンパイルの実行時の処理

2.5.5　JSPコンパイル結果のライフサイクルと出力先

2.5.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果

2.5.7　JSPコンパイル結果のクラス名

2.5.8　実行環境での設定（J2EEサーバの設定）

2.6　デフォルトの文字エンコーディング設定機能

2.6.1　デフォルトの文字エンコーディングの設定単位

2.6.2　デフォルトの文字エンコーディングの適用個所と適用条件

2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用

2.6.4　設定できる文字エンコーディング

2.6.5　デフォルトの文字エンコーディングの実装（Servlet仕様の場合）

2.6.6　DDでの定義

2.6.7　実行環境での設定

2.6.8　デフォルトの文字エンコーディングの注意事項

2.7　セッション管理機能

2.7.1　セッション情報を管理するオブジェクト

2.7.2　セッションIDの形式

2.7.3　セッションの管理方法

2.7.4　Webクライアントが保持する無効なセッションIDの削除

2.7.5　HttpSessionオブジェクト数の上限値の設定

2.7.6　セッションIDおよびCookieへのサーバIDの付加

2.7.7　cosminexus.xmlでの定義

2.7.8　実行環境での設定

2.7.9　セッション管理の注意事項

2.8　アプリケーションのイベントリスナ

2.9　リクエストおよびレスポンスのフィルタリング機能

2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）

2.9.2　フィルタ連鎖の推奨例

2.9.3　DDでの定義

2.9.4　実行環境での設定（Webアプリケーションの設定）

2.10　HTTPレスポンス圧縮機能

2.10.1　HTTPレスポンス圧縮フィルタの概要

2.10.2　HTTPレスポンス圧縮フィルタを使用するための条件

2.10.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

2.10.4　DDでの定義

2.10.5　DDの定義例

2.10.6　実行環境での設定（Webアプリケーションの設定）

2.11　EJBコンテナとの連携

2.11.1　Enterprise Beanの呼び出し方法

2.11.2　EJBコンテナとの連携のための実装

2.11.3　実行環境での設定（J2EEサーバの設定）

2.12　データベースとの接続

2.13　Webコンテナによるスレッドの作成

2.13.1　作成するスレッドの種類と数

2.13.2　作成するスレッドの総数

2.14　ユーザスレッドの使用

2.14.1　ユーザスレッドでの機能の使用可否

2.14.2　ユーザスレッド生成のための権限の設定

2.15　同時実行スレッド数の制御の概要

2.15.1　スレッド数を制御する単位

2.15.2　同時実行スレッド数制御のパラメタ

2.15.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

2.16　Webコンテナ単位での同時実行スレッド数の制御

2.16.1　同時実行スレッド数の制御の仕組み（Webコンテナ単位）

2.16.2　実行環境での設定（J2EEサーバの設定）

2.17　Webアプリケーション単位での同時実行スレッド数の制御

2.17.1　同時実行スレッド数の制御の仕組み（Webアプリケーション単位）

2.17.2　同時実行スレッド数の制御に必要なパラメタ（Webアプリケーション単位）

2.17.3　同時実行スレッド数設定の指針（Webアプリケーション単位）

2.17.4　cosminexus.xmlでの定義

2.17.5　実行環境での設定

2.17.6　同時実行スレッド数および実行待ちキューサイズの設定例（Webアプリケーション単位）

2.17.7　Webアプリケーション単位での同時実行スレッド数制御についての注意事項

2.18　URLグループ単位での同時実行スレッド数の制御

2.18.1　同時実行スレッド数の制御の仕組み（URLグループ単位）

2.18.2　URLパターンのマッピング処理

2.18.3　同時実行スレッド数の制御に必要なパラメタ（URLグループ単位）

2.18.4　同時実行スレッド数設定の指針（URLグループ単位）

2.18.5　cosminexus.xmlでの定義

2.18.6　実行環境での設定（Webアプリケーションの設定）

2.18.7　同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

2.19　同時実行スレッド数の動的変更

2.19.1　同時実行スレッド数の動的変更の概要

2.19.2　同時実行スレッド数の動的変更の流れ

2.19.3　同時実行スレッド数を動的に変更したときのWebアプリケーションの動作

2.19.4　同時実行スレッド数の動的変更についての注意事項

2.20　エラーページのカスタマイズ

2.21　静的コンテンツのキャッシュ

2.21.1　静的コンテンツのキャッシュの制御

2.21.2　DDでの定義（Webアプリケーション単位での設定）

2.21.3　実行環境での設定

2.22　簡易Webサーバ機能

2.22.1　簡易WebサーバでのIPアドレス指定（バインド先アドレス設定機能）

2.22.2　簡易Webサーバへのアクセスの制御

2.22.3　実行環境での設定（J2EEサーバの設定）

2.23　URIのデコード機能

2.23.1　URIのデコード機能の概要

2.23.2　実行環境での設定（J2EEサーバの設定）

2.23.3　URIのデコード機能を使用する場合の注意事項

2.24　 Webアプリケーションのバージョン設定機能

2.24.1　Webアプリケーションのバージョン設定機能の概要

2.24.2　 JSPファイルおよびタグファイルのコンパイルと実行

2.24.3　実行環境での設定

2.24.4　Webアプリケーションのバージョン指定機能を使用する場合の注意事項

2.25　POSTデータ最大サイズについての注意事項

3.　Webサーバ連携

3.1　この章の構成

3.2　Webサーバ（リダイレクタ）によるリクエストの振り分け

3.2.1　リダイレクタを使用したリクエスト振り分けの仕組み

3.2.2　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）

3.2.3　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）

3.2.4　Webサーバ連携時の注意事項

3.3　URLパターンでのリクエストの振り分け

3.3.1　URLパターンでのリクエストの振り分けの概要

3.3.2　URLパターンの種類と適用されるパターンの優先順位

3.3.3　実行環境での設定（Smart Composer機能を使用する場合）

3.3.4　実行環境での設定（Smart Composer機能を使用しない場合）

3.4　ラウンドロビン方式によるリクエストの振り分け

3.4.1　ラウンドロビン方式によるリクエストの振り分けの概要

3.4.2　ラウンドロビン方式によるリクエストの振り分けの例

3.4.3　ラウンドロビン方式によるリクエストの振り分けの定義

3.4.4　実行環境での設定（Smart Composer機能を使用する場合）

3.4.5　実行環境での設定（Smart Composer機能を使用しない場合）

3.4.6　ラウンドロビン方式によるリクエストの振り分けに関する注意事項

3.5　POSTデータサイズでのリクエストの振り分け

3.5.1　POSTデータサイズでのリクエストの振り分けの概要

3.5.2　POSTデータサイズによるリクエストの振り分けの例

3.5.3　リクエストの振り分け条件

3.5.4　POSTデータサイズによるリクエストの振り分けの定義

3.5.5　実行環境での設定（Smart Composer機能を使用する場合）

3.5.6　実行環境での設定（Smart Composer機能を使用しない場合）

3.6　通信タイムアウト（Webサーバ連携）

3.6.1　リクエスト送受信時の通信タイムアウト

3.6.2　レスポンス送受信時の通信タイムアウト

3.6.3　通信タイムアウトの設定

3.6.4　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

3.6.5　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

3.6.6　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

3.6.7　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

3.7　IPアドレス指定（Webサーバ連携）

3.7.1　バインド先アドレス設定機能

3.7.2　実行環境での設定（J2EEサーバの設定）

3.7.3　Webサーバ連携でのIPアドレス指定をする場合の注意事項

3.8　エラーページのカスタマイズ（Webサーバ連携）

3.8.1　エラーページのカスタマイズの概要

3.8.2　エラーページのカスタマイズの仕組み

3.8.3　実行環境での設定（Smart Composer機能を使用する場合）

3.8.4　実行環境での設定（Smart Composer機能を使用しない場合）

3.8.5　エラーページのカスタマイズの注意事項

3.9　ドメイン名指定でのトップページの表示

3.9.1　ドメイン名指定でのトップページの表示について

3.9.2　実行環境での設定（Smart Composer機能を使用する場合）

3.9.3　実行環境での設定（Smart Composer機能を使用しない場合）

3.10　Webコンテナへのゲートウェイ情報の通知

3.10.1　ゲートウェイ指定機能

3.10.2　実行環境での設定（Smart Composer機能を使用する場合）

3.10.3　実行環境での設定（Smart Composer機能を使用しない場合）

3.10.4　Webコンテナにゲートウェイ情報を通知する場合の注意事項

4.　インプロセスHTTPサーバ

4.1　この章の構成

4.2　インプロセスHTTPサーバの概要

4.2.1　インプロセスHTTPサーバの使用

4.2.2　インプロセスHTTPサーバで使用できる機能

4.2.3　実行環境での設定（J2EEサーバの設定）

4.3　Webクライアントからの接続数の制御

4.3.1　Webクライアントからの接続数の制御の概要

4.3.2　実行環境での設定（J2EEサーバの設定）

4.4　リクエスト処理スレッド数の制御

4.4.1　リクエスト処理スレッド数の制御の概要

4.4.2　実行環境での設定（J2EEサーバの設定）

4.5　Webクライアントからの同時接続数の制御によるリクエストの流量制御

4.5.1　Webクライアントからの同時接続数の制御

4.5.2　実行環境での設定（J2EEサーバの設定）

4.6　同時実行スレッド数の制御によるリクエストの流量制御

4.6.1　同時実行スレッド数の制御によるリクエストの流量制御の概要

4.6.2　実行環境での設定（J2EEサーバの設定）

4.7　リダイレクトによるリクエストの振り分け

4.7.1　URLパターンによるリクエストの振り分け

4.7.2　レスポンスのカスタマイズ

4.7.3　実行環境での設定（J2EEサーバの設定）

4.7.4　リダイレクトによるリクエストの振り分けに関する注意事項

4.8　Persistent ConnectionによるWebクライアントとの通信制御

4.8.1　Persistent Connectionによる通信制御

4.8.2　実行環境での設定（J2EEサーバの設定）

4.9　通信タイムアウト（インプロセスHTTPサーバ）

4.9.1　通信タイムアウトの概要

4.9.2　実行環境での設定（J2EEサーバの設定）

4.10　IPアドレス指定（インプロセスHTTPサーバ）

4.10.1　バインド先アドレス設定機能

4.10.2　実行環境での設定（J2EEサーバの設定）

4.10.3　インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項

4.11　アクセスを許可するホストの制限によるアクセス制御

4.11.1　アクセスを許可するホストの制限

4.11.2　実行環境での設定（J2EEサーバの設定）

4.12　リクエストデータのサイズの制限によるアクセス制御

4.12.1　リクエストデータのサイズの制限

4.12.2　実行環境での設定（J2EEサーバの設定）

4.13　有効なHTTPメソッドの制限によるアクセス制御

4.13.1　有効なHTTPメソッドの制限

4.13.2　実行環境での設定（J2EEサーバの設定）

4.14　HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

4.14.1　HTTPレスポンスヘッダのカスタマイズ

4.14.2　実行環境での設定（J2EEサーバの設定）

4.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）

4.15.1　カスタマイズできるエラーページ

4.15.2　エラーページのカスタマイズを実行する場合に必要な実装

4.15.3　実行環境での設定（J2EEサーバの設定）

4.15.4　エラーページのカスタマイズに関する注意事項

4.16　Webコンテナへのゲートウェイ情報の通知

4.16.1　ゲートウェイ指定機能

4.16.2　実行環境での設定（J2EEサーバの設定）

4.16.3　Webコンテナにゲートウェイ情報を通知する場合の注意事項

4.17　ログ・トレースの出力

4.17.1　インプロセスHTTPサーバが出力するログ・トレース

4.17.2　インプロセスHTTPサーバのアクセスログのカスタマイズ

5.　サーブレットおよびJSPの実装

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

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

5.1.2　サーブレット実装時の注意事項

5.1.3　Servlet 2.5仕様で追加，変更された仕様についての注意事項

5.1.4　Servlet 2.4仕様で追加，変更された仕様についての注意事項

5.1.5　JSP実装時の注意事項

5.1.6　JSP 2.1仕様で追加，変更された仕様についての注意事項

5.1.7　JSP 2.0仕様で追加，変更された仕様についての注意事項

5.1.8　既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点

5.1.9　前バージョンから08-00へ移行する場合のWebアプリケーションに関する注意事項

5.1.10　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

5.1.11　サーブレットでのアノテーションの使用

5.1.12　JavaVMのメソッドサイズ制限についての注意事項

5.2　JSP移行時の注意事項

5.2.1　カスタムタグのスクリプト変数の定義に関する注意事項

5.2.2　<jsp:useBean>タグのclass属性に関する注意事項

5.2.3　タグの属性値のExpressionチェックに関する注意事項

5.2.4　タグの属性値に指定するExpressionに関する注意事項

5.2.5　taglibディレクティブのprefix属性に関する注意事項

付録

付録A　エラーステータスコード

付録A.1　Webコンテナが返すエラーステータスコード

付録A.2　リダイレクタが返すエラーステータスコード

付録A.3　インプロセスHTTPサーバが返すエラーステータスコード

付録B　Hitachi Web Serverの設定に関する注意事項

付録B.1　Hitachi Web Serverの再起動時の注意事項

付録B.2　リダイレクタのログに関する注意事項

付録B.3　Hitachi Web Serverのアップグレード時の注意事項

付録C　Microsoft IISの設定

付録C.1　Microsoft IIS 6.0の設定

付録C.2　Microsoft IIS 7.0またはMicrosoft IIS 7.5の設定

付録D　Web Redirector

付録D.1　Web Redirectorのインストール手順

付録D.2　環境変数の設定

付録D.3　Webサーバの設定

付録D.4　Web Redirectorのディレクトリ構成

付録D.5　Web Redirectorの機能

付録E　各バージョンでの主な機能変更

付録E.1　08-53での主な機能変更

付録E.2　08-50での主な機能変更

付録E.3　08-00での主な機能変更

付録F　このマニュアルの参考情報

付録F.1　関連マニュアル

付録F.2　マニュアル体系の変更について

付録F.3　このマニュアルでの表記

付録F.4　英略語

付録F.5　KB（キロバイト）などの単位表記について

付録G　用語解説

索引

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2008, 2011, Hitachi, Ltd.

前書き

■ 対象製品

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64）※¹，Windows Server 2003 R2（x64）※¹，Windows Server 2008 x86，Windows Server 2008 x64※¹，Windows Server 2008 R2※¹

P-2443-7B84　 uCosminexus Application Server Standard-R　 08-70
P-2443-7D84　 uCosminexus Application Server Standard　 08-70
P-2443-7K84　 uCosminexus Application Server Enterprise　 08-70
P-2443-7M84　 uCosminexus Web Redirector　 08-70
P-2443-7S84　 uCosminexus Service Platform　 08-70※2

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Vista，Windows XP，Windows 7（32bit），Windows 7（x64）※¹

P-2443-7E84　 uCosminexus Developer Standard　 08-70
P-2443-7F84　 uCosminexus Developer Professional　 08-70
P-2443-7T84　 uCosminexus Service Architect　 08-70※2

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64）※¹，Windows Server 2003 R2（x64）※¹，Windows Server 2008 x86，Windows Server 2008 x64※¹，Windows Server 2008 R2※¹，Windows Vista，Windows XP，Windows 7（32bit），Windows 7（x64）※¹

P-2443-7H84　 uCosminexus Client　 08-70

●適用OS：Windows Server 2003（x64），Windows Server 2003 R2（x64），Windows Server 2008 x64，Windows Server 2008 R2

P-2943-7B84　 uCosminexus Application Server Standard-R　 08-70
P-2943-7D84　 uCosminexus Application Server Standard　 08-70
P-2943-7K84　 uCosminexus Application Server Enterprise　 08-70
P-2943-7S84　 uCosminexus Service Platform　 08-70※2

●適用OS：AIX 5L V5.3，AIX V6.1，AIX V7.1

P-1M43-7D81　 uCosminexus Application Server Standard　 08-70※2
P-1M43-7K81　 uCosminexus Application Server Enterprise　 08-70※2
P-1M43-7S81　 uCosminexus Service Platform　 08-70※2

●適用OS：HP-UX 11i V2（IPF），HP-UX 11i V3（IPF）

P-1J43-7D81　 uCosminexus Application Server Standard　 08-70
P-1J43-7K81　 uCosminexus Application Server Enterprise　 08-70
P-1J43-7S81　 uCosminexus Service Platform　 08-70※2

●適用OS：Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux 5 Advanced Platform（x86），Red Hat Enterprise Linux 5（x86），Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64），Red Hat Enterprise Linux 5（AMD/Intel 64），Red Hat Enterprise Linux Server 6（32-bit x86），Red Hat Enterprise Linux Server 6（64-bit x86_64）

P-9S43-7B81　 uCosminexus Application Server Standard-R　 08-70※2
P-9S43-7D81　 uCosminexus Application Server Standard　 08-70※2
P-9S43-7K81　 uCosminexus Application Server Enterprise　 08-70※2
P-9S43-7M81　 uCosminexus Web Redirector　 08-70※2
P-9S43-7S81　 uCosminexus Service Platform　 08-70※2

注※1　WOW64（Windows On Windows 64）環境だけで使用できます。
注※2　この製品については，サポート時期をご確認ください。
これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。
本製品では日立トレース共通ライブラリをインストールします。

■ 輸出時の注意

本製品を輸出される場合には，外国為替および外国貿易法ならびに米国の輸出管理関連法規などの規制をご確認の上，必要な手続きをお取りください。
なお，ご不明な場合は，弊社担当営業にお問い合わせください。

■ 商標類

Active Directoryは，米国Microsoft Corporationの，米国およびその他の国における登録商標または商標です。
AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
AX2000は，A10 Networks, Inc.の商品名称です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
gzipは，米国FSF(Free Software Foundation)が配布しているソフトウェアです。
HP-UXは，Hewlett-Packard Companyのオペレーティングシステムの名称です。
HP C/HP-UXは，Hewlett-Packard Companyの商品名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
J2EEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Javaは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JavaScriptは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDBCは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDKは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSPは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corporationの商品名称です。
MyEclipseは，米国Genuitec社の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 11gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
Solarisは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
すべてのSPARC商標は，米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は，米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。
Sunは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sun Microsystemsは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Vistaは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

■ マイクロソフト製品のスクリーンショットの使用について

Microsoft Corporationのガイドラインに従って画面写真を使用しています。

■ マイクロソフト製品の表記について

このマニュアルでは，マイクロソフト製品の名称を次のように表記しています。

製品名 | 表記
Microsoft(R) Active Directory(R) | Active Directory
Microsoft(R) Internet Information Services 6.0 | Microsoft IIS 6.0 | Microsoft IIS
Microsoft(R) Internet Information Services 7.0 | Microsoft IIS 7.0
Microsoft(R) Internet Information Services 7.5 | Microsoft IIS 7.5
Microsoft(R) Windows(R) 7 Enterprise（32bit） | Windows 7（32bit） | Windows 7 | Windows
Microsoft(R) Windows(R) 7 Professional（32bit）
Microsoft(R) Windows(R) 7 Ultimate（32bit）
Microsoft(R) Windows(R) 7 Enterprise（x64） | Windows 7（x64）
Microsoft(R) Windows(R) 7 Professional（x64）
Microsoft(R) Windows(R) 7 Ultimate（x64）
Microsoft(R) Windows Server(R) 2003，Enterprise Edition 日本語版 | Windows Server 2003 Enterprise Edition | Windows Server 2003
Microsoft(R) Windows Server(R) 2003，Standard Edition 日本語版 | Windows Server 2003 Standard Edition
Microsoft(R) Windows Server(R) 2003 R2，Enterprise Edition 日本語版 | Windows Server 2003 R2 Enterprise Edition | Windows Server 2003 R2
Microsoft(R) Windows Server(R) 2003 R2，Standard Edition 日本語版 | Windows Server 2003 R2 Standard Edition
Microsoft(R) Windows Server(R) 2003，Enterprise x64 Edition 日本語版 | Windows Server 2003 Enterprise x64 Edition | Windows Server 2003（x64）
Microsoft(R) Windows Server(R) 2003，Standard x64 Edition 日本語版 | Windows Server 2003 Standard x64 Edition
Microsoft(R) Windows Server(R) 2003 R2，Enterprise x64 Edition 日本語版 | Windows Server 2003 R2 Enterprise x64 Edition | Windows Server 2003 R2（x64）
Microsoft(R) Windows Server(R) 2003 R2，Standard x64 Edition 日本語版 | Windows Server 2003 R2 Standard x64 Edition
Microsoft(R) Windows Server(R) 2008 Enterprise 32-bit 日本語版 | Windows Server 2008 x86 | Windows Server 2008
Microsoft(R) Windows Server(R) 2008 Standard 32-bit 日本語版
Microsoft(R) Windows Server(R) 2008 Enterprise 日本語版 | Windows Server 2008 x64
Microsoft(R) Windows Server(R) 2008 Standard 日本語版
Microsoft(R) Windows Server(R) 2008 R2 Enterprise 日本語版 | Windows Server 2008 R2
Microsoft(R) Windows Server(R) 2008 R2 Standard 日本語版
Microsoft(R) Windows Vista(R) Business | Windows Vista Business | Windows Vista
Microsoft(R) Windows Vista(R) Enterprise | Windows Vista Enterprise
Microsoft(R) Windows Vista(R) Ultimate | Windows Vista Ultimate
Microsoft(R) Windows(R) XP Professional Operating System | Windows XP

■ 発行

2011年 7月 3020-3-U05-40

■ 著作権

All Rights Reserved. Copyright (C) 2008, 2011, Hitachi, Ltd.

変更内容

変更内容（3020-3-U05-40）uCosminexus Application Server Enterprise 08-70，uCosminexus Application Server Standard 08-70，uCosminexus Application Server Standard-R 08-70，uCosminexus Client 08-70，uCosminexus Developer Professional 08-70，uCosminexus Developer Standard 08-70，uCosminexus Service Architect 08-70，uCosminexus Service Platform 08-70，uCosminexus Web Redirector 08-70

追加・変更内容
変更個所

アプリケーションサーバ 08-70での主な機能変更についての説明を1.4，およびアプリケーションサーバ 08-53での主な機能変更についての説明を付録E.1に追加した。また，アプリケーションサーバ 08-50での主な機能変更についての説明を付録E.2に移動した。
1.4，付録E.1，付録E.2

page/tagディレクティブのimport属性暗黙インポート機能を追加した。
2.3，2.3.7，2.5.2，2.5.8

データベースセッションフェイルオーバ機能を使用している場合の，HttpSessionオブジェクト数の上限値の設定についての説明を追加した。
2.7.5

server.policyファイルの記述例に統合ユーザ管理機能のパーミッションに関する記述を追加した。
2.14.2

welcomeファイルにURLマッピングされたServletまたはJSPの指定についての説明を追加した。
5.1.1

次の製品の適用OSにAIX，HP-UX（IPF）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

－

次の製品の適用OSにRed Hat Enterprise Linux Server 6（32-bit x86），Red Hat Enterprise Linux Server 6（64-bit x86_64）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Application Server Standard-R

uCosminexus Service Platform

uCosminexus Web Redirector

－

uCosminexus Application Server Enterprise 08-53，uCosminexus Application Server Standard 08-53，uCosminexus Application Server Standard-R 08-53，uCosminexus Client 08-53，uCosminexus Developer Professional 08-53，uCosminexus Developer Standard 08-53，uCosminexus Service Architect 08-53，uCosminexus Service Platform 08-53，uCosminexus Web Redirector 08-53

追加・変更内容
変更個所

Microsoft IIS 7.0およびMicrosoft IIS 7.5に対応した。
付録C，付録C.2

HiRDB Version 9に対応した。
－

SQL Server 2008に対応した。これに伴い，使用できるJDBCドライバにSQL Server JDBC Driver 2.0，およびSQL Server JDBC Driver 3.0を追加した。
－

対象製品としてuCosminexus Application Server Standard-Rを追加した。
－

次の製品の適用OSからAIX，HP-UX，Linux（IPF）を削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Service Platform

－

単なる誤字・脱字などはお断りなく訂正しました。

変更内容（3020-3-U05-20）uCosminexus Application Server Enterprise 08-50，uCosminexus Application Server Standard 08-50，uCosminexus Client 08-50，uCosminexus Developer Professional 08-50，uCosminexus Developer Standard 08-50，uCosminexus Service Architect 08-50，uCosminexus Service Platform 08-50，uCosminexus Web Redirector 08-50

追加・変更内容

機能の分類とマニュアルの対応の説明に，次の機能を追加した。

OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）

Cosminexus JMSプロバイダ

スレッドの非同期並行処理

ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）

Server Plug-inの記述を削除した。

アプリケーションサーバ 08-50での主な機能変更についての説明を追加した。また，アプリケーションサーバ 08-00での主な機能変更についての説明を付録E.1に移動した。

リクエストURIの正規化についての説明を追加した。

Cosminexus Application Server 08-50では，Eclipse 3.4に対応するため，記述を変更した。

JP1 Version 9製品に対応した。また，JP1 Version 7製品をサポート外とした。

次の製品の適用OSにWindows Server 2008 R2を追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

uCosminexus Service Platform

uCosminexus Client

次の製品の適用OSからSolarisを削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

次の製品の適用OSにWindows 7を追加した。

uCosminexus Developer Standard

uCosminexus Developer Professional

uCosminexus Service Architect

uCosminexus Client

uCosminexus Application Server Enterprise 08-20，uCosminexus Application Server Standard 08-20

追加・変更内容

URIのデコード機能を追加した。

Webアプリケーションのバージョン設定機能を追加した。

はじめに

このマニュアルは，Cosminexus（コズミネクサス）のアプリケーションサーバの機能について説明したものです。このマニュアルでは，アプリケーションサーバで提供するWebコンテナの機能，およびWebコンテナに関連する機能（Webサーバ，サーブレット／JSPなど）について説明します。

アプリケーションサーバでは，次に示すプログラムプロダクトを使用してシステムを構築，運用します。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Application Server Standard-R

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Service Architect

uCosminexus Service Platform

uCosminexus Web Redirector

このマニュアルでは，これらのプログラムプロダクトの構成ソフトウェアのうち，次に示す構成ソフトウェアについて説明しています。

Cosminexus Component Container

Cosminexus Component Container - Client

Cosminexus Component Container - Redirector

Cosminexus Component Transaction Monitor

Cosminexus Developer's Kit for Java

Cosminexus Performance Tracer

Cosminexus TPBroker

なお，オペレーティングシステム（OS）の種類によって，機能が異なる場合があります。

対象読者

このマニュアルは，アプリケーションサーバのシステムを設計，構築または運用する方，およびアプリケーションサーバで動作するアプリケーションを開発する方を対象としています。

次の内容を理解されていることを前提としています。

システムを設計，構築または運用する方

Windowsまたはご使用のUNIXのシステム構築および運用に関する知識

Java EEに関する知識

SQLおよびリレーショナルデータベースに関する基本的な知識

CORBAに関する基本的な知識

アプリケーションを開発する方

Windowsの基本操作に関する知識

Javaによるプログラム開発に関する基本的な知識

使用するIDE（Eclipse）に関する基本的な知識

ご利用製品ごとの用語の読み替えについて

ご利用の製品によっては，マニュアルで使用している用語を，ご利用の製品名に読み替える必要があります。

次の表に従って，マニュアルで使用している用語をご利用の製品名に読み替えてください。

ご利用の製品名 | マニュアルで使用している用語
uCosminexus Application Server Standard-R | Application Server
uCosminexus Developer Professional※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Developer Standard※1，※2 | Application Server
uCosminexus Service Architect※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Service Platform

注※1　テスト環境で使用している場合にだけ読み替えが必要です。

注※2　uCosminexus Developer StandardとApplication Serverには一部機能差があります。機能差については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「付録D　Developer Standard使用時の注意事項」を参照してください。

図中で使用している記号

このマニュアルの図中で使用している記号を，次のように定義します。

文法で使用している記号

このマニュアルの文法で使用している記号について次に示します。

構文要素 | 定義
英字 | A～Z　a～z
数字 | 0～9
英数字 | A～Z　a～z　0～9

注　すべて半角文字を使用してください。

GUIの説明で使用している記号

このマニュアルのGUIの説明で使用している記号について次に示します。

記号 | 意味
［　　］ | 画面の名称および画面に表示されている項目を表します。
［　　］－［　　］ | －の前に示したメニューから，－の後ろのメニューを選択することを表します。
＜　　＞ | ＜＞内の名称がユーザの環境によって異なることを表します。
「　　」 | 入力値，可変値，またはメッセージなどを表します。

1.　アプリケーションサーバの機能

この章では，アプリケーションサーバの機能の分類と目的，および機能とマニュアルの対応について説明します。また，このバージョンで変更した機能についても説明しています。

＜この章の構成＞

1.1　機能の分類

1.2　システムの目的と機能の対応

1.3　このマニュアルに記載している機能の説明

1.4　アプリケーションサーバ 08-70での主な機能変更

1.1　機能の分類

アプリケーションサーバは，Java EE 5に準拠したJ2EEサーバを中心としたアプリケーションの実行環境を構築したり，実行環境上で動作するアプリケーションを開発したりするための製品です。Java EEの標準仕様に準拠した機能や，アプリケーションサーバで独自に拡張された機能など，多様な機能を使用できます。目的や用途に応じた機能を選択して使用することで，信頼性の高いシステムや，処理性能に優れたシステムを構築・運用できます。

アプリケーションサーバの機能は，大きく分けて，次の二つに分類できます。

アプリケーションの実行基盤としての機能

アプリケーションの実行基盤を運用・保守するための機能

二つの分類は，機能の位置づけや用途によって，さらに詳細に分類できます。アプリケーションサーバのマニュアルは，機能の分類に合わせて提供しています。

アプリケーションサーバの機能の分類と対応するマニュアル（機能解説）の体系について，次の図に示します。

図1-1　アプリケーションサーバの機能の分類と対応するマニュアル（機能解説）の体系

ここでは，機能の分類について，マニュアルとの対応と合わせて説明します。

＜この節の構成＞

1.1.1　アプリケーションの実行基盤としての機能

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

1.1.3　機能とマニュアルの対応

1.1.1　アプリケーションの実行基盤としての機能

アプリケーションとして実装されたオンライン業務やバッチ業務を実行する基盤となる機能です。システムの用途や求められる要件に応じて，使用する機能を選択します。

アプリケーションの実行基盤としての機能を使用するかどうかは，システム構築やアプリケーション開発よりも前に検討する必要があります。

アプリケーションの実行基盤としての機能について，分類ごとに説明します。

＜この項の構成＞

(1)　Java EEに準拠したアプリケーションを動作させるための基本的な機能（基本・開発機能）

(2)　信頼性や性能などを向上させるために拡張されたアプリケーションサーバ独自の機能（拡張機能）

(1)　Java EEに準拠したアプリケーションを動作させるための基本的な機能（基本・開発機能）

Java EEに準拠したアプリケーション（J2EEアプリケーション）を動作させるための基本的な機能が該当します。主にJ2EEサーバの機能が該当します。

アプリケーションサーバでは，Java EE 5に準拠したJ2EEサーバを提供しています。J2EEサーバでは，標準仕様に準拠した機能のほか，アプリケーションサーバ独自の機能も提供しています。

基本・開発機能は，機能を使用するJ2EEアプリケーションの形態に応じて，さらに三つに分類できます。アプリケーションサーバの機能解説のマニュアルは，この分類に応じて分冊されています。

それぞれの分類の概要を説明します。

Webアプリケーションを実行するための機能（Webコンテナ）
Webアプリケーションの実行基盤であるWebコンテナの機能，およびWebコンテナとWebサーバが連携して実現する機能が該当します。

Enterprise Beanを実行するための機能（EJBコンテナ）
Enterprise Beanの実行基盤であるEJBコンテナの機能が該当します。また，Enterprise Beanを呼び出すEJBクライアントの機能も該当します。

WebアプリケーションとEnterprise Beanの両方で使用する機能（コンテナ共通機能）
Webコンテナ上で動作するWebアプリケーションおよびEJBコンテナ上で動作するEnterprise Beanの両方で使用できる機能が該当します。

(2)　信頼性や性能などを向上させるために拡張されたアプリケーションサーバ独自の機能（拡張機能）

アプリケーションサーバで独自に拡張された機能が該当します。バッチサーバ，CTM，データベースなど，J2EEサーバ以外のプロセスを使用して実現する機能も含まれます。

アプリケーションサーバでは，システムの信頼性を高め，安定稼働を実現するための多様な機能が拡張されています。また，J2EEアプリケーション以外のアプリケーション（バッチアプリケーション）をJavaの環境で動作させる機能も拡張しています。

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

アプリケーションの実行基盤を効率良く運用したり，保守したりするための機能です。システムの運用開始後に，必要に応じて使用します。ただし，機能によっては，あらかじめ設定やアプリケーションの実装が必要なものがあります。

アプリケーションの実行基盤を運用・保守するための機能について，分類ごとに説明します。

＜この項の構成＞

(1)　システムの起動・停止など日常的な運用をするための機能（運用機能）

(2)　システムの利用状況を監視するための機能（監視機能）

(3)　ほかの製品と連携して運用するための機能（連携機能）

(4)　トラブル発生時などに対処するための機能（保守機能）

(5)　旧バージョンの製品から移行するための機能（移行機能）

(6)　旧バージョンの製品との互換のための機能（互換機能）

(1)　システムの起動・停止など日常的な運用をするための機能（運用機能）

システムの起動や停止，アプリケーションの開始や停止，入れ替えなどの，日常運用で使用する機能が該当します。

(2)　システムの利用状況を監視するための機能（監視機能）

システムの稼働状態や，リソースの枯渇状態などを監視するための機能が該当します。また，システムの操作履歴など，監査で使用する情報を出力する機能も該当します。

(3)　ほかの製品と連携して運用するための機能（連携機能）

JP1やクラスタソフトウェアなど，ほかの製品と連携して実現する機能が該当します。

(4)　トラブル発生時などに対処するための機能（保守機能）

トラブルシューティングのための機能が該当します。トラブルシューティング時に参照する情報を出力するための機能も含みます。

(5)　旧バージョンの製品から移行するための機能（移行機能）

旧バージョンのアプリケーションサーバから新しいバージョンのアプリケーションサーバに移行するための機能が該当します。

(6)　旧バージョンの製品との互換のための機能（互換機能）

旧バージョンのアプリケーションサーバとの互換用の機能が該当します。なお，互換機能については，「1.1.1　アプリケーションの実行基盤としての機能」に該当する機能などの推奨機能に移行することをお勧めします。

1.1.3　機能とマニュアルの対応

アプリケーションサーバの機能解説のマニュアルは，機能の分類に合わせて分冊されています。

機能の分類と，それぞれの機能について説明しているマニュアルとの対応を次の表に示します。

表1-1　機能の分類とマニュアルの対応

分類 | 機能 | マニュアル※1
基本・開発機能 | Webコンテナ | 基本・開発編(Webコンテナ)※2
Webサーバ連携
インプロセスHTTPサーバ
サーブレットおよびJSPの実装
EJBコンテナ | 基本・開発編(EJBコンテナ)
EJBクライアント
Enterprise Bean実装時の注意事項
ネーミング管理 | 基本・開発編(コンテナ共通機能)
リソース接続とトランザクション管理
OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）
アプリケーションサーバでのJPAの利用
Cosminexus JPAプロバイダ
Cosminexus JMSプロバイダ
JavaMailの利用
セキュリティ管理
アプリケーションの属性管理
アノテーションの使用
J2EEアプリケーションの形式とデプロイ
コンテナ拡張ライブラリ
拡張機能 | バッチサーバによるアプリケーションの実行 | 拡張編
CTMによるリクエストのスケジューリングと負荷分散
バッチアプリケーションのスケジューリング
J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）
明示管理ヒープ機能を使用したフルガーベージコレクションの抑止
クライアント性能の測定と分析
統合ユーザ管理
複数の構築済み実行環境の切り替え
アプリケーションのユーザログ出力
スレッドの非同期並行処理
運用機能 | システムの起動と停止 | 運用／監視／連携編
J2EEアプリケーションの運用
監視機能 | 稼働情報の監視（稼働情報収集機能）
リソースの枯渇監視
監査ログ出力機能
データベース監査証跡連携機能
運用管理コマンドによる稼働情報の出力
Managementイベントの通知とManagementアクションによる処理の自動実行
CTMの稼働統計情報の収集
コンソールログの出力
連携機能 | JP1と連携したシステムの運用
システムの構成定義および管理（JP1/IM-CMとの連携）
システムの集中監視（JP1/IMとの連携）
ジョブによるシステムの自動運転（JP1/AJSとの連携）
シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
監査ログの収集および一元管理（JP1/NETM/Auditとの連携）
クラスタソフトウェアとの連携
1:1系切り替えシステム（クラスタソフトウェアとの連携）
相互系切り替えシステム（クラスタソフトウェアとの連携）
N:1リカバリシステム（クラスタソフトウェアとの連携）
ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）
保守機能 | トラブルシューティング関連機能 | 保守／移行／互換編
性能解析トレースを使用したシステムの性能解析
日立固有のJavaVMの機能
移行機能 | 旧バージョンのアプリケーションサーバからの移行
推奨機能への移行
互換機能 | 旧バージョンとの互換用機能（ベーシックモード）
旧バージョンとの互換用機能（サーブレットエンジンモード）
Cosminexus DABroker Libraryを使用したデータベース接続

注※1　マニュアル名称の「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

注※2　このマニュアルです。

1.2　システムの目的と機能の対応

アプリケーションサーバでは，構築・運用するシステムの目的に合わせて，適用する機能を選択する必要があります。

この節では，Webアプリケーションを実行するためのそれぞれの機能をどのようなシステムの場合に使用するとよいかを示します。機能ごとに，次の項目への対応を示しています。

信頼性
高い信頼が求められるシステムの場合に使用するとよい機能です。
アベイラビリティ（安定稼働性）およびフォールトトレランス（耐障害性）を高める機能や，ユーザ認証などのセキュリティを高めるための機能が該当します。

性能
性能を重視したシステムの場合に使用するとよい機能です。
システムのパフォーマンスチューニングで使用する機能などが該当します。

運用・保守
効率の良い運用・保守をしたい場合に使用するとよい機能です。

拡張性
システム規模の拡大・縮小および構成の変更への柔軟な対応が必要な場合に使用するとよい機能です。

そのほか
そのほかの個別の目的に対応するための機能です。

また，Webアプリケーションを実行するための機能には，Java EE標準機能とアプリケーションサーバが独自に拡張した機能があります。機能を選択するときには，必要に応じて，Java EE標準への準拠についても確認してください。

＜この節の構成＞

1.2.1　Webコンテナの機能

1.2.2　Webサーバ連携の機能

1.2.3　インプロセスHTTPサーバの機能

1.2.1　Webコンテナの機能

Webコンテナの機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1-2　Webコンテナの機能とシステムの目的の対応

機能
システムの目的
Java EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
標準
拡張

Webアプリケーションの実行機能
－
－
－
－
－
○
○
2.2

JSPの実行機能
－
－
－
－
－
○
○
2.3

JSPデバッグ機能
－
－
－
－
○
○
○
2.4

JSP事前コンパイル機能とコンパイル結果の保持
－
○
－
－
－
－
○
2.5

デフォルトの文字エンコーディング設定機能
－
－
○
－
－
○
○
2.6

セッション管理機能
○
－
－
○
－
○
○
2.7

アプリケーションのイベントリスナ
－
－
－
－
○
○
－
2.8

リクエストおよびレスポンスのフィルタリング
－
－
○
－
－
○
○
2.9

HTTPレスポンス圧縮機能
－
○
－
－
－
－
○
2.10

EJBコンテナとの連携
－
－
－
－
－
○
○
2.11

データベースとの接続
－
－
－
○
－
○
○
2.12

Webコンテナによるスレッドの作成
－
○
－
－
－
－
○
2.13

ユーザスレッドの使用
－
－
－
－
○
－
○
2.14

同時実行スレッド数の制御
－
○
－
－
－
－
○
2.15
2.16
2.17
2.18
2.19

エラーページのカスタマイズ
－
－
－
－
○
－
○
2.20

静的コンテンツのキャッシュ
－
○
－
－
－
－
○
2.21

簡易Webサーバ機能
－
－
－
－
○
－
○
2.22

URIのデコード機能
－
－
○
－
－
○
－
2.23

Webアプリケーションのバージョン設定機能
－
－
○
－
－
○
○
2.24

（凡例）　○：対応する　　－：対応しない

注

「Java EE標準への準拠」の「標準」と「拡張」の両方に○が付いている機能は，Java EE標準の機能にアプリケーションサーバ独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はアプリケーションサーバ独自の機能であることを示します。

1.2.2　Webサーバ連携の機能

Webサーバ連携の機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1-3　Webサーバ連携の機能とシステムの目的の対応

機能
システムの目的
Java EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
標準
拡張

Webサーバ（リダイレクタ）によるリクエストの振り分け
○
○
－
○
－
－
○
3.2
3.3
3.4
3.5

通信タイムアウト（Webサーバ連携）
○
○
－
－
－
－
○
3.6

IPアドレス指定（Webサーバ連携）
－
－
－
－
○
－
○
3.7

エラーページのカスタマイズ（Webサーバ連携）
－
－
－
－
○
－
○
3.8

ドメイン名指定でのトップページの表示
－
－
－
－
○
○
－
3.9

Webコンテナへのゲートウェイ情報の通知
－
－
－
－
○
－
○
3.10

（凡例）　○：対応する　　－：対応しない

注

「Java EE標準への準拠」の「標準」と「拡張」の両方に○が付いている機能は，Java EE標準の機能にアプリケーションサーバ独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はアプリケーションサーバ独自の機能であることを示します。

1.2.3　インプロセスHTTPサーバの機能

インプロセスHTTPサーバの機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1-4　インプロセスHTTPサーバの機能とシステムの目的の対応

機能
システムの目的
Java EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
標準
拡張

Webクライアントからの接続数の制御
－
○
－
－
－
－
○
4.3

リクエスト処理スレッド数の制御
－
○
－
－
－
－
○
4.4

Webクライアントからの同時接続数の制御によるリクエストの流量制御
－
○
－
－
－
－
○
4.5

同時実行スレッド数の制御によるリクエストの流量制御
－
○
－
－
－
－
○
4.6

リダイレクトによるリクエストの振り分け
－
－
－
－
○
－
○
4.7

Persistent ConnectionによるWebクライアントとの通信制御
－
○
－
－
－
－
○
4.8

通信タイムアウト（インプロセスHTTPサーバ）
○
○
－
－
－
－
○
4.9

IPアドレス指定（インプロセスHTTPサーバ）
－
－
－
－
○
－
○
4.10

アクセスを許可するホストの制限によるアクセス制御
○
－
－
－
－
－
○
4.11

リクエストデータのサイズの制限によるアクセス制御
○
－
－
－
－
－
○
4.12

有効なHTTPメソッドの制限によるアクセス制御
○
－
－
－
－
－
○
4.13

HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ
－
－
－
－
○
－
○
4.14

エラーページのカスタマイズ（インプロセスHTTPサーバ）
－
－
－
－
○
－
○
4.15

Webコンテナへのゲートウェイ情報の通知
－
－
－
－
○
－
○
4.16

ログ・トレースの出力
－
－
－
－
○
－
○
4.17

（凡例）　○：対応する　　－：対応しない

注

「Java EE標準への準拠」の「標準」と「拡張」の両方に○が付いている機能は，Java EE標準の機能にアプリケーションサーバ独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はアプリケーションサーバ独自の機能であることを示します。

1.3　このマニュアルに記載している機能の説明

ここでは，このマニュアルで機能を説明するときの分類の意味と，分類を示す表の例について説明します。

＜この節の構成＞

1.3.1　分類の意味

1.3.2　分類を示す表の例

1.3.1　分類の意味

このマニュアルでは，各機能について，次の五つに分類して説明しています。マニュアルを参照する目的によって，必要な個所を選択して読むことができます。

解説
機能の解説です。機能の目的，特長，仕組みなどについて説明しています。機能の概要について知りたい場合にお読みください。

実装
コーディングの方法やDDの記載方法などについて説明しています。アプリケーションを開発する場合にお読みください。

設定
システム構築時に必要となるプロパティなどの設定方法について説明しています。システムを構築する場合にお読みください。

運用
運用方法の説明です。運用時の手順や使用するコマンドの実行例などについて説明しています。システムを運用する場合にお読みください。

注意事項
機能を使用するときの全般的な注意事項について説明しています。注意事項の説明は必ずお読みください。

1.3.2　分類を示す表の例

機能説明の分類については，表で説明しています。表のタイトルは，「この章の構成」または「この節の構成」となっています。

次に，機能説明の分類を示す表の例を示します。

機能説明の分類を示す表の例

表X-1　この章の構成（○○機能）

分類 | タイトル | 参照先
解説 | ○○機能とは | X.1
実装 | アプリケーションの実装 | X.2
DDおよびcosminexus.xml※での定義 | X.3
設定 | 実行環境での設定 | X.4
運用 | ○○機能を使用した運用 | X.5
注意事項 | ○○機能使用時の注意事項 | X.6

注※

cosminexus.xmlについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.　アプリケーションの属性管理」を参照してください。

ポイント

cosminexus.xmlを含まないアプリケーションのプロパティ設定

cosminexus.xmlを含まないアプリケーションでは，実行環境へのインポート後にプロパティを設定，または変更します。設定済みのプロパティも実行環境で変更できます。

実行環境でのアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。サーバ管理コマンドおよび属性ファイルでのアプリケーションの設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.3.2　J2EEアプリケーションのプロパティの設定手順」を参照してください。

属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。DDまたはcosminexus.xmlと属性ファイルのタグの対応についてはマニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　Cosminexusアプリケーション属性ファイル（cosminexus.xml）」を参照してください。

なお，各属性ファイルで設定するプロパティは，アプリケーション統合属性ファイルでも設定できます。

1.4　アプリケーションサーバ 08-70での主な機能変更

この節では，アプリケーションサーバ 08-70での主な機能の変更について，変更目的ごとに説明します。

説明内容は次のとおりです。

アプリケーションサーバ 08-70で変更になった主な機能と，その概要を説明しています。機能の詳細については参照先の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「Cosminexus アプリケーションサーバ V8」は省略しています。

＜この節の構成＞

(1)　導入・構築の容易性強化

(2)　標準機能・既存機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表1-5　導入・構築の容易性強化を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

運用管理ポータル改善
運用管理ポータルの画面で，リソースアダプタの属性を定義するプロパティ（Connector属性ファイルの設定内容）の設定，および接続テストができるようになりました。また，運用管理ポータルの画面で，J2EEアプリケーション（earファイルおよびzipファイル）をManagement Serverにアップロードできるようになりました。
ファーストステップガイド
3.4.1

運用管理ポータル操作ガイド
－

page/tagディレクティブのimport属性暗黙インポート機能の追加
page/tagディレクティブのimport属性暗黙インポート機能を使用できるようになりました。
このマニュアル
2.3.7

仮想化環境でのJP1製品に対する環境設定の自動化対応
仮想サーバへのアプリケーションサーバ構築時に，仮想サーバに対するJP1製品の環境設定を，フックスクリプトで自動的に設定できるようになりました。
仮想化システム構築・運用ガイド
7.7.2

統合ユーザ管理機能の改善
ユーザ情報リポジトリでデータベースを使用する場合に，データベース製品のJDBCドライバを使用して，データベースに接続できるようになりました。Cosminexus DABroker LibraryのJDBCドライバによるデータベース接続はサポート外になりました。
簡易構築定義ファイルおよび運用管理ポータルの画面で，統合ユーザ管理機能に関する設定ができるようになりました。
また，Active Directoryの場合，DNで日本語などの2バイト文字に対応しました。
機能解説 拡張編
10章

運用管理ポータル操作ガイド
3.5，10.9.1

リファレンス 定義編(サーバ定義)
14.3

Hitachi Web Server設定項目の拡充
簡易構築定義ファイルおよび運用管理ポータルの画面で，Hitachi Web Serverの動作環境を定義するディレクティブ（httpsd.conf（Hitachi Web Server定義ファイル）の設定内容）を直接設定できるようになりました。
システム構築・運用ガイド
8.4.3

運用管理ポータル操作ガイド
10.10.1

リファレンス 定義編(サーバ定義)
4.13

（凡例）－：マニュアル全体を参照する

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表1-6　標準機能・既存機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
ejb-jar.xmlの指定項目の追加 | ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。 | 機能解説 基本・開発編(EJBコンテナ) | 2.15
パラレルコピーガーベージコレクションへの対応 | パラレルコピーガーベージコレクションを選択できるようになりました。 | リファレンス 定義編(サーバ定義) | 19.5
Connector 1.5仕様に準拠したInboundリソースアダプタのグローバルトランザクションへの対応 | Connector 1.5仕様に準拠したリソースアダプタでTransacted Deliveryを使用できるようにしました。これによって，Message-driven Beanを呼び出すEISがグローバルトランザクションに参加できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 3.16.3
TP1インバウンドアダプタのMHPへの対応 | TP1インバウンドアダプタを使用してアプリケーションサーバを呼び出すOpenTP1のクライアントとして，MHPを使用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 4章
cjrarupdateコマンドのFTPインバウンドアダプタへの対応 | cjrarupdateコマンドでバージョンアップできるリソースアダプタにFTPインバウンドアダプタを追加しました。 | リファレンス コマンド編 | 2.2

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表1-7　信頼性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
データベースセッションフェイルオーバ機能の改善 | 性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。 | 機能解説 拡張編 | 6章
OutOfMemoryハンドリング機能の対象となる処理の拡大 | OutOfMemoryハンドリング機能の対象となる処理を追加しました。 | 機能解説 保守／移行／互換編 | 2.5.6
リファレンス 定義編(サーバ定義) | 19.2
HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加 | HTTPセッションで利用するExplicitヒープのメモリ使用量を抑止する機能を追加しました。 | 機能解説 拡張編 | 8.9

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表1-8　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応） | JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。 | 仮想化システム構築・運用ガイド | 1.2.2，3章，4章，5章，6章，7.8

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表1-9　そのほかの目的による変更

項目
変更の概要
参照先マニュアル
参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応
負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。
また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。
システム構築・運用ガイド
4.3.1

仮想化システム構築・運用ガイド
2.1

リファレンス 定義編(サーバ定義)
4.5

snapshotログ収集時のタイムアウトへの対応と収集対象の改善
snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。
機能解説 保守／移行／互換編
付録A

2.　Webコンテナ

この章では，サーブレットとJSPを実行するためのサーバ基盤である，Webコンテナの機能について説明します。Webコンテナの機能は，サーブレットまたはJSPを使用したJ2EEアプリケーションを実行する場合に使用します。

＜この章の構成＞

2.1　この章の構成

2.2　Webアプリケーションの実行機能

2.3　JSPの実行機能

2.4　JSPデバッグ機能

2.5　JSP事前コンパイル機能とコンパイル結果の保持

2.6　デフォルトの文字エンコーディング設定機能

2.7　セッション管理機能

2.8　アプリケーションのイベントリスナ

2.9　リクエストおよびレスポンスのフィルタリング機能

2.10　HTTPレスポンス圧縮機能

2.11　EJBコンテナとの連携

2.12　データベースとの接続

2.13　Webコンテナによるスレッドの作成

2.14　ユーザスレッドの使用

2.15　同時実行スレッド数の制御の概要

2.16　Webコンテナ単位での同時実行スレッド数の制御

2.17　Webアプリケーション単位での同時実行スレッド数の制御

2.18　URLグループ単位での同時実行スレッド数の制御

2.19　同時実行スレッド数の動的変更

2.20　エラーページのカスタマイズ

2.21　静的コンテンツのキャッシュ

2.22　簡易Webサーバ機能

2.23　URIのデコード機能

2.24　 Webアプリケーションのバージョン設定機能

2.25　POSTデータ最大サイズについての注意事項

2.1　この章の構成

アプリケーションサーバでは，Webアプリケーションの実行機能を提供するコンテナとしての機能（Webコンテナ）を提供しています。

アプリケーションサーバで提供するWebコンテナの機能と参照先を次の表に示します。

表2-1　Webコンテナの機能と参照先

機能 | 参照先
Webアプリケーションの実行機能 | 2.2
JSPの実行機能 | 2.3
JSPデバッグ機能 | 2.4
JSP事前コンパイル機能とコンパイル結果の保持 | 2.5
デフォルトの文字エンコーディング設定機能 | 2.6
セッション管理機能 | 2.7
アプリケーションのイベントリスナ | 2.8
リクエストおよびレスポンスのフィルタリング機能 | 2.9
HTTPレスポンス圧縮機能 | 2.10
EJBコンテナとの連携 | 2.11
データベースとの接続 | 2.12
Webコンテナによるスレッドの作成 | 2.13
ユーザスレッドの使用 | 2.14
同時実行スレッド数の制御 | 2.15
Webコンテナ単位での同時実行スレッド数の制御 | 2.16
Webアプリケーション単位での同時実行スレッド数の制御 | 2.17
URLグループ単位での同時実行スレッド数の制御 | 2.18
同時実行スレッド数の動的変更 | 2.19
エラーページのカスタマイズ | 2.20
静的コンテンツのキャッシュ | 2.21
簡易Webサーバ機能 | 2.22
URIのデコード機能 | 2.23
Webアプリケーションのバージョン設定機能 | 2.24
POSTデータ最大サイズについての注意事項 | 2.25

参考

アプリケーション開発時に，アプリケーションサーバが提供するcjjsp2javaコマンドを使用することで，JSPファイルからJavaソースファイルを生成し，JSPに記述ミスがないかを確認できます。

アプリケーションサーバで提供するWebコンテナの機能には，Java EEで規定された機能にアプリケーションサーバ独自の機能を拡張したものと，アプリケーションサーバ独自の機能として提供しているものがあります。アプリケーションサーバ独自の機能かどうかについては，「1.2　システムの目的と機能の対応」を参照してください。

2.2　Webアプリケーションの実行機能

Webコンテナでは，Webアプリケーションを実行できます。Webアプリケーションとは，Webコンテナ上で動作するサーバプログラムのことです。この節では，Webアプリケーションの実行機能について説明します。

この節の構成を次の表に示します。

表2-2　この節の構成（Webアプリケーションの実行機能）

分類 | タイトル | 参照先
解説 | Webアプリケーションのデプロイとアンデプロイ | 2.2.1
注意事項 | Webアプリケーションのデプロイとアンデプロイの注意事項 | 2.2.2

注　「実装」，「設定」および「運用」について，この機能固有の説明はありません。

通常のWebサーバは，固定されたHTMLファイルだけを送信します。Webコンテナが機能することによって，Webコンテナ上でWebアプリケーションを実行し，Webクライアントから受け取ったデータを処理したり，その処理の結果に応じて異なるWebページを生成したりできるようになります。

Webアプリケーションは，主に，サーブレットおよびJSPと呼ばれる2種類の技術を使用して開発されたアプリケーションです。サーブレットはJavaプログラムを使い，HTMLを生成したり，Webクライアントから受け取った情報を処理したりする技術です。JSP（JavaServer Pages）はサーブレット技術を基盤に，HTMLページの中にタグやJavaプログラムを埋め込むことで，動的にWeb画面を生成する技術です。JSPはJSPコンパイラによって，一度Javaで記述されたサーブレットプログラムに変換され，そのあと，Javaコンパイラによってコンパイル，実行されます。

アプリケーションサーバのWebコンテナでは，Java Servlet 2.5仕様，およびJavaServer Pages（JSP）2.1仕様に準拠したWebアプリケーションを実行できます。Webアプリケーション実行機能の詳細については，Java Servlet Specification v2.5，およびJavaServer Pages Specification v2.1を参照してください。

なお，Webコンテナを使用してWebアプリケーションを実行するには，WebサーバとしてHitachi Web ServerまたはMicrosoft IISを使用するか，インプロセスHTTPサーバを使用する必要があります。

参考

08-00より前のバージョンのアプリケーションサーバで実行できるアプリケーションは，08-00の環境でも実行できます。

＜この節の構成＞

2.2.1　Webアプリケーションのデプロイとアンデプロイ

2.2.2　Webアプリケーションのデプロイとアンデプロイの注意事項

2.2.1　Webアプリケーションのデプロイとアンデプロイ

Webアプリケーションは，デプロイすることによって，実行可能な状態になります。

WAR形式のWebアプリケーションを実行可能な状態に配置するには，WebアプリケーションをEAR形式にパッケージ化してアーカイブ形式のJ2EEアプリケーションにするか，または展開ディレクトリ形式のJ2EEアプリケーションにしてデプロイする必要があります。実行できるJ2EEアプリケーションの形式については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.2　実行できるJ2EEアプリケーションの形式」を参照してください。

複数のWebアプリケーションのデプロイを実行した場合，Webアプリケーションごとに独立のクラスローダが作成されます。このため，異なるWebアプリケーションで同一のクラス名のクラス（Loginサーブレットなど）を用いた場合でも，別々のクラスローダ上で独立に扱われます。

なお，J2EEアプリケーションとしてデプロイしたWebアプリケーションをアンデプロイする場合は，J2EEアプリケーションごとアンデプロイします。WAR単位でアンデプロイすることはできません。

2.2.2　Webアプリケーションのデプロイとアンデプロイの注意事項

ここでは，Webアプリケーションをデプロイ，またはアンデプロイする場合の留意事項について説明します。

＜この項の構成＞

(1)　サーブレット/JSPのデフォルトマッピングについて

(2)　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値について

(3)　サーブレットのインスタンス作成数

(4)　サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング

(5)　レスポンス送信時に使用されるサーブレットのバッファ

(6)　クエリ文字列の解析について

(1)　サーブレット/JSPのデフォルトマッピングについて

クライアントがリクエストするURLに対してどのサーブレットが呼び出されるかの設定をサーブレットマッピングといいます。Servlet仕様では，サーブレットマッピングをDD（WEB-INF/web.xml）内に記述するように求めています。

これに対して，Webコンテナでデフォルトで定義されているマッピングをデフォルトマッピングといいます。Webコンテナでは，次に示すマッピングをデフォルトで定義しています。

表2-3　Webコンテナで定義されているサーブレット/JSPのデフォルトマッピング

URL
取り扱い

*.jsp
JSPファイルとして取り扱われます。

*.jspx
Servlet 2.4以降の仕様に準拠したWebアプリケーションについては，JSPドキュメントとして取り扱われます。なお，Servlet 2.2およびServlet 2.3仕様に準拠したWebアプリケーションの場合は静的コンテンツとして扱われます。

/servlet/*
WEB-INF/classes以下，またはWEB-INF/lib以下に配置されたJARファイルに含まれているサーブレットのクラスが実行されます。実行するサーブレットは，サーブレット名から検索されます。
URLに指定された「*」の部分がサーブレット名として定義されていない場合，サーブレットクラスが検索されます。URLの「*」の部分には，サーブレットの完全修飾クラス名，またはweb.xmlで定義したサーブレット名を指定できます。
サーブレットの完全修飾クラス名を指定した場合，指定したサーブレットが実行されます。サーブレット名を指定した場合，web.xmlで定義したサーブレットが実行されます。

なお，サーブレットはweb.xmlにマッピング定義が必要なため，web.xmlが省略されたWebアプリケーションの場合，サーブレットのデフォルトマッピングは有効になりません。

サーブレットのデフォルトマッピングについては，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，次のパラメタに有効または無効を指定します。デフォルトの設定では，無効になっています。

webserver.container.servlet.default_mapping.enabled

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値について

Webコンテナでは，次に示すタグがDD（WEB-INF/web.xml）に設定されていない場合，次に示すデフォルト値を使用します。

表2-4　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値

タグ名
設定されていない場合のデフォルト値

welcome-file-list

<welcome-file-list>
   <welcome-file>
       index.jsp
   </welcome-file>
   <welcome-file>
       index.html
   </welcome-file>
   <welcome-file>
       index.htm
   </welcome-file>
</welcome-file-list>

session-timeout
30

mime-mapping
拡張子とMIMEタイプとの対応づけ。

DD（WEB-INF/web.xml）にこれらのタグを設定している場合には，次の設定となります。

<welcome-file-list>タグに設定された値で，デフォルト値を上書きします。

<session-timeout>タグに設定された値で，デフォルト値を上書きします。

<mime-mapping>タグに定義した拡張子単位の設定で，デフォルト値を拡張子単位に上書きします。

なお，DD（WEB-INF/web.xml）のmime-mappingタグにデフォルトで設定されている拡張子とMIMEタイプの対応づけについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「付録B.1　拡張子とMIMEタイプの対応づけ」を参照してください。

(3)　サーブレットのインスタンス作成数

Webアプリケーション単位に同じクラスのサーブレットのインスタンスを一つ作成します。SingleThreadModelを継承したサーブレットのインスタンスも，一般のサーブレットと同様にWebアプリケーション単位に一つ作成します。

ただし，同一のサーブレットおよびJSPに対して，デフォルトのマッピングとDDに記述したマッピングの両方でアクセスすると，インスタンスは次のように生成されます。

表2-5　デフォルトマッピングとDDに記述したマッピングの両方でアクセスする場合のインスタンスの生成

URL
インスタンス

*.jsp
DDに記述したマッピングでアクセスした場合とは別のインスタンスが生成されます。

*.jspx

/servlet/*

サーブレットの完全修飾クラス名を指定した場合
DDに記述したマッピングでアクセスした場合とは別のインスタンスが生成されます。

web.xmlで定義したサーブレット名を指定した場合
DDに記述したマッピングでアクセスした場合と同じインスタンスが生成されます。

また，SingleThreadModelを継承した単一のサーブレットに対して，Webアプリケーション単位にリクエストが並列に複数到着した場合，各スレッドがオーバラップしないで1スレッドずつ順に実行するように制御します。

(4)　サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング

サーブレットのinitメソッドおよびserviceメソッドの実行のタイミングは，デフォルトマッピングかサーブレットマッピングかによって異なります。

デフォルトマッピングでサーブレットにアクセスした場合
サーブレットのinitメソッドおよびserviceメソッドは，該当するURLにマッピングされているフィルタの処理の延長で，実行されます。

サーブレットマッピングでサーブレットにアクセスした場合
initメソッドはフィルタの処理の前に，実行されます。serviceメソッドは，該当するURLにマッピングされたフィルタの処理の延長で，実行されます。

(5)　レスポンス送信時に使用されるサーブレットのバッファ

レスポンス送信時に使用されるサーブレットのバッファは，リクエスト処理スレッドの数だけ保持されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを使用してバッファサイズを変更する場合は，バッファサイズ×リクエスト処理スレッド数分のメモリが確保されることを考慮した上で，メモリ使用量を見積もってください。

(6)　クエリ文字列の解析について

クエリ文字列は，URLの?マーク以降に，"名前=値"の組が一つ以上組み合わさって構成されます。

アプリケーションサーバでは，"名前=値"の部分に複数の"="がある場合，最初の"="より前の文字列が名前，後ろの文字列が値となります。例えば，URLが「http://host/examples?a=b=c」の場合は，「名前"a"の値は"b=c"」と解析されます。

2.3　JSPの実行機能

この節では，JSPの実行機能について説明します。

Webコンテナでは，Servlet仕様が規定したJSPの文法に従って作成されたJSPを，サーブレットに変換し，javaのプログラムとしてコンパイルして，Java VM内にロードして実行できます。

この節の構成を次の表に示します。

表2-6　この節の構成（JSPの実行機能）

分類 | タイトル | 参照先
解説 | JSPの実行機能の概要 | 2.3.1
タグファイルの実行 | 2.3.2
JSP ELの実行 | 2.3.3
タグライブラリのライブラリJARへの格納 | 2.3.4
カスタムタグの属性名チェック | 2.3.5
<jsp:useBean>タグのid属性重複チェック | 2.3.6
page/tagディレクティブのimport属性暗黙インポート | 2.3.7

注　「実装」，「設定」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.3.1　JSPの実行機能の概要

2.3.2　タグファイルの実行

2.3.3　JSP ELの実行

2.3.4　タグライブラリのJ2EEアプリケーションへの格納

2.3.5　カスタムタグの属性名チェック

2.3.6　<jsp:useBean>タグのid属性重複チェック

2.3.7　page/tagディレクティブのimport属性暗黙インポート

2.3.1　JSPの実行機能の概要

JSPは，JSP仕様の標準の書式である標準シンタックスと，XML仕様の書式であるXMLシンタックスで記述することができます。標準シンタックスで記述されたJSPをJSPページと呼び，XMLシンタックスで記述されたJSPをJSPドキュメントと呼びます。また，JSPページ，JSPドキュメントを総称して，JSPファイルと呼びます。

＜この項の構成＞

(1)　JSPの構成

(2)　トランスレーションエラー

(1)　JSPの構成

JSPは要素（ディレクティブ，アクション，スクリプティング要素）とテンプレートテキストから構成されます。テンプレートテキストには，ホワイトスペースが含まれます。通常，テンプレートテキストに含まれるホワイトスペースはそのまま保持されますが，JSP 2.1仕様から，JSPページまたは標準シンタックスのタグファイルのテンプレートテキストに含まれる不要なホワイトスペースを削除する機能が追加されました。詳細は，「5.1.6(2)　不要なホワイトスペースの削除機能」を参照してください。

参考

JSP 2.0仕様から，JSP ELが規定されました。JSP ELとは，アクションやテンプレートテキスト内に直接記述することができる簡易言語です。詳細は「2.3.3　JSP ELの実行」を参照してください。

(2)　トランスレーションエラー

トランスレーションエラーとは，JSPコンパイル処理のJSPファイルからjavaファイルへの変換（JSPトランスレーション）時に，構文誤りなどが原因でjavaファイルに変換できない場合に発生するエラーを指します。

JSPトランスレーションは次のタイミングで実行されますが，その際にトランスレーションエラーが発生するおそれがあります。

JSPへのリクエスト受信時

アプリケーションのリロード時

JSP事前コンパイル機能を使用する場合のアプリケーション開始時

JSP事前コンパイル機能を使用する場合のコマンド実行時

J2EEサーバ上でのJSPコンパイル時にトランスレーションエラーが発生した場合，メッセージKDJE39145-Eがサーブレットログに，メッセージKDJE39186-Eがメッセージログにそれぞれ出力されます。リクエスト処理時にトランスレーションエラーとなった場合，リダイレクタがエラーステータスコード500を返します。

cjjspcコマンドでのJSP事前コンパイル時にトランスレーションエラーが発生した場合，メッセージKDJE39145-E，およびメッセージKDJE39186-Eがコンソールに出力されます。

なお，TLDファイルの解析，タグライブラリバリデータによるJSPの検証や，TagExtraInfoクラスで指定したスクリプト変数の重複など，ほかの原因でトランスレーションエラーが発生することもあります。この場合，原因に応じたメッセージが出力されます。トランスレーションエラー発生時に出力されるメッセージを，原因ごとに次の表に示します。

表2-7　JSPコンパイル以外の動作が原因でトランスレーションエラーが発生した場合に出力されるメッセージ

原因の分類 | 出力されるメッセージ
TLDファイルの解析 | KDJE39214-E, KDJE39216-E, KDJE39193-E, KDJE39055-E, KDJE39205-E, KDJE39206-E, KDJE39207-E, KDJE39208-E, KDJE39296-E, KDJE39301-E, KDJE39302-E, KDJE39303-E, KDJE39305-E, KDJE39306-E, KDJE39307-E, KDJE39308-E
タグライブラリバリデータによるJSPの検証 | KDJE39104-E, KDJE39105-E, KDJE39106-E, KDJE39107-E, KDJE39108-E, KDJE39115-E, KDJE39116-E, KDJE39117-E, KDJE39134-E, KDJE39135-E
TagExtraInfoクラスで指定したスクリプト変数の重複 | KDJE39131-E, KDJE39132-E, KDJE39133-E, KDJE39136-E, KDJE39282-E, KDJE39283-E, KDJE39291-E, KDJE39294-E

2.3.2　タグファイルの実行

アプリケーションサーバでは，JSP 2.0以降で規定されているJSPの構文に従って作成されたタグファイルを実行できます。タグファイルの実行では，次の内容が実施されます。

タグファイルをjavaクラスに変換する

変換したjavaクラスファイルをコンパイルする

コンパイルしたファイルをJavaVM内にロードして実行する

タグファイルを使用すると，従来，カスタムタグライブラリで実現していたタグの拡張をJSPの構文だけで記述できます。

2.3.3　JSP ELの実行

アプリケーションサーバでは，JSP 2.0以降で規定されているELの構文に従って作成されたEL式を実行できます。JSP ELを使用すると，JSPファイルやタグファイル内でJavaBeans属性へのアクセスなどを記述できます。

JSP 2.1仕様で追加されたELの機能では，Java SEのEnum型への対応，JavaBeansの属性への値の設定，メソッドを示すELが記述できます。また，JSP 2.1仕様では，JSP 2.0仕様が規定したELに加え，JSF1.1仕様で規定されているELがJSP 2.1仕様のELとして記述することができます。

JSP 2.0仕様で規定されたELを特に指す場合，JSP 2.0仕様のELと呼びます。JSP 2.1仕様のELを特に指す場合，EL2.1と呼びます。

2.3.4　タグライブラリのJ2EEアプリケーションへの格納

アプリケーションサーバでは，タグライブラリをJ2EEアプリケーションに格納し，JSPから使用できます。

J2EEアプリケーションに格納されたタグライブラリをJSPから使用する方法は，JSPをJ2EEサーバでコンパイルするかcjjspcコマンドでコンパイルするかによって異なります。

J2EEサーバでJSPをコンパイルする場合

タグライブラリをライブラリJARに格納する。

cjjspcコマンドでJSPをコンパイルする場合

タグライブラリをクラスパスに指定したJARファイルに格納する。

それぞれの方法について説明します。

＜この項の構成＞

(1)　J2EEサーバでJSPをコンパイルする場合

(2)　cjjspcコマンドでJSPをコンパイルする場合

(1)　J2EEサーバでJSPをコンパイルする場合

タグライブラリをライブラリJARに格納することで，JSPから使用できます。

(a)　TLDファイルの検索

タグライブラリをライブラリJARとしてJ2EEアプリケーションに格納した場合，web.xmlの<taglib>要素でTLDファイルを指定することができません。この場合，JSPファイルのtaglibディレクティブのuri属性で，TLDファイルの<uri>要素に指定されたURIを指定してください。Webアプリケーション開始時に，ライブラリJARに格納されたTLDファイルがWebコンテナによって検索され，TLDファイルの<uri>要素に記述されたURIとそのTLDファイル自身がマッピングされます。

なお，<uri>要素がない場合はURIとそのTLDファイル自身はマッピングされません。

ライブラリJAR内のTLDファイルのマッピングは最も優先順位が低いマッピングです。このため，URIとTLDファイルのマッピングで，ライブラリJAR内のTLDファイルのURIがほかのTLDファイルやweb.xmlと重複しても，07-60以前のバージョンで動作していたJ2EEアプリケーションの動作に影響はありません。ライブラリJAR内のTLDファイルのマッピングの優先順位については，「5.1.5(7)　taglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングについて」を参照してください。

JSPファイルでは，taglibディレクティブのuri属性でURIを指定することでタグライブラリを使用できます。

(b)　ライブラリJARに格納する場合に使用できるタグライブラリの機能

タグライブラリをライブラリJARに格納する場合に使用できるタグライブラリの機能は，カスタムタグおよびリスナです。

タグファイルは使用できません。JSPファイルまたはタグファイルで，ライブラリJARに格納されたタグファイルを使用した場合，ライブラリJARに格納されたTLDファイルの<tag-file>要素が無視されます。そのため，タグファイルが存在しないと見なされて，JSPトランスレーション時にトランスレーションエラーとなります。

(2)　cjjspcコマンドでJSPをコンパイルする場合

JARファイル内のタグライブラリをcjjspcコマンドの-classpathオプションでクラスパスに指定することで，WebアプリケーションのWEB-INF/libディレクトリ以外に配置したタグライブラリをJSPから使用できます。

(a)　TLDファイルの検索

クラスパスに指定したJARファイルに含まれるTLDファイルが自動的に検出され，TLDファイルの<uri>要素で指定したURIとそのTLDファイル自身がマッピングされます。

クラスパスに指定したJARファイル内のTLDファイルのマッピングは最も優先順位が低いマッピングです。このため，URIとTLDファイルのマッピングで，クラスパスに指定したJARファイル内のTLDファイルのURIがほかのTLDファイルやweb.xmlと重複しても，07-60以前のバージョンで動作していたJ2EEアプリケーションの動作に影響はありません。クラスパスに指定したJARファイル内のTLDファイルのマッピングの優先順位については，「5.1.5(7)　taglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングについて」を参照してください。

(b)　クラスパスに指定したJARファイルに格納する場合に使用できるタグライブラリの機能

タグライブラリをクラスパスに指定したJARファイルに格納する場合に使用できるタグライブラリの機能は，カスタムタグおよびリスナです。

タグファイルは使用できません。JSPファイルまたはタグファイルで，クラスパスに指定したJARファイルに格納されたタグファイルを使用した場合，JARファイルに格納されたTLDファイルの<tag-file>要素が無視されます。そのため，タグファイルが存在しないと見なされて，JSPトランスレーション時にトランスレーションエラーとなります。

2.3.5　カスタムタグの属性名チェック

カスタムタグの属性名チェック時に，次の属性名で大文字と小文字が一致しない場合，トランスレーションエラーが発生します。

JSPのカスタムタグで指定した属性名

TLDファイルまたはタグファイルで定義した属性名

アプリケーションサーバでは，カスタムタグの属性名チェック時に，大文字と小文字の不一致によるトランスレーションエラーの発生を抑止できます。大文字と小文字の不一致によるトランスレーションエラーの発生を抑止すると，TLDファイルまたはタグファイルに定義されている属性名から，大文字と小文字を区別しないでカスタムタグの属性定義が検索されます。

TLDファイルおよびタグファイルの属性名を定義する個所は次のとおりです。

TLDファイルの<taglib><tag><attribute>要素内の<name>要素で定義した属性名

タグファイルのattributeディレクティブで定義した属性名

＜この項の構成＞

(1)　カスタムタグの属性名チェックを無効にする方法

(2)　注意事項

(1)　カスタムタグの属性名チェックを無効にする方法

カスタムタグの属性名チェック時に大文字と小文字の不一致によるトランスレーションエラーの発生を抑止するには，次の二つの方法があります。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内でパラメタwebserver.jsp.translation.customAction.ignoreCaseAttributeNameにtrueを指定します。
簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

cjjspcコマンドに-usebeannocheckduplicateidオプションを指定してコンパイルします。
コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

(2)　注意事項

大文字と小文字だけで区別されている属性がある場合に，大文字と小文字の不一致によるトランスレーションエラーの発生を抑止しないでください。抑止すると，次の問題が発生します。

大文字と小文字だけで区別されている複数の属性をJSPのカスタムタグで指定している場合
それぞれの属性に対してタグハンドラのsetterメソッドが実行されます。このとき，同一の属性が複数個指定されていても，トランスレーションエラーは発生しません。このため，複数個の同一の属性に対してsetterメソッドが実行されてしまうおそれがあります。

大文字と小文字だけで区別されている属性名に対応したタグハンドラを実装している場合
大文字と小文字の区別なく，TLDファイルまたはタグファイルで先に記述された属性のsetterメソッドが呼び出されます。このとき，トランスレーションエラーは発生しません。このため，意図したsetterメソッドを呼び出すことができなくなるおそれがあります。

2.3.6　<jsp:useBean>タグのid属性重複チェック

JSP仕様では，<jsp:useBean>タグのid属性値が重複していた場合，トランスレーションエラーが発生してJSPのコンパイルに失敗します。

アプリケーションサーバでは，<jsp:useBean>タグのid属性値の重複によるトランスレーションエラーの発生を抑止して，JSPをコンパイルできます。

<jsp:useBean>タグのid属性値の重複によるトランスレーションエラーの発生を抑止した場合，次のJSPファイルの記述例のように<jsp:useBean>タグのid属性値が重複していても，JSPが問題なく動作します。

JSPファイルの記述例

（省略）
：
<% if (条件式){ %>
<jsp:useBean id=”BeanTest” class=”test.TestClass1” />
<% } else { %>
<jsp:useBean id=”BeanTest” class=”test.TestClass2” />
<% } %>
：
（省略）

スクリプトレットを使用して，if節とelse節にそれぞれ<jsp:useBean>タグを記述することで，片方の<jsp:useBean>タグしか実行されません。そのため，<jsp:useBean>タグのid属性値が重複していてもJSPは問題なく動作します。

<jsp:useBean>タグのid属性値の重複によるトランスレーションエラーの発生を抑止している場合に，<jsp:useBean>タグのid属性値が重複したときは，KDJE39544-Iのメッセージが出力されます。

＜この項の構成＞

(1)　<jsp:useBean>タグのid属性重複チェックを有効にする方法

(2)　注意事項

(1)　<jsp:useBean>タグのid属性重複チェックを有効にする方法

<jsp:useBean>タグのid属性値の重複によるトランスレーションエラーの発生を抑止するには，次の二つの方法があります。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内でパラメタwebserver.jsp.translation.useBean.noCheckDuplicateIdにtrueを指定します。
簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

cjjspcコマンドに-usebeannocheckduplicateidオプションを指定してコンパイルします。
コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

(2)　注意事項

<jsp:useBean>タグで作成されたJavaBeansオブジェクトは，id属性値をキーにして，scope属性で指定されたスコープ内で管理されます。そのため，次の条件を満たす場合に，意図しないJavaBeansオブジェクトを取得して不正な動作となるおそれがあります。

<jsp:useBean>タグのid属性値の重複によるトランスレーションエラーの発生を抑止している。

<jsp:useBean>タグのid属性値が重複している。

id属性値が重複している二つ以上の<jsp:useBean>タグのclass属性に，異なるJavaBeansクラスを指定している。

<jsp:useBean>タグのid属性値の重複によるトランスレーションエラーの発生を抑止している場合に，意図したオブジェクトが取得できないおそれがあるJSPファイルの記述例について説明します。

(a)　単一のリクエストで意図しないJavaBeansオブジェクトが取得される場合のJSPファイルの記述例（二つ以上の異なる条件式で同じid属性を指定した例）

（省略）
：
<% if (条件式1){ %>
<jsp:useBean id="BeanTest" class="test.TestClass1" scope="page"/>
<% } %>
<% if(条件式2) { %>
<jsp:useBean id="BeanTest" class="test.TestClass2" type="test.TestIF" scope="page"/>
<% } %>
：
（省略）

条件式1と条件式2で，id属性値に同じ値（BeanTest）が指定されています。条件式1および条件式2の両方の条件を満たす場合，一つ目の<jsp:useBean>タグでも二つ目の<jsp:useBean>タグでもtest.TestClass1クラスのオブジェクトが取得され，test.TestClass2クラスのオブジェクトは取得されません。

一つ目の<jsp:useBean>タグでid属性値「BeanTest」に対してtest.TestClass1クラスのオブジェクトが登録されます。二つ目の<jsp:useBean>タグでも同じid属性値「BeanTest」に対しての処理であると解釈されるため，一つ目の<jsp:useBean>タグで登録済みのtest.TestClass1クラスのオブジェクトが取得されます。

(b)　複数のリクエストで意図しないJavaBeansオブジェクトが取得される場合のJSPファイルの記述例1（if文とelse文で同じid属性値を指定した例）

（省略）
：
<% if (条件式){ %>
<jsp:useBean id="BeanTest" class="test.TestClass1" scope="session"/>
<% } else { %>
<jsp:useBean id="BeanTest" class="test.TestClass2" scope="session"/>
<% } %>
：
（省略）

if文とelse文で，id属性値に同じ値（BeanTest）が指定されています。リクエストを2回受け付けて，1回目のリクエストではif文の条件式が成立し，2回目のリクエストではif文の条件式が不成立となった場合，一つ目の<jsp:useBean>タグと二つ目の<jsp:useBean>タグの両方でtest.TestClass1クラスのオブジェクトが取得され，test.TestClass2クラスのオブジェクトは取得されません。

一つ目の<jsp:useBean>タグでid属性値「BeanTest」に対してtest.TestClass1クラスのオブジェクトが登録されます。二つ目の<jsp:useBean>タグでも同じid属性値「BeanTest」に対しての処理であると解釈されるため，一つ目の<jsp:useBean>タグで登録済みのtest.TestClass1クラスのオブジェクトが取得されます。

(c)　複数のリクエストで意図しないJavaBeansオブジェクトが取得される場合のJSPファイルの記述例2（<jsp:getProperty>タグまたは<jsp:setProperty>タグで，二つ以上の<jsp:useBean>タグで共通して指定されているid属性値を使用してJavaBeansオブジェクトを呼び出す例1）

（省略）
：
<% if (条件式1){ %>
<jsp:useBean id=”BeanTest” class=”test.TestClass1” scope=”page”/>
<% } %>
<% if(条件式2) { %>
<jsp:useBean id=”BeanTest” class=”test.TestClass2” type=” test.TestIF” scope=”page”/>
<% } %>
：
<jsp:setProperty name=”BeanTest” property=”*”/>
：
<jsp:getProperty name=”BeanTest” property=”value”/>
：
（省略）

<jsp:getProperty>および<jsp:setProperty>タグで定義する処理では，<jsp:useBean>タグで作成されたJavaBeansオブジェクトを呼び出します。

異なるJavaBeansクラスを作成する二つ以上の<jsp:useBean>タグでid属性値を重複させると，最後に出現する<jsp:useBean>タグで指定されたオブジェクトが<jsp:getProperty>または<jsp:setProperty>タグでの処理に使用されます。

例では，条件式1と条件式2で，id属性値に同じ値（BeanTest）が指定されています。そのため，条件式1が成立する場合でも，一つ目の<jsp:useBean>タグで登録されたtest.TestClass1クラスのオブジェクトは<jsp:getProperty>および<jsp:setProperty>タグでの処理に使用されません。

(d)　複数のリクエストで意図しないJavaBeansオブジェクトが取得される場合のJSPファイルの記述例3（<jsp:getProperty>タグまたは<jsp:setProperty>タグで，二つ以上の<jsp:useBean>タグで共通して指定されているid属性値を使用してJavaBeansオブジェクトを呼び出す例2）

（省略）
：
<% if (条件式1){ %>
<jsp:useBean id=”BeanTest” class=”test.TestClass1” scope=”page”/>
：
<jsp:setProperty name=”BeanTest” property=”*”/>
：
<jsp:getProperty name=”BeanTest” property=”value”/>
：
<% } %>
<% if(条件式2) { %>
<jsp:useBean id=”BeanTest” class=”test.TestClass2” type=” test.TestIF” scope=”page”/>
：
<jsp:setProperty name=”BeanTest” property=”*”/>
：
<jsp:getProperty name=”BeanTest” property=”value”/>
：
<% } %>
：
（省略）

<jsp:getProperty>および<jsp:setProperty>タグで定義する処理では，<jsp:useBean>タグで作成されたJavaBeansオブジェクトを呼び出します。

異なるJavaBeansクラスを作成する二つ以上の<jsp:useBean>タグでid属性値を重複させると，最後に出現する<jsp:useBean>タグで指定されたオブジェクトが<jsp:getProperty>または<jsp:setProperty>タグでの処理に使用されます。

例では，条件式1と条件式2で，id属性値に同じ値（BeanTest）が指定されています。そのため，条件式1が成立する場合でも，一つ目の<jsp:setProperty>タグでの処理に使用されるのは，二つ目の<jsp:useBean>タグで登録されたtest.TestClass2クラスのオブジェクトです。一つ目の<jsp:useBean>タグで登録されたtest.TestClass1クラスのオブジェクトは<jsp:getProperty>および<jsp:setProperty>タグでの処理に使用されません。

2.3.7　page/tagディレクティブのimport属性暗黙インポート

JSP仕様では，JSPをコンパイルする際に次のクラスを暗黙にインポートします。

java.lang.*

javax.servlet.*

javax.servlet.jsp.*

javax.servlet.http.*

page/tagディレクティブのimport属性暗黙インポート機能を使用すると，上記のクラス以外の任意のクラスを暗黙にインポートできます。

＜この項の構成＞

(1)　暗黙インポートするクラスの指定方法

(2)　インポート文の出力順序

(3)　注意事項

(1)　暗黙インポートするクラスの指定方法

ここでは，page/tagディレクティブのimport属性暗黙インポート機能の指定方法について説明します。page/tagディレクティブのimport属性暗黙インポート機能は，J2EEサーバでJSPをコンパイルする場合，またはcjjspcコマンドでJSPをコンパイルする場合に使用できます。

暗黙にインポートしたいクラスは，完全修飾名のクラス名，または「パッケージ名.*」で指定します。複数のクラス名を指定する場合は，クラス名とクラス名の間をコンマ（,）で区切って指定してください。存在しないクラス名や，クラスパスに誤りがあるクラス名などを指定した場合は，JSPコンパイル時にKDJE39143-Eのメッセージが出力されます。

J2EEサーバでJSPをコンパイルする場合
簡易構築定義ファイルのwebserver.jsp.additional.import.listキーに暗黙にインポートしたいクラスを指定します。
簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

cjjspcコマンドでJSP事前コンパイルする場合
cjjspcコマンドの-addimportオプションで暗黙にインポートしたいクラスを指定します。
コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

(2)　インポート文の出力順序

JSPコンパイル時に，javaファイルに出力されるインポート文の順番を次に示します。

JSP仕様で規定されているクラスのインポート文

java.lang.*

javax.servlet.*

javax.servlet.jsp.*

javax.servlet.http.*

page/tagディレクティブのimport属性に指定されたクラスのインポート文

page/tagディレクティブのimport属性暗黙インポート機能で指定したクラスのインポート文

(3)　注意事項

(a)　cjjspcコマンドでJSP事前コンパイルしたJSPファイル

page/tagディレクティブのimport属性暗黙インポート機能は，JSPコンパイル時に動作します。cjjspcコマンドでJSP事前コンパイルした場合，JSP事前コンパイルしたWebアプリケーションに対して，簡易構築定義ファイルのwebserver.jsp.additional.import.listキーに指定したクラスは暗黙にインポートされません。そのため，cjjspcコマンドでJSP事前コンパイルする場合に，page/tagディレクティブのimport属性暗黙インポート機能を使用するときは，cjjspcコマンドに-addimportオプションを指定してWebアプリケーションをJSP事前コンパイルしてください。

(b)　J2EEサーバ内に複数のWebアプリケーションが存在する場合

簡易構築定義ファイルのwebserver.jsp.additional.import.listキーに指定したクラスは，cjjspcコマンドでJSP事前コンパイルされていないJ2EEサーバ内のすべてのWebアプリケーションに対して有効になります。Webアプリケーションごとに異なるクラスを指定したい場合は，cjjspcコマンドに-addimportオプションを指定してWebアプリケーションをJSP事前コンパイルしてください。

(c)　JSP事前コンパイル後の再コンパイル

次の条件をすべて満たす場合は，再コンパイル時にKDJE39143-Eのメッセージが出力されます。そのため，cjjspcコマンドに-addimportオプションを指定してJSP事前コンパイルしたWebアプリケーションを使用する場合は，簡易構築定義ファイルのwebserver.jsp.additional.import.listキーにcjjspcコマンドの-addimportオプションに指定したクラス名と同じクラス名を指定してください。

JSPファイル内で完全修飾名のクラス名でクラスを定義していない。

cjjspcコマンドの-addimportオプションに暗黙にインポートするクラス名を指定してJSP事前コンパイルする。

簡易構築定義ファイルのwebserver.jsp.additional.import.listキーに，cjjspcコマンドの-addimportオプションに指定した暗黙にインポートするクラスと異なるクラス名を指定する。または，webserver.jsp.additional.import.listキーを省略するか，webserver.jsp.additional.import.listキーに空文字を指定する。

J2EEサーバ上でJSP事前コンパイルしたWebアプリケーションが再コンパイルされる。

(d)　同名のクラスが存在するクラス名を指定した場合

page/tagディレクティブのimport属性暗黙インポート機能で指定したクラス名と，JSP仕様で規定されたインポート対象のパッケージ内のクラス名やpage/tagディレクティブのimport属性に指定されたクラス名が重複する場合，JSPコンパイル時にコンパイルエラーとなり，KDJE39143-Eのメッセージが出力されることがあります。

JSPコンパイル時にコンパイルエラーとなるケースの具体例について説明します。なお，具体例では，次のクラス名が存在していることを前提としています。

packageA.classA

packageB.classA

●異なるパッケージからのインポートクラス名が重複した場合

具体例について説明します。

次の指定内容の場合，複数のパッケージから同名のクラスをインポートしようとしているため，JSPコンパイル時にエラーとなります。

ファイルの種類 | 指定内容
JSPファイル | <%@page import="packageA.classA" %>
簡易構築定義ファイル | webserver.jsp.additional.import.list=packageB.classA

●JSPファイル内で使用するクラスのインポート元パッケージが特定できない場合

具体例について説明します。

次の指定内容の場合，JSPファイル内で使用している「classA」が，「packageA.classA」または「packageB.classA」のどちらかを特定できないため，JSPコンパイル時にエラーとなります。

ファイルの種類
指定内容

JSPファイル
<%@page import="packageA.*" %>
<% System.out.println(classA.method1()); %>

簡易構築定義ファイル
webserver.jsp.additional.import.list=packageB.*

2.4　JSPデバッグ機能

この節では，JSPデバッグ機能について説明します。

JSPデバッグ機能を使用すると，ブレークポイントの設定などのデバッグツールの機能をJSPファイルで実行できるようになり，変換後のjavaソースでのデバッグが不要になります。なお，JSPデバッグ機能は，JSP 2.0以降のJSPファイルで利用できます。

この節の構成を次の表に示します。

表2-8　この節の構成（JSPデバッグ機能）

分類 | タイトル | 参照先
解説 | JSPデバッグ機能の仕組み | 2.4.1
JSPデバッグ機能の使用手順 | 2.4.2
設定 | 実行環境での設定（J2EEサーバの設定） | 2.4.3
注意事項 | JSPデバッグ機能使用時の注意事項 | 2.4.4

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

2.4.1　JSPデバッグ機能の仕組み

2.4.2　JSPデバッグ機能の使用手順

2.4.3　実行環境での設定（J2EEサーバの設定）

2.4.4　JSPデバッグ機能使用時の注意事項

2.4.1　JSPデバッグ機能の仕組み

JSPデバッグ機能の仕組みについて次の図に示します。

図2-1　JSPデバッグの仕組み

図中のデータの流れについて説明します。

JSPファイルからサーブレットのjavaファイルへ変換します。

JSPファイルの行と，JSPファイルから変換したjavaファイルの行のマッピングを記述したSMAP（Source MAP）を作成します。

javaコンパイラでjavaファイルからクラスファイルを作成します。

作成したクラスファイルの拡張属性（SourceDebugExtension属性）にSMAP情報を埋め込みます。

デバッグの際，JPDA（Java Platform Debugger Architecture）を利用して，デバッグツールでクラスファイルに埋め込まれた拡張情報から埋め込まれているSMAPを取得します。

なお，SMAP情報の埋め込みに失敗した場合は，KDJE39324-Eのメッセージが出力されます。

注意

JSPデバッグ機能を使用する場合のクラス名

JSPデバッグ機能を使用する場合と使用しない場合とでは，コンパイル時に作成されるクラスのクラス名が異なります。JSPコンパイル結果のクラス名については，「2.5.7　JSPコンパイル結果のクラス名」を参照してください。

2.4.2　JSPデバッグ機能の使用手順

ここでは，JSPデバッグ機能の使用手順について説明します。JSPデバッグ機能は，J2EEサーバでJSPをコンパイルする場合，またはcjjspcコマンドでJSPをコンパイルする場合に使用できます。

それぞれの場合の使用手順について説明します。

＜この項の構成＞

(1)　J2EEサーバでJSPをコンパイルする場合

(2)　cjjspcコマンドでJSPをコンパイルする場合

(1)　J2EEサーバでJSPをコンパイルする場合

J2EEサーバでJSPをコンパイルする場合のJSPデバッグ機能の使用手順の流れを次の図に示します。

図2-2　JSPデバッグ機能の使用手順（J2EEサーバでJSPをコンパイルする場合）

図中の手順について説明します。

J2EEサーバの設定
JSPデバッグ機能を有効にします。また，JSPのリロードを有効にします。JSPのリロードについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.8.9　JSPのリロード」を参照してください。

J2EEサーバの開始
J2EEサーバを開始します。
JSPデバッグ機能を有効にすると，J2EEサーバの開始時には，KDJE39322-Wのメッセージがメッセージログに出力されます。

JSPファイルの作成，修正
JSPファイルを作成，または修正します。

JSPのテスト・デバッグ
MyEclipseなどのJPDAに対応したデバッグツールを使用して，テストおよびデバッグをします。JSPを修正する場合は，手順の3.に戻ります。

JSPの実行環境への配布
作成したJSPを含むJ2EEアプリケーションを開発環境でエクスポートして，実行環境へインポートします。

(2)　cjjspcコマンドでJSPをコンパイルする場合

J2EEアプリケーション開始前に，すべてのJSPをコンパイルしたい場合，cjjspcコマンドでJSP事前コンパイルを実施します。JSP事前コンパイルについては，「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

cjjspcコマンドでJSP事前コンパイルを実施する場合のJSPデバッグ機能の使用手順の流れを次の図に示します。

図2-3　JSPデバッグ機能の使用手順（cjjspcコマンドでJSPをコンパイルする場合）

図中の手順について説明します。

J2EEサーバの開始
JSPデバッグ機能を有効にします。また，JSPのリロードを有効にします。JSPのリロードについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.8.9　JSPのリロード」を参照してください。
JSPデバッグ機能を有効にすると，J2EEサーバの開始時には，KDJE39322-Wのメッセージがメッセージログに出力されます。

JSPファイルの作成，修正
JSPファイルを作成，または修正します。

JSP事前コンパイルの実行
cjjspcコマンドを使用して，JSP事前コンパイルを実行します。-debuggingオプションを指定してコマンドを実行し，JSPファイルをコンパイルします。
cjjspcコマンド実行時には，KDJE53442-Wのメッセージがコンソールログに出力されます。

JSPのテスト・デバッグ
MyEclipseなどのJPDAに対応したデバッグツールを使用して，テストおよびデバッグをします。JSPを修正する場合は，手順の2.に戻ります。

JSPの再コンパイル
JSPワークディレクトリを削除します。また，-debuggingオプションを指定しないでcjjspcコマンドを使用して，JSPファイルを再度コンパイルします。
なお，JSPファイルを再コンパイルしない場合，JSPを実行できません。詳細は「2.4.4　JSPデバッグ機能使用時の注意事項」を参照してください。

JSPの実行環境への配布
作成したJSPを含むJ2EEアプリケーションを開発環境でエクスポートして，実行環境へインポートします。

cjjspcコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

2.4.3　実行環境での設定（J2EEサーバの設定）

JSPデバッグ機能を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。JSPデバッグ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.jsp.debugging.enabledに指定します。このパラメタでは，JSPデバッグ機能を使用するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

2.4.4　JSPデバッグ機能使用時の注意事項

ここでは，JSPデバッグ機能を使用する場合の注意事項について説明します。

＜この項の構成＞

(1)　JSPデバッグ機能で作成されたクラスファイルの削除

(2)　cjjspcコマンドを使用してJSPをコンパイルする場合のJ2EEサーバの設定

(1)　JSPデバッグ機能で作成されたクラスファイルの削除

JSPデバッグ機能で作成されたクラスファイルは，JSPデバッグ機能が無効な環境では使用できません。JSPデバッグ機能が有効な環境で作成されたJ2EEアプリケーションを，JSPデバッグ機能が無効な環境に配布する場合，JSPデバッグ機能で作成されたクラスファイルを削除する必要があります。

クラスファイルを削除する方法を次に示します。

展開ディレクトリ形式のアプリケーションについてJSP事前コンパイル機能を使用してJSPをコンパイルした場合
JSP事前コンパイル機能のJSPワークディレクトリを削除してください。JSPワークディレクトリについては，「2.5.5(2)　JSPコンパイル結果の出力先」を参照してください。

1.以外の方法でJSPをコンパイルした場合
cjstopappコマンドを使用して，J2EEアプリケーションを停止してください。

(2)　cjjspcコマンドを使用してJSPをコンパイルする場合のJ2EEサーバの設定

cjjspcコマンドを使用してJSPをコンパイルする場合は，JSPが実行されるJ2EEサーバでJSPデバッグ機能を有効にしてください。

JSPデバッグ機能が無効なJ2EEサーバのアプリケーションに対して，cjjspcコマンドに-debuggingオプションを指定してJSPをコンパイルした場合，ロードするクラスファイルが異なります。そのため，JSPのHTTPリクエストに対して，Webコンテナがエラーステータスコード404を返します。

2.5　JSP事前コンパイル機能とコンパイル結果の保持

この節では，JSP事前コンパイル機能とコンパイル結果の保持について説明します。

通常，Webアプリケーション内のJSPファイルは，JSPファイルへの最初のリクエスト到着時にWebコンテナ上でコンパイルされます。JSP事前コンパイル機能を使用すると，Webアプリケーションのデプロイ前にコンパイルできます。JSP事前コンパイル機能であらかじめJSPファイルをコンパイルしておくと，JSPファイルへの最初のリクエスト到着時のレスポンスタイムを短縮できます。

また，JSPコンパイル結果である，Javaソースファイルおよびクラスファイルを，J2EEサーバの再起動時に保持するかどうか設定できます。

この節の構成を次の表に示します。

表2-9　この節の構成（JSP事前コンパイル機能とコンパイル結果の保持）

分類 | タイトル | 参照先
解説 | JSP事前コンパイル機能の概要 | 2.5.1
JSP事前コンパイルの方法 | 2.5.2
JSP事前コンパイルの適用例 | 2.5.3
JSP事前コンパイルの実行時の処理 | 2.5.4
JSPコンパイル結果のライフサイクルと出力先 | 2.5.5
JSP事前コンパイルを使用しない場合のJSPコンパイル結果 | 2.5.6
JSPコンパイル結果のクラス名 | 2.5.7
設定 | 実行環境での設定（J2EEサーバの設定） | 2.5.8

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.5.1　JSP事前コンパイル機能の概要

2.5.2　JSP事前コンパイルの方法

2.5.3　JSP事前コンパイルの適用例

2.5.4　JSP事前コンパイルの実行時の処理

2.5.5　JSPコンパイル結果のライフサイクルと出力先

2.5.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果

2.5.7　JSPコンパイル結果のクラス名

2.5.8　実行環境での設定（J2EEサーバの設定）

2.5.1　JSP事前コンパイル機能の概要

JSP事前コンパイル機能とは，Webアプリケーションに含まれるJSPファイルを，デプロイ前にコンパイルし，クラスファイルを生成する機能です。

JSP事前コンパイル機能を使用した場合の処理の流れを次の図に示します。

図2-4　JSP事前コンパイル機能を使用した場合の処理の流れ

通常，Webアプリケーションに含まれるJSPファイルは，JSPファイルに最初のリクエストが到着したときにコンパイルされ，JSPファイルからクラスファイルが生成されます。このため，JSPへの初回リクエスト時のレスポンスタイムは遅くなります。また，web.xmlで<load-on-startup>を指定していると，コンパイルのタイミングはWebアプリケーションの開始時となるため，JSPへの初回リクエスト到着時のレスポンスタイムは短縮できます。ただし，Webアプリケーションの開始に時間が掛かります。

JSP事前コンパイル機能を使用すると，あらかじめ，クラスファイルの生成までを実施しておけるので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。

2.5.2　JSP事前コンパイルの方法

JSP事前コンパイル方法には次の二つがあります。

cjjspcコマンドによるJSP事前コンパイル

cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

ここでは，JSP事前コンパイルを実行するコマンドの概要と，コンパイル方法について説明します。なお，コンパイル方法は，どの場面でJSPファイルを事前にコンパイルするかによって異なります。JSP事前コンパイルを適用する場面とコンパイル方法については，「2.5.3　JSP事前コンパイルの適用例」を参照してください。

＜この項の構成＞

(1)　コマンドの概要

(2)　cjjspcコマンドによるJSP事前コンパイル

(3)　cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

(1)　コマンドの概要

ここでは，JSP事前コンパイルを実施するための前提条件と，JSP事前コンパイル実行時に必要なファイル，および実行後に生成されるファイルについて説明します。

前提条件

JSP事前コンパイルを実施するためには，コンパイルするJSPファイルがWebアプリケーションのルートディレクトリ以下，またはそのサブディレクトリ以下に格納されていることが前提です。

JSP事前コンパイルに必要なファイル

JSP事前コンパイルを実施するためには，次に示すファイルが必要です。

JSPファイル（JSP 1.1，JSP 1.2，JSP 2.0，またはJSP 2.1）※1

JSP 2.0仕様またはJSP 2.1仕様に準拠したタグファイル

JSPファイルおよびタグファイルから静的にインクルードされるファイル

TLDファイル※2

web.xml※2，※3

コンパイルに必要なクラスライブラリ

注※1　JSPファイルとは，次に示すファイルを指します。

拡張子が.jspまたは.jspxであるファイル（.jspxはJSP 2.0以降の場合だけ）

web.xmlの<jsp-file>タグに指定されたファイル

web.xmlの<jsp-property-group><url-pattern>タグに合致するファイル（JSP 2.0以降の場合だけ）

注※2　JSP事前コンパイル実行時にDTDまたはXMLスキーマに従っているかどうかが検証されます。

注※3　web.xmlがない場合，Webアプリケーションのバージョンを2.5と見なしてコンパイルが実行されます。

JSP事前コンパイル後に生成されるファイル（JSPコンパイル結果）

JSPファイルやタグファイルから生成された，JavaソースファイルおよびクラスファイルをJSPコンパイル結果といいます。JSP事前コンパイルを実施すると，JSPワークディレクトリに次に示すJSPコンパイル結果が生成されます。

JSPファイルから生成されたJavaソースファイルおよびクラスファイル

タグファイルから生成されたJavaソースファイルおよびクラスファイル

なお，JSP事前コンパイル実行時には，Javaソースファイルを保存しておくかどうかを設定できます。

(2)　cjjspcコマンドによるJSP事前コンパイル

cjjspcコマンドは，JSP事前コンパイルを実施するためのコマンドです。アプリケーションの開発時などにこのコマンドを実施すると，Webアプリケーションに含まれるJSPファイルをコンパイルできます。cjjspcコマンドによるJSP事前コンパイルには，次の二つの方法があります。

JSPファイル単位での事前コンパイル
Webアプリケーションに含まれるJSPファイルのうち，指定されたJSPファイルだけをコンパイルします。

Webアプリケーション単位での事前コンパイル
Webアプリケーションに含まれるすべてのJSPファイルをコンパイルします。

また，このコマンド実行時に次の内容を設定できます。

コンパイル不要なJSPファイルの指定
コンパイル不要なJSPファイルがある場合，あらかじめ不要なファイルを指定しておくことで，事前コンパイルの対象外にできます。指定方法には，コンパイル不要なJSPファイル名をコマンドに一つずつ指定する方法と，コンパイル不要なJSPファイル名をファイルにまとめて記載したファイル（コンパイル対象外リストファイル）をコマンドに指定する方法があります。

実行結果リストファイルを出力するかどうかの指定
実行結果リストファイルを出力するかどうかを指定できます。実行結果リストファイルとは，cjjspcコマンドの実行結果を出力したファイルです。コンパイルに成功したJSPファイル，コンパイルに失敗したJSPファイル，およびコンパイル対象外のJSPファイルのパスを一覧で出力します。

Javaソースファイルを保存するかどうかの指定
JSPから生成されたJavaソースファイルを保存しておくかどうかを指定できます。

JSPコンパイル時のJava言語仕様のバージョンの指定
JSPトランスレーションによって生成されたJavaソースファイルをコンパイルするときのJava言語仕様のバージョンを指定できます。

JSPワークディレクトリ名を変更するかどうかの指定
JSPワークディレクトリとは，JSPコンパイル結果を格納するディレクトリのことです。JSPワークディレクトリ名は変更できます。なお，JSPワークディレクトリについては，「2.5.5(2)　JSPコンパイル結果の出力先」を参照してください。

デフォルトの文字エンコーディングの指定
JSPファイルのデフォルトの文字エンコーディングを指定できます。なお，デフォルトの文字エンコーディングの概要については，「2.6　デフォルトの文字エンコーディング設定機能」を参照してください。また，07-00でJSP事前コンパイル機能を使用していたWebアプリケーションに対して，07-10でデフォルトの文字エンコーディングを設定する場合の注意については，「2.6.8(5)　07-00でJSP事前コンパイルを実行したWebアプリケーションへの文字エンコーディング設定」を参照してください。

JSPデバッグ機能を使用するかどうかの指定
JSPデバッグ機能を使用するかどうかを指定できます。JSPデバッグ機能については「2.4　JSPデバッグ機能」を参照してください。

暗黙インポートするクラスの指定
page/tagディレクティブのimport属性暗黙インポート機能を使用して暗黙インポートするクラス名を指定できます。page/tagディレクティブのimport属性暗黙インポート機能については「2.3.7　page/tagディレクティブのimport属性暗黙インポート」を参照してください。

なお，これらの設定は，コマンドのオプションで指定します。JSPの事前コンパイルのコマンド（cjjspcコマンド）の使い方については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

注意

JavaVM起動オプションの変更

環境変数「CJ_CMD_JVM_ARGS」を設定すると，cjjspcコマンドが動作するJavaVMの起動オプションを変更できます。

デフォルトではJavaVMの起動オプションに「-Xmx512m」（Javaヒープメモリ領域の最大値が512MB）が設定されています。cjjspcコマンドで大規模なWebアプリケーションをコンパイルする場合，Javaヒープメモリ領域の最大値を超え，java.lang.OutOfMemoryErrorが発生するおそれがあります。したがって，大規模なWebアプリケーションをコンパイルする場合は，あらかじめ環境変数「CJ_CMD_JVM_ARGS」に，適切なJavaヒープメモリ領域を指定する必要があります。

参考

cjjspcコマンドを使用したJSP事前コンパイルで，JSPファイルまたはタグファイルのトランスレーション時にエラーが発生すると，エラーメッセージが出力されます。エラーメッセージはコンソールに出力されます。

コマンド実行時に標準出力または標準エラー出力にログを出力します。ログ出力の結果をファイルに残す場合は，コマンドの出力をファイルにリダイレクトしてください。
ログ出力の結果をファイルに残す場合の指定例を示します。
Windowsの場合の指定例

> cjjspc -root D:¥app¥webapp1 1> .¥stdout.log 2> .¥stderr.log

UNIXの場合の指定例

# cjjspc -root /app/webapp1 1> ./stdout.log 2> ./stderr.log

(3)　cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

cjstartappコマンドは，J2EEアプリケーションを開始するためのコマンドです。cjstartappコマンドに，JSP事前コンパイルをするオプションを指定すると，JSPの事前コンパイルを実施してから，J2EEアプリケーションが開始されます。J2EEアプリケーション開始時のJSP事前コンパイルでは，J2EEアプリケーションに含まれるすべてのJSPファイルをコンパイルします。

このコマンドの実行時の動作はあらかじめ設定できます。設定できる内容を次に示します。

Javaソースファイルを保存するかどうかの指定
JSPファイルから生成されたJavaソースファイルを保存しておくかどうかを指定できます。

JSPコンパイル時のJava言語仕様のバージョンの指定
JSPトランスレーションによって生成されたJavaソースファイルをコンパイルするときのJava言語仕様のバージョンを指定できます。

JSPワークディレクトリ名を変更するかどうかの指定
JSPワークディレクトリとは，JSPコンパイル結果を格納するディレクトリのことです。JSPワークディレクトリ名は変更できます。なお，JSPワークディレクトリについては，「2.5.5(2)　JSPコンパイル結果の出力先」を参照してください。

暗黙インポートするクラスの指定
page/tagディレクティブのimport属性暗黙インポート機能を使用して暗黙インポートするクラス名を指定できます。page/tagディレクティブのimport属性暗黙インポート機能については「2.3.7　page/tagディレクティブのimport属性暗黙インポート」を参照してください。

なお，これらの設定は，J2EEサーバの動作設定のカスタマイズで実施します。J2EEサーバの動作設定のカスタマイズについては，「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

参考

cjstartappコマンドを使用したJSP事前コンパイルで，JSPファイルまたはタグファイルのトランスレーション時にエラーが発生すると，エラーメッセージが出力されます。エラーメッセージはWebサーブレットログ，またはメッセージログに出力されます。

注意

JSPから生成されるJavaソースのコンパイルについて

cjjspcコマンドを使用して生成されたクラスファイルは，J2EEサーバでの実行時に使用されます。cjjspcコマンドでは，J2EEサーバで生成されたクラスファイルと同じクラスファイルを生成します。

このため，JSPファイルまたはタグファイルから生成されたJavaソースをコンパイルする場合，-sourceオプションでのJava言語仕様のバージョンの指定，または-classpathオプションでのクラスパスの指定以外はできません。Java言語仕様のバージョンの指定方法についてはマニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

2.5.3　JSP事前コンパイルの適用例

JSP事前コンパイルは次に示すときに使用できます。

アプリケーション開発時

システム運用時

JSP事前コンパイルの適用場面と使用するコマンドの対応表を次に示します。

表2-10　JSP事前コンパイルの適用場面と使用するコマンドの対応

適用する場面 | 使用するコマンド | 参照先
アプリケーション開発 | Webアプリケーションの開発時 | cjjspcコマンド | (1)　アプリケーション開発での使用
システム運用 | J2EEアプリケーション開始時 | cjstartappコマンド | (2)　システム運用での使用
J2EEアプリケーション入れ替え時 | 通常の入れ替え | cjstartappコマンド
リロードによる入れ替え | cjjspcコマンド
リデプロイによる入れ替え | cjjspcコマンド

JSP事前コンパイルを使用する場面について次に説明します。使用するコマンドの概要については，「2.5.2　JSP事前コンパイルの方法」を参照してください。

なお，cjstartappコマンドでJSP事前コンパイルを実施するためのオプションを指定すると，cjstartappコマンドの実行時にJSPコンパイルが実施されます。この処理はJ2EEサーバで行われるため，一時的にJ2EEサーバプロセスのメモリ使用量が増加します。

＜この項の構成＞

(1)　アプリケーション開発での使用

(2)　システム運用での使用

(1)　アプリケーション開発での使用

Webアプリケーションの開発では，Webアプリケーション完成後に，JSP事前コンパイルを実施します。

JSP事前コンパイルを実施するには，cjjspcコマンドを使用します。Webアプリケーション開発での，JSP事前コンパイルの適用例を次の図に示します。

図2-5　Webアプリケーション開発でのJSP事前コンパイルの適用例

JSP事前コンパイル機能を使用して，完成したWebアプリケーションに含まれるすべてのJSPファイルを，一括してコンパイルします。この結果，Webアプリケーション実行時のJSP初回リクエストのレスポンスタイムを向上できます。

Webアプリケーション内のすべてのJSPファイルを一括でコンパイルするには，cjjspcコマンドの，Webアプリケーション単位でのJSP事前コンパイルを実施します。

なお，cjjspcコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

(2)　システム運用での使用

システム運用時では，JSP初回リクエストのレスポンスタイムを向上させるために，運用の開始前に，JSP事前コンパイルを実施します。システム運用時のJSP事前コンパイルは，J2EEアプリケーションを開始するときや，J2EEアプリケーションの入れ替えをするときに実施します。システム運用での，JSP事前コンパイルの適用例を次の図に示します。

図2-6　システム運用でのJSP事前コンパイルの適用

JSP事前コンパイル機能を適用する場面ごとに概要を説明します。なお，システム運用時にJSP事前コンパイルを使用するときのコンパイルの実施方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。

(a)　J2EEアプリケーション開始時

J2EEアプリケーション開始時に，インポート済みのJ2EEアプリケーションに対してJSP事前コンパイルを使用できます。J2EEアプリケーション開始時に実施するJSP事前コンパイルは，cjstartappコマンドにJSP事前コンパイルを実施するためのオプションを指定して実行します。このコマンドを実行すると，J2EEアプリケーションの開始前に，J2EEアプリケーションに含まれるJSPファイルを一括してコンパイルします。

(b)　J2EEアプリケーション入れ替え時

J2EEアプリケーションを入れ替える場合，入れ替えを実施する前にJSP事前コンパイルを使用できます。なお，JSP事前コンパイルの方法は，J2EEアプリケーション入れ替えの方法によって異なります。

通常のJ2EEアプリケーションの入れ替えの場合
通常のJ2EEアプリケーションの入れ替えとは，J2EEアプリケーションをいったん停止してから，新しいアプリケーションと入れ替える方法です。
通常のJ2EEアプリケーションの入れ替えの場合，入れ替え後のJ2EEアプリケーションをインポートしたあとに，cjstartappコマンドにJSP事前コンパイルを実施するためのオプションを指定して，JSP事前コンパイルを実行します。このコマンドを実行すると，入れ替え後のJ2EEアプリケーションが開始される前に，J2EEアプリケーションに含まれるJSPファイルが一括でコンパイルされます。

リロードによるJ2EEアプリケーションの入れ替えの場合
リロードによるJ2EEアプリケーションの入れ替えとは，J2EEアプリケーションを停止しないで，新しいJ2EEアプリケーション（展開形式のアプリケーション）と入れ替える方法です。
JSPコンパイル結果を含むJ2EEアプリケーションをリロード機能を使用して運用している場合で，JSPファイルの修正が発生したときに，cjjspcコマンドによって修正したJSPファイルのコンパイルができます。

リデプロイによるJ2EEアプリケーションの入れ替えの場合
リデプロイによるJ2EEアプリケーションの入れ替えとは，J2EEアプリケーションを停止しないで，新しいJ2EEアプリケーション（アーカイブ形式のアプリケーション）と入れ替える方法です。
リデプロイによるJ2EEアプリケーションの入れ替えの流れを次に示します。

cjjspcコマンドでJSP事前コンパイルを実施し，J2EEアプリケーションに含まれるすべてのJSPファイルを一括してコンパイルします。

1.で生成したJSPコンパイル結果を含んだEARファイルを作成します。

2.のEARファイルをリデプロイします。

なお，J2EEアプリケーションの入れ替えの概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。なお，リロードについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.8　J2EEアプリケーションの更新検知とリロード」を参照してください。

2.5.4　JSP事前コンパイルの実行時の処理

ここでは，JSP事前コンパイル実行時に実施されるチェックやJSP事前コンパイル機能を実行したJ2EEアプリケーションの動作について説明します。

＜この項の構成＞

(1)　JSP事前コンパイルで実施されるチェック

(2)　JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い

(3)　JSP事前コンパイル機能の注意

(1)　JSP事前コンパイルで実施されるチェック

JSP事前コンパイルの実行時には，web.xmlの妥当性チェック，およびJSPコンパイル結果のバージョンチェックが実施されます。

(a)　web.xmlの妥当性チェック

JSP事前コンパイル機能では，コンパイル処理を実行する前に，web.xmlがDTDまたはXMLスキーマに従っているかどうかの検証が実施されます。また，JSP事前コンパイル時に参照する要素については，JSP事前コンパイルに必要な範囲で，設定値が妥当であるかどうかについても検証されます。スキーマに従っていない場合は，JSPファイルからJavaファイルを生成するJSPのトランスレーション時に，エラーが発生します。

JSP事前コンパイル実行時に検証されるweb.xmlの要素を次の表に示します。

表2-11　JSP事前コンパイル時に検証されるweb.xmlの要素

タグ名 | タグの説明 | Servletのバージョン
2.2 | 2.3 | 2.4 | 2.5
<!DOCTYPE> | DOCTYPE宣言 | ○ | ○ | × | ×
<web-app> | ルートタグ | ○ | ○ | ○ | ○
| <servlet> | サーブレットについての定義 | ○ | ○ | ○ | ○
|  | <jsp-file> | JSPファイル名 | ○ | ○ | ○ | ○
| <taglib> | タグライブラリについての定義 | ○ | ○ | － | －
|  | <taglib-uri> | タグライブラリのURI | ○ | ○ | － | －
|  | <taglib-location> | タグライブラリ記述ファイル（TLD）の場所 | ○ | ○ | － | －
| <jsp-config> | JSPについての定義 | － | － | ○ | ○
|  | <taglib> | タグライブラリについての定義 | － | － | ○ | ○
|  |  | <taglib-uri> | タグライブラリのURI | － | － | ○ | ○
|  |  | <taglib-location> | タグライブラリ記述ファイル（TLD）の場所 | － | － | ○ | ○
|  | <jsp-property-group> | 指定したURLパターンに合致するJSPの設定 | － | － | ○ | ○
|  |  | <url-pattern> | 設置を適用するJSPのURLパターン | － | － | ○ | ○
|  |  | <el-ignored> | EL（式言語）を無視するかの設定 | － | － | ○ | ○
|  |  | <scripting-invalid> | スクリプティング要素を無効にするかの設定 | － | － | ○ | ○
|  |  | <page-encoding> | ページエンコーディング名 | － | － | ○ | ○
|  |  | <include-prelude> | JSPのヘッダとしてインクルードするファイル | － | － | ○ | ○
|  |  | <include-coda> | JSPのフッタとしてインクルードするファイル | － | － | ○ | ○
|  |  | <is-xml> | XML形式で記述されているかの設定 | － | － | ○ | ○
|  |  | <deferred-syntax-allowed-as-literal> | ELが使えない部分で#{の文字列があった場合にエラーにするかの設定 | － | － | － | ○
|  |  | <trim-directive-whitespaces> | JSPから余分な空白を出力しないようにするかの設定 | － | － | － | ○

（凡例）○：検証される　　×：検証されない　　－：サポートしていない要素

(b)　JSPコンパイル結果のバージョンチェック

JSP事前コンパイル機能使用時，J2EEサーバはweb.xmlで指定されたWebアプリケーションのバージョンと，JSPコンパイル時のJSPのバージョンが合致するかチェックします。バージョンのチェックは次のタイミングで実施されます。

アプリケーション開始時に，JSP事前コンパイルを実施する指定をしていないとき（-jspcオプションを指定しないで，cjstartappコマンドでアプリケーションを開始したとき）

cjjspcコマンドを使用して，コンパイル対象外ファイルを指定してWebアプリケーション単位のJSP事前コンパイルを実行したとき

cjjspcコマンドを使用して，JSPファイル単位にJSP事前コンパイルを実行したとき

JSPから生成されるクラスファイルは，web.xmlで指定されたWebアプリケーションのバージョンに依存します。JSP事前コンパイル実行時のWebアプリケーションとバージョンが異なるWebアプリケーションで使用することはできません。このため，Webアプリケーションのバージョンを変更した際には，すべてのJSPファイルをコンパイルする必要があります。

なお，次の場合は，Webアプリケーションに含まれるすべてのJSPをコンパイルするため，JSPコンパイル結果のチェックは実施されません。

コンパイル対象外ファイルを指定しないでWebアプリケーション単位のJSP事前コンパイルを実行したとき

アプリケーション開始時のJSP事前コンパイルを実行したとき

参考

JSPコンパイル結果のバージョンチェックが実施されると，コンパイル対象のWebアプリケーションのJSPワークディレクトリに，JSPファイルのバージョン情報が記述されたバージョン情報ファイルが生成されます。バージョン情報ファイルは次の場所に生成されます。

<Webアプリケーションのディレクトリ>/WEB-INF/<JSPワークディレクトリ名>/WEB-INF/<JSPワークディレクトリ名>/jsp_compile_info

(c)　TLDファイルのチェック

TLDファイルは，JSP事前コンパイル実行時にDTDまたはXMLスキーマに従っているかどうか検証されます。WebアプリケーションのバージョンごとにTLDファイルのチェックについて説明します。

Webアプリケーションのバージョンが2.4以降の場合
デフォルトで検証が実施されます。なお，スキーマに従っていない場合，JSPファイルのトランスレーション時にエラーとなります。

Webアプリケーションのバージョンが2.3以前の場合
あらかじめ，検証をするかどうか設定しておく必要があります。TLDファイルを検証する設定をしている場合に，JSP事前コンパイル実行時に検証されます。
なお，TLDファイルの検証については，「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

(2)　JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い

JSP事前コンパイル機能を実行したJ2EEアプリケーションの動作について説明します。

(a)　リクエスト実行時およびJ2EEアプリケーション開始時の動作

JSP事前コンパイルを実施していると，リクエスト実行時にはJSPコンパイルは実施されません。事前コンパイル時に作成したJSPのクラスファイルがロードされ，実行されます。

このとき，JSPファイルからコンパイルされたクラスファイルがない場合などには，エラーになります。JSP事前コンパイルを実施していて，ファイルがない場合のJ2EEサーバの挙動を次の表に示します。

表2-12　ファイルがない場合のJ2EEサーバの挙動（JSP事前コンパイルを実行しているとき）

存在しないファイル | J2EEサーバの挙動
JSPファイル | JSPファイル | JSPファイルを参照しない
クラスファイル | 404エラーを返す
タグファイル | タグファイル | タグファイルを参照しない
クラスファイル | 500エラーを返す（java.lang.NoClassDefFoundErrorが発生する）
静的インクルードされたファイル | 静的インクルードされたファイルを参照しない
TLDファイル | TLDファイルを参照しない

事前コンパイルを実施してない場合でファイルがないときは，J2EEサーバは次のように動作します。

表2-13　ファイルがない場合のJ2EEサーバの挙動（JSP事前コンパイルを実行していないとき）

存在しないファイル | J2EEサーバの挙動
JSPファイル | JSPファイル | 404エラーを返す
クラスファイル | JSPファイルをコンパイルする
タグファイル | タグファイル | 500エラーを返す（コンパイルエラー）
クラスファイル | タグファイルをコンパイルする
静的インクルードされたファイル | 500エラーを返す（コンパイルエラー）
TLDファイル

(b)　J2EEアプリケーション開始時の動作

web.xmlでJSPファイルに<load-on-startup>を指定したWebアプリケーションのJSPファイルを事前コンパイルした場合，J2EEアプリケーション開始時には，JSPコンパイルは実施されません。JSP事前コンパイル時に生成されたクラスファイルがロードされ，jspInitメソッドが実行されます。このとき，JSPのクラスファイルまたはJSPが依存するクラスファイルがない場合は，JSPファイルのロードに失敗します。

なお，サーブレットとJSPのエラー通知の設定が有効になっている場合は，Webアプリケーション開始時に失敗します。サーブレットとJSPのエラー通知の設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.16　サーブレットとJSPのエラー通知の設定」を参照してください。

(3)　JSP事前コンパイル機能の注意

ここでは，JSP事前コンパイル機能での注意事項を説明します。

「jsp_precompile」を付加したリクエストの送信
JSP事前コンパイルを実行したアプリケーションに，クエリ文字列「jsp_precompile」，または「jsp_precompile=true」を付加したリクエストを送信しても，JSPコンパイルは実行されません。

JSP事前コンパイルのコマンドの複数起動による同じWebアプリケーションの操作
cjjspcコマンドの複数起動によって同じWebアプリケーションに対するJSP事前コンパイルを実行することはできません。また，アプリケーション開始時のJSP事前コンパイル実行時にcjjspcコマンドによって同じWebアプリケーションに対するコンパイル処理を実行することはできません。
なお，コマンドの排他処理のため，JSP事前コンパイル実行中には，JSPワークディレクトリにロックファイルが生成されます。ロックファイルは次の場所に生成されます。
<Webアプリケーションのディレクトリ>/WEB-INF/<JSPワークディレクトリ名>/WEB-INF/<JSPワークディレクトリ名>/ExecutingJspPrecompilation.lock

JSPコンパイル結果を使用するアプリケーションに移行する場合
アーカイブ形式のJ2EEアプリケーションの場合，アプリケーション開始時のJSP事前コンパイルで生成したコンパイル結果は，アプリケーションの停止時に削除されます。
アプリケーション開始時のJSP事前コンパイルで生成したJSPコンパイル結果を，アプリケーションの停止後も利用する場合の手順を，J2EEアプリケーションの形式ごとに説明します。
アーカイブ形式のJ2EEアプリケーションの場合

アプリケーション開始時のJSP事前コンパイルを実行する

アプリケーションをエクスポートする

リデプロイ機能などを使用して，JSPコンパイル結果を含むアプリケーションに入れ替える

展開ディレクトリ形式のJ2EEアプリケーションの場合

cjjspcコマンドまたはアプリケーション開始時にJSP事前コンパイルを実行する

JSPコンパイル結果を使用しないアプリケーションに移行する場合
JSP事前コンパイルで生成されたJSPコンパイル結果を使用しない場合は，JSPワークディレクトリを，ディレクトリごと削除する必要があります。
JSPコンパイル結果を使用しない場合の手順を，J2EEアプリケーションの形式ごとに説明します。
アーカイブ形式のJ2EEアプリケーションの場合

J2EEアプリケーションをエクスポートする

EARファイルを展開する

<Webアプリケーションのルートディレクトリ>/WEB-INFの下にある，JSPワークディレクトリをディレクトリごと削除する

EARファイルを作成する

リデプロイ機能などを使用して，J2EEアプリケーションを入れ替える

展開ディレクトリ形式のJ2EEアプリケーションの場合

J2EEアプリケーションを停止する

<Webアプリケーションのルートディレクトリ>/WEB-INFの下にある，JSPワークディレクトリをディレクトリごと削除する

J2EEアプリケーションを開始する

JSPファイルが依存するファイルを修正した場合
タグファイル，静的にインクルードされたファイル，またはTLDファイルを更新した場合は，更新したファイルを参照するすべてのJSPファイルをコンパイルする必要があります。

JSP事前コンパイル機能を使用する展開ディレクトリ形式のJ2EEアプリケーションを更新する場合
JSP事前コンパイル機能を使用する展開ディレクトリ形式のJ2EEアプリケーションを更新する場合，次の点に注意してください。

JSPファイルまたはタグファイルをJ2EEアプリケーションに追加した場合
追加したJSPファイルまたはタグファイルを参照するJSPファイルを，すべてコンパイルしてください。なお，JSPファイルのコンパイルには，JSP事前コンパイル機能を使用してください。

開発環境で更新したJSPコンパイル結果を実行環境に反映する場合
開発環境のJ2EEアプリケーションのJSPワークディレクトリ下にあるクラスファイルを，実行環境のJ2EEアプリケーションのJSPワークディレクトリにコピーしてください。この場合，開発環境でJSP事前コンパイル実行時に更新された，すべてのクラスファイルがコピー対象となります。

2.5.5　JSPコンパイル結果のライフサイクルと出力先

JSPは，Webコンテナ上でコンパイルされ，Javaソースファイルおよびクラスファイルが生成されます。Webコンテナでは，JSPのコンパイル結果である，Javaソースファイルおよびクラスファイルを，J2EEサーバの再起動時に保持するかどうか設定できます。ここでは，JSPファイルのコンパイル結果を保持するための設定について説明します。

JSP事前コンパイル機能を使用している場合の，JSPコンパイル結果のライフサイクルと，JSPコンパイル結果の出力先について説明します。

＜この項の構成＞

(1)　JSPコンパイル結果のライフサイクル

(2)　JSPコンパイル結果の出力先

(1)　JSPコンパイル結果のライフサイクル

JSP事前コンパイルを使用している場合のJSPのコンパイル結果のライフサイクルについて説明します。

コンパイル結果の生成

JSP事前コンパイル機能を使用する場合は，次のどちらかのタイミングでコンパイル結果が生成されます。

cjjspcコマンドを実行するとき

cjstartappコマンドに-jspcオプションを指定してWebアプリケーションを開始するとき

コンパイル結果の削除

アーカイブ形式のJ2EEアプリケーションの場合，アプリケーション開始時のJSP事前コンパイルを実行して生成されたコンパイル結果は，アプリケーションの停止時に削除されます。

(2)　JSPコンパイル結果の出力先

JSP事前コンパイルを実施すると，JSPワークディレクトリが作成され，JSPコンパイル結果はJSPワークディレクトリに出力されます。ただし，コンパイル対象となるJSPファイルが存在しない場合は，JSPワークディレクトリは作成されません。出力されるファイルは次のとおりです。

JSPファイルから生成されたJavaソースファイル※

1.のJavaソースファイルをコンパイルしたクラスファイル

タグファイルから生成されたJavaソースファイル※

3.のJavaソースファイルをコンパイルしたクラスファイル

注※　JSP事前コンパイルを実施する場合は，これらのファイルを保存するかどうかを設定できます。

ここでは，デフォルトの出力先と，出力先のディレクトリ構成について説明します。なお，出力されるクラス名については，「2.5.7　JSPコンパイル結果のクラス名」を参照してください。

(a)　デフォルトの出力先

JSP事前コンパイルを実行する場合，コンパイル結果はJSPワークディレクトリに出力されます。デフォルトのJSPワークディレクトリは次の場所になります。

Windowsの場合

<WebアプリケーションのWEB-INFディレクトリ>¥cosminexus_jsp_work

UNIXの場合

<WebアプリケーションのWEB-INFディレクトリ>/cosminexus_jsp_work

WEB-INFディレクトリがない場合，JSPワークディレクトリ作成時にWEB-INFディレクトリおよびJSPワークディレクトリが自動的に作成されます。

なお，JSPワークディレクトリ名はデフォルト値が設定されていますが，必要に応じて変更できます。cjjspcコマンドでJSP事前コンパイルを実施する場合のJSPワークディレクトリ名の変更については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。cjstartappコマンドでJ2EEアプリケーションの開始時にJSP事前コンパイルを実施する場合のJSPワークディレクトリ名の変更については，「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

また，JSPワークディレクトリ名を変更した場合は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，パラメタwebserver.jsp.precompile.jsp_work_dirで変更したJSPワークディレクトリ名を指定する必要があります。簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(b)　出力先のディレクトリ構成

JSPコンパイル結果は，JSPワークディレクトリに出力されます。JSPコンパイル結果の出力先ディレクトリ構成を次の図に示します。なお，この図ではJSPワークディレクトリはデフォルトのディレクトリ名となっています。

図2-7　JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行している場合）

ディレクトリ構成について説明します。

タグファイルから生成されたクラスのパッケージ名は次の形式となります。

WEB-INF/tags下のタグファイルの場合

org.apache.jsp.tag.web.</WEB-INF/tagsディレクトリ下のパス>

WEB-INF/lib下のjarファイルに含まれるタグファイルの場合

org.apache.jsp.tag.meta.<jarファイル名をエンコードした文字列>.<jarファイル内のMETA-INF/tagsディレクトリ下のパス>

JSPファイルおよびタグファイルから生成されるクラスファイルの出力先ディレクトリのパス長は，OSの上限によって制限があります。OSの上限を超えるパス長になる場合は，JSPワークディレクトリ名を変更してください。

注意

複数のJ2EEサーバで同じJSPワークディレクトリを指定した場合，同じコンテキストルートのアプリケーションをデプロイしたとき，JSPワークディレクトリの状態が不正となるおそれがあります。

2.5.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果

JSP事前コンパイルを使用しない場合，JSPファイルのコンパイルは，JSPファイルへの初回アクセス時に実施されます。ここでは，JSP事前コンパイル機能を使用しない場合の，JSPコンパイル結果，およびコンパイル結果の出力先を変更する方法について説明します。

＜この項の構成＞

(1)　JSPコンパイル結果のライフサイクル

(2)　JSPファイルのコンパイル結果の保持

(3)　JSPコンパイル結果の出力先

(1)　JSPコンパイル結果のライフサイクル

JSP事前コンパイルを使用しない場合のJSPのコンパイル結果のライフサイクルについて説明します。

コンパイル結果の生成

JSP事前コンパイル機能で事前にJSPファイルのコンパイルを実施していない場合は，JSPコンパイル結果は次のどちらかのタイミングで生成されます。

JSPに最初にアクセスするとき

DD（web.xml）でJSPに対し<load-on-startup>が指定されている，Webアプリケーションを開始するとき

コンパイル結果の削除

JSPのコンパイル結果は，次のタイミングで削除されます。

J2EEアプリケーションのアンデプロイ時

J2EEサーバの起動時※

J2EEサーバの終了時※

注※

JSPコンパイル結果を保持しない設定にしている場合，削除されます。なお，J2EEサーバ起動時については，コンパイル結果の削除は，サーバが強制終了された場合に備えて実施されます。

(2)　JSPファイルのコンパイル結果の保持

JSP事前コンパイルをしない場合，Webコンテナでは，JSPのコンパイル結果である，Javaソースファイルおよびクラスファイルを，J2EEサーバの再起動時に保持するかどうか設定できます。

JSPファイルのコンパイル結果を保持するための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

注意

Webアプリケーションアンデプロイ時の注意

デフォルトでは，JSPのコンパイル結果を保持する設定になっています。また，JSPコンパイル結果を保持する設定をしていても，Webアプリケーションをアンデプロイすると，JSPのコンパイル結果は削除されます。このため，ユーザは，サーバの再起動時にJSPのコンパイル結果を削除する必要はありません。JSPコンパイル結果を保持する設定でWebコンテナを稼働したあと，JSPコンパイル結果が不要となった場合は，J2EEアプリケーションをアンデプロイしてください。

JSPのコンパイル結果は保持する設定にしておくことをお勧めします。

(3)　JSPコンパイル結果の出力先

JSP事前コンパイルを実施していない場合，JSPコンパイル結果はJSP用テンポラリディレクトリに出力されます。

出力されるファイルは次のとおりです。

JSPファイルから生成されたJavaソースファイル

1.のJavaソースファイルをコンパイルしたクラスファイル

タグファイルから生成されたJavaソースファイル

3.のJavaソースファイルをコンパイルしたクラスファイル

ここでは，デフォルトの出力先と，出力先のディレクトリ構成について説明します。

なお，出力されるクラス名については，「2.5.7　JSPコンパイル結果のクラス名」を参照してください。

(a)　デフォルトの出力先

JSP事前コンパイルを実行していない場合，JSPコンパイル結果は，JSP用テンポラリディレクトリ下に作成される，Webアプリケーション単位のディレクトリに出力されます。デフォルトのJSP用テンポラリディレクトリは次の場所になります。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥server¥repository¥<サーバ名称>¥web

UNIXの場合

/opt/Cosminexus/CC/server/repository/<サーバ名称>/web

なお，JSP用テンポラリディレクトリは，デフォルト値が設定されていますが，必要に応じて変更できます。JSP用テンポラリディレクトリの変更については，「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

JSP用テンポラリディレクトリ下にはWebアプリケーション単位でディレクトリが作成され，該当するWebアプリケーション内のJSPコンパイル結果が出力されます。

なお，Webアプリケーション単位のディレクトリは，コンテキストルート名を基にしたディレクトリ名となります。コンテキストルート名にスラント（/），ドル記号（$），パーセント（%），プラス記号（+）が含まれる場合は，次に示す文字に変換されます。

変換前の文字 | 変換後の文字
/ | $2f
$ | $24
% | $25
+ | $2b

例：

JSP用テンポラリディレクトリがデフォルト，コンテキストルート名が「J2EE_AP1/WEB_AP1_war」である場合，該当するWebアプリケーションのJSPコンパイル結果の出力先を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥repository¥<サーバ名称>¥web¥J2EE_AP1$2fWEB_AP1_war

UNIXの場合
/opt/Cosminexus/CC/server/repository/<サーバ名称>/web/J2EE_AP1$2fWEB_AP1_war

(b)　出力先のディレクトリ構成

JSPコンパイル結果の出力先ディレクトリ構成を次の図に示します。

図2-8　JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行していない場合）

ディレクトリ構成について説明します。

タグファイルから生成されたクラスのパッケージ名は次の形式となります。

WEB-INF/tags下のタグファイルの場合

org.apache.jsp.tag.web.</WEB-INF/tagsディレクトリ下のパス>

WEB-INF/lib下のjarファイルに含まれるタグファイルの場合

org.apache.jsp.tag.meta.<jarファイル名をエンコードした文字列>.<jarファイル内のMETA-INF/tagsディレクトリ下のパス>

JSPファイルおよびタグファイルから生成されるクラスファイルの出力先ディレクトリのパス長は，OSの上限によって制限があります。OSの上限を超えるパス長になる場合は，JSPワークディレクトリ名を変更してください。

2.5.7　JSPコンパイル結果のクラス名

ここでは，JSPファイルまたはタグファイルから生成されるクラス名の形式およびクラス名の変換規則について説明します。

＜この項の構成＞

(1)　クラス名の形式

(2)　クラス名の変換規則

(1)　クラス名の形式

JSPファイルまたはタグファイルから生成されるクラスのクラス名は，ファイルの種類，およびJSPデバッグ機能が有効かどうかで形式が異なります。クラス名の形式について，次の表に示します。

表2-14　JSPファイルまたはタグファイルから生成されるクラスのクラス名の形式

ファイルの種別 | JSPデバッグ機能が無効の場合 | JSPデバッグ機能が有効の場合
JSPファイル | ＜ファイル名＞ | ＜ファイル名＞_jsp
タグファイル | ＜ファイル名＞_ | ＜ファイル名＞_tag

＜ファイル名＞には「(2)　クラス名の変換規則」で示す規則が適用されます。

(2)　クラス名の変換規則

JSPファイルまたはタグファイルから生成されるクラスのクラス名に，クラス名として使用できない文字，アンダースコア（_），またはドル記号（$）が含まれる場合，次の変換規則が順に適用されます。

先頭の文字がパッケージ名，およびクラス名の先頭の文字として使用できない文字の場合は，先頭にドル記号（$）を付与する。

ファイル名の中のピリオド（.）はドル記号（$）に変換する。

クラス名として使用できない文字は，アンダースコア（_）と，使用できない文字を4けたの16進数表現の文字列に変換する。
16進数表現で使用される英字は小文字です。

1.の変更規則は先頭文字だけに適用されます。2.，および3.の変換規則は文字列の先頭から順に適用されます。

JSPファイルまたはタグファイルから生成されるクラスのクラス名の変換例を次の表に示します。

表2-15　JSPファイルまたはタグファイルから生成されるクラスのクラス名の変換例

ファイルの種別 | ファイル名 | JSPデバッグ機能 | クラス名
JSPファイル | index.jsp | － | index$jsp
○ | index$jsp_jsp
10test-10.jspx | － | $10test_002d10$jspx
○ | $10test_002d10$jspx_jsp
test.tag | － | test$tag
○ | test$tag_jsp
タグファイル | tagfile1.tag | － | tagfile1$tag_
○ | tagfile1$tag_tag
Tag_File$10.tagx | － | Tag_005fFile_002410$tagx_
○ | Tag_005fFile_002410$tagx_tag

（凡例）－：無効　○：有効

2.5.8　実行環境での設定（J2EEサーバの設定）

JSP事前コンパイル機能を使用する場合，またはコンパイル結果の保持をする場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。JSP事前コンパイル機能を使用する場合，またはコンパイル結果の保持をする場合の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのJSP事前コンパイル機能を使用する場合，またはコンパイル結果の保持をする場合の定義について次の表に示します。

表2-16　簡易構築定義ファイルでのJSP事前コンパイル機能を使用する場合，またはコンパイル結果の保持をする場合の定義

項目
指定するパラメタ
設定内容

JSP事前コンパイル
webserver.jsp.additional.import.list
JSP コンパイル時に暗黙にインポートしたいクラス名（完全修飾名のクラス名または，「パッケージ名.*」）を指定します。

webserver.jsp.keepgenerated
JSPファイルから生成したJavaソースファイルを保持しておくかどうかを指定します。

webserver.jsp.compile.backcompat
JavaソースファイルをコンパイルするときのJava言語仕様のバージョンを指定します。
なお，Webアプリケーションによって，JSPファイルから生成されたJavaソースファイルのバージョンが異なる場合は，Webアプリケーションごとにバージョンを指定してJSP事前コンパイルを実施してください。

webserver.jsp.precompile.jsp_work_dir
JSP事前コンパイルを実施する場合のコンパイル結果を出力するディレクトリを指定します。

webserver.xml.validate
Webアプリケーションに含まれるサーブレットのバージョンが2.3以前の場合に，JSP事前コンパイル実行時にTLDファイルの検証を実施するかどうかを指定します。
なお，このパラメタは，Webアプリケーションのバージョンが2.3以前のときに指定します。Webアプリケーションのバージョンが2.4以降のときはデフォルトで検証を実施するため，このパラメタへの指定はできません。

JSPファイルのコンパイル結果の保持
webserver.work.clean
コンパイル結果を保持するかどうかを指定します。

webserver.work.directory
コンパイル結果の出力先（JSP用テンポラリディレクトリ）を指定します。デフォルトの出力先を変更する場合に指定します※。デフォルトの出力先については，「2.5.6(3)　JSPコンパイル結果の出力先」を参照してください。なお，この出力先はJSP事前コンパイルを実施しない場合の出力先となります。

注※　JSP用テンポラリディレクトリの設定を変更する場合

JSPコンパイル結果を保持する設定でWebコンテナを稼働したあと，JSP用テンポラリディレクトリの設定を変更した場合，変更前のJSP用テンポラリディレクトリは削除されません。このため，手動で削除する必要があります。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

2.6　デフォルトの文字エンコーディング設定機能

この節では，デフォルトの文字エンコーディング設定機能について説明します。

アプリケーションサーバでは，Servlet仕様に準拠した文字エンコーディングおよびアプリケーションサーバ独自の文字エンコーディングが設定できます。

この節の構成を次の表に示します。

表2-17　この節の構成（デフォルトの文字エンコーディング設定機能）

分類 | タイトル | 参照先
解説 | デフォルトの文字エンコーディングの設定単位 | 2.6.1
デフォルトの文字エンコーディングの適用個所と適用条件 | 2.6.2
JSP事前コンパイル実行時の文字エンコーディングの適用 | 2.6.3
設定できる文字エンコーディング | 2.6.4
実装 | デフォルトの文字エンコーディングの実装（Servlet仕様の場合） | 2.6.5
DDでの定義 | 2.6.6
設定 | 実行環境での設定 | 2.6.7
注意事項 | デフォルトの文字エンコーディングの注意事項 | 2.6.8

注　「運用」について，この機能固有の説明はありません。

リクエストのデコードやレスポンスのエンコードで使用する文字エンコーディングは，Servlet仕様に準拠した設定をする場合，サーブレットやJSPファイルごとに設定を記述します。アプリケーションサーバでは，Servlet仕様に準拠した設定のほかに，次の二つの方法でデフォルトの文字エンコーディングを設定できます。

J2EEサーバごとに使用する文字エンコーディングを設定する

Webアプリケーションごとに使用する文字エンコーディングを設定する

これによって，Webアプリケーション開発時に，サーブレットやJSPファイルに記述する文字エンコーディングの設定を省略できます。また，J2EEサーバまたはWebアプリケーションごとに，容易に文字エンコーディングを統一できます。

省略できるServlet仕様での文字エンコーディング設定を，次の図に示します。

図2-9　省略できるServlet仕様での文字エンコーディングの設定

この節では，デフォルトの文字エンコーディング設定について説明します。

＜この節の構成＞

2.6.1　デフォルトの文字エンコーディングの設定単位

2.6.2　デフォルトの文字エンコーディングの適用個所と適用条件

2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用

2.6.4　設定できる文字エンコーディング

2.6.5　デフォルトの文字エンコーディングの実装（Servlet仕様の場合）

2.6.6　DDでの定義

2.6.7　実行環境での設定

2.6.8　デフォルトの文字エンコーディングの注意事項

2.6.1　デフォルトの文字エンコーディングの設定単位

アプリケーションサーバでは，リクエストのデコード，レスポンスのエンコード，およびJSPファイルで使用するデフォルトの文字エンコーディングを，J2EEサーバ単位，Webアプリケーション単位で設定できます。

ここでは，デフォルトの文字エンコーディングの設定について説明します。なお，デフォルトの文字エンコーディングは，JSP事前コンパイル実行時に適用することもできます。JSP事前コンパイル実行時のデフォルトの文字エンコーディング設定については，「2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

＜この項の構成＞

(1)　J2EEサーバ単位の設定

(2)　Webアプリケーション単位の設定

(3)　複数の範囲で文字エンコーディングを設定している場合の動作

(1)　J2EEサーバ単位の設定

J2EEサーバごとにデフォルトの文字エンコーディングを設定します。J2EEサーバごとにデフォルトの文字エンコーディングを設定すると，J2EEサーバにデプロイされているすべてのJ2EEアプリケーションのサーブレットおよびJSPファイルに対して，設定した文字エンコーディングを適用します。これによって，J2EEサーバ単位で，文字エンコーディングを統一できます。

J2EEサーバ単位の場合，デフォルトの文字エンコーディングは，J2EEサーバの動作設定をカスタマイズする際に設定します。設定の詳細については，「2.6.7　実行環境での設定」を参照してください。

(2)　Webアプリケーション単位の設定

WARファイルごとに，デフォルトの文字エンコーディングを設定します。WARファイルごとにデフォルトの文字エンコーディングを設定すると，WARファイルに含まれるサーブレットおよびJSPファイルに対して，設定した文字エンコーディングを適用します。これによって，Webアプリケーション単位で，文字エンコーディングを統一できます。

Webアプリケーション単位での設定の場合，デフォルトの文字エンコーディングは，J2EEアプリケーションのプロパティを定義する際に設定します。設定の詳細については，「2.6.7　実行環境での設定」を参照してください。

(3)　複数の範囲で文字エンコーディングを設定している場合の動作

文字エンコーディングの設定は，J2EEサーバ単位またはWebアプリケーション単位での設定のほかに，Servlet仕様での文字エンコーディングの設定もできます。Servlet仕様での文字エンコーディング設定の場合，設定範囲は，サーブレットまたはJSPファイル単位になります。

それぞれの設定範囲を次の図に示します。

図2-10　文字エンコーディングの設定範囲

デフォルトの文字エンコーディングは複数範囲で設定することもできます。複数の範囲で設定されている場合，次の順序で適用されます。

サーブレット/JSPファイル単位での設定（Servlet仕様）

Webアプリケーション単位での設定

J2EEサーバ単位での設定

例えば，図2-10で，サーブレット2とJ2EEサーバに文字エンコーディングが設定されているとします。この場合，J2EEサーバ内のアプリケーション全体に，J2EEサーバ単位で設定したデフォルトの文字エンコーディングが適用されますが，サーブレット2だけは，サーブレット内に設定した文字エンコーディングが適用されます。

次の表に，文字エンコーディング設定の組み合わせごとに，有効になる設定を示します。

表2-18　文字エンコーディング設定の組み合わせと有効になる設定

設定の組み合わせ | 有効になる設定
サーブレット/JSPファイルでの設定（Servlet仕様）※ | Webアプリケーション単位での設定 | J2EEサーバ単位での設定
○ | × | × | サーブレット/JSPファイルでの設定
○ | ○ | ×
○ | × | ○
○ | ○ | ○
× | ○ | × | Webアプリケーション単位での設定
× | ○ | ○
× | × | ○ | J2EEサーバ単位での設定
× | × | × | Servlet仕様で規定されている文字エンコーディング

（凡例）○：設定あり　×：設定なし

注

文字エンコーディングの設定がない場合は，Servlet仕様で規定されている文字エンコーディングが適用されます。詳細については，「2.6.5(2)　Servlet仕様で規定されている文字エンコーディング」を参照してください。

注※

XMLシンタックスのJSPファイルまたはタグファイルでは，XML宣言でencoding属性を指定していない場合はデフォルトエンコーディング設定機能が有効となります。

2.6.2　デフォルトの文字エンコーディングの適用個所と適用条件

ここでは，J2EEサーバ単位，またはWebアプリケーション単位で設定したデフォルトの文字エンコーディングの適用個所と，適用時の条件について説明します。

＜この項の構成＞

(1)　適用個所

(2)　適用条件

(1)　適用個所

J2EEサーバ単位またはWebアプリケーション単位に設定したデフォルトの文字エンコーディングは，次の個所に適用されます。

リクエストのデコード
リクエストボディおよびクエリのデコードに使用する，デフォルトの文字エンコーディングに適用されます。

レスポンスのエンコード
レスポンスボディおよびレスポンスのContent-Typeヘッダのエンコードに使用する，デフォルトの文字エンコーディングに適用されます。

JSPファイル
JSPファイルのデフォルトの文字エンコーディングに適用されます。

(2)　適用条件

デフォルトの文字エンコーディングは，Servlet仕様での文字エンコーディングが設定されていない場合に適用されます。Servlet仕様での文字エンコーディングの設定方法については，「2.6.5　デフォルトの文字エンコーディングの実装（Servlet仕様の場合）」を参照してください。

また，リクエストのデコードおよびレスポンスのエンコードで使用する文字エンコーディングについては，さらに次に示す適用条件があります。

(a)　リクエストでの適用条件

リクエストのデコードで使用する文字エンコーディングの場合，次に示す適用条件があります。

クライアントから送信されたリクエストのHTTPリクエストヘッダに，charsetパラメタを含む，Content-Typeヘッダが含まれていない。

さらに，リクエストボディおよびクエリには，次に示す適用条件があります。

●リクエストボディ

サーブレットの場合

リクエストのPOSTデータを，次のどちらかの方法で読み込んでいる場合に適用されます。

javax.servlet.ServletRequestのgetReaderメソッドを使用して取得したBufferedReaderで読み込む。

リクエストのパラメタとして読み込む。

リクエストのパラメタとして読み込む場合，javax.servlet.ServletRequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用します。

JSPファイルの場合

リクエストのPOSTデータを，次のどちらかの方法で読み込んでいる場合に適用されます。

暗黙オブジェクトrequestのgetReaderメソッドを使用して取得したBufferedReaderで読み込む。

リクエストのパラメタとして読み込む。

リクエストのパラメタとして読み込む場合，暗黙オブジェクトrequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用，またはExpression Languageで暗黙オブジェクトparam，paramValuesを使用します。

●クエリ

サーブレットの場合

javax.servlet.ServletRequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用する方法で，クエリをリクエストのパラメタとして読み込んでいる場合に，適用されます。

JSPファイルの場合

次のどちらかの方法で，クエリをリクエストのパラメタとして読み込んでいる場合に適用されます。

暗黙オブジェクトrequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用して読み込む。

Expression Languageで暗黙オブジェクトparam，paramValuesを使用して読み込む。

(b)　レスポンスでの適用条件

レスポンスのエンコードで使用する文字エンコーディングの適用条件を，レスポンスボディとレスポンスのContent-Typeヘッダの文字エンコーディング名に分けて説明します。

●レスポンスボディ

サーブレットの場合

javax.servlet.ServletResponseのgetWriterメソッドで取得したPrintWriterでレスポンスデータを作成している場合に適用されます。

JSPファイルの場合

暗黙オブジェクトresponseのgetOutputStream()メソッドによってServletOutputStreamオブジェクトを取得しないで，レスポンスを出力している場合に適用されます。※

注※

ServletOutputStreamオブジェクトを取得した場合，JSP本文のテキストや，暗黙オブジェクトoutへの出力などのServletOutputStreamオブジェクトを使用しない出力は，すべて実行時にエラーとなります。このため，レスポンスとして出力することはできません。

●レスポンスのContent-Typeヘッダの文字エンコーディング名

サーブレットの場合

レスポンスのコンテンツ形式に「text/」で始まるMIMEタイプを設定し，charsetは設定していない場合に適用されます。

JSPファイルの場合

次のどちらかの場合に適用されます。

レスポンスのコンテンツ形式を設定していない。

「text/」で始まるMIMEタイプを設定し，charsetは設定していない。

静的コンテンツの場合

次の条件を満たした場合に適用されます。

静的コンテンツの拡張子が，デフォルトエンコーディング設定機能の対象として設定された拡張子である。

拡張子が「text/」で始まるMIMEタイプに設定されている。

静的コンテンツを出力するより前に，サーブレット，JSP，フィルタなどでレスポンスに対して文字エンコーディングを設定しない。

参考

コンテンツ形式とは，コンテンツのMIMEタイプを指します。コンテンツ形式には，文字エンコーディングを含めることができます。次に，サーブレットおよびJSPファイルでのコンテンツ形式の設定例を示します。

サーブレットの場合
javax.servlet.ServletResponseのsetContentTypeメソッドを使用します。
設定例：response.setContentType("text/html");

JSPファイルの場合
PageディレクティブのcontentType属性を設定します。
設定例：<%@ page contentType="text/plain" %>

また，デフォルトの文字エンコーディング設定が適用されるMIMEタイプの例と，適用されないMIMEタイプの例を示します。

適用されるMIMEタイプの例：「text/plain」，「text/html」

適用されないMIMEタイプの例：「image/gif」，「text/html;charset=UTF-8」

2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用

JSPファイルのデフォルトの文字エンコーディングについては，JSP事前コンパイル実行時に適用することもできます。JSP事前コンパイル時に適用させる場合，デフォルトの文字エンコーディング設定は，JSP事前コンパイルの方法によって異なります。JSP事前コンパイルの方法には，次の2種類があります。

アプリケーション開発時に実施するJSP事前コンパイル

J2EEアプリケーション開始時に実施するJSP事前コンパイル

JSP事前コンパイルの種類ごとに，デフォルトの文字エンコーディング設定について説明します。JSP事前コンパイル機能の詳細については，「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

なお，設定できる文字エンコーディングについては，「2.6.4　設定できる文字エンコーディング」を，設定したデフォルトの文字エンコーディングの適用個所および適用条件については，「2.6.2　デフォルトの文字エンコーディングの適用個所と適用条件」を参照してください。

＜この項の構成＞

(1)　アプリケーション開発時に実施するJSP事前コンパイル（cjjspcコマンド）

(2)　J2EEアプリケーション開始時に実施するJSP事前コンパイル（cjstartappコマンド）

(1)　アプリケーション開発時に実施するJSP事前コンパイル（cjjspcコマンド）

cjjspcコマンドでJSP事前コンパイルを実施する際，JSPファイルまたはタグファイルに，デフォルトの文字エンコーディングを適用できます。cjjspcコマンドの場合，デフォルトの文字エンコーディングは，cjjspcコマンドの引数に指定します。これによって，cjjspcコマンド実行時に，実行対象となるJSPファイルに対して，コマンドに指定したデフォルトの文字エンコーディングが適用されます。ただし，JSPファイルやタグファイルにServlet仕様での文字エンコーディング指定がある場合は，設定は適用されないので注意してください。

設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

注意

cjjspcコマンドの場合，リクエストのデコードおよびレスポンスのエンコードに使用するデフォルトの文字エンコーディングは，JSPファイルのコンパイル時に適用されないため，cjjspcコマンドでは設定できません。

(2)　J2EEアプリケーション開始時に実施するJSP事前コンパイル（cjstartappコマンド）

cjstartappコマンドでJ2EEアプリケーション開始とあわせてJSP事前コンパイルを実施する際，JSPファイルまたはタグファイルに，デフォルトの文字エンコーディングを適用できます。デフォルトの文字エンコーディングの設定方法は，J2EEサーバ単位，Webアプリケーション単位の場合と同様です。J2EEサーバ単位の場合は，J2EEサーバの動作設定時にJ2EEサーバごとに設定します。また，Webアプリケーション単位の場合は，Webアプリケーション開発時にWARファイルごとに設定します。cjstartappコマンドを実行すると，設定したデフォルトの文字エンコーディングが適用されます。

J2EEサーバ単位の設定およびWebアプリケーション単位での設定については，「2.6.1　デフォルトの文字エンコーディングの設定単位」を参照してください。また，設定の詳細については，「2.6.7　実行環境での設定」を参照してください。

2.6.4　設定できる文字エンコーディング

デフォルトの文字エンコーディングとして設定できる文字は，JavaVMがサポートしている文字エンコーディングとなります。JavaVMがサポートしている文字エンコーディングについては，JDKのドキュメントのサポートされているエンコーディングに関する説明を参照してください。

また，指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名になります。

注意

J2EEアプリケーションの開発環境と運用環境のOSが異なる場合で，J2EEアプリケーションを，実行時情報を含むEARファイルでエクスポートおよびインポートするときは，開発環境のOSと運用環境のOSの両方でサポートしている文字エンコーディングを設定してください。開発環境で設定した文字エンコーディングが運用環境でサポートされていない場合は，アプリケーション開始時に例外が発生することがあります。

また，設定したデフォルトの文字エンコーディングは，JavaVMでサポートしている文字エンコーディングかどうか検証されます。検証のタイミングは，デフォルトの文字エンコーディングの設定方法によって異なります。文字エンコーディングの検証のタイミングについて，次の表に示します。

表2-19　文字エンコーディングの検証のタイミング

検証のタイミング | サポートされていない文字エンコーディングが設定されていた場合の動作
J2EEサーバ開始時 | 警告メッセージを出力し，J2EEサーバ開始処理を続行します。なお，設定した文字エンコーディングは無視されます。
サーバ管理コマンド（cjsetappprop）実行時 | エラーメッセージを出力し，サーバ管理コマンドの処理を中止します。
cjjspcコマンド実行時※ | エラーメッセージを出力し，コマンドの処理を終了します。

注※

cjjspcコマンドでのJSP事前コンパイル実行時に，デフォルトの文字エンコーディング設定をするときの検証のタイミングです。なお，JSP事前コンパイルでのデフォルトの文字エンコーディングの適用については，「2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

2.6.5　デフォルトの文字エンコーディングの実装（Servlet仕様の場合）

Servlet仕様で規定された文字エンコーディングの設定がある個所で，アプリケーションサーバで設定したデフォルトの文字エンコーディングは無効となります。

ここでは，Servlet仕様で規定された文字エンコーディングの設定について説明します。なお，文字エンコーディングの設定は，Servlet仕様のバージョンによって異なります。

＜この項の構成＞

(1)　Servlet仕様での文字エンコーディングの設定方法

(2)　Servlet仕様で規定されている文字エンコーディング

(1)　Servlet仕様での文字エンコーディングの設定方法

Servlet仕様での文字エンコーディングの設定方法について，Servlet/JSPのバージョンごとに表に示します。

表2-20　Servlet仕様での文字エンコーディングの設定方法（Servlet 2.5/JSP 2.1）

設定内容
設定場所
Servlet仕様での設定方法

リクエストの文字エンコーディング
サーブレット
ServletRequest.setCharacterEncoding(java.lang.String env)※1

JSPファイル
なし

レスポンスの文字エンコーディング
サーブレット

ServletResponse.setCharacterEncoding(java.lang.String charset)※1

ServletResponse.setContentType(java.lang.String type)※1

ServletResponse.setLocale(java.util.Locale loc)※1

JSPファイル

PageディレクティブのcontentType属性値(charsetを含む)※2

PageディレクティブのpageEncoding属性※3

web.xmlのpage-encoding要素※2

JSPファイルの文字エンコーディング
JSPファイル

BOM※3

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブまたはTagディレクティブのpageEncoding属性※3

web.xmlのpage-encoding要素※2

XML宣言のencoding属性※4

注※1　パッケージはjavax.servletです。

注※2　JSPページに設定する方法です。

注※3　JSPページまたは標準形式のタグファイルに設定する方法です。

注※4　JSPドキュメントまたはXML形式のタグファイルに設定する方法です。

表2-21　Servlet仕様での文字エンコーディングの設定方法（Servlet 2.4/JSP 2.0）

設定内容
設定場所
Servlet仕様での設定方法

リクエストの文字エンコーディング
サーブレット
ServletRequest.setCharacterEncoding(java.lang.String env)※1

JSPファイル
なし

レスポンスの文字エンコーディング
サーブレット

ServletResponse.setCharacterEncoding(java.lang.String charset)※1

ServletResponse.setContentType(java.lang.String type)※1

ServletResponse.setLocale(java.util.Locale loc)※1

JSPファイル

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブのpageEncoding属性※3

web.xmlのpage-encoding要素※2

JSPファイルの文字エンコーディング
JSPファイル

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブまたはTagディレクティブのpageEncoding属性※3

web.xmlのpage-encoding要素※2

XML宣言のencoding属性※4

注※1　パッケージはjavax.servletです。

注※2　JSPページに設定する方法です。

注※3　JSPページまたは標準形式のタグファイルに設定する方法です。

注※4　JSPドキュメントまたはXML形式のタグファイルに設定する方法です。

表2-22　Servlet仕様での文字エンコーディングの設定方法（Servlet 2.3/JSP 1.2）

設定内容
設定場所
Servlet仕様での設定方法

リクエストの文字エンコーディング
サーブレット
ServletRequest.setCharacterEncoding(java.lang.String env)
※1

JSPファイル
なし

レスポンスの文字エンコーディング
サーブレット

ServletResponse.setContentType(java.lang.String type)※1

ServletResponse.setLocale(java.util.Locale loc)※1

JSPファイル
PageディレクティブのcontentType属性値（charsetを含む）

JSPファイルの文字エンコーディング
JSPファイル

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブのpageEncoding属性※2

注※1　パッケージはjavax.servletです。

注※2　JSPページまたはJSPドキュメントに設定する方法です。

(2)　Servlet仕様で規定されている文字エンコーディング

Servlet仕様での文字エンコーディング設定，およびアプリケーションサーバでのデフォルトの文字エンコーディングの設定がない場合は，Servlet仕様で規定されている文字エンコーディングが適用されます。

文字エンコーディングを設定していない場合に適用される，Servlet仕様で規定された文字エンコーディングを次に示します。

リクエストの場合
ISO-8859-1が適用されます。なお，サーブレットおよびJSPファイルでは，Servlet APIを使用して設定されます。

レスポンスの場合
Servlet仕様で規定された文字エンコーディングを，Servletのバージョンごとに次の表に示します。

表2-23　Servlet仕様で規定された文字エンコーディング（レスポンス）

Servletのバージョン | 種類 | 適用される文字エンコーディング
Servlet 2.3 | サーブレット | ISO-8859-1
JSPページ
JSPドキュメント
Servlet 2.4，Servlet 2.5 | サーブレット | ISO-8859-1
JSPページ
JSPドキュメント | UTF-8

JSPファイルの場合
Servlet仕様で規定された文字エンコーディングを，Servletのバージョンごとに次の表に示します。

表2-24　Servlet仕様で規定された文字エンコーディング（JSPファイル）

Servletのバージョン | JSPのバージョン | 種類 | 適用される文字エンコーディング
Servlet 2.3 | JSP 1.2 | JSPページ | ISO-8859-1
JSPドキュメント
Servlet 2.4，Servlet 2.5 | JSP 2.0，2.1 | JSPページ | ISO-8859-1
標準形式のタグファイル
JSPドキュメント | UTF-8
XML形式のタグファイル

2.6.6　DDでの定義

デフォルトの文字エンコーディングのWebアプリケーション単位の定義は，web.xmlに指定します。

DDでのデフォルトの文字エンコーディングの定義について次の表に示します。

表2-25　DDでのデフォルトの文字エンコーディングの定義

指定するタグ | 設定内容
<http-request>－<encoding>タグ | リクエストボディおよびクエリのデコードに使用する，文字エンコーディングを設定します。
<http-response>－<encoding>タグ | レスポンスボディのエンコードに使用する，文字エンコーディングを設定します。
<jsp>－<page-encoding>タグ | JSPファイルの文字エンコーディングを設定します。

注　Webアプリケーション内のサーブレットまたはJSPファイルに，Servlet仕様での文字エンコーディング設定がある場合は，Servlet仕様での設定が有効になります。設定の優先順位については，「2.6.1(3)　複数の範囲で文字エンコーディングを設定している場合の動作」を参照してください。

2.6.7　実行環境での設定

デフォルトの文字エンコーディングを設定する場合，J2EEサーバおよびWebアプリケーションの設定が必要です。

なお，Webアプリケーションの設定は，cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

＜この項の構成＞

(1)　J2EEサーバの設定

(2)　Webアプリケーションの設定

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。デフォルトの文字エンコーディングの定義の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのデフォルトの文字エンコーディングの定義の定義について次の表に示します。

表2-26　簡易構築定義ファイルでのデフォルトの文字エンコーディングの定義義

指定するパラメタ | 設定内容
webserver.http.request.encoding | リクエストボディおよびクエリのデコードに使用する文字エンコーディングを指定します。
webserver.http.response.encoding | レスポンスボディのエンコードに使用する文字エンコーディングを指定します。
webserver.jsp.pageEncoding | JSPファイルのエンコーディングを指定します。
webserver.static_content.encoding.extension | デフォルトのレスポンス文字エンコーディングを適用する静的コンテンツの拡張子を指定します。

注　J2EEサーバ単位の設定とあわせて，Webアプリケーション単位での文字エンコーディング設定がある場合は，Webアプリケーション単位での設定が有効になります。設定の優先順位については，「2.6.1(3)　複数の範囲で文字エンコーディングを設定している場合の動作」を参照してください。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　Webアプリケーションの設定

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。デフォルトの文字エンコーディングの定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「2.6.6　DDでの定義」を参照してください。

2.6.8　デフォルトの文字エンコーディングの注意事項

デフォルトの文字エンコーディングの適用については，次の点に注意してください。

＜この項の構成＞

(1)　レスポンスへのデフォルトの文字エンコーディングの設定の可否について

(2)　getCharacterEncodingメソッドに適用される文字エンコーディング

(3)　XML宣言内の文字エンコーディング

(4)　JSPファイルへの文字エンコーディングの適用

(5)　07-00でJSP事前コンパイルを実行したWebアプリケーションへの文字エンコーディング設定

(6)　デフォルトエラーページの文字エンコーディングについて

(1)　レスポンスへのデフォルトの文字エンコーディングの設定の可否について

次の場合は，レスポンスへのデフォルトの文字エンコーディングの設定は有効になりません。

静的コンテンツの拡張子が，webserver.static_content.encoding.extensionパラメタ※1に指定した拡張子以外の場合

Servlet仕様で規定されたエラーページの静的コンテンツに対して，レスポンスへのデフォルトの文字エンコーディングを設定しない場合※2

注※1　デフォルトの文字エンコーディングを適用させる静的コンテンツの拡張子を指定するためのパラメタです。

注※2　次のどちらかの条件のあとに出力された静的コンテンツの場合は，レスポンスへのデフォルトの文字エンコーディングの設定が有効になります。

レスポンスに対して文字エンコーディングを設定しない場合で，サーブレット，JSP，フィルタなどで，javax.servlet.ServletResponseクラスのgetWriterメソッドによってjava.io.PrintWriterオブジェクトが取得されるとき。

setAttributeメソッドが実行されても，リクエストオブジェクトがラップされる場合で，そのリクエストオブジェクトが，setAttributeメソッドを呼び出さないリクエストラッパでラップされるとき。

なお，HTTPレスポンス圧縮フィルタを使用している場合は，レスポンスへのデフォルトの文字エンコーディングの設定は有効になりません。

(2)　getCharacterEncodingメソッドに適用される文字エンコーディング

Servlet仕様で文字エンコーディングを設定していない場合，次に示すServlet APIのメソッドには，J2EEサーバ単位またはWebアプリケーション単位で設定したデフォルトの文字エンコーディングが適用されます。

javax.servlet.ServletRequestのgetCharacterEncodingメソッド（リクエストの場合）

javax.servlet.ServletResponseのgetCharacterEncodingメソッド（レスポンスの場合）

ただし，setCharacterEncodingメソッドで文字エンコーディングを変更しているときは，setCharacterEncodingメソッドで変更した文字エンコーディングが取得されます。

また，レスポンスの場合，javax.servlet.ServletResponseのresetメソッドを使用してレスポンスデータを初期化したときは，getCharacterEncodingメソッドで取得できる文字エンコーディングは，アプリケーションサーバで設定した文字エンコーディングとなります。

なお，Servlet仕様での文字エンコーディングの設定方法については，「2.6.5　デフォルトの文字エンコーディングの実装（Servlet仕様の場合）」を参照してください。

(3)　XML宣言内の文字エンコーディング

JSPドキュメントおよびXML形式のタグファイルで，WebコンテナがXML宣言を自動生成する場合，XML宣言内の文字エンコーディングの宣言には，レスポンスボディのエンコードに適用されたデフォルトの文字エンコーディングが出力されます。

(4)　JSPファイルへの文字エンコーディングの適用

JSPファイルへの文字エンコーディング設定は，JSPファイルのコンパイル時に適用されます。このため，すでにJSPファイルがコンパイルされている状態で，文字エンコーディングの設定を追加または変更しても，追加または変更した文字エンコーディングはJSPファイルに反映されません。設定を反映させるためには，再度，コンパイルを実施してください。

(5)　07-00でJSP事前コンパイルを実行したWebアプリケーションへの文字エンコーディング設定

07-00でJSP事前コンパイルを実行したWebアプリケーションに対して，レスポンスへのデフォルトの文字エンコーディングを設定する場合は，再度，JSP事前コンパイルを実施してください。

デフォルトの文字エンコーディングの設定単位ごとに説明します。

J2EEサーバ単位での設定の場合
J2EEサーバ上で動作するすべてのWebアプリケーションのJSPファイルに対して，JSP事前コンパイルを実施します。

Webアプリケーション単位での設定の場合
Webアプリケーションに含まれるJSPファイルに対して，JSP事前コンパイルを実施します。

なお，JSP事前コンパイル実行時でのデフォルトの文字エンコーディング設定については，「2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

(6)　デフォルトエラーページの文字エンコーディングについて

デフォルトエラーページの文字エンコーディングはUTF-8に設定されているため，デフォルトエンコーディングは適用されません。

2.7　セッション管理機能

この節では，セッション管理機能について説明します。

セッション管理は，リクエストとWebクライアントを対応づけるための機能です。この機能を使用すると，Webクライアントから，複数のWebページにわたって同じ情報を引き継いだ作業ができるようになります。

この節の構成を次の表に示します。

表2-27　この節の構成（セッション管理機能）

分類 | タイトル | 参照先
解説 | セッション情報を管理するオブジェクト | 2.7.1
セッションIDの形式 | 2.7.2
セッションの管理方法 | 2.7.3
Webクライアントが保持する無効なセッションIDの削除 | 2.7.4
HttpSessionオブジェクト数の上限値の設定 | 2.7.5
セッションIDおよびCookieへのサーバIDの付加 | 2.7.6
実装 | cosminexus.xmlでの定義 | 2.7.7
設定 | 実行環境での設定 | 2.7.8
注意事項 | セッション管理の注意事項 | 2.7.9

注　「運用」について，この機能固有の説明はありません。

セッション管理機能は，次に示す場合にも利用されます。

クラスタリングによる負荷分散機能を使用するときのクライアントの識別

セキュリティ管理機能でのログイン済みクライアントの識別

セッション管理の方式として，Servlet仕様では，Cookieを使用する方法とURL書き換えを使用する方法が明記されています。アプリケーションサーバのWebコンテナでも，これらの方式によってセッションを管理します。ただし，Servlet仕様では，具体的な管理方式を明記していない部分があります。このため，この節では，Servlet仕様で明記されていないセッションの管理方式について，アプリケーションサーバでどのように管理するかを説明します。

また，アプリケーションサーバの独自の機能である，次の3種類のセッション管理機能についても，この節で説明します。

Webクライアントが保持する無効なセッションIDの削除

HttpSessionオブジェクトの上限値の設定

セッションIDおよびCookieへのサーバIDの付加

ポイント

Webクライアントが保持する無効なセッションIDの削除，HttpSessionオブジェクトの上限値の設定，およびセッションIDへのサーバIDの付加は，アプリケーションサーバのセッションフェイルオーバ機能を使用する場合に前提になる機能です。セッションフェイルオーバ機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

＜この節の構成＞

2.7.1　セッション情報を管理するオブジェクト

2.7.2　セッションIDの形式

2.7.3　セッションの管理方法

2.7.4　Webクライアントが保持する無効なセッションIDの削除

2.7.5　HttpSessionオブジェクト数の上限値の設定

2.7.6　セッションIDおよびCookieへのサーバIDの付加

2.7.7　cosminexus.xmlでの定義

2.7.8　実行環境での設定

2.7.9　セッション管理の注意事項

2.7.1　セッション情報を管理するオブジェクト

ここでは，セッション情報の管理に使用するHttpSessionオブジェクトについて説明します。

＜この項の構成＞

(1)　HttpSessionオブジェクトの管理方法

(2)　HttpSessionオブジェクトの保存期間

(1)　HttpSessionオブジェクトの管理方法

セッション情報は，Servlet APIで規定されているHttpSessionオブジェクトによって管理される情報です。

セッション情報の管理が開始されるのは，次の時点です。

サーブレットの場合は，HttpSessionオブジェクトを参照した時点。

JSPの場合は，ページへの参照が発生した時点（ただし，これはデフォルトの場合です）。

セッション情報の管理が開始されたあとで，同一のWebアプリケーション内のサーブレットに対して，同じブラウザプロセスからリクエストが送信されると，管理されている内容のHttpSessionオブジェクトがサーブレットに渡されるようになります。

ただし，実際にサーブレットに渡されるHttpSessionオブジェクトのインスタンスは，リクエスト単位に異なります。つまり，同一セッションに属する一連のリクエストでは，内容が同じでインスタンスが異なるHttpSessionオブジェクトが渡される場合があります。

このため，HttpSessionオブジェクトに対する操作では，次の点に留意してください。

HttpSessionオブジェクトにアクセスする場合，リクエスト単位にインスタンスを取得する必要があります。

HttpSessionオブジェクトへの参照を，複数のリクエストにわたってキャッシングしないでください。

HttpSessionオブジェクトに対して，javaのsynchronizedキーワードでロックを掛けても意味はありませんので，ロックは掛けないでください。

(2)　HttpSessionオブジェクトの保存期間

HttpSessionオブジェクトは単一のJavaVM内にだけ保存されています。このため，サーブレットエンジンとして動作しているJavaVMプロセス（J2EEサーバ）に障害が発生した場合には，HttpSessionオブジェクトが保持しているセッション情報は失われます。

また，セッション情報は，正常・異常に関係なくJ2EEサーバが終了すると失われます。

J2EEサーバが終了したあとにもセッション情報を保持しておきたい場合は，アプリケーションサーバの機能であるセッションフェイルオーバ機能を使用してください。セッションフェイルオーバ機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

2.7.2　セッションIDの形式

ここでは，セッション情報の識別に使用するセッションIDの形式について説明します。HttpSessionオブジェクトは，セッションIDによって識別されます。

セッションIDの形式は，次の機能を使用しているかどうかで異なります。

リダイレクタによる負荷分散機能

セッションIDへのサーバIDの付加機能

セッションIDは，J2EEサーバ内で一意であることが保証されています。ただし，複数のJ2EEサーバにわたって一意の値にする必要がある場合には，セッションIDにワーカ名またはサーバIDを追加して，複数のJ2EEサーバにわたって一意になるように設定する必要があります。

使用している機能ごとのセッションIDの形式を，次の図に示します。

図2-11　セッションIDの形式

それぞれの場合について説明します。

リダイレクタによる負荷分散機能とサーバID付加機能のどちらも使用していない場合
セッションIDは，32文字の英数字になります。この英数字は，一つのJ2EEサーバ内で一意な値になります。

リダイレクタによる負荷分散機能を使用している場合
セッションIDは，32文字の英数字，「.」（ピリオド），およびワーカ名で構成されます。ワーカ名には，サーバごとに一意の名称を設定しておく必要があります。
リダイレクタによる負荷分散機能については，「3.2　Webサーバ（リダイレクタ）によるリクエストの振り分け」のロードバランサを使用する場合の説明を参照してください。

サーバID付加機能を使用している場合（リダイレクタによる負荷分散機能を使用していないとき）
セッションIDは，32文字の英数字およびサーバIDで構成されます。サーバIDには，サーバごとに一意の値を設定しておく必要があります。
サーバID付加機能については，「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。
なお，リダイレクタによる負荷分散機能を使用している場合，サーバIDは付加されません。

2.7.3　セッションの管理方法

Webコンテナでのセッションの管理方法には，HTTP Cookieを使用する方法と，URL書き換えを使用する方法の2種類があります。

Webコンテナは，セッションがどの方法で管理されているかを，セッションIDが何から取得できたかによって判別します。HTTP CookieからセッションIDを取得した場合は，HTTP Cookieによってセッションを管理していると判別します。URLのパスパラメタから取得できた場合は，URL書き換えによってセッションを管理していると判別します。これらの判別は，リクエストごとに実行されます。

ここでは，セッションの管理方法ごとのセッションIDの管理のされ方について説明します。

＜この項の構成＞

(1)　セッションの管理にHTTP Cookieを使用する場合

(2)　セッションの管理にURL書き換えを使用する場合

(1)　セッションの管理にHTTP Cookieを使用する場合

セッションIDは，HTTP Cookieとして管理されます。

HTTPセッションを新規に作成した場合に，HTTPレスポンスのヘッダにセッションIDを示すHTTP Cookieが付加されます。セッションIDを示すHTTP Cookieの名称は，「JSESSIONID」です。この名称は，Servlet仕様で決められているため，変更できません。なお，作成したHTTPセッションをコミットする前に無効化した場合，HTTP Cookieは付加されません。

(2)　セッションの管理にURL書き換えを使用する場合

セッションIDは，URLのパスパラメタとして管理されます。

セッションIDを示すURLのパスパラメタの名称は，「jsessionid」です。この名称は，Servlet仕様で決められているため，変更できません。セッションIDは，WebコンテナによってURLが書き換えられるときに，URLのパスの最後に，「;jsessionid=セッションID」の形式で付加されます。

URLのパスは，階層構造を持っている，リソースを識別するための値です。URLのパスには，クエリやフラグメントは含まれません。このため，これらの要素がURLに含まれている場合，セッションIDは，クエリまたはフラグメントの直前に付加されます。また，URLにセッションID以外のパスパラメタが含まれている場合，セッションIDを示すパスパラメタは，URLに含まれるパスパラメタの最後に付加されます。

ポイント

セッションIDをURLのパスパラメタに追加する場合，URLの文字数が増加します。

増加する文字数を次の表に示します。

表2-28　URL書き換えによって増加するURLの文字数

機能の使用状況 | 増加するURLの文字数（単位：文字数）
リダイレクタによる負荷分散機能またはサーバID付加機能を使用していない場合 | 44※
リダイレクタによる負荷分散機能を使用している場合 | 44※ + 1（ピリオドの文字数）+ワーカ名の文字数
サーバID付加機能を使用している場合（リダイレクタによる負荷分散機能を使用していないとき） | 44※ + サーバIDの文字数

注※

「;jsessionid=」の12文字とセッションIDの32文字の合計です。

2.7.4　Webクライアントが保持する無効なセッションIDの削除

アプリケーションサーバでは，Webクライアントが保持する無効なセッションIDを削除します。これによって，無効なセッションIDのWebクライアントからの送信を抑止します。

HTTPセッションを無効化した場合，または無効なセッションIDを含むHTTPセッションを受信した場合，Webコンテナによって，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP CookieがHTTPレスポンスのヘッダに付加されます。これによって，無効なセッションIDが削除されます。

無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP Cookieとは，次のすべての条件を満たすHTTP Cookieを指します。

セッションIDを示すHTTP Cookieであり，名称は「JSESSIONID」である。

値が「""」（空文字列）である。

HTTP Cookieの有効期限に，経過した期限となる正の数が設定されている。

HTTPレスポンスのヘッダに，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP Cookieが付加されるのは，次の二つの場合です。

HTTPセッションが無効化された。

J2EEサーバに存在しないセッションIDを受信した。

以降でそれぞれの場合について説明します。

Webサーバ連携機能を使用する場合の注意事項

レスポンスのステータスコードが304（Not Modified）である場合に，Webサーバの仕様でSet-Cookieヘッダが削除されるときがあります。このとき，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP Cookieも付加されなくなるため，Webクライアントが保持する無効なセッションIDの削除ができなくなります。

＜この項の構成＞

(1)　HTTPセッションが無効化された場合

(2)　J2EEサーバに存在しないセッションIDを受信した場合

(3)　Webクライアントが保持する無効なセッションIDの削除をする場合の注意事項

(1)　HTTPセッションが無効化された場合

次の条件をすべて満たす場合，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP CookieがHTTPレスポンスのヘッダに付加されます。

セッションIDがHTTP Cookieを使用して通知された。

Webアプリケーション内でHTTPレスポンスがコミットされる前にHTTPセッションが無効化された※1。

HTTPレスポンスのコミット時にHTTPセッションが存在しない※2。

注※1

HTTPレスポンスのヘッダは，レスポンスがコミットされた時点でWebクライアントに送信されるため，コミットしたあとのレスポンスにはHTTP Cookieを付加できません。そのため，Webアプリケーション内でHTTPレスポンスがコミットされたあとでHTTPセッションが無効化された場合，HTTP Cookie情報を削除するためのHTTP Cookieは付加されません。しかし，次回リクエスト受信時に，存在しないセッションIDを受信することになるため「2.7.4(2)　J2EEサーバに存在しないセッションIDを受信した場合」に該当し，HTTP Cookie情報が削除されます。

注※2

HTTPレスポンスのコミット時に新しいHTTPセッションが作成されていた場合は，新しいセッションIDを示すHTTP CookieでWebクライアントのHTTP Cookie情報が上書きされるため，HTTP Cookie情報の削除は不要になります。

なお，次の条件のどちらかを満たす場合，HTTPセッションが無効化された場合でも，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP Cookieは付加されません。

簡易Webサーバでリクエストを受信した。

サーブレットエンジンモードを使用している。

(2)　J2EEサーバに存在しないセッションIDを受信した場合

次の条件をすべて満たす場合，無効なセッションIDを受信したと判断され，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP CookieがHTTPレスポンスのヘッダに付加されます。

セッションIDがHTTP Cookieを使用して通知された。

通知されたセッションIDがJ2EEサーバに存在しないセッションIDである。

HTTPレスポンスのコミット時にHTTPセッションが存在していない。

(3)　Webクライアントが保持する無効なセッションIDの削除をする場合の注意事項

複数のJ2EEサーバで同じパスのリクエストを扱う構成の場合，この機能を無効にしてください。

リバースプロキシなどでCookieのPathが書き換えられた同じパスのリクエストを扱うと，HTTPセッションが不当に削除されるおそれがあります。

2.7.5　HttpSessionオブジェクト数の上限値の設定

アプリケーションサーバでは，有効となるHttpSessionオブジェクト数に，上限値を設定できます。

HttpSessionオブジェクトの上限値は，J2EEアプリケーションに含まれるWebアプリケーションの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，「2.7.7　cosminexus.xmlでの定義」を参照してください。

注意

Webアプリケーションにセッションフェイルオーバ機能を適用している場合，次の設定にしているときは，HttpSessionオブジェクト数の上限値の設定が必要です。

アプリケーション開始時のネゴシエーション処理に失敗したときに，Webアプリケーションの開始処理を中止する設定（簡易構築定義ファイルのwebserver.dbsfo.negotiation.high_levelキー）

この場合，HttpSessionオブジェクト数の上限値を設定していないと，セッション情報の引き継ぎを行うWebアプリケーションの開始時にエラーとなり，Webアプリケーションを開始できません。アプリケーション開始時のネゴシエーション処理に失敗したときに，Webアプリケーションの開始処理を続行する設定にしている場合は，HttpSessionオブジェクト数の上限値の設定は任意です。

セッションフェイルオーバ機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「5.2　セッションフェイルオーバ機能の概要」を参照してください。

セッションフェイルオーバ機能のWebアプリケーション開始時のネゴシエーション処理については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「6.8.1　アプリケーション開始時の処理」を参照してください。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

参考

グローバルセッション情報のサイズ見積もり機能を有効にする場合，セッションフェイルオーバ機能の前提条件であるHttpSessionオブジェクト数の上限値の指定は不要です。グローバルセッション情報のサイズ見積もり機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「7.5　グローバルセッション情報のサイズの見積もり」を参照してください。

＜この項の構成＞

(1)　上限値を設定する対象になるHttpSessionオブジェクト

(2)　HttpSessionオブジェクト数が上限値を超えた場合の動作（例外の発生）

(3)　HttpSessionオブジェクト数が上限値を超えた場合の動作（メッセージの出力）

(1)　上限値を設定する対象になるHttpSessionオブジェクト

上限値を設定する対象になるのは，有効なHttpSessionオブジェクトです。

有効なHttpSessionオブジェクトとは，javax.servlet.http.HttpServletRequestクラスのgetSessionメソッドで取得したHttpSessionオブジェクトのうち，次の二つの条件を満たすオブジェクトを指します。

タイムアウトしていないオブジェクト

invalidateメソッドが呼ばれていないオブジェクト

(2)　HttpSessionオブジェクト数が上限値を超えた場合の動作（例外の発生）

HttpSessionオブジェクト数の上限値を設定していると，設定した上限値を超えてHttpSessionオブジェクトを生成しようとした場合にjavax.servlet.http.HttpServletRequestクラスのgetSessionメソッドで例外が発生します。設定に応じて，次のどちらかの例外が発生します。

java.lang.IllegalStateException

java.lang.IllegalStateExceptionの派生クラスであるcom.hitachi.software.web.session.HttpSessionLimitExceededException

どちらの例外をスローするかは，J2EEアプリケーションのパラメタで設定します。J2EEアプリケーションの設定については，「2.7.8(1)　J2EEサーバの設定」を参照してください。

WebコンテナでのHttpSessionオブジェクト生成は，次のタイミングで実行されます。

JSP実行時
pageディレクティブのsession属性に「true」を指定した場合，またはsession属性を省略している場合に，JSPを実行したときを指します。

FORM認証を必要とするURLへのアクセス時

設定した上限値を超えてHttpSessionオブジェクトの生成処理が発生すると，次のように動作します。

JSP実行時に上限値を超えた場合
JSPのユーザコードが実行される前に，java.lang.IllegalStateExceptionまたはcom.hitachi.software.web.session.HttpSessionLimitExceededExceptionがスローされます。

FORM認証を必要とするURLへのアクセス時に上限値を超えた場合
ログイン用ページにリクエストが転送される前に，java.lang.IllegalStateExceptionまたはcom.hitachi.software.web.session.HttpSessionLimitExceededExceptionがスローされます。

ポイント

com.hitachi.software.web.session.HttpSessionLimitExceededExceptionクラスを使用する場合は，J2EEアプリケーションの開発時に<Cosminexusのインストールディレクトリ>/CC/lib/ejbserver.jarをクラスパスに追加して，Javaプログラムをコンパイルしてください。

(3)　HttpSessionオブジェクト数が上限値を超えた場合の動作（メッセージの出力）

HttpSessionオブジェクト数の上限値を設定していると，設定した上限値を超えてHttpSessionオブジェクトを生成しようとした場合にKDJE39225-Eのメッセージがログに出力されます。

KDJE39225-Eは，HTTPセッションを使用するリクエストが実行されるたびに出力されるため，同じメッセージでログが埋まってしまうおそれがあります。同じメッセージが繰り返し出力されるのを抑止するために，KDJE39225-Eのインターバル（出力間隔）を設定できます。必要に応じて，インターバルを設定してください。このインターバルはWebアプリケーション単位に適用されます。

メッセージの出力インターバルの設定については，「2.7.8(1)　J2EEサーバの設定」を参照してください。

2.7.6　セッションIDおよびCookieへのサーバIDの付加

アプリケーションサーバでは，HttpSessionのセッションIDやCookieに，サーバIDを付けることができます。これを，サーバID付加機能といいます。サーバIDは，Webコンテナごとに異なる値を設定します。

セッションIDおよびCookieへのサーバIDの付加についての設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「2.7.8　実行環境での設定」を参照してください。

なお，メモリセッションフェイルオーバ機能を使用する場合は，セッションIDへのサーバIDの付加は必須となります。メモリセッションフェイルオーバ機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「7.　メモリセッションフェイルオーバ機能」を参照してください。

＜この項の構成＞

(1)　HttpSessionのセッションIDへのサーバID付加

(2)　CookieへのサーバID付加

(1)　HttpSessionのセッションIDへのサーバID付加

セッションIDは，通常，同一のWebコンテナ内では一意となります。しかし，負荷分散機を使用して複数のWebコンテナで構成するシステムの場合，システム全体ではセッションIDが一意にならないおそれがあります。HttpSessionのセッションIDへのサーバID付加機能を使用すると，HttpSessionのセッションIDに，Webコンテナごとに異なるサーバIDが付加されます。これによって，セッションIDをシステム内で一意にできます。

参考

Webサーバとの連携時に，リダイレクタの設定でラウンドロビンでリクエストの振り分けをする場合，HttpSessionのセッションIDを付加するかどうかの設定にかかわらず，セッションIDには，ワーカ名が付加されます。サーバIDは付加されません。

(2)　CookieへのサーバID付加

同一のセッションのリクエストを，同一のWebコンテナに転送するには，負荷分散機のCookieによってリクエスト転送先を指定する機能と，CookieへのサーバID付加機能を使用して実現します。

CookieへのサーバID付加機能では，CookieにWebコンテナごとに異なるサーバIDが付加されます。HTTPレスポンスには，サーバIDが付加されたCookieを付けることができるので，同一のセッションのリクエストを，同一のWebコンテナに転送できます。なお，サーバIDが付いたCookieは，HttpSessionを生成したリクエストのレスポンスに付加されます。

なお，次の場合，サーバID付加機能で生成されるCookieにSecure属性が付加されます。

HTTPリクエストがHTTPSプロトコルで送信されている場合

ゲートウェイ指定機能でスキームをHTTPSと見なすように設定した場合

2.7.7　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

HttpSessionオブジェクト数の上限値の設定

cosminexus.xmlの<war>タグ内の<http-session>－<http-session-max-number>タグに指定します。セッション情報の引き継ぎを行うWebアプリケーションには，HTTPセッション数の上限値に1以上の有効な値を設定する必要があります。

指定するタグの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

2.7.8　実行環境での設定

セッション管理機能を使用する場合，J2EEサーバの設定が必要です。

また，cosminexus.xmlを含まないJ2EEアプリケーションを使用する場合，実行環境でのプロパティの設定または変更が必要です。

＜この項の構成＞

(1)　J2EEサーバの設定

(2)　J2EEアプリケーションの設定

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。セッション管理機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのセッション管理機能の定義について次の表に示します。

表2-29　簡易構築定義ファイルでのセッション管理機能の定義

項目
指定するパラメタ
設定内容

HttpSessionオブジェクト数の上限値の設定
webserver.session.max.throwHttpSessionLimitExceededException
HttpSessionオブジェクト数が上限値を超えた場合にcom.hitachi.software.web.session.HttpSessionLimitExceededException例外をスローするかどうかを指定します。
java.lang.IllegalStateException例外をスローする場合はfalseを指定します。

webserver.session.max.log_interval
KDJE39225-Eの出力インターバルを指定します。

セッションIDおよびCookieへのサーバID付加
webserver.session.server_id.enabled
セッションIDにサーバIDを付加するかどうかを指定します。

webserver.session.server_id.value
セッションIDに付加するサーバIDを指定します。

webserver.container.server_id.enabled
CookieにサーバIDを付加するかどうかを指定します。

webserver.container.server_id.name
サーバIDを付加するCookieの名称を指定します。

webserver.container.server_id.value
Cookieに付加するサーバIDを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。セッション管理機能の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.7.7　cosminexus.xmlでの定義」を参照してください。

2.7.9　セッション管理の注意事項

セッション管理の注意事項について説明します。

＜この項の構成＞

(1)　URL書き換えをする場合に使用するAPIと注意事項

(2)　URL書き換えを使用する場合の注意事項

(3)　セッションの管理に使用するHTTP CookieのSecure属性

(1)　URL書き換えをする場合に使用するAPIと注意事項

URL書き換えは，J2EEアプリケーション内でURL書き換えを実行するServlet APIを呼び出したときに実行されます。

URL書き換えを実行するServlet APIとは，次に示すjavax.servlet.http.HttpServletResponseインタフェースのメソッドです。

encodeURL(java.lang.String url)メソッド

encodeRedirectURL(java.lang.String url)メソッド

encodeUrl(java.lang.String url)メソッド

encodeRedirectUrl(java.lang.String url)メソッド

これらのメソッドの詳細については，Servlet仕様を参照してください。なお，encodeUrl(java.lang.String url)メソッド，およびencodeRedirectUrl(java.lang.String url)メソッドは，Servlet 2.1以降，非推奨のAPIとなっています。このため，これら以外のメソッドを使用することをお勧めします。

ここでは，Servlet仕様で明記されていないAPIの動作として，URL書き換えを実行するServlet APIの戻り値についての，アプリケーションサーバでの動作について説明します。

HTTPセッションは，リクエスト処理中のWebアプリケーション内だけで有効です。このため，Servlet APIの引数に指定されたURLが，リクエスト処理中のWebアプリケーション内を指しているURLの場合にだけ，URL書き換えをします。引数のURLごとに，リクエスト処理中のWebアプリケーション内を指していると判定する条件を次の表に示します。

表2-30　引数のURLごとに，リクエスト処理中のWebアプリケーション内を指していると判定する条件

引数のURLの種類
判定条件

相対URL
（（例）/ex/a.html）
次の条件を満たす場合にだけ，Webアプリケーション内であると判定されます。

引数のURLの正規化したパスが，リクエスト処理中のWebアプリケーションのコンテキストルート名を含んでいる。※1

絶対URL
（（例）http://host1/ex/）
次のすべての条件を満たす場合にだけ，Webアプリケーション内であると判定されます。

引数のURLのスキームが「http」，または「https」である。※2

引数のURLとリクエストのURLが同一のスキームの場合，ポート番号が一致する。

引数のURLのホスト名が，リクエストのホスト名と一致する。※1※3

引数のURLの正規化したパスが，リクエスト処理中のWebアプリケーションのコンテキストルート名を含んでいる。※1

注※1　名称を比較する場合に，大文字，小文字を区別します。

注※2　名称を比較する場合に，大文字，小文字を区別しません。

注※3　リクエストのホスト名は，リクエストのHostヘッダのホスト名部分とし，ホスト名の名前解決しないで，文字列を比較します。なお，リクエストのホスト名には，javax.servlet.ServletRequest.getServerNameメソッドの戻り値を使用します。なお，次の場合は，同じホストであっても異なるホストと判定します。

引数のURLがホスト名の指定で，リクエストのURLがIPアドレスの場合

引数のURLがIPアドレスの指定で，リクエストのURLがホスト名の場合

また，URL書き換えを実行するServlet APIの引数に，URL以外の文字列を指定した場合の戻り値について説明します。また，URLの先頭にクエリまたはフラグメントを指定した場合についても，あわせて説明します。

URL書き換えを実行するServlet APIの引数ごとの戻り値を次の表に示します。

表2-31　URL書き換えを実行するServlet APIの引数ごとの戻り値

項番
条件
戻り値または発生する例外

HTTPセッション
引数

1
－
null
nullが返されます。

2
－
URLとして不正なフォーマット
java.lang.IllegalArgumentException例外が発生します。

3

リクエスト処理中に新規作成したHTTPセッションがある。

URL書き換えでセッションIDが通知されている。

空文字列
HTTPリクエストのURLのパスおよびクエリに対して，セッションIDを付加した値が返されます。※1

4
クエリから開始されているURL（先頭文字が「?」の場合）
HTTPリクエストのURLのパスに，セッションIDおよび引数に指定した値が付加された値が返されます。※1

5
フラグメントから開始されているURL（先頭文字が「#」の場合）
引数に指定した値が返されます。※2

6
現在のHTTPセッションのセッションIDを表すパスパラメタが含まれているURL
引数に指定した値が返されます。

7
リクエスト処理中のWebアプリケーション内と判定されるURL
引数にセッションIDを付加した値が返されます。

8
上記の条件以外
引数に指定した値が返されます。

（凡例）－：該当しない

注

この表で示す項番は，条件の優先度を示します。項番の数字が小さいほど，条件の優先度は高くなります。

注※1

引数のURLにパスが含まれないため，引数のURLにパスパラメタを直接付加できません。引数が空文字列やクエリから始まるURLは，リクエストのURLのリソースを指しているURLであるため，リクエストのURLにパスパラメタを付加した値を使用して，URL書き換えをします。

注※2

フラグメントだけのURLは，現在のリソース内の特定の個所を示すURLです。Webブラウザでは，通常このURLを，表示されているコンテンツ内の移動を示すものとして扱います。このとき，サーバにリクエストは送信しません。なお，これは，RFC3986に従った動作です。

次に，URL書き換えを使用してセッションIDを付加したURLの例について説明します。なお，ここで説明する例は，次の前提条件に従っています。

前提条件

Servlet APIは，HTTPセッションの生成後に実行されたものとします。

HTTPリクエストのURLは，「http://host1/gyoumu1/app1/index.jsp?type=1」です。

コンテキストルート名は，「/gyoumu1」です。

URL書き換えに使用するServlet APIの引数の指定値と書き換え後の戻り値（URL）の対応の例を次の表に示します。

表2-32　URL書き換えに使用するServlet APIの引数の指定値と書き換え後の戻り値（URL）の対応の例

Servlet APIの引数 | 戻り値
b.html | b.html;jsessionid=AAAAA111112222233333444445555566svr0
../b.html | ../b.html;jsessionid=AAAAA111112222233333444445555566svr0
../../b.html | ../../b.html
http://host2/ | http://host2
https://host1/gyoumu1/ | https://host1/gyoumu1/;jsessionid=AAAAA111112222233333444445555566svr0
""(空文字列) | "/gyoumu1/app1/index.jsp;jsessionid=AAAAA111112222233333444445555566svr0?type=1"
"?mode=2" | "/gyoumu1/app1/index.jsp;jsessionid=AAAAA111112222233333444445555566svr0?mode=2"
"#aaa" | "#aaa"

(2)　URL書き換えを使用する場合の注意事項

URL書き換えを使用する場合の注意事項について説明します。

●静的コンテンツからの画面遷移

静的コンテンツ（HTMLファイルなど）から遷移した場合，URL書き換えによって管理されているセッションは維持されません。

URL書き換えを使用してセッションを管理する場合は，常にサーブレットまたはJSPを使用して画面を遷移するように実装してください。また，サーブレットまたはJSP内で，Servlet APIによってURLを書き換えて，セッションIDを追加する処理を実装してください。

●Webアプリケーションで取得したリクエストURL

HTTPリクエストのURLに，URL書き換えによって追加されたセッションIDを示すパスパラメタが含まれる場合であっても，次のメソッドによって取得したURLには，セッションIDを示すパスパラメタは含まれません。

インタフェース

javax.servlet.http.HttpServletRequestインタフェース

メソッド

getRequestURI()メソッド

getRequestURL()メソッド

(3)　セッションの管理に使用するHTTP CookieのSecure属性

HTTPリクエストをHTTPSプロトコルで送信した場合に，Webコンテナが生成したセッションIDがHTTP Cookieによってクライアントに返されます。そのとき，HTTP CookieにSecure属性が付与されます。

また，ゲートウェイ指定機能でスキームをHTTPSと見なすように設定している場合に，Webコンテナが生成したセッションIDを，HTTP Cookieによってクライアントに返すとき，そのHTTP CookieにはSecure属性が付与されます。

2.8　アプリケーションのイベントリスナ

この節では，アプリケーションのイベントリスナ機能について説明します。

Webアプリケーション単位でのイベントリスナ機能があります。アプリケーションイベントリスナは，Webアプリケーションのデプロイ時にインスタンス化されます。インスタンス化されたアプリケーションイベントリスナは，サーブレットコンテキストオブジェクトまたはセッションオブジェクトのどちらか一方，または両方の状態変化イベントを受け取ります。リスナオブジェクトが受け取るイベントを次に示します。

セッションオブジェクトの新規生成

セッションオブジェクトのシリアライズ前※1

セッションオブジェクトのデシリアライズ後※1

セッションオブジェクトの抹消

セッションオブジェクトの属性の追加，削除，変更

サーブレットコンテキストオブジェクトの生成

サーブレットコンテキストオブジェクトの抹消

サーブレットコンテキストオブジェクトの属性の追加，削除，変更

Webアプリケーションへのリクエストの到着※2

Webアプリケーションでのリクエスト処理の完了※2

リクエストオブジェクトの属性の追加，削除，変更※2

注※1

サーブレットエンジンのベンダ独自処理の都合で，セッションオブジェクトをシリアライズして格納，通信し，別の時点でデシリアライズして処理を再開することが，Servlet APIでは想定されています。

セッションオブジェクトに，これらのイベント通知が設けられている意図は，セッションオブジェクトにデータだけでなく，データベースコネクションやオブジェクトリファレンスなどの資源を持たせられるようにするためです。セッションオブジェクトに資源を持たせるような設計のアプリケーションでは，シリアライズの前にいったん資源を解放し，デシリアライズ後に再び獲得するようにしなければなりません。

セッションオブジェクトに資源を持たせるという構成は，注意深く利用しないとサーバ全体の必要資源量を大幅に増大させてしまい，資源が不足するおそれがあります。このため，イベントリスナ機能は，資源を確保できる場合に利用してください。

注※2

Servlet 2.4以降の仕様に準拠したWebアプリケーションの場合だけ使用できます。

2.9　リクエストおよびレスポンスのフィルタリング機能

この節では，リクエストおよびレスポンスのフィルタリング機能について説明します。

この節の構成を次の表に示します。

表2-33　この節の構成（リクエストおよびレスポンスのフィルタリング機能）

分類 | タイトル | 参照先
解説 | アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ） | 2.9.1
フィルタ連鎖の推奨例 | 2.9.2
実装 | DDでの定義 | 2.9.3
設定 | 実行環境での設定（Webアプリケーションの設定） | 2.9.4

注　「運用」および「注意事項」について，この機能固有の説明はありません。

アプリケーションサーバで使用できるフィルタリングの機能には，Servlet仕様で規定されている機能と，アプリケーションサーバで提供する機能があります。どちらの機能も，サーブレット/JSPのリクエストやレスポンスに対してフィルタリングをする機能です。

Servlet仕様で規定されているフィルタリング機能では，サーブレット/JSPを実行する前のリクエスト，またはサーブレット/JSPを実行したあとのレスポンスをラップします。これによって，データの変更，リソースに対するトレースの取得などができます。

また，アプリケーションサーバが提供するフィルタリング機能では，セッション情報を引き継いだり，HTTPレスポンスを圧縮したりできます。アプリケーションサーバでは，これらのフィルタリング機能を使用するためにサーブレットフィルタを提供しています。アプリケーションサーバが提供するサーブレットフィルタをbuilt-inフィルタといいます。次項でアプリケーションサーバが提供するbuilt-inフィルタについて説明します。

＜この節の構成＞

2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）

2.9.2　フィルタ連鎖の推奨例

2.9.3　DDでの定義

2.9.4　実行環境での設定（Webアプリケーションの設定）

2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）

アプリケーションサーバでは，次に示す機能を使用するためのサーブレットフィルタ（built-inフィルタ）を提供しています。

J2EEサーバ間のセッション情報の引き継ぎ（メモリセッションフェイルオーバ機能）
J2EEサーバ間のセッション情報を引き継ぐために，アプリケーションサーバはbuilt-inフィルタとしてセッションフェイルオーバ用フィルタを提供しています。

HTTPレスポンスの圧縮
HTTPリクエストに対するHTTPレスポンスを圧縮するために，アプリケーションサーバはbuilt-inフィルタとしてHTTPレスポンス圧縮フィルタを提供しています。

クライアント性能測定スクリプトの埋め込み
クライアント性能測定スクリプトのコードを測定したい対象に埋め込むために，アプリケーションサーバはbuilt-inフィルタとしてクライアント性能フィルタを提供しています。

built-inフィルタの種類を次の表に示します。また，Webアプリケーションにbuilt-inフィルタを組み込むことによって使用できる機能の参照先をあわせて示します。

表2-34　built-inフィルタの種類

built-inフィルタの種類 | 機能の説明 | 参照先マニュアル | 参照個所
セッションフェイルオーバ用フィルタ | J2EEアプリケーションで実行中のセッション情報を管理します。J2EEサーバで障害が発生したときに，管理しているセッション情報をほかのJ2EEサーバに引き継ぎます。 | マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」 | 7.4，7.2
HTTPレスポンス圧縮フィルタ | サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスをgzip形式に圧縮します。 | このマニュアル | 2.10
クライアント性能フィルタ | クライアント性能測定スクリプトのコードを測定したい対象に埋め込みます。クライアント性能測定スクリプトはWebブラウザ上で動作し，Webブラウザの操作に掛かる処理時間を記録します。 | マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」 | 9.1

ポイント

各フィルタをWebアプリケーションに組み込む場合は，フィルタマッピング定義で，「セッションフェイルオーバ用フィルタ」，「HTTPレスポンス圧縮フィルタ」，「クライアント性能フィルタ」の順に定義してください。セッションフェイルオーバ用フィルタは，すべてのbuilt-inフィルタ，ユーザのフィルタよりも前に配置する必要があります。

以降で，built-inフィルタのHTTPリクエスト・HTTPレスポンスへの作用，built-inフィルタの動作条件に関する制約について説明します。

＜この項の構成＞

(1)　HTTPリクエストおよびHTTPレスポンスへの作用

(2)　動作条件に関する制約

(1)　HTTPリクエストおよびHTTPレスポンスへの作用

built-inフィルタは，クライアント側から送信されるHTTPリクエストのリクエストヘッダ，およびリクエストボディに対して作用して，情報の削除，追加，変更などを実施する場合があります。また，サーバから送信されるHTTPレスポンスのレスポンスヘッダ，およびレスポンスボディに対して同様に作用する場合もあります。built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用を次の表に示します。

表2-35　built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用

built-inフィルタの種類 | HTTPリクエストへの作用 | HTTPレスポンスへの作用
セッションフェイルオーバ用フィルタ | － | －
HTTPレスポンス圧縮フィルタ | － | レスポンスボディが圧縮される場合，Content-Encodingヘッダに「gzip」を指定します。また，レスポンスボディをgzip形式で圧縮します。
クライアント性能フィルタ | 詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「9.2.2　クライアント性能フィルタの定義方法」を参照してください。

（凡例）　－：該当なし

(2)　動作条件に関する制約

ユーザのフィルタと，built-inフィルタを同時に使用する場合，フィルタ連鎖の中でbuilt-inフィルタが呼び出される順序に制約があります。

built-inフィルタごとに次に示す制約について説明します。

位置に関する制約
フィルタ連鎖中のbuilt-inフィルタの位置（呼び出される順序）に関する制約です。

動作条件に関する制約
built-inフィルタが動作する上での前提条件などの動作条件に関する制約です。

前後に配置するほかのサーブレットフィルタに対する制約
built-inフィルタの前後に配置するサーブレットフィルタに対する制約です。

(a)　セッションフェイルオーバ用フィルタに対する制約

セッションフェイルオーバ用フィルタに対する制約を次の表に示します。

表2-36　セッションフェイルオーバ用フィルタに対する制約

制約の種類 | 説明
位置に関する制約 | フィルタ連鎖の中で，最初に呼び出される必要があります。すべてのユーザのフィルタおよびbuilt-inフィルタよりも前に配置する必要があります。
動作条件に関する制約 | －
前後に配置するほかのサーブレットフィルタに対する制約 | －

（凡例）　－：該当なし

(b)　HTTPレスポンス圧縮フィルタに対する制約

HTTPレスポンス圧縮フィルタに対する制約を次の表に示します。

表2-37　HTTPレスポンス圧縮フィルタに対する制約

制約の種類 | 説明
位置に関する制約 | －
動作条件に関する制約 | －
前後に配置するほかのサーブレットフィルタに対する制約 | javax.servlet.http.HttpServletResponseクラスのsetHeaderメソッド，addHeaderメソッド，setIntHeaderメソッド，またはaddIntHeaderメソッドを使用して，Content-Lengthヘッダ，またはContent-Encodingヘッダの設定を変更するサーブレットフィルタと同時に使用する場合，そのサーブレットフィルタはHTTPレスポンス圧縮フィルタよりあとに配置する必要があります。

（凡例）　－：該当なし

(c)　クライアント性能フィルタに対する制約

クライアント性能フィルタに対する制約を次の表に示します。

表2-38　クライアント性能フィルタに対する制約

制約の種類
説明

位置に関する制約
－

動作条件に関する制約
－

前後に配置するほかのサーブレットフィルタに対する制約

HTMLを別のコンテンツの種類に変換するサーブレットフィルタと同時に使用する場合，クライアント性能フィルタはそのフィルタよりもあとに配置する必要があります。

最終的にクライアントが受け取るレスポンス内容をそのまま処理したいサーブレットフィルタと同時に使用する場合，クライアント性能フィルタはそのフィルタよりもあとに配置する必要があります。

HTMLレスポンスを生成するフィルタと同時に使用する場合，クライアント性能フィルタはそのフィルタよりも前に配置する必要があります。

（凡例）　－：該当なし

2.9.2　フィルタ連鎖の推奨例

フィルタ連鎖の推奨例を次に示します。次に示す順序で連鎖するように配置してください。

なお，例で説明するユーザのフィルタは，リクエストボディおよびレスポンスボディに作用する一般的なフィルタを想定しています。

セッションフェイルオーバ用フィルタ，HTTPレスポンス圧縮フィルタ，クライアント性能フィルタを使用する場合

セッションフェイルオーバ用フィルタ

HTTPレスポンス圧縮フィルタ

クライアント性能フィルタ

セッションフェイルオーバ用フィルタ，HTTPレスポンス圧縮フィルタ，クライアント性能フィルタ，およびユーザのフィルタ（FilterA）を使用する場合

セッションフェイルオーバ用フィルタ

HTTPレスポンス圧縮フィルタ

クライアント性能フィルタ

ユーザのフィルタ（FilterA）

セッションフェイルオーバ用フィルタ，およびユーザのフィルタ（FilterC）を使用する場合

セッションフェイルオーバ用フィルタ

ユーザのフィルタ（FilterC）

HTTPレスポンス圧縮フィルタ，およびユーザのフィルタ（FilterD）を使用する場合

HTTPレスポンス圧縮フィルタ

ユーザのフィルタ（FilterD）

クライアント性能フィルタ，およびユーザのフィルタ（FilterE）を使用する場合

クライアント性能フィルタ

ユーザのフィルタ（FilterE）

2.9.3　DDでの定義

リクエストおよびレスポンスのフィルタリング機能の定義は，web.xmlに指定します。

DDでのリクエストおよびレスポンスのフィルタリング機能の定義については，それぞれ次の場所を参照してください。

セッションフェイルオーバ用フィルタについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

HTTPレスポンス圧縮フィルタについては，「2.10　HTTPレスポンス圧縮機能」を参照してください。

クライアント性能フィルタの定義については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 拡張編」の「9.2.2　クライアント性能フィルタの定義方法」を参照してください。

2.9.4　実行環境での設定（Webアプリケーションの設定）

リクエストおよびレスポンスのフィルタリング機能を定義する場合，Webアプリケーションの設定が必要です。cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リクエストおよびレスポンスのフィルタリングの定義には，フィルタ属性ファイルおよびWAR属性ファイルを使用します。

フィルタ属性ファイルおよびWAR属性ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「2.9.3　DDでの定義」を参照してください。

2.10　HTTPレスポンス圧縮機能

この節では，HTTPレスポンス圧縮機能について説明します。

HTTPレスポンス圧縮機能とは，サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスを，gzip形式に圧縮する機能です。この機能を使用してHTTPレスポンスを圧縮することで，WebコンテナとWebクライアント（ブラウザなど）との間のHTTPレスポンス通信に掛かる時間を削減できます。

この機能は，Webアプリケーションに組み込んで動作させるサーブレットフィルタとして提供されています。これを，HTTPレスポンス圧縮フィルタといいます。

この節の構成を次の表に示します。

表2-39　この節の構成（HTTPレスポンス圧縮機能）

分類 | タイトル | 参照先
解説 | HTTPレスポンス圧縮フィルタの概要 | 2.10.1
HTTPレスポンス圧縮フィルタを使用するための条件 | 2.10.2
実装 | HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装 | 2.10.3
DDでの定義 | 2.10.4
DDの定義例 | 2.10.5
設定 | 実行環境での設定（Webアプリケーションの設定） | 2.10.6

注　「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.10.1　HTTPレスポンス圧縮フィルタの概要

2.10.2　HTTPレスポンス圧縮フィルタを使用するための条件

2.10.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

2.10.4　DDでの定義

2.10.5　DDの定義例

2.10.6　実行環境での設定（Webアプリケーションの設定）

2.10.1　HTTPレスポンス圧縮フィルタの概要

HTTPレスポンス圧縮機能を有効にすると，HTTPレスポンスのレスポンスボディをgzip形式に圧縮します。HTTPレスポンス圧縮機能の概要を次の図に示します。

図2-12　HTTPレスポンス圧縮機能の概要

HTTPレスポンス圧縮機能を有効にするためには，アプリケーションサーバが提供するHTTPレスポンス圧縮フィルタをWebアプリケーションに組み込む必要があります。HTTPレスポンス圧縮機能を適用する場合，WebアプリケーションのDD（web.xml）にHTTPレスポンス圧縮フィルタのフィルタ定義，およびフィルタマッピングの定義を追加します。J2EEサーバにデプロイ済みのWebアプリケーションに適用する場合は，サーバ管理コマンドを使用して，HTTPレスポンス圧縮フィルタのフィルタ定義，およびフィルタマッピングの定義を追加します。

2.10.2　HTTPレスポンス圧縮フィルタを使用するための条件

ここでは，HTTPレスポンス圧縮フィルタを使用する場合の条件や注意事項について説明します。

＜この項の構成＞

(1)　前提条件

(2)　必要なメモリ量

(3)　HTTPレスポンス圧縮機能を有効にする場合の条件

(4)　注意事項

(1)　前提条件

HTTPレスポンス圧縮機能を使用にするには，次の前提条件を満たしている必要があります。

Webクライアントのgzip形式の対応
HTTPレスポンス圧縮機能を有効にした場合，gzip形式で圧縮されたHTTPレスポンスをWebクライアントで解凍する必要があります。そのため，Webクライアントがgzip形式に対応していることが前提となります。Webクライアントがgzip形式に対応していない場合は，HTTPレスポンス圧縮機能を有効にしていても，HTTPレスポンスは圧縮されません。

WebクライアントのHTTP/1.1の対応
HTTPレスポンス圧縮機能では，Webクライアントがgzip形式に対応しているかどうかをHTTPリクエストのAccept-Encodingヘッダに指定された値によって判定しています。そのため，WebクライアントはAccept-Encodingヘッダの仕様が規定されているHTTP/1.1に対応している必要があります。

(2)　必要なメモリ量

HTTPレスポンス圧縮機能に必要なメモリ量は次の計算式で求められます。

HTTPレスポンス圧縮機能に必要なメモリ量（バイト）=HTTPレスポンス圧縮機能が有効となるHTTPリクエストの同時実行数×レスポンスの圧縮しきい値（バイト）

圧縮しきい値とは，HTTPレスポンスボディのサイズによって，HTTPレスポンスを圧縮するかどうかを判定するためのしきい値です。HTTPレスポンスボディのサイズが圧縮しきい値に定義したサイズを超える場合にだけ，HTTPレスポンスを圧縮します。なお，圧縮しきい値は，HTTPリクエストに対して設定します。

圧縮しきい値は，DD（web.xml）に定義します。圧縮しきい値を定義することで，HTTPレスポンスのサイズが小さい場合に，HTTPレスポンスの圧縮に掛かる時間が，通信に掛かる時間よりも大きくならないようにします。

圧縮しきい値は，圧縮するリソースの種別と通信回線の速度によって適切なサイズが決まります。圧縮しきい値に定義するサイズは実測で求め，適切なサイズを定義することを推奨します。

(3)　HTTPレスポンス圧縮機能を有効にする場合の条件

HTTPレスポンス圧縮機能が有効になる条件を指定できます。指定できる条件を次に示します。

HTTPリクエストのURLパターン
HTTPレスポンス圧縮フィルタを実装しているWebアプリケーションに対するリクエストのURLが，指定したURLパターンと一致する場合，そのリクエストに対するレスポンスを圧縮します。
HTTPレスポンスの圧縮を実行するHTTPリクエストのURLパターンとして「*.html」を指定した場合の例を次の図に示します。

図2-13　HTTPレスポンスの圧縮を実行するHTTPリクエストのURLパターンとして「*.html」を指定した場合の例

HTTPレスポンスのMedia-Type
HTTPレスポンスのContent-Typeヘッダに含まれるMedia-Typeの値が，指定した値と一致する場合，HTTPレスポンスを圧縮します。
HTTPレスポンスのMedia-Typeは，サーブレット/JSPの場合はJ2EEアプリケーションがsetContentTypeメソッドによって設定した値です。静的コンテンツの場合は拡張子に対応づけられたMIMEタイプとなります。
HTTPレスポンスの圧縮を実行するHTTPレスポンスのMedia-Typeとして「text/html」を指定した場合の例を次の図に示します。

図2-14　HTTPレスポンスの圧縮を実行するHTTPレスポンスのMedia-Typeとして「text/html」を指定した場合の例

HTTPレスポンスのボディサイズ
HTTPレスポンスの圧縮を実行するためしきい値を設定して，ボディサイズがこのしきい値を超える場合，HTTPレスポンスを圧縮します。
HTTPレスポンスの圧縮を実行するHTTPレスポンスのボディサイズとして「200バイト」を指定してHTTPレスポンス圧縮機能を有効にした場合の例を次の図に示します。

図2-15　HTTPレスポンスの圧縮を実行するHTTPレスポンスのボディサイズとして「200バイト」を指定した場合の例

(4)　注意事項

HTTPレスポンス圧縮フィルタの定義に関する注意事項

HTTPレスポンス圧縮フィルタを使用する場合，built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用やフィルタ連鎖の順序制約を考慮して，WebアプリケーションにHTTPレスポンス圧縮フィルタを組み込む必要があります。built-inフィルタの詳細については，「2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。

エラーページに関する注意事項

HTTPレスポンス圧縮機能を使用するWebアプリケーションでは，次の機能を使用してエラーページをカスタマイズできます。

Webサーバの機能を使用したエラーページのカスタマイズ

インプロセスHTTPサーバによるエラーページのカスタマイズ

web.xmlの<error-page>タグを使用したエラーページのカスタマイズ

web.xmlの<error-page>タグを使用したエラーページを使用する場合は，エラーページに静的コンテンツ，またはレスポンスからjavax.servlet.ServletOutputStreamを取得して使用するサーブレットを指定してください。

HTTPレスポンス圧縮機能では圧縮後のデータの出力にレスポンスオブジェクトから取得したjavax.servlet.ServletOutputStreamを使用します。そのため，エラーページを生成するサーブレット，またはJSPでレスポンスオブジェクトからは，java.io.PrintWriterを取得することができません。

2.10.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

ここでは，HTTPレスポンス圧縮フィルタを使用するアプリケーションを開発するときの注意事項について説明します。

＜この項の構成＞

(1)　ほかのフィルタと併用する場合の呼び出し順序

(2)　HTTPレスポンスのバッファに関する注意事項

(3)　HTTPレスポンスのレスポンスヘッダに関する注意事項

(4)　HTTPレスポンスのデータ出力に関する注意事項

(5)　アプリケーションでHTTPレスポンスを圧縮する場合の注意事項

(1)　ほかのフィルタと併用する場合の呼び出し順序

HTTPレスポンス圧縮フィルタは，HTTPレスポンスのヘッダに設定するほかのフィルタよりも前に呼び出される必要があります。javax.servlet.http.HttpServletResponseのsetHeaderメソッド，addHeaderメソッド，setIntHeaderメソッド，およびaddIntHeaderメソッドを使用して，Content-Lengthヘッダ，Content-Encodingヘッダを設定するほかのフィルタを使用する場合は，HTTPレスポンス圧縮フィルタよりも後ろに配置してください。

(2)　HTTPレスポンスのバッファに関する注意事項

HTTPレスポンス圧縮機能を有効にした場合，HTTPレスポンスのバッファよりも前に圧縮しきい値に指定したサイズのバッファが設けられます。HTTPレスポンスのバッファには，出力したデータが圧縮しきい値を超えたときに書き込まれます。

圧縮後のデータサイズがHTTPレスポンスのバッファサイズを超えなければ，WebクライアントにHTTPレスポンスが書き出されることはありません。出力したデータのサイズが圧縮しきい値を超える前に，HTTPレスポンスをWebクライアントに書き出す必要がある場合は，明示的にレスポンス出力用ストリーム※のflushメソッドを呼び出す必要があります。ただし，出力したデータのサイズが圧縮しきい値を超える前にflushメソッド，またはjavax.servlet.ServletResponseクラスのflushBufferメソッドを呼び出した場合は，出力したデータは圧縮されないでWebクライアントに書き出されます。

注※

レスポンス出力用ストリームとは，次に示すオブジェクトを指します。

javax.servlet. ServletResponseクラスのgetOutputStreamメソッドによって取得したjavax.servlet.ServletOutputStream

javax.servlet. ServletResponseクラスのgetWriterメソッドによって取得したjava.io.PrintWriter

JSPで暗黙的に利用できるjavax.servlet.jsp.JspWriter

(3)　HTTPレスポンスのレスポンスヘッダに関する注意事項

HTTPレスポンス圧縮機能によってHTTPレスポンスのレスポンスボディが圧縮される場合，このHTTPレスポンスのContent-Encodingヘッダにはgzip，VaryヘッダにはAccept-Encodingが指定されます。Content-Lengthヘッダには何も指定されません。

したがって，javax.servlet.ServletResponseクラスのsetContentLengthメソッドを使用する場合とjavax.servlet.http.HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用する場合は，次の点に注意してください。

次のどちらかのAPIを使用してContent-Lengthヘッダ，Content-Encodingヘッダを設定するフィルタを追加している場合は，レスポンス圧縮用フィルタよりもあとに実行されるようにDD（web.xml）で定義してください。

ServletResponseクラスのsetContentLengthメソッド

HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※

HTTPレスポンスのレスポンスボディが圧縮される場合，ServletResponseクラスのsetContentLengthメソッド，およびHttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用しても，HTTPレスポンスのContent-Lengthヘッダは付加されません。Content-Lengthヘッダが付加されていないHTTPレスポンスはWebコンテナによってchunk形式でクライアントに送信されます。

HTTPレスポンスのレスポンスボディが圧縮される場合，HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用してもContent-Encodingヘッダには値が設定されません。レスポンスボディが圧縮される場合は，WebコンテナによってContent-Encodingヘッダにgzipが指定されます。

注※

レスポンスヘッダを追加・変更するAPIとは，javax.servlet.http.HttpServletResponseクラスの次のメソッドを指します。

setHeaderメソッド

addHeaderメソッド

setIntHeaderメソッド

addIntHeaderメソッド

(4)　HTTPレスポンスのデータ出力に関する注意事項

javax.servlet.ServletResponseクラスのgetOutputStreamメソッド，またはgetWriterメソッドによってServletOutputStreamまたはPrintWriterを取得し，HTTPレスポンスを出力する場合は，次の点に注意してください。

ServletOutputStreamまたはPrintWriterを使用して，HTTPレスポンスのバッファにデータを書き出している状態で，ServletResponseのsetContentTypeメソッドを呼び出した場合，圧縮するように指定されたMedia-Typeを持つHTTPレスポンスであっても圧縮されません。
ただし，圧縮するMedia-Typeにアスタリスク（*）が指定されているときは圧縮されます。

Media-Typeを指定してJSPの出力を圧縮するためには，pageディレクティブのcontentType属性を指定するか，またはJSPのバッファを超える前にServletResponseクラスのsetContentTypeメソッドを呼び出す必要があります。

(5)　アプリケーションでHTTPレスポンスを圧縮する場合の注意事項

アプリケーションで圧縮したHTTPレスポンスには，HTTPレスポンス圧縮機能が有効にならないように設定してください。アプリケーションで圧縮したHTTPレスポンスに対して，HTTPレスポンス圧縮機能を有効にした場合の動作は保証できません。

2.10.4　DDでの定義

ここでは，HTTPレスポンス圧縮機能を使用する場合に必要なDDの定義について説明します。

HTTPレスポンス圧縮機能を有効にするためには，WebアプリケーションのDDに，フィルタ定義およびフィルタマッピング定義を追加する必要があります。HTTPレスポンス圧縮機能は，フィルタマッピング定義によってマッピングされたURLパターンを持つリソースに対してリクエストがあった場合にだけ有効となります。

HTTPレスポンス圧縮機能の定義は，web.xmlに指定します。

DDでのHTTPレスポンス圧縮機能の定義について次の表に示します。

表2-40　DDでのHTTPレスポンス圧縮機能の定義

設定項目
指定するタグ
設定内容

フィルタ定義
<filter>タグ内の<filter-name>タグ
追加するフィルタ名称を指定します。設定値は，固定値です。

設定値（固定値）

com.hitachi.software.was.web.ResponseCompressionFilter

<filter>タグ内の<filter-class>タグ
追加するフィルタのクラス名を指定します。設定値は，固定値です。

設定値（固定値）

com.hitachi.software.was.web.ResponseCompressionFilter

URLパターンとHTTPレスポンス圧縮規則のマッピング
<filter-class><init-param>タグ内の<param-name>タグ，<param-value>タグ
URLパターンとHTTPレスポンス圧縮機能のマッピングを指定します。
詳細については，「2.10.4(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）」を参照してください。

HTTPレスポンス圧縮規則
HTTPレスポンスの圧縮規則として，圧縮規則名，Media-Typeと圧縮しきい値を指定します。
詳細については，「2.10.4(2)　HTTPレスポンス圧縮規則」を参照してください。

フィルタマッピング定義
<filter-mapping>タグ内の<filter-name>タグ
フィルタ名称を指定します。設定値は，固定値です。

設定値（固定値）

com.hitachi.software.was.web.ResponseCompressionFilter

<filter-mapping>タグ内の<url-pattern>タグ
URLパターンやサーブレットクラスと，HTTPレスポンス圧縮フィルタのマッピングを指定します。HTTPレスポンス圧縮機能は，フィルタマッピング定義によって，マッピングされたURLパターンを持つリソースに対してリクエストがあった場合だけ有効となります。
設定値は，任意です。

次に示すDDの定義例を基に，DDの定義内容を説明します。

    ：
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /*=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:1000;
    </param-value>
  </init-param>
</filter>
    ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>タグで囲まれた部分がフィルタ定義，<filter-mapping>タグで囲まれた部分がフィルタマッピング定義となります。フィルタ定義の<filter-name>タグおよび<filter-class>タグに指定する値は，次のパッケージ名で固定です。

com.hitachi.software.was.web.ResponseCompressionFilter

次に，DDの<init-param>タグ内に定義する内容を示します。

＜この項の構成＞

(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）

(2)　HTTPレスポンス圧縮規則

(3)　注意事項

(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）

HTTPレスポンス圧縮機能が有効となるURLパターンと，指定したURLパターンに適用するHTTPレスポンス圧縮規則名のマッピングを指定します。

パラメタ指定時の規則およびURLパターンのマッピング規則を示します。

(a)　パラメタ指定時の規則

URLパターンは，大文字と小文字が区別されます。

HTTPレスポンス圧縮規則名は，大文字と小文字が区別されます。

URLパターンとHTTPレスポンス圧縮規則名は，半角のイコール（=）で区切ります。

複数指定する場合は，半角のセミコロン（;）で区切ります。

複数のURLパターンに該当する場合は，先に指定したものが使用されます。

パラメタ値の改行，タブ，スペースは無視されます。

パラメタ値の末尾にある半角のセミコロン（;）は無視されます。

(b)　URLパターンのマッピング規則

url-mappingパラメタに定義するURLパターンには，パス一致，拡張子一致，および完全一致のマッピング規則が適用されます。それぞれのマッピング規則を次に示します。

パス一致
URLパターンとして「/」で始まり「/*」で終わる文字列を指定した場合は，リクエストURLのコンテキストルートからの相対パスがURLパターンの「*」を除く文字列で始まっているときに，一致したとみなされます。また，URLパターンとして「/*」を指定した場合は，すべてのリクエストURLが一致したとみなされます。

（例）

URLパターンが「/jsp/*」では，リクエストURLのコンテキストルートからの相対パスが「/jsp/index.jsp」の場合に一致したとみなされます。

拡張子一致
URLパターンとして「*.」で始まる文字列を指定した場合は，リクエストURLの拡張子とURLパターンの「*.」に続く文字列と同じであるときに，一致したとみなされます。

（例）

URLパターンが「*.jsp」では，リクエストURLのコンテキストルートからの相対パスが「/jsp/index.jsp」の場合に一致したとみなされます。

完全一致
URLパターンとして「/」で始まる上記以外の文字列を指定した場合は，リクエストURLのコンテキストルートからの相対パスがこのURLパターンと完全に同じであるときに，一致したとみなされます。

（例）

URLパターンが「/jsp/index.jsp」では，リクエストURLのコンテキストルートからの相対パスが「/ jsp/index.jsp」の場合に一致したとみなされます。

(2)　HTTPレスポンス圧縮規則

圧縮するHTTPレスポンスのMedia-Typeと圧縮しきい値を指定します。

Media-Type

HTTPレスポンス圧縮機能では，条件として指定したMedia-TypeがHTTPレスポンスに含まれる場合に，HTTPレスポンスを圧縮します。

圧縮しきい値

圧縮しきい値は，100から2,147,483,647までの整数値で指定します。デフォルトの設定では，すべてのMedia-Typeに対して圧縮しきい値「100」が適用されます。

圧縮しきい値とは，HTTPレスポンスボディのサイズによって，HTTPレスポンスを圧縮するかどうかを判定するためのしきい値です。HTTPレスポンス圧縮機能では，HTTPレスポンスボディのサイズが圧縮しきい値に定義したサイズを超える場合に，HTTPレスポンスを圧縮します。

圧縮しきい値を定義することで，HTTPレスポンスのサイズが小さい場合に，HTTPレスポンスの圧縮に掛かる時間が，通信に掛かる時間よりも大きくならないようにします。

圧縮しきい値は，圧縮するリソースの種別と通信回線の速度によって適切なサイズが決まるので，圧縮しきい値に定義するサイズは実測で求め，適切なサイズを定義することをお勧めします。

パラメタ指定時の規則を示します。

Media-Typeにアスタリスク（*）を指定した場合は，すべてのMedia-Typeを表します。ただし，Media-Typeごとの指定がある場合は，Media-Typeごとの指定が優先されます。

Media-Typeは，大文字と小文字が区別されません。

Media-Typeと圧縮しきい値は，半角のコロン（:）で区切ります。

複数指定する場合は半角のセミコロン（;）で区切ります。

同じMedia-Typeを複数指定した場合はあとに指定したものが使用されます。

パラメタ値の改行，タブ，スペースは無視されます。

パラメタ値の末尾にある半角のセミコロン（;）は無視されます。

(3)　注意事項

HTTPレスポンス圧縮フィルタの設定時の注意事項を次に示します。

レスポンス圧縮用フィルタの初期化時に，フィルタの初期化パラメタの妥当性をチェックします。ここで初期化パラメタに定義された値に問題がある場合は，フィルタの初期化処理でエラーとなり，Webアプリケーションは開始しません。

リクエストURLがurl-mappingパラメタに指定したURLパターンに一致しても，レスポンス圧縮用フィルタがマッピングされているURLパターンに一致しない場合は，url-mappingパラメタに指定したレスポンス圧縮規則が適用されることはありません。

レスポンス圧縮フィルタに複数のURLパターンをマッピングする場合は，リクエストURLが同時に複数のURLパターンに一致しないようにフィルタマッピングの定義を記述する必要があります。複数のURLパターンに対して異なるレスポンス圧縮機能を設定する場合は，url-mappingパラメタに複数のURLパターンを指定してください。

メモリセッションフェイルオーバ機能を使用している場合は，セッションフェイルオーバ用フィルタのフィルタマッピングの定義よりも下にレスポンス圧縮フィルタのフィルタマッピングの定義を記述してください。

WebアプリケーションのバージョンがServlet 2.4以降の場合，<filter-mapping>タグの要素，および<dispatcher>タグは指定しないでください。また，<dispatcher>タグで「FORWARD」，「INCLUDE」，「ERROR」を指定した場合，Webアプリケーションの開始時にエラーが発生し，アプリケーションが開始できないので，注意してください。

2.10.5　DDの定義例

ここでは，次に示すそれぞれの場合を例に，HTTPレスポンス圧縮機能を使用するDDの定義例を示します。

HTTPレスポンスのボディサイズで圧縮条件を指定する場合

URLパターンで圧縮条件を指定する場合

HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

圧縮条件を組み合わせて指定する場合

＜この項の構成＞

(1)　HTTPレスポンスのボディサイズで圧縮条件を指定する場合

(2)　URLパターンで圧縮条件を指定する場合

(3)　HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

(4)　圧縮条件を組み合わせて指定する場合

(1)　HTTPレスポンスのボディサイズで圧縮条件を指定する場合

HTTPレスポンスのボディサイズで圧縮条件を指定する場合の定義例を示します。

<web-app>
    ：
<!-- The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /*=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:1000;
    </param-value>
  </init-param>
</filter>
    ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例では，URLパターンが/*のアクセスに対するHTTPレスポンスで，ボディサイズが1,000バイトを超えるものを圧縮します。

(2)　URLパターンで圧縮条件を指定する場合

URLパターンで圧縮条件を指定する場合の定義例を示します。

<web-app>
    ：
<!-- The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /app/dir/*=rule1;
      *.html=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:100;
    </param-value>
  </init-param>
</filter>
    ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/app/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例では，URLパターンが/app/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

HTTPリクエストのURLパターンが/app/dir/*で，ボディサイズが100バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが*.htmlで，ボディサイズが100バイトを超えるHTTPレスポンス

(3)　HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合の定義例を示します。

<web-app>
    ：
<!-- The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /*=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      text/html:500;
      application/pdf:1000;
    </param-value>
  </init-param>
</filter>
    ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例はURLパターンが/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

Media-Typeがtext/htmlでボディサイズが500バイトを超えるHTTPレスポンス

Media-Typeがapplication/pdfでボディサイズが1,000バイトを超えるHTTPレスポンス

(4)　圧縮条件を組み合わせて指定する場合

次に示す例のように，圧縮条件を組み合わせて定義することもできます。

<web-app>
    ：
<!-- The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /app/dir1/*=rule1;
      /app/dir2/*=rule2;
      *.html=rule3;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:500;
      application/pdf:1000;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule2</param-name>
    <param-value>
      application/pdf:2000;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule3</param-name>
    <param-value>
      *:100;
    </param-value>
  </init-param>
</filter>
    ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/app/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例では，URLパターンが/app/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

HTTPリクエストのURLパターンが/app/dir1/*でMedia-Typeがapplication/pdf以外，ボディサイズが500バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが/app/dir1/*でMedia-Typeがapplication/pdf，ボディサイズが1,000バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが/app/dir2/*でMedia-Typeがapplication/pdf，ボディサイズが2,000バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが*.htmlでボディサイズが100バイトを超えるHTTPレスポンス

2.10.6　実行環境での設定（Webアプリケーションの設定）

フィルタリングによるHTTPレスポンスの圧縮を使用する場合，Webアプリケーションの設定が必要です。

なお，Webアプリケーションの設定は，cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。フィルタリングによるHTTPレスポンスの圧縮の定義には，フィルタ属性ファイルおよびWAR属性ファイルを使用します。

フィルタ属性ファイルおよびWAR属性ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「2.10.4　DDでの定義」および「2.10.5　DDの定義例」を参照してください。

2.11　EJBコンテナとの連携

WebコンテナはEJBコンテナと連携して，J2EEサーバとして動作します。ここでは，Enterprise Beanの呼び出しについて説明します。なお，Enterprise Beanを呼び出すには，ビジネスインタフェースを使用することもできます。

この節の構成を次の表に示します。

表2-41　この節の構成（EJBコンテナとの連携）

分類 | タイトル | 参照先
解説 | Enterprise Beanの呼び出し方法 | 2.11.1
実装 | EJBコンテナとの連携のための実装 | 2.11.2
設定 | 実行環境での設定（J2EEサーバの設定） | 2.11.3

注　「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.11.1　Enterprise Beanの呼び出し方法

2.11.2　EJBコンテナとの連携のための実装

2.11.3　実行環境での設定（J2EEサーバの設定）

2.11.1　Enterprise Beanの呼び出し方法

Enterprise Beanの呼び出しは，ルックアップを使用する方法とDIを使用する方法があります。ルックアップを使用する場合，呼び出し方法はCORBAネーミングサービスの切り替え機能を利用するかどうかで異なります。

CORBAネーミングサービスの切り替え機能を利用する場合，または同じEARに含まれるEnterprise Beanを呼び出す場合

呼び出し対象のEnterprise Beanが同一のEARに含まれている場合，次の例に示すようにEnterprise Beanを呼び出します。

呼び出し対象のEnterprise Beanが同一のEARに含まれていない場合でも，CORBAネーミングサービスの切り替え機能を使用して，次に示すようにEnterprise Beanを呼び出すことができます。CORBAネーミングサービスの切り替え機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.8　CORBAネーミングサービスの切り替え」を参照してください。

例：

Context ctx = new InitialContext();
Object o = ctx.lookup("java:comp/env/ejb/cart");
CartHome h = (CartHome)PortableRemoteObject.narrow(o, CartHome.class);
Cart c = h.create();
c.call();

CORBAネーミングサービスの切り替え機能を利用しないで別EARに含まれるEnterprise Beanを呼び出す場合

CORBAネーミングサービスの切り替え機能を利用しない場合で，呼び出し対象のEnterprise Beanが別のEARに含まれているとき，次の例に示すようにEnterprise Beanを呼び出します。例を次に示します。

例：

Context ctx = new InitialContext();
Object o =
ctx.lookup("HITACHI_EJB/SERVERS/MyServer/EJB/APName/Cart");
CartHome h = (CartHome)PortableRemoteObject.narrow(o, CartHome.class);
Cart c = h.create();
c.call();

2.11.2　EJBコンテナとの連携のための実装

Enterprise Beanの呼び出しを利用する場合，該当Webアプリケーションをデプロイする前に，J2EEサーバからRMI-IIOPのスタブ（stubs.jar），およびRMI-IIOPインタフェースを取得し，WebアプリケーションのWEB-INF/libディレクトリに格納します。

また，複数のRMI-IIOPのスタブ（stubs.jar）を格納する場合，名前の重複を避けるためにWEB-INF/libディレクトリに格納する前に適当な名前に変更してください。

なお，RMI-IIOPのスタブについては，J2EEサーバのダイナミッククラスローディングを利用できます。ダイナミッククラスローディングの詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.3　ダイナミッククラスローディング」を参照してください。

WARからEJBを呼び出す場合は，WARのDDにejb-refを定義する必要があります。ただし，アノテーションを使用して参照を定義している場合は，web.xmlに参照を定義する必要はありません。また，WARから同一アプリケーション内のEJBを呼び出す場合は，WARに，スタブおよびリモートインタフェースを含める必要はありません。

なお，WARから別アプリケーションで動作するEJBを呼び出す場合，または別J2EEサーバで動作するEJBを呼び出す場合，リモートインタフェースとスタブが必要になります。WARにリモートインタフェースを含めて，実行環境でJ2EEアプリケーションの開始時にスタブが自動生成されるように設定してください。実行環境での設定については，「2.11.3　実行環境での設定（J2EEサーバの設定）」を参照してください。

2.11.3　実行環境での設定（J2EEサーバの設定）

J2EEサーバの設定は，簡易構築定義ファイルで実施します。EJBコンテナとの連携の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のejbserver.deploy.stub.generation.scopeに指定します。このパラメタでは，別アプリケーションのEJBをリモートインタフェースで呼び出すためのスタブを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

2.12　データベースとの接続

Webコンテナを利用している場合，Java EEサービスのリソースアダプタを使用して，データベースにアクセスできます。なお，リソースアダプタを通じてデータベースにアクセスする場合は，DB Connectorを使用します。データベースへのアクセス時には，次に示す機能を利用できます。

JDBCコネクションプーリング

JDBCコネクションシェアリング

分散トランザクション

データベースとの接続の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6　データベースへの接続」を参照してください。データベース接続するためのリソースアダプタの設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.9　実行環境での設定（リソースアダプタでの設定）」を参照してください。

2.13　Webコンテナによるスレッドの作成

この節では，Webコンテナによるスレッドの作成について説明します。

この節の構成を次の表に示します。

表2-42　この節の構成（Webコンテナによるスレッドの作成）

分類 | タイトル | 参照先
解説 | 作成するスレッドの種類と数 | 2.13.1
作成するスレッドの総数 | 2.13.2

注　「実装」，「設定」，「運用」および「注意事項」について，この機能固有の説明はありません。

Webコンテナでは，Webサーバ連携のためのスレッド，Webアプリケーションのためのスレッドなどを作成します。これらのスレッドに対して，システムのリソースが十分であるか検討してください。

なお，アプリケーションサーバでは，サーブレットおよびJSPからスレッド（ユーザスレッド）を作成して使用することもできます。ユーザスレッドで使用できるアプリケーションサーバの機能の詳細については，「2.14　ユーザスレッドの使用」を参照してください。

ここでは，Webコンテナが作成するスレッドについて説明します。

＜この節の構成＞

2.13.1　作成するスレッドの種類と数

2.13.2　作成するスレッドの総数

2.13.1　作成するスレッドの種類と数

Webコンテナが作成するスレッドを次の表に示します。

表2-43　Webコンテナが作成するスレッド

スレッドの分類 | 参照先
Webコンテナの簡易Webサーバ用のスレッド | (1)
Webサーバ連携機能を使用するためのスレッド※1 | (2)
インプロセスHTTPサーバを使用するためのスレッド※2 | (3)
Webアプリケーションのためのスレッド | (4)
管理用コンテキストのためのスレッド | (5)
レスポンス送信時のタイムアウトを監視するためのスレッド | (6)

注※1

Webサーバ連携機能を使用する場合に作成されるスレッドです。

注※2

インプロセスHTTPサーバを使用する場合に作成されるスレッドです。

＜この項の構成＞

(1)　Webコンテナの簡易Webサーバ用のスレッド（必須）

(2)　Webサーバ連携機能を使用するためのスレッド

(3)　インプロセスHTTPサーバを使用するためのスレッド

(4)　Webアプリケーションのためのスレッド

(5)　管理用コンテキストのためのスレッド

(6)　レスポンス送信時のタイムアウトを監視するためのスレッド

(1)　Webコンテナの簡易Webサーバ用のスレッド（必須）

簡易Webサーバ用のスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

TCPのコネクション接続要求を受信するスレッド，および受信したリクエストの処理用スレッドを作成します。

スレッドの数

TCPのコネクション接続要求を受信するスレッドは，1スレッドです。簡易Webサーバが受信したリクエストの処理用スレッドは，最小5スレッド，最大100スレッドです。

リクエスト処理用スレッドは，起動時に5スレッド作成し，同時実行スレッド数が起動済みスレッド数を超えた場合，100スレッドまで作成されます。

なお，Webコンテナの簡易Webサーバは，必ず使用します。

(2)　Webサーバ連携機能を使用するためのスレッド

Webサーバとの連携に使用するスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

リダイレクタからのコネクション接続要求を受信するスレッド，およびリダイレクタから受信したリクエストの処理用スレッドを作成します。

スレッドの数

リダイレクタからのコネクション接続要求を受信するスレッドは，1スレッドです。リダイレクタから受信したリクエストの処理用スレッドは，WebサーバとWebコンテナとのコネクション数分スレッドを作成します。

リダイレクタから受信したリクエスト処理用スレッドは，起動時に，usrconf.propertiesのwebserver.connector.ajp13.max_threadsキーに指定した数分作成します（webserver.connector.ajp13.max_threadsキーのデフォルトは10）。

(3)　インプロセスHTTPサーバを使用するためのスレッド

インプロセスHTTPサーバ用のスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

リクエスト処理スレッド，およびリクエスト処理スレッド数の監視用スレッドを作成します。

スレッドの数

Webクライアントまたはプロキシサーバからの接続数と同じ数のリクエスト処理スレッドを作成します。リクエスト処理スレッドは，J2EEサーバ起動時に，usrconf.propertiesのwebserver.connector.inprocess_http.init_threadsキーに指定した数分作成します（webserver.connector.inprocess_http.init_threadsキーのデフォルトは10）。同時実行スレッド数がJ2EEサーバ起動時に作成したスレッド数を超えた場合，Webクライアントからの接続数の最大値を上限として，リクエスト処理スレッドを作成します（webserver.connector.inprocess_http.max_connectionsキーのデフォルトは100）。

また，リクエスト処理スレッド数の監視用スレッドを1スレッド作成します。

(4)　Webアプリケーションのためのスレッド

Webアプリケーション単位に，セッションの有効期限監視スレッドを作成します。最小1スレッド，最大3スレッドです。

(5)　管理用コンテキストのためのスレッド

管理用コンテキストを二つ生成するため，2スレッド作成します。

(6)　レスポンス送信時のタイムアウトを監視するためのスレッド

レスポンス送信時のタイムアウトを有効にすると，送信タイムアウトを監視するためのスレッドを1スレッド作成します。

2.13.2　作成するスレッドの総数

Webコンテナがデフォルトの設定でプロセス起動時に作成するスレッドの総数を，Webサーバと連携する場合と，インプロセスHTTPサーバを使用する場合に分けて示します。ただし，この数値にはWebコンテナ以外のスレッド，およびJavaVMが作成するスレッドは含まれていません。

＜この項の構成＞

(1)　Webサーバと連携する場合

(2)　インプロセスHTTPサーバを使用する場合

(1)　Webサーバと連携する場合

Webサーバと連携する場合の作成するスレッドの総数について説明します。また，Webサーバ連携に使用するスレッド数についても説明します。

(a)　作成するスレッドの総数

作成するスレッドの総数は，レスポンス送信時のタイムアウトを設定しているかどうかによって異なります。

レスポンス送信時のタイムアウトを設定しているとき

スレッド総数=A＋B＋C＋D＋E

レスポンス送信時のタイムアウトを設定していないとき

スレッド総数=A＋B＋C＋D

（凡例）

A：Webコンテナの簡易Webサーバ用のスレッド数

B：Webサーバとの連携に使用するスレッド数

C：Webアプリケーション単位のスレッド数

D：管理用コンテキストのスレッド数

E：レスポンス送信時のタイムアウトを監視するためのスレッド数

このため，Webサーバ連携の場合のプロセス起動時のスレッド総数は次のようになります。

レスポンス送信時のタイムアウトを設定しているときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2＋1

=20＋Webアプリケーション数

レスポンス送信時のタイムアウトを設定していないときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2

=19＋Webアプリケーション数

プロセス起動後，Webサーバとのコネクション数，簡易Webサーバの同時実行数によってスレッド数が増加します。

(b)　Webサーバとの連携に使用するスレッド数

Webサーバ連携機能を使用する場合のリクエスト処理スレッドは，Webコンテナ起動時にusrconf.propertiesのwebserver.connector.ajp13.max_threadsキーに指定した数分作成し，以降はリダイレクタからのコネクション数分作成します。そのため，リクエスト処理スレッド数の最大数はWebサーバの最大接続数に依存します。

なお，リダイレクタ－Webコンテナ間のコネクションがタイムアウトによって切断された場合は，Webサーバの最大接続数以上にリクエスト処理スレッドが作成されます。リクエスト処理用スレッド数の最大値を算出する式を次に示します。

Hitachi Web Serverを使用している場合
リクエスト処理スレッド数の最大値＝A＋B

（凡例）

A：日立WebサーバのThreadsPerChildディレクティブの設定値

B：リダイレクタ－Webコンテナ間のコネクションがタイムアウトによって切断されたときの，実行中のリクエスト数（最大値はwebserver.connector.ajp13.max_threadsの設定値）

Microsoft IISを使用している場合
リクエスト処理スレッド数の最大値＝A×B＋C

（凡例）

A：Microsoft IISのスレッド数

B：Microsoft IISのプロセス数

C：リダイレクタ－Webコンテナ間のコネクションがタイムアウトによって切断されたときの，実行中のリクエスト数（最大値はwebserver.connector.ajp13.max_threadsの設定値）

(2)　インプロセスHTTPサーバを使用する場合

作成するスレッドの総数は，レスポンス送信時のタイムアウトを設定しているかどうかによって異なります。

レスポンス送信時のタイムアウトを設定しているとき

スレッド総数=A＋B＋C＋D＋E

レスポンス送信時のタイムアウトを設定していないとき

スレッド総数=A＋B＋C＋D

（凡例）

A：Webコンテナの簡易Webサーバを使用する場合のスレッド数

B：インプロセスHTTPサーバを使用する場合のスレッド数

C：Webアプリケーション単位のスレッド数

D：管理用コンテキストのスレッド数

E：レスポンス送信時のタイムアウトを監視するためのスレッド数

このため，インプロセスHTTPサーバを使用する場合のプロセス起動時のスレッド総数は次のようになります。

レスポンス送信時のタイムアウトを設定しているときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2＋1

=20＋Webアプリケーション数

レスポンス送信時のタイムアウトを設定していないときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2

=19＋Webアプリケーション数

J2EEサーバ起動後，Webクライアントとのコネクション数，簡易Webサーバの同時実行数によってスレッド数が増加します。

2.14　ユーザスレッドの使用

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

この節の構成を次の表に示します。

表2-44　この節の構成（ユーザスレッドの使用）

分類 | タイトル | 参照先
解説 | ユーザスレッドでの機能の使用可否 | 2.14.1
設定 | ユーザスレッド生成のための権限の設定 | 2.14.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.14.1　ユーザスレッドでの機能の使用可否

2.14.2　ユーザスレッド生成のための権限の設定

2.14.1　ユーザスレッドでの機能の使用可否

ここでは，ユーザスレッドで使用できるアプリケーションサーバの機能について説明します。ユーザスレッドの使用方法については，「5.1.1(15)　ユーザスレッドの使用方法」を参照してください。

アプリケーションサーバで提供される各機能について，ユーザスレッドで使用できるかどうかを次の表に示します。

表2-45　ユーザスレッドでの機能の使用可否

機能名 | 使用可否 | 参照先
サーブレットAPIの利用 | △ | (1)
Enterprise Beanの呼び出し | × | －
ネーミングサービス | ○ | (2)
リソース接続 | △ | (3)
トランザクションサービス | △
統合ユーザ管理 | × | －
ログ運用および障害検知 | ○ | (4)
J2EEアプリケーション運用 | △ | (5)
コンテナ拡張ライブラリの利用 | ○ | (6)

（凡例）○：使用できる　△：一部の機能が使用できない　×：使用できない　－：該当なし

ユーザスレッドで使用できる機能をさらに詳細機能に分類し，各機能についてサーブレット/JSP，およびユーザスレッドで使用できるかどうかを示します。また，ユーザスレッドで使用する場合の注意事項についても示します。

＜この項の構成＞

(1)　サーブレットAPI

(2)　ネーミングサービス

(3)　リソース接続およびトランザクションサービス

(4)　ログ運用および障害検知

(5)　J2EEアプリケーション運用

(6)　コンテナ拡張ライブラリ

(1)　サーブレットAPI

サーブレットAPIをユーザスレッドで使用する場合，リクエストオブジェクトおよびレスポンスオブジェクトは使用できません。リクエスト処理スレッドでだけ使用してください。詳細は，サーブレット仕様書のThread Safetyの項を参照してください。

(2)　ネーミングサービス

ネーミングサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2-46　ネーミングサービスの機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
JNDIのルックアップ | リソースアダプタ | DB Connector | ○ | ○
DB Connector for Cosminexus RMとCosminexus RM | ○ | ○
TP1/Message Queue-Access | ○ | ○
uCosminexus TP1 Connector | ○ | ○
Java Mail | ○ | ○
JavaBeansリソース | ○ | ○
ユーザトランザクション | ○ | ○

（凡例）○：使用できる

ネーミングサービスを使用する場合，ユーザスレッドの実行中にアプリケーションを停止しないでください。

(3)　リソース接続およびトランザクションサービス

リソース接続およびトランザクションサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2-47　リソース接続およびトランザクション管理の機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
コネクションプーリング | DB Connectorによるコネクションプーリング | ○ | ○
DB Connector for Cosminexus RMとCosminexus RMによるコネクションプーリング | ○ | ○
uCosminexus TP1 Connectorとのコネクションプーリング | ○ | ○
TP1/Message Queue - Accessとのコネクションプーリング | ○ | ○
SMTPサーバとのコネクションプーリング | × | ×
コネクションプールのウォーミングアップ | ○ | ○
コネクション数調節 | ○ | ○
コネクションシェアリング | ○ | ○
コネクションアソシエーション | ○ | ○
ステートメントプーリング（DB Connector） | ○ | ○
ライトトランザクション | ○ | ○
インプロセストランザクションサービス | ○ | ○
DataSourceオブジェクトのキャッシング | ○ | ○
DB Connectorのコンテナ管理でのサインオンの最適化 | ○ | ○
受信バッファのプーリング | ○ | ○
コネクションの障害検知 | DB Connectorによる障害検知 | ○ | ○
DB Connector for Cosminexus RMとCosminexus RMによる障害検知 | ○ | ○
uCosminexus TP1 Connectorとのコネクション障害検知 | × | ×
TP1/Message Queue - Accessとのコネクション障害検知 | × | ×
SMTPサーバとのコネクション障害検知 | × | ×
コネクション枯渇時のコネクション取得待ち | ○ | ○
コネクションの取得リトライ | DB Connectorによるコネクション取得リトライ | ○ | ○
DB Connector for Cosminexus RMとCosminexus RMによるコネクション取得リトライ | ○ | ○
uCosminexus TP1 Connectorとのコネクション取得リトライ | ○ | ○
TP1/Message Queue - Accessとのコネクション取得リトライ | ○ | ○
SMTPサーバとのコネクション取得リトライ | × | ×
コネクションプールクリア | ○ | ○
コネクションのクローズ・解放 | コネクション自動クローズ（Webコンテナ） | ○ | ×
コネクションスイーパ | ○ | ○
トランザクションタイムアウト | ○ | ○
トランザクションリカバリ | ○ | ○
トランザクションの自動決着※ | ○ | ×
障害調査用SQLの出力 | ○ | ○
コネクションプールのクラスタ化 | ○ | ○

（凡例）○：使用できる　×：使用できない

注※

サーブレットのメソッドからリターンするとき，未決着のトランザクションをロールバックする機能です。

ユーザスレッドでリソース接続およびトランザクションサービスを使用する場合の注意事項を示します。

SingleThreadModelインタフェースを実装したサーブレットで生成したスレッド上で，トランザクションの開始と決着，およびコネクションの取得と解放はできません。

スレッド生成時にトランザクションを引き継ぐことはできません。

トランザクションは，同じスレッド上で開始または決着してください。

スレッド間でコネクションを渡すことはできません。コネクションを使用すると，動作不正となります。

ユーザスレッドでコネクションを取得した場合，コネクションを取得したスレッド上で確実にコネクションをクローズしてください。

(4)　ログ運用および障害検知

ログ運用および障害検知として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2-48　ログ運用および障害検知の機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
Managementイベントによる処理の自動実行 | ○ | ○
JP1イベントによるシステムの監視 | ○ | ○
ユーザログ出力 | ○ | ○
性能解析トレース | ○ | ○
CTMの稼働情報の監視 | ○ | ○

（凡例）○：使用できる

(5)　J2EEアプリケーション運用

J2EEアプリケーション運用機能として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2-49　J2EEアプリケーション運用機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
Webコンテナでの同時実行スレッド数の制御 | ○ | ×
スケジュールキュー単位の同時実行数の動的変更 | ○ | ○
J2EEアプリケーションの実行時間監視 | メソッドタイムアウト機能 | ○ | ×
メソッドキャンセル機能 | ○ | ×
J2EEアプリケーションの停止 | 通常停止 | ○ | ○※1
強制停止 | ○ | ○※1
J2EEアプリケーションの入れ替え | リデプロイ機能による入れ替え | ○ | ○※2
リロード機能による入れ替え | ○ | ○
テストモードでのJ2EEアプリケーションの実行 | ○ | ×

（凡例）○：使用できる　×：使用できない

注※1

コンテナでは，ユーザスレッドを停止しません。

注※2

開始状態のJ2EEアプリケーションを入れ替えた場合，コンテナではユーザスレッドを停止しません。

(6)　コンテナ拡張ライブラリ

コンテナ拡張ライブラリは，サーブレット/JSPおよびユーザスレッドのどちらでも使用できます。

2.14.2　ユーザスレッド生成のための権限の設定

ユーザがプログラムの中で明示して生成するスレッド（ユーザスレッド）を生成するためには，対象となるサーブレットやJSPにスレッドの生成権限を与える必要があります。ここでは，ユーザスレッドを生成するための権限の設定について説明します。

ユーザスレッドを生成するには，server.policyに次の記述があるかどうかを確認してください。この定義によって，ユーザスレッドを生成するための権限が与えられます。

permission java.lang.RuntimePermission "modifyThread";
permission java.lang.RuntimePermission "modifyThreadGroup";

なお，server.policyは，Smart Composer機能のコマンドでシステムを構築したあとに設定してください。server.policyの記述例を次に示します。

：
//
// Grant permissions to JSP/Servlet
//
grant codeBase "file:${ejbserver.http.root}/web/${ejbserver.serverName}/-" {
permission java.lang.RuntimePermission "loadLibrary.*";
permission java.lang.RuntimePermission "queuePrintJob";
permission java.lang.RuntimePermission "modifyThread";
permission java.lang.RuntimePermission "modifyThreadGroup";
permission java.net.SocketPermission "*", "connect";
permission java.io.FilePermission "<<ALL FILES>>", "read, write";
permission java.util.PropertyPermission "*", "read";
permission javax.security.auth.AuthPermission "getSubject";
permission javax.security.auth.AuthPermission "createLoginContext.*";
};
：

2.15　同時実行スレッド数の制御の概要

Webコンテナでは，マルチスレッドでサーブレットのリクエストを処理します。このとき，同時に実行できるスレッド数に上限を設定できます。これによって，スラッシングなどによるパフォーマンスの低下を防止できます。また，適切なスレッド数を設定することで，アクセス状況に従ったパフォーマンスのチューニングができます。

この節では，同時に実行するスレッド数を制御するための設定について説明します。

この節の構成を次の表に示します。

表2-50　この節の構成（同時実行スレッド数の制御）

分類 | タイトル | 参照先
解説 | スレッド数を制御する単位 | 2.15.1
同時実行スレッド数制御のパラメタ | 2.15.2
静的コンテンツやリクエストのエラー処理に使用されるスレッド数 | 2.15.3

注　「実装」，「設定」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.15.1　スレッド数を制御する単位

2.15.2　同時実行スレッド数制御のパラメタ

2.15.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

2.15.1　スレッド数を制御する単位

同時に実行するスレッド数を制御するには，Webコンテナ単位で制御する方法，Webアプリケーション単位で制御する方法，およびURLグループ単位で制御する方法の3種類あります。

Webコンテナ単位での同時実行スレッド数制御
Webコンテナ上のWebアプリケーション全体で，同時にリクエストを処理するスレッド数を設定します。詳細については「2.16　Webコンテナ単位での同時実行スレッド数の制御」を参照してください。

Webアプリケーション単位での同時実行スレッド数制御
Webコンテナ上のWebアプリケーションごとに，同時にリクエストを処理するスレッド数を設定します。Webコンテナ単位での同時実行スレッド数制御より細かい単位でスレッド数を制御できます。詳細については，「2.17　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

URLグループ単位での同時実行スレッド数制御
Webアプリケーション内のサーブレットやJavaBeansなどの業務ロジックに対応するURLごとに，同時にリクエストを処理するスレッド数を設定します。特定のURLへのリクエストを処理する業務ロジックをURLグループといいます。URLグループ単位で，同時実行スレッド数を制御するので，Webアプリケーション単位の制御より細かい単位でスレッド数を制御できます。詳細については，「2.18　URLグループ単位での同時実行スレッド数の制御」を参照してください。

それぞれの制御単位の関係について次の図に示します。

図2-16　同時実行スレッド数制御の単位の関係

図に示すように，同時実行スレッド数制御のいちばん大きな単位は，Webコンテナ単位となります。Webコンテナ内のWebアプリケーションごとにスレッド数を制御する場合はWebアプリケーション単位で設定します。さらに，Webアプリケーション内のURLグループごとにスレッド数を制御する場合はURLグループ単位で設定します。スレッド数制御の最小単位はURLグループ単位となります。

スレッド数の制御には包含関係があるので，Webアプリケーション単位でスレッド数を制御する場合はWebコンテナ単位での設定も必要になります。また，URLグループ単位でスレッド数を制御する場合は，Webコンテナ単位およびWebアプリケーション単位での設定も必要になります。

2.15.2　同時実行スレッド数制御のパラメタ

同時実行スレッド数制御をする場合，最大同時実行スレッド数，占有スレッド数，実行待ちキューサイズなどのパラメタでスレッド数を制御します。

ここでは，スレッド数を制御するための主なパラメタについて説明します。

＜この項の構成＞

(1)　最大同時実行スレッド数

(2)　占有スレッド数

(3)　実行待ちキューサイズ

(4)　共有スレッド数

(5)　共有スレッド数の算出のしかた

(1)　最大同時実行スレッド数

最大同時実行スレッド数とは，利用できる全体のスレッド数のうち，同時実行スレッド数制御の対象となるリクエストを最大で同時に実行できるスレッド数です。

最大同時実行スレッド数は，Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位で設定します。

(2)　占有スレッド数

占有スレッド数とは，利用できる全体のスレッドのうち，同時実行スレッド数制御の対象となるリクエストを確実に実行できるスレッド数です。Webアプリケーション単位，およびURLグループ単位で設定することで，Webアプリケーションごと，またはURLグループごとにスレッド数を最低限確保できます。

(3)　実行待ちキューサイズ

同時実行スレッド数制御の対象となるリクエストが，同時実行スレッド数の上限に達した場合に，リクエストが入るキューサイズを指定できます。キューサイズには，キューに格納するリクエストの個数を指定します。

実行待ちキューにリクエストが格納される条件を次に示します。

同時実行スレッド数＜最大同時実行スレッド数で，かつ同時実行スレッド数≧占有スレッド数の場合に，使用できる共有スレッド数がないとき

同時実行スレッド数≧最大同時実行スレッド数の場合

なお，実行待ちキューに空きがない場合は，リクエストは処理されないで，クライアントにはエラーが返ります。

実行待ちキューサイズは，Webアプリケーション単位，およびURLグループ単位で設定できます。

(4)　共有スレッド数

共有スレッド数とは，利用できるスレッドのうち，占有されないスレッド数です。共有スレッド数には，Webコンテナの共有スレッド数と，Webアプリケーションの共有スレッド数があります。

Webコンテナの共有スレッド数
Webコンテナの共有スレッド数とは，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有するスレッド数です。

Webアプリケーションの共有スレッド数
Webアプリケーションの共有スレッド数とは，Webアプリケーションに含まれるすべての処理で共有するスレッド数です。

なお，共有スレッド数は，最大同時実行スレッド数と占有スレッド数から導き出します。

共有スレッド数の算出のしかたについては，「(5)　共有スレッド数の算出のしかた」を参照してください。

(5)　共有スレッド数の算出のしかた

ここでは，Webコンテナの共有スレッド数と，Webアプリケーションの共有スレッド数の算出のしかたについて説明します。なお，Webアプリケーション単位での同時実行スレッド数制御の設定をしている場合の，Webアプリケーションの共有スレッド数は，URLグループ単位の同時実行スレッド数制御を設定しているかどうかで異なります。

また，URLグループには共有スレッド数はありません。Webアプリケーション内にURLグループ単位の同時実行スレッド数制御を設定している場合は，Webアプリケーション単位の共有スレッド数を使用します。

Webコンテナの共有スレッド数
Webコンテナ上に，占有スレッド数を設定したWebアプリケーションがある場合の共有スレッド数は，次のとおりです。

Webコンテナの共有スレッドの総数＝

Webコンテナの最大同時実行スレッド数－Webアプリケーション単位の占有スレッド数の合計※

注※　WebコンテナにデプロイされているすべてのWebアプリケーションに設定されている，占有スレッド数の合計となります。

各Webアプリケーションに設定した占有スレッド数は，Webアプリケーションで最低限確保するためのスレッド数です。このスレッド数は，ほかのWebアプリケーションのリクエスト処理には使用されません。

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定している場合）

Webアプリケーションの共有スレッド数＝

Webアプリケーション単位の最大同時実行スレッド数－URLグループ単位の占有スレッド数の合計※

注※　Webアプリケーション内に設定されているすべてのURLグループの占有スレッド数の合計です。

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定していない場合）

Webアプリケーションの共有スレッド数＝Webアプリケーション単位の最大同時実行スレッド数

同時実行スレッド数が，次の図に示すとおり設定されている場合の，WebコンテナおよびWebアプリケーションの共有スレッド数の算出例を説明します。

図2-17　共有スレッド数の算出例

Webコンテナの共有スレッド数＝A－（Bの合計）
この図の場合，Webコンテナの共有スレッド数は7－（2＋0）で，5になります。

Webアプリケーション1の共有スレッド数＝C－（Dの合計）
Webアプリケーション1には，URLグループ単位の占有スレッド数が指定されています。この図では，共有スレッド数は3－（2＋0）で，1になります。

Webアプリケーション2の共有スレッド数＝Webコンテナの共有スレッド数
Webアプリケーション2には，同時実行スレッド数制御の設定はありません。このため，Webアプリケーション2の共有スレッド数は，Webコンテナの共有スレッド数が適用されます。この図では，共有スレッド数は5になります。

Webアプリケーション3の共有スレッド数＝最大同時実行スレッド数
Webアプリケーション3には，URLグループ単位の占有スレッド数が指定されていません。このため，Webアプリケーション3の共有スレッド数はWebアプリケーション3の最大同時実行スレッド数が適用されます。この図では，共有スレッド数は2になります。

2.15.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

Webサーバの最大同時接続数は，Webコンテナでのリクエスト処理のほかに，Webサーバ上に配置された静的コンテンツの処理，およびWebコンテナのリクエストを送信し，同時実行スレッド数と実行待ちキューを超えたリクエストのエラー処理に使用されます。静的コンテンツの処理および実行待ちキューを超えたリクエストのエラー処理に使用されるスレッド数は，次のとおりです。

静的コンテンツやリクエストのエラー処理に使用されるスレッド数＝

Webサーバの最大同時接続数－（Webコンテナ単位の最大同時実行スレッド数＋Webアプリケーション単位，URLグループ単位およびデフォルトの実行待ちキューサイズの合計）

なお，デフォルトの設定では静的コンテンツに使用されるスレッド数は割り当てられていません。静的コンテンツの処理に使用するスレッド数を確保する場合は，上記の式を満たすようにWebアプリケーション単位，URLグループ単位およびデフォルトの実行待ちキューサイズに適切な値を設定してください。

2.16　Webコンテナ単位での同時実行スレッド数の制御

この節では，Webコンテナ単位での同時実行スレッド数の制御について説明します。

この節の構成を次の表に示します。

表2-51　この節の構成（Webコンテナ単位での同時実行スレッド数の制御）

分類 | タイトル | 参照先
解説 | 同時実行スレッド数の制御の仕組み（Webコンテナ単位） | 2.16.1
設定 | 実行環境での設定（J2EEサーバの設定） | 2.16.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.16.1　同時実行スレッド数の制御の仕組み（Webコンテナ単位）

2.16.2　実行環境での設定（J2EEサーバの設定）

2.16.1　同時実行スレッド数の制御の仕組み（Webコンテナ単位）

Webコンテナ単位での同時実行スレッド数の制御の仕組みについて，次の図で説明します。

図2-18　Webコンテナ単位での同時実行スレッド数制御

例えば，Webコンテナに二つのWebアプリケーションがデプロイされていて，同時実行スレッド数に「5」を設定している場合，二つのWebアプリケーションで同時に実行できるスレッド数は5となります。

Webコンテナ単位に同時実行スレッド数を設定することで，Webコンテナにデプロイされた複数のWebアプリケーションのうち，一つのWebアプリケーションにアクセスが集中した場合でも，アクセスが集中しているWebアプリケーションにスレッドを割り当てることができます。この仕組みについて次の図で説明します。

図2-19　アクセスが集中したときのスレッドの扱い（Webコンテナ単位の場合）

図のように，WebコンテナにWebアプリケーションが二つデプロイされていて，同時実行スレッド数に「5」が設定されている場合に，Webアプリケーション1にリクエストが集中すると，5スレッドすべてがWebアプリケーション1に割り当てられます。

一方，Webアプリケーション2に対するリクエストは，Webアプリケーション1のリクエスト処理が完了するまで，Webコンテナ単位の実行待ちキューにためられます。なお，Webコンテナ単位の実行待ちキューにためられたリクエストは，リクエスト処理の完了後，順次実行されます。

2.16.2　実行環境での設定（J2EEサーバの設定）

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナ単位での同時実行スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のどちらかのパラメタを指定します。

webserver.connector.ajp13.max_threads
Webコンテナ全体の最大同時実行スレッド数を指定します。このパラメタはWebサーバ連携の場合に指定します。

webserver.connector.inprocess_http.max_execute_threads
Webコンテナ全体の最大同時実行スレッド数を指定します。このパラメタはインプロセスHTTPサーバを使用する場合に指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

2.17　Webアプリケーション単位での同時実行スレッド数の制御

この節では，Webアプリケーション単位での同時実行スレッド数の制御について説明します。

Webアプリケーション単位でスレッド数を制御するときには，Webコンテナ単位でのスレッド数制御も同時に設定する必要があります。「2.16　Webコンテナ単位での同時実行スレッド数の制御」もあわせて参照してください。

この節の構成を次の表に示します。

表2-52　この節の構成（Webアプリケーション単位での同時実行スレッド数の制御）

分類 | タイトル | 参照先
解説 | 同時実行スレッド数の制御の仕組み（Webアプリケーション単位） | 2.17.1
同時実行スレッド数の制御に必要なパラメタ（Webアプリケーション単位） | 2.17.2
同時実行スレッド数設定の指針（Webアプリケーション単位） | 2.17.3
実装 | cosminexus.xmlでの定義 | 2.17.4
設定 | 実行環境での設定 | 2.17.5
同時実行スレッド数および実行待ちキューサイズの設定例（Webアプリケーション単位） | 2.17.6
注意事項 | Webアプリケーション単位での同時実行スレッド数制御についての注意事項 | 2.17.7

注　「運用」について，この機能固有の説明はありません。

＜この節の構成＞

2.17.1　同時実行スレッド数の制御の仕組み（Webアプリケーション単位）

2.17.2　同時実行スレッド数の制御に必要なパラメタ（Webアプリケーション単位）

2.17.3　同時実行スレッド数設定の指針（Webアプリケーション単位）

2.17.4　cosminexus.xmlでの定義

2.17.5　実行環境での設定

2.17.6　同時実行スレッド数および実行待ちキューサイズの設定例（Webアプリケーション単位）

2.17.7　Webアプリケーション単位での同時実行スレッド数制御についての注意事項

2.17.1　同時実行スレッド数の制御の仕組み（Webアプリケーション単位）

Webコンテナ単位より細かい粒度で同時実行スレッド数を制御したい場合，Webアプリケーション単位で同時実行スレッド数を制御します。

Webアプリケーション単位で同時実行スレッド数を設定することで，Webアプリケーションごとの同時実行スレッド数に上限が設けられます。これによって，特定のWebアプリケーションへのリクエストが増大した場合に，そのWebアプリケーションがWebコンテナ全体の処理能力を占有するのを防ぎ，また，ほかの業務も滞りなく実行できるようになります。

なお，Webアプリケーション単位での同時実行スレッド数の設定の指針については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.3.4　Webアプリケーションの同時実行数を制御する」を参照してください。また，Webコンテナ単位での設定パラメタについては，「2.16.2　実行環境での設定（J2EEサーバの設定）」を参照してください。

2.17.2　同時実行スレッド数の制御に必要なパラメタ（Webアプリケーション単位）

Webアプリケーション単位でスレッド数を制御する場合に必要なパラメタについての概要を次に示します。

Webコンテナ単位の同時実行スレッド数制御の設定

Webコンテナ単位の最大同時実行スレッド数を設定します。なお，ここで設定した最大同時実行スレッド数は，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有します。

Webアプリケーション単位の同時実行スレッド数制御の設定

同時実行スレッド数を制御したいWebアプリケーションに対して，次に示すパラメタを設定します。

最大同時実行スレッド数
Webアプリケーションで最大で幾つのスレッドを同時に実行できるかを設定します。

占有スレッド数
Webアプリケーションの占有スレッド数を設定します。

Webアプリケーション単位の実行待ちキューサイズ
Webアプリケーションの実行待ちキューサイズを設定します。

デフォルトの実行待ちキューサイズ
Webアプリケーション単位の同時実行スレッド数制御を設定していないWebアプリケーションのための，実行待ちキューサイズを設定します。

Webアプリケーション単位の同時実行スレッド数制御の設定に必要なパラメタの詳細について説明します。

＜この項の構成＞

(1)　Webアプリケーションの最大同時実行スレッド数

(2)　Webアプリケーションの占有スレッド数

(3)　Webアプリケーションの実行待ちキューサイズ

(1)　Webアプリケーションの最大同時実行スレッド数

Webアプリケーション単位の最大同時実行スレッド数は，値を設定している場合は，その数が適用されます。ここでは，同時実行スレッド数を設定していないWebアプリケーションの最大同時実行スレッド数，および占有スレッド数を設定していないWebアプリケーションでの最大同時実行スレッド数の考え方について説明します。

(a)　同時実行スレッド数制御を設定していないWebアプリケーションの場合

最大同時実行スレッド数を設定していないWebアプリケーションの，最大同時実行スレッド数は次のとおりです。

最大同時実行スレッド数＝

Webコンテナの最大同時実行スレッド数－Webアプリケーション単位の占有スレッド数の合計※

注※

WebコンテナにデプロイされているすべてのWebアプリケーションに設定されている，占有スレッド数の合計となります。

(b)　占有スレッド数を設定していないWebアプリケーションの場合

Webアプリケーション単位の同時実行スレッド数制御の設定では，占有スレッド数の設定は任意となります。占有スレッド数を設定していないWebアプリケーションの最大同時実行スレッド数は，次のどちらかの値のうち，小さい方の値が適用されます。

最大同時実行スレッド数＝

Webアプリケーションに設定した最大同時実行スレッド数

　または

Webコンテナの最大同時実行スレッド数－Webアプリケーション単位の占有スレッド数の合計※

注※

WebコンテナにデプロイされているすべてのWebアプリケーション設定されている，占有スレッド数の合計となります。

(2)　Webアプリケーションの占有スレッド数

Webコンテナ単位での同時実行スレッド数だけを設定している場合，Webコンテナ内のほかのWebアプリケーションへのアクセスが集中すると，スレッドはアクセスが集中しているアプリケーションに使用されます。占有スレッド数を設定することで，Webアプリケーション内での実行に必要なスレッド数を最低限確保できるので，Webコンテナ内のほかのWebアプリケーションへのアクセスが集中した場合でも，リクエストが待ち状態になることなく，実行できます。

(a)　占有スレッド数の設定の有無によるWebアプリケーションの動作

Webアプリケーションの占有スレッド数について次の図に示します。この図を使用して，占有スレッド数を設定したWebアプリケーションと占有スレッド数を設定していないWebアプリケーションの動作を説明します。

図2-20　Webアプリケーションの占有スレッド数

図の内容について説明します。Webコンテナでは，Webアプリケーション1とWebアプリケーション2が動作しています。Webアプリケーション2では，Webアプリケーションでの同時実行スレッド数制御を設定していませんが，Webアプリケーション1では，Webアプリケーションでの同時実行スレッド制御を設定しています。Webアプリケーション1の最大同時実行スレッド数は3で，占有スレッド数は1に設定されています。

例えば，Webアプリケーション2にアクセスが集中した場合，Webアプリケーション1に占有スレッド数を設定していないと，すべてのスレッドがWebアプリケーション2に使用されます。図のようにWebアプリケーション1に占有スレッド数を設定することで，Webアプリケーション2へのアクセスが集中したときでも，Webアプリケーション1では1スレッドは最低限確保できます。これによって，占有スレッド数を設定しているWebアプリケーション1の処理を確実に実行できます。

このように，占有スレッド数を設定しておくと，ほかの業務へのアクセスが集中した場合でも確実に実行できます。このため，管理用アプリケーションなどの重要度の高いWebアプリケーションに対して占有スレッド数を設定しておくことをお勧めします。

なお，占有スレッド数に指定した数のスレッドは，ほかのWebアプリケーションのリクエスト処理には使用されません。また，Webアプリケーション単位の同時実行スレッド制御の設定では，占有スレッド数の設定は任意となります。

(b)　占有スレッド数と最大同時接続数

Webサーバの最大同時接続数（Webサーバ連携機能を使用する場合）またはWebクライアントからの最大同時接続数（インプロセスHTTPサーバを使用する場合）が少ないときに，占有スレッド数を設定していないWebアプリケーションへのリクエストによって最大同時接続数が占有されると，占有スレッド数を設定したWebアプリケーションにアクセスしても，Webサーバ上またはインプロセスHTTPサーバ上で実行待ちになったり，エラーになったりします。

占有スレッド数を設定したWebアプリケーションを，ほかのWebアプリケーションへのアクセス流量に依存しないで確実に実行させるためには，最大同時接続数に適切な値を設定する必要があります。最大同時接続数の設定方法を次に示します。

Webサーバの最大同時接続数の設定方法（Webサーバ連携機能を使用する場合）
Webサーバ連携機能を使用する場合，Webサーバの最大同時接続数を，次に示す値よりも大きい値にする必要があります。

Webサーバの最大同時接続数＞Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数

占有スレッド数を設定する場合は，上記の式を満たすように適切な値を設定してください。
なお，Webサーバの最大同時接続数は，次の個所に設定されています。

Hitachi Web Serverを使用している場合

httpsd.confのThreadsPerChildディレクティブ（Windowsのとき）またはhttpsd.confのMaxClientsディレクティブ（UNIXのとき）

Microsoft IISを使用している場合

［インターネット サービス マネージャ］で設定したクライアントとの接続数

Hitachi Web Serverを使用している場合の設定の詳細については，マニュアル「Hitachi Web Server」を参照してください。Microsoft IISを使用している場合の設定の詳細については，Microsoft IISのヘルプを参照してください。

Webクライアントからの最大同時接続数の設定方法（インプロセスHTTPサーバを使用する場合）
インプロセスHTTPサーバを使用する場合，Webクライアントからの最大同時接続数を次に示す値よりも大きい値にする必要があります。

Webクライアントからの最大同時接続数＞Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数

なお，Webクライアントからの同時接続数とは，Webクライアントからの最大接続数から，接続を拒否するリクエスト数を引いた値です。詳細については，「4.5　Webクライアントからの同時接続数の制御によるリクエストの流量制御」を参照してください。

(3)　Webアプリケーションの実行待ちキューサイズ

Webアプリケーションの実行待ちキューサイズを設定します。

Webアプリケーションに最大同時実行スレッド数を設定している場合，実行スレッド数が最大数に達してしまうと，リクエストはキューにためられます。このときの，実行待ちのキューのサイズを，Webアプリケーション単位で指定できます。

Webアプリケーション単位の実行待ちキューサイズの設定は，Webアプリケーション単位での同時実行スレッド数を設定しているかどうかで異なります。

Webアプリケーション単位で同時実行スレッド数を設定している場合
Webアプリケーションごとに実行待ちキューサイズを設定できます。

Webアプリケーション単位で同時実行スレッド数を設定していない場合
Webアプリケーションで共通となる実行待ちキューサイズが使用されます。共通の実行待ちキューサイズのことを，デフォルトの実行待ちキューサイズといいます。

Webアプリケーション単位およびデフォルトの実行待ちキューでの動作

実行待ちキューの設定が，Webアプリケーションの実行待ちキューサイズとデフォルトの実行待ちキューサイズを含め，複数ある場合，共有スレッド数を使用して実行されるリクエストの順序は，キューのリクエストのうち，先に到着したリクエストから処理されます。

Webサーバの最大同時接続数とWebアプリケーション単位およびデフォルトの実行待ちキュー（Webサーバ連携機能を使用する場合）

WebサーバからWebコンテナに転送されるリクエストの多重度は，Webサーバの最大同時接続数が上限となります。このため，占有スレッド数を設定する場合には，Webアプリケーション単位およびデフォルトの実行待ちキューサイズはWebサーバの最大同時接続数より少ない数にしてください。

Webクライアントからの最大同時接続数とWebアプリケーション単位およびデフォルトの実行待ちキュー（インプロセスHTTPサーバを使用する場合）

Webクライアントからの接続数の多重度の上限は次に示す値となります。

Webクライアントからの最大同時接続数－接続を拒否するリクエスト数

このため，占有スレッド数を設定する場合には，Webアプリケーション単位およびデフォルトの実行待ちキューサイズはWebクライアントからの最大同時接続数より少ない値にする必要があります。

なお，Webクライアントからの最大同時接続数が「Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数」よりも大きい場合，インプロセスHTTPサーバによるWebクライアントからの同時実行数の制御は不要です。また，Webクライアントからの最大同時接続数が「Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数」よりも小さい場合，インプロセスHTTPサーバによるWebクライアントからの同時実行数の制御を実行することによって，クライアントに対して接続待ちを発生させないで即座にエラーを返すことができます。

ポイント

同時実行スレッド数が最大数に達したときのリクエストの動作

Webアプリケーション単位の同時実行スレッド数が最大数に達した場合で，キューに空きがあるときは，リクエストはキューにたまります。そして，処理中のリクエスト処理が完了したあとに，順次キューからリクエストが取り出され，実行されます。なお，キューに空きがないときは，リクエストはエラーとなり，クライアントには，HTTP 503エラーが返ります。

2.17.3　同時実行スレッド数設定の指針（Webアプリケーション単位）

Webアプリケーション単位の同時実行スレッド数制御をする場合の設定の指針について説明します。

設定する値は，次の順に決定してください。

Webコンテナ単位の最大同時実行スレッド数を決定する。

Webアプリケーション単位の最大同時実行スレッド数を決定する。

Webアプリケーション単位の占有スレッド数を決定する。

Webアプリケーション単位およびデフォルトの実行待ちキューサイズを決定する。

Webアプリケーション単位の同時実行スレッド数の設定は，各Webアプリケーションの運用，およびJ2EEサーバが動作するホストの処理能力を考慮して設定してください。設定値が妥当であるかどうかは，Webアプリケーションを実行し，評価する必要があります。
なお，実行中のWebアプリケーションの稼働情報は，Management Serverを利用して確認できます。Webアプリケーションの稼働状況の確認については，「2.19.2(1)　Webアプリケーションの稼働状況の確認」を参照してください。

複数のWebアプリケーションに占有スレッド数を設定する場合，各Webアプリケーションの占有スレッド数の合計は，Webコンテナの最大同時実行スレッドの値以下にする必要があります。設定値については，Webコンテナ単位の同時実行スレッド数の制御とあわせて検討してください。

Webコンテナ単位の最大同時実行スレッド数が少ない場合，Webアプリケーション単位の最大同時実行スレッド数は，設定した数よりも少なくなるおそれがありますので，注意してください。

占有スレッド数は，Webアプリケーションの最大同時実行スレッド数以下にしてください。

2.17.4　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

Webアプリケーション単位でのスレッド数の制御を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのWebアプリケーション単位でのスレッド数の制御の定義について次の表に示します。

表2-53　cosminexus.xmlでのWebアプリケーション単位でのスレッド数の制御の定義

項目
指定するタグ
設定内容

Webアプリケーション単位での最大同時実行スレッド数※
<thread-control>タグ内の<thread-control-max-threads>タグ
Webアプリケーションで，最大で幾つのスレッドを同時に実行できるかを指定できます。

Webアプリケーション単位の占有スレッド数
<thread-control>タグ内の<thread-control-exclusive-threads>タグ
Webアプリケーションで，最低限確保するスレッド数（占有スレッド数）を指定できます。
なお，占有スレッド数を設定しない場合は，0を指定します。

Webアプリケーション単位の実行待ちキュー
<thread-control>タグ内の<thread-control-queue-size>タグ
実行スレッド数が最大数に達した場合，リクエストはキューに溜められます。このときの，実行待ちキューサイズをWebアプリケーション単位で指定します。

注※　Webアプリケーション単位の同時実行スレッド数の設定は，運用管理コマンド（mngsvrutil）を利用して，動的に変更することもできます。これによって，稼働中のWebアプリケーションのサービスを停止することなく，同時実行スレッド数の設定を変更できます。Webアプリケーションの最大同時実行スレッド数の動的変更については，「2.19　同時実行スレッド数の動的変更」を参照してください。

指定するタグの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

2.17.5　実行環境での設定

ここでは，Webアプリケーション単位でスレッド数を制御する場合の設定について説明します。

Webアプリケーション単位でスレッド数を制御する場合，J2EEサーバおよびJ2EEアプリケーションの設定が必要です。

なお，J2EEアプリケーションの設定は，cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

＜この項の構成＞

(1)　J2EEサーバの設定

(2)　J2EEアプリケーションの設定

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webアプリケーション単位でのスレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのWebアプリケーション単位でのスレッド数の制御の定義について次の表に示します。

表2-54　簡易構築定義ファイルでのWebアプリケーション単位でのスレッド数の制御の定義

項目
指定するパラメタ
設定内容

同時実行スレッド数の制御の有無
webserver.container.thread_control.enabled
Webアプリケーション単位で同時実行スレッド数を制御するかどうかを指定します。「true」を指定すると，Webアプリケーション単位での同時実行スレッド数制御が有効になります。なお，「false」を指定するとWebアプリケーション単位での同時実行スレッド数制御が無効となり，Webコンテナ単位で同時実行スレッド数が制御されます。

デフォルトの実行待ちキューサイズ
webserver.container.thread_control.queue_size
実行スレッド数が最大数に達した場合，リクエストはキューに溜められます。このときの，Webアプリケーションで共通となる実行待ちキューサイズ（デフォルトの実行待ちキューサイズ）を指定します。
設定した値は，Webアプリケーション単位での同時実行数を指定していない場合に適用されます。

簡易構築定義ファイル，指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。Webアプリケーション単位でのスレッド数の制御の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.17.4　cosminexus.xmlでの定義」を参照してください。

2.17.6　同時実行スレッド数および実行待ちキューサイズの設定例（Webアプリケーション単位）

同時実行スレッド数およびWebアプリケーション単位の実行待ちキューサイズの設定例について説明します。ここでは，Webサーバ連携機能を使用する場合の例について説明します。

＜この項の構成＞

(1)　説明で使用するWebアプリケーションの設定例

(2)　各Webアプリケーションで使用できるスレッド数

(1)　説明で使用するWebアプリケーションの設定例

この例では，Webコンテナに四つのWebアプリケーションがデプロイされていて，そのうちの二つのWebアプリケーションにWebアプリケーション単位での同時実行スレッド数制御がされているものとします。設定内容を次に示します。

Webサーバの最大同時接続数：50

Webコンテナ単位の最大同時実行スレッド数：10

デフォルトの実行待ちキューサイズ：10

Webアプリケーション単位の同時実行スレッド数制御の設定
WebアプリケーションAおよびBに，それぞれ次の設定がされているものとします。
なお，WebアプリケーションCおよびDには，Webアプリケーション単位の同時実行スレッド数制御の設定はありません。

Webアプリケーション名 | 最大同時実行スレッド数 | 占有スレッド数 | Webアプリケーション単位の実行待ちキューサイズ
WebアプリケーションA | 3 | 1 | 5
WebアプリケーションB | 3 | 2 | 10

Webコンテナ上に，Webアプリケーションごとの同時実行スレッド数制御の設定があるWebアプリケーションと，設定のないWebアプリケーションが混在している場合の例を，次の図に示します。

図2-21　Webアプリケーションの設定例

(2)　各Webアプリケーションで使用できるスレッド数

図2-21の設定の場合に使用できる最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズについて，Webアプリケーションごとに説明します。なお，説明の項番は，図中の項番と対応しています。

WebアプリケーションA

最大同時実行スレッド数および占有スレッド数
WebアプリケーションAでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
WebアプリケーションAの同時に実行できるスレッド数は最大で3スレッドです。そのうち，1スレッドは，WebアプリケーションAで最低限確保できる占有スレッド数となります。

Webアプリケーション単位の実行待ちキューサイズ
WebアプリケーションAではWebアプリケーション単位の実行待ちキューサイズを指定しています。WebアプリケーションAで同時に3スレッド使用している場合，WebアプリケーションAへのリクエストは，最大で5個，キューにたまります。

WebアプリケーションB

最大同時実行スレッド数および占有スレッド数
WebアプリケーションBでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
WebアプリケーションBの同時に実行できるスレッド数は最大で3スレッドです。そのうち，2スレッドは，WebアプリケーションBで最低限確保できる占有スレッド数となります。

Webアプリケーション単位の実行待ちキューサイズ
WebアプリケーションBではWebアプリケーション単位の実行待ちキューサイズを指定しています。WebアプリケーションBで同時に3スレッド使用している場合，WebアプリケーションBへのリクエストは，最大で10個，キューにたまります。

WebアプリケーションCおよびWebアプリケーションD
WebアプリケーションCおよびWebアプリケーションDでは，Webアプリケーション単位の同時実行スレッド制御を設定していません。
このため，次のように動作します。

最大同時実行スレッド数
WebアプリケーションCおよびWebアプリケーションDでは，Webコンテナの共有スレッド数を使用します。この場合，Webコンテナの共有スレッド数は7であるため，WebアプリケーションCおよびWebアプリケーションDで，合わせて最大で7スレッド使用できます。
なお，スレッド数は，WebアプリケーションCおよびWebアプリケーションDで共有することになります。
また，同時実行スレッド数制御を設定していないため，占有スレッド数はありません。WebアプリケーションAおよびWebアプリケーションBへのアクセスが集中し，使用できるスレッドがなくなると，WebアプリケーションCおよびWebアプリケーションDの処理は実行待ちになります。

デフォルトの実行待ちキューサイズ
WebアプリケーションCまたはWebアプリケーションDで実行待ちが発生した場合，これらのWebアプリケーションへのリクエストは，キューにたまります。WebアプリケーションCおよびWebアプリケーションDではWebアプリケーション単位の実行待ちキューサイズを指定していないため，キューはデフォルトの実行待ちキューにためられます。最大で10個のリクエストがキューにたまります。

参考

Webコンテナでは，スレッドは静的コンテンツやリクエストのエラー処理にも使用されます。これらの目的で使用されるスレッド数は，次の式から求められます。

Webサーバの処理スレッド数－（Webコンテナ単位の最大同時実行スレッド数＋実行待ちキューサイズの総和※）

注※　実行待ちキューサイズの総和とは，この図の場合，Webコンテナ，WebアプリケーションA，WebアプリケーションBの実行待ちキューサイズを足した値となります。

このため，この図の例の場合，50－（10＋（10＋5＋10））となり，静的コンテンツやリクエストのエラー処理に使用されるスレッド数は，15スレッドとなります。

2.17.7　Webアプリケーション単位での同時実行スレッド数制御についての注意事項

Webアプリケーション単位での同時実行スレッド数を制御する場合，次のことに注意してください。

スレッド数が，Webコンテナ単位の最大同時実行スレッド数を上回る場合
次の条件すべてを満たすときは，Webアプリケーションで最低限確保されているスレッド数だけリクエストが実施されるため，スレッド数が，一時的にWebコンテナ単位の最大同時実行スレッド数を上回るおそれがあります。

アクセスが集中したときなど，Webコンテナ単位の同時実行スレッド数に設定した数すべてを使用しているとき

占有スレッド数を設定したWebアプリケーションをデプロイしているとき

実行中のリクエスト処理スレッドが完了する前に，デプロイしたWebアプリケーションにリクエストがあったとき

制御の対象となるアクセス
サーブレット，JSPのほかに，静的コンテンツへのアクセスも，同時実行スレッド数の制御の対象となります。

エラーページのカスタマイズ機能使用時の注意
web.xmlに<error-page>タグを使用した，エラーページのカスタマイズ機能を使用している場合，エラー発生時に転送されたリクエスト処理は，同時実行スレッド数制御の対象外となります。同時実行スレッド数の制御による制限はありません。

スレッドについて
占有スレッド数は，Webアプリケーション専用のスレッドとして生成されるものではありません。ここで設定するスレッド数は，Webアプリケーションを実行するに当たり，最低限確保されるスレッド数です。
なお，リクエスト処理用のスレッドは，Webコンテナ全体で再利用されます。

Webアプリケーション単位の最大同時実行スレッド数について
Webアプリケーション単位の最大同時実行スレッド数が，Webコンテナ単位の最大同時実行スレッド数より大きな値が設定されていても，WebアプリケーションをJ2EEサーバにデプロイできます。ただし，デプロイされたWebアプリケーションの最大同時実行スレッド数は，Webコンテナ単位の最大同時実行スレッド数になるので，注意してください。

Webアプリケーション単位の共有スレッド数が0以下になる場合について
次のようなWebアプリケーションをデプロイすることで，Webアプリケーション単位の共有スレッド数が0以下になることがあります。Webアプリケーション単位の共有スレッド数が0以下になると，Webアプリケーションのデプロイに失敗するので注意してください。次のような場合で共有スレッド数が0以下になることが考えられます。

すでにURLグループ単位の同時実行スレッド数制御を設定しているWebアプリケーションがデプロイされていて，さらに占有スレッド数を設定したWebアプリケーションをデプロイしようとしている場合

デプロイするWebアプリケーションで，占有スレッド数，およびURLグループ単位の同時実行スレッド数制御を設定していて，設定段階ですでにWebアプリケーション単位の共有スレッド数が0以下となっている場合

2.18　URLグループ単位での同時実行スレッド数の制御

この節では，URLグループ単位での同時実行スレッド数の制御について説明します。

なお，URLグループ単位でスレッド数を制御するときには，Webコンテナ単位，およびWebアプリケーション単位でのスレッド数制御も同時に設定する必要があります。「2.16　Webコンテナ単位での同時実行スレッド数の制御」および「2.17　Webアプリケーション単位での同時実行スレッド数の制御」もあわせて参照してください。

この節の構成を次の表に示します。

表2-55　この節の構成（URLグループ単位での同時実行スレッド数の制御）

分類 | タイトル | 参照先
解説 | 同時実行スレッド数の制御の仕組み（URLグループ単位） | 2.18.1
URLパターンのマッピング処理 | 2.18.2
同時実行スレッド数の制御に必要なパラメタ（URLグループ単位） | 2.18.3
同時実行スレッド数設定の指針（URLグループ単位） | 2.18.4
実装 | cosminexus.xmlでの定義 | 2.18.5
設定 | 実行環境での設定（Webアプリケーションの設定） | 2.18.6
同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位） | 2.18.7

注　「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.18.1　同時実行スレッド数の制御の仕組み（URLグループ単位）

2.18.2　URLパターンのマッピング処理

2.18.3　同時実行スレッド数の制御に必要なパラメタ（URLグループ単位）

2.18.4　同時実行スレッド数設定の指針（URLグループ単位）

2.18.5　cosminexus.xmlでの定義

2.18.6　実行環境での設定（Webアプリケーションの設定）

2.18.7　同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

2.18.1　同時実行スレッド数の制御の仕組み（URLグループ単位）

Webアプリケーション単位より細かい粒度で同時実行スレッド数制御をしたい場合，URLグループ単位で同時実行スレッド数を制御します。

一つのWebアプリケーション内に処理に時間が掛かる業務ロジック（サーブレットやJavaBeans）がある場合，Webアプリケーション内の同時実行スレッド数のほとんどが使用されてしまい，ほかの業務ロジックの処理が待ち状態になるおそれがあります。このような場合にURLグループ単位の同時実行スレッド数制御を設定することで，Webアプリケーション内の業務ロジックがほかの処理に影響を与えることなく実行できます。

なお，同時実行スレッド数で制御できるURLは，RFC 2616で定義されているリクエストURIを指します。また，URLグループ単位での同時実行スレッド数の制御ができるURLは，リクエストURIのクエリ文字は含みません。例を次に示します。

制御できるHTTPリクエスト：/webapp/index.html

制御できないHTTPリクエスト：http://localhost/webapp/index.html?id=0001

なお，URLグループ単位の同時実行スレッド数の設定の指針については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「8.3.4　Webアプリケーションの同時実行数を制御する」を参照してください。

2.18.2　URLパターンのマッピング処理

URLパターンに指定したURLとリクエストURLとのマッピングの順序について説明します。また，welcomeファイルに対してURLパターンを設定している場合についても説明します。

＜この項の構成＞

(1)　マッピングの順序

(2)　welcomeファイルにURLパターンを設定しているときの処理の流れ

(1)　マッピングの順序

リクエストURLは，次の1.～3.の順序でマッピングされます。なお，マッピングの順序は，Servlet仕様のサーブレットマッピングの適用順序と同じです。

完全一致
リクエストURLとURLパターンが完全に一致する場合，一致したURLパターンが適用されます。

プリフィックス一致
リクエストURLとプリフィックスが一致し，さらに，リクエストURLとできるだけ長く文字列が一致するURLパターンが適用されます。

拡張子一致
リクエストURLと拡張子が一致する場合，一致したURLパターンが適用されます。

なお，上記の1.～3.に一致しない場合は，URLグループ単位の同時実行スレッド数制御の対象にはなりません。このようなリクエストURLは，Webアプリケーション単位の同時実行スレッド数制御の対象になります。

次に示すURLパターンを使用して，URLのマッピングの例を説明します。

表2-56　URLパターンの例

URLパターン | URLパターンに対応するURLグループ
/foo/bar | Control1
/foo/* | Control2
/foo/bar/* | Control3
*.do | Control4

マッピング例1：リクエストURLが「/foo/bar」の場合

Control1のURLパターンと完全一致するため，Control1に振り分けられます。

マッピング例2：リクエストURLが「/foo/bb」の場合

完全一致するURLパターンがないため，プリフィックスが一致するControl2に振り分けられます。

マッピング例3：リクエストURLが「/foo/aa.do」の場合

この場合，Control2とControl4で次の個所が一致します。

プリフィックス「/foo」がControl2と一致します。

拡張子「.do」がControl4と一致します。

マッピング順序では，拡張子一致よりプリフィックス一致が優先されるため，Control2に振り分けられます。

マッピング例4：リクエストURLが「/foo/bar/」の場合

この場合，Control2とControl3でそれぞれプリフィックスが一致します。

プリフィックス「/foo」がControl2と一致します。

プリフィックス「/foo/bar」がControl3と一致します。

より長い文字列で一致するControl3に振り分けられます。

マッピング例5：リクエストURLが「/foo/bar/action.do」の場合

この場合，Control2，Control3，Control4で次の個所が一致します。

プリフィックス「/foo」がControl2と一致します。

プリフィックス「/foo/bar」がControl3と一致します。

拡張子「.do」がControl4と一致します。

マッピング順序では拡張子一致よりプリフィックス一致が優先され，さらにより長い文字列が一致するURLパターンが優先されるので，Control3に振り分けられます。

マッピング例6：リクエストURLが「/context/fo」の場合

該当するURLパターンがないため，Webアプリケーション単位での同時実行スレッド制御として扱われます。

マッピング例7：リクエストURLが「/action.do」の場合

Control4と拡張子が一致するため，Control4に振り分けられます。

マッピング例8：リクエストURLが「/boo/action.do」の場合

Control4と拡張子が一致するため，Control4に振り分けられます。

(2)　welcomeファイルにURLパターンを設定しているときの処理の流れ

welcomeファイルにURLパターンを設定しているときの処理の流れについて，次の図で説明します。この図の例では，Webアプリケーションのコンテキストルートはcontextとし，welcomeファイルはweb.xmlで/index.htmlが設定されているものとします。また，URLパターンとURLグループ単位での同時実行スレッド数制御の定義名は次のとおりとします。

URLパターン：/index.html

URLグループ単位での同時実行スレッド数制御の定義名：Control1

図2-22　welcomeファイルにURLパターンを設定する場合の例

図の流れについて次に説明します。

クライアントはhttp://localhost/context/にリクエストを送信する。

J2EEサーバでは，web.xmlに設定されたwelcomeファイルに対して再度クライアントにアクセスしてもらうため，HTTPステータスコード302を返す。また，Locationヘッダにhttp://localhost/context/index.htmlを含める。

HTTPレスポンスを受信したクライアントは，Locationヘッダの値（http://localhost/context/index.html）にリクエストを送信する。

該当するWebアプリケーションのリクエストが/index.htmlなので，Control1のURLグループ単位の同時実行スレッド数制御の制御対象となる。リクエスト処理終了後，クライアントに対してレスポンスとしてindex.htmlを送信する。

2.18.3　同時実行スレッド数の制御に必要なパラメタ（URLグループ単位）

ここでは，URLグループ単位でスレッド数を制御する場合の設定について説明します。URLグループ単位でスレッド数を制御する場合は，次の設定が必要になります。

Webコンテナ単位の同時実行スレッド数制御の設定
Webコンテナ単位の最大同時実行スレッド数などを設定します。なお，ここで設定した最大同時実行スレッド数は，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有します。
Webコンテナ単位での同時実行スレッド数制御の設定については，「2.16　Webコンテナ単位での同時実行スレッド数の制御」を参照してください

Webアプリケーション単位の同時実行スレッド数制御の設定
Webアプリケーション単位の同時実行スレッド数や，占有スレッド数などを設定します。なお，URLグループ単位での同時実行スレッド数を設定する場合，Webアプリケーション単位での占有スレッド数の設定は必須になります。
Webアプリケーション単位での同時実行スレッド数制御の設定については，「2.17　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

URLグループ単位の同時実行スレッド数制御の設定
URLグループ単位の同時実行スレッド数制御は，Webアプリケーション単位での同時実行スレッド数制御を設定しているWebアプリケーション内のURLグループに対して，次に示すパラメタを設定します。

URLグループ単位の同時実行スレッド数制御の定義名
同時実行スレッド数制御の単位となるURLグループの名称を設定します。

最大同時実行スレッド数
URLグループで最大で幾つのスレッドを同時に実行できるかを設定します。

占有スレッド数
URLグループの占有スレッド数を設定します。

URLグループ単位の実行待ちキューサイズ
URLグループの実行待ちキューサイズを設定します。

URLパターン
スレッド数制御の対象となるリクエストURLに振り分けるための，URLパターンを設定します。

以降で，URLグループ単位での同時実行スレッド数制御の設定項目の詳細を説明します。

＜この項の構成＞

(1)　URLグループ単位の最大同時実行スレッド数

(2)　URLグループ単位の占有スレッド数

(3)　URLグループ単位の実行待ちキュー

(4)　URLパターンの設定

(1)　URLグループ単位の最大同時実行スレッド数

URLグループ単位で使用するスレッド数は，URLグループが属するWebアプリケーションのスレッド数です。このため，URLグループ単位でスレッドを一つ使用している場合，そのURLグループを含むWebアプリケーションでもスレッドが一つ実行されていることになります。

なお，URLグループ単位の最大同時実行スレッド数を設定していないリクエストURLについては，Webアプリケーション単位の共有スレッド数が使用されます。Webアプリケーション単位の共有スレッド数は，次のようになります。

Webアプリケーション単位の共有スレッド数＝

Webアプリケーション単位の最大同時実行スレッド数※－URLグループ単位の占有スレッド数の合計

注※　ここでの最大同時実行スレッド数の値には，次の1.と2.のうち，小さい方の値が適用されます。

Webコンテナ単位の共有スレッド数

Webアプリケーション単位の最大同時実行スレッド数に設定した値

このとき，Webアプリケーション単位の共有スレッド数は1以上である必要があります。共有スレッド数が0以下になる場合は，エラーが発生します。詳細は，「2.17.7　Webアプリケーション単位での同時実行スレッド数制御についての注意事項」を参照してください。

(2)　URLグループ単位の占有スレッド数

URLグループ単位の占有スレッド数は，特定の業務ロジックをWebアプリケーション内のほかの業務ロジックの影響を受けないで実行させるために設定します。

URLグループ単位の占有スレッド数は，Webアプリケーションで設定されている占有スレッド数の範囲で指定します。このため，URLグループが含まれるWebアプリケーションで占有スレッド数を設定していない場合は，URLグループ単位でも占有スレッド数を設定できないので注意してください。

また，URLグループ単位の同時実行スレッド数制御を設定しているリクエストURLに対するリクエスト数が，URLグループ単位の占有スレッド数を超える場合で，かつURLグループ単位の最大同時実行スレッド数に満たない場合は，Webアプリケーション単位の共有スレッド数を使用してリクエストを処理します。このため，Webアプリケーション単位の共有スレッド数が少ないと，URLグループ単位の最大同時実行スレッド数は，設定値よりも少なくなることがあるので注意してください。

(3)　URLグループ単位の実行待ちキュー

URLグループ単位の実行待ちキューは，URLグループ単位の同時実行スレッド数が上限に達したときにリクエストが入るキューです。URLグループ単位の実行待ちキューは，URLグループ単位の同時実行スレッド数の制御を設定した場合に，URLグループごとに作成されます。この実行待ちキューのサイズを設定します。

リクエストは，URLグループ単位の同時実行スレッド数が上限に達していて，URLグループ単位の実行待ちキューに空きがある場合，その実行待ちキューに入ります。URLグループ単位の実行待ちキューの中のリクエストは，処理中のリクエストが完了したあとに，その実行待ちキューから順次取り出され，実行されます。URLグループ単位の同時実行スレッド数が上限に達していて，URLグループ単位の実行待ちキューサイズに空きがない場合はエラーとなり，クライアントにHTTPステータスコード503が返ります。

なお，URLグループ単位の実行待ちキューに入るリクエストは，デフォルトの実行待ちキューやWebアプリケーションの実行待ちキューに入ることはありません。また，URLグループ単位の同時実行スレッド数の制御で設定したリクエストURLに該当しないリクエストについては，Webアプリケーションの実行待ちキューが使用されます。

(4)　URLパターンの設定

リクエストURLを振り分けるためのURLパターンを設定します。URLパターンには，Servlet仕様のサーブレットマッピングのURLパターンが指定できます。指定できるURLパターンを次に示します。

"/"で始まる文字列
例：/index.jsp

"/"で始まり，"/*"で終わる文字列
例：/test/*

"*."で始まる文字列
例：*.do

なお，リクエストURLのURLパターンとのマッピング順序については，「2.18.2　URLパターンのマッピング処理」を参照してください。

URLグループ単位で同時実行スレッド数を制御する場合，Webアプリケーション単位での同時実行スレッド数制御，およびWebコンテナでのスレッド数制御も同時に設定する必要があります。URLグループ単位での同時実行スレッド数制御で設定するパラメタを次の表に示します。

表2-57　URLグループ単位でスレッド数を制御する場合の設定パラメタ

設定するパラメタ | 設定単位
Webコンテナ単位 | Webアプリケーション単位 | URLグループ単位
同時実行スレッド数の制御をするかどうか | － | ○ | －
最大同時実行スレッド数 | ○ | ○ | ○
占有スレッド数 | － | ○ | ○
実行待ちキューサイズ | － | ○ | ○
デフォルトの実行待ちキューサイズ | － | ○ | －
URLグループ単位の同時実行スレッド数制御の定義名 | － | － | ○
制御対象となるURLパターン | － | － | ○

（凡例）　○：設定する　－：該当しない

次に，URLグループ単位での同時実行スレッド数制御の設定について説明します。URLグループ単位での同時実行スレッド数の制御は，サーバ管理コマンドで設定します。なお，Webコンテナ単位での設定パラメタについては，「2.16.2　実行環境での設定（J2EEサーバの設定）」を，Webアプリケーション単位での設定パラメタについては，「2.17.5　実行環境での設定」を参照してください。

サーバ管理コマンドでは，次の内容が設定できます。

URLグループ単位の同時実行スレッド数制御の定義名
同時実行スレッド数制御をするURLのグループ名を指定します。グループ名はWebアプリケーション内で一意な名称を指定する必要があります。
使用できる文字は次のとおりです。

半角英数字（A～Z，a～z，0～9）

半角ハイフン（-）

半角アンダーバー（_）

また，文字列の長さは1～64文字となります。

URLグループ単位の最大同時実行スレッド数
URLグループで，最大で幾つのスレッドを同時に実行できるかを指定します。設定範囲は次のとおりです。

最大同時実行スレッド数の設定範囲

1≦最大同時実行スレッド数（URLグループ単位）≦最大同時実行スレッド数（Webアプリケーション単位）

URLグループ単位の占有スレッド数
URLグループで，最低限確保するスレッド数（占有スレッド数）を指定します。設定範囲は次のとおりです。

占有スレッド数の設定範囲

0≦占有スレッド数（URLグループ単位）≦最大同時実行スレッド数（URLグループ単位）

さらに，URLグループ単位の占有スレッド数は，Webアプリケーション単位の占有スレッド数以下である必要があります。

また，Webアプリケーション内のURLグループ単位に設定している占有スレッド数の総和は，次の条件を満たしている必要があります。なお，条件は，Webアプリケーション単位の最大同時実行スレッド数とWebアプリケーション単位の占有スレッド数の値によって異なります。

Webアプリケーション単位の設定が，最大同時実行スレッド数≠占有スレッド数の場合

占有スレッド数（Webアプリケーション単位）≧占有スレッド数の総和（URLグループ単位）

Webアプリケーション単位の設定が，最大同時実行スレッド数＝占有スレッド数の場合

占有スレッド数（Webアプリケーション単位）＞占有スレッド数の総和（URLグループ単位）

なお，占有スレッド数を設定しない場合は，0を指定します。

URLグループ単位の実行待ちキューサイズ
実行スレッド数が最大数に達した場合，リクエストはキューに溜められます。このときの，実行待ちキューサイズをURLグループ単位で指定します。設定範囲は次のとおりです。

URLグループ単位の実行待ちキューサイズの設定範囲

0≦実行待ちキューサイズ（URLグループ単位）≦2,147,483,647

なお，0を設定すると，URLグループ単位の実行待ちキューを使用しない設定になります。このとき，同時実行スレッド数が上限に達すると，リクエストはエラーとなります。

制御対象となるURLパターン
同時実行スレッド数の制御対象となるURLを指定します。URLパターンはWebアプリケーション内で一意な名称を指定する必要があります。また，Webアプリケーションのコンテキスト以下を指定してください。

サーバ管理コマンドを使用する場合は，WAR属性ファイルの<thread-control>タグ下の<urlgroup-thread-control>タグで，同時実行スレッド数を設定します。

<urlgroup-thread-control-name>タグに，同時実行スレッド数制御の定義名を指定します。

<urlgroup-thread-control-max-threads>タグに，URLグループ単位での最大同時実行スレッド数を指定します。

<urlgroup-thread-control-exclusive-threads>タグに，占有スレッド数を指定します。

<urlgroup-thread-control-queue-size>タグに，URLグループ単位の実行待ちキューサイズを指定します。

<urlgroup-thread-control-mapping>タグに，制御対象となるURLパターンを<url-pattern>タグで囲んで指定します。

サーバ管理コマンドのcjgetapppropコマンドで属性ファイルを取得し，属性ファイル編集後に，cjsetapppropコマンドで編集内容を反映させてください。サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

2.18.4　同時実行スレッド数設定の指針（URLグループ単位）

URLグループ単位の同時実行スレッド数制御をする場合の設定の指針について説明します。

URLグループ単位の同時実行スレッド数制御の設定をする場合，事前に次の内容を設定しておいてください。

Webコンテナ単位の最大同時実行スレッド数

Webアプリケーション単位の最大同時実行スレッド数，占有スレッド数，実行待ちキューサイズ

設定する値は，次の順に決定してください。

URLグループ単位の最大同時実行スレッド数を設定する。

URLグループ単位の占有スレッド数を設定する。

URLグループ単位の実行待ちキューサイズを設定する。

URLパターンを設定する。

URLグループ単位の最大同時実行スレッド数は，J2EEアプリケーション内にある業務ロジックに対して，適切な値を設定してください。
例えば，特定の業務ロジックの処理が重い場合，その業務ロジックの同時実行スレッド数に上限を設けることで，特定の業務ロジックにアクセスが集中した場合でも，特定の業務ロジックがWebアプリケーション全体の処理能力を占有するのを防ぐことができます。

URLグループ単位の占有スレッド数は，特定の業務ロジックをWebアプリケーション内のほかの業務ロジックの影響を受けないで実行させるために設定します。

URLグループ単位の実行待ちキューサイズは，特定の業務ロジックへの流量の上限を設けるために設定します。URLグループ単位の実行待ちキューは，デフォルトの実行待ちキュー，Webアプリケーション単位の実行待ちキューと設定指針は同じです。

2.18.5　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

URLグループ単位での同時実行スレッド数の制御をするための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのURLグループ単位での同時実行スレッド数の制御の定義について次の表に示します。

表2-58　cosminexus.xmlでのURLグループ単位での同時実行スレッド数の制御の定義

指定するタグ | 設定内容
<urlgroup-thread-control-name>タグ | 同時実行スレッド数制御の定義名を指定します。
<urlgroup-thread-control-max-threads>タグ | URLグループ単位での最大同時実行スレッド数を指定します。
<urlgroup-thread-control-exclusive-threads>タグ | 占有スレッド数を指定します。
<urlgroup-thread-control-queue-size>タグ | URLグループ単位の実行待ちキューサイズを指定します。
<urlgroup-thread-control-mapping>タグ | 制御対象となるURLパターンを<url-pattern>タグで囲んで指定します。

指定するタグの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

2.18.6　実行環境での設定（Webアプリケーションの設定）

URLグループ単位での同時実行スレッド数の制御をする場合，Webアプリケーションの設定が必要です。

なお，Webアプリケーションの設定は，cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。URLグループ単位での同時実行スレッド数の制御の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.18.5　cosminexus.xmlでの定義」を参照してください。

2.18.7　同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

同時実行スレッド数およびURLグループ単位の実行待ちキューサイズの設定例について説明します。ここでは，Webサーバ連携機能を使用する場合の例について説明します。

＜この項の構成＞

(1)　説明で使用するWebアプリケーションの設定例

(2)　各Webアプリケーションで使用できるスレッド数

(1)　説明で使用するWebアプリケーションの設定例

この例では，Webコンテナに二つのWebアプリケーションがデプロイされていて，そのうちの一つのWebアプリケーションにWebアプリケーション単位での同時実行スレッド数制御およびURLグループ単位の同時実行スレッド数制御がされているものとします。設定内容を次に示します。

Webサーバの最大同時接続数：40

Webコンテナ単位の最大同時実行スレッド数：8

デフォルトの実行待ちキューサイズ：5

Webアプリケーション単位の同時実行スレッド数制御の設定
WebアプリケーションAに次の内容が設定されているものとします。なお，WebアプリケーションBでは，Webアプリケーション単位の同時実行スレッド数制御の設定はありません。

Webアプリケーション名 | 最大同時実行スレッド数 | 占有スレッド数 | Webアプリケーション単位の実行待ちキューサイズ
WebアプリケーションA | 7 | 3 | 5

URLグループ単位の同時実行スレッド数制御の設定
WebアプリケーションAでは，次に示すURLグループの設定がされているものとします。なお，Control Cには，URLグループ単位の同時実行スレッド数制御の設定はありません。

URLグループ名 | URLパターン | 最大同時実行スレッド数 | 占有スレッド数 | URLグループ単位の実行待ちキューサイズ
Control A | /health_check.jsp | 1 | 1 | 1
Control B | /create_pdf | 3 | 2 | 5

URLグループ単位でスレッド数を制御する場合の例を，次の図に示します。

図2-23　URLグループ単位の設定例

(2)　各Webアプリケーションで使用できるスレッド数

図2-23の設定の場合に使用できる最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズについて，WebアプリケーションまたはURLグループごとに説明します。なお，説明の項番は，図中の項番と対応しています。

WebアプリケーションA
WebアプリケーションAでは同時実行スレッド数制御を設定しています。また，WebアプリケーションA内の業務ロジック（Control AおよびControl B）にはURLグループ単位の同時実行スレッド数制御を設定しています。
ここでは，WebアプリケーションAのスレッド数について説明します。

最大同時実行スレッド数および占有スレッド数
最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
WebアプリケーションAの同時に実行できるスレッド数は最大で7スレッドです。そのうち，3スレッドは，WebアプリケーションAで最低限確保できる占有スレッド数となります。

共有スレッド数
WebアプリケーションA全体で使用できる共有スレッド数は，WebアプリケーションAの最大同時実行スレッド数－占有スレッド数の合計となります。この場合7－3となるので，共有スレッド数は4となります。

Webアプリケーション単位の実行待ちキューサイズ
WebアプリケーションAではWebアプリケーション単位の実行待ちキューサイズを指定しています。WebアプリケーションA全体で同時に7スレッド使用している場合，リクエストは最大で5個，Webアプリケーション単位の実行待ちキューにたまります。なお，このキューは，Webアプリケーション内の業務ロジックのうち，URLグループ単位の同時実行スレッド数制御を設定していない，Control Cの業務ロジックへのリクエストに使用されます。

Control A（/health_check.jspへのリクエスト）

最大同時実行スレッド数および占有スレッド数
Control Aでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
Control Aでは，同時に実行できるスレッド数は最大で1スレッドです。この1スレッドはControl Aで最低限確保できる占有スレッドでもあります。なお，Control Aの占有スレッド数はWebアプリケーションAの占有スレッドのうちの一つとなります。

URLグループ単位の実行待ちキューサイズ
Control AではURLグループ単位の実行待ちキューサイズを指定しています。Control Aで1スレッド使用している場合，リクエストは最大で1個，URLグループ単位の実行待ちキューにたまります。

Control B（/create_pdfへのリクエスト）

最大同時実行スレッド数および占有スレッド数
Control Bでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
Control Bでは，同時に実行できるスレッド数は最大で3スレッドです。そのうち2スレッドは，Control Bで最低限確保できる占有スレッドです。なお，Control Bの占有スレッド数はWebアプリケーションAの占有スレッドのうちの二つとなります。

URLグループ単位の実行待ちキューサイズ
Control BではURLグループ単位の実行待ちキューサイズを指定しています。Control Bで3スレッド使用している場合，リクエストは最大で5個，URLグループ単位の実行待ちキューにたまります。

Control Cの処理
WebアプリケーションA内の，Control Cへのリクエストに対しては，同時実行スレッド数制御を設定していません。
このため，次のように動作します。

最大同時実行スレッド数
WebアプリケーションAの共有スレッド数が最大同時実行スレッド数になります。WebアプリケーションAの共有スレッド数は4スレッドであるため，Control Cの処理の最大同時実行スレッド数は4になります。
また，同時実行スレッド数制御を設定してないため，占有スレッド数はありません。このため，Control AまたはBへのアクセスが集中し，WebアプリケーションA内で使用できるスレッドがなくなると，Control Cの業務ロジックの処理は実行待ちになります。

Webアプリケーション単位の実行待ちキューサイズ
Control Cの業務ロジックの処理で実行待ちが発生した場合，これらの処理へのリクエストは，キューにたまります。Control Cの業務ロジックではURLグループ単位の実行待ちキューサイズを指定していないため，キューはWebアプリケーションAの実行待ちキューにためられます。リクエストは，最大で5個，キューにたまります。

WebアプリケーションB
WebアプリケーションBでは，Webアプリケーション単位の同時実行スレッド制御を設定していません。
このため，次のように動作します。

最大同時実行スレッド数
Webコンテナの共有スレッド数が最大同時実行スレッド数になります。Webコンテナの共有スレッド数は，次の式で求められます。
　Webコンテナの最大同時実行スレッド数－WebアプリケーションAの占有スレッド数
この例の場合，8－3となるため，WebアプリケーションBの最大同時実行スレッド数は5になります。

デフォルトの実行待ちキューサイズ
WebアプリケーションBで実行待ちが発生した場合，WebアプリケーションBへのリクエストは，キューにたまります。WebアプリケーションBではWebアプリケーション単位の実行待ちキューサイズを指定していないため，キューはデフォルトの実行待ちキューにためられます。リクエストは，最大で5個，キューにたまります。

参考

Webコンテナでは，スレッドは静的コンテンツやリクエストのエラー処理にも使用されます。これらの目的で使用されるスレッド数は，次の式から求められます。

Webサーバの処理スレッド数－（Webコンテナ単位の最大同時実行スレッド数＋実行待ちキューサイズの総和※）

注※　実行待ちキューサイズの総和とは，この図の場合，Webコンテナ，WebアプリケーションA，Control A，およびControl Bの実行待ちキューサイズを足した値となります。

このため，この図の例の場合，40－（8＋（5＋5＋1＋5））となり，静的コンテンツやリクエストのエラー処理に使用されるスレッド数は，16スレッドとなります。

2.19　同時実行スレッド数の動的変更

この節では，同時実行スレッド数の動的変更について説明します。

この節の構成を次の表に示します。

表2-59　この節の構成（同時実行スレッド数の動的変更）

分類 | タイトル | 参照先
解説 | 同時実行スレッド数の動的変更の概要 | 2.19.1
同時実行スレッド数の動的変更の流れ | 2.19.2
同時実行スレッド数を動的に変更したときのWebアプリケーションの動作 | 2.19.3
注意事項 | 同時実行スレッド数の動的変更についての注意事項 | 2.19.4

注　「実装」，「設定」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

2.19.1　同時実行スレッド数の動的変更の概要

2.19.2　同時実行スレッド数の動的変更の流れ

2.19.3　同時実行スレッド数を動的に変更したときのWebアプリケーションの動作

2.19.4　同時実行スレッド数の動的変更についての注意事項

2.19.1　同時実行スレッド数の動的変更の概要

ここでは，同時実行スレッド数の動的変更の概要について説明します。

＜この項の構成＞

(1)　同時実行スレッド数の動的変更の用途

(2)　設定変更の例

(3)　設定変更後の動作

(4)　URLグループ単位の同時実行スレッド数制御への影響

(1)　同時実行スレッド数の動的変更の用途

アプリケーションサーバを使用して構築したシステムでは，Webアプリケーション単位の最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズを，サービスを停止しないで動的に変更できます。Webアプリケーション単位の最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズは，運用管理コマンド（mngsvrutil）を使用して変更します。

Webアプリケーション単位の最大同時実行スレッド数を変更すると，次のような局面に対応できます。

Webアプリケーション単位の稼働状態でのパフォーマンスチューニング
クライアントにサービスを提供しながらパフォーマンスをチューニングできます。

アクセス状況に応じた一時的なWebアプリケーション単位の最大同時実行スレッド数の変更
アクセス状況に応じて，特定のWebアプリケーションの最大同時実行スレッド数を一時的に増加または減少させたい場合に，対処できます。

時間帯に応じた計画的なWebアプリケーション単位の最大同時実行スレッド数の変更
時間帯に応じて，Webアプリケーションの最大同時実行スレッド数を計画的に増加または減少させたい場合に，対処できます。

なお，ここで設定した項目は，サービスを停止すると無効になり，設定内容はJ2EEサーバに保存されません。また，この方法で動的に変更できるのは，Webアプリケーションについての情報だけです。Webコンテナについての設定を変更する場合は，J2EEサーバを再起動しないと有効になりません。

Webコンテナ単位の最大同時実行スレッド数を変更したい場合，また，Webアプリケーションの最大同時実行スレッド数を一時的ではなく恒常的に変更したい場合は，システムの構築時と同じ手順で設定してください。

注意

Webアプリケーションの最大同時実行スレッド数を変更した場合，URLグループ単位の最大同時実行スレッド数や占有スレッド数との関係によっては，URLグループ単位の同時実行スレッド数制御の動作へ影響が出ることがあります。詳細については「2.19.1(4)　URLグループ単位の同時実行スレッド数制御への影響」を参照してください。

(2)　設定変更の例

ここでは，特定のWebアプリケーションに対して，スループットを向上し，エラーとなるリクエストを減らしたい場合の，設定変更例を紹介します。この例では，Webアプリケーションの，最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズを増やしています。なお，同時実行スレッド数の動的変更では，Webコンテナ単位の最大同時実行スレッド数およびURLグループ単位の最大同時実行スレッド数は変更できません。

表2-60　同時実行スレッド数の動的変更の例

パラメタ | 変更前の設定値 | 変更後の設定値
Webコンテナ単位の最大同時実行スレッド数 | 10 | －
Webアプリケーションの設定 | 最大同時実行スレッド数 | 7 | 8
占有スレッド数 | 4 | 5
実行待ちキューサイズ | 8 | 10

（凡例）　－：設定を変更できない

(3)　設定変更後の動作

同時実行スレッド数の変更はすぐに反映されます。変更した直後に注意が必要な動作を次に示します。

最大同時実行スレッド数を変更した場合

最大同時実行スレッド数を増加させたとき
Webアプリケーション単位の実行待ち状態のリクエストで，実行できる状態になったリクエストはすぐに実行されます。

最大同時実行スレッド数に指定しているスレッド数をすべて使用している状態で，最大同時実行スレッド数を減少させたとき
一時的に変更後の最大同時実行スレッド数を上回るリクエストが同時に実行されます。

占有スレッド数を変更した場合

Webコンテナ単位の最大同時実行スレッド数に設定した数のスレッドをすべて使用している状態で，占有スレッド数を増加させたとき
占有スレッド数を増加させたWebアプリケーションに実行待ちのリクエストがあるときは，占有スレッド数分のリクエストはすぐ実行されます。ただし，このとき，一時的にWebコンテナ単位の最大同時実行スレッド数を超えたリクエストが同時に実行されます。

占有スレッド数を減少させたとき
占有スレッド数を減少させると，すべてのWebアプリケーション単位で共有するスレッド数が増加します。このときに，実行待ち状態で，すべてのWebアプリケーション単位で共有するスレッド数の増加によって実行できる状態になったリクエストがあれば，すぐに実行されます。

Webアプリケーション単位の実行待ちキューサイズを変更した場合

Webアプリケーション単位の実行待ちキューで，キューの上限までリクエストの待ちがある状態で，実行待ちキューサイズを減少したとき
実行待ちキューサイズを超えたリクエストはHTTP 503エラーが返ります。

(4)　URLグループ単位の同時実行スレッド数制御への影響

URLグループ単位の同時実行スレッド数制御を設定しているWebアプリケーションの同時実行スレッド数を動的に変更した場合，URLグループ単位の同時実行スレッド数の設定に影響が出ることがあります。影響が出る変更を次に示します。

Webアプリケーション単位の最大同時実行スレッド数を減らした場合

Webアプリケーション単位の最大同時実行スレッド数の減少によって，次の条件を満たしたとき，URLグループ単位の最大同時実行スレッド数は，一時的にWebアプリケーション単位の同時実行スレッド数になります。

URLグループ単位の最大同時実行スレッド数が変更される条件

URLグループ単位の最大同時実行スレッド数＞Webアプリケーション単位の最大同時実行スレッド数

ただし，URLグループ単位の最大同時実行スレッド数の設定値が変更になるわけではありません。動的変更時に設定したスレッド数までWebアプリケーション単位の最大同時実行スレッド数が減少し，URLグループ単位の最大同時実行スレッド数がWebアプリケーション単位の最大同時実行スレッド数を下回ると，URLグループ単位の最大同時実行スレッド数は設定した値で動作します。

なお，この変更によって，実行中のリクエスト処理を継続させるために，一時的に変更後のWebアプリケーション単位の最大同時実行スレッド数を上回るリクエストが同時に実行されることがあります。

Webアプリケーション単位の占有スレッド数を減らした場合

Webアプリケーション単位の占有スレッド数の減少によって，Webアプリケーション内のすべてのURLグループ単位に設定されている占有スレッド数が使用できなくなります。使用できなくなる条件を次に示します。なお，条件は，Webアプリケーション単位の最大同時実行スレッド数と占有スレッド数の関係によって異なります。

Webアプリケーション単位の最大同時実行スレッド数＝Webアプリケーション単位の占有スレッド数の場合

次に示す式を満たしたとき，URLグループ単位に設定されている占有スレッド数は使用できなくなります。

Webアプリケーション単位の占有スレッド数≦URLグループ単位の占有スレッド数の総和

Webアプリケーション単位の最大同時実行スレッド数≠Webアプリケーション単位の占有スレッド数の場合

次に示す式を満たしたとき，URLグループ単位に設定されている占有スレッド数は使用できなくなります。

Webアプリケーション単位の占有スレッド数＜URLグループ単位の占有スレッド数の総和

2.19.2　同時実行スレッド数の動的変更の流れ

Webアプリケーションの最大同時実行スレッド数を動的に変更するための準備と手順を次に示します。

準備

Webアプリケーションの最大同時実行スレッド数の動的変更は，J2EEサーバおよびWebアプリケーションを含むJ2EEアプリケーションが起動，開始されている状態で実行します。

J2EEサーバの起動ついては，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「2.2.7　J2EEサーバの起動ユーザの設定」を参照してください。J2EEアプリケーションの開始を含むシステムの起動方法については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「9.　J2EEアプリケーションを実行するシステムの運用」を参照してください。

手順

次の手順で実行します。

Webアプリケーションの稼働状況を監視して，最大同時実行スレッド数を変更する必要があるかどうかを確認する（(1)参照）
運用管理コマンドを使用して実行します。

必要と判断した場合，Webアプリケーションの最大同時実行スレッド数を変更する（(2)参照）
運用管理コマンドを使用して実行します。

Webアプリケーションの稼働状況を確認して，改善されたことを確認する（(3)参照）
運用管理コマンドを使用して実行します。

＜この項の構成＞

(1)　Webアプリケーションの稼働状況の確認

(2)　Webアプリケーションの最大同時実行スレッド数の設定変更

(1)　Webアプリケーションの稼働状況の確認

稼働中のWebアプリケーションの稼働状況を確認します。Webアプリケーションの稼働状況は，運用管理コマンド（mngsvrutil）で確認できます。確認した結果，例えば，次のような場合には，最大同時実行スレッド数を変更することを検討してください。

稼働スレッド数に比べて実行待ちスレッド数が極端に多い状況を想定していない場合に，稼働スレッド数に比べて実行待ちスレッド数が極端に多いとき

Webアプリケーション単位の実行待ちリクエスト数の現在値が，Webアプリケーション単位の実行待ちリクエスト数の最大値に近づいている状況を想定していない場合に，Webアプリケーション単位の実行待ちリクエスト数の現在値が，Webアプリケーション単位の実行待ちリクエスト数の最大値に近づいているとき

Webアプリケーション単位の実行待ちキューからリクエストがあふれる状況を想定していない場合に，その実行待ちキューからリクエストがあふれているとき
なお，監視した結果，一時的にではなく恒常的に最大同時実行スレッド数を変更する必要があると判断した場合は，動的変更をするのではなく，Webアプリケーションを停止して，最大同時実行スレッド数の設定をし直してください。Webアプリケーションを停止した状態でのWebコンテナでの最大同時実行スレッド数の制御の設定については，「2.16　Webコンテナ単位での同時実行スレッド数の制御」，「2.17　Webアプリケーション単位での同時実行スレッド数の制御」，および「2.18　URLグループ単位での同時実行スレッド数の制御」を参照してください。

Webアプリケーションの稼働状況を確認するには，mngsvrutilコマンドに，サブコマンド「get」を指定して実行します。

実行形式および実行例を次に示します。なお，mngsvrutilコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <ホスト名> -k host get webApps

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host get webApps

コマンドの実行結果は，標準出力またはファイルに出力されます。

Webアプリケーションの稼働情報のうち，Webアプリケーションの最大同時実行スレッド数を変更する場合に参考になる情報は，次に示すヘッダ情報の項目で確認できます。なお，N秒とは，運用監視で設定しているサンプリング時間です。

表2-61　 Webアプリケーションの最大同時実行スレッド数を変更する場合に参考になる情報

ヘッダ情報 | 内容
contextRoot | Webアプリケーションのコンテキストルート。
exclusiveThreadCountUpperBound | Webアプリケーションの占有スレッド数。
activeThreadCountUpperBound | Webアプリケーションの最大同時実行スレッド数。
waitingRequestCountUpperBound | Webアプリケーションの実行待ちキューサイズ。
currentThreadCountUpperBound | Webアプリケーションの同時実行可能スレッド数の上限値。
activeThreadCount | 稼働スレッド数の現在値。
activeThreadCountPeak | 稼働スレッド数のN秒ピーク。
activeThreadCountAverage | 稼働スレッド数のN秒平均値。
activeThreadCountHightWaterMark | 稼働スレッド数の最大値。
activeThreadCountLowWaterMark | 稼働スレッド数の最小値。
waitingRequestCount | Webアプリケーション単位の実行待ちリクエスト数の現在値。
waitingRequestCountPeak | Webアプリケーション単位の実行待ちリクエスト数のN秒ピーク。
waitingRequestCountAverage | Webアプリケーション単位の実行待ちリクエスト数のN秒平均値。
waitingRequestCountHighWaterMark | Webアプリケーション単位の実行待ちリクエスト数の最大値。
waitingRequestCountLowWaterMark | Webアプリケーション単位の実行待ちリクエスト数の最小値。
overflowRequestCount | Webアプリケーション単位の実行待ちキューからあふれたリクエスト数。

(2)　Webアプリケーションの最大同時実行スレッド数の設定変更

稼働状況を確認したWebアプリケーションの次の項目を，必要に応じて変更します。

最大同時実行スレッド数

占有スレッド数

実行待ちキューサイズ

これらの項目は，運用管理コマンド（mngsvrutil）を使用して変更できます。ここで設定した値は，Webアプリケーションを停止するまで有効です。

注意

Webアプリケーションの最大同時実行スレッド数の動的変更実行中（mngsvrutilコマンドにサブコマンド「change」を指定して実行している間）は，J2EEアプリケーションのデプロイおよびアンデプロイは実行しないでください。

Webアプリケーションの最大同時実行スレッド数を動的に変更するには，mngsvrutilコマンドに，サブコマンド「change」を指定して実行します。

実行形式を次に示します。なお，mngsvrutilコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <ホスト名> -k host change webAppThreadCtrl <Webアプリケーションのコンテキストルート> <最大同時実行スレッド数>,<占有スレッド数>,<Webアプリケーション単位の実行待ちキューサイズ>

次に，実行例を示します。この例では，次の表に示すように設定を変更します。なお，Webアプリケーションの名称は，「WebAP1」とします。

表2-62　 Webアプリケーション（WebAP1）の最大同時実行スレッド数の動的変更の設定例

設定対象 | 設定項目 | 変更前の設定値 | 変更後の設定値
Webコンテナ | 最大同時実行スレッド数 | 10 | 10（変更できません）
Webアプリケーション（WebAP1） | 最大同時実行スレッド数 | 7 | 8
占有スレッド数 | 4 | 5
実行待ちキューサイズ | 8 | 10

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host change webAppThreadCtrl "WebAP1" 8,5,10

設定内容は，コマンド実行後，すぐに反映されます。

2.19.3　同時実行スレッド数を動的に変更したときのWebアプリケーションの動作

ここでは，Webアプリケーションの最大同時実行スレッド数を動的に変更したときのWebアプリケーションの動作について説明します。

＜この項の構成＞

(1)　最大同時実行スレッドを変更したことによる動作

(2)　占有スレッド数を変更したことによる動作

(3)　Webアプリケーション単位の実行待ちキューサイズを変更したことによる動作

(1)　最大同時実行スレッドを変更したことによる動作

最大同時実行スレッド数を変更した場合，Webアプリケーションは次のように動作します。

最大同時実行スレッド数を増やした場合

Webアプリケーション単位の実行待ち状態だったリクエストのうち，実行可能になったリクエストが直ちに実行されます。

例えば，設定変更によって最大同時実行スレッド数を7から8に変更した場合に，Webアプリケーション単位の実行待ちキューにリクエストがあったときには，その実行待ちキューのリクエストの一つがすぐに実行されることになります。

最大同時実行スレッド数を減らした場合

実行可能な最大同時実行スレッド数が減少されます。

ただし，最大同時実行スレッド数のスレッドをすべて使用している状態で設定を変更しようとした場合，実行中のスレッド数は減らないため，一時的に最大同時実行スレッド数を超える数のスレッドが実行されます。

例えば，設定変更によって最大同時実行スレッド数を8から7に変更した場合に，その時点で使用されているスレッド数が8個あったときは，一時的に設定変更後の最大同時実行スレッド数を超える8個のスレッドが実行されます。

稼働中のスレッドの一つが終了したときにスレッド数が減らされ，以降は設定値どおり，最大で7個のスレッドが同時実行されるようになります。

(2)　占有スレッド数を変更したことによる動作

占有スレッド数を変更した場合，Webアプリケーションは次のように動作します。

占有スレッド数を増やした場合

Webアプリケーション単位の実行待ち状態だったリクエストのうち，該当するWebアプリケーションの占有スレッド数が増えたことで実行可能になったリクエストが，直ちに実行されます。

また，アクセスのピーク時など，Webコンテナ単位の最大同時実行スレッド数に設定されているスレッド数をすべて使用している状態で特定のWebアプリケーションの占有スレッド数を増やした場合，そのWebアプリケーションの実行待ちキューにリクエストがあるときには，実行待ちキューのリクエストがすぐに実行されます。これによって，一時的に，Webコンテナ単位の最大同時実行スレッド数を超える数のスレッドが実行されることがあります。

例えば，Webコンテナ単位の最大同時実行スレッド数が10で，WebアプリケーションであるWebAP1とWebAP2でそれぞれ7個と3個のスレッドを使用している状態でWebAP1の占有スレッド数を8に変更した場合，一時的にWebコンテナ単位で11個のスレッドが実行されます。

占有スレッド数を減らした場合

特定のWebアプリケーションの占有スレッド数を減らすことで，Webコンテナ単位で共有されるスレッド数が増加します。Webアプリケーション単位，URLグループ単位およびデフォルトの実行待ちキューのリクエストのうち，共有スレッド数が増えることで実行可能になったスレッドがある場合は，直ちに実行されます。

(3)　Webアプリケーション単位の実行待ちキューサイズを変更したことによる動作

Webアプリケーション単位の実行待ちキューサイズを変更した場合，Webアプリケーションは次のように動作します。

Webアプリケーション単位の実行待ちキューサイズを増やした場合

Webアプリケーション単位の実行待ちキューサイズが直ちに増やされます。

Webアプリケーション単位の実行待ちキューサイズを減らした場合

Webアプリケーション単位の実行待ちキューで待っているリクエストの数よりも少ない値にWebアプリケーション単位の実行待ちキューサイズを変更した場合，その実行待ちキューサイズを超えるリクエストはHTTP 503エラーとして返却されます。

2.19.4　同時実行スレッド数の動的変更についての注意事項

動的に変更できるのは，Webアプリケーション単位の同時実行スレッド数の設定です。Webコンテナ単位の同時実行スレッド数およびURLグループ単位の同時実行スレッド数は，動的に変更できません。

動的に変更された同時実行スレッド数の情報はJ2EEサーバには保存されません。このため，サービスを停止すると変更した値は無効になるので注意してください。

Webアプリケーション単位の同時実行スレッド数の動的変更によって，Webアプリケーション単位の共有スレッド数が0以下になると，Webアプリケーション内のすべてのURLグループ単位で設定している占有スレッド数が使用できなくなります。

2.20　エラーページのカスタマイズ

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。クライアント側では，Webコンテナから返されたエラーステータスコードに対応するエラーページが表示されます。アプリケーションサーバでは，クライアントで表示されるエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

エラーページをカスタマイズするには，Servlet仕様で規定されているweb.xmlの<error-page>タグを使用する方法と，Webサーバの機能を使用する方法があります。また，インプロセスHTTPサーバによるエラーページのカスタマイズを利用することもできます。

Webサーバの機能を使用する場合のエラーページのカスタマイズについては，「3.8　エラーページのカスタマイズ（Webサーバ連携）」を参照してください。インプロセスHTTPサーバによるエラーページのカスタマイズについては，「4.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）」を参照してください。

2.21　静的コンテンツのキャッシュ

一度アクセスした静的コンテンツは，メモリ上にキャッシュできます。一度アクセスした静的コンテンツをメモリ上にキャッシュし，2回目以降のアクセスではキャッシュからブラウザにレスポンスを返すことで，静的コンテンツのレスポンスタイムを短縮できます。

Webコンテナでは，Webアプリケーション単位でキャッシュに使用するメモリサイズの上限と，キャッシュの対象とする静的コンテンツのファイルサイズの上限を設定して，静的コンテンツのキャッシュを制御できます。

この節では，静的コンテンツのキャッシュについて説明します。

この節の構成を次の表に示します。

表2-63　この節の構成（静的コンテンツのキャッシュ）

分類 | タイトル | 参照先
解説 | 静的コンテンツのキャッシュの制御 | 2.21.1
実装 | DDでの定義（Webアプリケーション単位での設定） | 2.21.2
設定 | 実行環境での設定 | 2.21.3

注　「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.21.1　静的コンテンツのキャッシュの制御

2.21.2　DDでの定義（Webアプリケーション単位での設定）

2.21.3　実行環境での設定

2.21.1　静的コンテンツのキャッシュの制御

Webコンテナでは，Webアプリケーション単位でキャッシュに使用するメモリサイズの上限と，キャッシュの対象とする静的コンテンツのファイルサイズの上限を設定して，静的コンテンツのキャッシュを制御できます。

静的コンテンツのキャッシュの制御には次の2種類の方法があります。

Webコンテナ単位の静的コンテンツのキャッシュの制御
静的コンテンツのキャッシュをWebコンテナ単位で制御する方法です。Webコンテナ単位に，Webアプリケーション単位でキャッシュするメモリサイズの上限値と，キャッシュを許可する静的コンテンツのファイルサイズの上限値を設定します。設定したWebアプリケーション単位のキャッシュに使用するメモリサイズの上限値，および静的コンテンツのファイルサイズの上限値は，WebコンテナにデプロイされているすべてのWebアプリケーションに適用されます。

Webアプリケーション単位の静的コンテンツのキャッシュの制御
静的コンテンツのキャッシュをWebアプリケーション単位で制御する方法です。Webアプリケーション単位に，キャッシュするメモリサイズの上限値，およびキャッシュを許可するファイルサイズの上限値を設定します。
Webアプリケーション単位での制御と，Webコンテナ単位での制御の両方を設定した場合，Webアプリケーション単位での制御の設定が優先されます。

なお，Webアプリケーション単位のキャッシュするメモリサイズが上限値を超えた場合，または静的コンテンツのファイルサイズが上限値を超えた場合は，メモリ上にはキャッシュしないで，毎回ファイルシステムからブラウザにレスポンスを返します。

静的コンテンツのキャッシュの設定は，設定する範囲ごとに，次の個所に設定します。

Webコンテナ単位の静的コンテンツのキャッシュの制御
J2EEサーバのプロパティとして指定します。

Webアプリケーション単位の静的コンテンツのキャッシュの制御
Webアプリケーションの属性（プロパティ）として設定します。

注意

J2EEアプリケーションのリロード機能が有効な場合は，静的コンテンツのキャッシュ機能は無効になるので注意してください。

2.21.2　DDでの定義（Webアプリケーション単位での設定）

Webアプリケーション単位に，静的コンテンツのキャッシュ機能を使用するかどうか，キャッシュを許可する静的コンテンツのメモリサイズ，およびファイルサイズの上限値を設定します。

アプリケーションの開発環境で必要なDDでの定義について説明します。

静的コンテンツのキャッシュのWebアプリケーション単位の定義は，web.xmlの<web-app><context-param>タグ内の<param-name>タグに指定します。

DDでの静的コンテンツのキャッシュの定義について次の表に示します。

表2-64　DDでの静的コンテンツのキャッシュの定義

項目
<param-name>タグに指定するパラメタ
<param-value>タグの設定内容

静的コンテンツキャッシュ機能の有効／無効
com.hitachi.software.web.static_content.cache.enabled
静的コンテンツキャッシュ機能の有効／無効を設定します。

Webアプリケーション単位のメモリサイズ
com.hitachi.software.web.static_content.cache.size
静的コンテンツキャッシュ機能を有効にした場合，メモリにキャッシュできるサイズをbyte単位で指定します。

Webアプリケーション単位で，キャッシュの合計サイズが指定した値を超えた場合は，アクセスされていない時間が最も長いキャッシュから削除されて，キャッシュの合計サイズが設定した値以下になるまでキャッシュの削除を繰り返します。

メモリサイズが設定されていないWebアプリケーションでは，そのプロパティに指定した値が用いられます。しかし，メモリサイズが設定されているWebアプリケーションでは，そのプロパティに指定した値は用いられません。

0～2147483647までの整数値で指定します。0を指定した場合は，Webアプリケーション単位でメモリにキャッシュできるサイズに制限を設けません。

このプロパティに無効な値が設定された場合，およびキャッシュを許可するファイルサイズで指定した値よりも小さい値の場合，デフォルト値が使用されます。

このプロパティに空文字列，または空白文字が設定された場合は，デフォルト値が使用されます。

キャッシュを許可するファイルサイズ
com.hitachi.software.web.static_content.cache.filesize.threshold
静的コンテンツキャッシュ機能を有効にした場合，キャッシュできるファイルサイズをbyte単位で指定します。

指定した値を超えるサイズのファイルはキャッシュされません。

ファイルサイズが設定されていないWebアプリケーションでは，そのプロパティに指定した値が用いられます。しかし，ファイルサイズが設定されているWebアプリケーションでは，そのプロパティに指定した値は用いられません。

0～2147483647までの整数値で指定します。0を指定した場合は，キャッシュできるファイルのサイズに制限を設けません。

プロパティに無効な値が設定された場合，およびWebアプリケーション単位のメモリサイズで指定した値より大きい場合は，デフォルト値が使用されます。

このプロパティに空文字列，または空白文字が設定された場合は，デフォルト値が使用されます。

注意

次に示すパラメタは，静的コンテンツキャッシュ機能で使用するため，DDの<context-param>タグ内で任意に使用できません。

com.hitachi.software.web.static_content.cache.enabled

com.hitachi.software.web.static_content.cache.size

com.hitachi.software.web.static_content.cache.filesize.threshold

DDの定義例を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 'http://java.sun.com/dtd/web-app_2_3.dtd'>

<web-app>
  <context-param>
     <param-name>
        com.hitachi.software.web.static_content.cache.enabled
     </param-name>-
     <param-value>true</param-value>
  </context-param>

  <context-param>
     <param-name>
        com.hitachi.software.web.static_content.cache.size
     </param-name>
     <param-value>5242880</param-value>
  </context-param>

  <context-param>
     <param-name>
        com.hitachi.software.web.static_content.cache.filesize.threshold
     </param-name>
     <param-value>102400</param-value>
  </context-param>
</web-app>

定義例では，次の内容が定義されています。

静的コンテンツキャッシュ機能を有効にします。

Webアプリケーション単位のメモリサイズを5MBにします。

キャッシュを許可するファイルサイズの上限値を100KBにします。

なお，DDで無効な値や空文字が設定された場合は，Webコンテナ単位での設定内容（簡易構築定義ファイルの設定内容）が使用されます。

2.21.3　実行環境での設定

静的コンテンツのキャッシュをWebコンテナ単位に定義する場合，J2EEサーバの設定が必要です。

静的コンテンツのキャッシュをWebアプリケーション単位に定義する場合，Webアプリケーションの設定が必要です。cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

ポイント

Webコンテナ単位での設定，Webアプリケーション単位での設定をどちらも設定した場合には，Webアプリケーション単位での設定が優先されます。

＜この項の構成＞

(1)　J2EEサーバの設定（Webコンテナ単位での設定）

(2)　Webアプリケーションの設定（Webアプリケーション単位での設定）

(1)　J2EEサーバの設定（Webコンテナ単位での設定）

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナ単位での静的コンテンツのキャッシュの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでの静的コンテンツのキャッシュの定義について次の表に示します。

表2-65　簡易構築定義ファイルでの静的コンテンツのキャッシュの定義

項目 | 指定するパラメタ | 設定内容
静的コンテンツキャッシュ機能の有効／無効 | webserver.static_content.cache.enabled | 静的コンテンツのキャッシュの有効，無効，または強制無効を指定します。
Webアプリケーション単位のメモリサイズ | webserver.static_content.cache.size | 静的コンテンツのキャッシュを許可する，Webアプリケーション単位のメモリサイズを設定します。
キャッシュを許可するファイルサイズ | webserver.static_content.cache.filesize.threshold | 静的コンテンツのキャッシュを許可する，Webアプリケーション単位のファイルサイズの上限値を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　Webアプリケーションの設定（Webアプリケーション単位での設定）

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。静的コンテンツのキャッシュの定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，DDと対応しています。DDでの定義については，「2.21.2　DDでの定義（Webアプリケーション単位での設定）」を参照してください。

2.22　簡易Webサーバ機能

WebコンテナをHTTPサーバとして，スタブなどのダウンロードに利用します。この機能は，常に利用するように設定されています。

この節では，簡易Webサーバ機能について説明します。

この節の構成を次の表に示します。

表2-66　この節の構成（簡易Webサーバ機能）

分類 | タイトル | 参照先
解説 | 簡易WebサーバでのIPアドレス指定（バインド先アドレス設定機能） | 2.22.1
簡易Webサーバへのアクセスの制御 | 2.22.2
設定 | 実行環境での設定（J2EEサーバの設定） | 2.22.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

注意

簡易Webサーバは，本番運用時のWebサーバとしては利用できませんので注意してください。

簡易Webサーバでは負荷分散機のヘルスチェックは実施できません。

＜この節の構成＞

2.22.1　簡易WebサーバでのIPアドレス指定（バインド先アドレス設定機能）

2.22.2　簡易Webサーバへのアクセスの制御

2.22.3　実行環境での設定（J2EEサーバの設定）

2.22.1　簡易WebサーバでのIPアドレス指定（バインド先アドレス設定機能）

Webコンテナでは，簡易Webサーバで利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数の物理ネットワークインタフェースを持つホスト，または一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するよう設定できます。

注意

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

簡易Webサーバで利用するIPアドレスには，ループバックアドレスを指定することはできません。簡易Webサーバで利用するIPアドレスにループバックアドレスを指定した場合は，ワイルドカードアドレスを使用してサーバが起動されます。

2.22.2　簡易Webサーバへのアクセスの制御

簡易Webサーバにアクセスできるホストを制限できます。簡易Webサーバへのアクセスを許可されていないホストからのアクセスがあった場合，J2EEサーバはそのアクセスを拒否※します。デフォルトでは，ローカルホストからのアクセスだけを許可します。ホストを制限するには，アクセスを許可するホストの，ホスト名，またはIPアドレスを設定します。このとき，ホスト名やIPアドレスの代わりにアスタリスク（*）を指定すると，全ホストからのアクセスを許可する設定になります。

注※

J2EEサーバがアクセスを拒否すると，Webブラウザが自動で再接続をリトライすることがあります。再接続のリトライ回数は，Webブラウザによって異なるため，1度のアクセスで，アクセスが拒否されたことを示すメッセージが複数出力されることがあります。

2.22.3　実行環境での設定（J2EEサーバの設定）

簡易WebサーバでのIPアドレス指定（バインド先アドレス設定機能）または簡易Webサーバへのアクセスの制御を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。簡易Webサーバでの簡易Webサーバの機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでの簡易Webサーバの機能の定義について次の表に示します。

表2-67　簡易構築定義ファイルでの簡易Webサーバの機能の定義

項目 | 指定するパラメタ | 設定内容
Webサーバで使用するホストの固定 | webserver.connector.http.bind_host | 簡易WebサーバのIPアドレスまたはホスト名を指定します。
管理用サーバ | webserver.connector.http.permitted.hosts | 管理用サーバへのアクセスを許可するホストのIPアドレスまたはホスト名を指定します※。
ejbserver.http.port | 管理用サーバのポート番号を指定します。

注※　アクセスを許可するホストをホスト名で指定した場合，J2EEサーバ起動時にホスト名の名前が解決されるため，次のことに注意する必要があります。

hostsファイル，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定でサーバが起動されます。

ホスト名の解決をJ2EEサーバの起動時にするため，サーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

2.23　URIのデコード機能

URIのデコード機能は，Webサーバ連携，およびインプロセスHTTPサーバで利用できます。

この節では，URIのデコード機能について説明します。

この節の構成を次の表に示します。

表2-68　この節の構成（URIのデコード機能）

分類 | タイトル | 参照先
解説 | URIのデコード機能の概要 | 2.23.1
設定 | 実行環境での設定（J2EEサーバの設定） | 2.23.2
注意事項 | URIのデコード機能を使用する場合の注意事項 | 2.23.3

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

2.23.1　URIのデコード機能の概要

2.23.2　実行環境での設定（J2EEサーバの設定）

2.23.3　URIのデコード機能を使用する場合の注意事項

2.23.1　URIのデコード機能の概要

URIのデコード機能を使用すると，アプリケーションサーバでは，リクエストURIのサーブレットパスおよび追加のパス情報に含まれるURLエンコードされた文字列がデコードされます。ただし，コンテキストパスはデコードされません。

デコードされたURIを使用しないWebアプリケーションを実行するときは，URIのデコード機能を使用しないように設定するか，Webアプリケーション側で対応する必要があります。

URIのデコード機能の使用時に影響があるServlet API，デコードされた文字列を使用する機能，デコード時に使用される文字コード，および文字列のデコードと正規化の実行順序を次に記述します。

＜この項の構成＞

(1)　URIのデコード機能の使用時に影響があるServlet API

(2)　デコードされた文字列を使用する機能

(3)　デコード時に使用される文字コード

(4)　文字列のデコードと正規化の実行順序

(1)　URIのデコード機能の使用時に影響があるServlet API

URIのデコード機能を使用する場合，javax.servlet.http.HttpServletRequestインタフェースの次のメソッドでは，デコードされたURIが戻り値となります。

getPathInfoメソッド

getPathTranslatedメソッド

getServletPathメソッド

ただし，getRequestURIメソッドおよびgetRequestURLメソッドでは，デコードされていないURLが戻り値となります。

(2)　デコードされた文字列を使用する機能

URIのデコード機能を使用する場合，次に示すマッチング処理で，デコードされた文字列が使用されます。

サーブレットおよびJSPのURLパターンとのマッチング

デフォルトマッピングとのマッチング

静的コンテンツとのマッチング

フィルタのURLパターンとのマッチング

web.xmlの<error-page>タグ，またはJSPのpageディレクティブのerrPage属性で指定するエラーページとのマッチング

アクセスを制限するURLパターンとのマッチング

ログイン認証のURL判定

リクエストのフォワードおよびインクルード

HTTPレスポンス圧縮フィルタのURLパターンとのマッチング

URLグループ単位の同時実行スレッド数制御のURLパターンとのマッチング

ただし，コンテキストパスはデコードされないで，元の文字列のまま扱われるため，コンテキストルートと一致しない場合は「404 Not Found」が戻り値となります。

また，アプリケーションサーバの次の機能では，デコード後の文字列でのマッチングは行われません。

インプロセスHTTPサーバのエラーページのカスタマイズ機能

インプロセスHTTPサーバのリダイレクトによるリクエストの振り分け機能

(3)　デコード時に使用される文字コード

URIのデコード機能を使用する場合，デコード時に使用される文字コードはUTF-8です。

(4)　文字列のデコードと正規化の実行順序

クライアントから送信されたリクエストURIで，マッチングに利用されるURLは，デコードされたあとで正規化されます。

2.23.2　実行環境での設定（J2EEサーバの設定）

URIのデコード機能を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。URIのデコード機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.http.request.uri_decode.enabledに指定します。このパラメタでは，URIのデコード機能を使用するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

2.23.3　URIのデコード機能を使用する場合の注意事項

ここでは，URIのデコード機能を使用する場合の注意事項について説明します。

＜この項の構成＞

(1)　文字列のデコードと正規化の実行順序

(2)　リクエストの属性

(3)　HTTPセッションの引き継ぎ

(1)　文字列のデコードと正規化の実行順序

サーブレットパスとURLパターンのマッチングでは，デコードされたあとで正規化されたURIが使用されます。

コンテキストパスとコンテキストルートのマッチングでは，デコードされないで正規化されたURIが使用されます。

(2)　リクエストの属性

フォワード時またはインクルード時にリクエストに追加される属性にも，デコードされた値が格納されるものがあります。フォワード時またはインクルード時にリクエストに設定される各属性について，格納される値がデコードされるかどうかを次の表に示します。

処理 | 属性 | 格納される値のデコードの実行
フォワード | javax.servlet.forward.request_uri | ×
javax.servlet.forward.context_path | ×
javax.servlet.forward.servlet_path | ○
javax.servlet.forward.path_info | ○
javax.servlet.forward.query_string | ×
インクルード | javax.servlet.include.request_uri | ×
javax.servlet.include.context_path | ×
javax.servlet.include.servlet_path | ○
javax.servlet.include.path_info | ○
javax.servlet.include.query_string | ×

（凡例）

○：デコードされる

×：デコードされない

各属性および各属性に格納される値については，サーブレット仕様書を参照してください。

(3)　HTTPセッションの引き継ぎ

コンテキストパスはデコードされないで，元の文字列のまま扱われるため，HTTPセッションは引き継がれます。

2.24　 Webアプリケーションのバージョン設定機能

この節では，Webアプリケーションのバージョン設定機能について説明します。

この節の構成を次の表に示します。

表2-69　この節の構成（Webアプリケーションのバージョン設定機能）

分類 | タイトル | 参照先
解説 | Webアプリケーションのバージョン設定機能の概要 | 2.24.1
JSPファイルおよびタグファイルのコンパイルと実行 | 2.24.2
設定 | 実行環境での設定 | 2.24.3
注意事項 | Webアプリケーションのバージョン指定機能を使用する場合の注意事項 | 2.24.4

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

2.24.1　Webアプリケーションのバージョン設定機能の概要

2.24.2　 JSPファイルおよびタグファイルのコンパイルと実行

2.24.3　実行環境での設定

2.24.4　Webアプリケーションのバージョン指定機能を使用する場合の注意事項

2.24.1　Webアプリケーションのバージョン設定機能の概要

アプリケーションサーバでは，Webアプリケーションの実行時に，web.xmlに定義されているWebアプリケーションのバージョンに準拠して，ServletやJSPが実行されます。

Webアプリケーションのバージョン設定機能は，Webアプリケーション実行時のバージョンを指定するための機能です。この機能を使用すると，web.xmlで定義されているWebアプリケーションのバージョンを変更しないで，設定したバージョンに準拠してWebアプリケーションを実行できます。

Webアプリケーションのバージョン設定機能を使用する場合と使用しない場合では，次の違いがあります。

Webアプリケーションのバージョン設定機能を使用する場合

旧バージョンで作成したWebアプリケーションの実行時に，新バージョンに準拠してServletやJSPを実行させるために，web.xmlに定義されているWebアプリケーションのバージョンを変更する必要はありません。

実行したいWebアプリケーションのバージョンを設定すれば，web.xmlを変更したときと同様に，JSPコンパイルでの文法チェックおよびサーブレットAPIの動作が変更されます。ただし，web.xmlに定義が必要な機能は使用できません。

Webアプリケーションのバージョン設定機能を使用しない場合

旧バージョンで作成したWebアプリケーションの実行時に，新バージョンに準拠してServletやJSPを実行させるためには，web.xmlに定義されているWebアプリケーションのバージョンを変更する必要があります。

web.xmlで定義されているWebアプリケーションのバージョンごとに，Webアプリケーションのバージョン設定機能で設定したバージョンによる動作の違いを次に示します。

表2-70　Webアプリケーションのバージョン設定機能で設定したバージョンによる動作の違い

web.xmlで
定義されている
バージョン
Webアプリケーションのバージョン設定機能で
設定したバージョン

指定なし
2.4
2.5

2.2
2.3として動作する※1
2.4として動作する
2.5として動作する

2.3
2.3として動作する

2.4
2.4として動作する

2.5
2.5として動作する
2.5※2として動作する

注※1　web.xmlで定義されているバージョンが2.2の場合，Webアプリケーションのバージョン設定機能で何も設定しないときは，2.3のWebアプリケーションとして動作します。

注※2　web.xmlで定義されているバージョンが2.5の場合，Webアプリケーションのバージョン設定機能で2.4を設定しても，2.5のWebアプリケーションとして動作します。

注意

Webアプリケーションのバージョン設定機能は，旧バージョンのアプリケーションの移行などを支援するための機能です。新規にアプリケーションを開発する場合に使用することは推奨しません。

新規にアプリケーションを開発する場合は，正しいバージョンのweb.xmlを指定してください。

2.24.2　 JSPファイルおよびタグファイルのコンパイルと実行

Webアプリケーションのバージョン設定機能を使用する際で，JSPファイルおよびタグファイルのコンパイル時と実行時でJSP仕様のバージョンが異なる場合の実行時の動作について説明します。ここでは，JSP事前コンパイル機能を使用している場合と，使用していない場合に分けて説明します。

＜この項の構成＞

(1)　JSP事前コンパイル機能を使用している場合

(2)　JSP事前コンパイル機能を使用していない場合

(1)　JSP事前コンパイル機能を使用している場合

JSP事前コンパイル機能では，JSPファイルのコンパイル時に，JSPファイルから生成されたクラスファイルだけでなく，バージョン情報ファイルも作成されます。バージョン情報ファイルは，JSP事前コンパイル機能実行時に出力されるファイルで，JSPファイルのバージョンが記載されています。

このため，JSPのバージョンが異なる状態には，次の二つの場合があります。

バージョン情報ファイルとWebアプリケーション実行時のWebアプリケーションバージョンに対応するJSP仕様のバージョンが異なる場合

JSP事前コンパイル機能によってJSPファイルから生成されたクラスファイルのバージョンと，それに対応するJSP仕様のバージョンが異なる場合

それぞれの場合について，Webアプリケーションの動作を，次の表に記述します。

表2-71　バージョン情報ファイルとJSP仕様のバージョンが異なる場合

ファイル変更のタイミング | Webアプリケーションの動作
Webアプリケーション開始前 | ケース1
Webアプリケーション開始後 | リロード有効時 | ケース2
リロード無効時

ケース1

Webアプリケーション開始前にJSP事前コンパイルコマンドが実行されている場合，Webアプリケーション開始時にKDJE39522-Eが出力されて，Webアプリケーションの開始に失敗します。

ケース2

J2EEサーバの再起動またはWebアプリケーションの再開始後，ケース1と同じ動作になります。

表2-72　クラスファイルとJSP仕様のバージョンが異なる場合

ファイル変更のタイミング | Webアプリケーションの動作
Webアプリケーション開始前 | ケース3
Webアプリケーション開始後 | リロード有効時 | ケース4
リロード無効時 | ケース5

ケース3

web.xmlで<load-on-startup>が指定されているJSPファイルの場合
WAR属性ファイルまたはcosminexus.xmlの<start-notify-error>タグにtrueが指定されているとき，またはタグの指定が省略されているときは，Webアプリケーション開始時にKDJE39298-Eが出力されて，Webアプリケーションの開始に失敗します。
cosminexus.xmlの<start-notify-error>タグにfalseが指定されているときは，Webアプリケーション開始時にKDJE39298-Eが出力されますが，Webアプリケーションの開始は成功します。ただし，リクエスト時にKDJE39298-Eが出力されて，エラーコード500（Internal Server Error）が返されます。

web.xmlで<load-on-startup>が指定されていないJSPファイルの場合
初回リクエスト時にKDJE39298-Eが出力されて，エラーコード500（Internal Server Error）が返されます。

ケース4

実行済みのJSPファイルの場合
J2EEサーバの再起動またはWebアプリケーションの再開始後，ケース3と同じ動作になります。

未実行のJSPファイルの場合
ケース3の「web.xmlで<load-on-startup>が指定されていないJSPファイルの場合」と同じ動作になります。

ケース5

実行済みのJSPファイルの場合
リロード実行時にKDJE39317-Eが出力されて，JSPのリロードが失敗します（該当するリクエストからエラーコード500（Internal Server Error）が返されます）。

未実行のJSPPファイルの場合
ケース4の「未実行のJSPファイルの場合」と同じ動作になります。

注意

クラスファイルだけが異なるケース（ケース3，ケース4，ケース5）は，異なるバージョンを指定してJSP事前コンパイルコマンドでコンパイルしたクラスファイルで上書きした場合を想定しています。そのため，Webアプリケーション開始時のJSP事前コンパイル機能は該当しません。

Webアプリケーション開始時のJSP事前コンパイル機能は，Webアプリケーション開始後にバージョン情報ファイルを更新できない（ケース2）ため，該当しません。

ケース1でWebアプリケーション開始時のJSP事前コンパイル機能を使用してWebアプリケーションを開始した場合は，バージョン情報ファイル自体を再作成するため，エラーにはなりません。また，Webアプリケーション開始前に，JSP事前コンパイルコマンドを実行する場合は，コマンド内でバージョンのチェックを実施しているため，コマンド実行時にバージョンの不一致を検知してエラーとなることがあります。

JSP事前コンパイルで個別のJSPファイルを指定してJSPコンパイルを実行する場合は，既存のバージョン情報ファイルで指定されたJSP仕様のバージョンと，コンパイル時のJSP仕様のバージョンが比較されます。その際，バージョンが異なるときはKDJE39522-Eが出力されてエラーとなります。個別のJSPファイルを指定しない場合は，バージョン情報ファイルが再作成されるため，エラーにはなりません。

(2)　JSP事前コンパイル機能を使用していない場合

コンパイル時のWebアプリケーションバージョンと実行時のWebアプリケーションバージョンが異なるクラスファイルの場合，KDJE39334-Iが出力されて，JSPファイルとタグファイルが再コンパイルされます。

コンパイル時のWebアプリケーションバージョンと実行時のWebアプリケーションが異なる場合の再コンパイルの動作を次に示します。

コンパイル時のバージョン | 実行時のバージョン（JSP仕様のバージョン）
web.xmlのバージョン | ファイル種別 | TLDのバージョン | 2.2 | 2.3 | 2.4 | 2.5
2.2 | JSPファイル | － | － | － | 2.0 | 2.1
2.3 | － | － | × | 2.0 | 2.1
2.4 | JSPファイル | － | 1.2※1 | 1.2 | × | 2.1
タグファイル | 2.0 | － | － | × | ×※2
2.5 | JSPファイル | － | 1.2※1 | 1.2 | 2.0 | ×
タグファイル | 2.0 | － | － | × | ×※2
2.1 | － | － | 2.0 | ×

（凡例）

－：該当しない

×：再コンパイルされない

1.2：JSP1.2仕様で再コンパイルされる

2.0：JSP2.0仕様で再コンパイルされる

2.1：JSP2.1仕様で再コンパイルされる

注※1

web.xmlのバージョンが2.2の場合はWebアプリケーションバージョン2.3として動作するため，JSP1.2仕様で再コンパイルされます。

注※2

JSP2.1仕様では，タグファイルはTLDファイルに定義されるJSPバージョンによって準拠するJSP仕様が決定されます。Webアプリケーションバージョンが2.5でも，タグファイルはJSP2.0仕様で動作できるため，再コンパイルされません。

2.24.3　実行環境での設定

Webアプリケーションのバージョン設定機能を使用する場合，J2EEサーバおよびJSP事前コンパイルのコマンド設定が必要です。

＜この項の構成＞

(1)　J2EEサーバの設定

(2)　JSP事前コンパイルのコマンドでの設定

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webアプリケーションのバージョン設定機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.application.lower_versionに指定します。このパラメタでは，Webアプリケーションのバージョン設定機能を使用するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　JSP事前コンパイルのコマンドでの設定

JSP事前コンパイルの設定は，cjjspcコマンドの-lowerversionオプションで実施します。cjjspcコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

2.24.4　Webアプリケーションのバージョン指定機能を使用する場合の注意事項

ここでは，Webアプリケーションのバージョン設定機能を使用する場合の注意事項について説明します。

＜この項の構成＞

(1)　アノテーションの使用

(2)　J2EEアプリケーションのエクスポート

(1)　アノテーションの使用

Webアプリケーションのバージョン設定機能でアノテーションを使用できるWebアプリケーションのバージョンを設定しても，アノテーション情報は読み込まれません。

(2)　J2EEアプリケーションのエクスポート

Webアプリケーションのバージョン設定機能を有効にして，Webアプリケーションをエクスポートした場合，Webアプリケーションのバージョン設定機能で設定したバージョンに変更されてエクスポートはされません。インポートしたときと同じバージョンのWebアプリケーションがエクスポートされます。

2.25　POSTデータ最大サイズについての注意事項

Webコンテナで取り扱えるPOSTデータの最大サイズは2GBです。また，Webコンテナの設定や，WebコンテナのフロントにあるWebサーバやリダイレクタの設定によって，取り扱えるPOSTデータの最大サイズは制限されます。

3.　Webサーバ連携

この章では，Webサーバ連携に関する機能について説明します。

＜この章の構成＞

3.1　この章の構成

3.2　Webサーバ（リダイレクタ）によるリクエストの振り分け

3.3　URLパターンでのリクエストの振り分け

3.4　ラウンドロビン方式によるリクエストの振り分け

3.5　POSTデータサイズでのリクエストの振り分け

3.6　通信タイムアウト（Webサーバ連携）

3.7　IPアドレス指定（Webサーバ連携）

3.8　エラーページのカスタマイズ（Webサーバ連携）

3.9　ドメイン名指定でのトップページの表示

3.10　Webコンテナへのゲートウェイ情報の通知

3.1　この章の構成

アプリケーションサーバでは，Webサーバと連携するためのリダイレクタの機能を提供しています。リダイレクタとは，Webコンテナで提供しているライブラリです。リダイレクタをWebサーバに登録することで，WebサーバあてのHTTPリクエストのうち特定のリクエストを，指定したWebコンテナに処理させたり，複数のWebコンテナにリクエストを振り分けて処理させたりできるようになります。

Webサーバ連携に関する機能と参照先を次の表に示します。

表3-1　Webサーバ連携に関する機能と参照先

機能 | 参照先
Webサーバ（リダイレクタ）によるリクエストの振り分け | 3.2
URLパターンでのリクエストの振り分け | 3.3
ラウンドロビン方式によるリクエストの振り分け | 3.4
POSTデータサイズでのリクエストの振り分け | 3.5
通信タイムアウト（Webサーバ連携） | 3.6
IPアドレス指定（Webサーバ連携） | 3.7
エラーページのカスタマイズ（Webサーバ連携）※ | 3.8
ドメイン名指定でのトップページの表示 | 3.9
Webコンテナへのゲートウェイ情報の通知 | 3.10

注※

WebサーバとしてHitachi Web Serverを使用する場合だけ使用できる機能です。Microsoft IISを使用する場合，この機能は使用できません。

また，Webサーバと連携した場合，Hitachi Web ServerのSSLによる認証やデータ暗号化，およびMicrosoft IISのSSLによる認証やデータ暗号化の機能も使用できます。Hitachi Web ServerのSSLによる認証やデータ暗号化については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「9.2.5　Hitachi Web ServerのSSLの設定」または「9.2.6　Hitachi Web ServerのSSLの設定（Webリダイレクタ環境の場合）」を参照してください。Microsoft IISのSSLによる認証やデータ暗号化については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「9.2.7　Microsoft IISの設定（Webリダイレクタ環境の場合）」を参照してください。なお，この機能が使用できるのはWebリダイレクタ環境でだけです。

なお，アプリケーションサーバで提供するWebサーバ連携の機能には，Java EEで規定された機能にアプリケーションサーバ独自の機能を拡張したものと，アプリケーションサーバ独自の機能として提供しているものがあります。アプリケーションサーバ独自の機能かどうかについては，「1.2　システムの目的と機能の対応」を参照してください。

Webサーバと連携する場合に必要な環境設定

Webサーバと連携する場合，次に示す環境設定が必要です。

Smart Composerを使用する場合

「付録B　Hitachi Web Serverの設定に関する注意事項」を参照して，Hitachi Web Serverの環境設定をしてください。

Smart Composerを使用しない場合

次のどれかのWebサーバの環境を設定してください。

Hitachi Web Server（付録B）

Microsoft IIS（付録C）

Web Redirector（付録D）

3.2　Webサーバ（リダイレクタ）によるリクエストの振り分け

この節では，リダイレクタを使用したリクエストの振り分けについて説明します。

この機能は，Webサーバ連携機能を使用する場合に使用できます。リクエストの振り分けをするには，Webサーバ/リダイレクタが動作しているホストに対して，振り分けを定義する必要があります。

この節の構成を次の表に示します。

表3-2　この節の構成（Webサーバ（リダイレクタ）によるリクエストの振り分け）

分類 | タイトル | 参照先
解説 | リダイレクタを使用したリクエスト振り分けの仕組み | 3.2.1
リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合） | 3.2.2
リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合） | 3.2.3
注意事項 | Webサーバ連携時の注意事項 | 3.2.4

注　「実装」，「設定」，および「運用」について，この機能固有の説明はありません。

なお，使用するWebサーバの種類によって，必要な定義が異なります。また，Webサーバの種類がHitachi Web Serverの場合は，使用するシステムの構築支援機能の種類によっても定義が異なります。使用するWebサーバの種類と定義を次の表に示します。

表3-3　使用するWebサーバの種類と定義

Webサーバの種類
システムの構築支援機能の種類
定義

Hitachi Web Server
Smart Composer機能

簡易構築定義ファイルの定義

workers.propertiesの定義

mod_jk.confの定義

Smart Composer機能以外

workers.propertiesの定義

mod_jk.confの定義

Microsoft IIS
－

workers.propertiesの定義

uriworkermap.propertiesの定義

isapi_redirect.confの定義

（凡例）－：該当しない

インプロセスHTTPサーバを使用する場合のリダイレクトによるリクエストの振り分けについては，「4.7　リダイレクトによるリクエストの振り分け」を参照してください。

＜この節の構成＞

3.2.1　リダイレクタを使用したリクエスト振り分けの仕組み

3.2.2　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）

3.2.3　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）

3.2.4　Webサーバ連携時の注意事項

3.2.1　リダイレクタを使用したリクエスト振り分けの仕組み

リダイレクタを使用すると，WebサーバあてのHTTPリクエストのうち，特定のリクエストを，指定したWebコンテナに処理させたり，複数のWebコンテナにリクエストを振り分けて処理させたりできます。

リダイレクタを使用してリクエストを振り分ける場合，ワーカプロセス※というWebサーバの背後で動作するWebコンテナの実行プロセスを使用します。ワーカプロセスは，リダイレクタを経由して，サーブレット，JSPを含むリクエストを処理するプロセスです。Webサーバとワーカプロセスとの間のデータ交換は，TCP/IPに基づき，ユーザが設定する特定のポート番号を通じて実行されます。リダイレクタの設定は，ワーカというWebコンテナを抽象化した設定単位を使用して行います。ワーカには，単体のJ2EEサーバを表すワーカと，クラスタ構成のJ2EEサーバを表すワーカがあります。J2EEサーバへリクエストを転送するワーカを転送先ワーカと呼びます。転送先ワーカはワーカタイプがajp13のワーカです。

注※

ワーカプロセスは，実際には，J2EEサーバとなります。

＜この項の構成＞

(1)　リクエストの転送パターン

(2)　リクエストの振り分け方法

(1)　リクエストの転送パターン

リダイレクタからワーカプロセスへのリクエストの転送には，次に示すパターンがあります。

一つのWebサーバから一つのワーカプロセスへの転送

一つのWebサーバから複数のワーカプロセスへの転送

なお，Webサーバとワーカプロセスは，同一のマシン上にあっても，異なるマシン上にあってもかまいません。

リダイレクタからワーカプロセスへのリクエスト転送パターンを次の図に示します。

図3-1　一つのWebサーバから一つのワーカプロセスへの転送

図3-2　一つのWebサーバから複数のワーカプロセスへの転送

複数のWebコンテナへリクエストを振り分けるには，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカプロセスを振り分け先として定義します。

(2)　リクエストの振り分け方法

リダイレクタを使用してリクエストを振り分ける方法には，次の3種類があります。

URLパターンによって振り分ける方法
一つのWebコンテナに特定の処理をさせたい場合，および複数のWebコンテナに処理を振り分けたい場合に使用します。
ワーカプロセスが一つの場合と複数の場合に使用できます。

ロードバランサを使用してラウンドロビン方式で振り分ける方法
複数のWebコンテナに処理を振り分けたい場合に使用します。

POSTデータサイズによって振り分ける方法
複数のWebコンテナに処理を振り分けたい場合に使用します。この振り分け方法は，WebサーバにHitachi Web Serverを使用している場合にだけ設定できます。
なお，次の機能を使用している場合，この振り分け方法は適用できません。

セッションフェイルオーバ機能

ラウンドロビン方式によるリクエストの振り分け

ワーカプロセスを作成するには，ワーカ定義ファイルと呼ばれるファイル（workers.properties）に，次の属性を定義します。

ワーカ名

ワーカのタイプ

ワーカが動作しているホスト名，またはIPアドレス

ワーカが受け付けるポート番号

標準で提供されるworkers.propertiesには，あらかじめ次に示すワーカが定義されています。WebサーバとWebコンテナを同一のホスト上で動作させる場合には，これらのパラメタを変更する必要はありません。

ワーカの属性 | パラメタ
ワーカ名 | worker1
ワーカのタイプ | ajp13
ホスト名 | localhost
ポート番号 | 8007

ワーカプロセスの定義方法の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.5　workers.properties（ワーカ定義ファイル）」を参照してください。

3.2.2　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）

リクエストを振り分けるためには，次のユーザ定義ファイルをテキストエディタなどで編集して，ワーカ，URLパターンとワーカのマッピング，リダイレクタの動作を設定します。

簡易構築定義ファイル
ワーカの定義，およびワーカごとのパラメタ，URLパターンとワーカのマッピングを設定します。URLパターンでのリクエスト振り分けを設定する場合に使用します。ラウンドロビン方式によるリクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けの場合，設定内容が物理ティアがfree-tierに出力されます。

workers.properties（ワーカ定義ファイル）
ワーカの定義，およびワーカごとのパラメタを設定します。ラウンドロビン方式によるリクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けを設定する場合に使用します。

mod_jk.conf（リダイレクタ動作定義ファイル）
Hitachi Web ServerへのリクエストでどのURLパターンがWebコンテナへ転送されるかというURLパターンとワーカのマッピング，リダイレクタの動作を設定します。ラウンドロビン方式によるリクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けを設定する場合に使用します。

ユーザ定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「8.1.2　システム構築で使用するファイル」を参照してください。簡易構築定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。ワーカ定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.5　workers.properties（ワーカ定義ファイル）」を参照してください。リダイレクタ動作定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.2　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

3.2.3　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）

リクエストを振り分けるためには，次のユーザ定義ファイルをテキストエディタなどで編集して，ワーカ，URLパターンとワーカのマッピング，リダイレクタの動作を設定します。

設定するファイルは，使用するWebサーバによって異なります。共通のユーザ定義ファイルと，Webサーバごとのユーザ定義ファイルを分けて説明します。なお，ユーザ定義ファイルのうち，httpsd.confの詳細については，マニュアル「Hitachi Web Server」を参照してください。ほかのユーザ定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

注意

Web Redirectorを使用してWebリダイレクタ環境を構築する場合は，各ユーザ定義ファイルの格納ディレクトリの「<Cosminexusのインストールディレクトリ>¥CCまたは/opt/Cosminexus/CC」を，「<Cosminexusのインストールディレクトリ>¥CCRまたは/opt/Cosminexus/CCR」と読み替えてください。

＜この項の構成＞

(1)　共通のユーザ定義ファイル

(2)　Hitachi Web Serverを使用する場合のユーザ定義ファイル

(3)　Microsoft IISを使用する場合のユーザ定義ファイル

(4)　注意事項

(1)　共通のユーザ定義ファイル

Hitachi Web Server，Microsoft IISを使用する場合で共通のユーザ定義ファイルを次に示します。

workers.properties（ワーカ定義ファイル）
ワーカの定義，およびワーカごとのパラメタを設定します。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥workers.properties

UNIXの場合
/opt/Cosminexus/CC/web/redirector/workers.properties

usrconf.properties（ユーザプロパティファイル）
リダイレクタからのリクエストをWebコンテナで受信するときの通信タイムアウトを設定します。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties

UNIXの場合
/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.properties

(2)　Hitachi Web Serverを使用する場合のユーザ定義ファイル

Hitachi Web Serverを使用する場合のユーザ定義ファイルを次に示します。

mod_jk.conf（リダイレクタ動作定義ファイル）
Hitachi Web Serverでのリダイレクタの動作を設定します。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥mod_jk.conf

UNIXの場合
/opt/Cosminexus/CC/web/redirector/mod_jk.conf

httpsd.conf（Hitachi Web Server定義ファイル）
Hitachi Web Serverの動作環境を定義するディレクティブ（Webサーバの実行環境を定義するパラメタ）を設定します。
ファイルの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥httpsd¥conf¥httpsd.conf

UNIXの場合
/opt/hitachi/httpsd/conf/httpsd.conf

(3)　Microsoft IISを使用する場合のユーザ定義ファイル

Microsoft IISを使用する場合のユーザ定義ファイルを次に示します。

uriworkermap.properties（マッピング定義ファイル）
Microsoft IISでのURLパターンとワーカのマッピングを設定します。
ファイルの格納場所を次に示します。
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥uriworkermap.properties

isapi_redirect.conf（リダイレクタ動作定義ファイル）
Microsoft IISでのリダイレクタの動作を設定します。
ファイルの格納場所を次に示します。
<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.conf

(4)　注意事項

ユーザ定義ファイルに関する注意事項を次に示します。

上書きインストールの場合，ユーザ定義ファイルは上書きされません。

アップグレードインストールの場合のワーカ定義ファイル，およびWebサーバ定義ファイルの処理については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「12.　旧バージョンのアプリケーションサーバからの移行」を参照してください。

リダイレクタの定義ファイルの1行の最大文字数は，1,023文字です。この文字数内で定義してください。

次のユーザ定義ファイルで，同じ名称のパラメタが複数指定されている場合は，最初に指定されたパラメタの値を使用して動作します。

isapi_redirect.conf

workers.properties

uriworkermap.properties

3.2.4　Webサーバ連携時の注意事項

Webサーバと連携するときの注意事項について説明します。

＜この項の構成＞

(1)　Webコンテナが送受信できるリクエストヘッダおよびレスポンスヘッダの上限値

(2)　Hitachi Web Serverを使用するときの注意事項

(3)　Microsoft IISを使用するときの注意事項

(1)　Webコンテナが送受信できるリクエストヘッダおよびレスポンスヘッダの上限値

Webサーバと連携する場合，Webコンテナで送受信できるリクエストヘッダおよびレスポンスヘッダには上限があります。上限はそれぞれ16KBです。16KBを超えるヘッダの送受信はできないので注意してください。

(2)　Hitachi Web Serverを使用するときの注意事項

アプリケーションサーバで構築したシステムでは，Hitachi Web Serverの仮想ホスト機能を使用できません。同一ホスト上で，複数のHitachi Web Serverを起動したい場合は，Management Serverを使用してください。

(3)　Microsoft IISを使用するときの注意事項

Microsoft IISを使用するときの注意事項を説明します。

Microsoft IISで複数のWebサイトを構築している場合，これらのWebサイトと同時に連携することはできません。複数のWebサイトを構築している場合は，Webサイトごとにリダイレクタの設定をしてください。

Microsoft IIS用リダイレクタでは，Webコンテナに転送するリクエストについては，リクエストURL情報を変更します。変更したリクエストURLはISAPIフィルタ内で使用します。
このため，Microsoft IIS用リダイレクタ以降に実行されるISAPIフィルタでは，Microsoft IISが最初に受信したリクエストURLを取得できません。Microsoft IISが受信したリクエストURLをISAPIフィルタで取得したい場合は，ISAPIフィルタの優先順位をMicrosoft IIS用リダイレクタよりも高く設定する必要があります。なお，優先順位を調整するために，Microsoft IIS用リダイレクタの優先順位を「中」または「低」に変更する必要がある場合は，Microsoft IIS用リダイレクタ動作定義ファイルのfilter_priorityキーで指定します。filter_priorityキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.2　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

Microsoft IISと連携する場合，次のHTTPリクエストヘッダはWebクライアントで指定していても，Webアプリケーションでは受信できません。

tomcaturl

tomcatquery

tomcatworker

tomcattranslate

これらのHTTPリクエストヘッダはリダイレクタで使用されます。

Microsoft IISと連携する場合，POSTデータサイズによるリクエストの振り分けは設定できません。

3.3　URLパターンでのリクエストの振り分け

この節では，URLパターンでのリクエストの振り分けについて説明します。

HTTPリクエストに含まれるURLパターンによって，リクエストを振り分けます。これによって，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて処理を振り分けたりできます。

この節の構成を次の表に示します。

表3-4　この節の構成（URLパターンでのリクエストの振り分け）

分類 | タイトル | 参照先
解説 | URLパターンでのリクエストの振り分けの概要 | 3.3.1
URLパターンの種類と適用されるパターンの優先順位 | 3.3.2
設定 | 実行環境での設定（Smart Composer機能を使用する場合） | 3.3.3
実行環境での設定（Smart Composer機能を使用しない場合） | 3.3.4

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

3.3.1　URLパターンでのリクエストの振り分けの概要

3.3.2　URLパターンの種類と適用されるパターンの優先順位

3.3.3　実行環境での設定（Smart Composer機能を使用する場合）

3.3.4　実行環境での設定（Smart Composer機能を使用しない場合）

3.3.1　URLパターンでのリクエストの振り分けの概要

Webコンテナに転送するリクエストは，URLパターンとワーカプロセスのマッピングによって定義します。リダイレクタは設定されたURLパターンに従って，リクエストを転送するWebコンテナを切り替えます。

例えば，「『/examples/』というURLを含むHTTPリクエストをWebコンテナで処理する」という定義や，「『/examples1/』というURLを含むHTTPリクエストはWebコンテナAで，『/examples2/』というURLを含むHTTPリクエストはWebコンテナBで処理する」などの定義ができます。

リダイレクタによるリクエストの振り分けの例を，次の図に示します。

図3-3　リダイレクタによるリクエストの振り分け（特定のリクエストをWebコンテナに転送する場合）

図3-4　リダイレクタによるリクエストの振り分け（リクエストを複数のWebコンテナに振り分けて転送する場合）

3.3.2　URLパターンの種類と適用されるパターンの優先順位

リダイレクタのURLマッピングには次の４種類のURLパターンを指定できます。

完全パス指定
完全に一致するパターンです。

例：

URLパターンが"/examples/jsp/index.jsp"で，URLが"/examples/jsp/index.jsp"の場合，一致となります。

パス指定
パスが一致するパターンです。

例：

URLパターンが"/examples/*"で，URLが"/examples/jsp/index.jsp"などの場合，一致となります。

拡張子指定
拡張子が一致するパターンです。指定されたパス以下のすべての階層に適用されます。

例：

URLパターンが"/examples/*.jsp"で，URLが"/examples/jsp/index.jsp"などの場合，一致となります。

サフィックス指定
サフィックスが一致するパターンです。指定されたパス以下のすべての階層に適用されます。

例：

URLパターンが"/examples/servlet/*Servlet"で，URLが"/examples/servlet/HelloServlet"などの場合，一致となります。

これらの四つのURLパターンへのマッピングのうち，最優先されるURLパターンは，「完全パス指定」です。「完全パス指定」に一致しない場合，次に示す順序でパスの一致が判定され，適用されるURLパターンが決定します。

「完全パス指定」に一致しない場合
「パス指定」「拡張子指定」「サフィックス指定」のうち，最長一致のものが適用されます。最長一致とは，先頭("/")から"*"の上位パスまでができるだけ長いものに一致することを示します。
次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/* worker1

/examples/jsp/* worker2

この場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用され，URLが"/examples/test/index.jsp"の場合にはworker1のマッピングが適用されます。

1.の条件に加えて，最長一致する「パス指定」「拡張子指定」「サフィックス指定」が複数存在する場合
「パス指定」より，「拡張子指定」または「サフィックス指定」が優先されます。
次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/jsp/* worker1

/examples/jsp/*.jsp worker2

この場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用され，URLが"/examples/jsp/test.html"の場合にはworker1のマッピングが適用されます。

1.および2.の条件に加えて，最長一致する「拡張子指定」「サフィックス指定」が複数存在する場合
あとに指定したURLパターンが優先されます。
次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/*.jsp worker1

/examples/*jsp worker2

この順番に指定されていた場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用されます。

注意

URLパターンでの注意事項を次に示します。

URLパターンの先頭に"/"以外を指定した場合，そのマッピングは無視されます。

指定できる"*"は一つだけです。

"*"の前は"/"である必要があります。

同じURLパターンのマッピングを複数記述しないでください。複数記述したときの動作は保証できません。

3.3.3　実行環境での設定（Smart Composer機能を使用する場合）

HTTPリクエストに含まれるURLパターンによってリクエストを振り分けることで，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて振り分けたりできます。なお，URLパターンによる振り分けは，原則としてWebアプリケーション単位で振り分けます。URLパターンは，リダイレクタの動作として定義します。

＜この項の構成＞

(1)　設定の手順

(2)　簡易構築定義ファイルでの設定

(3)　設定例

(1)　設定の手順

URLパターンによるリクエストの振り分けは，次の手順で設定します。

簡易構築定義ファイルで，ワーカ，およびURLパターンとワーカのマッピングを定義します。
ワーカ名のリスト，ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名などを設定します。
また，すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。
Webサーバの設定については，「付録B　Hitachi Web Serverの設定に関する注意事項」を参照してください。

(2)　簡易構築定義ファイルでの設定

URLパターンによるリクエストの振り分けの定義は，簡易構築定義ファイルで，論理Webサーバ（web-server）の<configuration>タグ内に定義します。

簡易構築定義ファイルでのURLパターンによるリクエストの振り分けの定義について次の表に示します。

表3-5　簡易構築定義ファイルでのURLパターンによるリクエストの振り分けの定義

分類
パラメタ
説明

ワーカの定義
worker.list
一つまたは複数のワーカ名のリストを指定します。

worker.<ワーカ名>.host
ワーカのホスト名，またはIPアドレスを指定します。

worker.<ワーカ名>.port
ワーカのポート番号を指定します。

worker.<ワーカ名>.type
ワーカのタイプ（ajp13，lbまたはpost_size_lb）を指定します。

worker.<ワーカ名>.cachesize
リダイレクタで再利用するワーカのコネクション数を指定します。
Windowsの場合にだけ指定できます。

worker.<ワーカ名>.receive_timeout
通信タイムアウト値を指定します。

worker.<ワーカ名>.delegate_error_code
エラーページの作成をWebサーバに委任する場合に利用するエラーステータスコードを指定します。

URLパターンとワーカのマッピングの定義
JkMount
URLパターンと，worker.listで指定されているワーカのどれかとの組み合わせを指定します。

注　<ワーカ名>には，worker.listパラメタで指定したワーカの名称を定義します。

(3)　設定例

URLパターンでのリクエスト振り分けの例を次の図に示します。

図3-5　URLパターンでのリクエスト振り分けの例

この例では，ホストAにはWebアプリケーション「app1」，ホストBにはWebアプリケーション「app2」がそれぞれデプロイされています。処理したいWebアプリケーション名をリクエストのURLパターンに含めることで，「/app1/*」というURLパターンを持つリクエストはホストAで，「/app2/*」というURLパターンを持つリクエストはホストBで処理できるようにします。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

簡易構築定義ファイルの例を次に示します。ここでは，複数のWebコンテナへリクエストを振り分けるので，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカを振り分け先として指定します。また，「/app1/*」というURLパターンと「worker1」，「/app2/*」というURLパターンと「worker2」とをマッピングします。

なお，この構成を実現するためには，複数のWebシステムに分割して構築する必要があります。

簡易構築定義ファイルの例

：
<param>
 <param-name>JkMount</param-name>
 <param-value>/app1/* worker1</param-value>
 <param-value>/app2/* worker2</param-value>
</param>
<param>
 <param-name>worker.list</param-name>
 <param-value>worker1,worker2</param-value>
</param>
<param>
 <param-name>worker.worker1.port</param-name>
 <param-value>8007</param-value>
</param>
<param>
 <param-name>worker.worker1.host</param-name>
 <param-value>hostA</param-value>
</param>
<param>
 <param-name>worker.worker1.type</param-name>
 <param-value>ajp13</param-value>
</param>
<param>
 <param-name>worker.worker1.cachesize</param-name>
 <param-value>64</param-value>
</param>
<param>
 <param-name>worker.worker2.port</param-name>
 <param-value>8007</param-value>
</param>
<param>
 <param-name>worker.worker2.host</param-name>
 <param-value>hostB</param-value>
</param>
<param>
 <param-name>worker.worker2.type</param-name>
 <param-value>ajp13</param-value>
</param>
<param>
 <param-name>worker.worker2.cachesize</param-name>
 <param-value>64</param-value>
</param>
：

3.3.4　実行環境での設定（Smart Composer機能を使用しない場合）

HTTPリクエストに含まれるURLパターンによってリクエストを振り分けることで，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて振り分けたりできます。なお，URLパターンによる振り分けは，原則としてWebアプリケーション単位で振り分けます。URLパターンは，リダイレクタの動作として定義します。

＜この項の構成＞

(1)　設定の手順

(2)　設定例

(1)　設定の手順

URLパターンによるリクエストの振り分けは，次の手順で設定します。

workers.propertiesでワーカを定義します。
ワーカ名のリスト，ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名などを設定します。
標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

Hitachi Web Serverを使用する場合は，mod_jk.confでURLパターンとワーカのマッピングを定義します。Microsoft IISを使用する場合は，uriworkermap.propertiesでURLパターンとワーカのマッピングを定義します。
すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。
Webサーバの設定については，「付録B　Hitachi Web Serverの設定に関する注意事項」，または「付録C　Microsoft IISの設定」を参照してください。

(2)　設定例

URLパターンでのリクエスト振り分けの例を次の図に示します。

図3-6　URLパターンでのリクエスト振り分けの例

この例では，ホストAにはWebアプリケーション「app1」，ホストBにはWebアプリケーション「app2」がそれぞれデプロイされています。処理したいWebアプリケーション名をリクエストのURLパターンに含めることで，「/app1/*」というURLパターンを持つリクエストはホストAで，「/app2/*」というURLパターンを持つリクエストはホストBで処理できるようにします。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

workers.propertiesの例を次に示します。ここでは，複数のWebコンテナへリクエストを振り分けるので，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカを振り分け先として指定します。

workers.propertiesの例（Windowsの場合）

worker.list=worker1,worker2

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64

workers.propertiesの例（UNIXの場合）

worker.list=worker1,worker2

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13

mod_jk.confおよびuriworkermap.propertiesの例を次に示します。ここでは，「/app1/*」というURLパターンと「worker1」，「/app2/*」というURLパターンと「worker2」とをマッピングします。

mod_jk.confの例（Hitachi Web Serverの場合）

JkMount /app1/* worker1
JkMount /app2/* worker2

uriworkermap.propertiesの例（Microsoft IISの場合）

/app1/*=worker1
/app2/*=worker2

3.4　ラウンドロビン方式によるリクエストの振り分け

この節では，ラウンドロビン方式によるリクエストの振り分けについて説明します。

この節の構成を次の表に示します。

表3-6　この節の構成（ラウンドロビン方式によるリクエストの振り分け）

分類 | タイトル | 参照先
解説 | ラウンドロビン方式によるリクエストの振り分けの概要 | 3.4.1
ラウンドロビン方式によるリクエストの振り分けの例 | 3.4.2
ラウンドロビン方式によるリクエストの振り分けの定義 | 3.4.3
設定 | 実行環境での設定（Smart Composer機能を使用する場合） | 3.4.4
実行環境での設定（Smart Composer機能を使用しない場合） | 3.4.5
注意事項 | ラウンドロビン方式によるリクエストの振り分けに関する注意事項 | 3.4.6

注　「実装」および「運用」について，この機能固有の説明はありません。

Webコンテナがクラスタ構成で配置されている場合，リダイレクタを使用して，ラウンドロビン方式でそれぞれのWebコンテナにリクエストを振り分けられます。リダイレクタは，各リクエストに付けられたセッションIDを参照することで，同一のWebクライアントから来たリクエストが常に同一のWebコンテナへ転送されるように，リクエストを振り分けます。

また，振り分け先のWebコンテナの処理性能が異なる場合などには，負荷パラメタを定義することで，ホストごとの負荷の割合を調整することもできます。この方式でリクエストを振り分ける場合は，振り分け処理をする各Webコンテナに，それぞれ同じWebアプリケーションがデプロイされていることが前提になります。

＜この節の構成＞

3.4.1　ラウンドロビン方式によるリクエストの振り分けの概要

3.4.2　ラウンドロビン方式によるリクエストの振り分けの例

3.4.3　ラウンドロビン方式によるリクエストの振り分けの定義

3.4.4　実行環境での設定（Smart Composer機能を使用する場合）

3.4.5　実行環境での設定（Smart Composer機能を使用しない場合）

3.4.6　ラウンドロビン方式によるリクエストの振り分けに関する注意事項

3.4.1　ラウンドロビン方式によるリクエストの振り分けの概要

クラスタ構成でのラウンドロビン方式によるリクエスト振り分けには，ロードバランサというワーカ定義を使用します。ロードバランサには，振り分け先となるワーカプロセスのリストが定義されています。この定義を基に，ワーカプロセスに対するラウンドロビン方式の振り分けが実行されます。

振り分けはHTTPリクエスト単位で実行されます。ただし，同じセッションに属するHTTPリクエストは，前回の振り分け先と同じワーカに振り分けられます。

参考

Webサーバ連携時に，リダイレクタの設定でラウンドロビン方式によるリクエストの振り分けを指定すると，HttpSessionのセッションIDにワーカ名が付加されます。また，サーバIDを付加するかどうかの設定に関係なく，HttpSessionのセッションIDにサーバIDは付加されません。

3.4.2　ラウンドロビン方式によるリクエストの振り分けの例

ロードバランサを使用したリクエストの振り分けの例を次の図に示します。

図3-7　ロードバランサを使用したリクエストの振り分けの例

3.4.3　ラウンドロビン方式によるリクエストの振り分けの定義

標準で提供されるworkers.propertiesには，あらかじめ次に示すロードバランサが定義されています。

#worker.list=loadbalancer1

#worker.loadbalancer1.type=lb
#worker.loadbalancer1.balanced_workers=worker1,worker2

worker.loadbalancer1.typeでは，ワーカのタイプを設定します。worker.loadbalancer1.balanced_workersでは，振り分け対象となるワーカプロセス名を設定します。workers.propertiesには，loadbalancer1として，それぞれ「lb」と「worker1，worker2」が定義されています。

ただし，この定義はコメントとして記述されています。このため，上記のロードバランサを利用する場合は，workers.propertiesの該当する行の先頭の「#」を削除してください。

リクエスト振り分けの比率は，振り分け対象となる各ワーカ定義のlbfactorパラメタに定義できます。lbfactorが大きければ大きいほどそのワーカプロセスに転送されるリクエストの割合は大きくなります。

例えば，worker1とworker2という二つのワーカプロセスでリクエストを振り分ける場合，ワーカ定義のlbfactorパラメタに次に示すように定義されているとします。

worker1のlbfactorパラメタ：2.0

worker2のlbfactorパラメタ：1.0

この場合，worker1はworker2の2倍の数のWebクライアントを担当することになります。

3.4.4　実行環境での設定（Smart Composer機能を使用する場合）

振り分け先となるワーカのリストをロードバランサに定義することで，ラウンドロビン方式でワーカにリクエストを振り分けます。

振り分け先となる各ワーカに負荷分散値を設定して，リクエスト振り分けの比率を定義すると，ホストごとの負荷の割合を調整できます。リダイレクタは，この比率でHTTPリクエスト単位にラウンドロビンでリクエストを振り分けるので，比率が高いワーカほど転送されるリクエストの割合が多くなります。ただし，同じセッションに属するHTTPリクエストは前回と同じワーカに振り分けられます。

＜この項の構成＞

(1)　設定の手順

(2)　workers.propertiesおよびmod_jk.confでの設定

(3)　設定例

(1)　設定の手順

ラウンドロビン方式によるリクエスト振り分けは，次の手順で設定します。

workers.propertiesでロードバランサ，およびワーカを定義します。

ロードバランサの定義

ワーカ名のリスト，ワーカのタイプ（「lb」を設定），負荷分散の対象となるワーカのリストなどを設定します。

各ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，負荷分散値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

mod_jk.confでURLパターンとワーカのマッピングを定義します。
すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。
Webサーバの設定については，「付録B　Hitachi Web Serverの設定に関する注意事項」を参照してください。

注意事項

リダイレクタで負荷分散を使用する場合に，あるワーカで障害を検出すると，障害を検出してから60秒間はそのワーカはリダイレクト先ワーカの選択肢から除外されます。そのため，障害が回復しても，最大で60秒間はそのワーカが使用されない場合があります。

UNIXの場合，Hitachi Web Serverのサーバプロセスを負荷に応じて生成・消滅させているときは，workers.propertiesの最初に定義したワーカによって多く割り振られます。また，サーバプロセス数を固定にしても，リクエストがどのサーバプロセスに割り振られるかは不定のため，同じ負荷分散値を指定してもラウンドロビンにならないことがあります。サーバプロセスは，消滅しなければ負荷に応じて増えてもよいため，サーバプロセスが短時間で生成・消滅しないようにディレクティブを指定する必要があります。
Hitachi Web Serverのhttpsd.confのディレクティブが次に示す条件を満たすように，指定してください。

条件 | 意味
MaxSpareServers ≧ MaxClients | サーバプロセスはMaxClientsまで増加し，処理終了後も常駐します。
MaxRequestsPerChild 10000 | HTTPリクエストを10,000回処理後，リフレッシュのためにサーバプロセスを終了させます（10,000は推奨値）。振り分け先のJ2EEサーバまたはWebコンテナサーバ数に対して十分に大きな値を指定します。
StartServers = MaxClients | 最初に全サーバプロセスを起動しておく場合に指定します。

ディレクティブの指定例

StartServers 256
MaxClients 256
MaxSpareServers 256
MaxRequestsPerChild 10000

(2)　workers.propertiesおよびmod_jk.confでの設定

ラウンドロビン方式によるリクエストの振り分けの設定は，workers.propertiesおよびmod_jk.confで定義します。workers.propertiesおよびmod_jk.confで定義するキーを次の表に示します。

表3-7　workers.propertiesおよびmod_jk.confで定義するキー（ラウンドロビン方式によるリクエストの振り分けの場合）

ファイルの種類
キー名
説明

workers.properties
worker.list
一つまたは複数のワーカ名のリストを指定します。

worker.<ワーカ名>.host
ワーカのホスト名，またはIPアドレスを指定します。

worker.<ワーカ名>.port
ワーカのポート番号を指定します。

worker.<ワーカ名>.type
ワーカのタイプを指定します。ロードバランサには「lb」を，負荷分散の対象となるワーカには「ajp13」を指定します。

worker.<ワーカ名>.balanced_workers
負荷分散の対象となるワーカのリストを指定します。

worker.<ワーカ名>.lbfactor
負荷分散値を指定します。

worker.<ワーカ名>.cachesize
リダイレクタで再利用するワーカのコネクション数を指定します。
Windowsの場合にだけ指定できます。

worker.<ワーカ名>.receive_timeout
通信タイムアウト値を指定します。

worker.<ワーカ名>.delegate_error_code
エラーページの作成をWebサーバに委任する場合に利用するエラーステータスコードを指定します。

mod_jk.conf
JkMount
URLパターンと，worker.listで指定されているワーカのどれかとの組み合わせを指定します。

注　<ワーカ名>には，worker.listキー，またはworker.<ワーカ名>.balanced_workersキーで指定したワーカの名称を定義します。

ワーカの種類ごとに指定できるパラメタを次の表に示します。

表3-8　ワーカの種類ごとに指定できるキー

キー名
ワーカの種類（worker.<ワーカ名>.typeキーの指定値）

ロードバランサ
（「lb」を指定）
ワーカ
（「ajp13」を指定）

worker.<ワーカ名>.host
×
○

worker.<ワーカ名>.port
×
○

worker.<ワーカ名>.type
○
○

worker.<ワーカ名>.balanced_workers
○
×

worker.<ワーカ名>.lbfactor
×
△

worker.<ワーカ名>.cachesize
×
△

worker.<ワーカ名>.receive_timeout
×
△

worker.<ワーカ名>.delegate_error_code
×
△

（凡例）○：指定できる　×：指定できない　△：任意に指定できる

(3)　設定例

ラウンドロビン方式によるリクエスト振り分けの例を次の図に示します。

図3-8　ラウンドロビン方式によるリクエスト振り分けの例

この例では，「/examples」以下のリクエストがホストA，ホストBに同じ比率で振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

workers.propertiesの例を次に示します。ここでは，ロードバランサとワーカを定義します。リクエストを同じ比率で振り分けるので，「worker1」と「worker2」の負荷分散値はどちらも「1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.lbfactor=1

workers.propertiesの例（UNIXの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.lbfactor=1

mod_jk.confの例を次に示します。ここでは，ロードバランサ名「loadbalancer1」を指定します。

mod_jk.confの例

JkMount /examples/* loadbalancer1

3.4.5　実行環境での設定（Smart Composer機能を使用しない場合）

振り分け先となるワーカのリストをロードバランサに定義することで，ラウンドロビン方式でワーカにリクエストを振り分けます。

振り分け先となる各ワーカに負荷分散値を設定して，リクエスト振り分けの比率を定義すると，ホストごとの負荷の割合を調整できます。リダイレクタは，この比率でHTTPリクエスト単位にラウンドロビンでリクエストを振り分けるので，比率が高いワーカほど転送されるリクエストの割合が多くなります。ただし，同じセッションに属するHTTPリクエストは前回と同じワーカに振り分けられます。

＜この項の構成＞

(1)　設定の手順

(2)　workers.propertiesおよびmod_jk.confでの設定

(3)　設定例

(1)　設定の手順

ラウンドロビン方式によるリクエスト振り分けは，次の手順で設定します。

workers.propertiesでロードバランサ，およびワーカを定義します。

ロードバランサの定義

ワーカ名のリスト，ワーカのタイプ（「lb」を設定），負荷分散の対象となるワーカのリストなどを設定します。

各ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，負荷分散値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

Hitachi Web Serverを使用する場合は，mod_jk.confでURLパターンとワーカのマッピングを定義します。Microsoft IISを使用する場合は，uriworkermap.propertiesでURLパターンとワーカのマッピングを定義します。
すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。
Webサーバの設定については，「付録B　Hitachi Web Serverの設定に関する注意事項」，または「付録C　Microsoft IISの設定」を参照してください。

注意事項

リダイレクタで負荷分散を使用する場合に，あるワーカで障害を検出すると，障害を検出してから60秒間はそのワーカはリダイレクト先ワーカの選択肢から除外されます。そのため，障害が回復しても，最大で60秒間はそのワーカが使用されない場合があります。

Microsoft IISを使用してリダイレクタが動作するワーカプロセスを複数に設定した場合，ワーカを2以上に設定していると，最初のリダイレクト先がworkers.propertiesの最初に定義したワーカに多く割り振られることがあります。
また，リクエストがどのワーカプロセスに割り振られるかはMicrosoft IISの制御によるため，同じ負荷分散値を指定してもラウンドロビンにならないことがあります。
この場合，アプリケーションプールの数を一つにすることで，最初のリダイレクトの割り振り先もラウンドロビンになります。

UNIXの場合，Hitachi Web Serverのサーバプロセスを負荷に応じて生成・消滅させているときは，workers.propertiesの最初に定義したワーカによって多く割り振られます。また，サーバプロセス数を固定にしても，リクエストがどのサーバプロセスに割り振られるかは不定のため，同じ負荷分散値を指定してもラウンドロビンにならないことがあります。サーバプロセスは，消滅しなければ負荷に応じて増えてもよいため，サーバプロセスが短時間で生成・消滅しないようにディレクティブを指定する必要があります。
Hitachi Web Serverのhttpsd.confのディレクティブが次に示す条件を満たすように，指定してください。

条件 | 意味
MaxSpareServers ≧ MaxClients | サーバプロセスはMaxClientsまで増加し，処理終了後も常駐します。
MaxRequestsPerChild 10000 | HTTPリクエストを10,000回処理後，リフレッシュのためにサーバプロセスを終了させます（10,000は推奨値）。振り分け先のJ2EEサーバまたはWebコンテナサーバ数に対して十分に大きな値を指定します。
StartServers = MaxClients | 最初に全サーバプロセスを起動しておく場合に指定します。

ディレクティブの指定例

StartServers 256
MaxClients 256
MaxSpareServers 256
MaxRequestsPerChild 10000

(2)　workers.propertiesおよびmod_jk.confでの設定

workers.propertiesおよびmod_jk.confでの設定については，Smart Composerを使用する場合と同様です。「3.4.4(2)　workers.propertiesおよびmod_jk.confでの設定」を参照してください。

(3)　設定例

ラウンドロビン方式によるリクエスト振り分けの例を次の図に示します。

図3-9　ラウンドロビン方式によるリクエスト振り分けの例

この例では，「/examples」以下のリクエストがホストA，ホストBに同じ比率で振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

workers.propertiesの例を次に示します。ここでは，ロードバランサとワーカを定義します。リクエストを同じ比率で振り分けるので，「worker1」と「worker2」の負荷分散値はどちらも「1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.lbfactor=1

workers.propertiesの例（UNIXの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.lbfactor=1

mod_jk.confおよびuriworkermap.propertiesの例を次に示します。ここでは，ロードバランサ名「loadbalancer1」を指定します。

mod_jk.confの例（Hitachi Web Serverの場合）

JkMount /examples/* loadbalancer1

uriworkermap.propertiesの例（Microsoft IISの場合）

/examples/*=loadbalancer1

3.4.6　ラウンドロビン方式によるリクエストの振り分けに関する注意事項

リダイレクタのラウンドロビン方式によるリクエストの振り分けに関する注意事項を次に示します。

J2EEアプリケーション停止中のWebコンテナへのリクエストの送信
ラウンドロビン方式でリクエストを振り分ける場合，J2EEアプリケーションが停止中であってもWebコンテナへリクエストが送信されます。このため，J2EEアプリケーションの変更は，すべてのWebコンテナをシステムから隔離した状態で実施する必要があります。

負荷分散機によるヘルスチェックの無効
負荷分散機と，ラウンドロビン方式によるリクエストの振り分けを併用した場合，J2EEサーバに障害が発生したときも，リダイレクタで正常なWebコンテナへ転送されます。このため，負荷分散機でJ2EEサーバの障害が検知できなくなり，Webコンテナの監視が行えません。

3.5　POSTデータサイズでのリクエストの振り分け

この節では，POSTデータサイズでのリクエストの振り分けについて説明します。

この節の構成を次の表に示します。

表3-9　この節の構成（POSTデータサイズでのリクエストの振り分け）

分類 | タイトル | 参照先
解説 | POSTデータサイズでのリクエストの振り分けの概要 | 3.5.1
POSTデータサイズによるリクエストの振り分けの例 | 3.5.2
リクエストの振り分け条件 | 3.5.3
POSTデータサイズによるリクエストの振り分けの定義 | 3.5.4
設定 | 実行環境での設定（Smart Composer機能を使用する場合） | 3.5.5
実行環境での設定（Smart Composer機能を使用しない場合） | 3.5.6

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

3.5.1　POSTデータサイズでのリクエストの振り分けの概要

3.5.2　POSTデータサイズによるリクエストの振り分けの例

3.5.3　リクエストの振り分け条件

3.5.4　POSTデータサイズによるリクエストの振り分けの定義

3.5.5　実行環境での設定（Smart Composer機能を使用する場合）

3.5.6　実行環境での設定（Smart Composer機能を使用しない場合）

3.5.1　POSTデータサイズでのリクエストの振り分けの概要

Webコンテナがクラスタ構成で配置されている場合，リダイレクタを使用して，POSTデータサイズごとにそれぞれのWebコンテナにリクエストを振り分けられます。この機能を使用すると，処理に時間が掛かる長大なPOSTデータのリクエストを，特定のWebコンテナに転送できます。これによって，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。この方式でリクエストを振り分ける場合は，振り分け処理をする各Webコンテナに，それぞれWebアプリケーションがデプロイされていることが前提になります。ただし，各J2EEサーバにデプロイするWebアプリケーションが同一である必要はありません。

クラスタ構成でのPOSTデータサイズによるリクエストの振り分けには，POSTリクエスト振り分けワーカというワーカ定義を使用します。POSTリクエスト振り分けワーカには，振り分け先となるワーカプロセスのリストが定義されています。この定義を基に，ワーカプロセスに対するPOSTデータサイズの振り分けが実行されます。POSTリクエスト振り分けワーカの振り分け先となるワーカプロセスをPOSTリクエスト転送先ワーカといいます。

POSTリクエスト転送先ワーカへの振り分けは，HTTPリクエスト単位で実行されます。

注意

HTTP CookieまたはURL書き換えによる制御でセッションが管理されている場合でも，POSTデータサイズによる振り分けを設定しているときは，POSTデータサイズによって，リクエストの振り分け先が決定されます。このため，同一クライアントからのリクエストの場合でも，HttpSessionのセッションIDは引き継がれません。

例えば，J2EEサーバ1でHttpSessionのセッションIDを生成したあと，J2EEサーバ2へリクエストが転送された場合，J2EEサーバ2で新たにHttpSessionのセッションIDが生成されます。この場合，再度J2EEサーバ1にアクセスすると，クライアントではJ2EEサーバ2で生成されたHttpSessionのセッションIDを使用しているため，J2EEサーバ1で新たにHttpSessionのセッションIDが生成されます。このため，HttpSessionのセッションは引き継がれません。

なお，J2EEサーバ1でHttpSessionのセッションIDを生成したあと，J2EEサーバ2へリクエストが転送されても，J2EEサーバ2でHttpSessionのセッションIDが生成されない場合，再度J2EEサーバ1にアクセスすると，J2EEサーバ1で生成済みのHttpSessionのセッションIDがそのまま使用されます。

3.5.2　POSTデータサイズによるリクエストの振り分けの例

POSTデータサイズでリクエストを振り分ける場合，POSTリクエスト振り分けワーカに転送されるリクエストが限定できるかどうかによって，POSTデータサイズの上限値に設定する値が異なります。

POSTリクエスト振り分けワーカに転送されるリクエストが限定できる場合
ここでは，次の条件を満たすリクエストが，POSTリクエスト振り分けワーカに転送されるものとして説明します。

POSTデータのリクエストである。

リクエストのPOSTデータサイズが200メガバイト未満である。

リクエストが限定できる場合，処理したい長大なPOSTデータの範囲も限定できます。長大なPOSTデータのリクエストを処理するワーカに，特定のPOSTデータサイズのリクエストが転送されるように，それぞれのリクエスト転送先ワーカで上限値を設定します。
リクエストが限定できる場合の，POSTデータサイズによるリクエストの振り分けの例を次の図に示します。

図3-10　POSTデータサイズによるリクエストの振り分けの例（リクエストが限定できる場合）

この図では，POSTリクエスト転送先ワーカを二つ用意し，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストがワーカプロセスBに転送されるように，それぞれにPOSTデータサイズの上限値を設定しています。リクエストのPOSTデータサイズが上限値未満の場合に，それぞれのPOSTリクエスト転送先ワーカに振り分けられます。リクエストのPOSTデータサイズが，複数のPOSTリクエスト転送先ワーカに当てはまる場合，POSTデータサイズの上限値が最も小さいPOSTリクエスト転送先ワーカに，リクエストは振り分けられます。例えば，POSTデータサイズが80メガバイトのリクエストの場合は，どちらのワーカにも該当しますが，ワーカプロセスAに振り分けられます。

POSTリクエスト振り分けワーカに転送されるリクエストが限定できない場合
リクエストを限定できない場合，長大なPOSTデータを処理するワーカのPOSTデータサイズの上限値には，最大値を設定します。
リクエストが限定できない場合の，POSTデータサイズによるリクエストの振り分けの例を次の図に示します。

図3-11　POSTデータサイズによるリクエストの振り分けの例（リクエストが限定できない場合）

この図では，POSTリクエスト転送先ワーカを二つ用意し，それぞれにPOSTデータサイズの上限値を設定しています。長大なPOSTデータのリクエストすべてをワーカプロセスBで処理するように，ワーカプロセスBのPOSTデータサイズの上限値には最大値を設定しています。ワーカプロセスAの上限値以上（100メガバイト以上）のPOSTデータのリクエストは，すべてワーカプロセスBに転送されます。なお，この場合，POSTデータ以外のリクエストや，POSTデータサイズが参照できないリクエストなどが転送されると，リクエスト振り分けワーカで振り分けられないため，リダイレクタによってエラーステータスコード400が返されてエラーとなります。

POSTデータサイズでリクエストを振り分ける場合，リクエストの振り分け条件に満たないリクエストがPOSTリクエスト振り分けワーカに転送されると，リダイレクタによってエラーステータスコード400が返されてエラーとなります。リクエストの振り分け条件については，「3.5.3　リクエストの振り分け条件」を参照してください。

リクエストの振り分け条件に満たないリクエストも処理したい場合は，そのリクエストを転送するワーカプロセスを設定する必要があります。リクエストの振り分け条件に満たないリクエストを転送するワーカプロセスをデフォルトワーカといいます。なお，デフォルトワーカの設定は任意です。

リクエストが限定できない場合に，リクエストの振り分け条件に満たないリクエストをデフォルトワーカに転送する例を次の図に示します。

図3-12　POSTデータサイズによるリクエストの振り分けの例（デフォルトワーカを設定した場合）

この図では，リクエストの振り分け条件に満たないリクエストを，デフォルトワーカのワーカプロセスAに転送するように設定しています。

3.5.3　リクエストの振り分け条件

POSTリクエスト転送先ワーカに振り分けられるリクエストは，次の条件を満たしている必要があります。

POSTリクエスト転送先ワーカに振り分けられるリクエストの条件

リクエストのメソッドがPOSTであること。

リクエストにContent-Lengthヘッダがある（ボディデータがチャンク形式でない）こと。

リクエストのContent-Lengthヘッダの値が，ワーカに設定しているPOSTデータサイズ未満であること。

どれか一つでも条件を満たさないリクエストは，デフォルトワーカに振り分けられます。デフォルトワーカが設定されていない場合は，エラーとなり，エラーステータスコード400のエラーが返されます。

3.5.4　POSTデータサイズによるリクエストの振り分けの定義

標準で提供されるworkers.propertiesには，あらかじめ次に示すPOSTリクエスト割り分けワーカが定義されています。

#worker.list=postsizelb1
#worker.postsizelb1.type=post_size_lb
#worker.postsizelb1.post_size_workers=worker1,worker2
#worker.postsizelb1.default_worker=worker1

worker.postsizelb1.typeでは，ワーカのタイプを設定します。worker.postsizelb1.post_size_workersでは，振り分け対象となるPOSTリクエスト転送先ワーカのワーカプロセス名を設定します。worker.postsizelb1.default_workerでは，デフォルトワーカを設定します。workers.propertiesには，postsizelb1として，ワーカのタイプに「post_size_lb」，POSTリクエスト転送先ワーカに「worker1，worker2」，デフォルトワーカに「worker1」が定義されています。

ただし，この定義はコメントとして記述されています。このため，この定義のPOSTリクエスト割り分けワーカを利用する場合は，workers.propertiesの該当する行の先頭の「#」を削除してください。

リクエストを振り分けるPOSTデータサイズは，workers.propertiesのワーカ定義のpost_dataパラメタで設定します。

例えば，標準提供のpostsizelb1の定義を利用して，worker1とworker2という二つのPOSTリクエスト転送先ワーカに，それぞれ次のようにPOSTデータサイズを定義しているとします。

worker1のpost_dataパラメタ：100m

worker2のpost_dataパラメタ：200m

この場合，worker1には100メガバイト未満のリクエストが，worker2には100メガバイト以上200メガバイト未満のリクエストが振り分けられます。リクエスト振り分けワーカが，200メガバイト以上のリクエストを振り分けた場合，そのリクエストはデフォルトワーカに設定されているworker1に転送されます。

3.5.5　実行環境での設定（Smart Composer機能を使用する場合）

振り分け先となるワーカのリストをPOSTリクエスト振り分けワーカに定義することで，POSTデータサイズでワーカにリクエストを振り分けます。

振り分け先となるPOSTリクエスト転送先ワーカに，POSTデータサイズの上限値を設定して，リクエスト振り分け先を定義します。これによって，特定のホストに，処理に時間が掛かる長大なPOSTデータサイズのリクエストの処理を振り分けられます。リダイレクタは，HTTPリクエスト単位にPOSTデータサイズの上限値で振り分けるので，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。なお，POSTデータサイズの上限値が設定されている場合は，同じセッションに属するHTTPリクエストであっても，POSTデータサイズの値が優先されます。

＜この項の構成＞

(1)　設定の手順

(2)　workers.propertiesおよびmod_jk.confでの設定

(3)　設定例

(1)　設定の手順

POSTデータサイズでのリクエスト振り分けは，次の手順で設定します。

workers.propertiesでPOSTリクエスト振り分けワーカ，およびPOSTリクエスト転送先ワーカを定義します。

POSTリクエスト振り分けワーカの定義

ワーカ名のリスト，ワーカのタイプ（「post_size_lb」を設定），POSTデータサイズによる振り分けの対象となるワーカのリストなどを設定します。必要に応じて，デフォルトワーカも設定します。

各POSTリクエスト転送先ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，POSTデータサイズの上限値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

mod_jk.confでURLパターンとワーカのマッピングを定義します。
すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。
Webサーバの設定については，「付録B　Hitachi Web Serverの設定に関する注意事項」を参照してください。

(2)　workers.propertiesおよびmod_jk.confでの設定

POSTデータサイズでのリクエストの振り分けの設定は，workers.propertiesおよびmod_jk.confで定義します。workers.propertiesおよびmod_jk.confで定義するキーを次の表に示します。

表3-10　workers.propertiesおよびmod_jk.confで定義するキー（POSTデータサイズでのリクエストの振り分けの場合）

ファイルの種類
キー名
説明

workers.properties
worker.list
一つまたは複数のワーカ名のリストを指定します。

worker.<ワーカ名>.host
ワーカのホスト名，またはIPアドレスを指定します。

worker.<ワーカ名>.port
ワーカのポート番号を指定します。

worker.<ワーカ名>.type
ワーカのタイプを指定します。POSTリクエスト振り分けワーカには「post_size_lb」を，振り分け対象となるPOSTリクエスト転送先ワーカには「ajp13」を指定します。

worker.<ワーカ名>.post_size_workers
POSTデータサイズによる振り分けの対象となるワーカのリストを指定します。

worker.<ワーカ名>.post_data
リクエストのPOSTデータサイズの上限値（バイト単位）を指定します。

worker.<ワーカ名>.default_worker
リクエストの振り分け先に該当するワーカが，クラスタ構成内のPOSTリクエスト転送先ワーカにない場合に，リクエストを転送するワーカ（デフォルトワーカ）を指定します。

worker.<ワーカ名>.cachesize
リダイレクタで再利用するワーカのコネクション数を指定します。
Windowsの場合にだけ指定できます。

worker.<ワーカ名>.receive_timeout
通信タイムアウト値を指定します。

worker.<ワーカ名>.delegate_error_code
エラーページの作成をWebサーバに委任する場合に利用するエラーステータスコードを指定します。

mod_jk.conf
JkMount
URLパターンと，worker.listで指定されているワーカのどれかとの組み合わせを指定します。

注　<ワーカ名>には，worker.listキー，またはworker.<ワーカ名>.post_size_workersキーで指定したワーカの名称を定義します。

ワーカの種類ごとに指定できるキーを次の表に示します。

表3-11　ワーカの種類ごとに指定できるキー

キー名
ワーカの種類（worker.<ワーカ名>.typeキーの指定値）

POSTリクエスト振り分けワーカ
（「post_size_lb」を指定）
POSTリクエスト転送先ワーカ
（「ajp13」を指定）

worker.<ワーカ名>.host
×
○

worker.<ワーカ名>.port
×
○

worker.<ワーカ名>.type
○
○

worker.<ワーカ名>.post_size_workers
○
×

worker.<ワーカ名>.post_data
×
○

worker.<ワーカ名>.default_worker
△
×

worker.<ワーカ名>.cachesize
×
△

worker.<ワーカ名>.receive_timeout
×
△

worker.<ワーカ名>.delegate_error_code
×
△

（凡例）○：指定できる。　×：指定できない。　△：任意に指定できる。

(3)　設定例

POSTデータサイズでのリクエスト振り分けの例を次の図に示します。ここでは，リクエストを限定できない場合を例に説明します。

図3-13　POSTデータサイズでのリクエスト振り分けの例

この例では，「/examples」以下のリクエストのうち，POSTデータサイズが100メガバイト未満のリクエストをホストA，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストをホストBに振り分けます。リクエストの振り分け条件に満たないリクエストは，デフォルトワーカに設定したホストAに振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。リクエストの振り分け条件については，「3.5.3　リクエストの振り分け条件」を参照してください。

workers.propertiesの例を次に示します。ここでは，POSTリクエスト振り分けワーカ，POSTリクエスト転送先ワーカおよびデフォルトワーカを定義します。POSTデータサイズの上限値は，「worker1」に「100m」，「worker2」に「2048m」（POSTデータサイズの上限値の最大値）を指定します。デフォルトワーカには，「worker1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.post_data=2048m

workers.propertiesの例（UNIXの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.post_data=2048m

mod_jk.confの例を次に示します。ここでは，POSTリクエスト振り分けワーカ「postsizelb1」を指定します。

mod_jk.confの例

JkMount /examples/* postsizelb1

参考

POSTデータサイズの上限値は，httpsd.conf（Hitachi Web Server定義ファイル）のLimitRequestBodyディレクティブでも設定できます。LimitRequestBodyディレクティブの詳細については，マニュアル「Hitachi Web Server」を参照してください。

3.5.6　実行環境での設定（Smart Composer機能を使用しない場合）

振り分け先となるワーカのリストをPOSTリクエスト振り分けワーカに定義することで，POSTデータサイズでワーカにリクエストを振り分けます。

振り分け先となるPOSTリクエスト転送先ワーカに，POSTデータサイズの上限値を設定して，リクエスト振り分け先を定義します。これによって，特定のホストに，処理に時間が掛かる長大なPOSTデータサイズのリクエストの処理を振り分けられます。リダイレクタは，HTTPリクエスト単位にPOSTデータサイズの上限値で振り分けるので，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。なお，POSTデータサイズの上限値が設定されている場合は，同じセッションに属するHTTPリクエストであっても，POSTデータサイズの値が優先されます。

注意

Microsoft IISと連携する場合，POSTデータサイズによるリクエストの振り分けは設定できません。

＜この項の構成＞

(1)　設定の手順

(2)　設定例

(1)　設定の手順

POSTデータサイズでのリクエスト振り分けは，次の手順で設定します。

workers.propertiesでPOSTリクエスト振り分けワーカ，およびPOSTリクエスト転送先ワーカを定義します。

POSTリクエスト振り分けワーカの定義

ワーカ名のリスト，ワーカのタイプ（「post_size_lb」を設定），POSTデータサイズによる振り分けの対象となるワーカのリストなどを設定します。

必要に応じて，デフォルトワーカも設定します。

各POSTリクエスト転送先ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，POSTデータサイズの上限値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

mod_jk.confでURLパターンとワーカのマッピングを定義します。
すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。
Webサーバの設定については，「付録B　Hitachi Web Serverの設定に関する注意事項」を参照してください。

(2)　設定例

POSTデータサイズでのリクエスト振り分けの例を次の図に示します。ここでは，リクエストを限定できない場合を例に説明します。

図3-14　POSTデータサイズでのリクエスト振り分けの例

この例では，「/examples」以下のリクエストのうち，POSTデータサイズが100メガバイト未満のリクエストをホストA，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストをホストBに振り分けます。リクエストの振り分け条件に満たないリクエストは，デフォルトワーカに設定したホストAに振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。リクエストの振り分け条件については，「3.5.3　リクエストの振り分け条件」を参照してください。

workers.propertiesの例を次に示します。ここでは，POSTリクエスト振り分けワーカ，POSTリクエスト転送先ワーカおよびデフォルトワーカを定義します。POSTデータサイズの上限値は，「worker1」に「100m」，「worker2」に「2048m」（POSTデータサイズの上限値の最大値）を指定します。デフォルトワーカには，「worker1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.post_data=2048m

workers.propertiesの例（UNIXの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.post_data=2048m

mod_jk.confの例を次に示します。ここでは，POSTリクエスト振り分けワーカ「postsizelb1」を指定します。

mod_jk.confの例

JkMount /examples/* postsizelb1

参考

POSTデータサイズの上限値は，httpsd.conf（Hitachi Web Server定義ファイル）のLimitRequestBodyディレクティブでも設定できます。LimitRequestBodyディレクティブの詳細については，マニュアル「Hitachi Web Server」を参照してください。

3.6　通信タイムアウト（Webサーバ連携）

この節では，Webサーバ連携での通信タイムアウトについて説明します。

Webサーバ連携機能を使用する場合，クライアント－Webサーバ間，およびWebサーバ－Webコンテナ間での，リクエスト受信およびレスポンス送信に，通信のタイムアウトを設定できます。ネットワークの障害やアプリケーションの障害発生などで応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

この節の構成を次の表に示します。

表3-12　この節の構成（通信タイムアウト（Webサーバ連携））

分類 | タイトル | 参照先
解説 | リクエスト送受信時の通信タイムアウト | 3.6.1
レスポンス送受信時の通信タイムアウト | 3.6.2
設定 | 通信タイムアウトの設定 | 3.6.3
リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合） | 3.6.4
リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合） | 3.6.5
レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合） | 3.6.6
レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合） | 3.6.7

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

Webサーバ連携機能を使用する場合，通信タイムアウトは，次に示す図中の四つの矢印が示す通信に対して設定します。さらに，リダイレクタ－Webコンテナ間の通信では，リダイレクタ側，Webコンテナ側の両方で通信タイムアウトを設定できます。リクエスト送信の場合は，リダイレクタ側でのリクエスト送信時およびWebコンテナ側でのリクエスト受信時に設定できます。また，レスポンス送信の場合は，Webコンテナ側でのレスポンス送信時およびリダイレクタ側でのレスポンス受信時に設定できます。タイムアウトを設定できる通信について次の図に示します。

図3-15　タイムアウトを設定できる通信

通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

＜この節の構成＞

3.6.1　リクエスト送受信時の通信タイムアウト

3.6.2　レスポンス送受信時の通信タイムアウト

3.6.3　通信タイムアウトの設定

3.6.4　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

3.6.5　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

3.6.6　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

3.6.7　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

3.6.1　リクエスト送受信時の通信タイムアウト

ここでは，Webサーバ連携機能を使用する場合のリクエスト送受信時の通信タイムアウト設定について説明します。リクエスト送受信時の，通信タイムアウトの設定場所を次の図に示します。

図3-16　リクエスト送受信時の通信タイムアウトの設定場所

Webサーバ連携機能を使用する場合，図中の○印の場所に通信タイムアウトを設定します。通信タイムアウトを設定する場所について説明します。なお，図中の項番は次の説明の項番と対応しています。

Webサーバでのリクエスト受信時（クライアント－Webサーバ）
クライアントからのリクエストを，Webサーバで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webサーバで設定します。
Webサーバでのリクエスト受信時に通信タイムアウトを設定することによって検知できる障害については，「(1)　Webサーバでのリクエスト受信時」を参照してください。

リダイレクタでのリクエスト送信時（リダイレクタ－Webコンテナ）
リダイレクタからWebコンテナにリクエストを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，リダイレクタで設定します。
リダイレクタでのリクエスト送信時に通信タイムアウトを設定することによって検知できる障害については，「(2)　リダイレクタでのリクエスト送信時」を参照してください。

Webコンテナでのリクエスト受信時（リダイレクタ－Webコンテナ）
リダイレクタからのリクエストを，Webコンテナで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webコンテナで設定します。
Webコンテナでのリクエスト受信時に通信タイムアウトを設定することによって検知できる障害については，「(3)　Webコンテナでのリクエスト受信時」を参照してください。

＜この項の構成＞

(1)　Webサーバでのリクエスト受信時

(2)　リダイレクタでのリクエスト送信時

(3)　Webコンテナでのリクエスト受信時

(1)　Webサーバでのリクエスト受信時

Webサーバでは，クライアントから転送されたリクエストの受信処理に，タイムアウト時間を設定できます。設定した通信タイムアウトによって，クライアント側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

クライアントが稼働するホストがダウンした

クライアント－Webサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

(2)　リダイレクタでのリクエスト送信時

リダイレクタでは，Webコンテナへのリクエスト送信処理にタイムアウト時間を設定できます。設定したタイムアウト時間を超えてタイムアウトが発生した場合にはHitachi Web Serverのエラーログにメッセージが出力されます。

(a)　設定できる通信タイムアウトと検知できる障害

リダイレクタでのリクエスト送信処理では，次に示す二つの時間にタイムアウトが設定できます。

Webコンテナにリクエストを送信するための，コネクションを確立する時間

Webコンテナにリクエストを送信する時間

設定した通信タイムアウトによって，Webコンテナ側またはネットワーク上で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webコンテナが稼働するホストがダウンした

リダイレクタ－Webコンテナ間でネットワーク障害が発生した

(b)　リクエスト送信処理のリトライ

リダイレクタからのリクエスト送信処理が一時的にできなくなった場合，リクエスト送信処理のリトライができます。一時的にリクエスト送信ができない場合とは次のような場合です。

ネットワークの一時的な障害が発生した場合

コネクション確立時に，Webコンテナにリクエストが集中している状態で，確立要求が一時的にリスンキューからあふれた場合

Webコンテナの起動完了を待っている場合

リトライできる処理は，コネクションの確立処理，およびリクエストヘッダの送信処理となります。リトライ処理の流れを次の図に示します。

図3-17　Webコンテナへのリクエスト送信時のリトライ処理の流れ

リトライは，図中のAまたはBでタイムアウトが発生した場合に実施されます。図中CまたはDの部分で処理に失敗し，タイムアウトが発生した場合，リトライは実施されません。コネクションはクローズされ，クライアントにエラーが返ります。なお，図中CまたはDの部分で処理の失敗とは，Webサーバからのリクエストボディの受信に失敗した場合，またはWebコンテナへのリクエストボディの送信に失敗した場合を指します。

ポイント

図中のCまたはDの処理では，Webコンテナ側ですでにリクエストに対する処理が開始されている可能性があります。Webサーバからのリクエストボディの受信に失敗した場合，およびWebコンテナへのリクエストボディの送信に失敗した場合は，リトライを実施すると二重送信となるおそれがあるため，リトライはされません。

次に，図中Aおよび図中Bで処理に失敗した場合のリトライについて説明します。

●図中Aの部分で処理に失敗した場合のリトライ

リダイレクタからWebコンテナにコネクションの確立要求を出したあと，Webコンテナが稼働するホストの電源が切断されたり，ネットワーク障害が発生したりした場合，次のように動作します。

設定したタイムアウトの時間が経過すると，コネクション確立でタイムアウトが発生したことを示すメッセージが出力されます。

指定した回数だけコネクションの確立をリトライします。

なお，リトライ回数分実施してもコネクションの確立ができなかった場合，リクエスト送信に失敗したことを示すメッセージが出力され，クライアントにエラー（ステータスコード500）が返されます。

●図中Bの部分で処理に失敗した場合のリトライ

コネクションの確立が成功したあと，またはWebコンテナにリクエストヘッダの送信をしたあと，Webコンテナが稼働するホストの電源が切断されたり，ネットワーク障害が発生したりした場合，次のように動作します。

設定したタイムアウトの時間が経過すると，リクエスト送信でタイムアウトが発生したことを示すメッセージが出力されます。

リクエストヘッダの送信処理に使用されたコネクションをクローズします。

指定した回数だけリクエストヘッダの送信をリトライします。
なお，このとき，コネクションキャッシュにコネクションがあるかどうかで動作が異なります。

コネクションキャッシュにコネクションがある場合
コネクションキャッシュ中のコネクションを使用して，リクエストヘッダの送信処理からリトライします。

コネクションキャッシュにコネクションがない場合
再度，コネクションの確立を実施してから，リクエストヘッダの送信処理をリトライします。

なお，リトライ回数分実施してもリクエストヘッダの送信ができなかった場合，リクエスト送信に失敗したことを示すメッセージが出力され，クライアントにステータスコード500が返されます。

●ロードバランサを使用してリクエストの振り分けをしている場合のリトライ動作

ロードバランサを使用したリクエストの振り分けをしている場合のリトライ動作について，次の図で説明します。

なお，この図では，リクエストは，Webコンテナ1，Webコンテナ2の順で振り分けられ，リトライ回数は3回が設定されていることとします。

図3-18　ロードバランサを使用してリクエストの振り分けをしている場合のリトライ動作

図のリトライ動作について説明します。

Webコンテナ1へのリクエスト送信
リクエストはWebコンテナ1に送信されます。Webコンテナ1へのコネクションの確立またはリクエストヘッダの送信処理に失敗すると，リトライをします。リトライは3回まで実施されます。

Webコンテナ2へのリクエスト送信
Webコンテナ1でのリトライに3回失敗すると，リクエストはWebコンテナ2に転送されます。リクエストが転送されると，リトライは再度1からカウントされるため，Webコンテナ2に対しても，最大で3回リトライが実行されます。

クライアントへのエラー通知
Webコンテナ2に対しても，コネクションの確立またはリクエストヘッダの送信処理が3回失敗すると，クライアントにエラー（ステータスコード500）が返ります。

参考

リクエストの転送は，設定されているWebコンテナの数だけ実施されます。

(3)　Webコンテナでのリクエスト受信時

Webコンテナでは，リダイレクタから転送されたリクエストの受信処理に，タイムアウト時間を設定できます。設定した通信タイムアウトによって，リダイレクタ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webサーバが稼働するホストがダウンした

Webサーバ－Webコンテナ間のネットワーク障害が発生した

クライアント－Webサーバ間での処理が終わる前に，Webコンテナ側でタイムアウトが発生した
これは，Webコンテナが要求したデータサイズ分の読み込みを，クライアント－Webサーバ間で行っているときに，クライアント－Webサーバ間の通信速度が十分ではないなどの理由によって，データの読み込みが終了する前に，Webコンテナで設定した通信タイムアウトが発生したことを意味します。

通信タイムアウトが発生する条件と発生後の動作について次の表に示します。

表3-13　通信タイムアウトが発生する条件と発生後の動作

通信タイムアウトが発生する条件
発生後の動作

リクエスト受信時に次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

ボディデータの形式がチャンク形式ではない。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ－Webコンテナ間のネットワークに障害が発生した。

リクエスト処理は実行されない。

メッセージログにKDJE39188-Eのメッセージを出力する。

サーブレット(JSP)内でのAPI※使用時に，次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

ボディデータの形式がチャンク形式ではない。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ－Webコンテナ間のネットワークに障害が発生した。

java.lang.IllegalStateExceptionが発生する。

リダイレクタとのコネクションがクローズされ，それ以降のデータの読み込み，書き込みができなくなる。

メッセージログにKDJE39188-Eのメッセージを出力する。

サーブレット(JSP)内でjavax.servlet.ServletInputStreamクラスまたはjavax.servlet.ServletRequestクラスのgetReaderメソッドによって得られたjava.io.BufferedReaderクラスを使用してPOSTデータを読み込んだ際に，次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ－Webコンテナ間のネットワークに障害が発生した。

java.net.SocketTimeoutExceptionが発生する。

リダイレクタとのコネクションがクローズされ，それ以降のデータの読み込み，書き込みができなくなる。

メッセージログにKDJE39188-Eのメッセージを出力する。

注※

javax.servlet.ServletRequestの，getParameterメソッド，getParameterMapメソッド，getParameterNamesメソッド，getParameterValuesメソッドを使用している場合を指します。

3.6.2　レスポンス送受信時の通信タイムアウト

ここでは，Webサーバ連携機能を使用する場合のレスポンス送受信時の通信タイムアウト設定について説明します。レスポンス送受信時の，通信タイムアウトの設定場所を次の図に示します。

図3-19　レスポンス送信時の通信タイムアウトの設定場所（Webサーバ連携機能を使用する場合）

Webサーバ連携機能を使用する場合，図中の○印の場所に通信タイムアウトを設定します。通信タイムアウトを設定する場所について説明します。なお，図中の項番は次の説明の項番と対応しています。

Webコンテナでのレスポンス送信時（Webコンテナ－リダイレクタ）
Webコンテナからリダイレクタにレスポンスを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webコンテナで設定します。
Webコンテナでのレスポンス送信時に通信にタイムアウトを設定することによって検知できる障害については，「(1)　Webコンテナでのレスポンス送信時」を参照してください。

リダイレクタでのレスポンス受信時（Webコンテナ－リダイレクタ）
Webコンテナからのレスポンスを，リダイレクタで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，リダイレクタで設定します。
リダイレクタでのレスポンス受信時に通信タイムアウトを設定することによって検知できる障害については，「(2)　リダイレクタでのレスポンス受信時」を参照してください。

Webサーバでのレスポンス送信時（Webサーバ－クライアント）
Webサーバからクライアントにレスポンスを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webサーバで設定します。
Webサーバでのレスポンス送信時に通信にタイムアウトを設定することによって検知できる障害については，「(3)　Webサーバでのレスポンス送信時」を参照してください。

＜この項の構成＞

(1)　Webコンテナでのレスポンス送信時

(2)　リダイレクタでのレスポンス受信時

(3)　Webサーバでのレスポンス送信時

(1)　Webコンテナでのレスポンス送信時

Webコンテナでは，リダイレクタへのレスポンス送信処理に対して，タイムアウト時間を設定できます。設定した通信タイムアウトによって，リダイレクタ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

リダイレクタが稼働するホストがダウンした

Webコンテナ－リダイレクタ間でネットワーク障害が発生した

また，通信タイムアウトが発生すると，KDJE39507-E（レスポンス送信処理でタイムアウト発生）がメッセージログに出力されます。通信タイムアウトが発生する条件と発生後の動作について次の表に示します。

表3-14　通信タイムアウトが発生する条件と発生後の動作

通信タイムアウトが発生するタイミング
通信タイムアウト発生後のメソッドの動作
通信タイムアウト発生後のサーブレットまたはJSPの動作

サーブレット内で，javax.servlet.ServletResponseクラスのgetOutputStreamメソッドによって得られたjavax.servlet.ServletOutputStreamクラスのメソッドを使用してレスポンスデータをクライアントに送信したとき
java.net.SocketTimeoutExceptionの例外が発生する。
リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

サーブレット内で，javax.servlet.ServletResponseクラスのgetWriterメソッドによって得られたjava.io.PrintWriterクラスのメソッドを使用して，レスポンスデータをクライアントに送信したとき
送信処理が中断されて，リターンする。

java.io.PrintWriterクラスのcheckErrorメソッドがtrueを返す。

リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

JSP内で，javax.servlet.jsp.JspWriterクラスのメソッドを使用してレスポンスデータをクライアントに送信したとき
java.net.SocketTimeoutExceptionの例外が発生する。
リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

静的コンテンツのレスポンスデータをクライアントに送信したとき
－
－

（凡例）－：該当しない

(2)　リダイレクタでのレスポンス受信時

リダイレクタは，Webコンテナにリクエストを送信すると，Webコンテナからのレスポンスを待ちます。このレスポンスの待ち時間に，タイムアウトを設定できます。設定した通信タイムアウトによって，Webコンテナ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webコンテナが稼働するホストがダウンした

Webコンテナ－リダイレクタ間でネットワーク障害が発生した

Webコンテナ内のWebアプリケーションで障害が発生した

Webアプリケーションで発生する障害には次のようなものがあります。

Webアプリケーションで発生する障害

サーブレット/JSP処理内の無限ループによって，レスポンスが返されない

サーブレット/JSPの延長でEnterprise Bean，データベースなどが呼び出され，それによる応答待ちをしている

Webアプリケーションでデッドロックが発生している

アクセスピーク時にサーバの処理が追いつかないで滞っている

リダイレクタでの通信タイムアウト後の動作

通信タイムアウトが発生すると，リダイレクタは，Webコンテナとのコネクションを切断し，クライアントにステータスコード500のエラーを返します。

ポイント

アプリケーション処理中にタイムアウトが発生したときの動作

Webコンテナでの処理中にリダイレクタがタイムアウトしていても，Webコンテナでは，リダイレクタがタイムアウトしていることを検知できません。

リダイレクタでのタイムアウトを検知できるのは，Webコンテナの処理が完了し，リダイレクタへレスポンスを転送するときとなります。しかし，この時点では，すでにリダイレクタがWebコンテナとのコネクションを切断しているため，レスポンス送信はエラーとなります。アプリケーション処理中にタイムアウトが発生したときの動作について次の図に示します。

図3-20　アプリケーション処理中にタイムアウトが発生したときの動作

図について説明します。

リダイレクタでタイムアウトが発生すると，Webコンテナとのコネクションを切断する要求を出します。

リダイレクタはWebサーバに対して，エラーコードを送信します。

Webコンテナでのアプリケーションの処理が完了すると，リダイレクタに対して，レスポンスを送信しますが，1.で，すでにリダイレクタとWebコンテナのコネクションは切断されているため，通信エラーが発生します。

(3)　Webサーバでのレスポンス送信時

Webサーバでは，クライアントへのデータ送信処理に対して，タイムアウト時間を設定できます。設定した通信タイムアウトによって，クライアント側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

クライアントが稼働するホストがダウンした

クライアント－Webサーバ間のネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

3.6.3　通信タイムアウトの設定

ここでは，クライアント－Webサーバ間，およびWebサーバ（リダイレクタ）－Webコンテナ間の通信タイムアウトの設定について説明します。

通信タイムアウトは，リクエストの送受信時，またはレスポンスの送受信時に設定します。通信タイムアウトの設定は，Smart Composerの使用の有無によって設定方法が異なります。通信タイムアウトの設定方法の参照先について，次の表に示します。

表3-15　通信タイムアウト（Webサーバ連携）の設定方法の参照先

設定するタイミング | Smart Composerの使用
使用する | 使用しない
リクエスト送受信時 | 3.6.4 | 3.6.5
レスポンスの送受信時 | 3.6.6 | 3.6.7

なお，通信タイムアウトは，EJBを呼び出すEJBクライアント側でも設定できます。EJBクライアント側での設定は，J2EEアプリケーション開発時に設定します。設定方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.11.5　RMI-IIOP通信のタイムアウト」を参照してください。

3.6.4　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

リクエスト送受信時の通信タイムアウトは，クライアント－Webサーバ間，リダイレクタ－Webコンテナ間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

＜この項の構成＞

(1)　Webサーバでのリクエスト受信時の設定

(2)　リダイレクタでのリクエスト送信時の設定

(3)　Webコンテナでのリクエスト受信時の設定

(1)　Webサーバでのリクエスト受信時の設定

クライアントからのリクエストをWebサーバで受信するときの通信タイムアウトは，Webサーバに設定します。Webサーバには，Hitachi Web Serverを使用できます。

(a)　設定方法

クライアントから転送されたリクエストの受信処理の通信タイムアウトを，httpsd.confに設定してください。

リクエスト受信処理の待ち時間
Timeoutディレクティブに，クライアントからのリクエスト受信処理の待ち時間（秒）を設定します。Timeoutディレクティブのデフォルト値は300秒です。なお，ここに設定する値は，クライアントへのデータ送信処理に対する通信タイムアウトと共用です。クライアントへのデータ送信処理に対する通信タイムアウトについては，「3.6.6(3)　Webサーバでのレスポンス送信時の設定」を参照してください。

(b)　設定時の注意

Webサーバでのリクエスト受信時に設定するタイムアウト値については，クライアント－Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，障害が発生したと判断できる時間を設定してください。

(2)　リダイレクタでのリクエスト送信時の設定

リダイレクタからWebコンテナにリクエストを送信するときには，Webコンテナとのコネクションを確立してからリクエストを送信します。リダイレクタからWebコンテナにリクエストを送信するときの通信タイムアウトは，コネクション確立時，およびリクエスト送信時に設定できます。また，コネクションの確立およびリクエストヘッダの送信に失敗した場合のリトライ回数を設定できます。

(a)　設定方法

リダイレクタからの，コネクション確立およびリクエスト送信処理の通信タイムアウトおよびリトライ回数を，簡易構築定義ファイルに設定してください。

コネクション確立の通信タイムアウト
論理Webサーバ（web-server）の<configuration>タグ内に，JkConnectTimeoutパラメタで，Webコンテナへのコネクション確立処理の待ち時間（秒）を設定します。JkConnectTimeoutパラメタのデフォルト値は30秒です。

リクエスト送信処理のタイムアウト
論理Webサーバ（web-server）の<configuration>タグ内に，JkSendTimeoutパラメタで，Webコンテナへのリクエスト送信処理の待ち時間（秒）を設定します。JkSendTimeoutパラメタのデフォルト値は100秒です。

コネクション確立およびリクエスト送信のリトライ回数
論理Webサーバ（web-server）の<configuration>タグ内に，JkRequestRetryCountパラメタで，Webコンテナへのコネクション確立およびリクエスト送信のリトライ回数を設定します。JkRequestRetryCountパラメタのデフォルト値は3回です。

(b)　設定時の注意

リダイレクタでのリクエスト送信時に設定する通信タイムアウト値，およびリトライ回数については，次の点に考慮して設定してください。

リトライ回数には，初回のコネクション確立およびリクエスト送信が含まれます。このため，初回のコネクション確立またはリクエスト送信処理で失敗した場合，コネクション確立またはリクエスト送信処理のリトライは，2回目としてカウントされます。

コネクション確立およびリクエスト送信処理の通信タイムアウト時間に0を指定した場合，またはTCPが持つコネクション確立およびデータ送信の再送タイマより長い時間を設定した場合は，通信タイムアウト時間はTCPの持つタイムアウト時間が適用されます。

(3)　Webコンテナでのリクエスト受信時の設定

リダイレクタからのリクエストをWebコンテナで受信するときの通信タイムアウトは，Webコンテナに設定します。

(a)　設定方法

リダイレクタから転送されたリクエストの受信処理の通信タイムアウトを，簡易構築定義ファイルに設定してください。

リクエスト受信処理のタイムアウト
論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.connector.ajp13.receive_timeoutパラメタで，リダイレクタからのリクエスト受信処理の待ち時間（秒）を設定します。パラメタのデフォルト値は100秒です。

(b)　設定時の注意

Webコンテナでのリクエスト受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

Webサーバのリクエスト受信時のタイムアウトに設定した時間より，大きい値を設定してください。
Webサーバのリクエスト受信時のタイムアウトに設定した時間より，小さい値を設定しているときに，クライアントや，クライアント－Webサーバ間でネットワーク障害が発生すると，Webサーバより先にWebコンテナでタイムアウトが発生してしまいます。この場合，障害が発生したのが，Webサーバ側であるのか，クライアント側であるのかが判別できなくなります。

クライアントからのデータ受信が必要な場合，クライアントとの通信速度を考慮して，データ受信ができる時間を設定してください。

リダイレクタでのWebコンテナへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。
なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

3.6.5　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

リクエスト送受信時の通信タイムアウトは，クライアント－Webサーバ間，リダイレクタ－Webコンテナ間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

＜この項の構成＞

(1)　Webサーバでのリクエスト受信時の設定

(2)　リダイレクタでのリクエスト送信時の設定

(3)　Webコンテナでのリクエスト受信時の設定

(1)　Webサーバでのリクエスト受信時の設定

クライアントからのリクエストをWebサーバで受信するときの通信タイムアウトは，Webサーバに設定します。Webサーバには，Hitachi Web ServerまたはMicrosoft IISのどちらかを使用できます。

(a)　設定方法

クライアントから転送されたリクエストの受信処理の通信タイムアウトを，次のファイルに設定してください。

httpsd.conf（Hitachi Web Serverの場合）
Timeoutディレクティブに，クライアントからのリクエスト受信処理の待ち時間（秒）を設定します。Timeoutディレクティブのデフォルト値は300秒です。なお，ここに設定する値は，クライアントへのデータ送信処理に対する通信タイムアウトと共用です。クライアントへのデータ送信処理に対する通信タイムアウトについては，「3.6.6(3)　Webサーバでのレスポンス送信時の設定」を参照してください。

isapi_redirect.conf（Microsoft IISの場合）
receive_client_timeoutキーに，クライアントからのリクエスト受信処理の待ち時間（秒）を設定します。

(b)　設定時の注意

Webサーバでのリクエスト受信時に設定するタイムアウト値については，クライアント－Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，障害が発生したと判断できる時間を設定してください。

(2)　リダイレクタでのリクエスト送信時の設定

リダイレクタからWebコンテナにリクエストを送信するときには，Webコンテナとのコネクションを確立してからリクエストを送信します。リダイレクタからWebコンテナにリクエストを送信するときの通信タイムアウトは，コネクション確立時，およびリクエスト送信時に設定できます。また，コネクションの確立およびリクエストヘッダの送信に失敗した場合のリトライ回数を設定できます。

(a)　設定方法

リダイレクタからの，コネクション確立およびリクエスト送信処理の通信タイムアウトおよびリトライ回数を，次のファイルに設定してください。

mod_jk.conf（Hitachi Web Serverの場合）

コネクション確立の通信タイムアウト
JkConnectTimeoutキーに，Webコンテナへのコネクション確立処理の待ち時間（秒）を設定します。JkConnectTimeoutキーのデフォルト値は30秒です。

リクエスト送信処理のタイムアウト
JkSendTimeoutキーに，Webコンテナへのリクエスト送信処理の待ち時間（秒）を設定します。JkSendTimeoutキーのデフォルト値は100秒です。

コネクション確立およびリクエスト送信のリトライ回数
JkRequestRetryCountキーに，Webコンテナへのコネクション確立およびリクエスト送信のリトライ回数を設定します。JkRequestRetryCountキーのデフォルト値は3回です。

isapi_redirect.conf（Microsoft IISの場合）

コネクション確立処理の通信タイムアウト
connect_timeoutキーに，Webコンテナへのコネクション確立処理の待ち時間（秒）を設定します。connect_timeoutキーのデフォルト値は30秒です。

リクエスト送信処理のタイムアウト
send_timeoutキーに，Webコンテナへのリクエスト送信処理の待ち時間（秒）を設定します。send_timeoutキーのデフォルト値は100秒です。

コネクション確立およびリクエスト送信のリトライ回数
request_retry_countキーに，Webコンテナへのコネクション確立およびリクエスト送信のリトライ回数を設定します。request_retry_countキーのデフォルト値は3回です。

(b)　設定時の注意

リダイレクタでのリクエスト送信時に設定する通信タイムアウト値，およびリトライ回数については，次の点に考慮して設定してください。

リトライ回数には，初回のコネクション確立およびリクエスト送信が含まれます。このため，初回のコネクション確立またはリクエスト送信処理で失敗した場合，コネクション確立またはリクエスト送信処理のリトライは，2回目としてカウントされます。

コネクション確立およびリクエスト送信処理の通信タイムアウト時間に0を指定した場合，またはTCPが持つコネクション確立およびデータ送信の再送タイマより長い時間を設定した場合は，通信タイムアウト時間はTCPの持つタイムアウト時間が適用されます。

(3)　Webコンテナでのリクエスト受信時の設定

リダイレクタからのリクエストをWebコンテナで受信するときの通信タイムアウトは，Webコンテナに設定します。

(a)　設定方法

リダイレクタから転送されたリクエストの受信処理の通信タイムアウトを，次のファイルに設定してください。

usrconf.properties
webserver.connector.ajp13.receive_timeoutキーに，リダイレクタからのリクエスト受信処理の待ち時間（秒）を設定します。

(b)　設定時の注意

Webコンテナでのリクエスト受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

Webサーバのリクエスト受信時のタイムアウトに設定した時間より，大きい値を設定してください。
Webサーバのリクエスト受信時のタイムアウトに設定した時間より，小さい値を設定しているときに，クライアントや，クライアント－Webサーバ間でネットワーク障害が発生すると，Webサーバより先にWebコンテナでタイムアウトが発生してしまいます。この場合，障害が発生したのが，Webサーバ側であるのか，クライアント側であるのかが判別できなくなります。

クライアントからのデータ受信が必要な場合，クライアントとの通信速度を考慮して，データ受信ができる時間を設定してください。

リダイレクタでのWebコンテナへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。
なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

3.6.6　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

レスポンス送受信時の通信タイムアウトは，Webコンテナ－リダイレクタ間，Webサーバ－クライアント間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

＜この項の構成＞

(1)　Webコンテナでのレスポンス送信時の設定

(2)　リダイレクタでのレスポンス受信時の設定

(3)　Webサーバでのレスポンス送信時の設定

(1)　Webコンテナでのレスポンス送信時の設定

Webコンテナからリダイレクタにレスポンス送信処理するときの通信タイムアウトは，Webコンテナに設定します。Webコンテナからのレスポンス送信時の待ち時間は，簡易構築定義ファイルに設定してください。

レスポンス送信処理のタイムアウト
論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.connector.ajp13.send_timeoutパラメタで，Webコンテナからのレスポンス送信時のタイムアウト時間（秒）を設定します。パラメタのデフォルト値は600秒です。

(2)　リダイレクタでのレスポンス受信時の設定

Webコンテナからのレスポンスを受信するときの通信タイムアウトをリダイレクタに設定します。

(a)　設定方法

Webコンテナからのレスポンス待ち時間を，簡易構築定義ファイルに設定してください。

レスポンス受信処理のタイムアウト
論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，worker.<ワーカ名>.receive_timeoutパラメタで，ワーカごとのレスポンス待ち時間（秒）を設定します。パラメタのデフォルト値は3600秒です。J2EEアプリケーション単位で通信タイムアウトを設定したい場合は，J2EEアプリケーションごとにワーカを定義してマッピングしてください。

(b)　設定時の注意

リダイレクタでのレスポンス受信時のタイムアウトでは，Webアプリケーションの障害を検知できます。そのため，運用状況によっては，Webアプリケーションの処理に必要となる時間を考慮して，障害検知と判断できる値を通信タイムアウトに設定する必要があります。

リダイレクタでのレスポンス受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

通信タイムアウトには，Webアプリケーションの処理に必要な時間より長い時間を設定してください。
設定したタイムアウトの時間が，Webアプリケーションの処理時間より短い場合，Webアプリケーションは正常に処理されていても，リダイレクタ側ではタイムアウトが発生したと判断して，クライアントにエラーが返されます。

Webコンテナのピーク時の，同時実行スレッド数の制御による待ち時間を考慮してください。
同時実行スレッド数の制御によって，Webコンテナのピーク時には，処理待ちリクエストの発生が考えられます。このため，同時実行スレッド数の制御を設定している場合，リクエストの処理時間が延長されることも考慮して，通信タイムアウトを設定しておく必要があります。同時実行スレッド数の制御の設定については，「2.15　同時実行スレッド数の制御の概要」を参照してください。

Webコンテナでのリダイレクタへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。
なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

(3)　Webサーバでのレスポンス送信時の設定

クライアントにレスポンスを送信するときの通信タイムアウトは，Webサーバに設定します。

(a)　設定方法

クライアントからのレスポンス待ち時間を，httpsd.confに設定してください。

データ送信処理の通信タイムアウト
Timeoutディレクティブに通信タイムアウトを設定してください。なお，Timeoutディレクティブで指定する通信タイムアウトは，リクエスト受信処理に対する通信タイムアウトおよびレスポンス送信処理に対する通信タイムアウトの両方の時間として指定します。このため，リクエスト受信処理の通信タイムアウトとレスポンス送信処理の通信タイムアウトで異なる時間を設定することはできません。
クライアントからのリクエスト受信処理に対する通信タイムアウトについては，「3.6.4(1)　Webサーバでのリクエスト受信時の設定」を参照してください。

(b)　設定時の注意

Webサーバでのレスポンス送信時に設定するタイムアウト値については，クライアント－Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，クライアントとデータの送受信をするのに十分な時間を設定してください。

また，Webサーバでのレスポンス送信時のタイムアウトは，Webコンテナでのレスポンス送信時のタイムアウト値よりも小さな値を設定してください。Webサーバでのレスポンス送信時のタイムアウトを，Webコンテナでのレスポンス送受信時のタイムアウト値よりも大きな値を設定しているときに，クライアント－Webサーバ間で障害が発生すると，Webサーバでのクライアントへのレスポンス送信のタイムアウトよりも先に，Webコンテナでのリダイレクタへのレスポンス送信でタイムアウトが発生するおそれがあります。この場合，障害が発生したのが，クライアント－Webサーバ間か，リダイレクタ－Webコンテナ間か判別できなくなります。

3.6.7　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

レスポンス送受信時の通信タイムアウトは，Webコンテナ－リダイレクタ間，Webサーバ－クライアント間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

＜この項の構成＞

(1)　Webコンテナでのレスポンス送信時の設定

(2)　リダイレクタでのレスポンス受信時の設定

(3)　Webサーバでのレスポンス送信時の設定

(1)　Webコンテナでのレスポンス送信時の設定

Webコンテナからリダイレクタにレスポンス送信処理するときの通信タイムアウトは，Webコンテナに設定します。Webコンテナからのレスポンス送信時の待ち時間は，次のファイルに，を設定してください。

usrconf.properties
webserver.connector.ajp13.send_timeoutキーに，Webコンテナからのレスポンス送信時のタイムアウト時間（秒）を設定します。デフォルト値は600秒です。

(2)　リダイレクタでのレスポンス受信時の設定

Webコンテナからのレスポンスを受信するときの通信タイムアウトをリダイレクタに設定します。

(a)　設定方法

次のファイルに，Webコンテナからのレスポンス待ち時間を設定してください。

workers.properties
worker.<ワーカ名>.receive_timeoutキーに，ワーカごとのレスポンス待ち時間（秒）を設定します。J2EEアプリケーション単位で通信タイムアウトを設定したい場合は，J2EEアプリケーションごとにワーカを定義してマッピングしてください。

(b)　設定時の注意

リダイレクタでのレスポンス受信時のタイムアウトでは，Webアプリケーションの障害を検知できます。そのため，運用状況によっては，Webアプリケーションの処理に必要となる時間を考慮して，障害検知と判断できる値を通信タイムアウトに設定する必要があります。

リダイレクタでのレスポンス受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

通信タイムアウトには，Webアプリケーションの処理に必要な時間より長い時間を設定してください。
設定したタイムアウトの時間が，Webアプリケーションの処理時間より短い場合，Webアプリケーションは正常に処理されていても，リダイレクタ側ではタイムアウトが発生したと判断して，クライアントにエラーが返されます。

Webコンテナのピーク時の，同時実行スレッド数の制御による待ち時間を考慮してください。
同時実行スレッド数の制御によって，Webコンテナのピーク時には，処理待ちリクエストの発生が考えられます。このため，サーバ管理コマンドを使用して同時実行スレッド数の制御を設定している場合，リクエストの処理時間が延長されることも考慮して，通信タイムアウトを設定しておく必要があります。サーバ管理コマンドでの同時実行スレッド数の制御の設定については，「2.15　同時実行スレッド数の制御の概要」を参照してください。

Webコンテナでのリダイレクタへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。
なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

(3)　Webサーバでのレスポンス送信時の設定

クライアントにレスポンスを送信するときの通信タイムアウトをWebサーバに設定できます。

(a)　設定方法

次のファイルに，クライアントからのレスポンス待ち時間を設定してください。

httpsd.conf（Hitachi Web Serverの場合）
Timeoutディレクティブに通信タイムアウトを設定してください。なお，Timeoutディレクティブで指定する通信タイムアウトは，リクエスト受信処理に対する通信タイムアウトおよびレスポンス送信処理に対する通信タイムアウトの両方の時間として指定します。このため，リクエスト受信処理の通信タイムアウトとレスポンス送信処理の通信タイムアウトで異なる時間を設定することはできません。
クライアントからのリクエスト受信処理に対する通信タイムアウトについては，「3.6.4(1)　Webサーバでのリクエスト受信時の設定」を参照してください。

MinFileBytesPerSecプロパティ（Microsoft IISの場合）
MinFileBytesPerSecプロパティに通信タイムアウトを設定してください。MinFileBytesPerSecプロパティには，Webサーバからクライアントへ送信するレスポンスデータのスループット（バイト/秒）を指定します。レスポンスデータのスループットがMinFileBytesPerSecに設定した値を下回った場合に，通信タイムアウトが発生します。なお，通信タイムアウトのデフォルトは240バイト/秒です。
設定の詳細については，Microsoft IISのマニュアルを参照してください。

(b)　設定時の注意

Webサーバでのレスポンス送信時に設定するタイムアウト値については，クライアント－Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，クライアントとデータの送受信をするのに十分な時間を設定してください。

また，Webサーバでのレスポンス送信時のタイムアウトは，Webコンテナでのレスポンス送信時のタイムアウト値よりも小さな値を設定してください。Webサーバでのレスポンス送信時のタイムアウトを，Webコンテナでのレスポンス送受信時のタイムアウト値よりも大きな値を設定しているときに，クライアント－Webサーバ間で障害が発生すると，Webサーバでのクライアントへのレスポンス送信のタイムアウトよりも先に，Webコンテナでのリダイレクタへのレスポンス送信でタイムアウトが発生するおそれがあります。この場合，障害が発生したのが，クライアント－Webサーバ間か，リダイレクタ－Webコンテナ間か判別できなくなります。

3.7　IPアドレス指定（Webサーバ連携）

この節では，Webサーバ連携でのIPアドレス指定によるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表3-16　この節の構成（IPアドレス指定（Webサーバ連携））

分類 | タイトル | 参照先
解説 | バインド先アドレス設定機能 | 3.7.1
設定 | 実行環境での設定（J2EEサーバの設定） | 3.7.2
注意事項 | Webサーバ連携でのIPアドレス指定をする場合の注意事項 | 3.7.3

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

3.7.1　バインド先アドレス設定機能

3.7.2　実行環境での設定（J2EEサーバの設定）

3.7.3　Webサーバ連携でのIPアドレス指定をする場合の注意事項

3.7.1　バインド先アドレス設定機能

Webコンテナでは，Webサーバ連携で利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数の物理ネットワークインタフェースを持つホスト，または一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するよう設定できます。

バインドするIPアドレスは，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.7.2　実行環境での設定（J2EEサーバの設定）」を参照してください。

3.7.2　実行環境での設定（J2EEサーバの設定）

Webサーバ連携でのIPアドレス指定を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webサーバ連携でのIPアドレス指定の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.ajp13.bind_host

Webサーバ連携機能を使用する場合のIPアドレスまたはホスト名を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

3.7.3　Webサーバ連携でのIPアドレス指定をする場合の注意事項

Webサーバ連携でのIPアドレス指定をする場合の注意事項を次に示します。

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。デフォルトでは，ワイルドカードアドレスを使用する設定になっています。なお，ワイルドカードアドレスを使用する場合は，次のことに注意してください。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

3.8　エラーページのカスタマイズ（Webサーバ連携）

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。クライアント側では，Webコンテナから返されたエラーステータスコードに対応するエラーページが表示されます。アプリケーションサーバでは，クライアントで表示されるエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

この節では，Webサーバと連携した場合の，Webサーバの機能を使用したエラーページのカスタマイズについて説明します。

この節の構成を次の表に示します。

表3-17　この節の構成（エラーページのカスタマイズ（Webサーバ連携））

分類 | タイトル | 参照先
解説 | エラーページのカスタマイズの概要 | 3.8.1
エラーページのカスタマイズの仕組み | 3.8.2
設定 | 実行環境での設定（Smart Composer機能を使用する場合） | 3.8.3
実行環境での設定（Smart Composer機能を使用しない場合） | 3.8.4
注意事項 | エラーページのカスタマイズの注意事項 | 3.8.5

注　「実装」および「運用」について，この機能固有の説明はありません。

注意

Webサーバの機能を使用したエラーページのカスタマイズは，Webサーバ連携機能を使用する場合に使用できる機能です。WebサーバがHitachi Web Serverの場合だけ使用できます。Microsoft IISの場合は使用できません。

＜この節の構成＞

3.8.1　エラーページのカスタマイズの概要

3.8.2　エラーページのカスタマイズの仕組み

3.8.3　実行環境での設定（Smart Composer機能を使用する場合）

3.8.4　実行環境での設定（Smart Composer機能を使用しない場合）

3.8.5　エラーページのカスタマイズの注意事項

3.8.1　エラーページのカスタマイズの概要

エラーページをカスタマイズするには，Servlet仕様で規定されているweb.xmlの<error-page>タグを使用する方法と，Webサーバの機能を使用する方法があります。ただし，リダイレクタがWebコンテナとの通信に失敗した場合など，リダイレクタがエラーを返す場合のエラーページは，web.xmlの<error-page>タグを使用する方法ではカスタマイズできません。リダイレクタがエラーを返す場合のエラーページのカスタマイズは，Webサーバの機能を使用する方法で行ってください。エラー発生場所とエラーページのカスタマイズ方法の対応を表に示します。

表3-18　エラー発生場所とエラーページのカスタマイズ方法の対応

エラー発生場所 | カスタマイズ方法
Webサーバの機能を使用する方法 | web.xmlの<error-page>タグを使用する方法
Webコンテナ | ○ | ○
リダイレクタ | ○ | ×

（凡例）　○：カスタマイズできる　×：カスタマイズできない

なお，Webコンテナでエラーが発生する条件と，対応するエラーステータスコードについては，「付録A　エラーステータスコード」を参照してください。

3.8.2　エラーページのカスタマイズの仕組み

エラーページのカスタマイズの処理の仕組みを，Webコンテナでエラーが発生した場合，およびリダイレクタでエラーが発生した場合のそれぞれについて説明します。

Webコンテナでエラーが発生した場合

Webコンテナからのエラーステータスコードは，リダイレクタが受信します。リダイレクタは，エラーページの作成をWebサーバに委任し，Webサーバでエラーステータスコードに対応したユーザ作成のページをクライアントに送信します。これによって，クライアントでは，ユーザが作成したページが表示されます。

エラーページのカスタマイズの処理の流れを次の図に示します。

図3-21　ユーザ作成のエラーページ表示の流れ（Webサーバの機能を使用する場合）

図中の1.～3.について説明します。

クライアントから存在しないリソースへのアクセスがあると，Webコンテナでは，404エラーをWebサーバに返します。

リダイレクタは404エラーを受け取ると，設定情報※を基にして，404エラーに対応するエラーページの生成をWebサーバに依頼します。

Webサーバでは，設定情報※を基に404エラーに対応するエラーページ「missing.html」を，クライアントに返します。

リダイレクタでエラーが発生した場合

リダイレクタでエラーが発生すると，リダイレクタは設定情報を基にして，発生したエラーに対応するエラーページの生成をWebサーバに依頼します。Webサーバでは，設定情報※を基にエラーステータスコードに対応したユーザ作成のページをクライアントに送信します。これによって，クライアントでは，ユーザが作成したページが表示されます。

注※

エラーページをカスタマイズするためには，あらかじめ，エラーステータスコードとエラーページの対応づけをしておく必要があります。

対応づけの概要を次の図に示します。

図3-22　エラーステータスコードとエラーページの対応づけ（Webサーバの機能を使用する場合）

エラーが発生したときに，エラーステータスコードが表示されたエラーページの代わりにユーザが作成したエラーページを表示させるためには，ユーザが作成したエラーページを特定のエラーステータスコードと対応づけます。該当するエラーステータスコードのエラーが発生した場合には，Webサーバ（Hitachi Web Server）に設定された情報を基に，エラーステータスコードに対応したエラーページをクライアントに送信します。

3.8.3　実行環境での設定（Smart Composer機能を使用する場合）

ここでは，エラーページのカスタマイズの設定について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

エラーステータスコードとエラーページとの対応づけは，次のファイルで定義します。

簡易構築定義ファイル
論理Webサーバ（web-server）の<configuration>タグ内に，worker.<ワーカ名>.delegate_error_codeパラメタで，エラーページに対応づけたいエラーステータスコードを設定します。

httpsd.conf
ErrorDocumentディレクティブで，エラーステータスコードと，対応するエラーページのファイル名を対応づけます。

(a)　エラーステータスコード設定時の注意事項

簡易構築定義ファイルでエラーステータスコードを指定する場合の注意事項を次に示します。

エラーステータスコードは，ワーカ単位で指定します。

エラーステータスコードを指定できるワーカのタイプは，「ajp13」だけです。ワーカのタイプが「lb」（ラウンドロビンに基づく負荷分散をするときの設定），および「post_size_lb」（POSTデータサイズに基づく振り分けをするときの設定）の場合，指定した内容は無視されます。

指定できるエラーステータスコードは，次の表のとおりです。これ以外のエラーステータスコードにエラーページを対応づけることはできません。

表3-19　エラーページと対応づけできるエラーステータスコード

エラーステータスコード | 説明句
400 | Bad Request
401 | Unauthorized
402 | Payment Required
403 | Forbidden
404 | Not Found
405 | Method Not Allowed
406 | Not Acceptable
407 | Proxy Authentication Required
408 | Request Time-out
409 | Conflict
410 | Gone
411 | Length Required
412 | Precondition Failed
413 | Request Entity Too Large
414 | Request-URI Too Long
415 | Unsupported Media Type
416 | Requested Range Not Satisfiable
417 | Expectation Failed
422 | Unprocessible Entity
423 | Locked
424 | Failed Dependency
500 | Internal Server Error
501 | Not Implemented
502 | Bad Gateway
503 | Service Unavailable
504 | Gateway Time-out
505 | HTTP Version not supported
507 | Insufficient Storage
510 | Not Extended

(b)　ErrorDocumentディレクティブ指定時の注意事項

httpsd.confでErrorDocumentディレクティブを指定する場合の注意事項を次に示します。

ErrorDocumentディレクティブにローカルURLを使用する場合には，リダイレクタがWebコンテナに転送しないURLを指定する必要があります。

ルートコンテキストの使用時など，リダイレクタの設定で「/*」というURLパターンをワーカにマッピングしている場合，すべてのリクエストがWebコンテナに転送されます。そのため，ErrorDocumentディレクティブには，Webコンテナ上のリソースを，完全URLを使用して設定してください。
ルートコンテキストを使用する場合で，エラーステータスコード404発生時に，Webコンテナ上のルートコンテキスト配下のerror404.jspを表示させるための設定例を次に示します。hostAは，Webサーバ稼働ホストです。

（例）

ErrorDocument 404 http://hostA/error404.jsp

また，このときWebコンテナが停止している場合には，リダイレクタはエラーステータスコード500のエラーを返します。このため，Webコンテナが停止している際のエラーページをカスタマイズするには，ErrorDocumentディレクティブで，エラーステータスコード500に対して別のWebサーバのリソースを，完全URLで指定する必要があります。

(2)　設定例

エラーページのカスタマイズの例を次に示します。

簡易構築定義ファイルの例

：
<param>
 <param-name>worker.list</param-name>
 <param-value>worker1</param-value>
</param>
<param>
 <param-name>worker.worker1.type</param-name>
 <param-value>ajp13</param-value>
</param>
<param>
 <param-name>worker.worker1.host</param-name>
 <param-value>host1</param-value>
</param>
<param>
 <param-name>worker.worker1.delegate_error_code</param-name>
 <param-value>404</param-value>
</param>
：

worker.<ワーカ名>.delegate_error_codeパラメタに，エラーステータスコード「404（Not Found）」を定義しています。

httpsd.confの例

# httpsd.confの記述#
#　　　　　：
ErrorDocument 404 /missing.html

エラーステータスコードと，対応するエラーページのファイル名を対応づけます。エラーステータスコード「404（Not Found）」のエラーが発生した場合に，missing.htmlファイルを表示するようになります。

ErrorDocumentディレクティブの詳細については，マニュアル「Hitachi Web Server」を参照してください。

3.8.4　実行環境での設定（Smart Composer機能を使用しない場合）

ここでは，エラーページのカスタマイズの設定について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

エラーステータスコードとエラーページとの対応づけは，次のファイルで定義します。

workers.properties
worker.<ワーカ名>.delegate_error_codeキーに，エラーページに対応づけたい，エラーステータスコードを設定します。

httpsd.conf
ErrorDocumentディレクティブで，エラーステータスコードと，対応するエラーページのファイル名を対応づけます。

workers.properties設定時の注意事項

エラーステータスコードは，ワーカ単位で指定します。

エラーステータスコードを指定できるワーカのタイプは，「ajp13」だけです。ワーカのタイプが「lb」（ラウンドロビンに基づく負荷分散をするときの設定）の場合，指定した内容は無視されます。

指定できるエラーステータスコードは，次の表のとおりです。これ以外のエラーステータスコードにエラーページを対応づけることはできません。

表3-20　エラーページと対応づけできるエラーステータスコード

エラーステータスコード | 説明句
400 | Bad Request
401 | Unauthorized
402 | Payment Required
403 | Forbidden
404 | Not Found
405 | Method Not Allowed
406 | Not Acceptable
407 | Proxy Authentication Required
408 | Request Time-out
409 | Conflict
410 | Gone
411 | Length Required
412 | Precondition Failed
413 | Request Entity Too Large
414 | Request-URI Too Long
415 | Unsupported Media Type
416 | Requested Range Not Satisfiable
417 | Expectation Failed
422 | Unprocessible Entity
423 | Locked
424 | Failed Dependency
500 | Internal Server Error
501 | Not Implemented
502 | Bad Gateway
503 | Service Unavailable
504 | Gateway Time-out
505 | HTTP Version not supported
507 | Insufficient Storage
510 | Not Extended

ErrorDocumentディレクティブ指定時の注意事項

ErrorDocumentディレクティブにローカルURLを使用する場合には，リダイレクタがWebコンテナに転送しないURLを指定する必要があります。

ルートコンテキストの使用時など，リダイレクタの設定で「/*」というURLパターンをワーカにマッピングしている場合，すべてのリクエストがWebコンテナに転送されます。そのため，ErrorDocumentディレクティブには，Webコンテナ上のリソースを，完全URLを使用して設定してください。
ルートコンテキストを使用する場合で，エラーステータスコード404発生時に，Webコンテナ上のルートコンテキスト配下のerror404.jspを表示させるための設定例を次に示します。hostAは，Webサーバ稼働ホストです。

ErrorDocument 404 http://hostA/error404.jsp

また，このときWebコンテナが停止している場合には，リダイレクタはエラーステータスコード500のエラーを返します。このため，Webコンテナが停止している際のエラーページをカスタマイズするには，ErrorDocumentディレクティブで，エラーステータスコード500に対して別のWebサーバのリソースを，完全URLで指定する必要があります。

(2)　設定例

エラーページのカスタマイズの例を次に示します。

workers.propertiesの例

# ワーカ定義ファイルの記述
worker.list=worker1

worker.worker1.type=ajp13
worker.worker1.host=host1
worker.worker1.port=8007
worker.worker1.delegate_error_code=404

worker.<ワーカ名>.delegate_error_codeキーに，エラーステータスコード「404（Not Found）」を定義しています。

httpsd.confの例

# httpsd.confの記述#
#　　　　　：
ErrorDocument 404 /missing.html

エラーステータスコードと，対応するエラーページのファイル名を対応づけます。エラーステータスコード「404（Not Found）」のエラーが発生した場合に，missing.htmlファイルを表示するようになります。

ErrorDocumentディレクティブの詳細については，マニュアル「Hitachi Web Server」を参照してください。

3.8.5　エラーページのカスタマイズの注意事項

Webサーバ連携機能を使用する場合に，Webサーバの機能を使用してエラーページをカスタマイズするときの注意事項を次に示します。

エラーページのカスタマイズは，WebサーバがHitachi Web Serverの場合だけ使用できます。このため，Microsoft IISと連携している場合に，workers.propertiesにエラーページのカスタマイズを設定しても，無効となります。

Servlet 2.3仕様に対応したWebアプリケーションでは，サーブレットの仕様で規定されているweb.xmlの<error-page>タグによるエラーページのカスタマイズ機能を使用している場合，Webコンテナは<error-page>タグに記述されているページへのアクセス結果をステータスコードとして返却します。このため，<error-page>タグに記述されているページへのアクセスでエラーが発生しない場合には，この機能は動作しません。

エラーページのカスタマイズをするための設定が，ワーカ定義（workers.propertiesまたは簡易構築定義ファイル）またはhttpsd.confのどちらか一方にしかない場合，設定されているエラーがWebコンテナで発生しても，ユーザが設定したファイルは表示されません。
エラーページの生成を委任するエラーステータスコードがワーカ定義だけに指定されている（httpsd.confのErrorDocumentディレクティブを定義していない）場合，そのエラーステータスコードのエラーが発生したときに返却されるエラーページは，Hitachi Web Serverが自動生成したページになります。

3.9　ドメイン名指定でのトップページの表示

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。この機能は，Webサーバ連携機能を使用する場合に使用できます。ここでは，index.htmlやindex.jspなどのファイルを，welcomeファイルと呼びます。

この節では，ドメイン名指定でのトップページの表示について説明します。

この節の構成を次の表に示します。

表3-21　この節の構成（ドメイン名指定でのトップページの表示）

分類 | タイトル | 参照先
解説 | ドメイン名指定でのトップページの表示について | 3.9.1
設定 | 実行環境での設定（Smart Composer機能を使用する場合） | 3.9.2
実行環境での設定（Smart Composer機能を使用しない場合） | 3.9.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

3.9.1　ドメイン名指定でのトップページの表示について

3.9.2　実行環境での設定（Smart Composer機能を使用する場合）

3.9.3　実行環境での設定（Smart Composer機能を使用しない場合）

3.9.1　ドメイン名指定でのトップページの表示について

ドメイン名だけでトップページを表示させるには，welcomeファイルをルートコンテキストに配置する必要があります。ルートコンテキストとは，コンテキストルート※が空文字（コンテキストルートに名称が指定されていない）のコンテキストです。

注※

Webアプリケーションをまとめた管理単位を，コンテキストといいます。このコンテキストのルートパスをコンテキストルートといいます。Webアプリケーションにアクセスするときは，コンテキストルートをURL上に指定します。

コンテキストとコンテキストルートについて，次の図に示します。

図3-23　コンテキストとコンテキストルート

ドメイン名だけでトップページを表示させるには，次の設定が必要になります。

リダイレクタの設定
ルートコンテキストには，Webサーバ経由でアクセスします。このため，リダイレクタのURLマッピング定義で，該当するURLがリダイレクトされるように設定する必要があります。mod_jk.conf（Hitachi Web Serverの場合）またはuriworkermap.properties（Microsoft IISの場合）に設定します。

アプリケーションの設定
インポートしたJ2EEアプリケーションのコンテキストルートに空文字を指定します。

●注意事項

ドメイン名指定でのトップページの表示機能を使用する上での注意事項を次に示します。

コンテキストルートとルートコンテキストが同じ階層を持つ場合にアクセスされる階層
コンテキストルートとルートコンテキストが同じ階層を持つ場合，コンテキストルートの階層にアクセスされます。例を次に示します。

例

WebアプリケーションAがコンテキストルートexampleを持ち，WebアプリケーションBのコンテキストルートが空文字で，両方のWebアプリケーション内に「example」という階層を持つ場合の例を説明します。

図3-24　コンテキストルートとルートコンテキストが同じ階層を持つ場合にアクセスされる階層を持つ例

この場合，「http://<ホスト名>/example」にアクセスすると，コンテキストルートを持つ，WebアプリケーションAのexample/index.jspが実行されます。

ただし，ディレクトリ内に，forwardやincludeがある場合で，例えばディレクトリ内のforwardにアクセスすると，ルートコンテキストのindex.jspにforwardされます。

Webアプリケーション内の構成
URLの先頭に「ejb」や「web」を使用することはできません。

使用できない例

http://<ホスト名>:<ポート番号>/ejb/

http://<ホスト名>:<ポート番号>/web/

このため，ルートコンテキストとしてデプロイするWebアプリケーションでは，「ejb」または「web」が先頭になるような構成にしないでください。

メッセージ本文での表示方法
コンソールやログファイルに出力されるメッセージでは，コンテキストルートは空文字で表示されます。

3.9.2　実行環境での設定（Smart Composer機能を使用する場合）

ここでは，ドメイン名指定でトップページを表示するための設定について説明します。

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

ドメイン名指定でトップページを表示するための設定方法を次に示します。

ルートコンテキストを設定します。
ルートコンテキストとは，コンテキストルートに名称が指定されていないコンテキストのことです。ルートコンテキストの指定は，動作モードによって異なります。
アプリケーション開発時に，cosminexus.xmlの<war>タグ内の<context-root>に，ルートコンテキストを指定します。コンテキストルートとしてルートコンテキストを設定する場合は，空文字を指定します。
J2EEアプリケーションのコンテキストルート定義については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.11.1　J2EEアプリケーションのコンテキストルート定義」を参照してください。

リダイレクタで，ルートコンテキストへのリクエストの振り分けを設定します。
ルートコンテキストへのリクエストの振り分けは，簡易構築定義ファイルに指定します。

(2)　設定例

ルートコンテキストへのリクエストの振り分けの設定例について説明します。

URLにドメイン名を指定するだけで，Webアプリケーションのトップページを表示させるためには，リダイレクタのURLマッピング定義で，ルートコンテキストにリクエストが振り分けられるように設定してください。例えば，ルートコンテキストは「worker1」に，「/examples」はworker2に振り分ける場合には，次のように指定します。

簡易構築定義ファイルの例

：
<param>
 <param-name>JkMount</param-name>
 <param-value>/* worker1</param-value>
 <param-value>/examples/* worker2</param-value>
</param>
：

3.9.3　実行環境での設定（Smart Composer機能を使用しない場合）

ここでは，ドメイン名指定でトップページを表示するための設定について説明します。

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

ドメイン名指定でトップページを表示するための設定方法を次に示します。

ルートコンテキストを設定します。
ルートコンテキストとは，コンテキストルートに名称が指定されていないコンテキストのことです。ルートコンテキストの指定は，動作モードによって異なります。
サーバ管理コマンドを使用してJ2EEアプリケーションのプロパティを定義するときにルートコンテキストを指定します。コンテキストルートとしてルートコンテキストを設定する場合は，空文字を指定します。J2EEアプリケーションのコンテキストルート定義については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「9.11.1　J2EEアプリケーションのコンテキストルート定義」を参照してください。

リダイレクタで，ルートコンテキストへのリクエストの振り分けを設定します。
ルートコンテキストへのリクエストの振り分けは，WebサーバにHitachi Web Serverを使用している場合はmod_jk.confに，Microsoft IISを使用している場合はisapi_redirect.confに指定します。

(2)　設定例

ルートコンテキストへのリクエストの振り分けの設定例について説明します。

URLにドメイン名を指定するだけで，Webアプリケーションのトップページを表示させるためには，リダイレクタのURLマッピング定義で，ルートコンテキストにリクエストが振り分けられるように設定してください。例えば，ルートコンテキストは「worker1」に，「/examples」はworker2に振り分ける場合には，次のように指定します。

mod_jk.confの例（Hitachi Web Serverの場合）

JkMount /* worker1
JkMount /examples/* worker2

uriworkermap.propertiesの例（Microsoft IISの場合）

/*=worker1
/examples/*=worker2

3.10　Webコンテナへのゲートウェイ情報の通知

この節では，Webコンテナへのゲートウェイ情報の通知について説明します。

ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

この節の構成を次の表に示します。

表3-22　この節の構成（Webコンテナへのゲートウェイ情報の通知）

分類 | タイトル | 参照先
解説 | ゲートウェイ指定機能 | 3.10.1
設定 | 実行環境での設定（Smart Composer機能を使用する場合） | 3.10.2
実行環境での設定（Smart Composer機能を使用しない場合） | 3.10.3
注意事項 | Webコンテナにゲートウェイ情報を通知する場合の注意事項 | 3.10.4

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

3.10.1　ゲートウェイ指定機能

3.10.2　実行環境での設定（Smart Composer機能を使用する場合）

3.10.3　実行環境での設定（Smart Composer機能を使用しない場合）

3.10.4　Webコンテナにゲートウェイ情報を通知する場合の注意事項

3.10.1　ゲートウェイ指定機能

クライアントと，Webサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合で，welcomeファイルやForm認証画面への遷移時などにWebコンテナが自動的にリダイレクトするとき，Webコンテナではゲートウェイの情報を得ることができず，転送先のURLを正しく作成できないことがあります。

これを解決するために，ゲートウェイ指定機能を使用します。ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

ゲートウェイ指定機能は次のような場合に使用できます。

クライアントと，Webサーバとの間にSSLアクセラレータを配置する場合
クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，welcomeファイルやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。
この場合，ゲートウェイ指定機能を使用して，スキームを常にhttpsと見なすように指定することで，正しくリダイレクトできるようになります。

Hostヘッダのないリクエストに対して，リクエストを受けたWebサーバ以外へリダイレクトする必要がある場合
Hostヘッダのないリクエストをリダイレクトする場合，リダイレクト先URLのホスト名・ポート番号は，リクエストを受けたWebサーバのホスト名・ポート番号となります。
ゲートウェイ指定機能は，Webサーバの前に負荷分散機を配置している場合などで，クライアントがアクセスするURLのホスト名・ポート番号が，リクエストを受けたWebサーバと異なるときに使用します。これによって，クライアントからアクセスするホスト名・ポート番号が指定されるので，正しくリダイレクトできるようになります。

なお，Webサーバと連携する場合，一つのWebコンテナに複数の異なる経路でアクセスする場合（複数のゲートウェイからWebコンテナにHTTPリクエストが転送される場合など），ゲートウェイ指定機能を使用できません。Webサーバと連携する場合，ゲートウェイ指定機能を使用するには，Webコンテナへのアクセス経路は一つになる構成にする必要があります。

3.10.2　実行環境での設定（Smart Composer機能を使用する場合）

ここは，ゲートウェイ指定機能を使用するための設定について説明します。

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合，ゲートウェイ指定機能を使用することで，Webコンテナにゲートウェイ情報を通知し，WebアプリケーションのトップページやForm認証画面に正しくリダイレクトできるようになります。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

ゲートウェイ指定機能を使用するための設定方法を次に示します。

ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームを，リダイレクタごとに指定します。

Webサーバを再起動します。

なお，ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームは，簡易構築定義ファイルに指定します。論理Webサーバ（web-server）の<configuration>タグ内に，次のパラメタで指定します。

ホスト名：JkGatewayHost

ポート番号：JkGatewayPort

リダイレクト先URLのスキーム：JkGatewayHttpsScheme

(2)　設定例

ゲートウェイ指定機能の設定例を次に示します。

図3-25　ゲートウェイ指定機能の設定例

この例では，クライアントとWebサーバの間にSSLアクセラレータを配置しています。クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，WebアプリケーションのトップページやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。この場合，ゲートウェイ指定機能を使用して，スキームを常にHTTPSと見なすように指定することで，正しくリダイレクトできるようになります。

簡易構築定義ファイルの例を次に示します。ここでは，リダイレクト先URLのスキームを常にHTTPSと見なすようにJkGatewayHttpsSchemeパラメタで「On」を指定します。

簡易構築定義ファイルの例

：
<param>
 <param-name>JkGatewayHost</param-name>
 <param-value>host1</param-value>
</param>
<param>
 <param-name>JkGatewayPort</param-name>
 <param-value>4443</param-value>
</param>
<param>
 <param-name>JkGatewayHttpsScheme</param-name>
 <param-value>On</param-value>
</param>
：

3.10.3　実行環境での設定（Smart Composer機能を使用しない場合）

ここでは，ゲートウェイ指定機能を使用するための設定について説明します。

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合，ゲートウェイ指定機能を使用することで，Webコンテナにゲートウェイ情報を通知し，WebアプリケーションのトップページやForm認証画面に正しくリダイレクトできるようになります。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

ゲートウェイ指定機能を使用するための設定方法を次に示します。

ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームを，リダイレクタごとに指定します。

Webサーバを再起動します。

なお，ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームは，WebサーバにHitachi Web Serverを使用している場合はmod_jk.confに，Microsoft IISを使用している場合はisapi_redirect.confに指定します。指定するキーはそれぞれ次のとおりです。

mod_jk.confの場合
ホスト名：JkGatewayHostキー
ポート番号：JkGatewayPortキー
リダイレクト先URLのスキーム：JkGatewayHttpsSchemeキー

isapi_redirect.confの場合
ホスト名：gateway_hostキー
ポート番号：gateway_portキー
リダイレクト先URLのスキーム：gateway_https_schemeキー

(2)　設定例

ゲートウェイ指定機能の設定例を次に示します。

図3-26　ゲートウェイ指定機能の設定例

この例では，クライアントとWebサーバの間にSSLアクセラレータを配置しています。クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，WebアプリケーションのトップページやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。この場合，ゲートウェイ指定機能を使用して，スキームを常にHTTPSと見なすように指定することで，正しくリダイレクトできるようになります。

mod_jk.conf，およびisapi_redirect.confの例を次に示します。ここでは，リダイレクト先URLのスキームを常にHTTPSと見なすようにmod_jk.confのJkGatewayHttpsSchemeキーで「On」，isapi_redirect.confのgateway_https_schemeキーで「true」を指定します。

mod_jk.confの例（Hitachi Web Serverの場合）

JkGatewayHost host1

JkGatewayPort 4443

JkGatewayHttpsScheme On

isapi_redirect.confの例（Microsoft IISの場合）

gateway_host=host1

gateway_port=4443

gateway_https_scheme=true

3.10.4　Webコンテナにゲートウェイ情報を通知する場合の注意事項

ゲートウェイ指定機能を使用する上での注意事項を次に示します。

リダイレクト先URLのホスト名，およびポート番号の指定について
通常，ブラウザはHostヘッダを付けてリクエストを送信するため，リダイレクト先URLのホスト名やポート番号を指定する必要はありません。
なお，リクエストにHostヘッダがあるかどうかは，javax.servlet.http.HttpServletRequestクラスのgetHeaderメソッドに，引数「Host」を指定して呼び出すことで確認できます。

サーブレットAPIの動作について
ゲートウェイ指定機能の利用によって，一部のサーブレットAPIの動作が変わります。WebアプリケーションでAPIを利用するときには注意が必要です。
なお，動作が変わるサーブレットAPIについては，「5.1.2(10)　ゲートウェイ指定機能を使用する場合の注意」を参照してください。

web.xmlの<transport-guarantee>タグについて
ゲートウェイ指定機能でスキームをHTTPSと見なすように設定した場合，WebサーバへのリクエストがHTTPであってもHTTPSであると見なされます。このため，web.xmlの<transport-guarantee>タグでINTEGRALやCONFIDENTIALを指定してもHTTPSのURLへリダイレクトされないので注意してください。

CookieのSecure属性について
ゲートウェイ指定機能でスキームをHTTPSと見なすように設定している場合に，Webコンテナが生成したセッションIDを，Cookieによってクライアントに返すとき，そのCookieにはSecure属性が付与されます。

ゲートウェイを通さないWebサーバへの通信
リダイレクタでゲートウェイ指定機能を有効にした場合，そのWebサーバにSSLアクセラレータや負荷分散機などのゲートウェイを通さないとき，直接HTTP通信はできません。

4.　インプロセスHTTPサーバ

この章では，インプロセスHTTPサーバ機能の設定について説明します。

＜この章の構成＞

4.1　この章の構成

4.2　インプロセスHTTPサーバの概要

4.3　Webクライアントからの接続数の制御

4.4　リクエスト処理スレッド数の制御

4.5　Webクライアントからの同時接続数の制御によるリクエストの流量制御

4.6　同時実行スレッド数の制御によるリクエストの流量制御

4.7　リダイレクトによるリクエストの振り分け

4.8　Persistent ConnectionによるWebクライアントとの通信制御

4.9　通信タイムアウト（インプロセスHTTPサーバ）

4.10　IPアドレス指定（インプロセスHTTPサーバ）

4.11　アクセスを許可するホストの制限によるアクセス制御

4.12　リクエストデータのサイズの制限によるアクセス制御

4.13　有効なHTTPメソッドの制限によるアクセス制御

4.14　HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

4.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）

4.16　Webコンテナへのゲートウェイ情報の通知

4.17　ログ・トレースの出力

4.1　この章の構成

アプリケーションサーバでは，Webサーバ機能としてインプロセスHTTPサーバを提供しています。インプロセスHTTPサーバとは，J2EEサーバのプロセス内で提供されるWebサーバ機能です。Webサーバを経由しないで，HTTPリクエストをJ2EEサーバのプロセスが直接受信することによって，Webサーバ連携時よりも優れた処理性能でWebサーバの機能を利用できます。

インプロセスHTTPサーバの機能と参照先を次の表に示します。

表4-1　インプロセスHTTPサーバの機能と参照先

機能 | 参照先
インプロセスHTTPサーバの概要 | 4.2
Webクライアントからの接続数の制御 | 4.3
リクエスト処理スレッド数の制御 | 4.4
Webクライアントからの同時接続数の制御によるリクエストの流量制御 | 4.5
同時実行スレッド数の制御によるリクエストの流量制御 | 4.6
リダイレクトによるリクエストの振り分け | 4.7
Persistent ConnectionによるWebクライアントとの通信制御 | 4.8
通信タイムアウト（インプロセスHTTPサーバ） | 4.9
IPアドレス指定（インプロセスHTTPサーバ） | 4.10
アクセスを許可するホストの制限によるアクセス制御 | 4.11
リクエストデータのサイズの制限によるアクセス制御 | 4.12
有効なHTTPメソッドの制限によるアクセス制御 | 4.13
HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ | 4.14
エラーページのカスタマイズ（インプロセスHTTPサーバ） | 4.15
Webコンテナへのゲートウェイ情報の通知 | 4.16
ログ・トレースの出力 | 4.17

なお，アプリケーションサーバで提供するインプロセスHTTPサーバの機能には，Java EEで規定された機能にアプリケーションサーバ独自の機能を拡張したものと，アプリケーションサーバ独自の機能として提供しているものがあります。アプリケーションサーバ独自の機能かどうかについては，「1.2　システムの目的と機能の対応」を参照してください。

4.2　インプロセスHTTPサーバの概要

この節では，インプロセスHTTPサーバの概要について説明します。

この節の構成を次の表に示します。

表4-2　この節の構成（インプロセスHTTPサーバの概要）

分類 | タイトル | 参照先
解説 | インプロセスHTTPサーバの使用 | 4.2.1
インプロセスHTTPサーバで使用できる機能 | 4.2.2
設定 | 実行環境での設定（J2EEサーバの設定） | 4.2.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.2.1　インプロセスHTTPサーバの使用

4.2.2　インプロセスHTTPサーバで使用できる機能

4.2.3　実行環境での設定（J2EEサーバの設定）

4.2.1　インプロセスHTTPサーバの使用

インプロセスHTTPサーバは，J2EEサーバのプロセス内で提供されるWebサーバ機能です。

Webサーバを経由しないで，HTTPリクエストをJ2EEサーバのプロセスが直接受信することによって，Webサーバ連携時よりも優れた処理性能でWebサーバの機能を利用できます。このため，性能を重視したシステムでは，インプロセスHTTPサーバを使用することを推奨します。

ただし，Hitachi Web ServerおよびMicrosoft IISと比べて提供機能に差異があるため，機能差異を確認した上で，インプロセスHTTPサーバを使用するかどうか検討してください。また，インプロセスHTTPサーバとWebサーバ連携機能を同時に使用することはできません。システム設計時に，あらかじめどちらの機能を使用するか選択しておく必要があります。選択の指針については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」を参照してください。

なお，インプロセスHTTPサーバを使用する場合，次のことが前提となります。

インプロセスHTTPサーバは不正アクセスが想定される外部ネットワークからのアクセスが可能なDMZに配置しないで，ファイアウォール内の内部ネットワークに配置する必要があります。インターネットなどの外部ネットワークからアクセスされるシステムでは，DMZにプロキシサーバを配置して，内部ネットワークのインプロセスHTTPサーバに転送するようにシステムを構築する必要があります。インプロセスHTTPサーバを使用する場合のシステム構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」を参照してください。

インプロセスHTTPサーバでは，HTTPだけがサポートされています。HTTPSはサポートされていません。HTTPSを使用する場合，SSLアクセラレータ，またはHitachi Web Serverのリバースプロキシを使用することが前提となります。

インプロセスHTTPサーバを使用してアクセスできるのは，J2EEサーバ上にデプロイされたWebアプリケーションだけです。なお，静的コンテンツだけをデプロイすることはできませんが，リダイレクトによるリクエストの振り分け，およびエラーページのカスタマイズを実行する場合だけ，Webアプリケーションに含まれない静的コンテンツを指定できます。

インプロセスHTTPサーバの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「4.2.3　実行環境での設定（J2EEサーバの設定）」を参照してください。

ポイント

インプロセスHTTPサーバは，デフォルトでは使用しない設定になっています。

4.2.2　インプロセスHTTPサーバで使用できる機能

インプロセスHTTPサーバで使用できる機能と参照先を次の表に示します。

表4-3　インプロセスHTTPサーバで使用できる機能と参照先

機能名 | 参照先
Webクライアントからの接続数の制御 | 4.3
Webクライアントからのリクエスト処理スレッド数の制御 | 4.4
リクエストの流量制御 | Webクライアントからの同時接続数の制御 | 4.5
同時実行スレッド数の制御※ | 4.6
リダイレクトによるリクエストの振り分け | 4.7
Webクライアントとの通信制御 | Persistent Connectionによる通信制御 | 4.8
インプロセスHTTPサーバで設定できる通信タイムアウト | 4.9
インプロセスHTTPサーバで利用するIPアドレス指定※ | 4.10
Webクライアントからのアクセス制御 | アクセスを許可するホストの制限 | 4.11
リクエストデータのサイズ制限 | 4.12
有効なHTTPメソッドの制限 | 4.13
Webクライアントへのレスポンスのカスタマイズ | HTTPレスポンスヘッダのカスタマイズ | 4.14
エラーページのカスタマイズ | 4.15
Webコンテナへのゲートウェイ情報の通知※ | 4.16
ログ・トレースの出力 | 4.17

注※

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。

4.2.3　実行環境での設定（J2EEサーバの設定）

ここでは，インプロセスHTTPサーバの設定手順について説明します。

J2EEサーバのプロセス内で提供されるWebサーバ機能を使用して，HTTPリクエストを受信するためには，インプロセスHTTPサーバ機能を使用する構成でシステムを構築する必要があります。インプロセスHTTPサーバ機能を使用するシステムの構成や構築手順については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」を参照してください。

設定手順を次に示します。

インプロセスHTTPサーバ機能の使用を有効にします。
インプロセスHTTPサーバの仕様の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.enabledパラメタで「true」を指定します。デフォルトでは「false」が指定されています。簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

Webクライアントからの接続数の制御とリクエスト処理スレッド数の制御を設定します。
サーバを稼働するホストの性能やクライアントからのアクセス状況に合わせてリクエスト処理スレッド数を調節することで，インプロセスHTTPサーバのパフォーマンスを向上できます。設定については，「4.3　Webクライアントからの接続数の制御」および「4.4　リクエスト処理スレッド数の制御」を参照してください。
設定時の留意点を次に示します。

サーバ起動直後から大量のリクエストを処理する必要がある場合は，サーバ起動時に作成するリクエスト処理スレッド数に大きな値を指定してください。

予備スレッドの最大数を大きくすると急なアクセス増加にも迅速に対応できますが，リソースを多く消費するため注意してください。

Webクライアントからのアクセス制御の設定をします。
クライアントからの接続や送信されるリクエストに対するセキュリティを強化することで，外部からの不正アクセスやサーバへの攻撃を防ぐことができます。設定については，「4.11　アクセスを許可するホストの制限によるアクセス制御」，「4.12　リクエストデータのサイズの制限によるアクセス制御」，および「4.13　有効なHTTPメソッドの制限によるアクセス制御」を参照してください。

必要に応じて，インプロセスHTTPサーバで使用できる各機能についても設定してください。
インプロセスHTTPサーバで使用できる機能については，「4.2.2　インプロセスHTTPサーバで使用できる機能」を参照してください。

4.3　Webクライアントからの接続数の制御

Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。リクエスト処理スレッド数の制御については，「4.4　リクエスト処理スレッド数の制御」を参照してください。

この節では，Webクライアントからの接続数の制御について説明します。

この節の構成を次の表に示します。

表4-4　この節の構成（Webクライアントからの接続数の制御）

分類 | タイトル | 参照先
解説 | Webクライアントからの接続数の制御の概要 | 4.3.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.3.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

インプロセスHTTPサーバでは，一度に接続できるWebクライアントの数を設定することで，インプロセスHTTPサーバで作成するリクエスト処理スレッド数を制御できます。また，処理を実行していないリクエスト処理スレッドを予備スレッドとして一定数プールしておくことで，リクエスト処理スレッドの追加・削除に掛かる処理を最小限に抑えられます。

＜この節の構成＞

4.3.1　Webクライアントからの接続数の制御の概要

4.3.2　実行環境での設定（J2EEサーバの設定）

4.3.1　Webクライアントからの接続数の制御の概要

インプロセスHTTPサーバでは，一度に接続するWebクライアントやプロキシサーバの数の最大値を設定して，リクエスト処理スレッド数を制御します。インプロセスHTTPサーバではWebクライアントからの接続数分のリクエスト処理スレッドを作成するため，Webクライアントからの接続数の最大値は，インプロセスHTTPサーバで作成するリクエスト処理スレッド数の上限となります。

なお，クライアントからの接続要求は，TCP/IPのListenキューに登録されて，リクエスト処理スレッドに渡されます。接続数の上限を超えたクライアントからの接続要求は，Listenキューに蓄えられます。Listenキューに蓄えられたクライアントからの接続要求が指定した最大値を超えた場合，クライアントはサーバへの接続に失敗します。

Webクライアントからの接続数の制御の概要を次の図に示します。

図4-1　Webクライアントからの接続数の制御の概要

4.3.2　実行環境での設定（J2EEサーバの設定）

Webクライアントからの接続数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのWebクライアントからの接続数の制御の定義について次の表に示します。

表4-5　簡易構築定義ファイルでのWebクライアントからの接続数の制御の定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.max_connections | Webクライアントやプロキシサーバとの接続数の最大値を指定します。インプロセスHTTPサーバでは，Webクライアントからの接続数分のリクエスト処理スレッドを作成するため，ここで指定した値がリクエスト処理スレッド数の上限になります。
webserver.connector.inprocess_http.backlog | Webクライアントからの接続数の上限を超えたHTTPリクエストは，Listenキューに蓄えられます。ここでは，Listenキューの登録数の最大値を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

4.4　リクエスト処理スレッド数の制御

Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。Webクライアントからの接続数の制御については，「4.3　Webクライアントからの接続数の制御」を参照してください。

この節では，リクエスト処理スレッド数の制御について説明します。この節の構成を次の表に示します。

表4-6　この節の構成（リクエスト処理スレッド数の制御）

分類 | タイトル | 参照先
解説 | リクエスト処理スレッド数の制御の概要 | 4.4.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.4.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.4.1　リクエスト処理スレッド数の制御の概要

4.4.2　実行環境での設定（J2EEサーバの設定）

4.4.1　リクエスト処理スレッド数の制御の概要

インプロセスHTTPサーバでは，起動時にリクエスト処理スレッドを作成したあと，リクエスト処理スレッドの状態，およびスレッド数を定期的に監視します。インプロセスHTTPサーバにリクエストが集中している場合は，リクエスト処理スレッドを追加して十分な予備スレッドをプールしておき，リクエストが少ない場合は余分にプールしている予備スレッドを削除します。

リクエスト処理スレッド数の制御は次のように実行します。

J2EEサーバ起動時に，指定した数分のリクエスト処理スレッドを作成します。

J2EEサーバの稼働中はリクエスト処理スレッド数を監視します。

監視のタイミングで，予備スレッド数が指定した最小値より少ない場合は，リクエスト処理スレッドを追加して予備スレッドとしてプールします。また，予備スレッド数が指定した最大値より多い場合は，余分な予備スレッドを削除します。
なお，J2EEサーバ起動時に作成したスレッド数を維持することもできます。起動時に作成したスレッド数を維持する場合，リクエスト処理スレッドと予備スレッドの総数が起動時に作成したスレッド数以下の場合，予備スレッド数が最大値を超えていても予備スレッドは削除されません。例えば，起動時に作成したスレッド数が8で，予備スレッド数の最大値が5の場合，リクエスト処理スレッドが2で，予備スレッド数が6のときは，予備スレッドは削除されません。

次に，リクエスト処理スレッド数の遷移について，例を使用して説明します。

遷移例1
次の内容が設定されていることとします。

Webクライアントからの最大接続数：15

Listenキューの登録数：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：5

予備スレッドの最大値：10

J2EEサーバ起動時に作成したスレッド数の維持：無効

リクエスト処理スレッド数の遷移例を次の図に示します。

図4-2　リクエスト処理スレッド数の遷移例

図中の項番1～7について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

4リクエストを受信した時点で，予備スレッドが4スレッドとなり，最小値より少ないため1スレッド追加します。

4リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値より少なく，最小値より多いため現状を維持します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，Webクライアントからの最大接続数に達しているため，予備スレッドを1スレッドだけ追加します。

13リクエストの処理が終了した時点で，予備スレッド数が最大値を超えているため，4スレッド削除します。

7リクエストを受信した時点で，予備スレッド数が最小値より少ないため，2スレッド追加します。

8リクエストの処理が終了した時点で，予備スレッド数が最大値を超えているため，3スレッド削除します。

遷移例2
予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にすることによって，一度作成したリクエスト処理スレッドを削除しないで使い続けることができます。
予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例について説明します。
なお，ここでは，次の内容が設定されていることとします。

Webクライアントからの接続数の最大値：15

Listenキューの登録数の最大値：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：5

予備スレッドの最大値：15

J2EEサーバ起動時に作成したスレッド数の維持：無効

予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例を次の図に示します。

図4-3　予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例

図中の項番1～7について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

4リクエストを受信した時点で，予備スレッドが4スレッドとなり，最小値より少ないため1スレッド追加します。

4リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値より少なく，最小値より多いため現状を維持します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，リクエスト処理スレッドの総数がWebクライアントからの接続数の最大値を超えないように，予備スレッドを1スレッドだけ追加します。

13リクエストの処理が終了した時点で，予備スレッドが14スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

7リクエストを受信した時点で，予備スレッドが7スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

8リクエストの処理が終了した時点で，予備スレッド数が15スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

設定例3
サーバ起動時に作成されたスレッド数を維持する場合のリクエスト処理スレッド数の遷移例について説明します。
なお，ここでは，次の内容が設定されていることとします。

Webクライアントからの接続数の最大値：15

Listenキューの登録数の最大値：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：3

予備スレッドの最大値：5

J2EEサーバ起動時に作成したスレッド数の維持：有効

サーバ起動時に作成されたスレッド数を維持する場合のリクエスト処理スレッド数の遷移例を次の図に示します。

図4-4　J2EEサーバ起動時に作成したスレッドを維持する場合のリクエスト処理スレッド数の遷移例

図中の項番1～8について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

6リクエストを受信した時点で，予備スレッドが2スレッドとなり，最小値より少ないため1スレッド追加します。

6リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値を超えていますが，サーバ起動時に作成したスレッド数を維持するため，1スレッドだけ削除します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，リクエスト処理スレッドの総数がWebクライアントからの接続数の最大値を超えないように，予備スレッドを1スレッドだけ追加します。

7リクエストの処理が終了した時点で，予備スレッドが8スレッドとなり，最大値を超えたため，3スレッド削除します。

3リクエストを受信した時点で，予備スレッドが2スレッドとなり，最小値より少ないため，1スレッド追加します。

1リクエストの処理が終了した時点で，予備スレッド数が4スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

9リクエストの処理が終了した時点で，予備スレッド数が13スレッドとなり，最大値より多くなっていますが，J2EEサーバ起動時のスレッド数を維持するため，5スレッドだけ削除します。

4.4.2　実行環境での設定（J2EEサーバの設定）

リクエスト処理スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエスト処理スレッド数の制御の定義について次の表に示します。

表4-7　簡易構築定義ファイルでのリクエスト処理スレッド数の制御の定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.init_threads | J2EEサーバ起動時に作成するリクエスト処理スレッド数を指定します。
webserver.connector.inprocess_http.min_spare_threads | 予備スレッドの最小値を指定します。予備スレッド数が指定した最小値より少ない場合は，リクエスト処理スレッドが追加されて予備スレッドとしてプールされます。
webserver.connector.inprocess_http.max_spare_threads | 予備スレッドの最大値を指定します。予備スレッド数が指定した最大値より多い場合は，余分な予備スレッドが削除されます。予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にすることによって，一度作成したリクエスト処理スレッドを削除しないで使い続けることができます。
webserver.connector.inprocess_http.keep_start_threads | J2EEサーバ起動時に作成したリクエスト処理スレッドを維持するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

4.5　Webクライアントからの同時接続数の制御によるリクエストの流量制御

この節では，Webクライアントからの同時接続数の制御によるリクエストの流量制御について説明します。

この節の構成を次の表に示します。

表4-8　この節の構成（Webクライアントからの同時接続数の制御によるリクエストの流量制御）

分類 | タイトル | 参照先
解説 | Webクライアントからの同時接続数の制御 | 4.5.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.5.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.5.1　Webクライアントからの同時接続数の制御

4.5.2　実行環境での設定（J2EEサーバの設定）

4.5.1　Webクライアントからの同時接続数の制御

インプロセスHTTPサーバでは，Webクライアントからの最大接続数の設定とあわせて，接続を拒否するリクエスト数を設定することによって，Webクライアントからの同時接続数を制御します。

Webクライアントからの接続数の増加や，J2EEアプリケーションなどの影響でJ2EEサーバの負荷が高くなった場合に，Webクライアントからのリクエストの受け付けを拒否して，即座にエラーを返すことで，Webクライアントは即座にレスポンスを受信できます。これによって，J2EEサーバの負荷を一定に抑え，リクエストに対するレスポンスタイムを維持できます。

Webクライアントからの最大接続数から接続を拒否するリクエスト数を引いた値が，Webクライアントからの接続を承諾する数となります。

Webクライアントからの同時接続数の制御の概要を，次の図に示します。

図4-5　Webクライアントからの同時接続数の制御の概要

例えば，Webクライアントからの最大接続数を40として，接続を拒否するリクエスト数を1とする場合，インプロセスHTTPサーバに接続し同時にリクエストを処理できるWebクライアントの数は39となります。リクエスト処理中のスレッド数が39になると，残りの1スレッドは処理中のリクエスト処理スレッド数が減るまで受信したリクエストに対してエラーを返し続けます。Webクライアントからの同時接続数の制御の例を次の図に示します。

図4-6　Webクライアントからの同時接続数の制御の例

Webクライアントからの同時接続数の制御によって，接続を拒否したリクエストに対しては，ステータスコード503のエラーをWebクライアントに返します。このときクライアントに返すエラーページをカスタマイズすると，レスポンスメッセージのカスタマイズや，ほかのサーバへのリダイレクトができます。

Webクライアントへのレスポンスのカスタマイズ（インプロセスHTTPサーバの場合）の設定については，「4.14　HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ」，および「4.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）」を参照してください。

注意

フレームを使用したページや，画像を挿入したページを表示する際，Webクライアントから複数のリクエストを受信する場合があります。その場合，Webクライアントからの同時接続数の制御によって表示されるページが部分的にエラーになることがあります。

4.5.2　実行環境での設定（J2EEサーバの設定）

Webクライアントからの同時接続数の制御をする場合，J2EEサーバの設定が必要です。

Webクライアントからの同時接続数の制御の設定方法および設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

Webクライアントからの同時接続数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.rejection_threads

接続を拒否するリクエスト数を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

注意

フレームを使用したページや，画像を挿入したページを表示する際，Webクライアントから複数のリクエストを受信する場合があります。その場合，Webクライアントからの同時接続数の制御によって表示されるページが部分的にエラーになることがあります。

(2)　設定例

Webクライアントからの同時接続数の制御の設定例について説明します。

次に，リクエスト処理スレッド数の上限が40，接続を拒否するリクエスト処理スレッド数が1の場合の設定例を示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.max_connections</param-name>
 <param-value>40</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.rejection_threads</param-name>
 <param-value>1</param-value>
</param>
：

この設定例では，接続後に同時にリクエストを処理できるWebクライアントの数は39となります。リクエスト処理中のスレッド数が39に達すると，残りの1スレッドはWebクライアントに対してエラーを返し続けます。

Webクライアントからの同時接続数の制御によって，接続を拒否したリクエストに対しては，ステータスコード503（Service Unavailable）のエラーをWebクライアントに返します。このときクライアントに返すエラーページをカスタマイズすると，レスポンスメッセージのカスタマイズや，ほかのサーバへのリダイレクトができます。それぞれの場合の設定例を次に示します。なお，エラーページのカスタマイズについては，「4.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）」を参照してください。

レスポンスメッセージをカスタマイズする場合
Webクライアントからの接続を拒否した場合に，レスポンスボディとして特定のファイルをWebクライアントに返すための設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.rejection_threads</param-name>
 <param-value>3</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.list</param-name>
 <param-value>REJECTION_1</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.status</param-name>
 <param-value>503</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.file</param-name>
 <param-value>C:/data/busy.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.file.content_type=text/html; charset</param-name>
 <param-value>ISO-8859-1</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.request_url</param-name>
 <param-value>/*</param-value>
</param>
：

この設定例では，エラーステータスコードに「503」，対応するエラーページのファイルに「C:/data/busy.html」，レスポンスのContent-Typeヘッダに「text/html; charset=ISO-8859-1（Media-Typeはtext/htmlで，ISO-8859-1文字セットを使用）」，URLパターンに「/*」を指定しています。このため，エラーステータスコード「503」が発生した場合には，リクエストのURIに関係なく，「C:/data/busy.html」のファイルの内容をレスポンスとして返します。

ほかのサーバへリダイレクトする場合
接続を拒否したリクエストをほかのサーバへリダイレクトする場合の設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.rejection_threads</param-name>
 <param-value>3</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.list</param-name>
 <param-value>REJECTION_1</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.status</param-name>
 <param-value>503</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.redirect_url</param-name>
 <param-value>http://host1/busy.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.request_url</param-name>
 <param-value>/*</param-value>
</param>
<param>
：

この設定例では，エラーステータスコードに「503」，対応するエラーページのファイルに「http://host1/busy.html」，URLパターンに「/*」を指定しています。このため，エラーステータスコード「503」が発生した場合には，リクエストのURIに関係なく，すべてのリクエストが「http://host1/busy.html」のURLにリダイレクトされます。

4.6　同時実行スレッド数の制御によるリクエストの流量制御

この節では，同時実行スレッド数の制御によるリクエストの流量制御について説明します。

この節の構成を次の表に示します。

表4-9　この節の構成（同時実行スレッド数の制御によるリクエストの流量制御）

分類 | タイトル | 参照先
解説 | 同時実行スレッド数の制御によるリクエストの流量制御の概要 | 4.6.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.6.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

参考

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。機能の解説については，「2.15　同時実行スレッド数の制御の概要」を参照してください。

＜この節の構成＞

4.6.1　同時実行スレッド数の制御によるリクエストの流量制御の概要

4.6.2　実行環境での設定（J2EEサーバの設定）

4.6.1　同時実行スレッド数の制御によるリクエストの流量制御の概要

Webコンテナでは，マルチスレッドでサーブレットのリクエストを処理します。このとき，同時に実行できるスレッド数に上限を設定することで，スラッシングなどによるパフォーマンスの低下を防止できます。また，適切なスレッド数を設定することで，アクセス状況に従ったパフォーマンスのチューニングができます。

4.6.2　実行環境での設定（J2EEサーバの設定）

Webコンテナでの同時実行スレッド数の制御をする場合，J2EEサーバの設定が必要です。

ここでは，Webコンテナでの同時実行スレッド数の制御の設定について説明します。

同時に実行するスレッド数を制御するには，Webコンテナ単位で制御する方法，Webアプリケーション単位で制御する方法，およびURLグループ単位で制御する方法の3種類あります。

＜この項の構成＞

(1)　Webコンテナ単位での制御

(2)　Webアプリケーション単位での制御

(3)　URLグループ単位での制御

(1)　Webコンテナ単位での制御

Webコンテナ単位で同時実行スレッド数を制御する場合，Webコンテナ全体で同時に実行できるスレッドの最大数を設定します。ここで設定したスレッド数は，WebコンテナにデプロイされているすべてのWebアプリケーションで共用するスレッド数となります。

Webコンテナ単位での同時実行スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.max_execute_threads

Webコンテナ全体で同時に実行できるスレッドの最大数を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(2)　Webアプリケーション単位での制御

Webアプリケーション単位で同時実行スレッド数を制御する場合，Webコンテナでのスレッド数制御も同時に設定する必要があります。

Webアプリケーション単位での同時実行スレッド数の制御は，簡易構築定義ファイルおよびサーバ管理コマンドで設定します。設定方法は，Webサーバ連携機能を使用する場合と同じです。Webサーバ連携機能を使用する場合の，Webアプリケーション単位での同時実行スレッド数の設定方法については，「2.17　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

(3)　URLグループ単位での制御

URLグループ単位で同時実行スレッド数を制御する場合，Webアプリケーション単位での同時実行スレッド数制御，およびWebコンテナでのスレッド数制御も同時に設定する必要があります。

URLグループ単位での同時実行スレッド数の制御は，サーバ管理コマンドで設定します。設定方法は，Webサーバ連携機能を使用する場合と同じです。Webサーバ連携機能を使用する場合の，URLグループ単位での同時実行スレッド数の設定方法については，「2.18　URLグループ単位での同時実行スレッド数の制御」を参照してください。

4.7　リダイレクトによるリクエストの振り分け

この節では，リダイレクトによるリクエストの振り分けについて説明します。

インプロセスHTTPサーバでは，HTTPリクエストに含まれるURLパターンによってリクエストを振り分けます。また，振り分けたリクエストに対するレスポンスをカスタマイズしてクライアントに返すこともできます。

URLパターンによるリクエストの振り分けと，レスポンスのカスタマイズの処理について説明します。また，リダイレクトによるリクエストの振り分けの設定の概要についても説明します。

この節の構成を次の表に示します。

表4-10　この節の構成（リダイレクトによるリクエストの振り分け）

分類 | タイトル | 参照先
解説 | URLパターンによるリクエストの振り分け | 4.7.1
レスポンスのカスタマイズ | 4.7.2
設定 | 実行環境での設定（J2EEサーバの設定） | 4.7.3
注意事項 | リダイレクトによるリクエストの振り分けに関する注意事項 | 4.7.4

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

4.7.1　URLパターンによるリクエストの振り分け

4.7.2　レスポンスのカスタマイズ

4.7.3　実行環境での設定（J2EEサーバの設定）

4.7.4　リダイレクトによるリクエストの振り分けに関する注意事項

4.7.1　URLパターンによるリクエストの振り分け

インプロセスHTTPサーバでは，インプロセスHTTPサーバあてのHTTPリクエストのうち，特定のURLへのリクエストを，指定したWebコンテナに振り分けて処理させることができます。これによって，システム構成の変更などの理由でWebアプリケーションを別なJ2EEサーバに移動する場合に，変更前のURLへのリクエストを，変更後のURLに転送できます。

また，インプロセスHTTPサーバでのリダイレクトによる振り分けでは，特定のWebアプリケーション，およびWebアプリケーション内の特定のサーブレット/JSPに対するリクエストを，一時的にほかのWebサーバにリダイレクトする場合にも使用できます。インプロセスHTTPサーバでは，リクエストされたサーブレット/JSPなどのリソースが実際にあるかどうかに関係なく，リダイレクトを実行します。リダイレクトは，サーブレット/JSPよりも優先されます。そのため，サーブレット/JSPへのリクエストがリダイレクトされるURLと一致した場合，サーブレット/JSPは実行されません。

4.7.2　レスポンスのカスタマイズ

特定のURLへのリクエストに対して，特定のファイルをレスポンスとして返すようにカスタマイズすることもできます。リダイレクトするURLへのリクエストに対するレスポンスのステータスコードが300～307の場合，レスポンスボディを自動生成してクライアントにレスポンスを返します。また，指定したファイルをレスポンスボディとして使用することもできます。ファイルを指定する場合，レスポンスのContent-Typeヘッダもあわせて指定します。

レスポンスボディが自動生成されるステータスコードの詳細，およびリダイレクトによるリクエストの振り分けの設定（インプロセスHTTPサーバの場合）については，「4.7.3　実行環境での設定（J2EEサーバの設定）」を参照してください。

4.7.3　実行環境での設定（J2EEサーバの設定）

ここでは，リダイレクトによるリクエストの振り分けの設定について説明します。

＜この項の構成＞

(1)　概要

(2)　設定方法

(3)　設定例

(1)　概要

インプロセスHTTPサーバでは，HTTPリクエストに含まれるURLパターンによってリクエストを振り分けることができます。また，振り分けたリクエストに対するレスポンスをカスタマイズして特定のファイルをクライアントに返すこともできます。リダイレクトするURLへのリクエストに対するレスポンスのステータスコードが300番台の場合，レスポンスボディを自動生成してクライアントにレスポンスを返します。また，指定したファイルをレスポンスボディとして使用することもできます。ファイルを指定する場合，レスポンスのContent-Typeヘッダもあわせて指定します。

自動生成されるレスポンスボディを次に示します。

<HTML><HEAD>
<TITLE>ステータスコードおよび説明句</TITLE>
</HEAD><BODY>
<H1>ステータスコードおよび説明句</H1>
</BODY></HTML>

レスポンスボディが自動生成されるステータスコードおよび説明句を次に示します。

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

305 Use Proxy

307 Temporary Redirect

リクエスト処理時にレスポンスボディとして使用するファイルの読み込みに失敗した場合，ステータスコードに300番台が指定されていれば，レスポンスボディを自動生成してクライアントに返します。ステータスコードに200が指定されていれば，ステータス500エラーをクライアントに返します。

(2)　設定方法

リダイレクトによるリクエストの振り分けの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリダイレクトによるリクエストの振り分けの定義について次の表に示します。

表4-11　簡易構築定義ファイルでのリダイレクトによるリクエストの振り分けの定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.redirect.list | リダイレクト定義名を指定します。
webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.request_url | リダイレクトするリクエストのURLを「/」（スラント）で始まる絶対パスで指定します。
webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.redirect_url | リクエストのリダイレクト先のURLを指定します。なお，ステータスコードに200を指定した場合は，URLを指定できません。
webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.status | リダイレクトを実行する場合のレスポンスのステータスコードを指定します。
webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.file | 特定のファイルをレスポンスとしてクライアントに返す場合にレスポンスボディとして使用するファイルを指定します。なお，ステータスコードに200を指定した場合は，使用するファイルを指定する必要があります。
webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.file.content_type | 特定のファイルをレスポンスとしてクライアントに返す場合にレスポンスボディとして使用するファイルのContent-Typeヘッダを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

注意

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，正しくブラウザに表示されないことがあります。

リダイレクトURLの指定値がリクエストURLの指定値と一致する場合，クライアントによってはリダイレクトを実行し続けることがあります。

URLの書き換えによるセッション管理をしている場合，リクエストURLと同じWebアプリケーション内へのリダイレクトを実行してもセッションを引き継ぐことはできません。

(3)　設定例

リダイレクトによるリクエストの振り分けの設定例について説明します。

設定例1
リダイレクトによるリクエストの振り分けの設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.redirect.list</param-name>
 <param-value>REDIRECT_1,REDIRECT_2</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_1.request_url</param-name>
 <param-value>/index.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_1.redirect_url</param-name>
 <param-value>http://host1/new_dir/index.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_1.status</param-name>
 <param-value>302</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.request_url</param-name>
 <param-value>/old_dir/*</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.redirect_url</param-name>
 <param-value>http://host1/new_dir/</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.status</param-name>
 <param-value>301</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.file</param-name>
 <param-value>C:/data/301.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.file.content_type</param-name>
 <param-value>text/html; charset=ISO-8859-1</param-value>
</param>
：

この設定例では，リダイレクト定義名として，「REDIRECT_1」と「REDIRECT_2」を使用しています。「REDIRECT_1」では，「/index.html」へのリクエストを「http://host1/new_dir/index.html」にステータスコード「302」でリダイレクトします。「REDIRECT_2」では，「/old_dir/」以下へのリクエストを「http://host1/new_dir/」以下にステータス「301」でリダイレクトします。また，レスポンスボディとして「C:/data/301.html」を使用し，Content-Typeヘッダとして「text/html; charset=ISO-8859-1」を使用します。

設定例2
リクエストURLとしてワイルドカードを使用し，リダイレクトURLに「/」で終わる値を指定した場合，レスポンスのLocationヘッダに設定される値は，「リダイレクトURLに指定した値」＋「実際のリクエストURLのワイルドカード以降のパス」になります。

：
<param>
 <param-name>webserver.connector.inprocess_http.redirect.list</param-name>
 <param-value>REDIRECT_3</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_3.request_url</param-name>
 <param-value>/dir1/*</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_3.redirect_url</param-name>
 <param-value>http://host/dir2/</param-value>
</param>
：

この設定例の場合，実際のリクエストURLが「/dir1/subdir1/index.html」のときには，Locationヘッダには「http://host/dir2/subdir1/index.html」が設定されます。なお，リクエストURLの指定でワイルドカードを使用した場合でも，リダイレクトURLが「/」で終わらないときは，Locationヘッダの値は，リダイレクトURLと同じ値になります。
リダイレクトが行われる際，実際のリクエストURLにクエリ文字列が付加されていた場合，Locationヘッダに設定される値は，リダイレクトURLの指定値にクエリ文字列を付加した値となります。また，リダイレクトURLにはクエリ文字列の付いた値を指定できます。この場合，実際のリクエストURLにもクエリ文字列が付いているときは，Locationヘッダに設定される値は，リダイレクトURLの指定値の後ろにリクエストのクエリ文字列が付加された値となります。

4.7.4　リダイレクトによるリクエストの振り分けに関する注意事項

リダイレクトによるリクエストの振り分けに関する注意事項を次に示します。

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，正しくブラウザに表示されない場合があります。

リダイレクトURLの指定値とリクエストURLの指定値が一致すると，クライアントによってはリダイレクトを実行し続けることがあるため注意してください。

URLの書き換えによるセッション管理をしている場合，Webアプリケーション内へのリダイレクトを実行してもセッションを引き継ぐことはできません。

4.8　Persistent ConnectionによるWebクライアントとの通信制御

この節では，Persistent ConnectionによるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表4-12　この節の構成（Persistent ConnectionによるWebクライアントとの通信制御）

分類 | タイトル | 参照先
解説 | Persistent Connectionによる通信制御 | 4.8.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.8.2

注　「実装」および「運用」について，この機能固有の説明はありません。

＜この節の構成＞

4.8.1　Persistent Connectionによる通信制御

4.8.2　実行環境での設定（J2EEサーバの設定）

4.8.1　Persistent Connectionによる通信制御

Persistent Connectionは，WebクライアントとインプロセスHTTPサーバ間で確立したTCPコネクションを持続して，複数のHTTPリクエスト間で使用し続けるための機能です。Persistent Connectionを使用することによって，WebクライアントとWebサーバ間でのコネクション接続に掛かる時間を短縮し，処理時間の短縮と通信トラフィックの軽減を図れます。

インプロセスHTTPサーバでは，次に示す項目を設定することで，Persistent Connectionによる通信制御を実現します。

Persistent Connection数の上限値
Persistent Connection数の上限値を設定することで，一つのTCPコネクションで連続してリクエストを処理できるWebクライアント数を制御します。TCPコネクション数が指定した上限値を超えた場合，リクエスト処理終了後に切断します。これによって，新規リクエストを処理するスレッドが確保でき，リクエスト処理スレッドを特定のクライアントに占有されることを防げます。

Persistent Connectionのリクエスト処理回数の上限値
Persistent Connectionのリクエスト処理回数の最大値を設定することで，同じWebクライアントから連続してリクエスト要求があった場合の処理を制御します。
Persistent Connectionのリクエスト処理回数が指定した上限値を超えた場合，リクエスト処理終了後にコネクションを切断します。これによってリクエスト処理スレッドを特定のクライアントに占有し続けられることを防げます。

Persistent Connectionのタイムアウト
Persistent Connectionのリクエスト待ち時間にタイムアウトを設定することで，Persistent Connectionのリクエスト待ち時間を制御します。指定したタイムアウト時間を超えてリクエスト処理要求がない場合は，TCPコネクションを切断します。これによって，使用されていない状態でTCPコネクションが占有され続けることを防げます。また，Persistent Connectionのリクエスト待ち時間に0を指定してタイムアウトをしない設定にしている場合でも，リクエスト処理回数の上限値を超えたリクエスト要求があるとコネクションが切断されます。

なお，コネクションを切断されたWebクライアントは，接続のリトライを実行して，再度リクエストを送信します。

4.8.2　実行環境での設定（J2EEサーバの設定）

Persistent Connectionによる通信制御を使用する場合，J2EEサーバの設定が必要です。

ここでは，Persistent Connectionによる通信制御の設定および設定例について説明します。

＜この項の構成＞

(1)　J2EEサーバの設定

(2)　設定例

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Persistent Connectionによる通信制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのPersistent Connectionによる通信制御の定義について次の表に示します。

表4-13　簡易構築定義ファイルでのPersistent Connectionによる通信制御の定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.persistent_connection.max_connections | 一つのTCPコネクションで連続してリクエストを処理できるWebクライアント数を制御するため，Persistent Connection数の上限値を指定します。
webserver.connector.inprocess_http.persistent_connection.max_requests | 同じWebクライアントから連続してリクエスト要求があった場合の処理を制御するため，Persistent Connectionのリクエスト処理回数の上限値を指定します。
webserver.connector.inprocess_http.persistent_connection.timeout | Persistent Connectionのリクエスト待ち時間を制御するため，Persistent Connectionのタイムアウトを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(2)　設定例

Persistent Connectionによる通信制御の設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.persistent_connection.max_connections</param-name>
 <param-value>5</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.persistent_connection.max_requests</param-name>
 <param-value>100</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.persistent_connection.timeout</param-name>
 <param-value>15</param-value>
</param>
：

この設定例では，TCPコネクション数が「5」を超えた場合，またはリクエスト処理回数が「100」を超えた場合には，リクエスト処理終了後にTCPコネクションを切断します。また，タイムアウト時間「15」秒を過ぎてもリクエスト処理要求がない場合は，TCPコネクションを切断します。

4.9　通信タイムアウト（インプロセスHTTPサーバ）

この節では，インプロセスHTTPサーバでの通信タイムアウトによるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表4-14　この節の構成（通信タイムアウト（インプロセスHTTPサーバ））

分類 | タイトル | 参照先
解説 | 通信タイムアウトの概要 | 4.9.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.9.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.9.1　通信タイムアウトの概要

4.9.2　実行環境での設定（J2EEサーバの設定）

4.9.1　通信タイムアウトの概要

インプロセスHTTPサーバを使用する場合，WebクライアントとインプロセスHTTPサーバ間での，リクエスト受信およびレスポンス送信に，通信タイムアウトを設定できます。ネットワークの障害やアプリケーションの障害などが発生し応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

インプロセスHTTPサーバを使用する場合，次に示す図中の二つの矢印が示す通信に対してタイムアウトを設定します。

図4-7　タイムアウトを設定できる通信（インプロセスHTTPサーバを使用する場合）

図に示すように，通信タイムアウトはリクエスト受信とレスポンス送信に対して設定します。通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

なお，Webクライアントからのリクエスト受信，およびWebクライアントへのレスポンス送信でタイムアウトが発生した場合，Webクライアントまたはネットワークで障害が発生したと見なされて，Webクライアントとの接続が切断されるため，レスポンスは返されません。

＜この項の構成＞

(1)　リクエスト受信時の通信タイムアウト

(2)　レスポンス送信時の通信タイムアウト

(1)　リクエスト受信時の通信タイムアウト

リクエスト受信時の通信タイムアウトの設定場所を次の図に示します。

図4-8　リクエスト受信時の通信タイムアウトの設定場所（インプロセスHTTPサーバを使用する場合）

インプロセスHTTPサーバを使用する場合，WebクライアントとインプロセスHTTPサーバ間の通信に，タイムアウトを設定します。

WebクライアントとインプロセスHTTPサーバ間の通信にタイムアウトを設定することによって，クライアント側で次に示す障害が発生したことを検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとインプロセスHTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

(2)　レスポンス送信時の通信タイムアウト

レスポンス送信時の通信タイムアウトの設定場所を次の図に示します。

図4-9　レスポンス送信時の通信タイムアウトの設定場所（インプロセスHTTPサーバを使用する場合）

インプロセスHTTPサーバを使用する場合，インプロセスHTTPサーバとWebクライアント間の通信に，タイムアウトを設定します。

インプロセスHTTPサーバとWebクライアント間の通信にタイムアウトを設定することによって，次に示す障害を検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとインプロセスHTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

4.9.2　実行環境での設定（J2EEサーバの設定）

インプロセスHTTPサーバの通信タイムアウトの設定をする場合，J2EEサーバの設定が必要です。

ここでは，インプロセスHTTPサーバの通信タイムアウトの設定および設定例について説明します。

通信タイムアウトは，リクエストの受信時，またはレスポンスの送信時に設定します。リクエスト受信時およびレスポンス送信時の通信タイムアウトの設定についてそれぞれ説明します。

＜この項の構成＞

(1)　リクエスト受信時の通信タイムアウトの設定

(2)　レスポンス送信時の通信タイムアウトの設定

(3)　設定例

(1)　リクエスト受信時の通信タイムアウトの設定

リクエスト受信時の通信タイムアウトは，クライアント－インプロセスHTTPサーバ間に設定します。

インプロセスHTTPサーバでのリクエスト受信時の通信タイムアウトは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.receive_timeout

クライアントからのリクエスト受信処理の待ち時間を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(2)　レスポンス送信時の通信タイムアウトの設定

レスポンス送信時の通信タイムアウトは，インプロセスHTTPサーバ－クライアント間に設定します。

インプロセスHTTPサーバでのレスポンス送信時の通信タイムアウトは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.send_timeout

クライアントへのレスポンス送信処理の待ち時間を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(3)　設定例

インプロセスHTTPサーバの通信タイムアウトの設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.receive_timeout</param-name>
 <param-value>300</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.send_timeout</param-name>
 <param-value>600</param-value>
</param>
：

この設定例では，リクエスト受信のタイムアウトに「300」秒，リクエスト送信のタイムアウトに「600」秒を設定しています。

4.10　IPアドレス指定（インプロセスHTTPサーバ）

この節では，インプロセスHTTPサーバでのIPアドレス指定によるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表4-15　この節の構成（IPアドレス指定（インプロセスHTTPサーバ））

分類 | タイトル | 参照先
解説 | バインド先アドレス設定機能 | 4.10.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.10.2
注意事項 | インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項 | 4.10.3

注　「実装」および「運用」について，この機能固有の説明はありません。

参考

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。機能の解説については，「3.7　IPアドレス指定（Webサーバ連携）」を参照してください。

＜この節の構成＞

4.10.1　バインド先アドレス設定機能

4.10.2　実行環境での設定（J2EEサーバの設定）

4.10.3　インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項

4.10.1　バインド先アドレス設定機能

Webコンテナでは，インプロセスHTTPサーバで利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数の物理ネットワークインタフェースを持つホスト，または一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するように設定できます。

4.10.2　実行環境での設定（J2EEサーバの設定）

インプロセスHTTPサーバのIPアドレスの設定をする場合，J2EEサーバの設定が必要です。

ここでは，インプロセスHTTPサーバのIPアドレスの設定について説明します。

インプロセスHTTPサーバのIPアドレスは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.bind_host

インプロセスHTTPサーバで利用するホスト名またはIPアドレスを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

4.10.3　インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項

インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項を次に示します。

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。デフォルトでは，ワイルドカードアドレスを使用する設定になっています。なお，ワイルドカードアドレスを使用する場合は，次のことに注意してください。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

4.11　アクセスを許可するホストの制限によるアクセス制御

J2EEサーバへの不正アクセスを防ぐため，アクセスできるホストを制限できます。デフォルトでは，全ホストからのアクセスが可能な状態になっています。アクセスを許可するホストのホスト名やIPアドレスを設定しておくことで，特定のホストからのアクセスだけを許可して，不正アクセスを防止できます。

この節では，アクセスを許可するホストの制限によるアクセス制御について説明します。

表4-16　この節の構成（アクセスを許可するホストの制限によるアクセス制御）

分類 | タイトル | 参照先
解説 | アクセスを許可するホストの制限 | 4.11.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.11.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.11.1　アクセスを許可するホストの制限

4.11.2　実行環境での設定（J2EEサーバの設定）

4.11.1　アクセスを許可するホストの制限

ホストを制限するには，アクセスを許可するホストの，ホスト名，またはIPアドレスを設定します。このとき，ホスト名やIPアドレスの代わりにアスタリスク（*）を指定すると，全ホストからのアクセスを許可する設定になります。アクセスを許可するホストをホスト名で指定した場合，J2EEサーバ起動時にホスト名が解決されます。なお，ローカルホストは明記しなくても常にアクセスが許可されます。通常，外部ネットワークからアクセスされるシステムでは，プロキシサーバのIPアドレスを指定します。

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

注意事項

hostsファイル，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定でサーバが起動されます。

ホスト名の解決をJ2EEサーバの起動時にするため，サーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

4.11.2　実行環境での設定（J2EEサーバの設定）

アクセスを許可するホストの制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，アクセスを許可するホストの制限の設定方法と設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

アクセスを許可するホストの制限は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.permitted.hosts

アクセスを許可するホストのホスト名やIPアドレスを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注意

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

hosts，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定（全ホストからのアクセスが可能な状態）でJ2EEサーバが起動されます。

J2EEサーバの起動時にホスト名を解決するため，J2EEサーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

(2)　設定例

アクセスを許可するホストの制限の設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.permitted.hosts</param-name>
 <param-value>host1,host2</param-value>
</param>
：

この設定例では，「host1」と「host2」からのアクセスだけを許可し，ほかのホストからのアクセスを許可しません。

4.12　リクエストデータのサイズの制限によるアクセス制御

インプロセスHTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

この節では，リクエストデータのサイズの制限によるアクセス制御について説明します。

この節の構成を次の表に示します。

表4-17　この節の構成（リクエストデータのサイズの制限によるアクセス制御）

分類 | タイトル | 参照先
解説 | リクエストデータのサイズの制限 | 4.12.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.12.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.12.1　リクエストデータのサイズの制限

4.12.2　実行環境での設定（J2EEサーバの設定）

4.12.1　リクエストデータのサイズの制限

インプロセスHTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

次に示す項目を設定することで，リクエストデータのサイズ制限によるアクセス制御を実現します。

リクエストラインの長さの制限
リクエストラインの長さの上限値を設定することで，アクセスを制御します。リクエストラインの長さには，HTTPメソッド，URI（クエリ文字列を含む），HTTPのバージョン，およびリクエストラインの終わりを示す改行文字（2バイト）が含まれます。
受信したリクエストラインの長さが上限値を超えた場合，Webクライアントに対して，ステータスコード414のエラーを返します。

HTTPヘッダ数の制限
HTTPリクエストに含まれるHTTPヘッダ数の上限値を設定することで，アクセスを制御します。
受信したHTTPリクエストに含まれるHTTPヘッダ数が上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストヘッダサイズの制限
HTTPリクエストのリクエストヘッダのサイズに上限値を設定することによって，アクセスを制御します。
受信したHTTPリクエストのHTTPヘッダのサイズが上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストボディサイズの制限
HTTPリクエストのボディサイズに上限値を設定することによって，アクセスを制御します。インプロセスHTTPサーバでは，リクエストヘッダに含まれるContent-Lengthヘッダの値で判断します。
HTTPリクエストのボディサイズが上限値を超えた場合，Webクライアントに対してステータスコード413のエラーを返します。
なお，チャンク形式でリクエストボディが送信された場合，サーブレット内部では指定された上限値までのデータを読み込みます。上限値を超えるとサーブレットで例外（IOException）が発生しますが，サーブレットの処理は続行されます。リクエストを送信したクライアントには，指定された上限値までのデータを読み込んだ結果に基づいて，アプリケーションが作成したレスポンスを返します。

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，プロキシサーバを配置していて，ゲートウェイ機器やプロキシサーバにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

4.12.2　実行環境での設定（J2EEサーバの設定）

リクエストデータのサイズ制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，リクエストデータのサイズ制限の設定方法と設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。リクエストデータのサイズ制限の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエストデータのサイズ制限の定義について次の表に示します。

表4-18　簡易構築定義ファイルでのリクエストデータのサイズ制限の定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.limit.max_request_line | リクエストラインの上限値を指定します。
webserver.connector.inprocess_http.limit.max_headers | HTTPリクエストに含まれるHTTPヘッダ数の上限値を指定します。
webserver.connector.inprocess_http.limit.max_request_header | HTTPリクエストのリクエストヘッダのサイズの上限値を指定します。
webserver.connector.inprocess_http.limit.max_request_body | HTTPリクエストのボディサイズの上限値を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，プロキシサーバを配置していて，ゲートウェイ機器やプロキシサーバにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

(2)　設定例

リクエストデータのサイズ制限の設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.limit.max_request_line</param-name>
 <param-value>1024</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.limit.max_headers</param-name>
 <param-value>100</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.limit.max_request_header</param-name>
 <param-value>8192</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.limit.max_request_body</param-name>
 <param-value>16384</param-value>
</param>
：

4.13　有効なHTTPメソッドの制限によるアクセス制御

この節では，有効なHTTPメソッドの制限によるアクセス制御について説明します。

この節の構成を次の表に示します。

表4-19　この節の構成（有効なHTTPメソッドの制限によるアクセス制御）

分類 | タイトル | 参照先
解説 | 有効なHTTPメソッドの制限 | 4.13.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.13.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.13.1　有効なHTTPメソッドの制限

4.13.2　実行環境での設定（J2EEサーバの設定）

4.13.1　有効なHTTPメソッドの制限

インプロセスHTTPサーバでは，HTTPリクエストで有効なHTTPメソッドを制限することによって，無効なHTTPメソッドを含むリクエストの受け付けを拒否します。これによって，サーバ上のリソースへの不正アクセスを防止できます。デフォルトでは，DELETEメソッド，HEADメソッド，GETメソッド，OPTIONSメソッド，POSTメソッド，およびPUTメソッドの使用を許可しています。

HTTPメソッドを制限するには，有効なHTTPメソッドのメソッド名を設定します。有効なHTTPメソッドとして設定する値は，RFC2616に規定されている値を使用する必要があります。ただし，メソッド名の文字列にアスタリスク（*）は使用できません。メソッド名の代わりにアスタリスク（*）を指定すると，すべてのメソッドの使用を許可する設定になります。

無効なHTTPメソッドを含むリクエストを受信した場合，Webクライアントに対してステータスコード405のエラーを返します。

なお，静的コンテンツに対してOPTIONSメソッドを含むリクエストを送信した場合，レスポンスに含まれるAllowヘッダには静的コンテンツに対してデフォルトで有効なメソッド（GETメソッド，POSTメソッド，TRACEメソッド，およびOPTIONSメソッド）から，インプロセスHTTPサーバで無効なメソッドを除いたメソッドが返されます。サーブレット/JSPの場合，Webアプリケーションの実装に依存します。

4.13.2　実行環境での設定（J2EEサーバの設定）

有効なHTTPメソッドの制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，有効なHTTPメソッドの制限の設定方法と設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

有効なHTTPメソッドの制限は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.enabled_methods

有効なHTTPメソッドのメソッド名を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

ポイント

静的コンテンツに対してOPTIONSメソッドを含むリクエストを送信した場合，静的コンテンツに対してデフォルトで有効なメソッド（GETメソッド，POSTメソッド，TRACEメソッド，およびOPTIONSメソッド）から，インプロセスHTTPサーバで無効なメソッドを除いたリクエストが返されます。サーブレット/JSPの場合，Webアプリケーションの実装に依存します。

(2)　設定例

有効なHTTPメソッドの制限の設定例を次に示します。なお，この設定例はデフォルトの設定です。

：
<param>
 <param-name>webserver.connector.inprocess_http.enabled_methods</param-name>
 <param-value>GET,HEAD,POST,PUT,DELETE,OPTIONS</param-value>
</param>
：

この設定例では，GETメソッド，HEADメソッド，POSTメソッド，PUTメソッド，DELETEメソッド，およびOPTIONSメソッドに対してアクセスを許可し，TRACEメソッドに対してアクセスを拒否します。

4.14　HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

この節では，HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズについて説明します。

この節の構成を次の表に示します。

表4-20　この節の構成（HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ）

分類 | タイトル | 参照先
解説 | HTTPレスポンスヘッダのカスタマイズ | 4.14.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.14.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.14.1　HTTPレスポンスヘッダのカスタマイズ

4.14.2　実行環境での設定（J2EEサーバの設定）

4.14.1　HTTPレスポンスヘッダのカスタマイズ

ここでは，HTTPレスポンスヘッダのカスタマイズについて説明します。

インプロセスHTTPサーバでは，HTTPレスポンスのServerヘッダに自動設定する情報をカスタマイズできます。デフォルトでは，「CosminexusComponentContainer」が自動設定されます。

Serverヘッダに自動設定する値は，RFC2616に規定されている値を使用する必要があります。サーブレット/JSPでServerヘッダを使用する設定にしている場合はその設定が優先されます。

4.14.2　実行環境での設定（J2EEサーバの設定）

HTTPレスポンスヘッダのカスタマイズの設定をする場合，J2EEサーバの設定が必要です。

ここでは，HTTPレスポンスヘッダのカスタマイズの設定方法と設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

HTTPレスポンスヘッダのカスタマイズは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.response.header.server

HTTPレスポンスのServerヘッダに自動設定する文字列を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　設定例

HTTPレスポンスヘッダのカスタマイズの設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.response.header.server</param-name>
 <param-value>GyoumuServer/1.0</param-value>
</param>
：

この設定例では，Serverヘッダの値として「GyoumuServer/1.0」を指定しています。

4.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）

クライアントから，存在しないリソースへのアクセスなどがあると，インプロセスHTTPサーバはエラーステータスコードとエラーページを返し，クライアントにはインプロセスHTTPサーバが生成したエラーページが表示されます。インプロセスHTTPサーバでは，このエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

この節では，エラーページを使用したWebクライアントへのレスポンスのカスタマイズについて説明します。

この節の構成を次の表に示します。

表4-21　この節の構成（エラーページのカスタマイズ（インプロセスHTTPサーバ））

分類 | タイトル | 参照先
解説 | カスタマイズできるエラーページ | 4.15.1
実装 | エラーページのカスタマイズを実行する場合に必要な実装 | 4.15.2
設定 | 実行環境での設定（J2EEサーバの設定） | 4.15.3
注意事項 | エラーページのカスタマイズに関する注意事項 | 4.15.4

注　「運用」について，この機能固有の説明はありません。

＜この節の構成＞

4.15.1　カスタマイズできるエラーページ

4.15.2　エラーページのカスタマイズを実行する場合に必要な実装

4.15.3　実行環境での設定（J2EEサーバの設定）

4.15.4　エラーページのカスタマイズに関する注意事項

4.15.1　カスタマイズできるエラーページ

存在しないリソースへのアクセスなどのエラーが発生したときに，エラーステータスコードが表示されたエラーページの代わりにユーザが作成したエラーページをクライアントに表示させることができます。

インプロセスHTTPサーバによるエラーページのカスタマイズを利用することで，特定のステータスコードに対応するエラーページのカスタマイズや，リクエストURLに対応するエラーページのカスタマイズをWebコンテナ単位にまとめて制御できます。また，次に示すようなWebアプリケーションによるエラーページのカスタマイズが実行できない場合でも，エラーページをカスタマイズできます。

リクエストに対応するコンテキストがない場合（ステータスコード404）

停止処理中のコンテキストでリクエスト処理を実行しようとした場合（ステータスコード503）

インプロセスHTTPサーバがエラーステータスコードを返す場合

インプロセスHTTPサーバが返すエラーステータスコードについては，「付録A.3　インプロセスHTTPサーバが返すエラーステータスコード」を参照してください。

インプロセスHTTPサーバでは，次に示すエラーページのカスタマイズができます。

ステータスコードに対応するエラーページのカスタマイズ
ステータスコード400番台，500番台に対応するエラーページをカスタマイズできます。
ステータスコードに対応するエラーページをカスタマイズすることによって，ステータスコードに対応するファイルの送信と，ステータスコードに対応するリダイレクトを実行できます。

ステータスコードに対応するファイルの送信
カスタマイズするステータスコードに対して，レスポンスボディとして特定のファイルをクライアントに返すことができます。この場合，レスポンスのContent-Typeヘッダの値を指定します。
なお，リクエスト処理時にファイルの読み込みに失敗した場合，デフォルトのエラーページが使用されます。

ステータスコードに対応するリダイレクト
カスタマイズするステータスコードに対して，特定のURLにリダイレクトできます。リダイレクトする場合，レスポンスのステータスコードに302を設定して，LocationヘッダにリダイレクトURLを指定します。
ステータスコードに対応するファイルを送信する場合，リダイレクトは実行できません。

リクエストURLに対応するエラーページのカスタマイズ
リクエストURLを指定して，特定のURLのエラーページをカスタマイズできます。リクエストURLを指定した場合，指定したURLと一致するリクエスト処理でエラーが発生した場合だけ，カスタマイズしたエラーページをクライアントに返します。

4.15.2　エラーページのカスタマイズを実行する場合に必要な実装

インプロセスHTTPサーバによるエラーページのカスタマイズを実行する場合，javax.servlet.http.HttpServletResponseインタフェースのsendErrorメソッドを使用してレスポンスのステータスコードを設定する必要があります。なお，setStatusメソッドを使用した場合（JSPでsetStatusメソッドを使用した場合など），インプロセスHTTPサーバによるカスタマイズが実行されないことがあります。ただし，sendErrorメソッドを使用しても，Webアプリケーションが次に示すどちらかの条件に該当する場合，インプロセスHTTPサーバによるエラーページのカスタマイズは実行されません。

sendErrorメソッドの実行時に例外が発生した場合

Webアプリケーションでエラーページのカスタマイズの設定をしていて，エラー発生時にその設定によるエラーページの実行が正常終了した場合※

注※

エラーページの実行が正常終了した場合とは，次の条件を満たす場合のことです。

エラーページでcatchされない例外が発生していない。

ステータスコードが400～599以外で終了している。

4.15.3　実行環境での設定（J2EEサーバの設定）

エラーページのカスタマイズを実行する場合，J2EEサーバの設定が必要です。

ここでは，エラーページのカスタマイズの設定方法と設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。エラーページのカスタマイズの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのエラーページのカスタマイズの定義について次の表に示します。

表4-22　簡易構築定義ファイルでのエラーページのカスタマイズの定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.error_custom.list | エラーページのカスタマイズ定義名を指定します。
webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.status | エラーステータスコードに対応づけるエラーページのカスタマイズをする場合に，エラーページをカスタマイズするエラーステータスコードを指定します。
webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.file | エラーステータスコードに対応するファイルを送信する場合に，レスポンスボディとしてクライアントに返すファイルを指定します。
webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.file.content_type | webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.fileパラメタに指定したファイルをレスポンスボディとしてクライアントに送信する際のContent-Typeヘッダの値を指定します。
webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.redirect_url | エラーステータスコードに対応するリダイレクトをする場合に，リダイレクト先のURLを指定します。
webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.request_url | リクエストURLに対応づけるエラーページのカスタマイズをする場合に，エラーページのカスタマイズを適用するリクエストURLを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　設定例

エラーページのカスタマイズの設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.list</param-name>
 <param-value>ERR_CUSTOM_1,ERR_CUSTOM_2</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_1.status</param-name>
 <param-value>404</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_1.file</param-name>
 <param-value>C:/data/404.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_1.file.content_type</param-name>
 <param-value>text/html; charset=ISO-8859-1</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_2.status</param-name>
 <param-value>503</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_2.redirect_url</param-name>
 <param-value>http://host1/503.html</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_2.request_url</param-name>
 <param-value>/dir1/*</param-value>
</param>
：

この設定例では，エラーページのカスタマイズ定義名として，「ERR_CUSTOM_1」と「ERR_CUSTOM_2」を使用しています。「ERR_CUSTOM_1」では，レスポンスのステータスコードが「404」の場合には，「C:/data/404.html」をクライアントに返します。Content-Typeヘッダの値は，「text/html; charset=ISO-8859-1」を使用します。また，「ERR_CUSTOM_2」では，リクエストが「/dir1/」から始まるURLで，レスポンスのステータスコードが「503」の場合に，「http://host1/503.html」にリダイレクトします。

4.15.4　エラーページのカスタマイズに関する注意事項

インプロセスHTTPサーバによるエラーページのカスタマイズに関する注意事項を次に示します。

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，エラーページが正しく表示されない場合があります。

ブラウザの設定によっては，ステータスコードがエラーを示し，レスポンスボディのサイズが小さい場合，レスポンスボディがブラウザ固定のメッセージに置き換えられて表示されることがあるため注意してください。特にエラーページをカスタマイズしなかった場合に表示されるデフォルトのエラーページは，レスポンスボディのサイズが小さいため注意してください。

リダイレクトURLの指定値とリクエストURLの指定値が一致して，リダイレクト後に同じエラーステータスが発生すると，クライアントによってはリダイレクトを実行し続けることがあるため注意してください。

ステータスコードに対応するリダイレクトを実施する場合，エラー発生時にリクエストURLに付加されていたクエリ文字列はリダイレクトURLに付加されません。また，URLの書き換えによるセッション管理をしている場合，エラーの発生したページと同じWebアプリケーション内へのリダイレクトを実施してもセッションを引き継ぐことはできません。

4.16　Webコンテナへのゲートウェイ情報の通知

この節では，Webコンテナへのゲートウェイ情報の通知について説明します。

この節の構成を次の表に示します。

表4-23　この節の構成（Webコンテナへのゲートウェイ情報の通知）

分類 | タイトル | 参照先
解説 | ゲートウェイ指定機能 | 4.16.1
設定 | 実行環境での設定（J2EEサーバの設定） | 4.16.2
注意事項 | Webコンテナにゲートウェイ情報を通知する場合の注意事項 | 4.16.3

注　「実装」および「運用」について，この機能固有の説明はありません。

参考

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。機能の解説については，「3.10　Webコンテナへのゲートウェイ情報の通知」を参照してください。

＜この節の構成＞

4.16.1　ゲートウェイ指定機能

4.16.2　実行環境での設定（J2EEサーバの設定）

4.16.3　Webコンテナにゲートウェイ情報を通知する場合の注意事項

4.16.1　ゲートウェイ指定機能

クライアントとインプロセスHTTPサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合で，welcomeファイルやForm認証画面への遷移時などにWebコンテナが自動的にリダイレクトするとき，Webコンテナではゲートウェイの情報を得ることができないで，転送先のURLを正しく作成できないことがあります。

これを解決するために，ゲートウェイ指定機能を使用します。ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

ゲートウェイ指定機能は次のような場合に使用できます。

クライアントとインプロセスHTTPサーバとの間にSSLアクセラレータを配置する場合
クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，welcomeファイルやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。
この場合，ゲートウェイ指定機能を使用して，スキームを常にhttpsと見なすように指定することで，正しくリダイレクトできるようになります。

Hostヘッダのないリクエストに対して，リクエストを受けたインプロセスHTTPサーバ以外へリダイレクトする必要がある場合
Hostヘッダのないリクエストをリダイレクトする場合，リダイレクト先URLのホスト名・ポート番号は，リクエストを受けたWebサーバのホスト名・ポート番号となります。
ゲートウェイ指定機能は，WebサーバまたはインプロセスHTTPサーバの前に負荷分散機を配置している場合などで，クライアントがアクセスするURLのホスト名・ポート番号が，リクエストを受けたWebサーバまたはインプロセスHTTPサーバと異なるときに使用します。これによって，クライアントからアクセスするホスト名・ポート番号が指定されるので，正しくリダイレクトできるようになります。

なお，インプロセスHTTPサーバを使用する場合，一つのWebコンテナに複数の異なる経路でアクセスする場合（複数のゲートウェイからWebコンテナにHTTPリクエストが転送される場合など），ゲートウェイ指定機能を使用できません。インプロセスHTTPサーバを使用する場合，ゲートウェイ指定機能を使用するには，Webコンテナへのアクセス経路は一つになる構成にする必要があります。

4.16.2　実行環境での設定（J2EEサーバの設定）

Webコンテナにゲートウェイ情報を通知するための設定をする場合，J2EEサーバの設定が必要です。

ここでは，Webコンテナにゲートウェイ情報を通知するための設定方法と設定例について説明します。

＜この項の構成＞

(1)　設定方法

(2)　設定例

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナにゲートウェイ情報を通知するための設定の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリWebコンテナにゲートウェイ情報を通知するための設定の定義について次の表に示します。

表4-24　簡易構築定義ファイルでのWebコンテナにゲートウェイ情報を通知するための設定の定義

指定するパラメタ | 設定内容
webserver.connector.inprocess_http.gateway.https_scheme | リダイレクト先URLのスキームを指定します。
webserver.connector.inprocess_http.gateway.host | ゲートウェイのホスト名を指定します。
webserver.connector.inprocess_http.gateway.port | ゲートウェイのポート番号を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　設定例

ゲートウェイ指定機能の設定例を次に示します。

：
<param>
 <param-name>webserver.connector.inprocess_http.gateway.host</param-name>
 <param-value>host1</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.gateway.port</param-name>
 <param-value>4443</param-value>
</param>
<param>
 <param-name>webserver.connector.inprocess_http.gateway.https_scheme</param-name>
 <param-value>true</param-value>
</param>
：

この設定例では，ゲートウェイ指定機能を使用して，スキームを常にHTTPSと見なすように設定しています。

4.16.3　Webコンテナにゲートウェイ情報を通知する場合の注意事項

ゲートウェイ指定機能を使用する上での注意事項を次に示します。

リダイレクト先URLのホスト名，およびポート番号の指定について
通常，ブラウザはHostヘッダを付けてリクエストを送信するため，リダイレクト先URLのホスト名やポート番号を指定する必要はありません。
なお，リクエストにHostヘッダがあるかどうかは，javax.servlet.http.HttpServletRequestクラスのgetHeaderメソッドに，引数「Host」を指定して呼び出すことで確認できます。

サーブレットAPIの動作について
ゲートウェイ指定機能の利用によって，一部のサーブレットAPIの動作が変わります。WebアプリケーションでAPIを利用するときには注意が必要です。
なお，動作が変わるサーブレットAPIについては，「5.1.2(10)　ゲートウェイ指定機能を使用する場合の注意」を参照してください。

web.xmlの<transport-guarantee>タグについて
ゲートウェイ指定機能でスキームをHTTPSと見なすように設定した場合，WebサーバへのリクエストがHTTPであってもHTTPSであると見なされます。このため，web.xmlの<transport-guarantee>タグでINTEGRALやCONFIDENTIALを指定してもHTTPSのURLへリダイレクトされないので注意してください。

CookieのSecure属性について
ゲートウェイ指定機能でスキームをHTTPSと見なすように設定している場合に，Webコンテナが生成したセッションIDを，Cookieによってクライアントに返すとき，そのCookieにはSecure属性が付与されます。

4.17　ログ・トレースの出力

この節では，インプロセスHTTPサーバが出力するログ・トレースについて説明します。

この節の構成を次の表に示します。

表4-25　この節の構成（ログ・トレースの出力）

分類 | タイトル | 参照先
解説 | インプロセスHTTPサーバが出力するログ・トレース | 4.17.1
設定 | インプロセスHTTPサーバのアクセスログのカスタマイズ | 4.17.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

4.17.1　インプロセスHTTPサーバが出力するログ・トレース

4.17.2　インプロセスHTTPサーバのアクセスログのカスタマイズ

4.17.1　インプロセスHTTPサーバが出力するログ・トレース

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，次の表に示すログおよびトレースを出力します。

表4-26　インプロセスHTTPサーバが出力するログ・トレース

ログ・トレースの種類
説明

アクセスログ
Webクライアントからのリクエスト，およびレスポンスの処理結果を出力します。Webクライアントとの通信の解析に使用します。
アクセスログを解析することによって，Webクライアントからリクエストされたファイルや，インプロセスHTTPサーバの性能情報，およびセッショントラッキング情報などを分析できます。

性能解析トレース
インプロセスHTTPサーバでリクエストを送受信するときの性能解析情報や，障害発生時のトラブルシュートのための情報を出力します。
性能解析トレースは，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて，システム全体のボトルネックの解析などに使用できます。性能解析トレースの詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「4.6　性能解析トレース」を参照してください。

スレッドトレース
保守用のトレースです。

通信トレース
保守用のトレースです。

4.17.2　インプロセスHTTPサーバのアクセスログのカスタマイズ

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，アクセスログ，性能解析トレース，スレッドトレース，および通信トレースを出力します。これらのファイルは，ファイル面数やファイルサイズなどを変更できます。また，アクセスログでは，ログの出力形式をカスタマイズできます。

ここでは，インプロセスHTTPサーバのアクセスログの出力形式のカスタマイズについて説明します。インプロセスHTTPサーバのアクセスログおよびトレースファイルのファイル面数やファイルサイズなどの変更については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.11　インプロセスHTTPサーバのログ取得の設定」を参照してください。

＜この項の構成＞

(1)　カスタマイズの手順

(2)　アクセスログのフォーマット

(3)　アクセスログのフォーマットの引数

(1)　カスタマイズの手順

アクセスログの出力形式のカスタマイズの手順を次に示します。

アクセスログのフォーマット名を定義します。
フォーマットを新規作成する場合には，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.logger.access_log.format_listパラメタで，新規に作成するフォーマット名を追加します。

設定例

：
<param>
 <param-name>webserver.logger.access_log.format_list</param-name>
 <param-value>formatA</param-value>
</param>
：

フォーマットを新規作成する場合には，デフォルトで提供されているアクセスログのフォーマットを参考にしてください。フォーマットについては，「(2)　アクセスログのフォーマット」を参照してください。

アクセスログの出力形式を定義します。
簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.logger.access_log.<フォーマット名>パラメタで，<フォーマット名>で指定したフォーマットでのアクセスログの出力形式を定義します。出力形式の定義では，アクセスログのフォーマットの引数を指定します。

設定例

：
<param>
 <param-name>webserver.logger.access_log.formatA</param-name>
 <param-value>%h %u %t &quot;%r&quot; %&gt;s HostHeader=&quot;%{host}i&quot;</param-value>
</param>
：

指定できるフォーマットの引数については，「(3)　アクセスログのフォーマットの引数」を参照してください。

アクセスログの出力に使用するフォーマットを指定します。
簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.logger.access_log.inprocess_http.usage_formatパラメタで，アクセスログの出力に使用するフォーマット名を指定します。ここで指定したフォーマットで，アクセスログが出力されるようになります。

設定例

：
<param>
 <param-name>webserver.logger.access_log.inprocess_http.usage_format</param-name>
 <param-value>formatA</param-value>
</param>
：

(2)　アクセスログのフォーマット

アプリケーションサーバでは，インプロセスHTTPサーバのアクセスログのフォーマットとして，common（デフォルトフォーマット）とcombined（拡張フォーマット）という2種類のフォーマットを提供しています。フォーマットを新規作成する場合には，これらのフォーマットを参考にしてください。

(a)　出力形式

アクセスログの出力形式について説明します。なお，△は，半角スペースを表します。また，ここでは，表記の都合上，複数行にわたっていますが，実際には1行で出力されます。

デフォルトフォーマットの出力形式を次に示します。

Webクライアントのホスト名またはIPアドレス△リモートログ名△認証ユーザ名
△Webクライアントのリクエストに応答した時刻△リクエストライン
△最終ステータスコード△HTTPヘッダを除く送信バイト数

拡張フォーマットの出力形式を次に示します。

Webクライアントのホスト名またはIPアドレス△リモートログ名△認証ユーザ名
△Webクライアントのリクエストに応答した時刻△リクエストライン
△最終ステータスコード△HTTPヘッダを除く送信バイト数
△”Refererヘッダの内容”△”User-Agentヘッダの内容”

下線部分が，デフォルトフォーマットと拡張フォーマットの差異です。拡張フォーマットでは，デフォルトフォーマットの出力内容に加えて，「Refererヘッダの内容」と「User-Agentヘッダの内容」が出力されます。

(b)　出力例

デフォルトフォーマットでのアクセスログの出力例を次に示します。

10.20.30.40 - user [20/Dec/2004:15:45:01 +0900] "GET /index.html HTTP/1.1" 200 8358
10.20.30.40 - user [20/Dec/2004:15:45:01 +0900] "GET /left.html HTTP/1.1" 200 2358
10.20.30.40 - user [20/Dec/2004:15:45:01 +0900] "GET /right.html HTTP/1.1" 200 4358

拡張フォーマットでのアクセスログの出力例を次に示します。

10.20.30.40 - - [18/Jan/2005:13:06:10 +0900] "GET / HTTP/1.0" 200 38 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
10.20.30.40 - - [18/Jan/2005:13:06:25 +0900] "GET /demo/ HTTP/1.0" 500 684 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

(3)　アクセスログのフォーマットの引数

フォーマットの出力形式を定義するときに指定する，アクセスログのフォーマットの引数を次の表に示します。

表4-27　アクセスログのフォーマットの引数の一覧

フォーマットの引数
出力内容
出力例

%%
%記号
%

%a
WebクライアントのIPアドレス
10.20.30.40

%A
J2EEサーバのIPアドレス
10.20.30.100

%b
HTTPヘッダを除く送信バイト数
（0バイトの場合は「-」となる）
2048

%B
HTTPヘッダを除く送信バイト数
（0バイトの場合は「0」となる）
1024

%h
Webクライアントのホスト名またはIPアドレス
（ホスト名を取得できない場合はIPアドレスとなる）
10.20.30.40

%H
リクエストプロトコル
HTTP/1.1

%l
リモートログ名※1
（常に「-」になる）
-

%m
リクエストメソッド
GET

%p
Webクライアントからのリクエストを受け付けたポート番号
80

%q
クエリ文字列
（「?」から始まる。クエリ文字列がない場合は空文字となる）
?id=100&page=15

%r
リクエストライン
GET /index.html HTTP/1.1

%>s
最終ステータスコード
（内部リダイレクトされた値は出力しない）
200

%S※2
ユーザのセッションID
（セッションIDがない場合は「-」となる）
00455AFE4DA4E7B7789F247B8FE5D605

%t
Webクライアントのリクエストに応答した時刻
（単位：秒，出力形式：dd/MMM/YYYY:HH:mm:ss Z）
[18/Jan/2005:13:06:10 +0900]

%T
Webクライアントのリクエストの処理に掛かった時間
（単位：秒，出力形式：dd/MMM/YYYY:HH:mm:ss Z）
2

%d
Webクライアントのリクエストに応答した時刻
（単位：ミリ秒，出力形式：dd/MMM/YYYY:HH:mm:ss.nnn Z（nnnはミリ秒））
[18/Jan/2005:13:06:10.152 +0900]

%D
Webクライアントのリクエストの処理に掛かった時間
（単位：ミリ秒，出力形式：dd/MMM/YYYY:HH:mm:ss.nnn Z（nnnはミリ秒））
2000

%u
Basic認証ユーザ名，Form認証ユーザ名
（認証ユーザ名がない場合は「-」となる）
user

%U
リクエストファイルパス
/index.html

%v
J2EEサーバのローカルホスト名
server

%{foo}i※3
リクエストヘッダfooの内容
（fooヘッダが存在しない場合は「-」となる）
%{Host}iの場合www.example.com:8888

%{foo}c
Webクライアントが送信したCookie情報でCookieの名前がfooの内容
（Cookieの名前にfooがない場合は「-」となる）
%{JSESSIONID}cの場合00455AFE4DA4E7B7789F247B8FE5D605

%{foo}o※3
レスポンスヘッダfooの内容
（fooヘッダが存在しない場合は「-」となる）
%{Server}oの場合CosminexusComponentContainer

注※1

リモートログ名は，RFC 1413で規定されているIdentificationプロトコルで取得できるWebクライアント側のユーザ名です。

注※2

%Sで表示されるセッションIDは，Cookie名「JSESSIONID」の値です。メモリセッションフェイルオーバ機能でのグローバルセッションIDとは異なります。グローバルセッションIDを出力させたい場合には，%{GSESSIONID}cを指定してください。GIDCookieNameを変更した場合は，変更したGIDCookieNameの値を指定してください。

注※3

一度のHTTPリクエストまたはHTTPレスポンスで同じヘッダ名を複数回送信する場合があります。この場合，最初に読み込んだヘッダの内容を出力します。

注意

フォーマットの引数の指定に誤りがある場合には，デフォルトフォーマットが使用されます。デフォルトフォーマットが使用される例を次に示します。

フォーマットの引数の一覧にない文字列（例：%Gなど）を指定した場合

リクエストヘッダの内容，レスポンスヘッダの内容，Cookie名で0文字（%{}iなど）を指定した場合

参考

デフォルトフォーマットと拡張フォーマットをフォーマットの引数で記述すると，次のような形式になります。

デフォルトフォーマット
%h %l %u %t "%r" %>s %b

拡張フォーマット
%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"

5.　サーブレットおよびJSPの実装

この章では，サーブレットおよびJSPを実装するときの注意事項について説明します。

＜この章の構成＞

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

5.2　JSP移行時の注意事項

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

この節では，サーブレットおよびJSPの実装時の注意事項について説明します。

この節の構成を次の表に示します。

表5-1　この節の構成（サーブレットおよびJSPの実装時の注意事項）

タイトル | 参照先
サーブレットおよびJSP実装時共通の注意事項 | 5.1.1
サーブレット実装時の注意事項 | 5.1.2
Servlet 2.5仕様で追加，変更された仕様についての注意事項 | 5.1.3
Servlet 2.4仕様で追加，変更された仕様についての注意事項 | 5.1.4
JSP実装時の注意事項 | 5.1.5
JSP 2.1仕様で追加，変更された仕様についての注意事項 | 5.1.6
JSP 2.0仕様で追加，変更された仕様についての注意事項 | 5.1.7
既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点 | 5.1.8
前バージョンから08-00へ移行する場合のWebアプリケーションに関する注意事項 | 5.1.9
既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点 | 5.1.10
サーブレットでのアノテーションの使用 | 5.1.11
JavaVMのメソッドサイズ制限についての注意事項 | 5.1.12

＜この節の構成＞

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

5.1.2　サーブレット実装時の注意事項

5.1.3　Servlet 2.5仕様で追加，変更された仕様についての注意事項

5.1.4　Servlet 2.4仕様で追加，変更された仕様についての注意事項

5.1.5　JSP実装時の注意事項

5.1.6　JSP 2.1仕様で追加，変更された仕様についての注意事項

5.1.7　JSP 2.0仕様で追加，変更された仕様についての注意事項

5.1.8　既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点

5.1.9　前バージョンから08-00へ移行する場合のWebアプリケーションに関する注意事項

5.1.10　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

5.1.11　サーブレットでのアノテーションの使用

5.1.12　JavaVMのメソッドサイズ制限についての注意事項

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.5 | 2.4 | 2.3 | 2.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アプリケーションのバージョン | Servlet | JSP | タグライブラリ※
2.5 | 2.4 | 2.3 | 2.2 | 2.1 | 2.0 | 1.2 | 1.1 | 2.1 | 2.0 | 1.2 | 1.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.1
Webアプリケーション開始時に次に示す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コネクションの使用はサポートされません。

サーブレット，JSPのサービスメソッドが生成したスレッド上のJDBCコネクションを使用する。

サーブレット，JSPのサービスメソッドから呼び出した別のサーブレット，JSPのサービスメソッドでJDBCコネクションを使用する。

サーブレット，JSPのサービスメソッドのinitメソッドで取得したJDBCコネクションを使用する。

インスタンス変数に格納されたJDBCコネクションを使用する。※

注※

SingleThreadModelのサーブレットおよびJSPを使用した場合は，インスタンス変数にJDBCコネクションを格納できます。

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

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

(5)　Cookie利用時の注意

日本語などの2バイトコードを含むCookieは使用しないでください。使用した場合，サーブレットおよびJSPで利用しているHTTPセッションが失われる場合があります。

Cookieでセッション管理をする場合，ホスト名によるURLでアクセスしたサーブレットまたはJSPで生成されたセッションは，ホスト名の代わりにIPアドレスを指定したURLでアクセスしたサーブレットまたはJSPに引き継がれません（逆も同様です）。

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

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

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

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

web.xmlで指定したエラーページ

JSPのpageディレクティブのerrorPage属性で指定したエラーページ

Webコンテナサーバが出力するデフォルトのエラーページ

レスポンスのコミットは，ユーザが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クラスが使用されます。

getResource(String).openConnection().getInputStream()

getResource(String).openStream()

これらのメソッドが呼び出される過程で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からスレッドを生成して，使用できます。ユーザがプログラムの中で明示して生成するスレッドのことを，ユーザスレッドといいます。

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

サービスメソッドやinitメソッドの範囲内で動作させる。

サービスメソッドやinitメソッドのバックグラウンドで動作させる。

ユーザスレッドの使用条件

ユーザスレッドは，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メソッドをオーバーライドしていないサーブレットを初期化または終了すると，次の形式のログがサーブレットログに出力されます。

メッセージID：KDJE39037-I

メッセージ本文：path="aa....aa" :bb....bb: init※

aa....aa

「/」から始まるコンテキストパスを表します。

bb....bb

web.xmlの<servlet-name>タグで指定したサーブレット名を表します。デフォルトマッピングのサーブレットの場合は，「org.apache.catalina.INVOKER.<クラス名>」となります。

注※

initメソッドの場合は「init」，destroyメソッドの場合は「destroy」となります。出力されるメッセージは，それぞれjavax.servlet.GenericServletクラスの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アプリケーションでは，次のことに注意してください。

クライアントから送信されたバイナリデータへのリクエストを実行する場合
バイナリデータへのリクエストで適用されるフィルタ内で，レスポンスオブジェクトからのPrintWriterを取得しないでください。

クライアントから送信されたリクエストを処理するサーブレットまたはJSPがディスパッチする場合
次の場所では，レスポンスオブジェクトからのPrintWriterを取得しないでください。

バイナリデータへのリクエストで適用されるフィルタ内

バイナリデータにディスパッチするサーブレットまたはJSP内

参考

バイナリデータとは，拡張子にマッピングされたMIMEタイプが"text/"から始まっていない静的コンテンツ，またはマッピングが存在しない静的コンテンツです。

(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の種類
あり | 絶対URI | Webサーバ連携 | リクエストラインのホスト名 | リクエストラインのポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
簡易Webサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
相対URI | Webサーバ連携 | Hostヘッダのホスト名 | Hostヘッダのポート番号
インプロセスHTTPサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
簡易Webサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
なし | 絶対URI | Webサーバ連携 | リクエストラインのホスト名 | リクエストラインのポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
簡易Webサーバ | J2EEサーバのホスト名またはIPアドレス※1 | 簡易Webサーバのポート番号
相対URI | Webサーバ連携 | Webサーバのホスト名またはIPアドレス※2 | Webサーバのポート番号
インプロセス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の種類
あり | 絶対URI | Webサーバ連携 | リクエストラインのホスト名 | リクエストラインのポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
相対URI | Webサーバ連携 | Hostヘッダのホスト名 | Hostヘッダのポート番号
インプロセスHTTPサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
なし | 絶対URI | Webサーバ連携 | ゲートウェイ指定機能で指定したホスト名 | ゲートウェイ指定機能で指定したポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
相対URI | Webサーバ連携 | ゲートウェイ指定機能で指定したホスト名 | ゲートウェイ指定機能で指定したポート番号
インプロセスHTTPサーバ | ゲートウェイ指定機能で指定したホスト名 | ゲートウェイ指定機能で指定したポート番号

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

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

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

互換用のパラメタ
07-60以前と同じ動作にする場合，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で互換用のパラメタwebserver.servlet_api.exception.getCause.backcompatにtrueを指定します。パラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。
互換用のパラメタwebserver.servlet_api.exception.getCause.backcompatの指定値によるgetCauseメソッドおよびgetRootCauseメソッドの戻り値の違いを次の表に示します。

表5-10　webserver.servlet_api.exception.getCause.backcompatの指定値によるgetCauseメソッドおよびgetRootCauseメソッドの戻り値の違い

メソッド | webserver.servlet_api.exception.getCause.backcompatの指定値
true | false
getCause() | × | ○
getRootCause() | ○ | ○

（凡例）○：根本原因の例外を返す　×： nullを返す

なお，この互換用のパラメタの指定内容は，javax.servlet.jsp.JspExceptionクラスのgetCauseメソッドおよびgetRootCauseメソッドの動作にも適用されます。

注意事項
根本原因の例外をgetCauseメソッドの実装によって取得できる場合，コンストラクタServletException(String, Throwable)またはServletException(Throwable)で生成したServletExceptionオブジェクトに対してinitCause(Throwable)を呼び出すことはできません。initCause(Throwable)を呼び出した場合，java.lang.IllegalStateException例外がスローされます。

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

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

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

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

コンテキストパスとコンテキストルートのマッチング

サーブレットおよびJSPのURLパターンとのマッチング

デフォルトマッピングとのマッチング

静的コンテンツとのマッチング

フィルタのURLパターンとのマッチング

web.xmlの<error-page>タグ，またはJSPのpageディレクティブのerrPage属性で指定するエラーページとのマッチング

アクセスを制限するURLパターンとのマッチング

ログイン認証のURL判定

リクエストのフォワードおよびインクルード

HTTPレスポンス圧縮フィルタのURLパターンとのマッチング

URLグループ単位の同時実行スレッド数制御のURLパターンとのマッチング

インプロセスHTTPサーバのエラーページのカスタマイズ

インプロセスHTTPサーバのリダイレクトによるリクエストの振り分け

(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設計の際に次のことに注意してください。

POSTリクエストを受け付けた際，ブラウザから送信されたリクエストボディの情報を転送先のwelcomeファイルに引き継げません。POSTされた情報がフォーム入力形式（Content-Typeがapplication/x-www-form-urlencoded）の場合だけ，Webコンテナが生成するwelcomeファイル転送先URLのクエリ文字列に情報を付与する形で引き継げます。ただし，この場合も，リクエストボディの情報が多い場合に転送先URLが長くなり過ぎる，ブラウザのアドレスバーにクエリ文字列として情報がそのまま見える，などについて考慮が必要です。

転送先のwelcomeファイルのサーブレットがdoGetメソッドを実装していない場合，ブラウザに「400 Bad Request」（HTTP/1.1以外の場合）または「405 Method Not Allowed」（HTTP/1.1の場合）が表示されます。

Webアプリケーションからjavax.servlet.RequestDispatcherインタフェースのincludeメソッドを呼び出した際，インクルードする対象のURLとしてwelcomeファイルが存在するディレクトリを指定していても，転送先のwelcomeファイルのコンテンツは挿入されません。

●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アプリケーションでも同じ順序で初期化処理をします。初期化処理の順序を次に示します。

web.xmlの<listener>要素に定義されたそれぞれのイベントリスナのインスタンスを作成します。

ServletContextListenerを実装しているリスナのインスタンスに対して，contextInitialized()メソッドを呼び出します※。

web.xmlの<filter>要素に指定したフィルタのインスタンスを作成し，フィルタの init()メソッドを呼び出します。

web.xmlの<servlet>要素に<load-on-startup>要素を含むサーブレットについて，<load-on-startup>要素の値で定義された順番でサーブレットのインスタンスを作成し，サーブレットのinit()メソッドを呼び出します。

注※

リスナのcontextInitialized()メソッドの呼び出しで例外が発生しても，KDJE39103-Eのメッセージを出力してWebアプリケーションの開始処理を継続します。

5.1.2　サーブレット実装時の注意事項

サーブレットを実装するときの注意事項を示します。

＜この項の構成＞

(1)　入出力ストリーム利用時の注意

(2)　ロケール設定時の注意

(3)　URI取得時の注意

(4)　POSTデータの読み込み失敗時の動作について

(5)　属性の変更に対するイベント通知時の注意

(6)　ServletContextインタフェース利用時の注意

(7)　Webアプリケーションに含まれるディレクトリにアクセスするときの注意

(8)　ServletRequestインタフェース利用時の注意

(9)　プロセス内で複数回実行してはならない処理を実装する場合の注意

(10)　ゲートウェイ指定機能を使用する場合の注意

(11)　ゲートウェイ使用時の注意

(12)　ServletContextオブジェクトに登録する日立独自の属性

(13)　ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

(14)　javax.servlet.ServletResponseインタフェースのresetメソッド実行時の注意

(15)　setMaxInactiveIntervalメソッドの引数に0を指定した場合の動作

(16)　java.io.BufferedReaderのmark操作について

(17)　setVersionメソッドの引数に1を指定した場合の動作

(18)　getRequestDispatcherメソッドでのパスの指定について

(19)　setBufferSizeメソッドを使用してバッファサイズを変更する場合の注意

(20)　HTTPレスポンスのContent-Typeヘッダについての注意

(21)　javax.servlet.http.HttpSessionクラスのgetIdメソッドについての注意事項

(22)　javax.servlet.ServletRequestクラスおよびjavax.servlet.http.HttpServletRequestクラスのメソッドについての注意事項

(23)　javax.servlet.ServletRequestクラスのgetLocale(getLocales)メソッドについての注意事項

(24)　javax.servlet.http.HttpServletRequestインタフェースのgetServerNameメソッドの戻り値

(25)　Servlet 2.4以前のinclude先のサーブレットでのレスポンスヘッダの設定

(26)　MIMEマッピングがない静的コンテンツのコンテンツ形式

(1)　入出力ストリーム利用時の注意

ServletInputStreamのavailableメソッドは，簡易Webサーバ機能を使用している場合，常に0を返します。それ以外の場合，バッファの状態に依存した値を返します。

ServletOutputStreamクラスのprint(char c)メソッドの引数には，0x00～0xFFの範囲で指定してください。範囲外の値を指定するとjava.io.CharConversionExceptionが発生します。

ServletInputStreamクラスでは，markメソッドおよびresetメソッドをサポートしていません。また，markSupportedメソッドは常にfalseを返します。

ServletInputStreamクラスからデータを読み出したあとに転送（forward）した場合，転送先のServletInputStreamクラスから読み出されるデータは，転送する前に読み出された位置からのものとなります。また，転送する前にServletInputStreamクラスからすべてのデータを読み出した場合，転送先のリクエストパラメタは空となります。

(2)　ロケール設定時の注意

ServletResponseクラスのsetLocaleメソッドにLocale.JAPANESEを指定した場合，Content-TypeヘッダのcharsetはShift_JIS（シフトJIS）になります。

(3)　URI取得時の注意

HttpServletRequestクラスのgetRequestURIメソッドでは，最適化されたURIが返されます。例えば，「xxx//yyy/zzz」は「xxx/yyy/zzz」に，「xxx/yyy/../zzz」は「xxx/zzz」のように変換されます。

(4)　POSTデータの読み込み失敗時の動作について

WebサーバでPOSTデータの読み込みに失敗した場合，Webコンテナで動作するサーブレットでは，ServletRequestクラスの次に示すメソッドの呼び出し時にIllegalStateException例外が発生します。

getParameterメソッド

getParameterNamesメソッド

getParameterValuesメソッド

getParameterMapメソッド

(5)　属性の変更に対するイベント通知時の注意

ServletContextAttributeListenerインタフェース，HttpSessionAttributeListenerインタフェース，およびServletRequestAttributeListenerでは，Webコンテナが内部で使用している属性の追加，削除，更新があった場合にもイベントが通知される場合があります。通知されたイベントの属性名を参照して，Webアプリケーションで使用している属性名以外の場合には無視するようにしてください。

(6)　ServletContextインタフェース利用時の注意

ServletContextインタフェースのgetResourcePathsメソッドによって得られるjava.util.Setは参照用です。このjava.util.Setに対し，要素の追加，削除の操作をしないでください。add，addAll，clear，remove，およびremoveAllメソッドを使用するとIllegalStateException例外が発生する場合があります。

ServletContextインタフェースのgetContextメソッドの引数には，存在するコンテキストルート名を使用したURLを指定してください。存在しないコンテキストルート名を使用したURLを指定した場合の動作は保証されません。

ServletContextインタフェースのgetResourceメソッドおよびgetResourceAsStreamメソッドには，該当Webアプリケーションに含まれるリソースを指定してください。該当Webアプリケーション外のリソースを指定した場合の動作は保証されません。

(7)　Webアプリケーションに含まれるディレクトリにアクセスするときの注意

Webアプリケーションに含まれるディレクトリにアクセスするときは，クエリ文字列およびPOSTデータがリダイレクト先リソースで取得できないことがあるため，クエリ文字列およびPOSTデータは付けないようにしてください。

(8)　ServletRequestインタフェース利用時の注意

ServletRequestインタフェースのgetRemoteHostメソッドは，リクエストを送信したクライアントのホスト名を返しますが，Webサーバがホスト名を解決できないか，解決しないように設定されている場合はIPアドレスを返します。

既定の設定ではWebサーバの設定がされていないため，IPアドレスを返します。ホスト名を取得する場合は，Webサーバの設定を変更する必要があります。ただし，設定を変更すると，ホスト名の解決のため，レスポンスが遅くなる場合があります。Webサーバの設定の変更方法については，マニュアル「Hitachi Web Server」を参照してください。

(9)　プロセス内で複数回実行してはならない処理を実装する場合の注意

1プロセス内で複数回実行してはならない処理をサーブレット中に記述する場合，サーブレットの実行とその処理が同期することがないようにしてください。特に，OTMとの通信を開始するための初期化処理の中には，インスタンスを削除しても終了しない常駐スレッドを生成するものがあります。例えば，Cosminexus TPBrokerの初期化関数であるORB.initメソッドは，呼び出されるたびにガーベージコレクション実行のための監視用常駐スレッドを生成し，このスレッドはプロセス終了まで消えません。そのため，１プロセス内でORB.initメソッドを必要以上に実行すると，不要なガーベージコレクション処理が増え，システム全体の性能が著しく低下するなどの悪影響があります。

このような事態を避けるため，プロセス中で1回だけ実行させたい処理をサーブレットに記述する場合には，その処理がプロセス中で実行済みかどうかをあらかじめ判定する必要があります。具体的には，ある処理が実行済みかどうかの状態を格納する条件フラグとしてstatic変数を任意のクラス中で用意します。static変数の値が「未実行」を意味するものである場合にだけ処理を実行し，値を「実行済み」を意味するものに変更することで，その処理の実行回数をプロセス中で1回だけに限定できます。ただし，次の2点に注意してください。

任意のクラスでstatic変数を使用する場合は，usrconf.propertiesまたはhitachi_web.propertiesに次の設定をしないでください。
・webserver.context.reloadable=true
・webserver.jsp.recompilable=true
設定した場合，そのクラスのインスタンスが自動的に破棄されて，再生成されることがあるため，それに伴ってstatic変数の値も初期化されてしまうことがあります。usrconf.propertiesとhitachi_web.propertiesの設定については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

あるスレッドが条件フラグであるstatic変数の値を参照してから値を変更するまでの間に，ほかのスレッドが同様の処理を実行することがないよう，この処理を実行するメソッドにsynchronizedキーワードを指定してください。この方法を用いてCosminexus TPBrokerの初期化関数ORB.initメソッドが1回だけ呼び出されるようにするためのコーディング例を次に示します。

static org.omg.CORBA.ORB _orb=null;
public static synchronized org.omg.CORBA.ORB getORB(String[] args, Properties props){
 if(_orb==null){
   _orb=org.omg.CORBA.ORB.init(args,props);
 }
return _orb;
}

(10)　ゲートウェイ指定機能を使用する場合の注意

Webコンテナにゲートウェイ情報を通知し，welcomeファイルやFORM認証画面に正しくリダイレクトするゲートウェイ指定機能を使用できます。ゲートウェイ指定機能については，「3.10　Webコンテナへのゲートウェイ情報の通知」を参照してください。

ゲートウェイ指定機能を使用する場合，一部のサーブレットAPIの動作が変わります。ゲートウェイ指定機能使用時のサーブレットAPIの注意事項を，使用するメソッドごとに示します。

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッド
引数に相対URLを指定し，Hostヘッダのないリクエストの場合，リダイレクト先URLのホスト名とポート番号は，ゲートウェイ指定機能で指定した値となります。引数に相対URLを指定し，ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，リダイレクト先URLのスキームは常に「https」となります。

javax.servlet.ServletRequestインタフェースのgetRequestURLメソッド
ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，戻り値は常に「https://」で始まるURLとなります。

javax.servlet.ServletRequestインタフェースのgetServerNameメソッド
ゲートウェイ指定機能でリダイレクト先URLのホスト名を指定し，リクエストにHostヘッダがない場合，戻り値は指定した値となります。

javax.servlet.ServletRequestインタフェースのgetServerPortメソッド
ゲートウェイ指定機能でリダイレクト先URLのポート番号を指定し，リクエストにHostヘッダがない場合，戻り値は指定した値となります。ゲートウェイ指定機能でリダイレクト先URLのホスト名を指定し，ポート番号を省略した場合，戻り値はリクエストのスキームがhttpであれば「80」，httpsであれば「443」となります。

javax.servlet.ServletRequestインタフェースのgetSchemeメソッド
ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，戻り値は常に「https」となります。

javax.servlet.ServletRequestインタフェースのisSecureメソッド
ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，戻り値は常に「true」となります。

javax.servlet.ServletRequestインタフェースのgetAttributeメソッド
ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合でも，次の属性は取得できません。

javax.servlet.request.cipher_suite（WebサーバにMicrosoft IISを使用している場合は，ゲートウェイ指定機能の使用に関係なく取得できません）

javax.servlet.request.key_size

javax.servlet.request.X509Certificate

(11)　ゲートウェイ使用時の注意

SSLアクセラレータや負荷分散器などのゲートウェイを使用した場合，次のサーブレットAPIの戻り値はクライアントのIPアドレスやホスト名ではなく，ゲートウェイのIPアドレスやホスト名になります。

javax.servlet.ServletRequestクラスのgetRemoteAddrメソッド

javax.servlet.ServletRequestクラスのgetRemoteHostメソッド

(12)　ServletContextオブジェクトに登録する日立独自の属性

Webコンテナは，Webアプリケーションの制御に必要な情報をjavax.servlet.ServletContextオブジェクトの属性に登録しています。WebアプリケーションでServletContextインタフェースのgetAttributeNamesメソッドによって取得する属性名には，Webコンテナによって登録された属性の名称も含まれます。

Webアプリケーション内でServletContextオブジェクトに属性を登録する時，次の文字列で開始するキー名称を使用しないでください。

org.apache.catalina

com.hitachi.software.web

jspx

また，ServletContextにはJava EEの仕様で定められた属性も追加されるため，これらと同じキー名称の属性を登録しないでください。

(13)　ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

次に示すjavax.servlet.ServletRequestクラスのメソッドは，リクエストを送信したクライアント，または最後に通ったプロキシの情報を取得するためのメソッドですが，リバースプロキシを使用した環境では，取得する情報がリバースプロキシの情報となります。

getRemoteAddrメソッド

getRemoteHostメソッド

getRemotePortメソッド

(14)　javax.servlet.ServletResponseインタフェースのresetメソッド実行時の注意

javax.servlet.ServletResponseインタフェースのgetWriterメソッドを実行したあとに，resetメソッドを実行した場合，HTTPレスポンスのContent-Typeで指定する文字エンコーディングは，次に示すAPIのどれか（すべてjavax.servlet.ServletResponseインタフェース）を使用して，再度同じ文字エンコーディングを指定してください。

setContentTypeメソッド

setLocaleメソッド

setCharacterEncodingメソッド※

注※

Servlet 2.4仕様で追加されたメソッドです。

Servlet 2.4仕様以降では，これらのAPIを使用して文字エンコーディングを設定する場合は，getWriterメソッドを実行する前に呼び出す必要があります。ただし，getWriterメソッドを実行したあとにresetメソッドを実行した場合にかぎり，再度getWriterメソッドを呼び出すまではこれらのAPIで文字エンコーディングを設定できます。

(15)　setMaxInactiveIntervalメソッドの引数に0を指定した場合の動作

javax.servlet.http.HttpSessionインタフェースのsetMaxInactiveIntervalメソッドの引数に0を指定した場合，セッションがタイムアウトになることはありません。

(16)　java.io.BufferedReaderのmark操作について

インプロセスHTTPサーバ機能を使用している場合に，javax.servlet.ServletRequestのgetReaderメソッドで得られるjava.io.BufferedReaderは，mark操作をサポートしていません。markSupportedメソッドではfalseが返されます。

(17)　setVersionメソッドの引数に1を指定した場合の動作

javax.servlet.http.CookieのsetVersionメソッドの引数に1を指定した場合，Webサーバ連携機能使用時には，レスポンスにSet-Cookie2ヘッダが付加されますが，インプロセスHTTPサーバ機能使用時にはSet-Cookieヘッダが付加されます。

(18)　getRequestDispatcherメソッドでのパスの指定について

javax.servlet.ServletRequestのgetRequestDispatcherメソッドの引数に「/」ではじまらない相対パスを指定した場合，このサーブレットのサーブレットマッピングに指定したURLパターンからの相対パスになります。URLパターンが「/」で終わっている場合は，親のディレクトリからの相対パスになります。

例えば，サーブレットマッピングを"/a/b/"に指定したサーブレットから，"hello.html"を指定してgetRequestDispatcherメソッドを実行すると，"/a/hello.html"が得られます。

(19)　setBufferSizeメソッドを使用してバッファサイズを変更する場合の注意

レスポンス送信時に使用されるサーブレットのバッファは，リクエスト処理スレッドごとに保持されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを実行してバッファサイズを変更した場合，変更したバッファサイズは，同一J2EEサーバ上のほかのWebアプリケーションを含め，該当するスレッドが処理するすべてのリクエストに適用されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを使用してバッファサイズを変更する場合は，（バッファサイズ）×（リクエスト処理スレッド数）分のメモリが確保されることを考慮した上で，メモリ使用量を見積もってください。

なお，一度確保されたバッファは，処理スレッドごとにWebアプリケーションからsetBufferSizeメソッドで更新されるまで有効となります。

(20)　HTTPレスポンスのContent-Typeヘッダについての注意

サーブレットでは，javax.servlet.ServletResponseクラスのsetContentTypeメソッドで明示的にContent-Typeを設定していない場合，Content-Typeヘッダを作成しません。そのため，HTTPレスポンスの文字エンコーディングをContent-Typeヘッダの”charset=”フィールドから確認することはできません。

(21)　javax.servlet.http.HttpSessionクラスのgetIdメソッドについての注意事項

Servlet 2.4仕様以前に準拠したWebアプリケーションで，無効化されたjavax.servlet.http.HttpSessionオブジェクトのgetIdメソッドを呼び出した場合の動作がServlet仕様とアプリケーションサーバとで異なります。それぞれの動作を次に示します。

Servlet仕様

java.lang.IllegalStateException例外をスローする。

アプリケーションサーバ

nullを返す。

(22)　javax.servlet.ServletRequestクラスおよびjavax.servlet.http.HttpServletRequestクラスのメソッドについての注意事項

次の表に示すメソッドで取得した情報をレスポンスに出力する場合は，サニタイズする必要があります。

表5-11　取得した情報をサニタイズする必要があるメソッド

クラス名 | メソッド名
javax.servlet.ServletRequest | getCharacterEncoding()
getContentType()
getInputStream()
getParameter(java.lang.String name)
getParameterMap()
getParameterNames()
getParameterValues(java.lang.String name)
getProtocol()
getReader()
getServerName()
javax.servlet.http.HttpServletRequest | getCookies()
getHeader(java.lang.String name)
getHeaderNames()
getHeaders(java.lang.String name)
getMethod()
getPathInfo()
getPathTranslated()
getQueryString()
getRequestedSessionId()
getRequestURI()
getRequestURL()
getServletPath()

(23)　javax.servlet.ServletRequestクラスのgetLocale(getLocales)メソッドについての注意事項

javax.servlet.ServletRequestクラスのgetLocaleメソッド，またはgetLocalesメソッドで取得できるjava.util.Localeオブジェクトは，HTTPリクエストのAccept-Languageヘッダの値から作成します。

Webコンテナでは，Accept-Languageヘッダの値のロケール（ISO言語コード，ISO国コード，またはバリアント）が英字以外を含むかどうかをチェックします。ロケールが英字以外を含む場合は，不正なロケールと判断して，不正なロケールごとにKDJE39546-Wのメッセージをメッセージログに出力して無視します。

不正なロケールを含むAccept-Languageヘッダを受信した場合は，getLocaleメソッド，またはgetLocalesメソッドは正しいロケールのjava.util.Localeオブジェクトだけを返します。Accept-Languageヘッダに指定されたロケールがすべて不正な場合は，Accept-Languageヘッダがないと見なしてサーバのデフォルトロケールを返します。

(24)　javax.servlet.http.HttpServletRequestインタフェースのgetServerNameメソッドの戻り値

javax.servlet.http.HttpServletRequestインタフェースのgetServerNameメソッドの戻り値は，Hitachi Web ServerやリバースプロキシなどでHostヘッダを書き換えた場合，HTTPクライアントが設定したHostヘッダの値と異なることがあります。

(25)　Servlet 2.4以前のinclude先のサーブレットでのレスポンスヘッダの設定

Servlet 2.4以前では，include先のサーブレットでのレスポンスヘッダの設定はすべて無視される仕様です。ただし，アプリケーションサーバでは，Servlet 2.4を使用した場合でも，getSessionでのレスポンスヘッダの設定は有効になります。

(26)　MIMEマッピングがない静的コンテンツのコンテンツ形式

MIMEマッピングがない静的コンテンツの場合，Content-Typeは付与されません。

5.1.3　Servlet 2.5仕様で追加，変更された仕様についての注意事項

Servlet 2.5仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。Servlet 2.5仕様およびServlet 2.4仕様については，それぞれの仕様書（Servlet 2.5仕様書，Servlet 2.4仕様書）を参照してください。

＜この項の構成＞

(1)　web.xmlのXMLスキーマ変更について

(2)　web.xmlの省略に関する注意事項

(3)　<load-on-startup>要素への空文字列の指定

(4)　<security-constraint>要素でのHTTPメソッドの指定範囲について

(5)　アノテーションの使用

(6)　Webアプリケーションの呼び出し時のHTTPセッションの継続について

(7)　フィルタマッピングでのすべてのサーブレットの指定について

(8)　javax.servlet.ServletRequestインタフェースのsetCharacterEncodingメソッドの呼び出しの無効について

(9)　javax.servlet.http.HttpServletRequestインタフェースのgetRequestURLメソッドの戻り値となるURLの変更について

(10)　javax.servlet.http.HttpSessionインタフェースのgetIdメソッドが呼び出された場合の動作について

(11)　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出しについて

(12)　include先のサーブレットでのレスポンスヘッダの設定について

(1)　web.xmlのXMLスキーマ変更について

アプリケーションサーバでは，Servlet 2.5仕様に従ってweb.xmlのXMLスキーマが変更されています。

(2)　web.xmlの省略に関する注意事項

Servlet 2.5仕様では，web.xmlの省略について記述が追加されています。

アプリケーションサーバでは，WebアプリケーションがJSPおよび静的コンテンツしか含まない場合，web.xmlを省略できます。web.xmlが省略されたWebアプリケーションのバージョンは2.5と見なされます。また，web.xmlを省略した場合，WEB-INFディレクトリを省略できます。

ここではweb.xml省略時の注意事項について説明します。web.xmlの省略については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.4.5　web.xmlを省略したWebアプリケーションに対する操作」を参照してください。

(a)　Webアプリケーションにサーブレットおよびフィルタが含まれている場合のweb.xmlの省略

サーブレット，およびフィルタはweb.xmlにマッピング定義が必要なため，web.xmlを省略すると動作しません。

(b)　Webアプリケーションにリスナが含まれている場合のweb.xmlの省略

次に示すリスナはweb.xmlに定義が必要なため，web.xmlを省略すると動作しません。

javax.servlet.ServletContextListener

javax.servlet.ServletContextAttributeListener

javax.servlet.ServletRequestListener

javax.servlet.ServletRequestAttributeListener

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

ただし，次に示すリスナはweb.xmlに定義しないため，web.xmlを省略しても動作します。

javax.servlet.http.HttpSessionBindingListener

javax.servlet.http.HttpSessionActivationListener

また，タグライブラリでリスナが定義されている場合，web.xmlを省略してもリスナは実行されます。

(c)　実行環境でのWebアプリケーションのプロパティの設定

web.xmlを省略した場合，サーバ管理コマンドおよび属性ファイルを使用したプロパティの設定はできません。

(d)　マッピングの設定

web.xmlを省略した場合でも，拡張子がjspおよびjspxのファイルのマッピング，デフォルトのwelcomeファイル，セッションタイムアウト，およびデフォルトのmime-mappingの設定は有効です。サーブレットのデフォルトマッピングの有効または無効の設定に関係なく，サーブレットのデフォルトマッピングは使用できません。

(e)　フィルタの使用

web.xmlを省略したWebアプリケーションではフィルタを使用できません。そのため，HTTPレスポンス圧縮機能やメモリセッションフェイルオーバ機能など，built-inフィルタが必要な機能は使用できません。

(3)　<load-on-startup>要素への空文字列の指定

Servlet 2.5仕様で定義されたweb.xmlのスキーマでは，<load-on-startup>要素に指定できる値が変更されました。

アプリケーションサーバでは，<load-on-startup>要素に指定できる値はweb.xmlに記述するServlet仕様のバージョン情報に対応したサーブレットに従って制御されます。サーブレットのバージョンごとに<load-on-startup>要素に指定できる値について次の表に示します。

表5-12　<load-on-startup>要素に指定できる値

サーブレットのバージョン | 指定できる値
Servlet 2.5 | 整数，または空文字列。空文字列が指定された場合，<load-on-startup>要素が指定されなかった場合と同様に，サーブレットのロードを行わない。
Servlet 2.4 | 整数。07-60と同様の指定値。

なお，指定できない値を指定した場合，J2EEアプリケーションのインポートに失敗します。

(4)　<security-constraint>要素でのHTTPメソッドの指定範囲について

Servlet 2.5仕様で定義されたweb.xmlのスキーマでは，<security-constraint><web-resource-collection>要素内の<http-method>要素に指定できる内容について変更されました。指定できる内容について次の表に示します。

表5-13　<security-constraint><web-resource-collection>要素内の<http-method>要素に指定できる内容

サーブレットのバージョン | 指定できる内容
Servlet 2.5 | 半角英数字（0-9，A-Z，a-z）および特殊文字（! # $ % & ' * + - . ^ _ ` | ~）を1回以上。
Servlet 2.4 | GET，POST，PUT，DELETE，HEAD，OPTIONS，TRACEのどれか。

<security-constraint><web-resource-collection>要素内の<http-method>要素に指定するのは，リクエストのHTTPメソッドです。

アプリケーションサーバでサポートするリクエストのHTTPメソッドは，web.xmlに記述するServlet仕様のバージョン情報に対応したサーブレットでサポートする内容と同じです。ただし，Servlet 2.5仕様に準拠したWebアプリケーションでサポートするリクエストのHTTPメソッドは，使用するWebサーバによって異なります。アプリケーションサーバでサポートするリクエストのHTTPメソッドについて，Webサーバごとに次に示します。

表5-14　アプリケーションサーバでサポートするリクエストのHTTPメソッド

サーブレットのバージョン | 使用するWebサーバ | 指定できる内容
Servlet 2.5 | Hitachi Web ServerおよびMicrosoft IIS | HTTP1.1で使用可能なメソッドの一部※。
インプロセスHTTPサーバ | HTTP1.1で使用可能なすべてのメソッド。
Servlet 2.4 | Hitachi Web Server，Microsoft IIS，インプロセスHTTPサーバ | GET，POST，PUT，DELETE，HEAD，OPTIONS，TRACEのどれか。

注※　指定できるメソッドの詳細については「付録A.2　リダイレクタが返すエラーステータスコード」を参照してください。

指定できない値を指定した場合，J2EEアプリケーションのインポートに失敗します。

(5)　アノテーションの使用

アプリケーションサーバでは，Servlet 2.5仕様で規定されたアノテーションをサポートします。アノテーションの使用については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「11.　アノテーションの使用」を参照してください。

(6)　Webアプリケーションの呼び出し時のHTTPセッションの継続について

Servlet 2.5仕様では，クロスコンテキストで呼び出されたサーブレットおよびJSP内でセッションを作成した場合，次のどちらの場合もセッションが継続するように記述が追加されています。

関連づけられたコンテキストに直接リクエストが来た場合のクロスコンテキストの呼び出し

ディスパッチ（javax.servlet.RequestDispatcherインタフェースのforwardメソッドおよびincludeメソッド呼び出し）によるクロスコンテキストの呼び出し

しかし，アプリケーションサーバでは，Webアプリケーションの呼び出し時のHTTPセッションの継続はできません。

(7)　フィルタマッピングでのすべてのサーブレットの指定について

Servlet 2.5仕様では，web.xmlの<filter-mapping>要素内の<servlet-name>要素での*（半角アスタリスク）の指定について記述が追加されています。

web.xmlの<filter-mapping>要素内の<servlet-name>要素で*を指定することで，すべてのサーブレットへのリクエストをフィルタ呼び出しの対象にできます。

web.xmlでの定義例を次に示します。

<filter-mapping>
   <filter-name>All Filter</filter-name>
   <servlet-name>*</servlet-name>
</filter-mapping>

この例では，すべてのサーブレットへのリクエストに対してフィルタ名「All Filter」のフィルタが呼び出されます。

注意

Servlet 2.4仕様に準拠したWebアプリケーションではフィルタマッピングで指定する*（半角アスタリスク）に特別な意味はありませんでした。しかし，Servlet 2.5仕様に準拠したWebアプリケーションでは*はすべてのサーブレットを意味します。サーブレット名が*のサーブレットだけを指定する方法はないため注意してください。

アプリケーションサーバでは，web.xmlの<filter-mapping><servlet-name>要素で*（半角アスタリスク）を指定した場合，該当するweb.xmlを含むWebアプリケーションへのすべてのリクエストがフィルタ呼び出しの対象となります。

(8)　javax.servlet.ServletRequestインタフェースのsetCharacterEncodingメソッドの呼び出しの無効について

Servlet 2.5仕様では，javax.servlet.ServletRequestインタフェースのgetReaderメソッドが呼び出されたあと，setCharacterEncodingメソッドの呼び出しが無効になることについて明記されました。

アプリケーションサーバでは，サーブレットのバージョンに関係なく，Servlet 2.5仕様に従います。getReaderメソッド呼び出し後のsetCharacterEncodingメソッドの呼び出しは無効となり，次の内容は変更されません。

getReaderメソッドで取得したBufferedReaderオブジェクトが使用する文字エンコーディング

getCharacterEncodingメソッドの戻り値

07-60以前は，getReaderメソッド呼び出し後のsetCharacterEncodingメソッドの呼び出しによってgetCharacterEncodingメソッドの戻り値が変更されていましたが，08-00では，サーブレットのバージョンに関係なく，変更されません。

(9)　javax.servlet.http.HttpServletRequestインタフェースのgetRequestURLメソッドの戻り値となるURLの変更について

Servlet 2.5仕様では，forward先でjavax.servlet.http.HttpServletRequestインタフェースのgetRequestURLメソッドが呼び出された場合に戻り値となるURLについて，クライアントに指定されたURLのパスではなく，javax.servlet.RequestDispatcherオブジェクトを取得するために使用したパスが反映されることが明記されました。

アプリケーションサーバでは，web.xmlに記述するServlet仕様のバージョン情報に対応したサーブレットに従って，戻り値となるURLを決定します。

Servlet 2.5仕様では，javax.servlet.RequestDispatcherオブジェクトを取得するために呼び出したjavax.servlet.ServletRequestインタフェースのgetRequestDispatcherメソッドの引数に指定したパスが戻り値となります。Servlet 2.4仕様では，リクエストのURLのパスが戻り値となります。

(10)　javax.servlet.http.HttpSessionインタフェースのgetIdメソッドが呼び出された場合の動作について

Servlet 2.5仕様では，無効化されたjavax.servlet.http.HttpSessionオブジェクトのgetIdメソッドが呼び出された場合にjava.lang.IllegalStateException例外がスローされる仕様が削除されました。

アプリケーションサーバでは，無効化されたjavax.servlet.http.HttpSessionオブジェクトのgetIdメソッドが呼び出された場合の戻り値は，web.xmlに記述するServlet仕様のバージョン情報に対応したサーブレットに従って制御されます。

Servlet 2.5仕様の場合はセッションID，Servlet 2.4仕様の場合は07-60と同様にnullが戻り値となります。

(11)　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出しについて

サーブレットのバージョンが異なるWebアプリケーション間でクロスコンテキストを呼び出した場合，呼び出し元と呼び出し先のサーブレットのバージョンによって，呼び出し先の動作が異なるメソッドがあります。サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出しをした場合のクロスコンテキストの呼び出し先の動作について，メソッドごとに表に示します。

表5-15　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出し先の動作（javax.servlet.http.HttpServletRequestインタフェースのgetRequestURLメソッド）

Webアプリケーションのサーブレットのバージョン | クロスコンテキストの呼び出し先の動作 | 参照先
呼び出し元 | 呼び出し先
Servlet 2.5 | Servlet 2.4以前 | Servlet 2.5仕様に従う。 | 5.1.3(9)
Servlet 2.4以前 | Servlet 2.5 | Servlet 2.4仕様に従う。

表5-16　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出し先の動作（無効化されたjavax.servlet.http.HttpSessionオブジェクトのgetIdメソッド）

Webアプリケーションのサーブレットのバージョン | クロスコンテキストの呼び出し先の動作 | 参照先
呼び出し元 | 呼び出し先
Servlet 2.5 | Servlet 2.4以前 | Servlet 2.5仕様に従い，セッションIDを返す。 | 5.1.3(10)
Servlet 2.4以前 | Servlet 2.5 | Servlet 2.4仕様に従い，nullを返す。

(12)　include先のサーブレットでのレスポンスヘッダの設定について

Servlet 2.5仕様では，include先のサーブレットでのレスポンスヘッダの設定について，getSessionの場合だけ設定が有効となります。ただし，アプリケーションサーバでは，Servlet 2.4を使用した場合でも，getSessionでのレスポンスヘッダの設定は有効になります。

5.1.4　Servlet 2.4仕様で追加，変更された仕様についての注意事項

Servlet 2.4仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。Servlet 2.4仕様およびServlet 2.3仕様については，それぞれの仕様書（Servlet 2.4仕様書，Servlet 2.3仕様書）を参照してください。

＜この項の構成＞

(1)　X-Powered-Byヘッダの利用

(2)　java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意

(3)　javax.servlet.SingleThreadModelインタフェースの非推奨化について

(4)　javax.servlet.ServletResponseクラスのsetLocaleメソッドについて

(5)　javax.servlet.UnavailableExceptionについて

(6)　javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて

(7)　javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて

(8)　HTTPステータスコード302のステータスメッセージについて

(9)　サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト

(10)　リスナで例外が発生した場合の制御について

(11)　共通で使用する外部のライブラリ（Extension）について

(12)　サーブレットのバージョンが異なるWebアプリケーション間のクロスコンテキストの使用について

(1)　X-Powered-Byヘッダの利用

Servlet 2.4仕様で追加されたX-Powered-Byヘッダはレスポンスに追加されません。

(2)　java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意

javax.servlet.ServletRequestクラス，およびjavax.servlet.ServletContextクラスのgetRequestDispatcherメソッドで取得したjavax.servlet.RequestDispatcherクラスのforwardメソッドを実行すると，リクエストオブジェクトには次のキーの属性が追加されます。ただし，javax.servlet.ServletContextクラスのgetNamedDispatcherメソッドで取得したRequestDispatcherオブジェクトのforwardメソッドでは追加されません。

javax.servlet.forward.request_uri

javax.servlet.forward.context_path

javax.servlet.forward.servlet_path

javax.servlet.forward.path_info※1

javax.servlet.forward.query_string※2

注※1

Webコンテナが受信したHTTPリクエストが追加のパス情報を含まない場合，この属性は追加されません。

注※2

Webコンテナが受信したHTTPリクエストのリクエストURIがクエリ文字列を含まない場合，この属性は追加されません。　

これらの属性は，Webコンテナによって追加されます。javax.servlet.ServletRequestAttributeListenerに属性追加のイベントは通知されません。追加される属性の値については，Servlet 2.4仕様書を参照してください。

(3)　javax.servlet.SingleThreadModelインタフェースの非推奨化について

javax.servlet.SingleThreadModelインタフェースは，Servlet 2.4仕様から非推奨となっています。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，javax.servlet.SingleThreadModelインタフェースを使用できます。ただし，Servlet 2.4仕様を参照し，非推奨となった理由に注意して使用してください。

(4)　javax.servlet.ServletResponseクラスのsetLocaleメソッドについて

javax.servlet.ServletResponseクラスのsetLocaleメソッドによって，HTTPレスポンスのContent-Typeヘッダに文字エンコーディングが設定されます。Servlet 2.4仕様では，設定される文字エンコーディングが有効となる条件が変更されています。

アプリケーションサーバで有効となる条件を，Servlet 2.4以降とServlet 2.3に分けて示します。

Servlet 2.4以降

次のすべての条件を満たす必要があります。

HTTPレスポンスがコミットされる前であること。

getWriterメソッドの呼び出し前であること。

setCharacterEncodingメソッドの呼び出し前であること。

setContentTypeメソッドによって文字エンコーディングが設定されていないこと。

条件に反する場合，setLocalメソッドは，ServletResponseクラスにロケールを設定するだけで，レスポンスの文字エンコーディングは設定しません。

Servlet 2.3

次の条件を満たす必要があります。

HTTPレスポンスがコミットされる前であること※。

注※

レスポンスがコミットされる前の場合，getWriterメソッドの呼び出し前後に関係なく，文字エンコーディングが設定されます。

レスポンスがコミットされる前の場合，setContentTypeメソッドで文字エンコーディングが設定されているかどうかに関係なく，文字エンコーディングが設定されます。

(5)　javax.servlet.UnavailableExceptionについて

javax.servlet.UnavailableException例外は永久的に利用できないことを示します。javax.servlet.UnavailableException例外をthrowしたサーブレット，JSPにアクセスした場合のHTTPレスポンスコードの仕様が，Servlet 2.4仕様で追記されています。

アプリケーションサーバでこの例外をthrowしたサーブレット，JSPにアクセスした場合のHTTPレスポンスコードを，Servlet 2.4以降とServlet 2.3に分けて示します。

Servlet 2.4以降

404エラーとなります。

Servlet 2.3

503エラーとなります。

(6)　javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドを呼び出すタイミングが，Servlet 2.4仕様で変更されています。

アプリケーションサーバでこのメソッドを呼び出す場合のタイミングを，Servlet 2.4以降とServlet 2.3に分けて示します。

Servlet 2.4以降

セッションが破棄される前に実行されます。

Servlet 2.3

セッションが破棄されたあとに実行されます。

なお，セッションタイムアウトが無効のとき，次の順序でセッションに関するリスナが通知されます。Webアプリケーションのバージョンごとに，順序を示します。

Servlet 2.4以降の場合

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyed()メソッド

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueUnbound()メソッド

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeRemoved()メソッド

Servlet 2.3の場合

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueUnbound()メソッド

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeRemoved()メソッド

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyed()メソッド

(7)　javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドを使用する条件が，Servlet 2.4仕様で変更されています。

アプリケーションサーバでこのメソッドを正常に実行するには，次の条件をすべて満たす必要があります。

実行するタイミングが，レスポンスがコミットされる前であること。

引数に適切なURLを指定すること。

この条件を満たさない場合のエラー制御を，Servlet 2.4以降とServlet 2.3に分けて示します。

Servlet 2.4以降

条件を満たさない場合は，java.lang.IllegalStateException例外がthrowされます。

Servlet 2.3

レスポンスがすでにコミットされている場合
java.lang.IllegalStateException例外がthrowされます。

引数に不正なURLが指定された場合
レスポンスコードが404になります。

(8)　HTTPステータスコード302のステータスメッセージについて

Servlet 2.4仕様では，HTTPステータスコードの302を示す定数として，javax.servlet.http.HttpServletResponseクラスに「SC_FOUND」が追加されています。また，下位互換性のため，Servlet 2.3仕様で定義されていた「SC_MOVED_TEMPORARILY」はそのまま使用できます。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，「SC_FOUND」および「SC_MOVED_TEMPORARILY」を使用できます。

なお，ステータスメッセージの「Found」がWebコンテナで使用されるのは，次の場合です。

Webアプリケーションで302を返す場合

デフォルトエラーページが出力された場合（HTML本文中）

(9)　サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト

Servlet 2.4仕様では，サービスメソッド実行中のjavax.servlet.http.HttpSessionクラスでのタイムアウトについて仕様が追記されています。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，Webアプリケーションでのリクエスト処理を実行している間は，HttpSessionはタイムアウトされません。

また，Webアプリケーション単位またはURLグループ単位の同時実行スレッド数制御によって，リクエストが実行待ち状態の場合も，HttpSessionはタイムアウトされません。ただし，Webコンテナ単位での同時実行スレッド数制御による実行待ち状態の場合は，HttpSessionはタイムアウトされるので注意してください。

(10)　リスナで例外が発生した場合の制御について

Servlet 2.4仕様では，リスナで例外が発生した場合についての記述が追加されています。

アプリケーションサーバを使用している場合で，リスナで例外が発生した場合の制御を，Servlet 2.4以降とServlet 2.3に分けて示します。

Servlet 2.4以降

該当するイベントを処理するリスナが複数あっても，例外を発生したリスナ以降のリスナは，実行されません。

Servlet 2.3

発生した例外はWebコンテナによってcatchされます。複数のリスナが登録されている場合，例外がcatchされたあとに，正常時と同様に登録されているリスナが順次実行されます。

(11)　共通で使用する外部のライブラリ（Extension）について

Webアプリケーションで外部のライブラリを使用する場合に記載するMANIFESTファイルの扱いについて，Servlet 2.4仕様では記述が変更されています。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，MANIFESTファイルの存在，およびMANIFESTファイルの内容は確認されません。

(12)　サーブレットのバージョンが異なるWebアプリケーション間のクロスコンテキストの使用について

サーブレットのバージョンが異なるWebアプリケーション間で，クロスコンテキストを使用したリクエストをforwardしたあとの動作，およびincludeしたあとの動作を，次の表に示します。

表5-17　forward後およびinclude後の動作

項番
Servlet 2.4仕様の追加機能／Webアプリケーションのバージョンで違いのある機能
リクエストのforward先／include先の動作

2.4から2.3にforward／include※1
2.3から2.4にforward／include※2

1
forward時またはinclude時のフィルタ適用
forward後／include後のサーブレット，またはJSPから，さらにforwardまたはincludeする場合，Servlet 2.4仕様が適用され，フィルタは使用できます。
forward後／include後のサーブレット，またはJSPからさらにforwardまたはincludeする場合，Servlet 2.3仕様が適用され，フィルタは使用できません。

2
javax.servlet.ServletRequestAttributeListenerの呼び出し
Servlet 2.4仕様が適用され，リクエストへの属性追加時にリスナが使用できます。
Servlet 2.3仕様が適用され，リクエストへの属性追加時にリスナは使用できません。

3
JSPのコンパイル
Servlet 2.3に対応したアプリケーションとしてJSPコンパイルを実行します。
Servlet 2.4に対応したアプリケーションとしてJSPコンパイルを実行します。

4
javax.servlet.ServletResponseクラスのsetLocaleメソッド
Servlet 2.4仕様が適用され，次に示す条件をすべて満たす場合，文字エンコーディングの設定が有効となります。

レスポンスがコミットされる前であること。

getWriterメソッドの呼び出し前であること。

setCharacterEncodingメソッドの呼び出し前であること。

serContentTypeメソッドで文字エンコーディングが設定されていないこと。

Servlet 2.3仕様が適用され，レスポンスがコミットされる前である場合，文字エンコーディングの設定が有効となります。

5
永久的に利用できないことを示すjavax.servlet.UnavailableException例外をthrowしたサーブレット，JSPへのディスパッチ
Servlet 2.3仕様が適用され，ステータス503を設定したレスポンスが返されます。
Servlet 2.4仕様が適用され，ステータス404を設定したレスポンスが返されます。

6
javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッド
Servlet 2.4仕様が適用され，HTTPセッションが破棄される前に実行されます。
Servlet 2.3仕様が適用され，HTTPセッションが破棄されたあとに実行されます。

7
javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドに不正なURLを指定
Servlet 2.4仕様の仕様が適用され，java.lang.IllegalStateException例外がthrowされます。
Servlet 2.3の仕様が適用され，ステータス404がレスポンスに設定されます。

8
使用するリスナ定義
次に示すリスナの場合，forward先またはinclude先のアプリケーションで定義されたリスナが動作します。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，forwardまたはincludeを呼び出したアプリケーションで定義されたリスナが動作します。

javax.servlet.ServletRequestAttributeListener

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

次に示すリスナの場合，forward先またはinclude先のアプリケーションで定義されたリスナが動作します。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，forwardまたはincludeを呼び出したアプリケーションで定義されたリスナが動作します。

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

9
該当するイベントを処理するリスナがweb.xmlで複数定義されていた場合に，forwardもしくはinclude先のアプリケーション内でリスナが例外を発生したときの動作
次に示すリスナの場合，Servlet 2.4仕様が適用され，例外を発生したリスナ以降のリスナは実行されません。

javax.servlet.ServletRequestAttributeListener

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

次に示すリスナの場合，Servlet 2.3仕様が適用され，発生した例外をキャッチし，その後正常時と同様に登録されている次のリスナへ処理が移ります。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，Servlet 2.4仕様が適用され，例外を発生したリスナ以降のリスナは実行されません。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，Servlet 2.3仕様が適用され，発生した例外をキャッチし，その後正常時と同様に登録されている次のリスナへ処理が移ります。

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

10
web.xmlで指定されたエラーページを表示したレスポンスのステータスコード
Servlet 2.4仕様が適用され，エラー発生時のステータスコードのレスポンスが返されます。
Servlet 2.3仕様が適用され，ステータス200のレスポンスが返されます。

注※1

Servlet 2.4に対応したアプリケーションからServlet 2.3に対応したアプリケーションにforwardまたはincludeした場合を表します。

注※2

Servlet 2.3に対応したアプリケーションからServlet 2.4に対応したアプリケーションにforwardまたはincludeした場合を表します。

5.1.5　JSP実装時の注意事項

JSPを実装するときの注意事項を示します。

＜この項の構成＞

(1)　includeディレクティブ利用時の注意

(2)　タグライブラリ利用時の注意

(3)　<%=%>タグ記述時の注意

(4)　URL指定とマッピング定義によるアクセスについて

(5)　<jsp:plugin>タグ利用時の注意

(6)　JSPドキュメント内のversion属性について

(7)　taglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングについて

(8)　JSPで動的なページをインクルードする場合の注意

(9)　TLDファイルでのDOCTYPE宣言への内部サブセットの記述について

(10)　JSPドキュメントおよびXML形式のタグファイルでの外部サブセットURIの指定について

(11)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.jsp.jspException属性の値について

(12)　TLDファイルのバージョンに関する注意事項

(13)　JSPでサポートしている文字エンコーディングについて

(1)　includeディレクティブ利用時の注意

JSPファイルのincludeディレクティブでファイルをインクルードする場合，インクルード元となるJSPファイルでエンコーディングを指定してください。

JSPでHTMLなどの静的ファイルをインクルードする場合は，includeアクションを使用しないで，includeディレクティブを使用してください。includeアクションはJSPやサーブレットなど動的なページをインクルードする場合に使用してください。

(2)　タグライブラリ利用時の注意

タグライブラリを作成する場合には，タグライブラリを記述したクラスファイルの先頭にpackage文で必ずパッケージ名を付けるようにしてください。パッケージ名が付いていない場合，そのタグライブラリは正常に動作しません。

タグライブラリ・ディスクリプタ（TLDファイル）で，<variable>タグ内の<scope>タグ要素には，NESTED，AT_BEGIN，AT_ENDのどれかを指定してください。これら以外の値を指定した場合には，デフォルトのNESTEDが仮定されて実行されます。

タグライブラリのタグハンドラを実装する場合には，doStartTagメソッド，doAfterBodyメソッド，およびdoEndTagメソッドが仕様で規定されている戻り値を返すようにしてください。仕様で規定されている戻り値以外の値を返した場合，デフォルトの戻り値を仮定して動作します。デフォルトの戻り値とは，javax.servlet.jsp.tagext.TagSupportまたはjavax.servlet.jsp.tagext.BodyTagSupportクラスの各メソッドがオーバーライドしない場合に返す戻り値です。例えば，BodyTagインタフェースを実装したクラス（またはBodyTagSupportクラスを継承したクラス）で，doStartTagメソッドがEVAL_PAGEを戻り値として返した場合，デフォルトの戻り値であるEVAL_BODY_BUFFEREDが返されたと仮定して動作します。

Webアプリケーションのバージョンが2.3の場合で，かつタグライブラリのタグハンドラで属性の指定を持つカスタムタグを実装した場合，JSPのカスタムタグで同じ属性を複数指定すると，該当するタグハンドラのsetterメソッドが指定された回数呼び出されます。通常指定された値を上書きするようなsetterメソッドを実装している場合には，後ろに記述された属性の値が有効になります。

(3)　<%=%>タグ記述時の注意

JSPで<%= %>タグを使用する場合は，その中に「;（セミコロン）」が入らないようにしてください。セミコロンが入っている場合，JSPコンパイルでエラーとなります。

(4)　URL指定とマッピング定義によるアクセスについて

直接JSPファイルのパスをURL指定してアクセスする場合とマッピング定義されたURLでアクセスする場合には，それぞれ別々のインスタンスが生成されます。したがって，jspInitメソッドがそれぞれのインスタンスで実行されることに注意してください。なお，<load-on-startup>タグで起動時にロードされるように指定した場合，起動時にロードされるインスタンスは，マッピング定義されたURLでアクセスするものと同じになります。

(5)　<jsp:plugin>タグ利用時の注意

JSPページで，pluginアクションまたはJSPドキュメントでの<jsp:plugin>タグのcode属性は必ず指定してください。省略した場合はコンパイルエラーとなります。

(6)　JSPドキュメント内のversion属性について

JSPドキュメントでは，<jsp:root>タグの属性として，使用するバージョン情報を記述できます。しかし，JSPで使用できる機能範囲は，該当するJSPを含むWebアプリケーションのweb.xmlのバージョン情報に従います。

例えば，<jsp:root version="1.2">と記述しているJSPドキュメントであっても，JSP 2.0仕様で追加されたJSP ELを使用できます。

(7)　taglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングについて

taglibディレクティブのuri属性で指定するURIは，JSP仕様によって次に示すどれかの方法でマッピングします。同じURIを異なるTLDファイルにマッピングすることはできません。URIが重複した場合は，次に示す番号順を優先順位とし，優先順位の高いマッピングが有効になります。

JSTLおよびJSFのURIの暗黙マッピング（Servlet 2.5仕様以降のWebアプリケーション）

web.xmlの<taglib>要素の<taglib-uri>要素で指定したURIと，<taglib-location>要素で指定したTLDファイルのマッピング

Webアプリケーション内のTLDファイルの<uri>要素で指定したURIと，そのTLDファイル自身のマッピング

ライブラリJAR（cjjspcコマンドの場合は-classpathオプションで指定したJARファイル）の/META-INFディレクトリ以下に格納されたTLDファイルの<uri>要素で指定したURIと，そのTLDファイル自身のマッピング

次に，2.～4.までのURIとTLDファイルのマッピングする場合のディレクトリ構成とファイルの記述例を示します。

(a)　web.xmlの<taglib>要素の<taglib-uri>要素で指定したURIと，<taglib-location>要素で指定したTLDファイルのマッピング（2.の場合）

2.の場合のディレクトリ構成とファイルの記述例について説明します。

2.の場合，TLDファイルはWebアプリケーション内に格納されています。2.の場合のディレクトリ構成の例を次に示します。

図5-3　ディレクトリ構成（2.の場合）

このディレクトリ構成の場合のtaglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングを次の図に示します。

図5-4　URIとTLDファイルのマッピング（2.の場合）

図中のデータの対応について説明します。

タグのプリフィックスにtaglibディレクティブで指定したプリフィックスを指定します。

TLDファイルの<name>要素で指定した値を，JSPファイルのプリフィックスと対応づけます。

web.xmlの<taglib-uri>要素で，JSPファイルのtaglibディレクティブで指定したuriを指定します。

web.xmlの<taglib-location>要素で，マッピングするTLDファイル名を指定します。

(b)　TLDファイルの<uri>要素で指定したURIと，そのTLDファイル自身をマッピングする場合

3.または4の場合のディレクトリ構成とファイルの記述例について説明します。

3.の場合，TLDファイルはWebアプリケーション内に格納されています。3.の場合のディレクトリ構成の例を次に示します。

図5-5　ディレクトリ構成（3.の場合）

4.の場合，TLDファイルはライブラリJARの/META-INFディレクトリ以下に格納されています。4.の場合のディレクトリ構成の例を次に示します。

図5-6　ディレクトリ構成（4.の場合）

3.または4.の場合のディレクトリ構成でのtaglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングを次の図に示します。

図5-7　TLDファイルの<uri>要素で指定したURIと，そのTLDファイル自身のマッピング（3.または4.の場合）

図中のデータの対応について説明します。

タグのプリフィックスにtaglibディレクティブで指定したプリフィックスを指定します。

TLDファイルの<name>要素で指定した値を，JSPファイルのプリフィックスと対応づけます。

TLDファイルの<url>要素で，JSPファイルのtaglibディレクティブで指定したuriを指定します。

URIの重複が検出された場合，次のメッセージがWebアプリケーション単位で出力され，該当するマッピングは無視されます。

表5-18　URI重複時に出力されるメッセージと出力条件

メッセージID
出力条件

KDJE39314-W

J2EEサーバモード，サーブレットエンジンモード，またはcjjspcコマンドの場合

TLDファイルで記述した<uri>要素の内容が，web.xmlの<taglib-uri>要素の内容，またはほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

cjjsp2javaコマンドの場合

TLDファイルで記述した<uri>要素の内容が，コマンド引数-taglibに指定したuriの内容，またはほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

KDJE39315-W
TLDファイルで記述した<uri>要素の内容が，ほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

KDJE39316-W
web.xmlに指定した<taglib>要素の内容と重複する<taglib-uri>要素を持つほかの<taglib>要素が指定されている場合に出力されます。

KDJE39325-W
web.xmlの<taglib-uri>要素の内容，またはほかのTLDファイルで記述した<uri>要素の内容が，Java EE仕様のタグライブラリ（JSTL, JSF）のURIと重複したときに出力されます。

KDJE39326-W
ライブラリJAR（cjjspcコマンドの場合は-classpathオプションで指定したJARファイル）に格納されたTLDファイルの<uri>要素の内容が，web.xmlの<taglib-uri>要素の内容，またはほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

(8)　JSPで動的なページをインクルードする場合の注意

JSPで，JSPやサーブレットなどの動的なページをインクルードする場合は，javax.servlet.RequestDispatcherのincludeメソッドを使用しないで，includeアクションを使用してください。

(9)　TLDファイルでのDOCTYPE宣言への内部サブセットの記述について

TLDファイル（タグライブラリ・ディスクリプタ）で，DOCTYPE宣言に内部サブセットを記述しないでください。

タグの要素拡張またはタグライブラリの要素拡張でxsi:schemaLocation属性に指定するURIは絶対URIだけ指定できます。タグの要素拡張またはタグライブラリの要素拡張以外の目的で，Java EE仕様で定められたDTD／XMLスキーマ以外を参照しないでください。

(10)　JSPドキュメントおよびXML形式のタグファイルでの外部サブセットURIの指定について

DOCTYPE宣言を指定する場合，外部サブセットURIには絶対URIだけ指定できます。また，XML1.0仕様で定義された外部エンティティ参照をする場合，外部エンティティ宣言に指定するURIには絶対URIだけ指定できます。相対URIを指定した外部サブセットおよび外部エンティティは参照できません。

(11)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.jsp.jspException属性の値について

JSPファイルで例外をスローした場合，pageディレクティブのerrorPage属性でエラーページを指定しているとき，例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.jsp.jspException属性に設定されるとJSP仕様に記述されていますが，pageディレクティブのerrorPage属性でエラーページを指定しない場合も設定されます。

(12)　TLDファイルのバージョンに関する注意事項

07-00以降のバージョンでは，JSPトランスレーション時にTLDファイルのバージョン（TLDファイルが対応するJSPのバージョン）をチェックします。そのため，TLDファイルのバージョンが，Webアプリケーションのバージョンに対応しているJSPおよびTLDファイルのバージョンより上位のJSPの場合，JSPトランスレーションでエラーになります。また，JSP 1.2，およびJSP 2.0仕様以降では，TLDファイルにスキーマ言語を定義する必要があります。

TLDファイルのバージョンは，TLDファイルに記述されたスキーマ言語から判定します。ただし，スキーマ言語が定義されていない場合は，Webアプリケーションのバージョンから判定します。

TLDファイルにスキーマ言語を定義していない場合のTLDファイルのバージョンを次の表に示します。

表5-19　スキーマ言語未定義時のTLDファイルのバージョン

Webアプリケーションのバージョン | TLDファイルのバージョン
2.2 | 1.1
2.3 | 1.2
2.4 | 2.0
2.5 | 2.1

(13)　JSPでサポートしている文字エンコーディングについて

ここでは，JSPファイル，およびタグファイルで使用できる文字エンコーディングについて説明します。

(a)　JSPページの場合

JSPページで使用できる文字エンコーディングと，文字エンコーディングの指定方法について次に示します。

JSPページで使用できる文字エンコーディング
JavaVMがサポートしている文字エンコーディングが使用できます。JavaVMがサポートしている文字エンコーディングについては，JDKのドキュメントを参照してください。
ただし，UTF-16などの英数字が複数バイトで表現される文字エンコーディングについては，次の二つの条件を満たしている必要があります。

Servlet 2.4/JSP 2.0仕様以降に準拠したWebアプリケーションである。

JSPファイルの先頭にBOMを付加している。

文字エンコーディングの指定方法
JSPページに使用する文字エンコーディングは，次に示す方法から一つ以上の方法を選択して指定できます。

JSPページの先頭にBOMを付加する（Servlet 2.5/JSP 2.1仕様以降に準拠したWebアプリケーションの場合）。

web.xmlの<jsp-property-group>要素内の<page-encoding>要素に指定する（Servlet 2.4/JSP 2.0仕様以降に準拠したWebアプリケーションの場合）。

pageディレクティブのpageEncoding属性に指定する（Servlet 2.3/JSP 1.2仕様以降に準拠したWebアプリケーションの場合）。

pageディレクティブのcontentType属性に指定する。

指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名になります。
なお，指定する文字エンコーディングと，JSPページで使用する文字エンコーディングは，必ず一致するようにしてください。

(b)　JSPドキュメントの場合（Servlet 2.4仕様以降に準拠したWebアプリケーションの場合）

Servlet 2.4仕様以降に準拠したWebアプリケーション内のJSPドキュメントで使用できる文字エンコーディングと，使用する文字エンコーディングの指定方法について次に示します。

JSPドキュメントで使用できる文字エンコーディング
Cosminexus XML Processorがサポートしている文字エンコーディング※が使用できます。
ただし，拡張子がjspxでないJSPドキュメントについては，web.xmlの<jsp-property-group>要素内の<is-xml>要素が指定されていない場合，JSPドキュメントの文字エンコーディングにISO-10646-UCS-4は使用できません。
また，UTF-16などの英数字が複数バイトで表現される文字エンコーディングについては，次の二つの条件を満たしている必要があります。

JSPドキュメントの先頭にBOMを付加している

ISO-10646-UCS-2を使用している場合は，ビッグエンディアンのISO-10646-UCS-2を使用している

文字エンコーディングの指定方法
JSPドキュメントに使用する文字エンコーディングは，XML宣言のencoding属性に指定します。指定できる文字列は，Cosminexus XML Processorがサポートしている文字エンコーディング※です。
ただし，拡張子がjspxでないJSPドキュメントについては，web.xmlの<jsp-property-group>要素内の<is-xml>要素が指定されていない場合，次に示す方法のどれか一つ以上の方法で使用する文字エンコーディングを指定します。

XML宣言のencoding属性に指定する。

web.xmlの<jsp-property-group>要素内の<page-encoding>要素に指定する。

pageディレクティブのpageEncoding属性に指定する。

指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名になります。
なお，指定する文字エンコーディングと，JSPドキュメントで使用する文字エンコーディングは，必ず一致するようにしてください。

注※　Cosminexus XML Processorがサポートしている文字エンコーディングについては，マニュアル「Cosminexus XML Processor ユーザーズガイド」の「1.3.2　処理できる文字コード」を参照してください。

(c)　JSPドキュメントの場合（Servlet 2.3仕様に準拠したWebアプリケーションの場合）

Servlet 2.3仕様に準拠したWebアプリケーション内のJSPドキュメントで使用できる文字エンコーディングと，使用する文字エンコーディングの指定方法について次に示します。

JSPドキュメントで使用できる文字エンコーディング
Cosminexus XML Processorがサポートしている文字エンコーディングが使用できます。Cosminexus XML Processorがサポートしている文字エンコーディングについては，マニュアル「Cosminexus XML Processor ユーザーズガイド」の「1.3.2　処理できる文字コード」を参照してください。
ただし，UTF-16などの英数字が複数バイトで表現される文字エンコーディングは使用できません。

文字エンコーディングの指定方法
JSPドキュメントに使用する文字エンコーディングは，次に示す方法の両方またはどちらかを選択して指定できます。

XML宣言のencoding属性に指定する。

pageディレクティブのpageEncoding属性に指定する。

指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名になります。
なお，指定する文字エンコーディングと，JSPドキュメントで使用する文字エンコーディングは，必ず一致するようにしてください。

(d)　標準シンタックスのタグファイルの場合

標準シンタックスのタグファイルで使用できる文字エンコーディングと，使用する文字エンコーディングの指定方法について次に示します。

タグファイルで使用できる文字エンコーディング
JavaVMがサポートしている文字エンコーディングが使用できます。JavaVMがサポートしている文字エンコーディングについては，JDKのドキュメントを参照してください。
ただし，UTF-16などの英数字が複数バイトで表現される文字エンコーディングについては，タグファイルの先頭にBOMを付加する必要があります。

文字エンコーディングの指定方法
タグファイルに使用する文字エンコーディングは，次に示す方法の両方またはどちらかを選択して指定できます。

タグファイルの先頭にBOMを付加する（Servlet 2.5/JSP 2.1仕様以降に準拠したWebアプリケーションの場合）。

tagディレクティブのpageEncoding属性に指定する（Servlet 2.4/JSP 2.0仕様以降に準拠したWebアプリケーションの場合）。

指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名になります。
なお，指定する文字エンコーディングとタグファイルで使用する文字エンコーディングは，必ず一致するようにしてください。

(e)　XMLシンタックスのタグファイルの場合

XMLシンタックスのタグファイルで使用できる文字エンコーディングと，使用する文字エンコーディングの指定方法を示します。

タグファイルで使用できる文字エンコーディング
Cosminexus XML Processorがサポートしている文字エンコーディング※が使用できます。

文字エンコーディングの指定方法
タグファイルに使用する文字エンコーディングは，XML1.0仕様に従って指定してください。指定できる文字列は，Cosminexus XML Processorがサポートしている文字エンコーディング※です。
なお，指定する文字エンコーディングとタグファイルで使用する文字エンコーディングは，必ず一致するようにしてください。

注※　Cosminexus XML Processorがサポートしている文字エンコーディングについては，マニュアル「Cosminexus XML Processor ユーザーズガイド」の「1.3.2　処理できる文字コード」を参照してください。

(f)　デフォルトの文字エンコーディング

JSPファイル，またはタグファイルに文字エンコーディングを明示的に指定しない場合，デフォルトの文字エンコーディングでJSPを処理します。

なお，この場合も，デフォルトの文字エンコーディングと，タグファイルで使用する文字エンコーディングは，必ず一致するようにしてください。デフォルトの文字エンコーディングについて，ServletおよびJSPの仕様ごとに次の表に示します。

表5-20　デフォルトの文字エンコーディング

仕様 | JSPページ | JSPドキュメント | 標準シンタックスのタグファイル | XMLシンタックスのタグファイル
Servlet 2.2/ JSP1.1 | ISO-8859-1 | ISO-8859-1 | － | －
Servlet 2.3/ JSP 1.2 | ISO-8859-1 | ISO-8859-1 | － | －
Servlet 2.4/ JSP 2.0 | ISO-8859-1 | UTF-8 | ISO-8859-1 | UTF-8
Servlet 2.5/ JSP 2.1 | ISO-8859-1 | UTF-8 | ISO-8859-1 | UTF-8

（凡例）－：該当しない

デフォルトの文字エンコーディングは，デフォルトの文字エンコーディング設定機能を使用しても設定できます。詳細については，「2.6　デフォルトの文字エンコーディング設定機能」を参照してください。

5.1.6　JSP 2.1仕様で追加，変更された仕様についての注意事項

JSP 2.1仕様で追加，変更された仕様を，アプリケーションサーバ上で利用するときの注意事項を示します。JSP 2.1仕様およびJSP 2.0仕様については，それぞれの仕様書（JSP 2.1仕様書，JSP 2.0仕様書）を参照してください。

＜この項の構成＞

(1)　EL2.1

(2)　不要なホワイトスペースの削除機能

(3)　タグハンドラに一意の識別子を設定する機能

(4)　JSPのAPIの追加

(5)　アノテーションの使用

(6)　タグファイルのバージョンの決定方法

(7)　タグの属性に指定できる要素について

(8)　エラーページの参照

(9)　拡張子以外同じ名前のタグファイルの扱い

(10)　APIの仕様変更

(11)　JSPページおよびタグファイルの文字エンコーディングの設定方法

(12)　TLDファイルとURIのマッピングについて

(13)　ELのエスケープシーケンス

(14)　ELでのEnum型に対する処理の変更

(15)　ELでの<，>，lt，gt演算子の処理の変更

(16)　ELのAPIの変更

(1)　EL2.1

JSP 2.1仕様のELは，JSP 2.0仕様のELと，JSF1.1仕様のELが統合されたELです。

EL2.1の仕様としてELの文法やAPIが定めてあり，JSP 2.1仕様やJSF1.2仕様で定義される暗黙オブジェクトなどの変数は，ELのAPIを通して使用できます。

次に示すJSP 2.1仕様のELに関する機能の追加および仕様変更について，以降で説明します。

#{}の書式のEL

TLDへの要素追加

下位互換性のオプション追加

(a)　#{}の書式のEL

JSP 2.0仕様である${}の書式のELに加え，JSF1.1仕様のELである#{}の書式のELをJSP 2.1仕様の機能として記述できます。

#{}の書式のELの評価のタイミングについて

#{}の書式のELはJSP出力時に評価されません。

Webコンテナによって，ELの評価結果の値ではなくELのオブジェクトであるjavax.el.ValueExpressionまたはjavax.el.MethodExpressionがタグハンドラに渡されます。渡されたオブジェクトのメソッドが，タグハンドラの実装によって任意のタイミングで評価されます。

(b)　TLDへの要素追加

JSP 2.1仕様では，#{}の書式を期待するタグの属性であるかどうかを示すため，TLDファイルの<attribute>要素内に次に示す要素が追加されました。

<deferred-value>要素

<deferred-value>要素内の<type>要素

<deferred-method>要素

<deferred-method>要素内の<method-signature>要素

また，タグファイルのattributeディレクティブにもここに示したTLDの要素に対応する属性が追加されました。

(c)　下位互換性のオプション追加

JSP 2.1仕様では，EL2.1仕様で#{}の書式が追加されたことに伴い，次の個所に#{}の書式のELを記述するとトランスレーションエラーが発生します。

JSPのファイルまたはタグファイルのテンプレートテキスト

遅延評価でないカスタムタグの属性値

アプリケーションサーバでは，次に示す要素または属性の値にtrueと指定した場合，テンプレートテキストまたは遅延評価でないカスタムタグの属性値に#{}の書式のELがあってもトランスレーションエラーは発生しません。#{}はそのまま文字列として出力されます。

web.xmlの<web-app><jsp-config><jsp-property-group>要素内の<deferred-syntax-allowed-as-literal>要素

page，tagディレクティブのdeferredSyntaxAllowedAsLiteral属性

web.xmlでの設定とpage，tagディレクティブでの設定を組み合わせた場合，#{}のELに対してトランスレーションエラーが発生するかどうかを次の表に示します。

表5-21　web.xmlでの設定とpage，tagディレクティブでの設定を組み合わせた場合のトランスレーションエラーの発生有無

web.xmlの<deferred-syntax-allowed-as-literal>要素 | page，tagディレクティブのdeferredSyntaxAllowedAsLiteral属性
true | false | 指定なし
true | ○ | × | ○
false | ○ | × | ×
指定なし | ○ | × | ×

（凡例）

○：トランスレーションエラーは発生しないで#{}のELがそのまま出力される

×：トランスレーションエラーが発生する

注　web.xmlでの設定よりpage，tagディレクティブでの設定が優先されます。

(2)　不要なホワイトスペースの削除機能

JSP 2.1仕様では，JSPのテンプレートテキストに含まれる不要なホワイトスペースを削除する機能が追加されました。アプリケーションサーバでは，JSP 2.1仕様に従ってこの機能をサポートします。

次に示す要素または属性の値にtrueと指定した場合，JSPの出力時にホワイトスペースだけのテンプレートテキストは削除されます。

web.xmlの<web-app><jsp-config><jsp-property-group>要素内の<trim-directive-whitespaces>要素

page，tagディレクティブのtrimDirectiveWhitespaces属性

ただし，ホワイトスペースではないテンプレートテキストと連続しているホワイトスペースは削除されません。

表5-22　web.xmlでの設定とpage，tagディレクティブでの設定を組み合わせた場合のホワイトスペースの削除機能の有効／無効

web.xmlの<trim-directive-whitespaces>要素 | page，tagディレクティブのtrimDirectiveWhitespaces属性
true | false | 指定なし
true | ○ | × | ○
false | ○ | × | ×
指定なし | ○ | × | ×

（凡例）

○：ホワイトスペースの削除機能が有効になる

×：ホワイトスペースの削除機能が無効になる

注　web.xmlでの設定よりpage，tagディレクティブでの設定が優先されます。

なお，JSPドキュメントのpageディレクティブ，またはXMLシンタックスのtagディレクティブにtrimDirectiveWhitespaces属性を設定した場合，設定値によって次のように処理されます。

設定値がtrueまたはfalseの場合，trimDirectiveWhitespaces属性の設定は無視され，正常に処理されます。

設定値がtrueまたはfalse以外の不正値を指定した場合，トランスレーションエラーとなります。

ホワイトスペースの削除例

次の図に，JSP要素の間に，ホワイトスペースだけのテンプレートテキストが存在する例を示します。

図5-8　ホワイトスペースだけのテンプレートテキストが存在する例

1～4行目のtaglibディレクティブは出力しないため無視し，1行目の復帰改行，2行目の復帰改行，および３行目の半角スペースから復帰改行がホワイトスペースだけのテンプレートテキストとなります。

JSPページの4行目の復帰改行は，ホワイトスペースではないテンプレートテキストと連続しているホワイトスペースであるため削除されません。そのため，ホワイトスペースの削除機能が有効な場合，4行目の復帰改行から[EOF]までが出力されます。

(3)　タグハンドラに一意の識別子を設定する機能

JSP 2.1仕様では，トランスレーション単位（JSPとincludeディレクティブでインクルードされるファイル）ごとに一意である識別子をタグハンドラに設定する機能が追加されました。この機能は，JspIdConsumerインタフェースをタグハンドラに実装することで使用できます。JspIdConsumerインタフェースのパッケージ名はjavax.servlet.jsp.tagextです。

Webコンテナは，JSPの実行時にこのインタフェースを実装したタグハンドラに対して，インタフェースのsetJspIdメソッドを使用して識別子を設定します。識別子はJSPコンパイル時に決定されるため，リクエスト処理ごとに識別子が変更されるおそれはありません。

一意の識別子として，id＜N＞という文字列を使用します。＜N＞は整数値を表します。＜N＞は0～2,147,483,647の範囲で割り当てられます。

(4)　JSPのAPIの追加

JSP 2.1仕様では次に示すクラスおよびメソッドが追加されました。

JSP 2.1仕様で追加されたクラス

パッケージ名 | クラス名
javax.servlet.jsp | JspApplicationContext

JSP 2.1仕様でコンストラクタが追加されたクラス

パッケージ名 | クラス名
javax.servlet.jsp.tagext | TagAttributeInfo

JSP 2.1仕様で追加されたメソッド

パッケージ名 | クラス名 | メソッド名
javax.servlet.jsp | JspFactory | getJspApplicationContext
javax.servlet.jsp.tagext | TagAttributeInfo | getDescription
isDeferredValue
isDeferredMethod
getExpectedTypeName
getMethodSignature
TagLibraryInfo | getTagLibraryInfos

(5)　アノテーションの使用

アプリケーションサーバでは，JSP 2.1仕様で規定されたアノテーションをサポートします。アノテーションの使用については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「11.　アノテーションの使用」を参照してください。

(6)　タグファイルのバージョンの決定方法

JSP 2.1仕様でタグファイルに記述できる要素が追加されたため，タグファイルのバージョンの明確化が必要になりました。そのため，アプリケーションサーバでは，JSP 2.1仕様に従ってタグファイルのバージョンを決定します。

ただし，タグファイルのバージョンはタグファイルのファイル単位で一致する必要があります。異なるバージョンのTLDファイルを使用して同一のタグファイルを実行した場合の動作は保証されません。

なお，TLDファイルやimplicit.tldなど，バージョン決定要素となるもののバージョンが異なっていても，実際の使用方法で決定するバージョンがファイル単位で一致すれば問題なく動作します。

例えば，次のようにTLDファイルとimplicit.tldのバージョンが異なっていても，常にTLDを使ってタグファイルを使用する場合，または常にJSPからディレクトリを指定して使用する場合は問題なく動作します。

表5-23　バージョン決定要素のバージョンが異なっている例

バージョン決定要素 | バージョン
タグファイルを参照するTLDファイル | 2.1
タグファイルを配置しているディレクトリのimplicit.tld | 2.0

(7)　タグの属性に指定できる要素について

JSP 2.1仕様では，タグの属性の設定でrtexprvalueがfalseの場合，deferredValueまたはdeferredMethodがtrueのときでも，タグの属性にスクリプティング要素の式を指定できません。

アプリケーションサーバでは，タグの属性の設定でrtexprvalueがfalseの場合でも，deferredValueまたはdeferredMethodがtrueのときは，タグの属性にスクリプティング要素の式を指定できます。アプリケーションサーバでのタグの属性の設定と指定できる要素の対応について，次の表に示します。

表5-24　タグの属性の設定と指定できる要素の対応

タグの属性の設定 | 指定できる要素
rtexprvalue | deferredValueまたはdeferredMethod | 文字列 | 式(<%= %>) | EL(${}) | EL(#{})
false | false | ○ | × | × | ×
true | false | ○ | ○ | ○ | ×
false | true | ○ | ○ | × | ○
true | true | ○ | ○ | ○ | ○

（凡例）○：指定できる　×：指定できない

(8)　エラーページの参照

JSPページのエラー発生時の遷移先としてpageディレクティブのerrorPage属性に自分自身を指定している場合の動作を次に示します。

表5-25　JSPページのエラー発生時の遷移先としてpageディレクティブのerrorPage属性に自分自身を指定している場合の動作

Servlet仕様/JSP仕様のバージョン | 内容
Servlet 2.5/JSP 2.1 | JSP 2.1仕様と同様にトランスレーションエラーとなります※。
Servlet 2.4/JSP 2.0 | JSPにアクセスし例外が発生した場合に，例外に対処しないで，例外が際限なく発生すると，スタックオーバーフローエラーが発生するおそれがあります。

注※

エラー発生時の遷移先をファイル名だけで指定した場合，およびコンテキストルートからの相対パスを指定した場合以外はトランスレーションエラーとなりません。

(a)　トランスレーションエラーとなるエラー発生時の遷移先の指定例

次のようなファイル構成の場合に，トランスレーションエラーとなる，JSPページのエラー発生時の遷移先の指定例について説明します。

example.jspのJSPページのエラー発生時の遷移先に，次のどちらかの方法で自分自身（example.jsp）を指定すると，トランスレーションエラーとなります。

ファイル名だけで自分自身を指定する
指定例：<%@ page isErrorPage="true" errorPage="example.jsp" %>

コンテキストルートからの相対パスで自分自身を指定する
指定例：<%@ page isErrorPage="true" errorPage="/jsp/example.jsp" %>

(b)　異なるページ間で相互にエラー発生時の遷移先に指定していた場合に発生するエラー

次のようなJSPページがあるとします。

JSPページA：エラー発生時の遷移先をJSPページBに設定している。

JSPページB：エラー発生時の遷移先をJSPページAに設定している。

JSPページAでエラーが発生し，JSPページBでもエラーが発生した場合，例外が発生してJSPページAに遷移します。ここに示した構造で例外が際限なく発生した場合，スタックオーバーフローエラーとなります。

(9)　拡張子以外同じ名前のタグファイルの扱い

タグファイルには.tagと.tagxの2種類の拡張子があります。example.tagとexample.tagxなど，拡張子だけが異なる同じ名前のタグファイルは配置しないでください。

JSP2.1仕様では，拡張子だけが異なる同じ名前のタグファイルが配置されている場合，タグライブラリが無効化されます。

アプリケーションサーバでは，拡張子だけが異なる同じ名前のタグファイルが配置されていても，タグライブラリは無効化されません。ただし，タグファイルはファイルシステムから検索されたファイルが使用されます。拡張子だけが異なる同じ名前のタグファイルの場合は，先に検索されたファイルが使用され，ファイルの検索順序については保証されないため，注意してください。

(10)　APIの仕様変更

アプリケーションサーバでは，JSP 2.1仕様でのAPIの仕様変更に従ってAPIの仕様を変更します。javax.servlet.jsp.JspExceptionの動作変更の詳細については「5.1.9(2)　javax.servlet.ServletException，およびjavax.servlet.jsp.JspExceptionで生成したオブジェクトに対するinitCause(Throwable)の呼び出しについて」を参照してください。

なお，Webアプリケーションのクラスで総称を使用するようになったAPIについて，JSP 2.0以前に準拠しているタイプセーフではないメソッドを使用している場合，メソッドの動作に変更はなく，08-00以降でもそのままクラスを使用できます。なお，コンパイル時にjavacコマンドで警告メッセージ（unchecked warning）が発生するようになりますが，動作に影響する警告メッセージではありません。警告メッセージが発生した原因の個所にアノテーション@SuppressWarnings("unchecked")を適用することで警告メッセージが発生しなくなります。

(11)　JSPページおよびタグファイルの文字エンコーディングの設定方法

アプリケーションサーバでは，JSP 2.1仕様に従って，JSPページ，および標準シンタックスのタグファイルの文字エンコーディングの設定方法にBOMの付加での設定を追加します。

JSPページについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。タグファイルの場合は，タグファイルのバージョンに対応するJSP仕様に従って制御されます。JSPページおよびタグファイルの文字エンコーディングの判別方法について，次の表に示します。

表5-26　JSPページおよびタグファイルの文字エンコーディングの判別方法

JSP仕様のバージョン
内容

JSP 2.1
JSP 2.1仕様に従って文字エンコーディングが設定されます。ただし，UTF-32のBOMはサポートされません。

JSP 2.0
BOMの付加での文字エンコーディングの設定はできません。
文字エンコーディングの指定が必要な場合は，web.xmlの<jsp-property-group>要素内の<page-encoding>要素またはpage，tagディレクティブでのpageEncoding属性で指定できます。

JSPファイルおよびタグファイルの文字エンコーディングの詳細は「5.1.5(13)　JSPでサポートしている文字エンコーディングについて」を参照してください。

Servlet 2.5仕様以降に準拠したWebアプリケーションのJSPページおよびタグファイルでは，BOMの付加で文字エンコーディングを設定するかどうかを次のどちらかの方法で指定できます。

簡易構築定義ファイルを使用した指定方法
論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，パラメタwebserver.jsp.jsp_page.bom.enabledの値にBOMの付加での文字エンコーディングを有効にする場合はtrueを，無効にする場合はfalseを指定します。

cjjspcコマンドを使用した指定方法
cjjspcコマンドにBOMの付加での文字エンコーディングを有効にする-jsppagedisablebomオプションを指定してJSP事前コンパイルを実施します。

なお，Servlet 2.5仕様以降に準拠したWebアプリケーションのJSPページおよびタグファイルで，BOMの付加での文字エンコーディングを設定しない場合，Servlet 2.4仕様に従ってJSPページの文字エンコーディングが設定されます。

(12)　TLDファイルとURIのマッピングについて

TLDファイルとURIのマッピングについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。JSP仕様のバージョンごとのTLDファイルとURIのマッピング方法を次の表に示します。

表5-27　TLDファイルとURIのマッピング方法

Version
マッピング方法

Servlet 2.5（JSP 2.1）
JSP 2.1仕様に従って，JSTLおよびJSFのURIを自動的にマッピングします。マッピングするURIは以下のとおりです。

http://java.sun.com/jsp/jstl/core

http://java.sun.com/jsp/jstl/xml

http://java.sun.com/jsp/jstl/fmt

http://java.sun.com/jsp/jstl/sql

http://java.sun.com/jsp/jstl/functions

http://java.sun.com/jstl/core

http://java.sun.com/jstl/xml

http://java.sun.com/jstl/fmt

http://java.sun.com/jstl/sql

http://java.sun.com/jstl/core_rt

http://java.sun.com/jstl/xml_rt

http://java.sun.com/jstl/fmt_rt

http://java.sun.com/jstl/sql_rt

http://java.sun.com/jsf/core

http://java.sun.com/jsf/html

Servlet 2.4（JSP 2.0）
自動的にマッピングしません。JSTL，JSFを使用する場合，通常のTLDファイルと同様に，JSTL，JSF仕様のTLDファイルを配置してください。

Servlet 2.5仕様以降に準拠したWebアプリケーションでは，自動的なマッピングが最優先で処理されるため，TLDファイルとURIのマッピングの上書きができません。

そのため，アプリケーションサーバでは，TLDファイルとURIの自動的なマッピングをするかどうかを次のどちらかの方法で指定できます。

簡易構築定義ファイルを使用した指定方法
論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，パラメタwebserver.jsp.tld.mapping.java_ee_tag_library.enabledの値に，自動的なマッピングを有効にする場合はtrueを，無効にする場合はfalseを指定します。

cjjspcコマンドを使用した指定方法
cjjspcコマンドに自動的なマッピングを無効にする-nojavaeetaglibオプションを指定してJSP事前コンパイルを実施します。

Webアプリケーションごとに複数のバージョンのタグライブラリを使用したい場合は，これらの方法で，自動的なマッピングを無効に設定してください。自動的なマッピングが無効になると，それぞれのWebアプリケーションにライブラリを配置することで複数のバージョンのライブラリを混在させることができます。

(13)　ELのエスケープシーケンス

JSP 2.1仕様では，ELの開始を示す文字に"#{"が追加されました。

JSPページおよびJSPドキュメントについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。タグファイルの場合は，タグファイルのバージョンに対応するJSP仕様に従って制御されます。また，ELの設定を有効にしているかどうかで制御が異なります。

"#"を文字列として表すエスケープシーケンスへの制御について，サーブレットおよびJSP仕様のバージョンごとに次の表に示します。

表5-28　#を文字列として表すエスケープシーケンスへの制御

サーブレット仕様/JSP仕様のバージョン | 仕様
ELの設定を有効にしている場合 | ELの設定を無効にしている場合
¥$の出力 | ¥#の出力 | ¥$の出力 | ¥#の出力
Servlet 2.5/JSP 2.1 | $ | # | $ | #
Servlet 2.4/JSP 2.0 | $ | ¥# | $ | ¥#

Servlet 2.5仕様に準拠したWebアプリケーションの場合，"¥#"は"¥$"と同様に条件に関係なくエスケープシーケンスによって#と出力されます。そのため，"¥#"と出力したい場合は，"¥¥#"と記述する必要があります。

JSP 2.0仕様の"¥$"のエスケープシーケンスの仕様については「5.1.7(15)　EL（Expression Language）のエスケープシーケンスについて」を参照してください。

(14)　ELでのEnum型に対する処理の変更

JSP 2.1仕様のELから，Java SE 5仕様で規定されたEnum型のオブジェクトに対応した処理が追加されました。

JSPページおよびJSPドキュメントについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。タグファイルの場合は，タグファイルのバージョンに対応するJSP仕様に従って制御されます。

アプリケーションサーバでのサーブレットおよびJSP仕様のバージョンごとのELでのEnum型に対する処理について，次の表に示します。

表5-29　ELでのEnum型に対する処理

サーブレット仕様/JSP仕様のバージョン | 内容
Servlet 2.5/JSP 2.1 | JSP 2.1仕様に従って処理されます。
Servlet 2.4/JSP 2.0 | JSP 2.0仕様に従って，Enum型であってもほかのオブジェクトと同様に処理されます。

ただし，JSP 2.1仕様で非推奨となった，JSP 2.0仕様で規定されているELのAPIを使用した場合，Webアプリケーションのバージョンに関係なくJSP 2.0仕様のELの機能範囲で処理されます。

(15)　ELでの<，>，lt，gt演算子の処理の変更

JSPページおよびJSPドキュメントについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。タグファイルの場合は，タグファイルのバージョンに対応するJSP仕様に従って制御されます。

アプリケーションサーバでのELでの<，>，lt，gt演算子の処理について，サーブレットおよびJSP仕様のバージョンごとに次の表に示します。

表5-30　ELでの<，>，lt，gt演算子の処理

サーブレット仕様/JSP仕様のバージョン | 内容
Servlet 2.5/JSP 2.1 | JSP 2.1仕様に従って，<，>，lt，gt演算子が処理されます。
Servlet 2.4/JSP 2.0 | JSP 2.0仕様に従って，<，>，lt，gt演算子が処理されます。

ただし，JSP 2.1仕様で非推奨となった，JSP 2.0仕様で規定されているELのAPIを使用した場合，Webアプリケーションのバージョンに関係なくJSP 2.0仕様のELの機能範囲で処理されます。

(16)　ELのAPIの変更

アプリケーションサーバでのJSP仕様のELのAPIについて説明します。

JSP 2.1仕様で追加となったAPIに対応します。JSP 2.1仕様で追加されたELの機能を使用する場合，javax.elパッケージのAPIを使用してください。

JSP 2.0仕様で規定されたELのAPIを使用した場合，JSP 2.0仕様で規定されたELの仕様に従ってELが評価されます。

5.1.7　JSP 2.0仕様で追加，変更された仕様についての注意事項

JSP 2.0仕様で追加，変更された仕様を，アプリケーションサーバ上で利用するときの注意事項を示します。JSP 2.0仕様およびJSP 1.2仕様については，それぞれの仕様書（JSP 2.0仕様書，JSP 1.2仕様書）を参照してください。

＜この項の構成＞

(1)　JSPドキュメントのデフォルト拡張子

(2)　タグファイルのJavaソースファイルとクラスファイルの出力先

(3)　JSP EL式の評価APIの複数指定

(4)　XMLシンタックスで記述されたJSPファイルとタグファイル

(5)　pageディレクティブのisThreadSafe属性の非推奨化について

(6)　JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について

(7)　タグライブラリ・ディスクリプタ（TLDファイル）の配置について

(8)　javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について

(9)　includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて

(10)　JSPドキュメント内の矛盾する文字コードについて

(11)　JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について

(12)　pageディレクティブのpageEncoding属性の複数回指定について

(13)　JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について

(14)　JSPドキュメントの文字コードについて

(15)　EL（Expression Language）のエスケープシーケンスについて

(16)　ELの評価結果の型について

(1)　JSPドキュメントのデフォルト拡張子

JSP 2.0仕様では，JSPドキュメントの標準的な拡張子を「jspx」としています。アプリケーションサーバで利用するWebコンテナでは，「jspx」を拡張子としたファイルは，デフォルトマッピングによってweb.xmlにURLマッピング定義しなくてもJSPドキュメントとして扱われます。

(2)　タグファイルのJavaソースファイルとクラスファイルの出力先

タグファイルは，JSPファイルと同様に，JSPのコンパイルによってJavaソースファイルとクラスファイルが生成されます。Javaソースファイルおよびクラスファイルは，JSPコンパイル結果の出力先ディレクトリに出力されます。

JSPコンパイル結果の出力先ディレクトリは変更できます。なお，生成されるJavaソースファイル，およびクラスファイルのパスがOSの上限を超える場合は，出力先ディレクトリを変更する必要があります。

JSPコンパイル結果の出力先ディレクトリについては，JSP事前コンパイル機能を使用している場合，「2.5.5(2)　JSPコンパイル結果の出力先」，JSP事前コンパイル機能を使用していない場合，「2.5.6(3)　JSPコンパイル結果の出力先」を参照してください。

(3)　JSP EL式の評価APIの複数指定

JSP 2.0仕様では，EL式の構文解析と評価をするAPIとして次のAPIが提供されます。

javax.servlet.jsp.el.ExpressionEvaluatorクラスのevaluateメソッド

javax.servlet.jsp.el.Expressionクラスのevaluateメソッド

JSP 2.0仕様では，これらのAPIから複数のEL式を指定することはできませんが，アプリケーションサーバでは，複数のEL式を指定できます。

(4)　XMLシンタックスで記述されたJSPファイルとタグファイル

文字エンコードについて
Webアプリケーションのバージョン2.4で，JSPドキュメントの文字エンコードを指定する場合は，XML宣言で文字エンコードを指定してください。
JSP 1.2仕様の場合は，ファイルの文字エンコードは，pageディレクティブのpageEncoding属性，またはcontentType属性のcharset値で指定していましたが，JSP 2.0仕様からはXML宣言で文字エンコードを指定するように変更されています。

標準アクションの接頭辞ついて
JSPの標準アクションは，XML名前空間の「http://java.sun.com/JSP/Page」で識別されます。したがって，XML名前空間の接頭辞で標準アクションを指定する必要があります。接頭辞をjspとした場合の記述例を示します。

<?xml version="1.0" ?>
<jsp:root
   xmlns:jsp=http://java.sun.com/JSP/Page
   version="2.0">
   <jsp:directive.page import="java.util.*"/>
   <jsp:useBean id="name" class="test.Bean"/>

</jsp:root>

<jsp:root>要素の扱いについて
JSP 2.0仕様から<jsp:root>要素をルート要素に指定していなくても，XMLシンタックスのJSPファイル，またはタグファイルとして扱われます。
JSP 1.2仕様では，JSPドキュメントの条件として<jsp:root>がルート要素に指定されている必要がありましたが，JSP 2.0仕様からは，<jsp:root>が指定されていなくても，web.xmlに定義した<jsp-config><jsp-property-group><is-xml>の値がtrue，または拡張子がjspx，tagxであれば，XMLシンタックス形式のJSPと扱うように変更されています。

(5)　pageディレクティブのisThreadSafe属性の非推奨化について

pageディレクティブのisThreadSafe属性は，javax.servlet.SingleThreadModelインタフェースが非推奨となったことによって，JSP 2.0仕様では非推奨とされています。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，pageディレクティブのisThreadSafe属性を使用できます。ただし，Servlet 2.4仕様で，javax.servlet.SingleThreadModelインタフェースが非推奨となった理由に注意して使用してください。

(6)　JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について

JSP 2.0仕様では，JSPドキュメントを使用した場合に，デフォルトのContentTypeの値が「text/xml」になると追記されています。

アプリケーションサーバでは，JSP 2.0以降の場合は「text/xml」，JSP 1.2の場合は「text/html」をデフォルトとして動作します。

(7)　タグライブラリ・ディスクリプタ（TLDファイル）の配置について

JSP 2.0仕様では，タグライブラリ・ディスクリプタの配置場所についての規定が追加されています。

アプリケーションサーバでは，配置するディレクトリによって，JSPのコンパイル時にKDJE39289-Wのメッセージが出力されることがあります。ただし，エラーとはならないでWebアプリケーションが実行されます。

メッセージが出力される条件を次に示します。

配置するディレクトリ

/WEB-INFディレクトリ以下以外

/WEB-INF/classesディレクトリ以下

/WEB-INF/libディレクトリ以下

メッセージが出力されるタイミング

該当するタグライブラリ・ディスクリプタを，web.xmlの<taglib><taglib-location>タグに指定して，Webアプリケーション開始するとき

該当するタグライブラリ・ディスクリプタを，タグライブラリの宣言で直接指定して使用するJSPをコンパイルするとき

(8)　javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について

javax.servlet.jsp.tagext.PageDataオブジェクトのgetInputStreamメソッドで取得できるXMLビュー情報の仕様が，JSP 2.0仕様で変更されています。getInputStreamメソッドは，javax.servlet.jsp.tagext.TagLibraryValidatorクラスのvalidateメソッドの第三引数に指定して使用されます。

アプリケーションサーバでの変更点を，JSP 2.0以降とJSP 1.2に分けて示します。

(a)　jsp:id属性

JSP 2.0以降

jsp:id属性を付加します。

JSP 1.2

jsp:id属性を付加しません。

(b)　XMLビューの文字エンコード

JSP 2.0以降

XMLビューの文字エンコードを常にUTF-8とし，文字コードをUTF-8としてXML宣言を出力します。

JSP 1.2

XMLビューの文字エンコードを常にUTF-8とし，文字コードをUTF-8としてXML宣言を出力しません。

(c)　pageディレクティブのpageEncoding属性

JSP 2.0以降

pageEncoding属性の値をUTF-8に設定します。pageEncoding属性がない場合は，pageEncoding属性を追加します。

JSP 1.2

pageEncoding属性の値は変更しません。

(d)　pageディレクティブのcontentType属性

JSP 2.0以降

contentType属性の値にServletResponseクラスのsetContentTypeメソッドで設定された値を設定します。contentType属性がない場合は，contentType属性を追加します。

JSP 1.2

contentType属性の値は変更しません。

(9)　includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて

JSP 2.0仕様では，pageディレクティブのpageEncoding属性は，pageEncoding属性を記述したファイルにだけ適用されることが追記されています。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，includeディレクティブでファイルをインクルードするときに，インクルード先のファイルに文字コードの指定がないと，インクルード元の文字コードがインクルード先のファイルに適用されます。

(10)　JSPドキュメント内の矛盾する文字コードについて

JSPドキュメントでのXML宣言に指定する文字コードと，JSPドキュメントでのpageディレクティブのpageEncoding属性に指定する文字コードが異なる場合の仕様がJSP 2.0仕様では追記されています。JSP 1.2仕様には記述がありません。

アプリケーションサーバで文字コードが異なる場合の制御を，JSP 2.0以降とJSP 1.2に分けて示します。

JSP 2.0以降

トランスレーションエラーとなります。

JSP 1.2

pageディレクティブのpageEncoding属性が使用されます。

(11)　JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について

JSPドキュメントでpageディレクティブのcontentType属性がない場合や，属性にCHARSET値がない場合に使用されるHTTPレスポンスのデフォルトの文字コードがJSP 2.0仕様では追記されています。

アプリケーションサーバでのデフォルト値を，JSP 2.0以降とJSP 1.2に分けて示します。

JSP 2.0以降

UTF-8が使用されます。

JSP 1.2

ISO-8859-1が使用されます。

(12)　pageディレクティブのpageEncoding属性の複数回指定について

pageディレクティブのpageEncoding属性の複数回指定について，JSP 2.0仕様では仕様が変更されています。

JSP 2.0仕様では，トランスレーション単位（JSPとincludeディレクティブでインクルードされるファイル）でpageEncoding属性の複数回指定ができるようになっています。また，同じJSPファイル内でpageEncoding属性の複数回指定をするとコンパイルエラーとなることが追記されています。

アプリケーションサーバでは，Webアプリケーションのバージョンに関係なく，トランスレーション単位でpageEncoding属性の複数回指定ができます。このとき，ファイル単位に指定した値が該当するファイルに適用されます。また，同じJSPファイル内でのpageEncoding属性の複数回指定については，JSP 2.0以降とJSP 1.2で仕様が異なります。アプリケーションサーバでの仕様を，JSP 2.0以降とJSP 1.2に分けて示します。

JSP 2.0以降

一つのファイルに1回だけ指定できます。複数回指定した場合は，コンパイルエラーとなります。

JSP 1.2

一つのファイルに複数回指定できます。最初に記述した値が適用されます。

(13)　JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について

JSPドキュメントでnamespaceを使ってタグライブラリを宣言し，指定したuriがtaglibマップ（uriとタグライブラリ・ディスクリプタのマッピング）で見つからない場合の動作について，JSP 2.0仕様では追記されています。

アプリケーションサーバでの動作を，JSP 2.0以降とJSP 1.2に分けて示します。

JSP 2.0以降

指定したuriがtaglibマップに登録されていない場合，uriのnamespaceで定義されたアクションは，解析しないで扱われます（テキストとして出力されます）。

JSP 1.2

uriが絶対URIの場合
トランスレーションエラーとなります。

uriが絶対URI以外の場合
Webアプリケーション内のパスとしてTLDファイル（タグライブラリ・ディスクリプタ）を検索して使用されます。TLDファイルがない場合は，トランスレーションエラーとなります。

(14)　JSPドキュメントの文字コードについて

JSPドキュメントでのファイルの文字コードの決定方法について，JSP 2.0仕様で仕様が変更されています。

アプリケーションサーバでの文字コードの決定方法を，JSP 2.0以降とJSP 1.2に分けて示します。

JSP 2.0以降

XML 1.0の仕様に従い，XML宣言に従います。XML宣言がない場合はデフォルト値のUTF-8となります。

JSP 1.2

pageディレクティブのpageEncoding属性に従います。pageEncoding属性がない場合はcontentType属性のcharset=で指定した文字コードに従います。どちらもない場合はデフォルト値のISO-8859-1になります。

(15)　EL（Expression Language）のエスケープシーケンスについて

JSP 2.0仕様であるELの開始を示す"${"に含まれる"$"を文字列として表すエスケープシーケンスについて，JSP仕様と，アプリケーションサーバで利用するWebコンテナの仕様を次に示します。

アプリケーションサーバで利用するWebコンテナでは，"¥$"はエスケープシーケンスによって，"$"と出力されます。"¥$"と出力したい場合は，"¥¥$"と記述します。

"¥$"と記述した場合の動作を，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

JSP 2.0仕様では，ELの設定を無効に設定している場合，"$"はELの開始文字とする必要がなく，"¥"は制御コードとしては扱われません。JSP 2.0で動作する場合は，ELの設定を有効にしているかどうかによって，"¥$"の出力結果が異なります。JSP 2.0で動作する場合の"¥$"の出力結果を次の表に示します。

表5-31　JSP 2.0で動作する場合の"¥$"の出力結果

ELの設定の有効/無効 | 仕様 | 出力結果
有効 | JSP 2.0仕様 | "$"
アプリケーションサーバで利用するWebコンテナ | "$"
無効 | JSP 2.0仕様 | "¥$"
アプリケーションサーバで利用するWebコンテナ | "$"

ELの設定を無効にする場合は，次に示すどれかの方法で設定します。

pageディレクティブのisELIgnored属性にtrueを指定する。

tagディレクティブのisELIgnored属性にtrueを指定する。

web.xmlの<el-ignored>タグにtrueを指定する。

JSP 1.2

JSP 1.2仕様では"$"は予約語ではありません。"¥"は制御コードとしては扱われないため，"¥$"と出力されます。

アプリケーションサーバで利用するWebコンテナでは，JSP1.2で動作する場合でも"¥"は制御コードとして扱われるため，"$"と出力されます。ただし，JSPドキュメント形式の属性値で使用する場合は，"¥$"と出力されます。

JSP 1.2で動作する場合の"¥$"の出力結果を次の表に示します。

表5-32　JSP 1.2で動作する場合の"¥$"の出力結果

仕様 | 出力結果
JSP 1.2仕様 | "¥$"
アプリケーションサーバで利用するWebコンテナ | "$"

(16)　ELの評価結果の型について

カスタムタグの属性に指定したELの評価結果の型について，JSP仕様と，アプリケーションサーバの仕様を次に示します。

JSP 2.0仕様

ELの評価結果は，カスタムタグの属性の期待する型に変換されます。

アプリケーションサーバ

ELの評価結果は，カスタムタグの属性に対応するセッターメソッドの引数の型に変換されます。TLDの属性の定義に記述されたtype要素は型の変換に使用しません。

ELの記載個所がタグファイルの場合，attributeディレクティブのtype属性に指定した型に変換されます。

ELの評価結果の型がJSP仕様とアプリケーションサーバで異なる場合の例について次に示します。

例

カスタムタグの属性名：attr

カスタムタグのセッターのシグニチャ：void setAttr(java.lang.String hoge)

TLDでのattr属性のtype要素の値：java.lang.Integer

この例の場合，ELの評価結果の型は次に示す型になります。

JSP 2.0仕様

java.lang.Integerに変換されます。

アプリケーションサーバ

java.lang.Stringに変換されます。

5.1.8　既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点

Servlet 2.4仕様に対応したWebアプリケーションをServlet 2.5仕様にバージョンアップする場合に必要な作業，および注意事項を示します。なお，Servlet 2.5仕様の詳細については，Servlet 2.5仕様書を参照してください。

＜この項の構成＞

(1)　Servlet 2.5仕様，およびJSP 2.1仕様で追加された仕様，および変更された仕様について

(2)　web.xmlの移行について

(3)　JSPから生成するクラスのサイズについて

(1)　Servlet 2.5仕様，およびJSP 2.1仕様で追加された仕様，および変更された仕様について

Servlet 2.5仕様およびJSP 2.1仕様で追加，変更された仕様についての注意事項については，それぞれ「5.1.3　Servlet 2.5仕様で追加，変更された仕様についての注意事項」または「5.1.6　JSP 2.1仕様で追加，変更された仕様についての注意事項」を参照してください。

(2)　web.xmlの移行について

web.xmlは，Servlet 2.5仕様に従った定義に修正します。詳細はJava Servlet Specification v2.5を参照してください。また，仕様変更については「5.1.3　Servlet 2.5仕様で追加，変更された仕様についての注意事項」を参照してください。

(3)　JSPから生成するクラスのサイズについて

Servlet 2.5仕様に準拠したWebアプリケーションに含まれるJSPから生成したクラスは，JSP 2.1仕様の機能が適用されるようになります。そのため，JSPから生成したJavaソースファイル，クラスファイルの内容が変わります。

この場合，Javaソースファイルの行数，JSPから生成したクラスに含まれるメソッドのサイズ，またはPermanent領域の使用量が増加することがあるため，注意してください。

5.1.9　前バージョンから08-00へ移行する場合のWebアプリケーションに関する注意事項

前バージョンから08-00へ移行する場合の，Webアプリケーションに関する注意事項を示します。

＜この項の構成＞

(1)　Webコンテナがサポートするバージョン情報取得API

(2)　javax.servlet.ServletException，およびjavax.servlet.jsp.JspExceptionで生成したオブジェクトに対するinitCause(Throwable)の呼び出しについて

(3)　javax.servlet.ServletRequestインタフェースのsetCharacterEncodingメソッドを呼び出した場合の動作

(4)　javax.servlet.GenericServletクラスが保持するServletConfigオブジェクトがnullの場合の動作

(5)　javax.servlet.GenericServletクラスのinitメソッドとdestroyメソッドで出力するログ

(6)　ライブラリJAR内のTLDファイルの検索

(7)　cjjspcコマンドでのクラスパスに指定したJARファイル内のTLDファイルの検索

(8)　HTTPセッションのセッションIDを示すHTTP Cookieの削除

(1)　Webコンテナがサポートするバージョン情報取得API

次の表に示すServlet APIでは，WebコンテナがサポートするServlet仕様のバージョン情報を取得できます。

表5-33　Webコンテナがサポートするバージョン情報取得API

クラス名 | メソッド名
javax.servlet.ServletContext | getMajorVersion
getMinorVersion
javax.servlet.jsp.JspEngineInfo | getSpecificationVersion

WebアプリケーションのバージョンがServlet 2.4/JSP 2.0以前であっても，WebコンテナがサポートするServlet仕様のバージョンは，Servlet 2.5/JSP 2.1となります。そのため，これらのServlet APIはServlet仕様のバージョンとしてServlet 2.5/JSP 2.1の情報を返します。なお，サーバの動作モードにも関係なく情報を取得します。

(2)　javax.servlet.ServletException，およびjavax.servlet.jsp.JspExceptionで生成したオブジェクトに対するinitCause(Throwable)の呼び出しについて

次に示すオブジェクトに対して，initCause(Throwable)を呼び出すことができません。

javax.servlet.ServletExceptionのコンストラクタServletException(String, Throwable)およびServletException(Throwable)で生成したServletExceptionオブジェクト

javax.servlet.jsp.JspExceptionのコンストラクタJspException(String, Throwable)およびJspException(Throwable)で生成したJspExceptionオブジェクト

initCause(Throwable)を呼び出したい場合は，簡易構築定義ファイルに互換用のプロパティを設定します。設定の方法については，「5.1.1(22)　javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について」を参照してください。

(3)　javax.servlet.ServletRequestインタフェースのsetCharacterEncodingメソッドを呼び出した場合の動作

javax.servlet.ServletRequestインタフェースのgetReaderメソッドを呼び出したあとでjavax.servlet.ServletRequestインタフェースのsetCharacterEncodingメソッドを呼び出した場合，getCharacterEncodingメソッドの戻り値が変更されません。詳細については，「5.1.3(8)　javax.servlet.ServletRequestインタフェースのsetCharacterEncodingメソッドの呼び出しの無効について」を参照してください。

(4)　javax.servlet.GenericServletクラスが保持するServletConfigオブジェクトがnullの場合の動作

javax.servlet.GenericServletクラスがインスタンス変数として保持するServletConfigがnullの場合，次に示すメソッドによってスローされる例外がバージョンごとに異なります。

getInitParameter(String)

getInitParameterNames()

getServletContext()

getServletName()

これらのメソッドによってスローされる例外をバージョンごとに次に示します。

07-60以前

java.lang.NullPointerException

08-00

java.lang.IllegalStateException

例外のメッセージとして「ServletConfig has not been initialized.」が出力されます。

これらの例外は，次の二つの条件を両方満たす場合にスローされます。

javax.servlet.GenericServletを継承したサーブレットがinit(ServletConfig)をオーバーライドしている場合

オーバーライドしたinit(ServletConfig)の中でsuper.init(ServletConfig)を呼び出していない，または，引数にnullを指定してsuper.init(ServletConfig)を呼び出している場合

(5)　javax.servlet.GenericServletクラスのinitメソッドとdestroyメソッドで出力するログ

javax.servlet.GenericServletクラスのinitメソッドとdestroyメソッドをオーバーライドしていないサーブレットを初期化または終了すると，サーブレットログにログが出力されます。出力されるログについては「5.1.1(17)　initメソッドおよびdestroyメソッドをオーバーライドしていない場合に出力されるメッセージ」を参照してください。

ただし，javax.servlet.GenericServletクラスがインスタンス変数で持つServletConfigがnullの場合の動作が07-60以前と08-00で異なります。バージョンごとの動作の差異を次に示します。

07-60以前

ログ出力に失敗し，java.lang.NullPointerException例外をスローする。

08-00

例外をスローしない。また，ログも出力しない。

(6)　ライブラリJAR内のTLDファイルの検索

08-00では，ライブラリJARに含まれるTLDファイルを検索し，ライブラリJAR内のタグライブラリが使用できます。ライブラリJARにTLDファイルが含まれる場合，以前のバージョンでは使用できなかったTLDファイルが使用できるため，次に示す動作変更が発生します。

ライブラリJAR内のTLDファイルの<uri>要素に記述されたURIが，web.xmlやほかのTLDファイルに記述されたURIと重複する場合，警告メッセージが出力されます。ライブラリJAR内のTLDファイルに記述されたURIとTLDファイルのマッピングは無効となります。

JSPのtaglibディレクティブのuri属性で，ライブラリJAR内のTLDファイルに記述されたURIを指定していた場合，JSPトランスレーションができるようになります。なお，07-60以前ではJSPトランスレーション時にトランスレーションエラーとなります。

詳細は，「2.3.4　タグライブラリのJ2EEアプリケーションへの格納」を参照してください。

(7)　cjjspcコマンドでのクラスパスに指定したJARファイル内のTLDファイルの検索

08-00では，cjjspcコマンドでのJSPコンパイル時に，-classpathオプションでクラスパスに指定したJARファイル内のTLDファイルを検索し，JARファイル内のタグライブラリが使用できます。クラスパスに指定したJARファイルにTLDファイルが含まれる場合，07-60以前では使用できなかったTLDファイルが使用できるため，次の現象が発生します。

クラスパスに指定したJARファイル内のTLDファイルの<uri>要素に記述されたURIが，web.xmlやほかのTLDファイルに記述されたURIと重複する場合，警告メッセージが出力されます。クラスパスに指定したJARファイル内のTLDファイルに記述されたURIとTLDファイルのマッピングは無効となります。

JSPのtaglibディレクティブのuri属性で，クラスパスに指定したJARファイル内のTLDファイルに記述されたURIを指定していた場合，JSPトランスレーションができるようになります。なお，07-60以前ではJSPトランスレーション時にトランスレーションエラーとなります。

詳細は，「2.3.4　タグライブラリのJ2EEアプリケーションへの格納」を参照してください。

(8)　HTTPセッションのセッションIDを示すHTTP Cookieの削除

Webアプリケーション内でHTTPセッションを無効化した場合に，Webクライアントの保持するHTTP Cookieの情報についての動作が07-60以前と08-00で異なります。バージョンごとの動作の差異を次に示します。

08-00

Webクライアントの保持するHTTP Cookieの情報を削除します。また，無効化済みのHTTPセッションに対するセッションID送信を抑止します。

07-60以前

Webクライアントの保持するHTTP Cookie情報を削除しません。そのため，HTTPセッション無効化後も無効なセッションIDの送信が続く場合があります。

HTTP Cookieの削除については「2.7.4　Webクライアントが保持する無効なセッションIDの削除」を参照してください。

07-60以前のバージョンから08-00へアップグレードインストールをした場合，セットアップ済みのJ2EEサーバの設定に，次のパラメタの設定が追加されます。

webserver.session.delete_cookie.backcompat=true

この設定の追加によって，HTTP Cookie情報を削除しなくなり，07-60以前と同様の動作になります。パラメタについての詳細はマニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.4　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

5.1.10　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

Servlet 2.2仕様またはServlet 2.3仕様に対応したWebアプリケーションをServlet 2.4仕様にバージョンアップする場合に必要な作業，および注意事項を示します。なお，Servlet 2.4仕様の詳細については，Servlet 2.4仕様書を参照してください。

＜この項の構成＞

(1)　web.xmlの移行

(2)　Servlet 2.4仕様に対応したコードへの修正

(3)　サーブレットエンジンモードからJ2EEサーバモードへの移行

(4)　JSPのシンタックスチェックについて

(1)　web.xmlの移行

Servlet 2.2仕様またはServlet 2.3仕様に従って作成したweb.xmlは，Servlet 2.4仕様に従った定義に修正します。Servlet 2.4仕様で変更された点については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション開発ガイド」の「5.2.7　Servlet 2.4以降で追加，変更された仕様についての注意事項（web.xml）」を参照してください。

(2)　Servlet 2.4仕様に対応したコードへの修正

Servlet 2.4仕様では，Servlet 2.2仕様およびServlet 2.3仕様から仕様が追加，変更されています。追加，変更された点を確認し，Servlet 2.4仕様に対応したコードに修正してください。Servlet 2.4仕様で追加，変更された点については，「5.1.4　Servlet 2.4仕様で追加，変更された仕様についての注意事項」を参照してください。

また，JSP 2.0仕様でもJSP 1.2仕様から仕様が追加，変更されています。追加，変更された点を確認し，JSP 2.0仕様に対応したコードに修正してください。JSP 2.0仕様で追加，変更された点については，「5.1.7　JSP 2.0仕様で追加，変更された仕様についての注意事項」を参照してください。

(3)　サーブレットエンジンモードからJ2EEサーバモードへの移行

Servlet 2.4仕様に対応したWebアプリケーションは，サーブレットエンジンモードでは実行できません。したがって，サーブレットエンジンモードを使用していた場合は，J2EEサーバモードに移行する必要があります。

サーブレットエンジンモードからJ2EEサーバモードへの移行方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「10.　旧バージョンとの互換用機能（サーブレットエンジンモード）」を参照してください。

(4)　JSPのシンタックスチェックについて

Servlet 2.4仕様に対応したWebアプリケーションに含まれるJSPファイルは，JSP 2.0仕様に準拠します。JSP 2.0仕様では，JSP 1.2仕様よりも厳密にシンタックスチェックされます。したがって，Servlet 2.3仕様のWebアプリケーションでは通知されなかったエラーが通知されることがあります。

Servlet 2.2仕様またはServlet 2.3仕様に対応したWebアプリケーションをServlet 2.4仕様にバージョンアップする場合は，cjjspcコマンドでJSPをコンパイルして，エラーが発生しないことを確認してください。コンパイルエラーが通知された場合は，エラー通知内容に従って修正してください。

cjjspcコマンドについては，「2.5.2　JSP事前コンパイルの方法」を参照してください。

5.1.11　サーブレットでのアノテーションの使用

アプリケーションサーバでは，サーブレットでアノテーションを使用できます。アプリケーションサーバが対応しているアノテーションについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「2.　アプリケーションサーバが対応しているアノテーションおよびDependency Injection」を参照してください。

5.1.12　JavaVMのメソッドサイズ制限についての注意事項

JavaVMでは，64KBを超えるメソッドが存在すると，クラスファイル生成時にエラーとなるか，クラスのロード時にjava.lang.LinkageError例外が発生します。そのため，1メソッドのバイトコードは64KB以内のサイズにする必要があります。

また，64KB以内であっても，非常に大きいサイズのメソッドが存在する場合は，次のような弊害が発生するおそれがあります。

GC処理の実行に非常に時間が掛かる。

JITコンパイルに非常に時間が掛かる。

JITコンパイルに非常に多くのメモリを消費する。

Webアプリケーションでは，自動生成されるjavaソースコードによって，1メソッドのバイトコードが64KBを超える場合があります。javaソースコードの自動生成と，メソッドサイズが大きい場合の見直し方法について説明します。

＜この項の構成＞

(1)　javaソースコードの自動生成

(2)　メソッドサイズが大きい場合の見直し方法

(1)　javaソースコードの自動生成

javaソースコードの自動生成について説明します。

JSP仕様での自動生成
JSP仕様では，JSPファイル，またはタグファイルに記述した内容から，_jspServiceメソッドまたはdoTagメソッド内にjavaソースコードが自動生成されます。

アプリケーションサーバでのカスタムタグ使用時の自動生成
アプリケーションサーバでは，カスタムタグを使用している場合，カスタムタグの処理やボディに記述した内容がメソッド化され，javaソースコードが自動生成されます。
なお，カスタムタグをメソッド化できるのは，カスタムタグの処理またはボディに含まれるすべてのカスタムタグが次の条件を満たす場合です。

属性やボディがスクリプトレスである。

スクリプト変数を定義していない。

(2)　メソッドサイズが大きい場合の見直し方法

自動生成されたjavaソースコードのメソッドの行数が，コメントおよび空行を含めて1000行を超える場合，KDJE39231-WおよびKDJE39333-Wのメッセージが出力されます。

メッセージが出力された場合は，JSPファイル，タグファイル，またはカスタムタグのボディの内容を見直してください。

見直す個所ごとに，見直す方法を次に示します。

JSPファイルの内容のサイズが大きい場合
動的インクルード（インクルードアクション）でJSPファイルを分割する。

タグファイルの内容のサイズが大きい場合
次のどちらかを実施します。

JSPファイルから使用するタグファイルを複数のタグファイルに分割する。

タグファイルから別のタグファイルを呼び出すように分割する。

カスタムタグのボディのサイズが大きい場合
動的インクルード（インクルードアクション）でカスタムタグを分割する。

5.2　JSP移行時の注意事項

この節では，JSP移行時の注意事項について説明します。

07-00より前のバージョンと07-00以降のバージョンでは，JSPのコンパイルの動作が異なります。アプリケーションサーバでは，JSPトランスレーション時に，JSP仕様に従ってJSPの内容がチェックされるため，JSPトランスレーション時にエラーになって移行できないことがあります。その場合，JSPトランスレーション下位互換機能を使用すると，07-00より前のバージョンと07-00以降のバージョンでJSPのコンパイルの動作を同じように設定できて，エラーが発生しないようにできます。

JSPトランスレーション下位互換機能の定義は，簡易構築定義ファイルで指定します。指定内容については，以降の各項を参照してください。また，JSPトランスレーション下位互換機能の定義は，cjjspcコマンドを実行するときのオプションにも指定できます。cjjspcコマンドを実行するときにオプションに指定する方法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」を参照してください。

この節の構成を次の表に示します。

表5-34　この節の構成（JSP移行時の注意事項）

タイトル | 参照先
カスタムタグのスクリプト変数の定義に関する注意事項 | 5.2.1
<jsp:useBean>タグのclass属性に関する注意事項 | 5.2.2
タグの属性値のExpressionチェックに関する注意事項 | 5.2.3
タグの属性値に指定するExpressionに関する注意事項 | 5.2.4
taglibディレクティブのprefix属性に関する注意事項 | 5.2.5

＜この節の構成＞

5.2.1　カスタムタグのスクリプト変数の定義に関する注意事項

5.2.2　<jsp:useBean>タグのclass属性に関する注意事項

5.2.3　タグの属性値のExpressionチェックに関する注意事項

5.2.4　タグの属性値に指定するExpressionに関する注意事項

5.2.5　taglibディレクティブのprefix属性に関する注意事項

5.2.1　カスタムタグのスクリプト変数の定義に関する注意事項

ここでは，JSPのカスタムタグで，スクリプト変数を定義する場合の注意事項，JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異，およびJSPトランスレーション下位互換機能の定義について説明します。

＜この項の構成＞

(1)　注意事項

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

(3)　JSPトランスレーション下位互換機能の定義

(1)　注意事項

●スコープ指定時の注意

複数のカスタムタグで，スクリプト変数名とスクリプト変数のスコープが重複した場合，アプリケーションサーバのバージョンによって，JSPのコンパイル結果が異なります。スクリプト変数のスコープは，次のどちらかで指定します。

javax.servlet.jsp.tagext.TagExtraInfoクラスのサブクラス

TLDファイルのvariable要素内のscope要素

JSPのカスタムタグで同じ名称のスクリプト変数を指定した場合に，アプリケーションサーバのバージョンごとの動作の違いを次に示します。

07-00より前のバージョンの場合
2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数の変数宣言をします。

07-00以降のバージョンの場合
2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでは，スクリプト変数の変数宣言をしません。

スコープが「AT_BEGIN」で，属性idに指定された変数名（var）のスクリプト変数を定義するカスタムタグ<my:foo>を例に説明します。

定義例

<my:foo id="var" type="String">
 <%=var%>
</my:foo>

<my:foo id="var" type="String">
 <%=var%>
</my:foo>

07-00より前のバージョンの場合
2回目のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数varで変数宣言をします。この場合，各カスタムタグでのスコープ「AT_BEGIN」の範囲は次のようになります。

このため，JSPから生成されたJavaソースのコンパイル時にコンパイルエラーとなります。

07-00以降のバージョンの場合
2回目のカスタムタグに対応するJSPから生成されたJavaコードでは，スクリプト変数varで変数宣言をしません。この場合，各カスタムタグでのスコープ「AT_BEGIN」の範囲は次のようになります。

このため，同一スコープ内で同一の名称のスクリプト変数を定義しても，JSPから生成されたJavaソースのコンパイルは正常に実行されます。

●スクリプトレット記述時の注意

JSPからJavaソースを生成する際，スクリプトレットで記述されたJavaコードは解析しません。このため，カスタムタグの前後，またはボディのスクリプトレットで，スクリプト変数のスコープが変更される処理を定義していると，アプリケーションサーバのバージョンによっては，JSPコンパイルの結果がエラーとなることがあります。

スコープが「AT_BEGIN」の場合にコンパイルエラーとなる例
この例では，カスタムタグ<my:foo>で，スコープに「AT_BEGIN」，属性idに指定された変数名（var）のスクリプト変数を定義しています。

<% if(flag) { %>

 <my:foo id="var" type="String">
   <%=var%>
 </my:foo>

<% } else { %>

 <my:foo id="var" type="String">
   <%=var%>
 </my:foo>

<% } %>

この定義例での，アプリケーションサーバのバージョンごとの動作を次に示します。

07-00より前のバージョンの場合
2回目のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数varで変数宣言をします。このため，2回目のスクリプト変数varの参照でもエラーとなりません。JSPコンパイルは正常に実行されます。

07-00以降のバージョンの場合
2回目のカスタムタグでは，スクリプト変数varが宣言済みと解析します。この場合，カスタムタグに対応するJSPから生成されたJavaコードでは，変数varで変数宣言をしません。このため，2回目のスクリプト変数varの参照でエラーとなります。

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

07-00以降のバージョンで，JSPトランスレーション下位互換機能を使用するときと使用しないときの，コンパイルの動作の差異を次に示します。

複数のカスタムタグで，スクリプト変数名とスクリプト変数のスコープが重複した場合

JSPトランスレーション下位互換機能を使用する
2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数の変数宣言をする。

JSPトランスレーション下位互換機能を使用しない
2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでは，スクリプト変数の変数宣言をしない。

(3)　JSPトランスレーション下位互換機能の定義

JSPトランスレーション下位互換機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.jsp.translation.backcompat.customAction.declareVariable

JSPファイルから生成されたJavaコードで2回目のカスタムタグに対応するスクリプト変数の変数宣言を出力するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

5.2.2　<jsp:useBean>タグのclass属性に関する注意事項

ここでは，<jsp:useBean>タグのclass属性に関する注意事項，JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異，およびJSPトランスレーション下位互換機能の定義について説明します。

＜この項の構成＞

(1)　注意事項

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

(3)　JSPトランスレーション下位互換機能の定義

(1)　注意事項

<jsp:useBean>タグでは，class属性はオブジェクトの実装クラス名であることがJSPの仕様で定義されています。07-00以降では，この仕様に準拠して，JSPトランスレーション時に，class属性に指定されたクラスについて次のチェックを実施しています。

クラスの修飾子がpublicである。

クラスの修飾子がinterfaceではない。

クラスの修飾子がabstractではない。

メソッドの修飾子がpublicで引数がないコンストラクタが存在する。

このため，class属性にこれらのチェック項目に該当しないクラスを指定したとき，07-00より前と07-00以降ではJSPコンパイルの結果が異なります。

次のようにinclude元で実装クラスを指定して，include先でインタフェースを指定したJSPを例にして説明します。

test1.jsp（インクルード元）

<jsp:useBean id="bean" scope="request" class="test.TestBean"/>
<jsp:include page="test1_included.jsp"/>

test1_included.jsp（インクルード先）

<jsp:useBean id="bean" scope="request" class="test.TestBeanIF"/>

注　class属性に指定したtest.TestBeanはJSP仕様に準拠した実装クラス，test.TestBeanIFはtest.TestBeanのインタフェースになります。

この定義例での，アプリケーションサーバのバージョンごとの動作を次に示します。

07-00より前のバージョンの場合
JSPトランスレーション時にチェックを実施しないため，JSPファイルから生成されたサーブレットが実行されます。
JSPファイルから生成されたサーブレットでは，id属性に指定された"bean"で既存のスクリプト変数を検索します。上記ではインクルード元（test1.jsp）ですでに同一スクリプト変数が定義済みのため，class属性で指定されたクラス（test.TestBeanIFインタフェース）からのインスタンス化はしないで，既存のオブジェクト（test.TestBeanクラスのインスタンス）を使用します。そのため，正常に実行されます。

07-00以降のバージョンの場合
test1_included.jspは，JSPトランスレーション時にclass属性に指定されたクラスのチェックを実施するため，JSPトランスレーションでエラーとなります。

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

07-00以降のバージョンで，JSPトランスレーション下位互換機能を使用するときと使用しないときの，コンパイルの動作の差異を次に示します。

インスタンス化できないクラス名をclass属性に指定した場合

JSPトランスレーション下位互換機能を使用する
2回目以降の<jsp:useBean>タグで指定したid属性値がエラーにならないで，Beanが取得できる。

JSPトランスレーション下位互換機能を使用しない
JSPのトランスレーション時にエラーになる。

(3)　JSPトランスレーション下位互換機能の定義

JSPトランスレーション下位互換機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.jsp.translation.backcompat.taglib.noCheckPrefix

JSPトランスレーション時に<jsp:useBean>タグのクラス属性値のチェック処理を実行するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

5.2.3　タグの属性値のExpressionチェックに関する注意事項

ここでは，タグの属性値のExpressionチェックに関する注意事項，JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異，およびJSPトランスレーション下位互換機能の定義について説明します。

＜この項の構成＞

(1)　注意事項

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

(3)　JSPトランスレーション下位互換機能の定義

(1)　注意事項

JSP仕様では，Expressionを指定できるタグの属性が制限されています。07-00以降のバージョンでは，JSPトランスレーション下位互換機能を使用しないでExpressionが指定できる属性以外でExpressionを指定した場合，JSPトランスレーション時にエラーになります。しかし，07-00より前のバージョンでは，JSPトランスレーション時にExpressionが指定できるかどうかをチェックしないため，Expressionを表す「<%=」や「%>」は文字列として認識されてエラーになりません。そのため，Expressionが指定できる属性以外でExpressionを指定した場合，07-00より前のバージョンと07-00以降のバージョンではJSPコンパイルの結果が異なります。

Expressionが指定できる属性以外でExpressionを指定しているJSPを使用する場合は，必ずJSPトランスレーション下位互換機能を設定してください。

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

07-00以降のバージョンで，JSPトランスレーション下位互換機能を使用するときと使用しないときの，コンパイルの動作の差異を次に示します。

Expressionの指定が許されていないタグの属性値に，Expressionを指定した場合

JSPトランスレーション下位互換機能を使用する
Expressionの指定が許されていないタグの属性値に指定したExpressionは，文字列として扱われる。

JSPトランスレーション下位互換機能を使用しない
JSPのトランスレーション時にエラーになる。

(3)　JSPトランスレーション下位互換機能の定義

JSPトランスレーション下位互換機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.jsp.translation.backcompat.tag.noCheckRtexprvalue

Expressionが指定できないタグの属性値にExpressionが指定されているかどうか検証するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

5.2.4　タグの属性値に指定するExpressionに関する注意事項

ここでは，タグの属性値に指定するExpressionに関する注意事項，JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異，およびJSPトランスレーション下位互換機能の定義について説明します。

＜この項の構成＞

(1)　注意事項

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

(3)　JSPトランスレーション下位互換機能の定義

(1)　注意事項

タグの属性値にExpressionを指定する場合，「"<%= scriptlet_expr %>"」または，「'<%= scriptlet_expr %>'」と指定します。

タグの属性値が，「"<%=」（または「'<%=」）で開始していて「%>"」（または「%>'」）で終了していない場合，07-00より前のバージョンでは，「"」（または「'」）で囲まれた値を文字列として扱います。例えば，「%>」と「"」の間に，任意の文字列がある場合は，「"」で囲まれた値を文字列として扱います。しかし，07-00以降のバージョンでは，「%>"」（または「%>'」）を属性値の末尾として扱うため，JSPトランスレーション時にエラーになります。

タグの属性値が，「"<%=」（または「'<%=」）で開始していて「%>"」（または「%>'」）で終了していない場合は，必ずJSPトランスレーション下位互換機能を設定してください。

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

07-00以降のバージョンで，JSPトランスレーション下位互換機能を使用するときと使用しないときの，コンパイルの動作の差異を次に示します。

タグの属性値が「"<%=」（または「'<%=」）で開始していて，「%>"」（または「%>'」）で終了していない場合

JSPトランスレーション下位互換機能を使用する
「"」（または，「'」）で囲まれた属性値を，文字列として処理する。

JSPトランスレーション下位互換機能を使用しない
「"」（または，「'」）で囲まれた属性値を，Expressionとして処理する。

(3)　JSPトランスレーション下位互換機能の定義

JSPトランスレーション下位互換機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.jsp.translation.backcompat.tag.rtexprvalueTerminate

タグの属性値が，「"<%=」または「'<%=」で開始しており，「%>"」（「'<%」で開始した場合は「%>'」）で終了していない属性値の「"」（または「'」）で囲まれた値を文字列として扱うかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

5.2.5　taglibディレクティブのprefix属性に関する注意事項

ここでは，taglibディレクティブのprefix属性に関する注意事項，JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異，およびJSPトランスレーション下位互換機能の定義について説明します。

＜この項の構成＞

(1)　注意事項

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

(3)　JSPトランスレーション下位互換機能の定義

(1)　注意事項

JSP仕様では，taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを指定できません。07-00以降のバージョンでは，JSP仕様に従って，taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを記述しているかをチェックします。taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを記述している場合，トランスレーション時にエラーになります。しかし，07-00より前のバージョンでは，このチェックをしないため，記述されたカスタムタグは，文字列として扱われます。

そのため，taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用してカスタムタグを記述している場合は，07-00より前と07-00以降のバージョンではJSPコンパイルの結果が異なります。

taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを記述している場合は，必ずJSPトランスレーション下位互換機能を設定してください。

(2)　JSPトランスレーション下位互換機能の使用有無によるJSPのコンパイルの動作の差異

07-00以降のバージョンで，JSPトランスレーション下位互換機能を使用するときと使用しないときの，コンパイルの動作の差異を次に示します。

taglibディレクティブの前に，taglibディレクティブで指定したprefixを使用したカスタムタグを記述している場合

JSPトランスレーション下位互換機能を使用する
カスタムタグではなく文字列として扱う。

JSPトランスレーション下位互換機能を使用しない
JSPのトランスレーション時にエラーになる。

(3)　JSPトランスレーション下位互換機能の定義

JSPトランスレーション下位互換機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.jsp.translation.backcompat.useBean.noCheckClass

JSPトランスレーション時に<jsp:useBean>タグのクラス属性値のチェック処理を実行するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

付録

＜この付録の構成＞

付録A　エラーステータスコード

付録B　Hitachi Web Serverの設定に関する注意事項

付録C　Microsoft IISの設定

付録D　Web Redirector

付録E　各バージョンでの主な機能変更

付録F　このマニュアルの参考情報

付録G　用語解説

付録A　エラーステータスコード

ここでは，Webコンテナ，リダイレクタ，およびインプロセスHTTPサーバが返すエラーステータスコードについて示します。

使用するWebサーバによって，エラーが発生する個所が異なります。エラーが発生する個所に応じたエラーステータスコードを参照してください。使用するWebサーバとエラーが発生する個所の対応について次の表に示します。

表A-1　使用するWebサーバとエラーが発生する個所の対応

使用するWebサーバ | エラーが発生する個所
Webコンテナ | リダイレクタ | インプロセスHTTPサーバ
Hitachi Web ServerまたはMicrosoft IIS | ○ | ○ | －
インプロセスHTTPサーバ | ○ | － | ○
簡易Webサーバ | ○ | － | －

（凡例）○：エラーが発生する。　－：エラーは発生しない。

＜この節の構成＞

付録A.1　Webコンテナが返すエラーステータスコード

付録A.2　リダイレクタが返すエラーステータスコード

付録A.3　インプロセスHTTPサーバが返すエラーステータスコード

付録A.1　Webコンテナが返すエラーステータスコード

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。Webコンテナが返すエラーステータスコードと，エラーステータスコードを返す条件を次の表に示します。

表A-2　Webコンテナが返すエラーステータスコードと条件

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
次のどちらかに該当する場合，エラーステータスコード400が返ります。

FORM認証で使用するログインページとして指定されたリソースに対して，クライアントから直接リクエストを送信し，その結果表示されたログインページからユーザ認証に成功した場合

次の三つの条件をすべて満たしているアクセスの場合

HTTPのバージョンが"HTTP/1.0"のとき

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承しているとき

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていないとき

Content-Lengthヘッダの値が2147483647より大きい，または0より小さいリクエストヘッダでアクセスされた場合

Content-Lengthヘッダの値が数値以外のリクエストヘッダでアクセスされた場合

Content-Lengthヘッダを複数含むリクエストヘッダでアクセスされた場合

リクエストURIを正規化できなかった場合

401　Unauthorized
BASIC認証を必要とするリソースに対して，次のようなアクセスがあった場合，エラーステータスコード401が返ります。

不正なユーザ名，またはパスワードでアクセスされた場合

認証情報を含まないでアクセスされた場合（Authorizationヘッダがないアクセス）。

403　Forbidden
次のどれかに該当する場合，エラーステータスコード403が返ります。

BASIC認証，またはFORM認証を必要とするリソースに対して，認可できないユーザ名でアクセスされた場合

web.xmlで，auth-constraint要素にrole-name要素を指定しないで，すべてのアクセスを許可しないとするリソースにアクセスされた場合※1

静的コンテンツに対して，PUTまたはDELETEメソッドでアクセスされた場合

web.xmlの<transport-guarantee>要素で，INTEGRALまたはCONFIDENTIALが設定されているリソースにhttpでアクセスされた場合※2

404　Not Found
次のどちらかのアクセスがあった場合，エラーステータスコード404が返ります。

存在しないリソースにアクセスされた場合

javax.servlet.UnavailableExceptionが発生しているサーブレット，またはJSPファイルにアクセスされた場合※3

405　Method Not Allowed
次の三つの条件をすべて満たしているアクセスの場合，エラーステータスコード405が返ります。

HTTPのバージョンが"HTTP/1.1"の場合

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承している場合

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていない場合

412　Precondition Failed
If-Matchヘッダ，またはIf-Unmodified-Sinceヘッダで指定した条件に一致しない静的コンテンツへのアクセスの場合，エラーステータスコード412が返ります。

413　Request Entity Too Large
リクエストボディのサイズが上限値を超えた場合，エラーステータスコード413が返ります。

416　Requested Range Not Satisfiable
次のどれかに当てはまる不正なRangeヘッダの値を使用した静的コンテンツへのアクセスの場合，エラーステータスコード416が返ります。

Rangeヘッダの値が"byte"から始まっていない

範囲定義に数字や"-"を使用していない

指定範囲が妥当ではない

500　Internal Server Error
次のどれかに該当する場合，エラーステータスコード500が返ります。

例外が発生するサーブレットまたはJSPファイルにアクセスされた場合※4

コンパイルに失敗したJSPファイルにアクセスされた場合

削除された静的コンテンツにアクセスされた場合※5

静的コンテンツへのアクセスでI/Oエラーが発生した場合

web.xmlの定義が不正な状態で，<auth-constraint>要素で保護されたリソースにアクセスされた場合※6

501　Not Implemented
静的コンテンツまたはjavax.servlet.http.HttpServletを継承したサーブレットに対して，GET，HEAD，POST，PUT，DELETE，OPTIONS，TRACEメソッド以外のHTTPメソッドでアクセスされた場合，エラーステータスコード501が返ります。

503　Service Unavailable
次のどれかに該当する場合，エラーステータスコード503が返ります。

リクエストの実行待ちキューに空きがない場合※7

javax.servlet.UnavailableExceptionが発生しているサーブレットまたはJSPファイルにアクセスされた場合※8

終了処理中のWebコンテナに対してアクセスされた場合

予期しないエラーまたは例外によって，異常な状態になったWebアプリケーションにアクセスされた場合

Webコンテナサーバで，Webコンテナサーバだけが起動して，Webアプリケーションが起動していない場合に，起動しなかったWebアプリケーションにアクセスされたとき

注※1　Webアプリケーションのバージョンが2.4以降の場合に該当します。

注※2　usrconf.propertiesのwebserver.connector.redirect_https.portキーに転送先のhttpsのポート番号を設定していない場合が該当します。

注※3　Webアプリケーションのバージョンが2.4以降の場合で，永久的に利用できないことを示すjavax.servlet.UnavailableExceptionが発生し，サーブレットおよびJSPファイルで例外をcatchしていないときが該当します。

注※4　次のような場合が該当します。

Webアプリケーションのバージョンが2.4以降の場合
サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合
web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

注※5　Webアプリケーションのリロード機能，JSPファイルの再コンパイル機能，またはJ2EEアプリケーションのリロード機能を使用しない場合が該当します。

注※6　web.xmlで<auth-constraint>要素に<role-name>要素が定義され，<login-config>要素が定義されていない場合に該当します。この状態でアプリケーションを開始すると，KDJE39150-Wの警告メッセージがコンソール画面，およびメッセージログに出力されます。

注※7　Webアプリケーション単位の同時実行スレッド数制御，またはURLグループ単位の同時実行スレッド数制御を設定している場合が該当します。

注※8　次のような場合が該当します。

Webアプリケーションのバージョンが2.4以降の場合
一時的に利用できないことを示す，javax.servlet.UnavailableExceptionが発生し，サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合
web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

付録A.2　リダイレクタが返すエラーステータスコード

Webコンテナとのデータ送受信時にタイムアウトが発生したり，定義ファイルに記載誤りがあったりすると，リダイレクタはエラーステータスコードを返します。リダイレクタが返すエラーステータスコードと，エラーステータスコードを返す条件を，Webサーバの種類ごとに表に示します。

表A-3　リダイレクタが返すエラーステータスコードと発生条件（Hitachi Web Serverの場合）

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
次のどちらかに該当する場合，エラーステータスコード400が返ります。

リクエストのHostヘッダのポート番号が不正な場合

リクエストのメソッドがPOSTではない場合※1

リクエストにContent-Lengthヘッダがない（POSTリクエストである場合，ボディがチャンク形式である）場合※1

リクエストのContent-Lengthヘッダの値が，POSTリクエスト転送先ワーカに設定されたPOSTデータサイズの上限を超えた値である場合※1

500　Internal Server Error
次のどれかに該当する場合，エラーステータスコード500が返ります。

mod_jk.confの内容に記述誤りがある場合※2

workers.propertiesの読み込みに失敗した場合，または内容に記述誤りがある場合※1

リクエストヘッダが16KBを超えている場合※3

Webコンテナとのコネクション確立に失敗した場合

Webコンテナとのコネクション確立でタイムアウトが発生した場合

Webコンテナへのデータ送信時にエラーが発生した場合

Webコンテナへのデータ送信時にタイムアウトが発生した場合

Webコンテナからのデータ受信時にエラーが発生した場合

Webコンテナからのデータ受信時にタイムアウトが発生した場合

クライアントからのPOSTデータの読み込みでタイムアウトが発生した場合

リクエストにサポートしないHTTPメソッド※4が指定されている場合

注※1　POSTデータサイズによる振り分けで，デフォルトワーカを指定していない場合が該当します。

注※2　Windowsの場合だけ該当します。UNIXの場合は起動に失敗します。

注※3　Hitachi Web Serverのリクエストヘッダの制限に関する設定で合計16KB以上のリクエストヘッダを受信可能にしている場合，該当するおそれがあります。

注※4　HTTPメソッドのサポート可否については，表A-5を参照してください。

表A-4　リダイレクタが返すエラーステータスコードと発生条件（Microsoft IISの場合）

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
次のどちらかの場合，エラーステータスコード400が返ります。

リクエストURLに"%"を含み，さらに"%"のあとに続く2文字が16進数を表さない文字（A～F，a～f，または0～9以外の文字）の場合

リクエストのHostヘッダのポート番号が不正の場合

403　Forbidden
次のどちらかの場合，エラーステータスコード403が返ります。

リクエストURLが"hitachi_ccfj"から始まる場合※1

リクエストURLに"%2F"が含まれる場合※1

500　Internal Server Error
次のどれかに該当する場合，エラーステータスコード500が返ります。

isapi_redirect.confの内容に記述誤りがある場合

workers.propertiesの読み込みに失敗した場合，または内容に記述誤りがある場合

リクエストヘッダが16KBを超えている場合※2

Webコンテナとのコネクション確立に失敗した場合

Webコンテナとのコネクション確立でタイムアウトが発生した場合

Webコンテナへのデータ送信時にエラーが発生した場合

Webコンテナへのデータ送信時にタイムアウトが発生した場合

Webコンテナからのデータ受信時にエラーが発生した場合

Webコンテナからのデータ受信時にタイムアウトが発生した場合

クライアントからのPOSTデータの読み込みでタイムアウトが発生した場合

リクエストにサポートしないHTTPメソッド※3が指定されている場合

注※1　大文字・小文字の区別はありません。

注※2　Microsoft IISのリクエストヘッダの制限に関する設定で合計16KB以上のリクエストヘッダを受信可能にしている場合，該当するおそれがあります。

注※3　HTTPメソッドのサポート可否については，表A-5を参照してください。

リダイレクタでのリクエストのHTTPメソッドのサポート可否

リダイレクタでのリクエストのHTTPメソッドのサポート可否について，次の表に示します。

表A-5　リダイレクタでのリクエストのHTTPメソッドのサポート可否

HTTPメソッド | サポート可否
OPTIONS | ○
GET | ○
HEAD | ○
POST | ○
PUT | ○
DELETE | ○
TRACE | ○
CONNECT | ×※
PROPFIND | ○
PROPPATCH | ○
MKCOL | ○
COPY | ○
MOVE | ○
LOCK | ○
UNLOCK | ○
ACL | ○
REPORT | ○
VERSION-CONTROL | ○
CHECKIN | ○
CHECKOUT | ○
UNCHECKOUT | ○
SEARCH | ○
上記以外のHTTP1.1で使用できるメソッド | ×※

（凡例）○：サポートする　×：サポートしない

注※

サポートしないHTTPメソッドが指定されているリクエストには，リダイレクタがステータス500エラーを返します。また，メッセージKDJE41001-Eが出力されます。

付録A.3　インプロセスHTTPサーバが返すエラーステータスコード

クライアントからのリクエストのサイズが上限値を超えたり，値が不正だったりした場合，インプロセスHTTPサーバはエラーステータスコードを返します。インプロセスHTTPサーバが返すエラーステータスコードとエラーステータスコードを返す条件を次の表に示します。

表A-6　インプロセスHTTPサーバが返すエラーステータスコードと条件

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
リクエストの状態が次のどれかの場合，エラーステータスコード400が返ります。

リクエストのHTTPのバージョンが1.1で，Hostヘッダがない場合

リクエストのHostヘッダのポート番号が不正な場合

リクエストヘッダのサイズが上限値を超えた場合

リクエストヘッダの数が上限値を超えた場合

リクエストURIが不正な場合

リクエストURIのデコードに失敗した場合

リクエストURIを正規化できなかった場合

リクエストのContent-Lengthヘッダの値が2147483647より大きい，または0より小さい場合

リクエストのContent-Lengthヘッダの値が数値以外の場合

リクエストのContent-Lengthヘッダが複数指定されている場合

リクエストラインのHTTPのバージョンがサポートされていない場合

403　Forbidden
web.xmlの<transport-guarantee>要素で，INTEGRALまたはCONFIDENTIALが設定されているリソースにhttpでアクセスされた場合，エラーステータスコード403が返ります。

405　Method Not Allowed
許可しないHTTPメソッドからアクセスがあった場合，エラーステータスコード405が返ります。

413　Request entity too large
リクエストボディのサイズが上限値を超えた場合，エラーステータスコード413が返ります。

414　Request-URI too large
リクエストラインの長さが上限値を超えた場合，エラーステータスコード414が返ります。

500　Internal Server Error
リダイレクト機能によってステータスコード200でファイルを返す際にファイルの読み込みに失敗した場合，エラーステータスコード500が返ります。

501　Not implemented
リクエストのtransfer-encodingヘッダの値が，サポートされていない場合に，エラーステータスコード501が返ります。

503　Service Unavailable
流量制御の上限を超えてリクエスト処理を実行しようとした場合，エラーステータスコード503が返ります。

付録B　Hitachi Web Serverの設定に関する注意事項

ここでは，Hitachi Web Serverの設定に関する注意事項について説明します。

＜この節の構成＞

付録B.1　Hitachi Web Serverの再起動時の注意事項

付録B.2　リダイレクタのログに関する注意事項

付録B.3　Hitachi Web Serverのアップグレード時の注意事項

付録B.1　Hitachi Web Serverの再起動時の注意事項

Hitachi Web Serverの再起動に失敗した原因が，簡易構築定義ファイル（Smart Composer機能を使用しない場合はリダイレクタ定義ファイル（mod_jk.conf），またはワーカ定義ファイル（workers.properties））にある場合，次のどちらかにメッセージが出力されます。

Hitachi Web Serverの起動コマンド実行画面またはイベントログ

Hitachi Web Serverをコマンドプロンプトから起動，停止，または再起動するときは，起動コマンド実行画面に出力されます。

Hitachi Web Serverをサービスから起動，停止，または再起動するときは，イベントログに出力されます。Windowsの場合だけが該当します。

Hitachi Web Serverのエラーログファイル
エラーログファイルは，デフォルトでは次の場所に出力されます。

Windowsの場合
<Hitachi Web Serverのインストールディレクトリ>¥logs¥error.log

UNIXの場合
opt/hitachi/httpsd/logs/error.log

それぞれに出力されるメッセージを表に示します。

表B-1　Hitachi Web Serverの起動コマンド実行画面またはイベントログに出力されるメッセージ

メッセージ
原因・対策方法

JkWorkersFile file_name invalid※
JkWorkersFileキーに指定されたファイル名が無効です。JkWorkersFileキーに指定している値を修正したあと，Webサーバを再起動してください。

Can't find the workers file specified※
指定されたワーカ定義ファイルが見つかりません。JkWorkersFileキーに指定されているファイルの有無を確認したあと，Webサーバを再起動してください。

Content should start with /※
URLパターンの先頭文字が「/」（スラント）以外です。JkMountキーに指定されているURLパターンの先頭文字を「/」（スラント）に修正したあと，Webサーバを再起動してください。

JkOptions: Illegal option 'a...a'
JkOptionキーに指定された値（a...a）は不正です。
JkOptionキーに指定している値を修正したあと，Webサーバを再起動してください。

a...a takes b...b arguments,
a...aに示すキーに指定できる値の数はb...bです。
a...aに示すキーに指定している値の数を修正したあと，Webサーバを再起動してください。

a...a must be On or Off
a...aに示すキーに指定できる値はOnまたはOffです。
a...aに示すキーに指定している値をOnまたはOffにしたあと，Webサーバを再起動してください。

JkModulePriority: Invalid value specified.a...a
JkModulePriorityキーに設定された値a...aが不正です。JkModulePriorityキーに正しい値を設定して，Webサーバを再起動してください。

注※　UNIXの場合だけ出力されるメッセージです。

表B-2　Hitachi Web Serverのエラーログファイル

メッセージ
説明・対策方法

[時刻] [emerg] Memory error
メモリが不足しています。
システムが利用できるメモリ使用量を確保したあと，Webサーバを再起動してください。

[時刻] [emerg] Error while opening the workers※
次のどちらかの問題が発生しています。

ワーカ定義ファイルのオープンに失敗しました。
JkWorkersFileキーに指定されているファイルのアクセス権に読み取り権限があることを確認したあと，Webサーバを再起動してください。

ワーカ定義ファイルの内容が不正です。
ワーカ定義ファイルの内容を正しく修正したあと，Webサーバを再起動してください。

[時刻] [emerg] Error while checking the mod_jk.conf※
リダイレクタ定義ファイルに不適切な記述がありました。リダイレクタに出力されているメッセージを確認したあと，Webサーバを再起動してください。

注※　UNIXの場合だけ出力されるメッセージです。

付録B.2　リダイレクタのログに関する注意事項

ログ出力先ディレクトリにHitachi Web Serverの実行アカウントの書き込み権限がない場合，リクエストは正常に処理されますが，ログは出力されません。

Windowsの場合，デフォルトの状態ではリダイレクタのログ出力先ディレクトリ（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥logs）がありません。このため，Hitachi Web Serverは，起動時に一つ上のディレクトリ（redirectorディレクトリ）のアクセス権を引き継いで，logsディレクトリを生成してログを出力しようとします。このとき，Hitachi Web Serverの実行アカウントの書き込み権限がないとログは出力されません。この場合は，logsディレクトリを生成してアクセス権を設定するか，または一つ上のディレクトリ（redirectorディレクトリ）にアクセス権を設定してください。
また，リダイレクタのログ出力先ディレクトリを変更している場合に，指定しているパスが途中までしかないときは，存在する最下層のディレクトリに対してアクセス権を設定するか，または指定したパスに対応するディレクトリをすべて作成して，最下層のディレクトリにアクセス権を設定してください。

付録B.3　Hitachi Web Serverのアップグレード時の注意事項

Hitachi Web Serverをアップグレードした場合，Hitachi Web Server用のリダイレクタの変更内容を反映するためには，Hitachi Web Serverを再起動する必要があります。Hitachi Web Serverの再起動の方法については，マニュアル「Hitachi Web Server」を参照してください。

付録C　Microsoft IISの設定

ここでは，Microsoft IISを使用してWebサーバと連携する場合の設定方法について説明します。

Microsoft IISの設定は，Microsoft IIS 6.0の場合と，Microsoft IIS 7.0またはMicrosoft IIS 7.5の場合で異なります。

＜この節の構成＞

付録C.1　Microsoft IIS 6.0の設定

付録C.2　Microsoft IIS 7.0またはMicrosoft IIS 7.5の設定

付録C.1　Microsoft IIS 6.0の設定

ここでは，Microsoft IISを使用してWebサーバと連携する場合のMicrosoft IIS 6.0の設定方法について説明します。

J2EEサーバとMicrosoft IIS 6.0との連携は，次に示す手順で設定します。

仮想ディレクトリの作成

Webサーバの認証機能の解除

ISAPIフィルタの設定

Webサービス拡張の設定

WWWサービスの起動と動作確認

＜この項の構成＞

(1)　仮想ディレクトリの作成

(2)　Webサーバの認証機能の解除

(3)　ISAPIフィルタの設定

(4)　Webサービス拡張の設定

(5)　リダイレクタのログ出力先ディレクトリへのアクセス権の設定

(6)　WWWサービスの起動と動作確認

(7)　ほかのフィルタと共存させる場合の注意事項

(1)　仮想ディレクトリの作成

「hitachi_ccfj」という名称の仮想ディレクトリを作成します。仮想ディレクトリの作成の手順を次に示します。

［スタート］メニューの［すべてのプログラム］－［管理ツール］から，インターネット インフォメーション サービス（IIS）マネージャを起動します。

インターネット インフォメーション サービス（IIS）マネージャの左側ツリービューの「Webサイト」の下にある「既定のWebサイト」を右クリックし，表示されるメニューから［新規作成］－［仮想ディレクトリ］を選択します。

仮想ディレクトリの作成ウィザードダイアログが表示されたら，［次へ］ボタンをクリックします。
［仮想ディレクトリ エイリアス］画面が表示されます。

「エイリアス」欄に「hitachi_ccfj」と入力します。

［次へ］ボタンをクリックします。
ディレクトリの物理パスを入力する画面が表示されます。

isapi_redirect.dllが格納されているディレクトリ（デフォルトは，<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector）を指定します。

［次へ］ボタンをクリックします。
仮想ディレクトリのアクセス許可を設定する画面が表示されます。

「ISAPIアプリケーションやCGIなどを実行する」をチェックします。

［次へ］ボタンをクリックして終了します。

仮想ディレクトリ「hitachi_ccfj」を右クリックし，メニューから「プロパティ」を選択します。
プロパティダイアログが表示されます。

(2)　Webサーバの認証機能の解除

Webコンテナの認証機能を使用する場合，次に示すWebサーバの認証機能の解除が必要になります。

ダイジェスト認証
Webコンテナの認証機能の使用の有無に関係なく，必ず解除してください。

統合Windows認証
Webコンテナの認証機能（Basic認証）を使用する場合は解除してください。

Passport認証
Webコンテナが管理するリソースへアクセスする場合は解除してください。

ダイジェスト認証，統合Windows認証，およびPassport認証を解除する手順を次に示します。

「hitachi_ccfj」のプロパティダイアログで，［ディレクトリ セキュリティ］タブを選択します。

「認証とアクセス制御」の［編集］ボタンをクリックします。
［認証方法］画面が表示されます。

［認証方法］画面で，「Windowsドメインサーバーでダイジェスト認証を使用する」のチェックを外し，ダイジェスト認証を解除します（必須）。
Webコンテナの認証機能の使用の有無に関係なく，ダイジェスト認証は必ず解除してください。

［認証方法］画面で，「統合Windows認証」のチェックを外し，統合Windows認証を解除します（任意）。
WebコンテナのBasic認証を設定している場合は，必ず解除してください。

［認証方法］画面で，「.NET パスポート認証」のチェックを外し，Passport認証を解除します（任意）。
Webコンテナが管理するリソースへアクセスする場合は解除してください。

［OK］ボタンをクリックして各ウィンドウを閉じます。

(3)　ISAPIフィルタの設定

ISAPIフィルタの設定の手順を次に示します。

インターネット インフォメーション サービス（IIS）マネージャの左側ツリービュー内の「Webサイト」を右クリックし，表示されるメニューから「プロパティ」を選択します。

［Webサイトのプロパティ］画面が表示されたら，［ISAPIフィルタ］タブを選択します。

［追加］ボタンをクリックします。
［フィルタのプロパティの追加と編集］画面が表示されます。

フィルタ名に「hitachi_ccfj」，実行可能ファイルに「<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll」を指定します。

［OK］ボタンをクリックします。
［Webサイトのプロパティ］画面が表示されます。

フィルタ名に「hitachi_ccfj」が登録されたのを確認して，［適用］ボタンをクリックします。

インターネット インフォメーション サービス（IIS）マネージャを終了します。

注意

ISAPIフィルタを追加すると，「hitachi_ccfj」の優先順位に「*不明*」と表示されますが，動作に問題はありません。初回リクエスト処理後に，isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）のfilter_priorityキーで指定した優先順位が表示されます。

(4)　Webサービス拡張の設定

Webサービス拡張の設定の手順を次に示します。

インターネット インフォメーション サービス（IIS）マネージャの左側ツリービュー内の［Webサービス拡張］を選択します。
右側のビューに，Webサービス拡張状態の一覧が表示されます。

Webサービス拡張状態の一覧から「すべての不明なISAPI拡張」を右クリックし，表示されるメニューから「許可」を選択します。

(5)　リダイレクタのログ出力先ディレクトリへのアクセス権の設定

Microsoft IISと連携する場合，リダイレクタの実行アカウントは「NetworkService」となります。このため，リダイレクタのログ出力先ディレクトリのアクセス権に，Usersグループに対する書き込み権限を付加しておく必要があります。エクスプローラから，リダイレクタのログ出力先ディレクトリにアクセス権を設定してください。

なお，新規インストール時には，デフォルトの状態ではリダイレクタのログ出力先ディレクトリ（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥logs）がありません。このため，logsディレクトリを作成してアクセス権を設定するか，または一つ上のディレクトリ（redirectorディレクトリ）にアクセス権を設定してください。

また，リダイレクタのログ出力先ディレクトリを変更している場合に，指定しているパスが途中までしか存在しないときは，存在する最下層のディレクトリに対してアクセス権を設定するか，または指定したパスに対応するディレクトリをすべて作成して，最下層のディレクトリにアクセス権を設定してください。

(6)　WWWサービスの起動と動作確認

Microsoft IISのWWWサービスの起動と動作確認の手順を次に示します。

［スタート］メニューの［すべてのプログラム］－［管理ツール］から，［サービス］を選択します。
サービス一覧が表示されます。

サービス一覧の中から「World Wide Web Publishing Service」を選択します。

［サービスの開始］アンカーをクリックします。
WWWサービスが再起動します。

(7)　ほかのフィルタと共存させる場合の注意事項

Microsoft IISが受信したリクエストが，Webコンテナに転送するリクエストの場合，Microsoft IIS用リダイレクタはISAPIフィルタ内で使用するリクエストURL情報を変更します。そのため，Microsoft IIS用リダイレクタよりあとに実行されるISAPIフィルタでは，Microsoft IISが受信したリクエストURLを取得できません。Microsoft IISが受信したリクエストURLをフィルタで取得する場合は，Microsoft IIS用リダイレクタよりも順番が先になるように設定してください。順番を調整するために，Microsoft IIS用リダイレクタの優先順位を「中」または「低」に変更する必要がある場合は，isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）のfilter_priorityキーで指定します。isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）のfilter_priorityキーの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

付録C.2　Microsoft IIS 7.0またはMicrosoft IIS 7.5の設定

ここでは，Microsoft IIS を使用してWeb サーバと連携する場合のMicrosoft IIS 7.0またはMicrosoft IIS 7.5の設定方法について説明します。

J2EEサーバとMicrosoft IIS 7.0またはMicrosoft IIS 7.5との連携は，次に示す手順で設定します。

役割サービスのインストール

ISAPIおよびCGIの制限の追加

ISAPIフィルタの追加

ハンドラマッピングの設定

仮想ディレクトリの追加

［サーバー］ノードでのアプリケーションプールの設定

［サイト］ノードでのアプリケーションプールの設定

リダイレクタログ出力先ディレクトリへのアクセス権の設定

Webサイトの開始

参考

Microsoft IIS 7.0とMicrosoft IIS 7.5では，画面表記が一部異なります。以降の手順では，Microsoft IIS 7.5の場合の表記で説明します。Microsoft IIS 7.0を使用している場合は，次の表に示すとおりに読み替えてください。

Microsoft IIS 7.5の画面表記 | Microsoft IIS 7.0の画面表記
サーバーマネージャー | サーバーマネージャ
インターネット インフォメーション サービス（IIS）マネージャー | インターネット インフォメーション サービス（IIS）マネージャ
ISAPIフィルター | ISAPIフィルタ
フィルター名 | フィルタ名
ハンドラー マッピング | ハンドラ マッピング
ワーカー プロセス | ワーカ プロセス

Microsoft IIS 7.0またはMicrosoft IIS 7.5の設定で使用する，［インターネット インフォメーション サービス（IIS）マネージャー］の画面構成を次に示します。

以降で示す手順に従って，［接続］ウィンドウ，［機能ビュー］，［操作］ウィンドウなどで設定を実施してください。

＜この項の構成＞

(1)　役割サービスのインストール

(2)　ISAPIおよびCGIの制限の追加

(3)　ISAPIフィルタの追加

(4)　ハンドラマッピングの設定

(5)　仮想ディレクトリの追加

(6)　［サーバー］ノードでのアプリケーションプールの設定

(7)　［サイト］ノードでのアプリケーションプールの設定

(8)　リダイレクタログ出力先ディレクトリへのアクセス権の設定

(9)　Webサイトの開始

(10)　注意事項

(1)　役割サービスのインストール

Microsoft IIS 7.0またはMicrosoft IIS 7.5を使用する場合，用途に応じた役割サービスをインストールする必要があります。役割サービスをインストールする手順を次に示します。

［スタート］メニューの［すべてのプログラム］－［管理ツール］から，［サーバーマネージャー］を起動します。

［サーバーマネージャー］の［役割］を選択し，［Webサーバー(IIS)］の［役割サービスの追加］をクリックします。

［役割サービスの追加］ダイアログで，次に示す役割サービスを選択します。

静的なコンテンツ

既定のドキュメント

ディレクトリの参照

HTTPエラー

ISAPI拡張

ISAPIフィルター

IIS管理コンソール

［インストール］をクリックします。

［閉じる］をクリックします。
インストールが完了します。

(2)　ISAPIおよびCGIの制限の追加

ISAPIおよびCGIの制限を追加する手順を次に示します。

［スタート］メニューの［すべてのプログラム］－［管理ツール］から，［インターネット インフォメーション サービス（IIS）マネージャー］を起動します。

［機能ビュー］のサーバの［ホーム］ページで，［ISAPIおよびCGI制限］をダブルクリックします。

［ISAPIおよびCGI制限］ページの［操作］ウィンドウで［追加］をクリックします。

［ISAPIまたはCGIの制限の追加］ダイアログで次の操作をします。

［ISAPIまたはCGIパス］にリダイレクタのDLL（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）を指定します。

［説明］に「ISAPI」と入力します。

［拡張パスの実行を許可する］をチェックします。

［OK］ボタンをクリックします。
［ISAPIまたはCGIの制限の追加］ダイアログが閉じて，設定が反映されます。

(3)　ISAPIフィルタの追加

ISAPIフィルタを追加する手順を次に示します。

［機能ビュー］のサイトの［ホーム］ページで［ISAPIフィルター］をダブルクリックします。

［ISAPIフィルター］ページの［操作］ウィンドウで［追加］をクリックします。

［ISAPIフィルターの追加］ダイアログで次の操作をします。

［フィルター名］に「hitachi_ccfj」と入力します。

［実行可能ファイル］にリダイレクタのDLL（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）を指定します。

［OK］ボタンをクリックします。
［ISAPIフィルターの追加］ダイアログが閉じて，設定が反映されます。

(4)　ハンドラマッピングの設定

ハンドラマッピングを設定する手順を次に示します。

［機能ビュー］のサイトの［ホーム］ページで［ハンドラー マッピング］をダブルクリックします。

［ハンドラー マッピング］ページで「ISAPI-dll」を選択し，［操作］ウィンドウで［編集...］をクリックします。

［モジュール マップの編集］ダイアログで次の操作をします。

［要求パス］に「*.dll」と入力します。

［実行可能ファイル］にリダイレクタのDLL（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）を指定します。

すでにハンドラマッピングが設定されている場合，［スクリプトマップの編集］ダイアログが起動しますが，操作内容は同じです。

［OK］ボタンをクリックします。

モジュールマップの編集を有効にするかどうかを確認するメッセージダイアログで，ISAPI拡張機能を有効にするために，［はい］ボタンをクリックします。

［ハンドラー マッピング］ページで「ISAPI-dll」を選択し，［操作］ウィンドウで［機能のアクセス許可の編集...］をクリックします。

［機能のアクセス許可の編集］ダイアログで「読み取り」，「スクリプト」および「実行」のすべてのアクセス許可をチェックします。

［OK］ボタンをクリックします。
［機能のアクセス許可の編集］ダイアログが閉じて，設定が反映されます。

(5)　仮想ディレクトリの追加

「hitachi_ccfj」という名称の仮想ディレクトリを追加します。仮想ディレクトリを追加する手順を次に示します。

［接続］ウィンドウで［サイト］ノードを展開し，仮想ディレクトリを追加するサイトをクリックします。

［操作］ウィンドウで，［仮想ディレクトリの表示］をクリックします。
［仮想ディレクトリ］ページが表示されます。

［仮想ディレクトリ］ページの［操作］ウィンドウで，［仮想ディレクトリの追加...］をクリックします。

［仮想ディレクトリの追加］ダイアログで次の操作をします。

［エイリアス］に「hitachi_ccfj」と入力します。

［物理パス］にリダイレクタのDLL（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）が格納されているディレクトリを指定します。

［OK］ボタンをクリックします。
［仮想ディレクトリの追加］ダイアログが閉じて，設定が反映されます。

(6)　［サーバー］ノードでのアプリケーションプールの設定

［サーバー］ノードでのアプリケーションプールの設定手順を次に示します。

［接続］ウィンドウでサーバノードを展開し，［アプリケーション プール］をクリックします。

［アプリケーション プール］ページで，使用するアプリケーションプールを選択し，［操作］ウィンドウの［詳細設定］をクリックします。

［詳細設定］ダイアログで次の操作をします。

［32ビットアプリケーションの有効化］に「True」を指定します（64ビットOSの場合だけに必要な指定です）。

［ワーカー プロセスの最大数］※に，Microsoft IIS内でリクエストを処理するプロセスの最大数を指定します。

注※

このマニュアルでは，Webコンテナの実行プロセスのことも「ワーカプロセス」と表記していますが，ここで設定する「ワーカー プロセス」とはMicrosoft IIS内でリクエストを処理するプロセスを指します。

［OK］ボタンをクリックします。
［詳細設定］ダイアログが閉じて，設定が反映されます。

(7)　［サイト］ノードでのアプリケーションプールの設定

サイトノードでのアプリケーションプールの設定手順を次に示します。

［接続］ウィンドウで［サイト］ノードを展開し，アプリケーションプールを指定するサイトをクリックします。

［操作］ウィンドウで，［詳細設定］をクリックします。

［詳細設定］ダイアログで，［アプリケーションプール］を入力します。
［アプリケーションプール］に，「(6) ［サーバー］ノードでのアプリケーションプールの設定」で設定したアプリケーションプールの名称を指定します。

［OK］ボタンをクリックします。
［詳細設定］ダイアログが閉じて，設定が反映されます。

(8)　リダイレクタログ出力先ディレクトリへのアクセス権の設定

リダイレクタのログ出力先ディレクトリには，Microsoft IISのアプリケーションプールの実行アカウントに対する書き込み権限を付加しておく必要があります。エクスプローラから，リダイレクタのログ出力ディレクトリにアクセス権を設定してください。

アプリケーションプールの実行アカウントは，アプリケーションプールの［詳細設定］ダイアログの［ID］で指定します。デフォルトのIDを指定している場合は，「IIS_IUSRS」グループに対して書き込み権限を付加してください。

デフォルトのIDは次のとおりです。

Microsoft IIS 7.0：「NetworkService」

Microsoft IIS 7.5：「ApplicationPoolIdentity」

なお，新規インストール時には，デフォルトの状態ではリダイレクタのログ出力先ディレクトリ（<Cosminexusのインストールディレクトリ>¥CC¥web¥redirector¥logs）がありません。このため，logsディレクトリを作成してアクセス権を設定するか，または一つ上のディレクトリ（redirectorディレクトリ）にアクセス権を設定してください。

また，リダイレクタのログ出力先ディレクトリを変更している場合に，指定しているパスが途中までしかないときは，存在する最下層のディレクトリに対してアクセス権を設定するか，または指定したパスに対応するディレクトリをすべて作成して，最下層のディレクトリにアクセス権を設定してください。

(9)　Webサイトの開始

Microsoft IISのWebサイトの開始の手順を次に示します。

［接続］ウィンドウで［サイト］ノードを展開し，開始するサイトをクリックします。

［操作］ウィンドウで，［開始］をクリックします。開始済みの場合は，［再起動］をクリックします。
Webサイトが開始，または再起動します。

(10)　注意事項

ここでは，Microsoft IIS 7.0またはMicrosoft IIS 7.5の設定時の注意事項について説明します。

(a)　構成設定の複数環境へのレプリケーションについての注意事項

Microsoft IIS 7.0またはMicrosoft IIS 7.5では，構成設定をweb.configファイルに保存できます。また，保存したweb.configファイルを基に，xcopyを使用して複数環境に構成環境をレプリケーションできます。

ただし，リダイレクタを使用する構成環境の場合，xcopyでの複数環境へのレプリケーションでリダイレクタの設定はできません。xcopyで複数環境を同一の構成設定にする場合も，リダイレクタの設定は環境ごとに手動で同期してください。

(b)　エラーページのカスタマイズについての注意事項

Microsoft IIS 7.0またはMicrosoft IIS 7.5でエラーページにカスタムエラーページを返す設定にしている場合，web.xmlの<error-page>タグによるエラーページのカスタマイズは無効となることがあります。web.xmlの<error-page>タグによるエラーページのカスタマイズを有効にしたい場合は，Microsoft IIS 7.0またはMicrosoft IIS 7.5のエラーページのカスタムエラーページの設定を無効にしてください。

付録D　Web Redirector

Web Redirectorは，WebサーバとWebコンテナを連携させるためのWebリダイレクタ環境を構築するための製品です。WebサーバとWebコンテナを別のサーバマシンで運用するシステムで，Webサーバを配置するサーバマシンにWeb Redirectorをインストールして使用します。アプリケーションサーバに含まれるコンポーネントのうち，Webリダイレクタ環境に必要なコンポーネント，またはそのサブセットに当たるコンポーネントによって構成されています。

なお，Web Redirectorの対象OSはWindowsとLinuxだけです。

ここでは，Web Redirectorに関連する次の項目について説明します。

インストール手順

環境変数の設定

Webサーバの設定

Web Redirectorのディレクトリ構成

Web Redirectorの機能

参考

同一のサーバマシン上に，複数のWebリダイレクタ環境を構築する場合は，Management Serverを使用して構築してください。

＜この節の構成＞

付録D.1　Web Redirectorのインストール手順

付録D.2　環境変数の設定

付録D.3　Webサーバの設定

付録D.4　Web Redirectorのディレクトリ構成

付録D.5　Web Redirectorの機能

付録D.1　Web Redirectorのインストール手順

ここでは，Web Redirectorのインストール手順について説明します。

Web Redirectorのインストール手順を次に示します。

Web Redirectorをインストールします。
インストール後のWeb Redirectorのディレクトリ構成については，「付録D.4　Web Redirectorのディレクトリ構成」を参照してください。

環境変数を設定します。
Web Redirectorで設定が必要な環境変数については，「付録D.2　環境変数の設定」を参照してください。

リソースおよびメモリ所要量を見積もって設定します。
Web Redirectorをインストールしたマシンで使用するリソースの見積もりと設定をします。リソースの見積もりと設定については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」を参照してください。

Webリダイレクタ環境を構築します。
Webリダイレクタを使用する環境を構築するためには，Webサーバの設定が必要です。Webサーバの設定については，「付録D.3　Webサーバの設定」を参照してください。

ポイント

Web Redirectorを使用してWebリダイレクタ環境を構築する場合は，各ユーザ定義ファイルの格納ディレクトリの「<Cosminexusのインストールディレクトリ>¥CC，または/opt/Cosminexus/CC」を，「<Cosminexusのインストールディレクトリ>¥CCR，または/opt/Cosminexus/CCR」と読み替えてください。

付録D.2　環境変数の設定

Web Redirectorを使用する場合に設定が必要な環境変数について，OSごとに説明します。環境変数の詳細については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.3.2　環境変数の詳細」を参照してください。

＜この項の構成＞

(1)　Windowsの場合

(2)　Linuxの場合

(1)　Windowsの場合

Windowsの場合に設定する環境変数と設定値を次の表に示します。

表D-1　設定する環境変数と設定値（Windowsの場合）

環境変数名 | 設定値
PRFSPOOL※ | <Cosminexusのインストールディレクトリ>¥PRF¥spool
TZ | JST-9　など

注※　インストーラによって設定されます。

注意

CLASSPATHは空にしてください。CLASSPATHは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。簡易構築定義ファイルの指定内容を次に示します。

<param-name>タグ

add.class.path

<param-value>タグ

設定値

(2)　Linuxの場合

Linuxの場合に設定する環境変数と設定値を次の表に示します。

表D-2　設定する環境変数と設定値（Linuxの場合）

環境変数名 | 設定値
PRFSPOOL | /opt/Cosminexus/PRF/spool
TZ | JST-9　など

注意

CLASSPATHは空にしてください。CLASSPATHは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。簡易構築定義ファイルの指定内容を次に示します。

<param-name>タグ

add.class.path

<param-value>タグ

設定値

付録D.3　Webサーバの設定

Webリダイレクタ環境を構築するには，Webサーバの設定が必要です。ここでは，Webリダイレクタ環境の構築に必要な，J2EEサーバとWebサーバとの連携に必要な設定方法を説明します。

＜この項の構成＞

(1)　Hitachi Web Serverの設定

(2)　Microsoft IISの設定

(1)　Hitachi Web Serverの設定

J2EEサーバとHitachi Web Serverとの連携は，次に示す手順で設定します。

httpsd.conf（Hitachi Web Server定義ファイル）に次の行を追加します。

Windowsの場合
Include "<Cosminexusのインストールディレクトリ>/CC/web/redirector/mod_jk.conf"

Linuxの場合
Include /opt/Cosminexus/CC/web/redirector/mod_jk.conf

Hitachi Web Serverを再起動します。

httpsd.confの詳細，および再起動の方法については，マニュアル「Hitachi Web Server」を参照してください。

また，Hitachi Web Serverの設定に関する注意事項については，「付録B　Hitachi Web Serverの設定に関する注意事項」を参照してください。

(2)　Microsoft IISの設定

Microsoft IISの設定については，「付録C　Microsoft IISの設定」を参照してください。

付録D.4　Web Redirectorのディレクトリ構成

Web Redirectorと，その構成ソフトウェアであるCosminexus Component Container - Redirectorのディレクトリ構成をOSごとに図に示します。

図D-1　Web Redirectorのディレクトリ構成（Windowsの場合）

図D-2　Web Redirectorのディレクトリ構成（Linuxの場合）

付録D.5　Web Redirectorの機能

Web Redirectorには，次の機能があります。

Webサーバの構築
Hitachi Web ServerまたはMicrosoft IISを使用してWebサーバを構築できます。Hitachi Web Serverについては，マニュアル「Hitachi Web Server」を参照してください。

リダイレクタによるリクエスト振り分けの実行
Webサーバに登録したリダイレクタによってWebコンテナへのリクエスト振り分けができます。リクエスト振り分けについては，「3.2　Webサーバ（リダイレクタ）によるリクエストの振り分け」を参照してください。

WebコンテナおよびWebサーバの通信タイムアウト
クライアント－Webサーバ間，Webサーバ－Webコンテナ間で，リクエスト受信時およびレスポンス送信時の通信タイムアウトを設定しておき，トラブル発生時の応答待ちなどの場合に通信タイムアウトを検知できます。通信タイムアウトについては，「3.6　通信タイムアウト（Webサーバ連携）」を参照してください。

エラーページのカスタマイズ
クライアントから存在しないリソースに対してアクセスした場合などに，クライアントからのリクエストに対してユーザがカスタマイズしたエラーページを表示できます。エラーページの表示は，リダイレクタが実行します。エラーページのカスタマイズについては，「3.8　エラーページのカスタマイズ（Webサーバ連携）」を参照してください。

Webコンテナへのゲートウェイ情報の通知
クライアントとWebサーバとの間にSSLアクセラレータや負荷分散機などのゲートウェイを配置している場合に，Webコンテナにゲートウェイ情報を通知して，welcomeファイルやFORM認証画面に自動的に正しくリダイレクトできます。Webコンテナへのゲートウェイ情報の通知については，「3.10　Webコンテナへのゲートウェイ情報の通知」を参照してください。

性能解析トレース出力
Webサーバに登録したリダイレクタからリクエストを送信するときの性能解析情報を出力できます。出力した性能解析情報は，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて分析できます。
性能解析トレース出力については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「6.　性能解析トレースを使用したシステムの性能解析」を参照してください。

参考

各機能のWebリダイレクタ環境での設定については，「3.　Webサーバ連携」に記載されている機能の設定のうち，Smart Composer機能を使用しない場合の設定を参照してください。

付録E　各バージョンでの主な機能変更

ここでは，08-70よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。08-70での主な機能変更については，「1.4　アプリケーションサーバ 08-70での主な機能変更」を参照してください。

説明内容は次のとおりです。

アプリケーションサーバの各バージョンで変更になった主な機能と，その概要を説明しています。機能の詳細については，「参照先マニュアル」の「参照個所」の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「Cosminexus アプリケーションサーバ V8」は省略しています。

＜この節の構成＞

付録E.1　08-53での主な機能変更

付録E.2　08-50での主な機能変更

付録E.3　08-00での主な機能変更

付録E.1　08-53での主な機能変更

＜この項の構成＞

(1)　導入・構築の容易性強化

(2)　標準機能・既存機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表E-1　導入・構築の容易性強化を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築
さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。
また，複数のハイパーバイザが混在する環境にも対応しました。
仮想化システム構築・運用ガイド
2章，3章，5章

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表E-2　標準機能・既存機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
トランザクション連携に対応したOpenTP1からの呼び出し | OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 4章
JavaMail | POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 8章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表E-3　信頼性の維持・向上を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

JavaVMのトラブルシュート機能強化
JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行／互換編
4章，5章，
8章

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表E-4　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
JP1/ITRMへの対応 | ITリソースを一元管理する製品であるJP1/ITRMに対応しました。 | 仮想化システム構築・運用ガイド | 1.3，2.1

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表E-5　そのほかの目的による変更

項目
変更の概要
参照先マニュアル
参照個所

Microsoft IIS 7.0およびMicrosoft IIS 7.5への対応
WebサーバとしてMicrosoft IIS 7.0およびMicrosoft IIS 7.5に対応しました。
－
－

HiRDB Version 9およびSQL Server 2008への対応
データベースとして次の製品に対応しました。

HiRDB Server Version 9

HiRDB/Developer's Kit Version 9

HiRDB/Run Time Version 9

SQL Server 2008

また，SQL Server 2008に対応するJDBCドライバとして，SQL Server JDBC Driverに対応しました。
機能解説 基本・開発編(コンテナ共通機能)
3章

（凡例）－：該当なし。

付録E.2　08-50での主な機能変更

＜この項の構成＞

(1)　導入・構築の容易性強化

(2)　標準機能・既存機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表E-6　導入・構築の容易性強化を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

Webサービスプロバイダ側でのweb.xmlの指定必須タグの変更
Webサービスプロバイダ側でのweb.xmlで，listenerタグ，servletタグおよびservlet-mappingタグの指定を必須から任意に変更しました。
リファレンス 定義編(サーバ定義)
2.4

論理サーバのネットワークリソース使用
J2EEアプリケーションからほかのホスト上にあるネットワークリソースやネットワークドライブにアクセスするための機能を追加しました。
機能解説 運用／監視／連携編
1.2.3，5.2，5.8

サンプルプログラムの実行手順の簡略化
一部のサンプルプログラムをEAR形式で提供することによって，サンプルプログラムの実行手順を簡略化しました。
ファーストステップガイド
3.4.1

システム構築・運用ガイド
付録F

運用管理ポータルの画面の動作の改善
セットアップウィザードの完了画面の改善
画面の更新間隔を「更新しない」から「3秒」に変更しました。
セットアップウィザード完了時の画面に，セットアップで使用した簡易構築定義ファイルおよびConnector属性ファイルが表示されるようになりました。
運用管理ポータル操作ガイド
7.4.1

システム構築・運用ガイド
2.2.12，3.3

仮想化環境の構築
ハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築する手順を追加しました。※
仮想化システム構築・運用ガイド
3章，5章

注※

08-50モードで構築する場合は，マニュアル「Cosminexus アプリケーションサーバ 仮想化システム構築・運用ガイド」の「付録D　08-50モードの仮想サーバマネージャを利用する場合の設定」を参照してください。

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表E-7　標準機能・既存機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
OpenTP1からの呼び出しへの対応 | OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 4章
JMSへの対応 | JMS1.1仕様に対応したCosminexus JMSプロバイダ機能を使用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 7章
Java SE 6への対応 | Java SE 6の機能が使用できるようになりました。 | 機能解説 保守／移行／互換編 | 5.5，5.8.1
ジェネリクスの使用への対応 | EJBでジェネリクスを使用できるようになりました。 | 機能解説 基本・開発編(EJBコンテナ) | 4.2.17

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表E-8　信頼性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
明示管理ヒープ機能の使用性向上 | 自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。 | システム設計ガイド | 7.1.1，7.6.3，7.10.5，7.11.1
機能解説 拡張編 | 8章
データベースセッションフェイルオーバ機能のURI単位での抑止 | データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。 | 機能解説 拡張編 | 6.6
仮想化環境での障害監視 | 仮想化システムで，仮想サーバを監視し，障害の発生を検知できるようになりました。 | 仮想化システム構築・運用ガイド | 付録D

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表E-9　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
管理ユーザアカウントの省略 | 運用管理ポータル，Management Serverのコマンド，Smart Composer機能のコマンドで，ユーザのログインIDおよびパスワードの入力を省略できるようになりました。 | システム構築・運用ガイド | 7.6.1，7.6.2，7.6.5
運用管理ポータル操作ガイド | 2.2，7.1.1，7.1.2，7.1.3，8.1，8.2.1，付録G.2
リファレンス コマンド編 | 1.4，mngsvrctl（Management Serverの起動／停止／セットアップ），mngsvrutil（Management Serverの運用管理コマンド），8.3，cmx_admin_passwd（Management Serverの管理ユーザアカウントの設定）
仮想化環境の運用 | 仮想化システムで，複数の仮想サーバを対象にした一括起動・一括停止，スケールイン・スケールアウトなどを実行する手順を追加しました。※ | 仮想化システム構築・運用ガイド | 4章，6章

注※

08-50モードで運用する場合は，マニュアル「Cosminexus アプリケーションサーバ 仮想化システム構築・運用ガイド」の「付録D　08-50モードの仮想サーバマネージャを利用する場合の設定」を参照してください。

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表E-10　そのほかの目的による変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
Tenured領域内不要オブジェクト統計機能 | Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。 | 機能解説 保守／移行／互換編 | 8.8
Tenured増加要因の基点オブジェクトリスト出力機能 | Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。 | 8.9
クラス別統計情報解析機能 | クラス別統計情報をCSV形式で出力できるようになりました。 | 8.10
論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え | Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。 | 機能解説 運用／監視／連携編 | 20.4.3，20.5.3，22.2.2，22.3.3，22.3.4
ホスト単位管理モデルを対象とした系切り替えシステム | クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。 | 22章
ACOS（AX2000，BS320）のサポート | 使用できる負荷分散機の種類にACOS（AX2000，BS320）が追加になりました。 | システム構築・運用ガイド | 4.3.1，8.2，8.3，8.11.6，付録A，付録A.2
リファレンス 定義編(サーバ定義) | 4.5，4.6.2，4.6.4，4.6.5，4.6.6，4.10.1
CMTでトランザクション管理をする場合にStateful Session Bean（SessionSynchronization）に指定できるトランザクション属性の追加 | CMTでトランザクション管理をする場合に，Stateful Session Bean（SessionSynchronization）にトランザクション属性としてSupports，NotSupportedおよびNeverを指定できるようになりました。 | 機能解説 基本・開発編(EJBコンテナ) | 2.7.3
OutOfMemoryError発生時の運用管理エージェントの強制終了 | JavaVMでOutOfMemoryErrorが発生したときに，運用管理エージェントが強制終了するようになりました。 | 機能解説 保守／移行／互換編 | 2.5.7
スレッドの非同期並行処理 | TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。 | 機能解説 拡張編 | 13章

付録E.3　08-00での主な機能変更

＜この項の構成＞

(1)　開発生産性の向上

(2)　標準機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表E-11　開発生産性の向上を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

ほかのアプリケーションサーバ製品からの移行容易化
ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

このマニュアル
2.3，2.7.5

cosminexus.xmlの提供
Cosminexus アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。
機能解説 基本・開発編(コンテナ共通機能)
10.3

(2)　標準機能への対応

標準機能への対応を目的として変更した項目を次の表に示します。

表E-12　標準機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
Servlet 2.5への対応 | Servlet 2.5に対応しました。 | このマニュアル | 2.2，2.5.4，2.6，5章
JSP 2.1への対応 | JSP 2.1に対応しました。 | このマニュアル | 2.3.1，2.3.3，2.5，2.6，5章
JSPデバッグ | MyEclipseを使用した開発環境でJSPデバッグができるようになりました。 | このマニュアル | 2.4
タグライブラリのライブラリJARへの格納とTLDのマッピング | タグライブラリをライブラリJARに格納した場合に，Webアプリケーション開始時にWebコンテナによってライブラリJAR内のTLDファイルを検索し，自動的にマッピングできるようになりました。 | このマニュアル | 2.3.4
application.xmlの省略 | J2EEアプリケーションでapplication.xmlが省略できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 10.4
アノテーションとDDの併用 | アノテーションとDDを併用できるようになり，アノテーションで指定した内容をDDで更新できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 11.5
アノテーションのJava EE 5標準準拠（デフォルトインターセプタ） | デフォルトインターセプタをライブラリJARに格納できるようになりました。また，デフォルトインターセプタからDIできるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 10.4
@Resourceの参照解決 | @Resourceでリソースの参照解決ができるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 11.4
JPAへの対応 | JPA仕様に対応しました。 | 機能解説 基本・開発編(コンテナ共通機能) | 5章，6章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表E-13　信頼性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
セッション情報の永続化 | HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。 | 機能解説 拡張編 | 5章，6章
フルガーベージコレクションの抑止 | フルガーベージコレクションの要因となるオブジェクトをJavaヒープ外に配置することで，フルガーベージコレクション発生を抑止できるようになりました。 | 機能解説 拡張編 | 8章
クライアント性能モニタ | クライアント処理に掛かった時間を調査・分析できるようになりました。 | 機能解説 拡張編 | 9章

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表E-14　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
運用管理ポータルでのアプリケーション操作性向上 | アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。 | 運用管理ポータル操作ガイド | 1.1.4

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表E-15　そのほかの目的による変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
無効なHTTP Cookieの削除 | 無効なHTTP Cookieを削除できるようになりました。 | このマニュアル | 2.7.4
ネーミングサービスの障害検知 | ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 2.7
コネクション障害検知タイムアウト | コネクション障害検知タイムアウトのタイムアウト時間を指定できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 3.15.1
Oracle11gへの対応 | データベースとしてOracle11gが使用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 3章
バッチ処理のスケジューリング | バッチアプリケーションの実行をCTMによってスケジューリングできるようになりました。 | 機能解説 拡張編 | 4章
バッチ処理のログ | バッチ実行コマンドのログファイルのサイズ，面数，ログの排他処理失敗時のリトライ回数とリトライ間隔を指定できるようになりました。 | リファレンス 定義編(サーバ定義) | 3.6
snapshotログ | snapshotログの収集内容が変更されました。 | 機能解説 保守／移行／互換編 | 付録A.1，付録A.2
メソッドキャンセルの保護区公開 | メソッドキャンセルの対象外となる保護区リストの内容を公開しました。 | 機能解説 運用／監視／連携編 | 付録C
統計前のガーベージコレクション選択機能 | クラス別統計情報を出力する前に，ガーベージコレクションを実行するかどうかを選択できるようになりました。 | 機能解説 保守／移行／互換編 | 8.7
Survivor領域の年齢分布情報出力機能 | Survivor領域のJavaオブジェクトの年齢分布情報を日立JavaVMログファイルに出力できるようになりました。 | 機能解説 保守／移行／互換編 | 8.11
ファイナライズ滞留解消機能 | JavaVMのファイナライズ処理の状態を監視して，処理の滞留を解消できるようになりました。 | 機能解説 保守／移行／互換編 | 8.12
サーバ管理コマンドの最大ヒープサイズの変更 | サーバ管理コマンドが使用する最大ヒープサイズが変更されました。 | リファレンス 定義編(サーバ定義) | 5.2，5.3
推奨しない表示名を指定された場合の対応 | J2EEアプリケーションで推奨しない表示名を指定された場合にメッセージが出力されるようになりました。 | メッセージ 2 | KDJE42374-W

付録F　このマニュアルの参考情報

このマニュアルを読むに当たっての参考情報を示します。

＜この節の構成＞

付録F.1　関連マニュアル

付録F.2　マニュアル体系の変更について

付録F.3　このマニュアルでの表記

付録F.4　英略語

付録F.5　KB（キロバイト）などの単位表記について

付録F.1　関連マニュアル

アプリケーションサーバのマニュアルについて次に示します。

Cosminexus アプリケーションサーバ V8 概説（3020-3-U01）
アプリケーションサーバの概要について説明しています。

Cosminexus アプリケーションサーバ V8 ファーストステップガイド（3020-3-U02）
Application ServerまたはDeveloperを使用して，サンプルプログラムを動かすためのシステムを構築する手順について説明しています。

Cosminexus アプリケーションサーバ V8 システム設計ガイド（3020-3-U03）
システム設計時に，システムの目的に応じたシステム構成や運用方法を検討するための指針について説明しています。また，チューニングの方法についても説明しています。

Cosminexus アプリケーションサーバ V8 システム構築・運用ガイド（3020-3-U04）
セットアップウィザードおよびSmart Composer機能を使用したシステムの構築・運用の手順について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(EJBコンテナ)（3020-3-U06）
アプリケーションサーバで提供するEJBコンテナの機能，およびEJBコンテナに関連する機能（EJB，EJBクライアントなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能)（3020-3-U07）
WebコンテナおよびEJBコンテナで共通して利用する機能について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 拡張編（3020-3-U08）
アプリケーションサーバで提供する拡張機能（セッションフェイルオーバ機能，バッチサーバ，CTMなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 運用／監視／連携編（3020-3-U09）
アプリケーションサーバで提供する運用・監視機能，およびほかのプログラムとの連携について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 保守／移行／互換編（3020-3-U10）
アプリケーションサーバで構築したシステムの保守に関する機能，移行情報，および互換用機能について説明しています。

Cosminexus アプリケーションサーバ V8 アプリケーション設定操作ガイド（3020-3-U12）
アプリケーションサーバで動作するアプリケーションの操作方法について説明しています。

Cosminexus アプリケーションサーバ V8 運用管理ポータル操作ガイド（3020-3-U13）
運用管理ポータルの使用方法について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス コマンド編（3020-3-U14）
アプリケーションサーバを構築・運用するときに使用するコマンドについて説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス 定義編(サーバ定義)（3020-3-U15）
アプリケーションサーバを構築・運用するとき，またはアプリケーションを開発するときに，使用するファイルのうち，J2EEサーバやManagement Serverなどのサーバの定義に使用するファイルの形式について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス 定義編(アプリケーション／リソース定義)（3020-3-U16）
アプリケーションサーバを構築・運用するとき，またはアプリケーションを開発するときに使用するファイルのうち，アプリケーションやリソースの属性設定に使用するファイルの形式について説明しています。

Cosminexus アプリケーションサーバ V8 仮想化システム構築・運用ガイド（3020-3-U18）
アプリケーションサーバを仮想化したサーバ上に構築する場合の設計，構築，運用の手順について説明しています。

Cosminexus アプリケーションサーバ V8 アプリケーション開発ガイド（3020-3-U25）
アプリケーションサーバで動作させるアプリケーションの開発方法について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス API編（3020-3-U26）
アプリケーションを開発するときに使用するAPIの形式について説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 1 KDAL-KDCGおよびHitachi Web Server編（3020-3-U41）
アプリケーションサーバで出力されるKDALからKDCGまでのメッセージ，およびHitachi Web Serverのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 2 KDJE-KDJW編（3020-3-U42）
アプリケーションサーバで出力されるKDJEからKDJWまでのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 3 KECX-KEDT／KEOS02000-29999／KEUC-KFRM編（3020-3-U43）
アプリケーションサーバで出力されるKECXからKEDTまでのメッセージ，KEOS02000からKEOS29999までのメッセージ，およびKEUCからKFRMまでのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 4 監査ログ編（3020-3-U44）
アプリケーションサーバで出力される監査ログメッセージについて説明しています。

また，このマニュアルと関連するこのほかのマニュアルを次に示します。必要に応じてお読みください。

Hitachi Web Server（3020-3-U17）

Cosminexus アプリケーションサーバ V8 Cosminexus XML Processor ユーザーズガイド（3020-3-U27）

なお，このマニュアルでは，次のマニュアルについて，対象OSおよびバージョン番号を省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

正式名称 | このマニュアルでの表記
Cosminexus アプリケーションサーバ V8 ファーストステップガイド | Cosminexus アプリケーションサーバ ファーストステップガイド
Cosminexus アプリケーションサーバ V8 システム設計ガイド | Cosminexus アプリケーションサーバ システム設計ガイド
Cosminexus アプリケーションサーバ V8 システム構築・運用ガイド | Cosminexus アプリケーションサーバ システム構築・運用ガイド
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(EJBコンテナ) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)
Cosminexus アプリケーションサーバ V8 機能解説 拡張編 | Cosminexus アプリケーションサーバ 機能解説 拡張編
Cosminexus アプリケーションサーバ V8 機能解説 運用／監視／連携編 | Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編
Cosminexus アプリケーションサーバ V8 機能解説 保守／移行／互換編 | Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編
Cosminexus アプリケーションサーバ V8 アプリケーション設定操作ガイド | Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド
Cosminexus アプリケーションサーバ V8 運用管理ポータル操作ガイド | Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド
Cosminexus アプリケーションサーバ V8 リファレンス コマンド編 | Cosminexus アプリケーションサーバ リファレンス コマンド編
Cosminexus アプリケーションサーバ V8 リファレンス 定義編(サーバ定義) | Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)
Cosminexus アプリケーションサーバ V8 リファレンス 定義編(アプリケーション／リソース定義) | Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)
Cosminexus アプリケーションサーバ V8 仮想化システム構築・運用ガイド | Cosminexus アプリケーションサーバ 仮想化システム構築・運用ガイド
Cosminexus アプリケーションサーバ V8 アプリケーション開発ガイド | Cosminexus アプリケーションサーバ アプリケーション開発ガイド
Cosminexus アプリケーションサーバ V8 リファレンス API編 | Cosminexus アプリケーションサーバ リファレンス API編
Cosminexus アプリケーションサーバ V8 メッセージ 1 KDAL-KDCGおよびHitachi Web Server編 | Cosminexus アプリケーションサーバ メッセージ 1
Cosminexus アプリケーションサーバ V8 メッセージ 2 KDJE-KDJW編 | Cosminexus アプリケーションサーバ メッセージ 2
Cosminexus アプリケーションサーバ V8 Cosminexus XML Processor ユーザーズガイド | Cosminexus XML Processor ユーザーズガイド

付録F.2　マニュアル体系の変更について

08-00では，07-60のマニュアル「Cosminexus　機能解説」，マニュアル「Cosminexus　システム構築ガイド」およびマニュアル「Cosminexus　システム運用ガイド」の内容を6分冊して，マニュアル体系を変更しました。変更後のマニュアル体系については，「1.1　機能の分類」を参照してください。

付録F.3　このマニュアルでの表記

このマニュアルで使用している表記と，対応する製品名を次に示します。

表記 | 製品名
ACOS | AX2000 | AX2000
AX2500 | AX2500
BS320 | BS320ロードバランサブレード
Application Server | Application Server Enterprise | uCosminexus Application Server Enterprise
Application Server Standard | uCosminexus Application Server Standard
Developer | Developer Professional | uCosminexus Developer Professional
Developer Standard | uCosminexus Developer Standard
Eclipse | Eclipse 3.6.1
IPF | Itanium(R) Processor Family
JP1/AJS | JP1/AJS - Agent | JP1/Automatic Job Management System 2 - Agent※
JP1/Automatic Job Management System 3 - Agent
JP1/AJS - Manager | JP1/Automatic Job Management System 2 - Manager※
JP1/Automatic Job Management System 3 - Manager
JP1/AJS - View | JP1/Automatic Job Management System 2 - View※
JP1/Automatic Job Management System 3 - View
JP1/AJS2 - SO | JP1/AJS2 - SO Manager | JP1/Automatic Job Management System 2 - Scenario Operation Manager
JP1/AJS2 - SO View | JP1/Automatic Job Management System 2 - Scenario Operation View
JP1/IM | JP1/IM - CM | JP1/Integrated Management - Central Information Master
JP1/IM - Manager | JP1/Integrated Management - Manager
JP1/IM - View | JP1/Integrated Management - View
JP1/NETM/Audit | JP1/NETM/Audit - Manager
Oracle11g | Oracle Database 11g
Oracle Database 11g R2
UNIX | AIX | AIX 5L V5.3
AIX V6.1
AIX V7.1
HP-UXまたはHP-UX（IPF） | HP-UX 11i V2（IPF）
HP-UX 11i V3（IPF）
Linux | Linux（IPF） | Red Hat Enterprise Linux(R) AS 4（IPF）
Red Hat Enterprise Linux(R) 5 Advanced Platform（Intel Itanium）
Red Hat Enterprise Linux(R) 5（Intel Itanium）
Linux（x86/AMD64 & Intel EM64T） | Red Hat Enterprise Linux(R) AS 4（x86）
Red Hat Enterprise Linux(R) ES 4（x86）
Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) 5 Advanced Platform（x86）
Red Hat Enterprise Linux(R) 5（x86）
Red Hat Enterprise Linux(R) 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux(R) 5（AMD/Intel 64）
Red Hat Enterprise Linux(R) Server 6（32-bit x86）
Red Hat Enterprise Linux(R) Server 6（64-bit x86_64）
Red Hat Enterprise Linux(R) ES 4（x86）
Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）
Solaris | Solaris 10（SPARC）
Solaris 10（x64）
Solaris 9（SPARC）
Web Redirector | uCosminexus Web Redirector

注※　総称して，JP1/AJS2と表記することがあります。

なお，Application ServerおよびDeveloperを総称して，アプリケーションサーバと表記します。

また，Linuxに関しては，バージョンごとに次のように表記することがあります。

表記 | OS名
Red Hat Enterprise Linux 4 | Red Hat Enterprise Linux(R) AS 4（IPF）
Red Hat Enterprise Linux(R) AS 4（x86）
Red Hat Enterprise Linux(R) ES 4（x86）
Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5 | Red Hat Enterprise Linux(R) 5 Advanced Platform（Intel Itanium）
Red Hat Enterprise Linux(R) 5（Intel Itanium）
Red Hat Enterprise Linux(R) 5 Advanced Platform（x86）
Red Hat Enterprise Linux(R) 5（x86）
Red Hat Enterprise Linux(R) 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux(R) 5（AMD/Intel 64）
Red Hat Enterprise Linux Server 6 | Red Hat Enterprise Linux(R) Server 6（32-bit x86）
Red Hat Enterprise Linux(R) Server 6（64-bit x86_64）

このマニュアルで使用している表記と，対応するアプリケーションサーバの機能名を次に示します。

表記 | アプリケーションサーバの機能名
Cosminexus Developer's Kit for Java | Cosminexus Developer's Kit for JavaTM
CTM | Cosminexus Component Transaction Monitor
Management Server | Cosminexus Management Server
MyEclipse | MyEclipse for Cosminexus
PRF | Cosminexus Performance Tracer
Smart Composer | Cosminexus Smart Composer

このマニュアルで使用している表記と，対応するJava関連用語を次に示します。

表記 | Java関連用語
DI | Dependency Injection
EAR | Enterprise ARchive
EJBまたはEnterprise JavaBeans | Enterprise JavaBeansTM
J2EEまたはJava 2 Platform, Enterprise Edition | J2EETM
JavaTM 2 Platform, Enterprise Edition
J2SE | JavaTM 2 Platform, Standard Edition
JAR | JavaTM Archive
Java | JavaTM
Java 2 Runtime Environment, Standard Edition | JavaTM 2 Runtime Environment, Standard Edition
Java 2 SDK, Standard Edition | JavaTM 2 Software Development Kit, Standard Edition
JavaBeans | JavaBeansTM
Java EEまたはJava Platform, Enterprise Edition | JavaTM Platform, Enterprise Edition
Java SE | JavaTM Platform, Standard Edition
JavaVM | JavaTM Virtual Machine
JDBC | JDBCTM
JavaTM Database Connectivity
JDK | JDKTM
JavaTM Development Kit
JNDI | Java Naming and Directory InterfaceTM
JNI | JavaTM Native Interface
JSP | JSPTM
JavaServer PagesTM
Servletまたはサーブレット | JavaTM Servlet
SMAP | Source Map
WAR | Web ARchive

付録F.4　英略語

このマニュアルで使用している英略語を次に示します。

英略語 | 英字での表記
ACOS | Advanced Core Operating System
API | Application Programming Interface
BOM | Byte Order Mark
CORBA | Common Object Request Broker Architecture
CSV | Comma Separated Value
DB | Database
DD | Deployment Descriptor
DMZ | Demilitarized Zone
DN | Distinguished Name
DTD | Document Type Definition
EIS | Enterprise Information System
EL | Expression Language
HTML | Hyper Text Markup Language
HTTP | Hyper Text Transfer Protocol
HTTPS | Hyper Text Transfer Protocol Security
IIOP | Internet Inter-Orb Protocol
ISAPI | Internet Server Application Programming Interface
MHP | Message Handling Program
MIB | Management Information Base
OS | Operating System
OTM | Object Transaction Monitor
OTS | Object Transaction Service
RMI | Remote Method Invocation
SFO | Session Fail Over
SNMP | Simple Network Management Protocol
SSL | Secure Sockets Layer
URI | Uniform Resource Identifier
URL | Uniform Resource Locator
VM | Virtual Machine
XML | Extensible Markup Language

付録F.5　KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

付録G　用語解説

アプリケーションサーバで使用する用語について説明します。

（数字）

1.4モード

サーバの動作モードです。J2EE 1.4以降の機能を使用できます。データベースを含む複数のリソースのトランザクション管理ができます。

（英字）

Application Server

アプリケーションサーバの実行環境を構築する基盤製品です。Application Server Standardと，Application Server Enterpriseの総称です。

CORBAネーミングサービス

CORBAの仕様に準拠した，リモートオブジェクトの格納場所を管理するためのネーミングサービスです。アプリケーションサーバの構成ソフトウェアであるCosminexus TPBrokerによって提供される機能です。

cosminexus.xml

Cosminexus アプリケーションサーバ独自の情報を定義するための属性ファイルです。

Cosminexus Component Transaction Monitor

クライアントからのリクエストのスケジューリングを実現するための構成ソフトウェアです。

Cosminexus Performance Tracer

リクエストが処理されるときに，決められたポイントごとに各機能が出力する性能解析情報をファイルに出力するための構成ソフトウェアです。

Cosminexus アプリケーションサーバ

アプリケーションサーバを中核とした，性能および信頼性の高いアプリケーションを実行および開発するためのシステム構築基盤製品です。

DD

アプリケーションを運用環境に配置するときの定義情報を記述したものです。

EJBコンテナ

Enterprise Beanを制御する実行環境です。また，通信，トランザクション管理などのシステムレベルのサービスも提供します。Enterprise Beanの実体は，EJBコンテナの中で実行されます。

J2EEサーバ

J2EEコンテナを生成，実行する環境です。

JSP EL

JSP 2.0で定義された式言語です。JSPファイルやタグファイル内にJavaBeansの属性へのアクセスなどを記述できます。また，APIも提供されています。

JSPコンパイル結果

JSPファイルおよびタグファイルのコンパイルで生成されるJavaソースファイルやクラスファイルです。

JSP事前コンパイル

Webアプリケーションに含まれるJSPファイルおよびタグファイルをデプロイ前にコンパイルし，Javaソースファイルやクラスファイルを生成する機能です。JSP事前コンパイル機能を使用してあらかじめJavaソースファイルやクラスファイルを生成しておくと，Webアプリケーション実行時の初回リクエストでのレスポンスタイムを短縮できます。

JSPタグライブラリ

JSPタグを作成するためのもので，JSP仕様で規定されています。アプリケーションサーバでは，統合ユーザ管理をする場合に，Cosminexus標準ログインモジュールを使用してユーザ認証をするためのJSPタグライブラリを提供しています。

JSPデバッグ

JSPのコンパイル時に，JSPファイルの行とjavaファイルの行のマッピングを記述したSMAP情報を埋め込んだクラスファイルを作成する機能です。ブレークポイントの設定など，デバッグツールの機能をJSPファイルで実行できるようになります。

URIのデコード機能

リクエストURIのサーブレットパスおよび追加のパス情報に含まれるURLエンコードされた文字列をデコードする機能です。URIのデコード機能でデコードされた文字列が，アプリケーションサーバの各種マッチング処理で使用されます。

Webアプリケーション

Webブラウザを備えたクライアントを対象に作成されたアプリケーションです。具体的には，サーブレットプログラム，JSPファイル，HTML/XMLドキュメントなどの集合体です。

Webアプリケーションのバージョン設定機能

web.xmlで定義されているWebアプリケーションのバージョンを変更しないで，設定したバージョンに準拠してWebアプリケーションを実行する機能です。旧バージョンで作成したアプリケーションを移行するときなどに利用できます。

Webコンテナ

Webアプリケーションを制御する実行環境です。また，セキュリティ，トランザクションなどの各種サービスも提供します。Webアプリケーションは，Webコンテナ上で動作します。

Java Servlet2.5仕様，およびJavaServer Pages Specification v2.1仕様に準拠したWebアプリケーションを実行できます。

Webサーバ

Webブラウザからのリクエスト受信およびWebブラウザへのデータ送信に関連する処理を実行するプログラムです。アプリケーションサーバでは，Hitachi Web Server，Microsoft IIS，またはインプロセスHTTPサーバを使用できます。インプロセスHTTPサーバは，J2EEサーバプロセス内で動作するWebサーバです。

なお，Management Serverを利用する場合，Hitachi Web Serverは論理サーバとして扱えます。

Webサーバ連携

アプリケーションサーバで使用するWebサーバとして，Hitachi Web ServerまたはMicrosoft IISを使用する方法です。

Hitachi Web ServerまたはMicrosoft IISにCosminexus Component Containerが提供するリダイレクタモジュールを組み込んで使用します。

（ア行）

アプリケーションサーバ

情報システムの中間に位置し，ユーザの要求（プレゼンテーション層）とデータベースなどの業務システム（データ層）の処理を橋渡しするためのアプリケーション層を構築するためのミドルウェアです。

イベントリスナ

イベントを受け取って処理するオブジェクトです。アプリケーションサーバでは，Webアプリケーション単位でサーブレットコンテキストオブジェクトまたはセッションオブジェクトの状態変化イベントを受け取ります。

インプロセス

プロセスの起動のしかたです。インプロセスで起動させると，J2EEサーバのプロセス内で実行するように最適化されるので，パフォーマンスの高いシステムが実現できます。ネーミングサービス，トランザクションサービスおよびHTTPサーバ機能をインプロセスで起動できます。このとき，CORBAネーミングサービス，インプロセスOTSおよびインプロセスHTTPサーバは，J2EEサーバ起動時に自動で起動されます。

インプロセスHTTPサーバ

J2EEサーバのインプロセスで動作するWebサーバ機能です。Webコンテナの機能の一部として提供されます。

エラーページのカスタマイズ

Webクライアントから存在しないリソースへのアクセスなどがあった場合に，Webコンテナから返却されるエラーページをユーザが作成した任意のページに変更して表示させる機能です。

（カ行）

簡易Webサーバ

WebコンテナをHTTPサーバとして使用して，スタブなどのダウンロードに利用する機能です。インプロセスHTTPサーバとは異なり，実運用時にはスタブのダウンロード以外の目的では使用できません。

Management Serverを利用する場合は，「管理用サーバ」という名称で扱います。

共有スレッド数

Webコンテナ上にデプロイされているWebアプリケーションで共有されるスレッド数です。

グローバルセッション

セッションフェイルオーバ機能では，障害発生前のHTTPセッションと，障害発生後に引き継がれたHTTPセッションを一つのセッションとして扱います。これをグローバルセッションといいます。

グローバルセッション情報

グローバルセッションが持つ情報をグローバルセッション情報といいます。グローバルセッション情報は，メモリセッションフェイルオーバ機能を使用する場合，SFOサーバで管理されます。また，データベースセッションフェイルオーバ機能を使用する場合，データベースで管理されます。

ゲートウェイ指定機能

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合に，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようにするための機能です。

コンテキスト

Webアプリケーションをまとめた管理単位です。

コンテキストルート

コンテキストのルートパスです。コンテキスト内のWebアプリケーションにアクセスするときにURL上に指定します。コンテキストパスとも呼びます。

（サ行）

サーバ管理コマンド

サーバで管理しているアプリケーションおよびリソースの設定をするためのコマンド群です。

サーブレットおよびJSPのサービスメソッド

javax.servlet.Servletのserviceメソッド，およびserviceメソッドから呼び出すメソッドです。serviceメソッドから呼び出すメソッドは， サーブレットの場合はdo*メソッド(doGet，doDeleteなど)，JSPの場合は_jspServiceメソッドです。

サーブレットフィルタ

サーブレット/JSPへのリクエストや，サーブレット/JSPからのレスポンスを，フィルタリングする機能です。サーブレットフィルタによって，サーブレット/JSPの実行前のリクエスト，または実行後のレスポンスをラップして，データの変更，リソースに対するトレースの取得などができます。

アプリケーションサーバの機能を実現するためのサーブレットフィルタとしては，セッションフェイルオーバ用フィルタ，HTTPレスポンス圧縮用フィルタ，およびクライアント性能フィルタが提供されています。

実行待ちキュー

同時実行スレッドの最大値を設定している場合に，実行スレッド数が最大に達したときに，リクエストをためておくキューのことです。

静的コンテンツ

HTMLファイルや画像ファイルなど，クライアントからの要求に対する応答に使用するファイルのうち，リクエスト内容に影響されないで常に同じ内容になるコンテンツのことです。

セッション

Webアプリケーションに対する一連の作業を示す単位です。セッションは通常，WebクライアントからWebサーバへの複数のリクエストの集合から構成されます。

占有スレッド数

利用できるスレッド数のうち，同時実行スレッド数制御の対象となるリクエストを確実に実行できるスレッド数です。Webコンテナ上にデプロイされているWebアプリケーションごと，またはWebアプリケーション内の業務処理ロジックごとに指定できます。

（タ行）

デプロイ

J2EEアプリケーションの場合，J2EEサーバ内にインポートしたJ2EEアプリケーションを，クライアントから実行可能な状態にすることです。

J2EEリソースアダプタの場合，J2EEサーバ内にインポートしたJ2EEリソースアダプタを，そのJ2EEサーバ上で動作するすべてのJ2EEアプリケーションから使用可能な状態にすることです。

（ハ行）

バインド先アドレス設定機能

Webサーバ連携および簡易Webサーバで利用するIPアドレスを，Webコンテナで明示的に指定する機能をバインド先アドレス設定機能といいます。複数の物理ネットワークインタフェースを持つホストまたは一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，この機能を使用することで，任意のIPアドレスを設定できます。

負荷分散機

Webブラウザなどからのリクエストを一元的に受け付けて，同等の機能を持つ複数のサーバに転送して各サーバの負荷を分散させるための装置です。

（ヤ行）

ユーザスレッド

ユーザがプログラムの中で明示して生成するスレッドのことです。

（ラ行）

リクエスト処理スレッド

Webブラウザなどのクライアントからのリクエストを受け付けて処理するためにWebサーバで生成されるスレッドです。インプロセスHTTPサーバの場合は，Webコンテナで生成されます。

リダイレクタ

Webサーバに登録しWebコンテナへの接続を可能にするプラグインコンポーネント（ライブラリ）です。Webサーバに登録したリダイレクタによって，リクエストをURLパターンまたはラウンドロビン方式で複数のWebコンテナに振り分けて処理できます。

ルートコンテキスト

コンテキストルートが空文字（コンテキストルートに名称が指定されていない）の，WARファイル内のルートパスです。

ロードバランサ

リダイレクタを使用してリクエストを振り分ける場合に使用するワーカ定義のうち，クラスタ構成の場合に使用する特殊なワーカ定義です。振り分け先のWebコンテナのリストが定義されています。リダイレクタでは，この定義を基に，ラウンドロビン方式でリクエストの振り分け処理をします。

（ワ行）

ワーカプロセス

Webサーバの背後で動作するWebコンテナのプロセスです。リダイレクタから見た場合のWebコンテナ実行プロセスになります。具体的には，J2EEサーバまたはWebコンテナサーバに当たります。

索引

[記号]
[数字]
[Ａ][Ｂ][Ｃ][Ｄ][Ｅ][Ｈ][Ｉ][Ｊ][Ｍ][Ｐ][Ｓ][Ｔ][Ｕ][Ｗ][Ｘ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行][ワ行]

(記号)

<%=%>タグ記述時の注意

<jsp:plugin>タグ利用時の注意

<jsp:useBean>タグのclass属性に関する注意事項

(数字)

08-00での主な機能変更

08-50での主な機能変更

08-53での主な機能変更

1.4モード

(英字)

(Ａ)

Application Server

(Ｂ)

built-inフィルタ

built-inフィルタ

(Ｃ)

cjjspcコマンドによるJSP事前コンパイル

cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

CookieへのサーバID付加

Cookie利用時の注意

CORBAネーミングサービス

cosminexus.xml

Cosminexus Component Transaction Monitor

Cosminexus Performance Tracer

Cosminexus アプリケーションサーバ

(Ｄ)

DD

(Ｅ)

EJBコンテナ

EJBコンテナとの連携

EJBコンテナとの連携

EL（Expression Language）のエスケープシーケンスについて

ELの評価結果の型について

Enterprise Beanの呼び出し方法

(Ｈ)

Hitachi Web Serverのアップグレード時の注意事項

Hitachi Web Serverの再起動時の注意事項

Hitachi Web Serverの設定に関する注意事項

httpsd.conf

HttpSessionオブジェクト

HttpSessionオブジェクト数の上限値の設定

HttpSessionオブジェクト数の上限値の設定

HttpSessionのセッションIDへのサーバID付加

HTTPステータスコード302のステータスメッセージについて

HTTPレスポンス圧縮機能

HTTPレスポンス圧縮機能

HTTPレスポンス圧縮機能を有効にする場合の条件

HTTPレスポンス圧縮フィルタ

HTTPレスポンス圧縮フィルタに対する制約

HTTPレスポンス圧縮フィルタの概要

HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

HTTPレスポンス圧縮フィルタを使用するための条件

HTTPレスポンスヘッダのカスタマイズ

HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

(Ｉ)

includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて

includeディレクティブ利用時の注意

IPアドレス指定（Webサーバ連携）

IPアドレス指定（Webサーバ連携）

IPアドレス指定（インプロセスHTTPサーバ）

IPアドレス指定（インプロセスHTTPサーバ）

isapi_redirect.conf

ISAPIフィルタの設定

(Ｊ)

J2EEサーバ

J2EEサーバ単位の設定

java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意

JavaVMのメソッドサイズ制限についての注意事項

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

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

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて

javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について

javax.servlet.ServletResponseインタフェースのresetメソッド実行時の注意

javax.servlet.ServletResponseクラスのsetLocaleメソッドについて

javax.servlet.SingleThreadModelインタフェースの非推奨化について

javax.servlet.UnavailableExceptionについて

JSP

JSP 2.0仕様で追加，変更された仕様についての注意事項

JSP 2.1仕様で追加，変更された仕様についての注意事項

JSP EL

JSP EL式の評価APIの複数指定

JSP ELの実行

JSP移行時の注意事項

JSPコンパイル結果

JSPコンパイル結果

JSPコンパイル結果の出力先

JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行していない場合）

JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行している場合）

JSPコンパイル結果のバージョンチェック

JSPコンパイル結果のライフサイクル

JSPコンパイル結果のライフサイクル

JSP事前コンパイル

JSP事前コンパイル機能

JSP事前コンパイル機能とコンパイル結果の保持

JSP事前コンパイル機能の概要

JSP事前コンパイル機能の注意

JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い

JSP事前コンパイル実行時の文字エンコーディングの適用

JSP事前コンパイル時に検証されるweb.xmlの要素

JSP事前コンパイルで実施されるチェック

JSP事前コンパイルの実行時の処理

JSP事前コンパイルの適用場面と使用するコマンドの対応

JSP事前コンパイルの適用例

JSP事前コンパイルの方法

JSP実装時の注意事項

JSPタグライブラリ

JSPデバッグ

JSPデバッグ機能

JSPデバッグ機能

JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について

JSPドキュメント内のversion属性について

JSPドキュメント内の矛盾する文字コードについて

JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について

JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について

JSPドキュメントのデフォルト拡張子

JSPドキュメントの文字コードについて

JSPトランスレーション

JSPトランスレーション下位互換機能

JSPの実行機能

JSPの実行機能

JSPファイルおよびタグファイルのコンパイルと実行

JSPファイルのコンパイル結果の保持

(Ｍ)

Microsoft IISの設定

mod_jk.conf

(Ｐ)

page/tagディレクティブのimport属性暗黙インポート

pageディレクティブのisThreadSafe属性の非推奨化について

pageディレクティブのpageEncoding属性の複数回指定について

Persistent Connection

Persistent ConnectionによるWebクライアントとの通信制御

Persistent ConnectionによるWebクライアントとの通信制御

Persistent Connectionによる通信制御

POSTデータサイズでのリクエストの振り分け

POSTデータサイズでのリクエストの振り分けの概要

POSTデータサイズによるリクエストの振り分けの例

POSTデータの読み込み失敗時の動作について

POSTリクエスト転送先ワーカ

POSTリクエスト振り分けワーカ

PrintWriter，JSPWriterクラス利用時の性能向上について

(Ｓ)

Servlet 2.4仕様で追加，変更された仕様についての注意事項

Servlet 2.5仕様で追加，変更された仕様についての注意事項

ServletContextインタフェース利用時の注意

ServletContextオブジェクトに登録する日立独自の属性

ServletRequestインタフェース利用時の注意

ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

Servlet仕様で規定された文字エンコーディング（JSPファイル）

Servlet仕様で規定された文字エンコーディング（レスポンス）

Servlet仕様で規定されている文字エンコーディング

Servlet仕様での文字エンコーディングの設定方法

Servlet仕様での文字エンコーディングの設定方法（Servlet 2.3/JSP 1.2）

Servlet仕様での文字エンコーディングの設定方法（Servlet 2.4/JSP 2.0）

(Ｔ)

taglibディレクティブのprefix属性に関する注意事項

TLDファイルのバージョンに関する注意事項

(Ｕ)

uriworkermap.properties

URI取得時の注意

URIのデコード機能

URIのデコード機能

URLConnectionクラス使用時の注意

URL書き換えを実行するServlet APIの引数ごとの戻り値

URLグループ単位での同時実行スレッド数の制御

URLグループ単位の最大同時実行スレッド数

URLグループ単位の実行待ちキュー

URLグループ単位の占有スレッド数

URL指定とマッピング定義によるアクセスについて

URLパターンでのリクエストの振り分け

URLパターンでのリクエストの振り分けの概要

URLパターンによるリクエストの振り分け

URLパターンの種類と適用されるパターンの優先順位

URLパターンの設定

URLパターンのマッピング処理

usrconf.properties

(Ｗ)

Web Redirector

Web Redirectorのインストール手順

Web Redirectorの機能

Web Redirectorのディレクトリ構成

webserver.connector.ajp13.max_threads

webserver.connector.inprocess_http.max_execute_threads

webserver.container.server_id.enabled

webserver.container.server_id.name

webserver.container.server_id.value

webserver.session.max.log_interval

webserver.session.max.throwHttpSessionLimitExceededException

webserver.session.server_id.enabled

webserver.session.server_id.value

Webアプリケーション

Webアプリケーション

Webアプリケーション（WebAP1）の最大同時実行スレッド数の動的変更の設定例

Webアプリケーションアンデプロイ時の注意

Webアプリケーション開発でのJSP事前コンパイルの適用例

Webアプリケーション単位での同時実行スレッド数制御についての注意事項

Webアプリケーション単位での同時実行スレッド数の制御

Webアプリケーション単位の稼働状態でのパフォーマンスチューニング

Webアプリケーション単位の設定

Webアプリケーションに含まれるディレクトリにアクセスするときの注意

Webアプリケーションの稼働状況の確認

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定していない場合）

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定している場合）

Webアプリケーションの最大同時実行スレッド数

Webアプリケーションの最大同時実行スレッド数の設定変更

Webアプリケーションの最大同時実行スレッド数を変更する場合に参考になる情報

Webアプリケーションの実行機能

Webアプリケーションの実行機能

Webアプリケーションの実行待ちキューサイズ

Webアプリケーションの占有スレッド数

Webアプリケーションのデプロイとアンデプロイ

Webアプリケーションのデプロイとアンデプロイの注意事項

Webアプリケーションのバージョン設定機能

Webアプリケーションのバージョン設定機能

Webクライアントからの接続数の制御

Webクライアントからの接続数の制御

Webクライアントからの接続数の制御の概要

Webクライアントからの同時接続数の制御

Webクライアントからの同時接続数の制御によるリクエストの流量制御

Webクライアントからの同時接続数の制御によるリクエストの流量制御

Webコンテナ

Webコンテナ

Webコンテナ

Webコンテナが返すエラーステータスコード

Webコンテナ単位での同時実行スレッド数の制御

Webコンテナでのリクエスト受信時

Webコンテナでのレスポンス送信時

Webコンテナによるスレッドの作成

Webコンテナによるスレッドの作成

Webコンテナの機能

Webコンテナの共有スレッド数

Webコンテナへのゲートウェイ情報の通知

Webコンテナへのゲートウェイ情報の通知

Webコンテナへのゲートウェイ情報の通知

Webコンテナへのゲートウェイ情報の通知

Webサーバ

Webサーバ（リダイレクタ）によるリクエストの振り分け

Webサーバ（リダイレクタ）によるリクエストの振り分け

Webサーバで使用するホストの固定

Webサーバでのリクエスト受信時

Webサーバでのレスポンス送信時

Webサーバの認証機能の解除

Webサーバ連携

Webサーバ連携時の注意事項

Webサーバ連携の機能

Webサービス拡張の設定

workers.properties

WWWサービスの起動と動作確認

(Ｘ)

X-Powered-Byヘッダの利用

(ア行)

(あ)

アクセス状況に応じた一時的なWebアプリケーション単位の最大同時実行スレッド数の変更

アクセスを許可するホストの制限

アクセスを許可するホストの制限によるアクセス制御

アクセスを許可するホストの制限によるアクセス制御

アプリケーションサーバ

アプリケーションサーバ 08-70での主な機能変更

アプリケーションサーバが提供するサーブレットフィルタ

アプリケーションサーバの機能

アプリケーションのイベントリスナ

アプリケーションのイベントリスナ

アプリケーションの実行基盤としての機能

アプリケーションの実行基盤を運用・保守するための機能

(い)

イベントリスナ

インプロセス

インプロセスHTTPサーバ

インプロセスHTTPサーバ

インプロセスHTTPサーバ

インプロセスHTTPサーバが返すエラーステータスコード

インプロセスHTTPサーバが出力するログ・トレース

インプロセスHTTPサーバで使用できる機能

インプロセスHTTPサーバのアクセスログのカスタマイズ

インプロセスHTTPサーバの概要

インプロセスHTTPサーバの機能

インプロセスHTTPサーバの使用

(え)

エラーページのカスタマイズ

エラーページのカスタマイズ

エラーページのカスタマイズ

エラーページのカスタマイズ（Webサーバ連携）

エラーページのカスタマイズ（Webサーバ連携）

エラーページのカスタマイズ（インプロセスHTTPサーバ）

エラーページのカスタマイズ（インプロセスHTTPサーバ）

エラーページのカスタマイズの概要

エラーページのカスタマイズの仕組み

エラーページのカスタマイズの注意事項

(カ行)

(か)

カスタマイズできるエラーページ

カスタムタグのスクリプト変数の定義に関する注意事項

仮想ディレクトリの作成

簡易Webサーバ

簡易Webサーバ機能

簡易Webサーバ機能

簡易Webサーバへのアクセスの制御

管理用サーバ

(き)

既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点

機能とマニュアルの対応

機能の分類

共通で使用する外部のライブラリ（Extension）について

共有スレッド数

共有スレッド数

共有スレッド数の算出のしかた

(く)

クエリ文字列の解析について

クライアント性能フィルタに対する制約

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

グローバルセッション

グローバルセッション情報

(け)

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能を使用する場合の注意

ゲートウェイ使用時の注意

(こ)

このマニュアルに記載している機能の説明

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

コンテキスト

コンテキスト

コンテキストルート

コンテキストルート

コンパイル結果の削除

コンパイル結果の削除

コンパイル結果の生成

コンパイル結果の生成

コンパイル結果の保持

(サ行)

(さ)

サーバID付加機能

サーバ管理コマンド

サーブレット

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

サーブレットおよびJSPのサービスメソッド

サーブレットおよびJSPの実装

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

サーブレット実装時の注意事項

サーブレットでのアノテーションの使用

サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング

サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト

サーブレットフィルタ

サーブレットマッピング

最大同時実行スレッド数

作成するスレッドの種類と数

作成するスレッドの総数

(し)

時間帯に応じた計画的なWebアプリケーション単位の最大同時実行スレッド数の変更

システム運用でのJSP事前コンパイルの適用

システムの目的と機能の対応

実行待ちキュー

実行待ちキューサイズ

(す)

スレッド数を制御する単位

(せ)

静的コンテンツ

静的コンテンツのキャッシュ

静的コンテンツのキャッシュ

静的コンテンツのキャッシュの制御

静的コンテンツやリクエストのエラー処理に使用されるスレッド数

セッション

セッションID

セッションIDおよびCookieへのサーバIDの付加

セッション管理機能

セッション管理機能

セッション情報を管理するオブジェクト

セッションフェイルオーバ用フィルタに対する制約

設定できる文字エンコーディング

前提条件

前バージョンから08-00へ移行する場合のWebアプリケーションに関する注意事項

占有スレッド数

占有スレッド数

占有スレッド数

占有スレッド数

占有スレッド数と最大同時接続数

(そ)

属性の変更に対するイベント通知時の注意

(タ行)

(た)

タグの属性値に指定するExpressionに関する注意事項

タグの属性値のExpressionチェックに関する注意事項

タグファイルのJavaソースファイルとクラスファイルの出力先

タグファイルの実行

タグライブラリ・ディスクリプタ（TLDファイル）の配置について

タグライブラリ利用時の注意

(つ)

通信タイムアウト（Webサーバ連携）

通信タイムアウト（インプロセスHTTPサーバ）

通信タイムアウト（インプロセスHTTPサーバ）

通信タイムアウトの概要

通信タイムアウトの設定

(て)

データベースとの接続

データベースとの接続

適用個所

適用条件

デフォルトの実行待ちキューサイズ

デフォルトの文字エンコーディング設定機能

デフォルトの文字エンコーディング設定機能

デフォルトの文字エンコーディングの実装（Servlet仕様の場合）

デフォルトの文字エンコーディングの設定単位

デフォルトの文字エンコーディングの注意事項

デフォルトの文字エンコーディングの適用個所と適用条件

デフォルトマッピング

デフォルトワーカ

デプロイ

(と)

同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

同時実行スレッド数および実行待ちキューサイズの設定例（Webアプリケーション単位）

同時実行スレッド数制御のパラメタ

同時実行スレッド数の制御

同時実行スレッド数の制御（URLグループ単位）

同時実行スレッド数の制御によるリクエストの流量制御

同時実行スレッド数の制御によるリクエストの流量制御

同時実行スレッド数の制御の概要

同時実行スレッド数の動的変更

同時実行スレッド数を動的に変更したときのWebアプリケーションの動作

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

ドメイン名指定でのトップページの表示

ドメイン名指定でのトップページの表示

ドメイン名指定でのトップページの表示について

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

トランスレーションエラー

(ナ行)

(に)

入出力ストリーム利用時の注意

(ね)

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

(ハ行)

(は)

バインド先アドレス設定機能

バインド先アドレス設定機能

バインド先アドレス設定機能

バインド先アドレス設定機能

バインド先アドレス設定機能

バインド先アドレス設定機能

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

(ふ)

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

フィルタ連鎖の推奨例

負荷分散機

複数のWebアプリケーションのデプロイ

複数の範囲で文字エンコーディングを設定している場合の動作

プロセス内で複数回実行してはならない処理を実装する場合の注意

(ほ)

ほかのフィルタと共存させる場合の注意事項

ホワイトスペース

(マ行)

(ま)

マッピングの順序

(も)

文字エンコーディング設定の組み合わせと有効になる設定

文字エンコーディングの設定範囲

(ヤ行)

(ゆ)

有効なHTTPメソッドの制限によるアクセス制御

有効なHTTPメソッドの制限によるアクセス制御

ユーザスレッド

ユーザスレッド

ユーザスレッド生成のための権限の設定

ユーザスレッドの使用

ユーザスレッドの使用

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

(ラ行)

(ら)

ラウンドロビン方式によるリクエストの振り分け

ラウンドロビン方式によるリクエストの振り分けの概要

ラウンドロビン方式によるリクエストの振り分けの例

(り)

リクエストURIの正規化

リクエストおよびレスポンスのフィルタリング

リクエストおよびレスポンスのフィルタリング機能

リクエスト受信時の通信タイムアウト

リクエスト処理スレッド

リクエスト処理スレッド数の制御

リクエスト処理スレッド数の制御

リクエスト処理スレッド数の制御の概要

リクエスト送受信時の通信タイムアウト

リクエスト送信処理のリトライ

リクエストデータのサイズの制限

リクエストデータのサイズの制限によるアクセス制御

リクエストデータのサイズの制限によるアクセス制御

リクエストの転送パターン

リクエストの振り分け条件

リクエストの振り分け方法

リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）

リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）

リスナで例外が発生した場合の制御について

リダイレクタ

リダイレクタ

リダイレクタが返すエラーステータスコード

リダイレクタでのリクエスト送信時

リダイレクタでのリクエストのHTTPメソッドのサポート可否

リダイレクタでのレスポンス受信時

リダイレクタのログ出力先ディレクトリへのアクセス権の設定

リダイレクタのログに関する注意事項

リダイレクタを使用したリクエスト振り分けの仕組み

リダイレクトによるリクエストの振り分け

リダイレクトによるリクエストの振り分け

(る)

ルートコンテキスト

(れ)

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

レスポンス送受信時の通信タイムアウト

レスポンス送信時に使用されるサーブレットのバッファ

レスポンス送信時の通信タイムアウト

レスポンスのカスタマイズ

(ろ)

ロードバランサ

ロードバランサ

ログ・トレースの出力

ログ・トレースの出力

ロケール設定時の注意

(ワ行)

(わ)

ワーカ定義ファイル

ワーカプロセス

ワーカプロセス

■ 商標類

Active Directoryは，米国Microsoft Corporationの，米国およびその他の国における登録商標または商標です。
AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
AX2000は，A10 Networks, Inc.の商品名称です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
gzipは，米国FSF(Free Software Foundation)が配布しているソフトウェアです。
HP-UXは，Hewlett-Packard Companyのオペレーティングシステムの名称です。
HP C/HP-UXは，Hewlett-Packard Companyの商品名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
J2EEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Javaは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JavaScriptは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDBCは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDKは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSPは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corporationの商品名称です。
MyEclipseは，米国Genuitec社の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 11gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
Solarisは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
すべてのSPARC商標は，米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は，米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。
Sunは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sun Microsystemsは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Vistaは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).