Cosminexus V11 アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)

解説書

3021-3-J05-60

前書き

対象製品

マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の前書きの対象製品の説明を参照してください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，DABroker，HiRDB，JP1，OpenTP1，TPBroker，uCosminexusは，株式会社 日立製作所の商標または登録商標です。

Amazon Web Services，AWS，Powered by AWS ロゴは，Amazon.com, Inc. またはその関連会社の商標です。

EclipseおよびJakartaは，Eclipse Foundation, Inc.の商標です。

Microsoft，Azure，SQL Server，Windows，Windows Server は，マイクロソフト 企業グループの商標です。

Oracle(R)，Java ，MySQL及びNetSuite は，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Red Hat, and Red Hat Enterprise Linux are registered trademarks of Red Hat, Inc. in the United States and other countries. Linux(R) is the registered trademark of Linus Torvalds in the U.S. and other countries.

Red Hat，およびRed Hat Enterprise Linuxは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。Linux(R)は，米国およびその他の国におけるLinus Torvalds氏の登録商標です。

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

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

マイクロソフトの許可を得て使用しています。

発行

2024年 9月 3021-3-J05-60

著作権

All Rights Reserved. Copyright (C) 2020, 2024, Hitachi, Ltd.

変更内容

変更内容(3021-3-J05-60) uCosminexus Application Server 11-50，uCosminexus Client 11-50，uCosminexus Developer 11-50，uCosminexus Service Architect 11-50，uCosminexus Service Platform 11-50

追加・変更内容

変更個所

アプリケーションサーバ 11-50での主な機能変更についての説明を追加した。

1.4

デフォルトのJSON Providerについての説明を変更した。

4.3.3

JSONデータのデシリアライズに関する注意事項を削除した。

4.8

マニュアル訂正の内容を反映した。

-

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

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」のはじめにの説明を参照してください。

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

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

1.1　機能の分類

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

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

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

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

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

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

図1‒1　アプリケーションサーバの機能の分類と対応するマニュアル

注※1

マニュアル名称の「アプリケーションサーバ」を省略しています。

注※2

アプリケーションサーバでは，SOAP WebサービスとRESTful Webサービスを実行できます。目的によっては，マニュアル「アプリケーションサーバ Webサービス開発ガイド」以外の次のマニュアルも参照してください。

SOAPアプリケーションを開発・実行する場合

アプリケーションサーバ SOAPアプリケーション開発の手引

SOAP WebサービスやSOAPアプリケーションのセキュリティを確保する場合

XML Security - Core ユーザーズガイド

アプリケーションサーバ Webサービスセキュリティ構築ガイド

XMLの処理について詳細を知りたい場合

XML Processor ユーザーズガイド

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

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

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

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

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

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

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

アプリケーションサーバでは，Java EE 8に対応した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)　Webサービスを開発するための機能

Webサービスの実行環境および開発環境としての機能が該当します。

アプリケーションサーバでは，次のエンジンを提供しています。

JAX-WS仕様に従ったSOAPメッセージのバインディングを実現するJAX-WSエンジン

JAX-RS仕様に従ったRESTful HTTPメッセージのバインディングを実現するJAX-RSエンジン

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

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

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

(4)　システムのセキュリティを確保するための機能（セキュリティ管理機能）

アプリケーションサーバを中心としたシステムのセキュリティを確保するための機能が該当します。不正なユーザからのアクセスを防止するための認証機能や，通信路での情報漏えいを防止するための暗号化機能などがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表1‒1　機能の分類と機能解説のマニュアルの対応

分類

機能

マニュアル※1

基本・開発機能

Webコンテナ

基本・開発編(Webコンテナ)※2

JSFおよびJSTLの利用

JAX-RS 2.1の利用

WebSocket

NIO HTTPサーバ

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

セッションマネージャの指定機能

EJBコンテナ

基本・開発編(EJBコンテナ)

EJBクライアント

Enterprise Bean実装時の注意事項

ネーミング管理

基本・開発編(コンテナ共通機能)

リソース接続とトランザクション管理

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

JPA 2.2の利用

CJMSプロバイダ

JavaMailの利用

アプリケーションサーバでのCDIの利用

アプリケーションサーバでのBean Validationの利用

Java Batch

JSON-P

JSON-B

Concurrency Utilities

アプリケーションの属性管理

アノテーションの使用

J2EEアプリケーションの形式とデプロイ

コンテナ拡張ライブラリ

ライブラリ競合回避機能

パッケージ名変換機能

拡張機能

バッチサーバによるアプリケーションの実行

拡張編

CTMによるリクエストのスケジューリングと負荷分散

バッチアプリケーションのスケジューリング

J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）

データベースセッションフェイルオーバ機能

明示管理ヒープ機能を使用したFullGCの抑止

アプリケーションのユーザログ出力

セキュリティ管理機能

統合ユーザ管理による認証

セキュリティ管理機能編

アプリケーションの設定による認証

SSL/TLS通信でのTLSv1.2の使用

APIによる直接接続を使用する負荷分散機の運用管理機能からの制御

運用機能

システムの起動と停止

運用／監視／連携編

J2EEアプリケーションの運用

監視機能

稼働情報の監視（稼働情報収集機能）

リソースの枯渇監視

監査ログ出力機能

データベース監査証跡連携機能

運用管理コマンドによる稼働情報の出力

Managementイベントの通知とManagementアクションによる処理の自動実行

CTMの稼働統計情報の収集

コンソールログの出力

連携機能

JP1と連携したシステムの運用

システムの集中監視（JP1/IMとの連携）

ジョブによるシステムの自動運転（JP1/AJSとの連携）

監査ログの収集および一元管理（JP1/Audit Management - Managerとの連携）

クラスタソフトウェアとの連携

1:1系切り替えシステム（クラスタソフトウェアとの連携）

相互系切り替えシステム（クラスタソフトウェアとの連携）

N:1リカバリシステム（クラスタソフトウェアとの連携）

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

保守機能

トラブルシューティング関連機能

保守／移行編

性能解析トレースを使用した性能解析

製品のJavaVM（以降，JavaVMと略す場合があります）の機能

移行機能

旧バージョンのアプリケーションサーバからの移行

推奨機能への移行

互換機能

基本・開発機能の互換機能

互換編

拡張機能の互換機能

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

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

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

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

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

信頼性

高い信頼が求められるシステムの場合に使用するとよい機能です。

アベイラビリティ（安定稼働性）およびフォールトトレランス（耐障害性）を高める機能や，ユーザ認証などのセキュリティを高めるための機能が該当します。

性能

性能を重視したシステムの場合に使用するとよい機能です。

システムのパフォーマンスチューニングで使用する機能などが該当します。

運用・保守

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

拡張性

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

そのほか

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

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

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

EJBコンテナとの連携

−

−

−

−

−

○

○

2.9

データベースとの接続

−

−

−

○

−

○

○

2.10

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

−

○

−

−

−

−

○

2.11

ユーザスレッドの使用

−

−

−

−

○

−

○

2.12

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

−

○

−

−

−

−

○

2.13

2.14

2.15

2.16

2.17

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

−

−

−

−

○

−

○

2.18

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

−

○

−

−

−

−

○

2.19

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

−

−

○

−

−

○

○

2.20

セッションマネージャの指定機能

○

−

−

○

−

−

○

2.22

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

注

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

1.2.2　JSFおよびJSTLの機能

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

表1‒3　JSFおよびJSTLの機能とシステムの目的の対応

機能

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

JSF

−

−

−

−

○※

○

−

3章

JSTL

−

−

−

−

○※

○

−

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

注※

アプリケーション開発時の開発容易性を向上させる機能です。

1.2.3　NIO HTTPサーバの機能

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

表1‒4　NIO HTTPサーバの機能とシステムの目的の対応

機能

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

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

−

○

−

−

−

−

○

7.3

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

−

○

−

−

−

−

○

7.4

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

−

○

−

−

−

−

○

7.5

通信タイムアウト（NIO HTTPサーバ）

○

○

−

−

−

−

○

7.6

IPアドレス指定（NIO HTTPサーバ）

−

−

−

−

○

−

○

7.7

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

○

−

−

−

−

−

○

7.8

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

○

−

−

−

−

−

○

7.9

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

−

−

−

−

○

−

○

7.10

ログ・トレースの出力

−

−

○

−

−

−

○

7.11

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

注

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

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

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

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

ポイント

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

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

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

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

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

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

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

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

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

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

1.4.1　標準機能・既存機能への対応

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

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

項目

変更の概要

参照先マニュアル

参照個所

接続できるデータベースにAmazon RDS for SQL Serverを追加

DB Connectorを使用して接続できるデータベースにAmazon RDS for SQL Serverを追加しました。

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

3.6

マニュアルに「アプリケーションサーバでのSpringの利用」の章を追加

マニュアルに，アプリケーションサーバでのSpring Framework 6の利用方法について記載を追加しました。

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

21章

2　Webコンテナ

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

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

EJBコンテナとの連携

2.9

データベースとの接続

2.10

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

2.11

ユーザスレッドの使用

2.12

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

2.13

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

2.14

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

2.15

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

2.16

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

2.17

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

2.18

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

2.19

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

2.20

アプリケーションサーバで提供する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 3.1仕様，およびJavaServer Pages（JSP）2.3仕様に準拠したWebアプリケーションを実行できます。また，Webアプリケーション実行機能の詳細については，Java Servlet Specification v3.0，およびJavaServer Pages Specification v2.3を参照してください。

参考

以前のバージョンのアプリケーションサーバで実行できるアプリケーションは，本バージョンでも実行できます。

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

WAR形式のWebアプリケーションは，次のどちらかの方法でデプロイすることによって，実行可能な状態になります。

WebアプリケーションをEAR形式にパッケージ化してアーカイブ形式のJ2EEアプリケーション，または展開ディレクトリ形式のJ2EEアプリケーションとしてインポートします。

WARファイルまたはWARディレクトリを指定して，Webアプリケーションを単体でインポートします。

単体でインポートしたWebアプリケーションをWARアプリケーションといいます。WARアプリケーションについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.9　WARアプリケーション」を参照してください。

実行できるJ2EEアプリケーションの形式については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.2　実行できるJ2EEアプリケーションの形式」を参照してください。

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

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

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

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

(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

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

(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タイプの対応づけについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「付録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の実行機能の概要

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

注意事項

初回リクエスト時にJSPファイルをコンパイルする場合，JDK 8以前よりも時間が掛かることがあります。これによる処理性能の劣化が問題となる場合は，JSPファイルの事前コンパイルの使用を検討してください。JSPファイルの事前コンパイルの詳細については，「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

(1)　JSPの構成

JSPは要素（ディレクティブ，アクション，スクリプティング要素）とテンプレートテキストから構成されます。テンプレートテキストには，ホワイトスペースが含まれます。通常，テンプレートテキストに含まれるホワイトスペースはそのまま保持されますが，JSP 2.1仕様から，JSPページまたは標準シンタックスのタグファイルのテンプレートテキストに含まれる不要なホワイトスペースを削除する機能が追加されました。詳細は，「8.2.9(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の実行

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

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

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

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

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

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

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

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

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

(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ファイルのマッピングは最も優先順位が低いマッピングです。ライブラリJAR内のTLDファイルのマッピングの優先順位については，「8.2.7(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ファイルのマッピングは最も優先順位が低いマッピングです。クラスパスに指定したJARファイル内のTLDファイルのマッピングの優先順位については，「8.2.7(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)　カスタムタグの属性名チェックを無効にする方法

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

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内でパラメタwebserver.jsp.translation.customAction.ignoreCaseAttributeNameにtrueを指定します。

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

cjjspcコマンドに-usebeannocheckduplicateidオプションを指定してコンパイルします。

コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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属性重複チェックを有効にする方法

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

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内でパラメタwebserver.jsp.translation.useBean.noCheckDuplicateIdにtrueを指定します。

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

cjjspcコマンドに-usebeannocheckduplicateidオプションを指定してコンパイルします。

コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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)　暗黙インポートするクラスの指定方法

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

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

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

簡易構築定義ファイルのwebserver.jsp.additional.import.listキーに暗黙にインポートしたいクラスを指定します。

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

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

cjjspcコマンドの-addimportオプションで暗黙にインポートしたいクラスを指定します。

コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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デバッグ機能の仕組み

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をコンパイルする場合

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

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

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

J2EEサーバの設定

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

J2EEサーバの開始

J2EEサーバを開始します。

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

JSPファイルの作成，修正

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

JSPのテスト・デバッグ

WTPなどの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のリロードについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8.9　JSPのリロード」を参照してください。

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

JSPファイルの作成，修正

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

JSP事前コンパイルの実行

cjjspcコマンドを使用して，JSP事前コンパイルを実行します。-debuggingオプションを指定してコマンドを実行し，JSPファイルをコンパイルします。

cjjspcコマンド実行時には，KDJE53442-Wのメッセージがコンソールログに出力されます。

JSPのテスト・デバッグ

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

JSPの再コンパイル

JSPワークディレクトリを削除します。また，-debuggingオプションを指定しないでcjjspcコマンドを使用して，JSPファイルを再度コンパイルします。

なお，JSPファイルを再コンパイルしない場合，JSPを実行できません。詳細は「2.4.4　JSPデバッグ機能使用時の注意事項」を参照してください。

JSPの実行環境への配布

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

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

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

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

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

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

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

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

(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事前コンパイル機能の概要

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)　コマンドの概要

ここでは，JSP事前コンパイルを実施するための前提条件と，JSP事前コンパイル実行時に必要なファイル，および実行後に生成されるファイルについて説明します。

前提条件

JSP事前コンパイルを実施するためには，コンパイルするJSPファイルがWebアプリケーションのルートディレクトリ以下，またはそのサブディレクトリ以下に格納されていることが前提です。

JSP事前コンパイルに必要なファイル

JSP事前コンパイルを実施するためには，次に示すファイルが必要です。

JSPファイル（JSP 1.1，JSP 1.2，JSP 2.0，JSP 2.1，JSP 2.2，またはJSP 2.3）※1

JSP 2.0仕様，JSP 2.1仕様，JSP 2.2仕様，またはJSP 2.3仕様に準拠したタグファイル

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アプリケーションのバージョンを3.1と見なしてコンパイルが実行されます。

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　デフォルトの文字エンコーディング設定機能」を参照してください。

JSPデバッグ機能を使用するかどうかの指定

JSPデバッグ機能を使用するかどうかを指定できます。JSPデバッグ機能については「2.4　JSPデバッグ機能」を参照してください。

暗黙インポートするクラスの指定

page/tagディレクティブのimport属性暗黙インポート機能を使用して暗黙インポートするクラス名を指定できます。page/tagディレクティブのimport属性暗黙インポート機能については「2.3.7　page/tagディレクティブのimport属性暗黙インポート」を参照してください。

なお，これらの設定は，コマンドのオプションで指定します。JSPの事前コンパイルのコマンド（cjjspcコマンド）の使い方については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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言語仕様のバージョンの指定方法についてはマニュアル「アプリケーションサーバリファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

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

JSP事前コンパイルは次に示すときに使用できます。

アプリケーション開発時

システム運用時

JSP事前コンパイルの適用場面と使用するコマンドの対応表を次に示します。

表2‒10　JSP事前コンパイルの適用場面と使用するコマンドの対応

適用する場面

使用するコマンド

参照先

アプリケーション開発

Webアプリケーションの開発時

cjjspcコマンド

2.5.3(1)

システム運用

J2EEアプリケーション開始時

cjstartappコマンド

2.5.3(2)

J2EEアプリケーション入れ替え時

通常の入れ替え

cjstartappコマンド

リロードによる入れ替え

cjjspcコマンド

リデプロイによる入れ替え

cjjspcコマンド

JSP事前コンパイルを使用する場面について次に説明します。使用するコマンドの概要については，「2.5.2　JSP事前コンパイルの方法」を参照してください。

なお，cjstartappコマンドでJSP事前コンパイルを実施するためのオプションを指定すると，cjstartappコマンドの実行時にJSPコンパイルが実施されます。この処理はJ2EEサーバで行われるため，一時的にJ2EEサーバプロセスのメモリ使用量が増加します。

(1)　アプリケーション開発での使用

Webアプリケーションの開発では，Webアプリケーション完成後に，JSP事前コンパイルを実施します。

JSP事前コンパイルを実施するには，cjjspcコマンドを使用します。Webアプリケーション開発での，JSP事前コンパイルの適用例を次の図に示します。

図2‒5　Webアプリケーション開発でのJSP事前コンパイルの適用例

JSP事前コンパイル機能を使用して，完成したWebアプリケーションに含まれるすべてのJSPファイルを，一括してコンパイルします。この結果，Webアプリケーション実行時のJSP初回リクエストのレスポンスタイムを向上できます。

Webアプリケーション内のすべてのJSPファイルを一括でコンパイルするには，cjjspcコマンドの，Webアプリケーション単位でのJSP事前コンパイルを実施します。

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

(2)　システム運用での使用

システム運用時では，JSP初回リクエストのレスポンスタイムを向上させるために，運用の開始前に，JSP事前コンパイルを実施します。システム運用時のJSP事前コンパイルは，J2EEアプリケーションを開始するときや，J2EEアプリケーションの入れ替えをするときに実施します。システム運用での，JSP事前コンパイルの適用例を次の図に示します。

図2‒6　システム運用でのJSP事前コンパイルの適用

JSP事前コンパイル機能を適用する場面ごとに概要を説明します。なお，システム運用時にJSP事前コンパイルを使用するときのコンパイルの実施方法については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「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アプリケーションの入れ替えの概要については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。なお，リロードについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8　J2EEアプリケーションの更新検知とリロード」を参照してください。

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

ここでは，JSP事前コンパイル実行時に実施されるチェックやJSP事前コンパイル機能を実行したJ2EEアプリケーションの動作について説明します。

(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

3.0

3.1

<!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から余分な空白を出力しないようにするかの設定

−

−

−

○

○

○

<default-content-type>

pageディレクティブのcontentType属性のデフォルトの設定

−

−

−

−

○※

○

<buffer>

pageディレクティブのbuffer属性のデフォルトの設定

−

−

−

−

○※

○

<error-on-undeclared-namespace>

JSPページで未知の名前空間を使用した場合にエラーにするかどうかの設定

−

−

−

−

○※

○

（凡例）○：検証される　　×：検証されない　　−：サポートしていない要素

注※

11-00以前はタグを無視しましたが，11-10以降はJSPコンパイル時に検証が実施されます。そのため，11-10以降では要素の値が不正な場合，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のエラー通知の設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「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コンパイル結果のライフサイクル

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ワークディレクトリ名の変更については，マニュアル「アプリケーションサーバ リファレンスコマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。cjstartappコマンドでJ2EEアプリケーションの開始時にJSP事前コンパイルを実施する場合のJSPワークディレクトリ名の変更については，「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

また，JSPワークディレクトリ名を変更した場合は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，パラメタwebserver.jsp.precompile.jsp_work_dirで変更したJSPワークディレクトリ名を指定する必要があります。簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(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コンパイル結果のライフサイクル

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の場合

<Application Serverのインストールディレクトリ>¥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の場合

<Application Serverのインストールディレクトリ>¥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)　クラス名の形式

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用テンポラリディレクトリは削除されません。このため，手動で削除する必要があります。

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

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　デフォルトの文字エンコーディングの設定単位

アプリケーションサーバでは，リクエストのデコード，レスポンスのエンコード，およびJSPファイルで使用するデフォルトの文字エンコーディングを，J2EEサーバ単位，Webアプリケーション単位で設定できます。

ここでは，デフォルトの文字エンコーディングの設定について説明します。なお，デフォルトの文字エンコーディングは，JSP事前コンパイル実行時に適用することもできます。JSP事前コンパイル実行時のデフォルトの文字エンコーディング設定については，「2.6.3　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

(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)　適用個所

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コマンド）

cjjspcコマンドでJSP事前コンパイルを実施する際，JSPファイルまたはタグファイルに，デフォルトの文字エンコーディングを適用できます。cjjspcコマンドの場合，デフォルトの文字エンコーディングは，cjjspcコマンドの引数に指定します。これによって，cjjspcコマンド実行時に，実行対象となるJSPファイルに対して，コマンドに指定したデフォルトの文字エンコーディングが適用されます。ただし，JSPファイルやタグファイルにServlet仕様での文字エンコーディング指定がある場合は，設定は適用されないので注意してください。

設定の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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仕様での文字エンコーディングの設定方法

Servlet仕様での文字エンコーディングの設定方法について，Servlet/JSPのバージョンごとに表に示します。

表2‒20　Servlet仕様での文字エンコーディングの設定方法（Servlet 2.5，3.0，3.1/JSP 2.1，2.2，2.3）

設定内容

設定場所

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以降

サーブレット

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以降

JSP 2.0，2.1，2.2，2.3

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サーバの設定

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)　複数の範囲で文字エンコーディングを設定している場合の動作」を参照してください。

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

(2)　Webアプリケーションの設定

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。デフォルトの文字エンコーディングの定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「2.6.6　DDでの定義」を参照してください。

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

デフォルトの文字エンコーディングの適用については，次の点に注意してください。

(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ファイルに反映されません。設定を反映させるためには，再度，コンパイルを実施してください。

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の付加は，アプリケーションサーバのセッションフェイルオーバ機能を使用する場合に前提になる機能です。セッションフェイルオーバ機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」の「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

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

ここでは，セッション情報の管理に使用する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サーバが終了したあとにもセッション情報を保持しておきたい場合は，アプリケーションサーバの機能であるセッションフェイルオーバ機能を使用してください。セッションフェイルオーバ機能については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「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付加機能を使用している場合

セッションIDは，32文字の英数字およびサーバIDで構成されます。サーバIDには，サーバごとに一意の値を設定しておく必要があります。

サーバID付加機能については，「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

データベースセッションフェイルオーバ機能を使用している場合（完全性保障モードが無効のとき）

セッションIDは，32文字の英数字，サーバIDおよび16文字の英数字で構成されます。データベースセッションフェイルオーバ機能（完全性保障モードが無効のとき）は，サーバID付加機能によるセッションIDへのサーバID付加が前提となります。

また，サーバIDには，サーバごとに一意の値を設定しておく必要があります。

サーバID付加機能については，「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

データベースセッションフェイルオーバ機能の前提となる設定については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「5.4.2　前提となる設定」を参照してください。

2.7.3　セッションの管理方法

ここでは，セッションの管理方法とセッションIDの管理について説明します。

(1)　セッションの管理方法

トラッキングモードでWebコンテナのセッションの管理方法を指定します。トラッキングモードには，HTTP Cookieを使用する方法と，URL書き換えを使用する方法の2種類があります。トラッキングモードは，そのどちらか一方，または両方を選択できます。

HTTP Cookieだけを使用する場合

HTTP Cookieによるセッション管理だけが有効になります。このとき，URL書き換えで生成される文字列にセッションIDを示すURLパスパラメタは含まれません。

URL書き換えだけを使用する場合

URL書き換えによるセッション管理だけが有効になります。このとき，レスポンスにセッションIDを示すHTTP Cookieの情報は含まれません。

HTTP CookieとURL書き換えの両方を使用する場合

HTTP Cookieによるセッション管理とURL書き換えによるセッション管理の両方が有効になります。Webコンテナは，セッションがどの方法で管理されているかを，セッションIDが何から取得できたかによって判別します。HTTP CookieからセッションIDを取得した場合は，HTTP Cookieによってセッションを管理していると判別します。URLのパスパラメタから取得できた場合は，URL書き換えによってセッションを管理していると判別します。これらの判別は，リクエストごとに実行されます。

(2)　セッションの管理にHTTP Cookieを使用する場合のセッションIDの管理

セッションIDは，HTTP Cookieとして管理されます。HTTP CookieにはHttpOnly属性を付与できます。

HTTPセッションを新規に作成した場合に，HTTPレスポンスのヘッダにセッションIDを示すHTTP Cookieが付加されます。セッションIDを示すHTTP Cookieの名称は，「JSESSIONID」です。この名称は，アプリケーションサーバのバージョンが09-00以降の場合，変更できます。

なお，作成したHTTPセッションをコミットする前に無効化した場合，HTTP Cookieは付加されません。

(3)　セッションの管理にURL書き換えを使用する場合のセッションIDの管理

セッションIDは，URLのパスパラメタとして管理されます。

セッションIDを示すURLのパスパラメタの名称は，「jsessionid」です。この名称は，アプリケーションサーバのバージョンが09-00以降の場合，変更できます。セッションIDは，WebコンテナによってURLが書き換えられるときに，URLのパスの最後に，「;jsessionid=セッションID」の形式で付加されます。

URLのパスは，階層構造を持っている，リソースを識別するための値です。URLのパスには，クエリやフラグメントは含まれません。このため，これらの要素がURLに含まれている場合，セッションIDは，クエリまたはフラグメントの直前に付加されます。また，URLにセッションID以外のパスパラメタが含まれている場合，セッションIDを示すパスパラメタは，URLに含まれるパスパラメタの最後に付加されます。

ポイント

セッションIDをURLのパスパラメタに追加する場合，URLの文字数が増加します。

増加する文字数を次の表に示します。

表2‒28　URL書き換えによって増加するURLの文字数

機能の使用状況

増加するURLの文字数（単位：文字数）

サーバID付加機能を使用していない場合

44※

サーバID付加機能を使用している場合

44※ + サーバIDの文字数

データベースセッションフェイルオーバ機能（完全性保障モードが無効の場合）

44※ + サーバIDの文字数 + 16（英数字の文字数）

注※

「;jsessionid=」の12文字とセッションIDの32文字の合計です。URLのパスパラメタの名称を変更している場合は，次の値の合計がパスパラメタのサイズとなります。

・パスパラメタの文字数

・セミコロン（;），およびイコール（=）の文字数（2文字）

・HTTPセッションのセッションIDの文字列長（32文字）

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

アプリケーションサーバでは，Webクライアントが保持する無効なセッションIDを削除します。これによって，無効なセッションIDのWebクライアントからの送信を抑止します。なお，この機能はV9互換モードの場合だけ使用できます。

HTTPセッションを無効化した場合，または無効なセッションIDを含むHTTPセッションを受信した場合，Webコンテナによって，無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP CookieがHTTPレスポンスのヘッダに付加されます。これによって，無効なセッションIDが削除されます。

無効なセッションIDを表すHTTP Cookie情報を削除するためのHTTP Cookieとは，次のすべての条件を満たすHTTP Cookieを指します。

セッションIDを示すHTTP Cookieであり，名称は「JSESSIONID」である（Servlet 3.0以降は変更できます）。

値が「""」（空文字列）である。

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セッションが無効化された場合

次の条件をすべて満たす場合，無効なセッション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は付加されません。

管理用サーバでリクエストを受信した。

webserver.session.delete_cookie.backcompatパラメタにtrueを指定している。

これらの機能は旧バージョンとの互換用の機能です。

(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オブジェクト数の上限値の設定は任意です。

セッションフェイルオーバ機能については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「5.2　セッションフェイルオーバ機能の概要」を参照してください。

セッションフェイルオーバ機能のWebアプリケーション開始時のネゴシエーション処理については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「6.4.1　アプリケーション開始時の処理」を参照してください。

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

(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アプリケーションの開発時に<Application Serverのインストールディレクトリ>/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　実行環境での設定」を参照してください。

注意事項

この機能で設定するCookieの名前は，ServletまたはJSPで設定するCookieの名前およびWebコンテナが自動で設定するCookieの名前と重複しないようにしてください。Webコンテナが自動で設定する名前は次の名前です。

JSESSIONID

アプリケーションサーバのバージョンが09-00以降の場合，Webコンテナが設定するCookieの名前を変更できます。Webコンテナが設定するCookieの名前を変更した場合にCookieへサーバIDを付与したときの注意事項については，「2.7.9　セッション管理の注意事項」を参照してください。

(1)　HttpSessionのセッションIDへのサーバID付加

セッションIDは，通常，同一のWebコンテナ内では一意となります。しかし，負荷分散機を使用して複数のWebコンテナで構成するシステムの場合，システム全体ではセッションIDが一意にならないおそれがあります。HttpSessionのセッションIDへのサーバID付加機能を使用すると，HttpSessionのセッションIDに，Webコンテナごとに異なるサーバ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.xmlの<war>-<session-config>タグ内に指定します。

セッションパラメタの定義を次の表に示します。

表2‒29　cosminexus.xmlでのセッションパラメタのカスタマイズ

指定するタグ

設定内容

<cookie-config>-<name>タグ

HTTP Cookieの名称，およびURLのパスパラメタ名を指定します。

<cookie-config>-<http-only>タグ

HTTP CookieにHttpOnly属性を付けるかどうかを指定します。

<tracking-mode>タグ

HTTPセッションの管理方法を指定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

2.7.8　実行環境での設定

セッション管理機能を使用する場合，J2EEサーバの設定が必要です。

また，cosminexus.xmlを含まないJ2EEアプリケーションを使用する場合，実行環境でのプロパティの設定または変更が必要です。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。セッション管理機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのセッション管理機能の定義について次の表に示します。

表2‒30　簡易構築定義ファイルでのセッション管理機能の定義

項目

指定するパラメタ

設定内容

セッションパラメタのカスタマイズ

webserver.session.cookie_config.name

HTTP Cookieの名称，およびURLのパスパラメタ名を指定します。

webserver.session.cookie_config.http_only

HTTP CookieにHttpOnly属性を付けるかどうかを指定します。

webserver.session.tracking_mode

HTTPセッションの管理方法を指定します。

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

webserver.session.max.throwHttpSessionLimitExceededException

HttpSessionオブジェクト数が上限値を超えた場合にcom.hitachi.software.web.session.HttpSessionLimitExceededException例外をスローするかどうかを指定します。

java.lang.IllegalStateException例外をスローする場合はfalseを指定します。

webserver.session.max.log_interval

KDJE39225-Eの出力インターバルを指定します。

セッションIDおよびHTTPレスポンスへのサーバID追加

webserver.session.server_id.enabled

セッションIDにサーバIDを付加するかどうかを指定します。

webserver.session.server_id.value

セッションIDに付加するサーバIDを指定します。

webserver.container.server_id.enabled

HTTPレスポンスに，サーバIDを示すHTTP Cookieを追加するかどうかを指定します。

webserver.container.server_id.name

HTTPレスポンスに，サーバIDを示すHTTP Cookieを追加する場合に，HTTP Cookieの名前を指定します。

webserver.container.server_id.value

HTTPレスポンスに，サーバIDを示すHTTP Cookieを追加する場合に，HTTP Cookieの値を指定します。

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

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。セッション管理機能の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。なお，セッションパラメタのカスタマイズの定義は，Servlet3.0の標準仕様に準拠しています。cosminexus.xmlでの定義については，「2.7.7　cosminexus.xmlでの定義」を参照してください。

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

セッション管理の注意事項について説明します。

(1)　セッションパラメタのカスタマイズと注意事項

HTTP Cookieの名称，およびURLのパスパラメタ名は，次の設定で変更できます。

簡易構築定義ファイル（webserver.session.cookie_config.nameパラメタ）

cosminexus.xml（<war>-<session-config>-<cookie-config>-<name>タグ）

web.xml（/web-app/session-config/cookie-config/name要素）（Servlet 3.0以降の場合）

Servlet API（javax.servlet.SessionCookieConfigインタフェースのsetName()メソッド）（Servlet 3.0以降の場合）

注意事項

異なる方法による設定が存在する場合，「Servlet APIによる設定」，「cosminexus.xmlの記述」，「web.xmlの記述」，「簡易構築定義ファイルの記述」の順に設定が有効となります。

簡易構築定義ファイルのwebserver.container.server_id.enabledパラメタがtrueで，webserver.session.cookie_config.nameパラメタに指定したHTTP Cookieの名称およびURLのパスパラメタ名と，サーバIDのCookieの付加機能で指定したCookieの名称が重複した場合，次のように動作します。

簡易構築定義ファイルのwebserver.session.cookie_config.nameパラメタで指定した名称と重複した場合

デフォルトのセッションIDが設定されます。HTTP Cookieのときは「JSESSIONID」となります。URLのパスパラメタのときは「jsessionid」となります。

cosminexus.xml，web.xml，またはServlet APIで指定した名称と重複した場合

Webアプリケーションの開始時にKDJE39338-Eが出力され，開始に失敗します。Webアプリケーションのリロード処理の実行時はKDJE39338-Eが出力され，リロード処理が続行されます。リロード処理中にKDJE39338-Eが出力された場合は，Servlet APIを使用してCookieの名前を変更したファイルを修正してから，再度リロード処理を実行してください。

(2)　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‒31　引数の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‒32　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‒33　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"

(3)　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()メソッド

(4)　セッションの管理に使用するHTTP CookieのSecure属性

HTTPリクエストをHTTPSプロトコルで送信した場合に，Webコンテナが生成したセッションIDがHTTP Cookieによってクライアントに返されます。そのとき，HTTP CookieにSecure属性が付与されます。

(5)　HTTPセッションの属性名に関する注意事項

HTTPセッションでは，次に示す属性名の属性をアプリケーションで使用することや削除することはできません。

「WELD」から始まる属性名

「org.jboss.weld」から始まる属性名

「javax.faces」から始まる属性名

「facelets」から始まる属性名

「com.sun.faces」から始まる属性名

「csf」から始まる属性名

(6)　CDI使用時のセッション情報引き継ぎ機能に関する注意事項

CDIが有効なアプリケーションに対して，各種セッションフェイルオーバ機能は使用できません。

セッションフェイルオーバ機能を使用するJ2EEサーバでは，プロパティ「ejbserver.javaee.cdi.beansXmlRequired」にtrueを指定してください。また，「beans.xml」ファイルを含んだアプリケーションをセッションフェイルオーバの対象にしないでください。セッションフェイルオーバ機能については，マニュアル「アプリケーションサーバ機能解説 拡張編」を参照してください。

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

この節では，アプリケーションのイベントリスナ機能について説明します。

Webアプリケーション単位でのイベントリスナ機能があります。アプリケーションイベントリスナは，Webアプリケーションのデプロイ時にインスタンス化されます。インスタンス化されたアプリケーションイベントリスナは，サーブレットコンテキストオブジェクトまたはセッションオブジェクトのどちらか一方，または両方の状態変化イベントを受け取ります。リスナオブジェクトが受け取るイベントを次に示します。

セッションオブジェクトの新規生成

セッションオブジェクトのシリアライズ前※1

セッションオブジェクトのデシリアライズ後※1

セッションオブジェクトの抹消

セッションオブジェクトの属性の追加，削除，変更

サーブレットコンテキストオブジェクトの生成

サーブレットコンテキストオブジェクトの抹消

サーブレットコンテキストオブジェクトの属性の追加，削除，変更

Webアプリケーションへのリクエストの到着※2

Webアプリケーションでのリクエスト処理の完了※2

リクエストオブジェクトの属性の追加，削除，変更※2

非同期操作が完了，タイムアウト，またはエラー発生※3

注※1

サーブレットエンジンのベンダ独自処理の都合で，セッションオブジェクトをシリアライズして格納，通信し，別の時点でデシリアライズして処理を再開することが，Servlet APIでは想定されています。

セッションオブジェクトに，これらのイベント通知が設けられている意図は，セッションオブジェクトにデータだけでなく，データベースコネクションやオブジェクトリファレンスなどの資源を持たせられるようにするためです。セッションオブジェクトに資源を持たせるような設計のアプリケーションでは，シリアライズの前にいったん資源を解放し，デシリアライズ後に再び獲得するようにしなければなりません。

セッションオブジェクトに資源を持たせるという構成は，注意深く利用しないとサーバ全体の必要資源量を大幅に増大させてしまい，資源が不足するおそれがあります。このため，イベントリスナ機能は，資源を確保できる場合に利用してください。

注※2

Servlet 2.4以降の仕様に準拠したWebアプリケーションの場合だけ使用できます。

注※3

Servlet 3.0以降の仕様に準拠したWebアプリケーションの場合だけ使用できます。

2.9　EJBコンテナとの連携

WebコンテナはEJBコンテナと連携して，J2EEサーバとして動作します。ここでは，Enterprise Beanの呼び出しについて説明します。なお，Enterprise Beanを呼び出すには，ビジネスインタフェースを使用することもできます。

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

表2‒34　この節の構成（EJBコンテナとの連携）

分類

タイトル

参照先

解説

Enterprise Beanの呼び出し方法

2.9.1

実装

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

2.9.2

設定

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

2.9.3

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

2.9.1　Enterprise Beanの呼び出し方法

Enterprise Beanの呼び出しは，ルックアップを使用する方法とDIを使用する方法があります。ルックアップを使用する場合，呼び出し方法はCORBAネーミングサービスの切り替え機能を利用するかどうかで異なります。

CORBAネーミングサービスの切り替え機能を利用する場合，または同じEARに含まれるEnterprise Beanを呼び出す場合

呼び出し対象のEnterprise Beanが同一のEARに含まれている場合，次の例に示すようにEnterprise Beanを呼び出します。

呼び出し対象のEnterprise Beanが同一のEARに含まれていない場合でも，CORBAネーミングサービスの切り替え機能を使用して，次に示すようにEnterprise Beanを呼び出すことができます。CORBAネーミングサービスの切り替え機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.10　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.9.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サーバのダイナミッククラスローディングを利用できます。ダイナミッククラスローディングの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.3　ダイナミッククラスローディング」を参照してください。

WARからEJBを呼び出す場合は，WARのDDにejb-refを定義する必要があります。ただし，アノテーションを使用して参照を定義している場合は，web.xmlに参照を定義する必要はありません。また，WARから同一アプリケーション内のEJBを呼び出す場合は，WARに，スタブおよびリモートインタフェースを含める必要はありません。

なお，WARから別アプリケーションで動作するEJBを呼び出す場合，または別J2EEサーバで動作するEJBを呼び出す場合，リモートインタフェースとスタブが必要になります。WARにリモートインタフェースを含めて，実行環境でJ2EEアプリケーションの開始時にスタブが自動生成されるように設定してください。実行環境での設定については，「2.9.3　実行環境での設定（J2EEサーバの設定）」を参照してください。

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

J2EEサーバの設定は，簡易構築定義ファイルで実施します。EJBコンテナとの連携の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のejbserver.deploy.stub.generation.scopeに指定します。このパラメタでは，別アプリケーションのEJBをリモートインタフェースで呼び出すためのスタブを指定します。

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

2.10　データベースとの接続

Webコンテナを利用している場合，Java EEサービスのリソースアダプタを使用して，データベースにアクセスできます。なお，リソースアダプタを通じてデータベースにアクセスする場合は，DB Connectorを使用します。データベースへのアクセス時には，次に示す機能を利用できます。

JDBCコネクションプーリング

JDBCコネクションシェアリング

分散トランザクション

データベースとの接続の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6　データベースへの接続」を参照してください。データベース接続するためのリソースアダプタの設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.20　実行環境での設定（リソースアダプタでの設定）」を参照してください。

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

この節では，Webコンテナによるスレッドの作成について説明します。

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

表2‒35　この節の構成（Webコンテナによるスレッドの作成）

分類

タイトル

参照先

解説

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

2.11.1

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

Webコンテナでは，Webサーバ連携のためのスレッド，Webアプリケーションのためのスレッドなどを作成します。これらのスレッドに対して，システムのリソースが十分であるか検討してください。

なお，アプリケーションサーバでは，サーブレットおよびJSPからスレッド（ユーザスレッド）を作成して使用することもできます。ユーザスレッドで使用できるアプリケーションサーバの機能の詳細については，「2.12　ユーザスレッドの使用」を参照してください。

ここでは，Webコンテナが作成するスレッドについて説明します。

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

Webコンテナが作成するスレッドを次の表に示します。

表2‒36　Webコンテナが作成するスレッド

スレッドの分類

参照先

リクエスト処理のためのスレッド

2.11.1(1)

Webアプリケーションのためのスレッド

2.11.1(2)

管理用コンテキストのためのスレッド

2.11.1(3)

(1)　リクエスト処理のためのスレッド

リクエスト処理に使用するスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

接続要求受付スレッド，ソケット状態監視スレッド，およびリクエスト処理スレッドを作成します。

スレッド数

J2EEサーバ起動時に，接続要求受付スレッドを1スレッド，ソケット状態監視スレッドを1〜2スレッド作成します。

リクエスト処理スレッドは，J2EEサーバ起動時に，usrconf.propertiesのwebserver.connector.nio_http.min_threadsキーに指定した数分のスレッドを作成します（webserver.connector.nio_http.min_threadsキーのデフォルトは10）。

同時実行スレッド数がJ2EEサーバ起動時に作成したスレッド数を超えた場合，webserver.connector.nio_http.max_threadsキーに指定した数を上限としてリクエスト処理スレッドを追加します（webserver.connector.nio_http.max_threadsキーのデフォルトは100）。

(2)　Webアプリケーションのためのスレッド

Webアプリケーション単位に次のスレッドを作成します。最小1スレッド，最大3スレッドです。

セッションの有効期限監視スレッド

Webアプリケーションのリロード監視スレッド

(webserver.context.check_intervalに1以上を設定した場合)

JSPの更新監視スレッド

(webserver.jsp.check_intervalに1以上を設定した場合)

(3)　管理用コンテキストのためのスレッド

管理用コンテキストを二つ生成するため，2スレッド作成します。

2.12　ユーザスレッドの使用

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

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

表2‒37　この節の構成（ユーザスレッドの使用）

分類

タイトル

参照先

解説

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

2.12.1

設定

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

2.12.2

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

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

ここでは，ユーザスレッドで使用できるアプリケーションサーバの機能について説明します。ユーザスレッドの使用方法については，「8.2.1(15)　ユーザスレッドの使用方法」を参照してください。

アプリケーションサーバで提供される各機能について，ユーザスレッドで使用できるかどうかを次の表に示します。

表2‒38　ユーザスレッドでの機能の使用可否

機能名

使用可否

参照先

サーブレットAPIの利用

△

2.12.1(1)

Enterprise Beanの呼び出し

×

−

ネーミングサービス

○

2.12.1(2)

リソース接続

△

2.12.1(3)

トランザクションサービス

△

統合ユーザ管理

×

−

ログ運用および障害検知

○

2.12.1(4)

J2EEアプリケーション運用

△

2.12.1(5)

コンテナ拡張ライブラリの利用

○

2.12.1(6)

（凡例）○：使用できる　△：一部の機能が使用できない　×：使用できない　−：該当なし

ユーザスレッドで使用できる機能をさらに詳細機能に分類し，各機能についてサーブレット/JSP，およびユーザスレッドで使用できるかどうかを示します。また，ユーザスレッドで使用する場合の注意事項についても示します。

(1)　サーブレットAPI

サーブレットAPIをユーザスレッドで使用する場合，リクエストオブジェクトおよびレスポンスオブジェクトは使用できません。リクエスト処理スレッドでだけ使用してください。詳細は，サーブレット仕様書のThread Safetyの項を参照してください。

(2)　ネーミングサービス

ネーミングサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2‒39　ネーミングサービスの機能の使用可否（ユーザスレッド）

分類／機能名

サーブレット/JSP

ユーザスレッド

JNDIのルックアップ

リソースアダプタ

DB Connector

○

○

DB Connector for Reliable MessagingとReliable Messaging

○

○

TP1/Message Queue-Access

○

○

TP1 Connector

○

○

Java Mail

○

○

JavaBeansリソース

○

○

ユーザトランザクション

○

○

（凡例）○：使用できる

ネーミングサービスを使用する場合，ユーザスレッドの実行中にアプリケーションを停止しないでください。

(3)　リソース接続およびトランザクションサービス

リソース接続およびトランザクションサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2‒40　リソース接続およびトランザクション管理の機能の使用可否（ユーザスレッド）

分類／機能名

サーブレット/JSP

ユーザスレッド

コネクションプーリング

DB Connectorによるコネクションプーリング

○

○

DB Connector for Reliable MessagingとReliable Messagingによるコネクションプーリング

○

○

TP1 Connectorとのコネクションプーリング

○

○

TP1/Message Queue - Accessとのコネクションプーリング

○

○

コネクションプールのウォーミングアップ

○

○

コネクション数調節

○

○

コネクションシェアリング

○

○

コネクションアソシエーション

○

○

ステートメントプーリング（DB Connector）

○

○

ライトトランザクション

○

○

インプロセストランザクションサービス

○

○

DataSourceオブジェクトのキャッシング

○

○

DB Connectorのコンテナ管理でのサインオンの最適化

○

○

受信バッファのプーリング

○

○

コネクションの障害検知

DB Connectorによる障害検知

○

○

DB Connector for Reliable MessagingとReliable Messagingによる障害検知

○

○

TP1 Connectorとのコネクション障害検知

×

×

TP1/Message Queue - Accessとのコネクション障害検知

×

×

コネクション枯渇時のコネクション取得待ち

○

○

コネクションの取得リトライ

DB Connectorによるコネクション取得リトライ

○

○

DB Connector for Reliable MessagingとReliable Messagingによるコネクション取得リトライ

○

○

TP1 Connectorとのコネクション取得リトライ

○

○

TP1/Message Queue - Accessとのコネクション取得リトライ

○

○

コネクションプールクリア

○

○

コネクションのクローズ・解放

コネクション自動クローズ（Webコンテナ）

○

×

コネクションスイーパ

○

○

トランザクションタイムアウト

○

○

トランザクションリカバリ

○

○

トランザクションの自動決着※

○

×

障害調査用SQLの出力

○

○

クラスタコネクションプール（互換機能）

○

○

（凡例）○：使用できる　×：使用できない

注※

サーブレットのメソッドからリターンするとき，未決着のトランザクションをロールバックする機能です。

ユーザスレッドでリソース接続およびトランザクションサービスを使用する場合の注意事項を示します。

SingleThreadModelインタフェースを実装したサーブレットで生成したスレッド上で，トランザクションの開始と決着，およびコネクションの取得と解放はできません。

スレッド生成時にトランザクションを引き継ぐことはできません。

トランザクションは，同じスレッド上で開始または決着してください。

スレッド間でコネクションを渡すことはできません。コネクションを使用すると，動作不正となります。

ユーザスレッドでコネクションを取得した場合，コネクションを取得したスレッド上で確実にコネクションをクローズしてください。

(4)　ログ運用および障害検知

ログ運用および障害検知として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2‒41　ログ運用および障害検知の機能の使用可否（ユーザスレッド）

分類／機能名

サーブレット/JSP

ユーザスレッド

Managementイベントによる処理の自動実行

○

○

JP1イベントによるシステムの監視

○

○

ユーザログ出力

○

○

性能解析トレース

○

○

CTMの稼働情報の監視

○

○

（凡例）○：使用できる

(5)　J2EEアプリケーション運用

J2EEアプリケーション運用機能として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表2‒42　J2EEアプリケーション運用機能の使用可否（ユーザスレッド）

分類／機能名

サーブレット/JSP

ユーザスレッド

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

○

×

スケジュールキュー単位の同時実行数の動的変更

○

○

J2EEアプリケーションの実行時間監視

メソッドタイムアウト機能

○

×

メソッドキャンセル機能

○

×

J2EEアプリケーションの停止

通常停止

○

○※1

強制停止

○

○※1

J2EEアプリケーションの入れ替え

リデプロイ機能による入れ替え

○

○※2

リロード機能による入れ替え

○

○※2

（凡例）○：使用できる　×：使用できない

注※1

コンテナでは，ユーザスレッドを停止しません。

注※2

開始状態のJ2EEアプリケーションを入れ替えた場合，コンテナではユーザスレッドを停止しません。

(6)　コンテナ拡張ライブラリ

コンテナ拡張ライブラリは，サーブレット/JSPおよびユーザスレッドのどちらでも使用できます。

2.12.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.13　同時実行スレッド数の制御の概要

Webコンテナでは，マルチスレッドでサーブレットのリクエストを処理します。このとき，同時に実行できるスレッド数に上限を設定できます。これによって，スラッシングなどによるパフォーマンスの低下を防止できます。また，適切なスレッド数を設定することで，アクセス状況に従ったパフォーマンスのチューニングができます。

この節では，同時に実行するスレッド数を制御するための設定について説明します。

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

表2‒43　この節の構成（同時実行スレッド数の制御）

分類

タイトル

参照先

解説

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

2.13.1

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

2.13.2

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

2.13.3

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

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

同時に実行するスレッド数を制御するには，Webコンテナ単位で制御する方法，Webアプリケーション単位で制御する方法，およびURLグループ単位で制御する方法の3種類あります。

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

Webコンテナ上のWebアプリケーション全体で，同時にリクエストを処理するスレッド数を設定します。詳細については「2.14　Webコンテナ単位での同時実行スレッド数の制御」を参照してください。

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

Webコンテナ上のWebアプリケーションごとに，同時にリクエストを処理するスレッド数を設定します。Webコンテナ単位での同時実行スレッド数制御より細かい単位でスレッド数を制御できます。詳細については，「2.15　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

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

Webアプリケーション内のサーブレットやJavaBeansなどの業務ロジックに対応するURLごとに，同時にリクエストを処理するスレッド数を設定します。特定のURLへのリクエストを処理する業務ロジックをURLグループといいます。URLグループ単位で，同時実行スレッド数を制御するので，Webアプリケーション単位の制御より細かい単位でスレッド数を制御できます。詳細については，「2.16　URLグループ単位での同時実行スレッド数の制御」を参照してください。

それぞれの制御単位の関係について次の図に示します。

図2‒12　同時実行スレッド数制御の単位の関係

図に示すように，同時実行スレッド数制御のいちばん大きな単位は，Webコンテナ単位となります。Webコンテナ内のWebアプリケーションごとにスレッド数を制御する場合はWebアプリケーション単位で設定します。さらに，Webアプリケーション内のURLグループごとにスレッド数を制御する場合はURLグループ単位で設定します。スレッド数制御の最小単位はURLグループ単位となります。

スレッド数の制御には包含関係があるので，Webアプリケーション単位でスレッド数を制御する場合はWebコンテナ単位での設定も必要になります。また，URLグループ単位でスレッド数を制御する場合は，Webコンテナ単位およびWebアプリケーション単位での設定も必要になります。

なお，WebSocketや非同期サーブレットを処理するスレッドは最大同時実行スレッド数制御機能の管理対象外となります。

これらのスレッドの管理については，「7.　NIO HTTPサーバ」参照してください。

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

同時実行スレッド数制御をする場合，最大同時実行スレッド数，占有スレッド数，実行待ちキューサイズなどのパラメタでスレッド数を制御します。

ここでは，スレッド数を制御するための主なパラメタについて説明します。

(1)　最大同時実行スレッド数

最大同時実行スレッド数とは，利用できる全体のスレッド数のうち，同時実行スレッド数制御の対象となるリクエストを最大で同時に実行できるスレッド数です。

最大同時実行スレッド数は，Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位で設定します。

(2)　占有スレッド数

占有スレッド数とは，利用できる全体のスレッドのうち，同時実行スレッド数制御の対象となるリクエストを確実に実行できるスレッド数です。Webアプリケーション単位，およびURLグループ単位で設定することで，Webアプリケーションごと，またはURLグループごとにスレッド数を最低限確保できます。

(3)　実行待ちキューサイズ

同時実行スレッド数制御の対象となるリクエストが，同時実行スレッド数の上限に達した場合に，リクエストが入るキューサイズを指定できます。キューサイズには，キューに格納するリクエストの個数を指定します。

実行待ちキューにリクエストが格納される条件を次に示します。

同時実行スレッド数＜最大同時実行スレッド数で，かつ同時実行スレッド数≧占有スレッド数の場合に，使用できる共有スレッド数がないとき

同時実行スレッド数≧最大同時実行スレッド数の場合

なお，実行待ちキューに空きがない場合は，リクエストは処理されないで，クライアントにはエラーが返ります。

実行待ちキューサイズは，Webアプリケーション単位，およびURLグループ単位で設定できます。

(4)　共有スレッド数

共有スレッド数とは，利用できるスレッドのうち，占有されないスレッド数です。共有スレッド数には，Webコンテナの共有スレッド数と，Webアプリケーションの共有スレッド数があります。

Webコンテナの共有スレッド数

Webコンテナの共有スレッド数とは，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有するスレッド数です。

Webアプリケーションの共有スレッド数

Webアプリケーションの共有スレッド数とは，Webアプリケーションに含まれるすべての処理で共有するスレッド数です。

なお，共有スレッド数は，最大同時実行スレッド数と占有スレッド数から導き出します。

共有スレッド数の算出のしかたについては，「2.13.2(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‒13　共有スレッド数の算出例

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.13.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

Webサーバの最大同時接続数は，Webコンテナでのリクエスト処理のほかに，Webサーバ上に配置された静的コンテンツの処理，およびWebコンテナのリクエストを送信し，同時実行スレッド数と実行待ちキューを超えたリクエストのエラー処理に使用されます。静的コンテンツの処理および実行待ちキューを超えたリクエストのエラー処理に使用されるスレッド数は，次のとおりです。

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

Webサーバの最大同時接続数−（Webコンテナ単位の最大同時実行スレッド数＋Webアプリケーション単位，URLグループ単位およびデフォルトの実行待ちキューサイズの合計）

なお，デフォルトの設定では静的コンテンツに使用されるスレッド数は割り当てられていません。静的コンテンツの処理に使用するスレッド数を確保する場合は，上記の式を満たすようにWebアプリケーション単位，URLグループ単位およびデフォルトの実行待ちキューサイズに適切な値を設定してください。

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

この節では，Webコンテナ単位での同時実行スレッド数の制御について説明します。

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

表2‒44　この節の構成（Webコンテナ単位での同時実行スレッド数の制御）

分類

タイトル

参照先

解説

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

2.14.1

設定

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

2.14.2

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

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

Webコンテナ単位での同時実行スレッド数の制御の仕組みについて，次の図で説明します。

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

例えば，Webコンテナに二つのWebアプリケーションがデプロイされていて，同時実行スレッド数に「5」を設定している場合，二つのWebアプリケーションで同時に実行できるスレッド数は5となります。

Webコンテナ単位に同時実行スレッド数を設定することで，Webコンテナにデプロイされた複数のWebアプリケーションのうち，一つのWebアプリケーションにアクセスが集中した場合でも，アクセスが集中しているWebアプリケーションにスレッドを割り当てることができます。この仕組みについて次の図で説明します。

図2‒15　アクセスが集中したときのスレッドの扱い（Webコンテナ単位の場合）

図のように，WebコンテナにWebアプリケーションが二つデプロイされていて，同時実行スレッド数に「5」が設定されている場合に，Webアプリケーション1にリクエストが集中すると，5スレッドすべてがWebアプリケーション1に割り当てられます。

一方，Webアプリケーション2に対するリクエストは，Webアプリケーション1のリクエスト処理が完了するまで，Webコンテナ単位の実行待ちキューにためられます。なお，Webコンテナ単位の実行待ちキューにためられたリクエストは，リクエスト処理の完了後，順次実行されます。

Webコンテナ単位の実行待ちキューからあふれたリクエストは，Listenキューに蓄えられ，実行中のリクエストが完了次第順次取り出されます。クライアントからの接続要求が指定した最大値を超えた場合，または接続タイムアウト時間内に実行されなかった場合，クライアントはサーバへの接続に失敗します。

リバースプロキシと常設コネクションで接続する構成の場合，Listenキューに蓄えられたリクエストは実行されることがないため，リバースプロキシはサーバへの接続に失敗します。

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

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナ単位での同時実行スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタを指定します。

webserver.connector.nio_http.max_servlet_execute_threads

Webコンテナ全体のサーブレットの最大同時実行スレッド数を指定します。

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

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

この節では，Webアプリケーション単位での同時実行スレッド数の制御について説明します。

Webアプリケーション単位でスレッド数を制御するときには，Webコンテナ単位でのスレッド数制御も同時に設定する必要があります。「2.14　Webコンテナ単位での同時実行スレッド数の制御」もあわせて参照してください。

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

表2‒45　この節の構成（Webアプリケーション単位での同時実行スレッド数の制御）

分類

タイトル

参照先

解説

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

2.15.1

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

2.15.2

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

2.15.3

実装

cosminexus.xmlでの定義

2.15.4

設定

実行環境での設定

2.15.5

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

2.15.6

注意事項

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

2.15.7

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

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

Webコンテナ単位より細かい粒度で同時実行スレッド数を制御したい場合，Webアプリケーション単位で同時実行スレッド数を制御します。

Webアプリケーション単位で同時実行スレッド数を設定することで，Webアプリケーションごとの同時実行スレッド数に上限が設けられます。これによって，特定のWebアプリケーションへのリクエストが増大した場合に，そのWebアプリケーションがWebコンテナ全体の処理能力を占有するのを防ぎ，また，ほかの業務も滞りなく実行できるようになります。

なお，Webアプリケーション単位での同時実行スレッド数の設定の指針については，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.3.4　Webアプリケーションの同時実行数を制御する」を参照してください。また，Webコンテナ単位での設定パラメタについては，「2.14.2　実行環境での設定（J2EEサーバの設定）」を参照してください。

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

Webアプリケーション単位でスレッド数を制御する場合に必要なパラメタについての概要を次に示します。

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

Webコンテナ単位の最大同時実行スレッド数を設定します。なお，ここで設定した最大同時実行スレッド数は，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有します。

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

同時実行スレッド数を制御したいWebアプリケーションに対して，次に示すパラメタを設定します。

最大同時実行スレッド数

Webアプリケーションで最大で幾つのスレッドを同時に実行できるかを設定します。

占有スレッド数

Webアプリケーションの占有スレッド数を設定します。

Webアプリケーション単位の実行待ちキューサイズ

Webアプリケーションの実行待ちキューサイズを設定します。

デフォルトの実行待ちキューサイズ

Webアプリケーション単位の同時実行スレッド数制御を設定していないWebアプリケーションのための，実行待ちキューサイズを設定します。

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‒16　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サーバのリバースプロキシを経由する場合）またはNIO HTTPサーバの最大同時接続数が少ないときに，占有スレッド数を設定していないWebアプリケーションへのリクエストによって最大同時接続数が占有されると，占有スレッド数を設定したWebアプリケーションにアクセスしても，Webサーバ上またはNIO HTTPサーバ上で実行待ちになったり，エラーになったりします。

占有スレッド数を設定したWebアプリケーションを，ほかのWebアプリケーションへのアクセス流量に依存しないで確実に実行させるためには，最大同時接続数に適切な値を設定する必要があります。最大同時接続数の設定方法を次に示します。

Webサーバの最大同時接続数の設定方法（Webサーバのリバースプロキシを経由する場合）

Webサーバのリバースプロキシを経由する場合，Webサーバの最大同時接続数を，次に示す値よりも大きい値にする必要があります。

Webサーバの最大同時接続数＞Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数

占有スレッド数を設定する場合は，上記の式を満たすように適切な値を設定してください。

なお，Webサーバの最大同時接続数の詳細は，マニュアル「HTTP Server」を参照してください。

NIO HTTPサーバの最大同時接続数の設定方法

NIO HTTPサーバの最大同時接続数を次に示す値よりも大きい値にする必要があります。

NIO HTTPサーバの最大同時接続数＞Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数

詳細については，「7.　NIO HTTPサーバ」を参照してください。

(3)　Webアプリケーションの実行待ちキューサイズ

Webアプリケーションの実行待ちキューサイズを設定します。

Webアプリケーションに最大同時実行スレッド数を設定している場合，実行スレッド数が最大数に達してしまうと，リクエストはキューにためられます。このときの，実行待ちのキューのサイズを，Webアプリケーション単位で指定できます。

Webアプリケーション単位の実行待ちキューサイズの設定は，Webアプリケーション単位での同時実行スレッド数を設定しているかどうかで異なります。

Webアプリケーション単位で同時実行スレッド数を設定している場合

Webアプリケーションごとに実行待ちキューサイズを設定できます。

Webアプリケーション単位で同時実行スレッド数を設定していない場合

Webアプリケーションで共通となる実行待ちキューサイズが使用されます。共通の実行待ちキューサイズのことを，デフォルトの実行待ちキューサイズといいます。

Webアプリケーション単位およびデフォルトの実行待ちキューでの動作

実行待ちキューの設定が，Webアプリケーションの実行待ちキューサイズとデフォルトの実行待ちキューサイズを含め，複数ある場合，共有スレッド数を使用して実行されるリクエストの順序は，キューのリクエストのうち，先に到着したリクエストから処理されます。

Webサーバの最大同時接続数とWebアプリケーション単位およびデフォルトの実行待ちキュー（Webサーバのリバースプロキシを経由する場合）

WebサーバからWebコンテナに転送されるリクエストの多重度は，Webサーバの最大同時接続数が上限となります。このため，占有スレッド数を設定する場合には，Webアプリケーション単位およびデフォルトの実行待ちキューサイズはWebサーバの最大同時接続数より少ない数にしてください。

NIO HTTPサーバの最大同時接続数とWebアプリケーション単位およびデフォルトの実行待ちキュー

占有スレッド数を設定する場合には，Webアプリケーション単位およびデフォルトの実行待ちキューサイズはNIO HTTPサーバの最大同時接続数より少ない値にする必要があります。

ポイント

同時実行スレッド数が最大数に達したときのリクエストの動作

Webアプリケーション単位の同時実行スレッド数が最大数に達した場合で，キューに空きがあるときは，リクエストはキューにたまります。そして，処理中のリクエスト処理が完了したあとに，順次キューからリクエストが取り出され，実行されます。なお，キューに空きがないときは，リクエストはエラーとなり，クライアントには，HTTP 503エラーが返ります。

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

Webアプリケーション単位の同時実行スレッド数制御をする場合の設定の指針について説明します。

設定する値は，次の順に決定してください。

Webコンテナ単位の最大同時実行スレッド数を決定する。

Webアプリケーション単位の最大同時実行スレッド数を決定する。

Webアプリケーション単位の占有スレッド数を決定する。

Webアプリケーション単位およびデフォルトの実行待ちキューサイズを決定する。

Webアプリケーション単位の同時実行スレッド数の設定は，各Webアプリケーションの運用，およびJ2EEサーバが動作するホストの処理能力を考慮して設定してください。設定値が妥当であるかどうかは，Webアプリケーションを実行し，評価する必要があります。

なお，実行中のWebアプリケーションの稼働情報は，Management Serverを利用して確認できます。Webアプリケーションの稼働状況の確認については，「2.17.2(1)　Webアプリケーションの稼働状況の確認」を参照してください。

複数のWebアプリケーションに占有スレッド数を設定する場合，各Webアプリケーションの占有スレッド数の合計は，Webコンテナの最大同時実行スレッドの値以下にする必要があります。設定値については，Webコンテナ単位の同時実行スレッド数の制御とあわせて検討してください。

Webコンテナ単位の最大同時実行スレッド数が少ない場合，Webアプリケーション単位の最大同時実行スレッド数は，設定した数よりも少なくなるおそれがありますので，注意してください。

占有スレッド数は，Webアプリケーションの最大同時実行スレッド数以下にしてください。

2.15.4　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

Webアプリケーション単位でのスレッド数の制御を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのWebアプリケーション単位でのスレッド数の制御の定義について次の表に示します。

表2‒46　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.17　同時実行スレッド数の動的変更」を参照してください。

指定するタグの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

2.15.5　実行環境での設定

ここでは，Webアプリケーション単位でスレッド数を制御する場合の設定について説明します。

Webアプリケーション単位でスレッド数を制御する場合，J2EEサーバおよびJ2EEアプリケーションの設定が必要です。

なお，J2EEアプリケーションの設定は，cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webアプリケーション単位でのスレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのWebアプリケーション単位でのスレッド数の制御の定義について次の表に示します。

表2‒47　簡易構築定義ファイルでのWebアプリケーション単位でのスレッド数の制御の定義

項目

指定するパラメタ

設定内容

デフォルトの実行待ちキューサイズ

webserver.container.thread_control.queue_size

実行スレッド数が最大数に達した場合，リクエストはキューに溜められます。このときの，Webアプリケーションで共通となる実行待ちキューサイズ（デフォルトの実行待ちキューサイズ）を指定します。

設定した値は，Webアプリケーション単位での同時実行数を指定していない場合に適用されます。

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

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。Webアプリケーション単位でのスレッド数の制御の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.15.4　cosminexus.xmlでの定義」を参照してください。

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

同時実行スレッド数およびWebアプリケーション単位の実行待ちキューサイズの設定例について説明します。ここでは，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‒17　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.15.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.16　URLグループ単位での同時実行スレッド数の制御

この節では，URLグループ単位での同時実行スレッド数の制御について説明します。

なお，URLグループ単位でスレッド数を制御するときには，Webコンテナ単位，およびWebアプリケーション単位でのスレッド数制御も同時に設定する必要があります。「2.14　Webコンテナ単位での同時実行スレッド数の制御」および「2.15　Webアプリケーション単位での同時実行スレッド数の制御」もあわせて参照してください。

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

表2‒48　この節の構成（URLグループ単位での同時実行スレッド数の制御）

分類

タイトル

参照先

解説

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

2.16.1

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

2.16.2

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

2.16.3

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

2.16.4

実装

cosminexus.xmlでの定義

2.16.5

設定

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

2.16.6

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

2.16.7

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

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

Webアプリケーション単位より細かい粒度で同時実行スレッド数制御をしたい場合，URLグループ単位で同時実行スレッド数を制御します。

一つのWebアプリケーション内に処理に時間が掛かる業務ロジック（サーブレットやJavaBeans）がある場合，Webアプリケーション内の同時実行スレッド数のほとんどが使用されてしまい，ほかの業務ロジックの処理が待ち状態になるおそれがあります。このような場合にURLグループ単位の同時実行スレッド数制御を設定することで，Webアプリケーション内の業務ロジックがほかの処理に影響を与えることなく実行できます。

なお，URLグループ単位の同時実行スレッド数の設定の指針については，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.3.4　Webアプリケーションの同時実行数を制御する」を参照してください。

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

同時実行スレッド数制御で制御できるURL，およびURLパターンに指定したURLとリクエストURLとのマッピングの順序について説明します。また，welcomeファイルに対してURLパターンを設定している場合についても説明します。

(1)　同時実行スレッド数制御で制御できるURL

URLグループ単位での同時実行スレッド数制御で制御できるURLとは，RFC 2616で定義されているリクエストURIを指します。URLグループ単位での同時実行スレッド数制御で制御できるURLは，リクエストURIのスキーム，ホスト，ポート，およびクエリ文字列を含みません。

URLグループ単位での同時実行スレッド数制御で制御できるURLの例を次に示します。

受信したHTTPリクエストのリクエストURI：

http://localhost/webapp/index.html?id=0001

URLグループ単位の同時実行スレッド数制御で使用する部分：

/webapp/index.html

(2)　マッピングの順序

リクエストURLは，次の1.〜3.の順序でマッピングされます。なお，マッピングの順序は，Servlet仕様のサーブレットマッピングの適用順序と同じです。

完全一致

リクエストURLとURLパターンが完全に一致する場合，一致したURLパターンが適用されます。

プリフィックス一致

リクエストURLとプリフィックスが一致し，さらに，リクエストURLとできるだけ長く文字列が一致するURLパターンが適用されます。

拡張子一致

リクエストURLと拡張子が一致する場合，一致したURLパターンが適用されます。

なお，上記の1.〜3.に一致しない場合は，URLグループ単位の同時実行スレッド数制御の対象にはなりません。このようなリクエストURLは，Webアプリケーション単位の同時実行スレッド数制御の対象になります。

次に示すURLパターンを使用して，URLのマッピングの例を説明します。

表2‒49　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に振り分けられます。

(3)　welcomeファイルにURLパターンを設定しているときの処理の流れ

welcomeファイルにURLパターンを設定しているときの処理の流れについて，次の図で説明します。この図の例では，Webアプリケーションのコンテキストルートはcontextとし，welcomeファイルはweb.xmlで/index.htmlが設定されているものとします。また，URLパターンとURLグループ単位での同時実行スレッド数制御の定義名は次のとおりとします。

URLパターン：/index.html

URLグループ単位での同時実行スレッド数制御の定義名：Control1

図2‒18　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.16.3　同時実行スレッド数の制御に必要なパラメタ（URLグループ単位）

ここでは，URLグループ単位でスレッド数を制御する場合の設定について説明します。URLグループ単位でスレッド数を制御する場合は，次の設定が必要になります。

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

Webコンテナ単位の最大同時実行スレッド数などを設定します。なお，ここで設定した最大同時実行スレッド数は，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有します。

Webコンテナ単位での同時実行スレッド数制御の設定については，「2.14　Webコンテナ単位での同時実行スレッド数の制御」を参照してください

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

Webアプリケーション単位の同時実行スレッド数や，占有スレッド数などを設定します。なお，URLグループ単位での同時実行スレッド数を設定する場合，Webアプリケーション単位での占有スレッド数の設定は必須になります。

Webアプリケーション単位での同時実行スレッド数制御の設定については，「2.15　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

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

URLグループ単位の同時実行スレッド数制御は，Webアプリケーション単位での同時実行スレッド数制御を設定しているWebアプリケーション内のURLグループに対して，次に示すパラメタを設定します。

URLグループ単位の同時実行スレッド数制御の定義名

同時実行スレッド数制御の単位となるURLグループの名称を設定します。

最大同時実行スレッド数

URLグループで最大で幾つのスレッドを同時に実行できるかを設定します。

占有スレッド数

URLグループの占有スレッド数を設定します。

URLグループ単位の実行待ちキューサイズ

URLグループの実行待ちキューサイズを設定します。

URLパターン

スレッド数制御の対象となるリクエストURLに振り分けるための，URLパターンを設定します。

以降で，URLグループ単位での同時実行スレッド数制御の設定項目の詳細を説明します。

(1)　URLグループ単位の最大同時実行スレッド数

URLグループ単位で使用するスレッド数は，URLグループが属するWebアプリケーションのスレッド数です。このため，URLグループ単位でスレッドを一つ使用している場合，そのURLグループを含むWebアプリケーションでもスレッドが一つ実行されていることになります。

なお，URLグループ単位の最大同時実行スレッド数を設定していないリクエストURLについては，Webアプリケーション単位の共有スレッド数が使用されます。Webアプリケーション単位の共有スレッド数は，次のようになります。

Webアプリケーション単位の共有スレッド数＝

Webアプリケーション単位の最大同時実行スレッド数※−URLグループ単位の占有スレッド数の合計

注※　ここでの最大同時実行スレッド数の値には，次の1.と2.のうち，小さい方の値が適用されます。

Webコンテナ単位の共有スレッド数

Webアプリケーション単位の最大同時実行スレッド数に設定した値

このとき，Webアプリケーション単位の共有スレッド数は1以上である必要があります。共有スレッド数が0以下になる場合は，エラーが発生します。詳細は，「2.15.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.16.2　URLパターンのマッピング処理」を参照してください。

URLグループ単位で同時実行スレッド数を制御する場合，Webアプリケーション単位での同時実行スレッド数制御，およびWebコンテナでのスレッド数制御も同時に設定する必要があります。URLグループ単位での同時実行スレッド数制御で設定するパラメタを次の表に示します。

表2‒50　URLグループ単位でスレッド数を制御する場合の設定パラメタ

設定するパラメタ

設定単位

Webコンテナ単位

Webアプリケーション単位

URLグループ単位

最大同時実行スレッド数

○

○

○

占有スレッド数

−

○

○

実行待ちキューサイズ

−

○

○

デフォルトの実行待ちキューサイズ

−

○

−

URLグループ単位の同時実行スレッド数制御の定義名

−

−

○

制御対象となるURLパターン

−

−

○

（凡例）　○：設定する　−：該当しない

次に，URLグループ単位での同時実行スレッド数制御の設定について説明します。URLグループ単位での同時実行スレッド数の制御は，サーバ管理コマンドで設定します。なお，Webコンテナ単位での設定パラメタについては，「2.14.2　実行環境での設定（J2EEサーバの設定）」を，Webアプリケーション単位での設定パラメタについては，「2.15.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コマンドで編集内容を反映させてください。サーバ管理コマンドについては，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

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

URLグループ単位の同時実行スレッド数制御をする場合の設定の指針について説明します。

URLグループ単位の同時実行スレッド数制御の設定をする場合，事前に次の内容を設定しておいてください。

Webコンテナ単位の最大同時実行スレッド数

Webアプリケーション単位の最大同時実行スレッド数，占有スレッド数，実行待ちキューサイズ

設定する値は，次の順に決定してください。

URLグループ単位の最大同時実行スレッド数を設定する。

URLグループ単位の占有スレッド数を設定する。

URLグループ単位の実行待ちキューサイズを設定する。

URLパターンを設定する。

URLグループ単位の最大同時実行スレッド数は，J2EEアプリケーション内にある業務ロジックに対して，適切な値を設定してください。

例えば，特定の業務ロジックの処理が重い場合，その業務ロジックの同時実行スレッド数に上限を設けることで，特定の業務ロジックにアクセスが集中した場合でも，特定の業務ロジックがWebアプリケーション全体の処理能力を占有するのを防ぐことができます。

URLグループ単位の占有スレッド数は，特定の業務ロジックをWebアプリケーション内のほかの業務ロジックの影響を受けないで実行させるために設定します。

URLグループ単位の実行待ちキューサイズは，特定の業務ロジックへの流量の上限を設けるために設定します。URLグループ単位の実行待ちキューは，デフォルトの実行待ちキュー，Webアプリケーション単位の実行待ちキューと設定指針は同じです。

2.16.5　cosminexus.xmlでの定義

アプリケーションの開発環境で必要なcosminexus.xmlでの定義について説明します。

URLグループ単位での同時実行スレッド数の制御をするための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのURLグループ単位での同時実行スレッド数の制御の定義について次の表に示します。

表2‒51　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>タグで囲んで指定します。

指定するタグの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

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

URLグループ単位での同時実行スレッド数の制御をする場合，Webアプリケーションの設定が必要です。

なお，Webアプリケーションの設定は，cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。URLグループ単位での同時実行スレッド数の制御の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.16.5　cosminexus.xmlでの定義」を参照してください。

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

同時実行スレッド数およびURLグループ単位の実行待ちキューサイズの設定例について説明します。ここでは，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‒19　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.17　同時実行スレッド数の動的変更

この節では，同時実行スレッド数の動的変更について説明します。

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

表2‒52　この節の構成（同時実行スレッド数の動的変更）

分類

タイトル

参照先

解説

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

2.17.1

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

2.17.2

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

2.17.3

注意事項

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

2.17.4

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

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

ここでは，同時実行スレッド数の動的変更の概要について説明します。

(1)　同時実行スレッド数の動的変更の用途

アプリケーションサーバを使用して構築したシステムでは，Webアプリケーション単位の最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズを，サービスを停止しないで動的に変更できます。Webアプリケーション単位の最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズは，運用管理コマンド（mngsvrutil）を使用して変更します。

Webアプリケーション単位の最大同時実行スレッド数を変更すると，次のような局面に対応できます。

Webアプリケーション単位の稼働状態でのパフォーマンスチューニング

クライアントにサービスを提供しながらパフォーマンスをチューニングできます。

アクセス状況に応じた一時的なWebアプリケーション単位の最大同時実行スレッド数の変更

アクセス状況に応じて，特定のWebアプリケーションの最大同時実行スレッド数を一時的に増加または減少させたい場合に，対処できます。

時間帯に応じた計画的なWebアプリケーション単位の最大同時実行スレッド数の変更

時間帯に応じて，Webアプリケーションの最大同時実行スレッド数を計画的に増加または減少させたい場合に，対処できます。

なお，ここで設定した項目は，サービスを停止すると無効になり，設定内容はJ2EEサーバに保存されません。また，この方法で動的に変更できるのは，Webアプリケーションについての情報だけです。Webコンテナについての設定を変更する場合は，J2EEサーバを再起動しないと有効になりません。

Webコンテナ単位の最大同時実行スレッド数を変更したい場合，また，Webアプリケーションの最大同時実行スレッド数を一時的ではなく恒常的に変更したい場合は，システムの構築時と同じ手順で設定してください。

注意事項

Webアプリケーションの最大同時実行スレッド数を変更した場合，URLグループ単位の最大同時実行スレッド数や占有スレッド数との関係によっては，URLグループ単位の同時実行スレッド数制御の動作へ影響が出ることがあります。詳細については「2.17.1(4)　URLグループ単位の同時実行スレッド数制御への影響」を参照してください。

(2)　設定変更の例

ここでは，特定のWebアプリケーションに対して，スループットを向上し，エラーとなるリクエストを減らしたい場合の，設定変更例を紹介します。この例では，Webアプリケーションの，最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズを増やしています。なお，同時実行スレッド数の動的変更では，Webコンテナ単位の最大同時実行スレッド数およびURLグループ単位の最大同時実行スレッド数は変更できません。

表2‒53　同時実行スレッド数の動的変更の例

パラメタ

変更前の設定値

変更後の設定値

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.17.2　同時実行スレッド数の動的変更の流れ

Webアプリケーションの最大同時実行スレッド数を動的に変更するための準備と手順を次に示します。

準備

Webアプリケーションの最大同時実行スレッド数の動的変更は，J2EEサーバおよびWebアプリケーションを含むJ2EEアプリケーションが起動，開始されている状態で実行します。

J2EEサーバの起動ついては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.24　システムを起動する（CUI利用時）」を参照してください。J2EEアプリケーションの開始を含むシステムの起動方法については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.29　業務アプリケーションを設定して開始する（CUI利用時）」を参照してください。

手順

次の手順で実行します。

Webアプリケーションの稼働状況を監視して，最大同時実行スレッド数を変更する必要があるかどうかを確認する（(1)参照）

運用管理コマンドを使用して実行します。

必要と判断した場合，Webアプリケーションの最大同時実行スレッド数を変更する（(2)参照）

運用管理コマンドを使用して実行します。

Webアプリケーションの稼働状況を確認して，改善されたことを確認する（(1)参照）

運用管理コマンドを使用して実行します。

(1)　Webアプリケーションの稼働状況の確認

稼働中のWebアプリケーションの稼働状況を確認します。Webアプリケーションの稼働状況は，運用管理コマンド（mngsvrutil）で確認できます。確認した結果，例えば，次のような場合には，最大同時実行スレッド数を変更することを検討してください。

稼働スレッド数に比べて実行待ちスレッド数が極端に多い状況を想定していない場合に，稼働スレッド数に比べて実行待ちスレッド数が極端に多いとき

Webアプリケーション単位の実行待ちリクエスト数の現在値が，Webアプリケーション単位の実行待ちリクエスト数の最大値に近づいている状況を想定していない場合に，Webアプリケーション単位の実行待ちリクエスト数の現在値が，Webアプリケーション単位の実行待ちリクエスト数の最大値に近づいているとき

Webアプリケーション単位の実行待ちキューからリクエストがあふれる状況を想定していない場合に，その実行待ちキューからリクエストがあふれているとき

なお，監視した結果，一時的にではなく恒常的に最大同時実行スレッド数を変更する必要があると判断した場合は，動的変更をするのではなく，Webアプリケーションを停止して，最大同時実行スレッド数の設定をし直してください。Webアプリケーションを停止した状態でのWebコンテナでの最大同時実行スレッド数の制御の設定については，「2.14　Webコンテナ単位での同時実行スレッド数の制御」，「2.15　Webアプリケーション単位での同時実行スレッド数の制御」，および「2.16　URLグループ単位での同時実行スレッド数の制御」を参照してください。

Webアプリケーションの稼働状況を確認するには，mngsvrutilコマンドに，サブコマンド「get」を指定して実行します。

実行形式および実行例を次に示します。なお，mngsvrutilコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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‒54　 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アプリケーション単位の実行待ちキューからあふれたリクエスト数。

maxThreads（最大スレッド数）の確認方法

mngsvrutilコマンドの実行結果からcurrentThreadCountUpperBoundの値を確認します。

または，Webアプリケーションの稼働情報ファイルに出力される情報からActiveThreadCount.UpperBoundの値を確認します。

exclusiveThreads（占有スレッド数）の確認方法

mngsvrutilコマンドの実行結果およびWebアプリケーションの稼働情報ファイルに出力される情報共に反映されません。

queueSize（Webアプリケーション単位の実行待ちキューサイズ）

mngsvrutilコマンドの実行結果に反映されません。

Webアプリケーションの稼働情報ファイルに出力される情報からWaitingRequestCount.UpperBoundの値を確認します。

(2)　Webアプリケーションの最大同時実行スレッド数の設定変更

稼働状況を確認したWebアプリケーションの次の項目を，必要に応じて変更します。

最大同時実行スレッド数

占有スレッド数

実行待ちキューサイズ

これらの項目は，運用管理コマンド（mngsvrutil）を使用して変更できます。ここで設定した値は，Webアプリケーションを停止するまで有効です。

注意事項

Webアプリケーションの最大同時実行スレッド数の動的変更実行中（mngsvrutilコマンドにサブコマンド「change」を指定して実行している間）は，J2EEアプリケーションのデプロイおよびアンデプロイは実行しないでください。

Webアプリケーションの最大同時実行スレッド数を動的に変更するには，mngsvrutilコマンドに，サブコマンド「change」を指定して実行します。

実行形式を次に示します。なお，mngsvrutilコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

(a)　実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <ホスト名> -k host change webAppThreadCtrl <Webアプリケーションのコンテキストルート> <最大同時実行スレッド数>,<占有スレッド数>,<Webアプリケーション単位の実行待ちキューサイズ>

次に，実行例を示します。この例では，次の表に示すように設定を変更します。なお，Webアプリケーションの名称は，「WebAP1」とします。

表2‒55　 Webアプリケーション（WebAP1）の最大同時実行スレッド数の動的変更の設定例

設定対象

設定項目

変更前の設定値

変更後の設定値

Webコンテナ

最大同時実行スレッド数

10

10（変更できません）

Webアプリケーション（WebAP1）

最大同時実行スレッド数

7

8

占有スレッド数

4

5

実行待ちキューサイズ

8

10

(b)　実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host change webAppThreadCtrl "WebAP1" 8,5,10

設定内容は，コマンド実行後，すぐに反映されます。

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

ここでは，Webアプリケーションの最大同時実行スレッド数を動的に変更したときの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.17.4　同時実行スレッド数の動的変更についての注意事項

動的に変更できるのは，Webアプリケーション単位の同時実行スレッド数の設定です。Webコンテナ単位の同時実行スレッド数およびURLグループ単位の同時実行スレッド数は，動的に変更できません。

動的に変更された同時実行スレッド数の情報はJ2EEサーバには保存されません。このため，サービスを停止すると変更した値は無効になるので注意してください。

Webアプリケーション単位の同時実行スレッド数の動的変更によって，Webアプリケーション単位の共有スレッド数が0以下になると，Webアプリケーション内のすべてのURLグループ単位で設定している占有スレッド数が使用できなくなります。

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

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。クライアント側では，Webコンテナから返されたエラーステータスコードに対応するエラーページが表示されます。アプリケーションサーバでは，クライアントで表示されるエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

エラーページをカスタマイズするには，Servlet仕様で規定されているweb.xmlの<error-page>タグを使用する方法と，Webサーバの機能を使用する方法があります。

Webサーバの機能を使用する場合のエラーページのカスタマイズについては，マニュアル「HTTP Server」の「ErrorDocument」ディレクティブを参照してください。

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

一度アクセスした静的コンテンツは，メモリ上にキャッシュできます。一度アクセスした静的コンテンツをメモリ上にキャッシュし，2回目以降のアクセスではキャッシュからブラウザにレスポンスを返すことで，静的コンテンツのレスポンスタイムを短縮できます。

Webコンテナでは，Webアプリケーション単位でキャッシュに使用するメモリサイズの上限と，キャッシュの対象とする静的コンテンツのファイルサイズの上限を設定して，静的コンテンツのキャッシュを制御できます。

この節では，静的コンテンツのキャッシュについて説明します。

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

表2‒56　この節の構成（静的コンテンツのキャッシュ）

分類

タイトル

参照先

解説

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

2.19.1

実装

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

2.19.2

設定

実行環境での設定

2.19.3

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

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

Webコンテナでは，Webアプリケーション単位でキャッシュに使用するメモリサイズの上限と，キャッシュの対象とする静的コンテンツのファイルサイズの上限を設定して，静的コンテンツのキャッシュを制御できます。

静的コンテンツのキャッシュの制御には次の2種類の方法があります。

Webコンテナ単位の静的コンテンツのキャッシュの制御

静的コンテンツのキャッシュをWebコンテナ単位で制御する方法です。Webコンテナ単位に，Webアプリケーション単位でキャッシュするメモリサイズの上限値と，キャッシュを許可する静的コンテンツのファイルサイズの上限値を設定します。設定したWebアプリケーション単位のキャッシュに使用するメモリサイズの上限値，および静的コンテンツのファイルサイズの上限値は，WebコンテナにデプロイされているすべてのWebアプリケーションに適用されます。

Webアプリケーション単位の静的コンテンツのキャッシュの制御

静的コンテンツのキャッシュをWebアプリケーション単位で制御する方法です。Webアプリケーション単位に，キャッシュするメモリサイズの上限値，およびキャッシュを許可するファイルサイズの上限値を設定します。

Webアプリケーション単位での制御と，Webコンテナ単位での制御の両方を設定した場合，Webアプリケーション単位での制御の設定が優先されます。

なお，Webアプリケーション単位のキャッシュするメモリサイズが上限値を超えた場合，または静的コンテンツのファイルサイズが上限値を超えた場合は，メモリ上にはキャッシュしないで，毎回ファイルシステムからブラウザにレスポンスを返します。

静的コンテンツのキャッシュの設定は，設定する範囲ごとに，次の個所に設定します。

Webコンテナ単位の静的コンテンツのキャッシュの制御

J2EEサーバのプロパティとして指定します。

Webアプリケーション単位の静的コンテンツのキャッシュの制御

Webアプリケーションの属性（プロパティ）として設定します。

注意事項

J2EEアプリケーションのリロード機能が有効な場合は，静的コンテンツのキャッシュ機能は無効になるので注意してください。

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

Webアプリケーション単位に，静的コンテンツのキャッシュ機能を使用するかどうか，キャッシュを許可する静的コンテンツのメモリサイズ，およびファイルサイズの上限値を設定します。

アプリケーションの開発環境で必要なDDでの定義について説明します。

静的コンテンツのキャッシュのWebアプリケーション単位の定義は，web.xmlの<web-app><context-param>タグ内の<param-name>タグに指定します。

DDでの静的コンテンツのキャッシュの定義について次の表に示します。

表2‒57　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.19.3　実行環境での設定

静的コンテンツのキャッシュをWebコンテナ単位に定義する場合，J2EEサーバの設定が必要です。

静的コンテンツのキャッシュをWebアプリケーション単位に定義する場合，Webアプリケーションの設定が必要です。cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

ポイント

Webコンテナ単位での設定，Webアプリケーション単位での設定をどちらも設定した場合には，Webアプリケーション単位での設定が優先されます。

(1)　J2EEサーバの設定（Webコンテナ単位での設定）

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナ単位での静的コンテンツのキャッシュの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでの静的コンテンツのキャッシュの定義について次の表に示します。

表2‒58　簡易構築定義ファイルでの静的コンテンツのキャッシュの定義

項目

指定するパラメタ

設定内容

静的コンテンツキャッシュ機能の有効／無効

webserver.static_content.cache.enabled

静的コンテンツのキャッシュの有効，無効，または強制無効を指定します。

Webアプリケーション単位のメモリサイズ

webserver.static_content.cache.size

静的コンテンツのキャッシュを許可する，Webアプリケーション単位のメモリサイズを設定します。

キャッシュを許可するファイルサイズ

webserver.static_content.cache.filesize.threshold

静的コンテンツのキャッシュを許可する，Webアプリケーション単位のファイルサイズの上限値を指定します。

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

(2)　Webアプリケーションの設定（Webアプリケーション単位での設定）

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。静的コンテンツのキャッシュの定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，DDと対応しています。DDでの定義については，「2.19.2　DDでの定義（Webアプリケーション単位での設定）」を参照してください。

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

この節では，Webアプリケーションのバージョン設定機能について説明します。

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

表2‒59　この節の構成（Webアプリケーションのバージョン設定機能）

分類

タイトル

参照先

解説

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

2.20.1

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

2.20.2

設定

実行環境での設定

2.20.3

注意事項

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

2.20.4

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

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

アプリケーションサーバでは，Webアプリケーションの実行時に，web.xmlに定義されているWebアプリケーションのバージョンに準拠して，ServletやJSPが実行されます。

Webアプリケーションのバージョン設定機能は，Webアプリケーション実行時のバージョンを指定するための機能です。この機能を使用すると，web.xmlで定義されているWebアプリケーションのバージョンを変更しないで，設定したバージョンに準拠してWebアプリケーションを実行できます。

注意事項

Webアプリケーションのバージョン設定機能は，旧バージョンのアプリケーションの移行などを支援するための機能です。新規にアプリケーションを開発する場合に使用することは推奨しません。新規にアプリケーションを開発する場合は，正しいバージョンのweb.xmlを指定してください。

Webアプリケーションのバージョン設定機能では，バージョン3.0以降の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‒60　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アプリケーションとして動作します。

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

Webアプリケーションのバージョン設定機能を使用する際で，JSPファイルおよびタグファイルのコンパイル時と実行時でJSP仕様のバージョンが異なる場合の実行時の動作について説明します。ここでは，JSP事前コンパイル機能を使用している場合と，使用していない場合に分けて説明します。

(1)　JSP事前コンパイル機能を使用している場合

JSP事前コンパイル機能では，JSPファイルのコンパイル時に，JSPファイルから生成されたクラスファイルだけでなく，バージョン情報ファイルも作成されます。バージョン情報ファイルは，JSP事前コンパイル機能実行時に出力されるファイルで，JSPファイルのバージョンが記載されています。

このため，JSPのバージョンが異なる状態には，次の二つの場合があります。

バージョン情報ファイルとWebアプリケーション実行時のWebアプリケーションバージョンに対応するJSP仕様のバージョンが異なる場合

JSP事前コンパイル機能によってJSPファイルから生成されたクラスファイルのバージョンと，それに対応するJSP仕様のバージョンが異なる場合

それぞれの場合について，Webアプリケーションの動作を，次の表に記述します。

表2‒61　バージョン情報ファイルとJSP仕様のバージョンが異なる場合

ファイル変更のタイミング

Webアプリケーションの動作

Webアプリケーション開始前

ケース1

Webアプリケーション開始後

リロード有効時

ケース2

リロード無効時

ケース1

Webアプリケーション開始前にJSP事前コンパイルコマンドが実行されている場合，Webアプリケーション開始時にKDJE39522-Eが出力されて，Webアプリケーションの開始に失敗します。

ケース2

J2EEサーバの再起動またはWebアプリケーションの再開始後，ケース1と同じ動作になります。

表2‒62　クラスファイルと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：JSP 1.2仕様で再コンパイルされる

2.0：JSP 2.0仕様で再コンパイルされる

2.1：JSP 2.1仕様で再コンパイルされる

注※1

web.xmlのバージョンが2.2の場合はWebアプリケーションバージョン2.3として動作するため，JSP 1.2仕様で再コンパイルされます。

注※2

JSP 2.1仕様では，タグファイルはTLDファイルに定義されるJSPバージョンによって準拠するJSP仕様が決定されます。Webアプリケーションバージョンが2.5でも，タグファイルはJSP 2.0仕様で動作できるため，再コンパイルされません。

2.20.3　実行環境での設定

Webアプリケーションのバージョン設定機能を使用する場合，J2EEサーバおよびJSP事前コンパイルのコマンド設定が必要です。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webアプリケーションのバージョン設定機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.application.lower_versionに指定します。このパラメタでは，Webアプリケーションのバージョン設定機能を使用するかどうかを指定します。

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

(2)　JSP事前コンパイルのコマンドでの設定

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

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

ここでは，Webアプリケーションのバージョン設定機能を使用する場合の注意事項について説明します。

(1)　アノテーションの使用

Webアプリケーションのバージョン設定機能でアノテーションを使用できるWebアプリケーションのバージョンを設定しても，アノテーション情報は読み込まれません。

(2)　J2EEアプリケーションのエクスポート

Webアプリケーションのバージョン設定機能を有効にして，Webアプリケーションをエクスポートした場合，Webアプリケーションのバージョン設定機能で設定したバージョンに変更されてエクスポートはされません。インポートしたときと同じバージョンのWebアプリケーションがエクスポートされます。

2.21　Webコンテナに関する注意事項

Webコンテナで取り扱えるPOSTデータの最大サイズは2⁶³-1バイトです。また，Webコンテナの設定や，WebコンテナのフロントにあるWebサーバの設定によって，取り扱えるPOSTデータの最大サイズは制限されます。

Webコンテナが返すEta（Entity Tag）は，ファイルサイズおよび最終更新日時から構成され，ファイルに割り当てられた一意なID（inode）は含まれません。

URLに"%2F"または"%5C"を含むリクエストを受信した場合，セキュリティ脆弱性を考慮し，Webコンテナはエラーステータスコード400を返します。

2.22　セッションマネージャの指定機能

この節では，セッションマネージャの指定機能について説明します。

アプリケーションサーバでは，セッションフェイルオーバ機能をサポートしています。セッションフェイルオーバ機能を使用すると，システム内の特定のJ2EEサーバに障害が発生した場合に，障害発生前のセッション情報を引き継いで，ほかのJ2EEサーバで業務を続行できます。

同様のことをクラウド環境で実施する場合は，セッションマネージャの指定機能を使用してください。

なお，オンプレミス環境の場合にセッションフェイルオーバ機能を使用するときは，マニュアル「アプリケーションサーバ機能解説 拡張編」の「データベースセッションフェイルオーバ機能」を参照してください。

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

表2‒63　この節の構成（セッションマネージャの指定機能）

分類

タイトル

参照先

解説

セッションマネージャの指定機能の概要

2.22.1

設定

セッションマネージャの指定

2.22.2

セッションマネージャの指定機能で使用するプロパティ

2.22.3

セッションマネージャの指定機能（性能解析トレースおよびログ出力対応）

2.22.4

2.22.1　セッションマネージャの指定機能の概要

セッションマネージャの指定機能の構成とセッションの流れを次の図に示します。

図2‒20　セッションマネージャの指定機能の構成とセッションの流れ

注

WebサーバとJ2EEサーバは，AWSの仮想マシンに配置してください。このとき，同じ仮想マシン内に，AWSサービスに接続するためのライブラリを配置してください。

セッション情報は，J2EEサーバをスケールインおよびスケールアウトしてもリクエストが正常に動作するように，ライブラリを通してAWSサービスに格納してください。

Webコンテナのセッションマネージャは，HTTP セッションを作成して維持するために使われます。各ライブラリは，セッションマネージャを実装しています。

セッションマネージャの指定機能は，AWS環境でグローバルセッション情報を外部に保存する場合にだけ使用できます。グローバルセッション情報については，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「5.3.1　グローバルセッション情報」を参照してください。

注意事項

セッションマネージャを指定した場合，明示管理ヒープ機能は使用できません。明示管理ヒープ機能が有効の場合に，セッションマネージャの指定機能を指定したアプリケーションが存在すると，アプリケーションの起動に失敗します。

明示管理ヒープ機能はサーバ単位で指定するため，明示管理ヒープ機能を使用するアプリケーションと，セッションマネージャの指定機能を使用するアプリケーションは同一サーバに配置できません。

セッションフェイルオーバ機能と，セッションマネージャの指定機能は同時に指定できません。同時に指定した場合，アプリケーションの起動に失敗します。

セッションマネージャの指定機能では，アプリケーションサーバで提供しているインタフェースで，ライブラリが動作するようにしています。実際のシステムへ適用する場合，ライブラリの機能および動作の詳細については，ライブラリの開発元にお問い合わせください。

2.22.2　セッションマネージャの指定

セッションマネージャは，ユーザ定義プロパティで指定します。ユーザ定義プロパティを次に示します。

webserver.sessionManager.<コンテキストルート名>.className=<セッションマネージャのクラス名>

セッションマネージャは，war単位に指定します。<コンテキストルート名>にwarのコンテキストルートを指定します。<セッションマネージャのクラス名>に使用するライブラリのセッションマネージャを指定します。コンテキストルート名が「/examples」の場合の設定例を次に示します。

webserver.sessionManager./examples.className=de.javakaffee.web.msm.MemcachedBackupSessionManager

webserver.sessionManager.<コンテキストルート名>.classNameで指定できる値は，de.javakaffee.web.msm.MemcachedBackupSessionManagerとなります。それ以外の値を指定した場合は，アプリケーションの起動に失敗します。

サーバ単位でセッションマネージャを指定する場合は，コンテキストルート名にはアスタリスクを指定します。設定例を次に示します。

webserver.sessionManager.*.className=de.javakaffee.web.msm.MemcachedBackupSessionManager

war単位の指定とサーバ単位の指定を同時に指定することもできます。その場合は，war単位で指定したセッションマネージャを優先します。それ以外のwarはアスタリスクで指定したセッションマネージャが指定されます。

(1)　セッションマネージャの指定機能のバックグラウンド処理

セッションマネージャを指定した場合，ライブラリ側のバックグラウンド処理の実装によっては，セッションのタイムアウト処理やバックアップ処理が実行されます。ライブラリ側のバックグラウンド処理が実行されるようにするためには，Webコンテナ側でスレッドを作成する必要があります。

スレッドは，J2EEサーバ用ユーザプロパティファイルのwebserver.sessionManager.backgroundProcessor.threadsのプロパティに，スレッド数を指定することで作成できます。設定例を次に示します。

webserver.sessionManager.backgroundProcessor.threads=2

この値のデフォルト値は0です。スレッド数はサーバ単位での指定であり，セッションマネージャを指定したすべてのアプリケーションで使い回されます。セッションマネージャの指定機能の使用の有無に関係なく，指定した数のスレッドが作成されます。この値を-1にした場合または不正な値を指定した場合，デフォルト値が使用されます。スレッドが作成されない場合，指定されたセッションマネージャのバックグラウンド処理は実行されません。

注意事項

スティッキーセッションを無効にしてmemcached session managerを使用する場合，バックグラウンド処理でセッションのタイムアウト処理やバックアップ処理は実行されません。memcached session managerでスティッキーセッションを無効にする場合は，J2EEサーバ用ユーザプロパティファイルのwebserver.sessionManager.backgroundProcessor.threadsのプロパティに0（デフォルト値）を設定してください。

指定されたセッションマネージャのバックグラウンド処理を実行する場合，実行間隔を指定できます。バックグラウンド処理は，J2EEサーバ用ユーザプロパティファイルのwebserver.sessionManager.backgroundProcessor.delayのプロパティに指定した実行間隔（秒単位）を6倍した間隔で実行されます。10を指定した場合，60秒間隔でバックグラウンド処理が実行されます。設定例を次に示します。

webserver.sessionManager.backgroundProcessor.delay=10

この値のデフォルト値は10です。実行間隔はサーバ単位での指定になり，セッションマネージャを指定したすべてのアプリケーションで同じ値を使用します。この値を0以下にした場合，バックグラウンド処理は実行されません。不正な値を指定した場合，デフォルト値が使用されます。

(2)　HttpSessionオブジェクト数の上限値の指定

指定されたセッションマネージャのHttpSessionオブジェクト数の上限値を指定できます。上限値はmaxActiveSessionsプロパティに指定します。設定例を次に示します。classNameと同じように，コンテキストルート名にアスタリスクを指定できます。

webserver.sessionManager./examples.maxActiveSessions=-1

HttpSessionオブジェクト数の上限値を設定した場合の動作は，cosminexus.xmlの<war>タグ内の<http-session>-<http-session-max-number>を設定した場合と同じ動作になります。cosminexus.xmlに上限値を設定した場合は，警告メッセージを出力してcosminexus.xmlの設定を無視します。

(3)　セッションマネージャのプロパティの指定

classNameとmaxActiveSessionsはアプリケーションサーバで用意するプロパティですが，指定されたセッションマネージャのプロパティを指定することもできます。webserver.sessionManager.<コンテキストルート名>.propertiesのあとに，セッションマネージャのプロパティ名を指定します。指定できるプロパティは各セッションマネージャを参照してください。propertiesのコンテキストルート名にはアスタリスクは指定できません。

webserver.sessionManager.<コンテキストルート名>.properties.<プロパティ名>=<値>

memcached session managerの指定例を次に示します。プロパティの詳細はmemcached session managerのドキュメントを参照してください。

webserver.sessionManager./examples.properties.memcachedNodes=node1:11211
webserver.sessionManager./examples.properties.sticky=false
webserver.sessionManager./examples.properties.sessionBackupAsync=false

(4)　セッションフェイルオーバ機能との関係

アプリケーションサーバのセッションフェイルオーバ機能の前提となる設定と，セッションマネージャの指定機能の関係を次に示します。

(a)　アプリケーションサーバのセッションフェイルオーバ機能の前提となる設定

HTTPセッションのスティッキー（Sticky）の設定

アプリケーションサーバのセッションフェイルオーバ機能はスティッキーセッションを使用することが前提となっています。スティッキーセッションを使用することで，リクエストを処理するインスタンスを限定して性能劣化を防ぎます。

セッションマネージャの指定機能を使用したクラウド環境では，インスタンスのスケールインおよびスケールアウトのために，スティッキーセッションは使用しないことを前提とします。グローバルセッションをインメモリ製品に保存することで，性能劣化を防ぎます。スティッキーセッションは通常，負荷分散機とライブラリ側で設定します。

ホストの時刻の設定

システム内のJ2EEサーバが稼働するそれぞれのノードは同じ時刻を設定します。時刻が異なる場合の動作は保証しません。

(b)　アプリケーションサーバのデータベースセッションフェイルオーバ機能の前提となる設定

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

アプリケーションサーバのデータベースセッションフェイルオーバ機能の場合，cosminexus.xmlの<http-session>-<http-session-max-number>で指定します。セッションマネージャの指定機能では，maxActiveSessionsで指定します。設定例を次に示します。

webserver.sessionManager./examples.maxActiveSessions=-1

完全性保証モード

データベースセッションフェイルオーバの設定の注意事項なので，セッションマネージャの指定機能は関係ありません。

デフォルトの実行待ちキュー，Webアプリケーション単位の実行待ちキュー，およびURLグループ単位の実行待ちキューの設定

データベースセッションフェイルオーバの設定の注意事項なので，セッションマネージャの指定機能は関係ありません。

(5)　memcached session managerの設定

(a)　使用するファイル

セッションマネージャの指定機能では，ライブラリとしてmemcached session managerを使用します。ライブラリを使用するために必要なファイルを次に示します。memcached session managerの詳細に関しては，開発元のドキュメントを参照してください。

表2‒64　セッションマネージャの指定機能で使用するファイル

ファイル

バージョン

CCCサポートバージョン

入手先

memcached-session-manager-2.3.2.jar

2.3.2

11-10

memcached session managerの開発元のサイトから，サポートしているバージョンを入手してください。

memcached-session-manager-tc9-2.3.2.jar

2.3.2

11-10

elasticache-java-cluster-client-1.1.2.jar （memcached AWS用クライアント）

1.1.2

11-10

memcached session managerの機能を使用する場合に，上記以外のファイルが必要になる場合があります。詳細は開発元のドキュメントを参照してください。

(b)　ファイルの設定

アプリケーションサーバで，memcached session managerに接続する場合，（a）にあるファイルを，J2EEサーバ用オプション定義ファイルに定義します。また，ライブラリの設定をJ2EEサーバ用ユーザプロパティファイルに設定します。設定例を次に示します。ライブラリの設定のclassNameには，memcached session managerのセッションマネージャを指定します。memcachedNodesには接続先を設定します。stickyには，スティッキーセッションを有効にしないため，falseを指定します。また，sessionBackupAsyncにはfalseを指定し，Explicitヒープも無効にします。

J2EEサーバ用オプション定義ファイルの例

add.class.path=C:¥lib¥elasticache-java-cluster-client-1.1.2.jar
add.class.path=C:¥lib¥memcached-session-manager-2.3.2.jar
add.class.path=C:¥lib¥memcached-session-manager-tc9-2.3.2.jar
add.jvm.arg=-XX:-HitachiUseExplicitMemory

J2EEサーバ用ユーザプロパティファイルの例

webserver.sessionManager./examples.className=de.javakaffee.web.msm.MemcachedBackupSessionManager
webserver.sessionManager./examples.properties.memcachedNodes=node1:11211
webserver.sessionManager./examples.properties.sticky=false
webserver.sessionManager./examples.properties.sessionBackupAsync=false

(6)　memcached session managerの注意事項

アプリケーションサーバのセッションマネージャを使用した場合，一定間隔でタイムアウト監視をします。ただし，セッションマネージャの指定機能でスティッキーセッションを無効にした場合，セッションをWebコンテナで管理せずmemcachedで管理するため，アプリケーションサーバではタイムアウト監視をしません。タイムアウト監視をしないときのタイムアウトしたセッションの破棄については，管理しているmemcachedの仕様に依存します。memcachedの仕様については，memcachedのドキュメントやFAQを参照してください。

Webアプリケーションをリロードする場合，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用します。セッションマネージャの指定機能でスティッキーセッションを無効にする場合は，セッションをWebコンテナで管理しません。そのため，リロードを実行しても，セッション情報ファイルにセッション情報は出力されません。Webアプリケーションのリロード時のセッション情報の引き継ぎについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「18.8.8(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ」を参照してください。

セッションマネージャの指定機能を使用した場合，稼働統計のSessionCount.HighWaterMark,LowWaterMark,Currentは常に0になります。

セッションマネージャの指定機能でスティッキーセッションを無効にする場合，Webコンテナでセッションを管理しません。そのため，HttpSessionオブジェクト数の上限値を超えたセッションを作成しようとしても，例外にならないことがあります。リクエストの処理中は，Webコンテナ内にセッションを保持するため，HttpSessionオブジェクト数の上限値を超えたリクエストを同時に処理しようとした場合に，例外が発生します。HttpSessionオブジェクト数の上限値が0の場合，セッションを使用するリクエストがあった場合に，例外が発生します。HttpSessionオブジェクト数の上限値については，「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。

セッションマネージャの指定機能を使用する場合，memcachedノードがダウンしてセッション情報を保存できないときにアプリケーションが動作すると，セッションはリクエスト終了時に保存されず，破棄されます。そのため，memcachedノードがダウンしてセッション情報が保存できない状況にならないように，アプリケーションの運用には注意してください。

memcached session managerのスティッキーセッションの設定のデフォルト値はスティッキー有効（sticky=true）ですが，アプリケーションサーバで使用する場合のデフォルト値はスティッキー無効（sticky=false）になります。アプリケーションサーバでmemcached session managerを使用する場合，スティッキー有効にするためには明示的にsticky=trueを指定してください。

memcachedは，メモリがいっぱいのとき，更新内容の古いデータを新しいデータで上書きするため，セッションが期限切れになる前にセッションが削除されるおそれがあります。そのため，memcachedにメモリを割り当てる場合は，memcachedのメモリがいっぱいにならないように注意してください。

スティッキーセッションを無効にする場合，実際のセッションに加えて，SessionValidityInfoオブジェクトがmemcachedに格納されます。セッションとSessionValidityInfoの合計が，1セッションで使用するデータサイズになります。これらの実際の格納サイズは，セッションのシリアライズの方法によって異なります。そのため，memcachedのメモリを見積もるときは，セッションが格納されている状態で，コマンド等でこれらのサイズを確認してください。サイズの統計コマンドの実行例を次に示します。

# telnet localhost 11211
stats sizes
STAT 128 7
STAT 704 7
END

セッションの有効期限が切れても，memcachedのデータは削除されません。詳細はmemcachedのFAQを参照してください。

memcached session managerのJMXStatisticsは，アプリケーションサーバでは使用できません。

同一セッションでは，セッションを生成したリクエストとは別のリクエストでjavax.servlet.http.HttpSessionインタフェースのsetMaxInactiveIntervalメソッドを呼び出しても，HTTPセッションの有効期限は変更されません。setMaxInactiveIntervalメソッドの呼び出しは，セッションを生成したリクエストと同じリクエストで実施してください。

memcached session managerのプロパティのsessionBackupAsyncにtrue（デフォルト値）が指定されている場合，2台以上のJ2EEサーバを構成した環境でアプリケーションからセッションを取得したとき（javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドを呼び出したとき）に，セッションの存在に関係なく，nullが返ることがあります。そのため，sessionBackupAsyncにはfalseを指定してください。

2.22.3　セッションマネージャの指定機能で使用するプロパティ

プロパティファイルusrconf.propertiesに記載できるプロパティのうち，セッションマネージャの指定機能で使用するものを次に示します。

表2‒65　セッションマネージャの指定機能で使用するプロパティ

プロパティ名

概要

デフォルト値

webserver.sessionManager.<コンテキストルート名>.className

使用するライブラリのセッションマネージャのクラス名

org.apache.catalina.session.StandardManager

webserver.sessionManager.<コンテキストルート名>.maxActiveSessions

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

-1（上限なし）

2.22.4　セッションマネージャの指定機能（性能解析トレースおよびログ出力対応）

セッションマネージャの指定機能に関する性能解析トレースおよびログを出力します。これによって，障害発生時や性能劣化が起きたときに，アプリケーションサーバと，セッションマネージャの指定機能で使用するライブラリ（memcached session manager）の，どちらに原因があるかを特定できます。

性能解析トレース

性能解析トレースおよびログについての詳細は，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「8.8　Webコンテナのトレース取得ポイント（セッションマネージャの指定機能のトレース）」を参照してください。

タイムアウトによるセッション破棄

セッションマネージャの指定機能は，スティッキーセッションを無効に設定します（stickyにfalseを指定）。その場合，バックグラウンドスレッドでのタイムアウトによるセッション破棄は，アプリケーションサーバ側では発生しません。タイムアウトによるセッション破棄は，memcached側で実施されます。このため，タイムアウトによるセッション破棄のPRFはアプリケーションサーバでは出力されません。アプリケーションサーバ側から，セッション破棄されたかどうかを確認する場合は，memcachedにアクセス（findSessionメソッドを実行）した際のセッション有無で確認してください。

ログの出力

ライブラリが出力するログは，メッセージはアプリケーションサーバの保守用ログとして，例外のスタックトレースはアプリケーションサーバの例外ログとして出力されます。

3　JSFおよびJSTLの利用

この章では，JSFおよびJSTLの利用について説明します。

3.1　この章の構成

この章では，JSFおよびJSTLの利用について説明します。

JSF（Java Server Faces）は，JavaEEの標準仕様で提供しているWebアプリケーションフレームワークです。

JSTL（Java Server Pages Standard Tag Library）は，Webアプリケーションで頻繁に使用されるタグをまとめたタグライブラリです。

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

表3‒1　この章の構成（JSFおよびJSTLの利用）

分類

タイトル

参照先

解説

JSFおよびJSTLの概要

3.2

JSFおよびJSTLの機能

3.3

実装

DDでの定義

3.4

JSFアプリケーションの開発の流れ

3.5

設定

実行環境の設定

3.6

運用

障害対応用の情報の出力および確認

3.7

注意事項

JSFおよびJSTL使用時の注意事項

3.8

3.2　JSFおよびJSTLの概要

この節では，JSFとJSTLの概要について説明します。なお，JSFからは，Bean Validationの機能を利用できます。

3.2.1　JSFの概要

(1)　JSFとは

JSFは，JaveEEで標準仕様として策定されたWebアプリケーションのユーザインタフェースを開発するためのフレームワークです。Webアプリケーションの開発効率の向上を目的としています。JSFで開発したWebアプリケーションをJSFアプリケーションといいます。

JSFでは，MVCモデルに準じ，Model層（ビジネスロジック）とView層（入出力画面）の開発を明確に区別しています。これらの層を区別することによって，JSFアプリケーション開発に携わる担当者の作業を分担しやすくなります。各担当者は自分の作業にだけ専念できるため，開発効率の向上が図れます。

(2)　Bean Validationとの連携

アプリケーションサーバでは，JSFアプリケーションでの入力値の検証処理を簡略化するために，Bean Validationの機能を利用できます。

Bean Validationの利用に関しては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.　アプリケーションサーバでのBean Validationの利用」を参照してください。

3.2.2　JSTLの概要

JSTLは，Webアプリケーションで実行するデータベースアクセスやループ処理などの共通処理を表現するタグをまとめたライブラリです。JSTLのタグを使用することによって，これまでコーディングする必要があった処理を記述する時間を短縮することができ，開発効率の向上が図れます。

3.3　JSFおよびJSTLの機能

この節では，JSFおよびJSTLの機能について説明します。

JSFおよびJSTLを使ったWebアプリケーションでの処理の流れを次の図に示します。

図3‒1　JSFおよびJSTLを使ったWebアプリケーションでの処理の流れ

クライアントからJSFアプリケーションを使用したWebページにアクセスすると，リクエストがJSFフレームワーク内のサーブレットFacesServletに渡ります。FacesServletを起点としてJSFアプリケーションの処理が始まり，JSFフレームワークのJSFCoreからユーザが定義したクラスやページの処理が実行されます。リクエストを処理した結果はレスポンスとしてFacesServletを介してクライアントへ返されます。

クライアントからJSTLを使用したWebページにアクセスすると，JSTLライブラリがWebページで使用しているタグに対応した処理を実行します。処理した結果はレスポンスとしてクライアントへ返されます。

3.3.1　JSFの機能

ここでは，JSFの機能について説明します。

(1)　JSFの基本機能

JSFを利用したWebアプリケーションの開発では，アクセスページビューの定義，ページの再利用，クライアントからの入力値の型の変換やバリデーション，アプリケーション内でのイベントの制御など，いろいろな機能を利用できます。

JSFの機能の多くは，ManagedBeanとEL式を利用して実現します。

ManagedBeanとは，JSPおよびFaceletsページで使用するデータとメソッドを定義するJavaBeanのことです。ManagedBeanの詳細については，JSFの仕様を参照してください。

EL式とは，規定の形式で記述することで，ManagedBeanに定義したプロパティやメソッドをJSFタグの属性と関連づけることができる機能です。EL式はJSPの仕様の一部です。詳細は，JSPの仕様を参照してください。

(2)　アプリケーションサーバでのJSFの動作

アプリケーションサーバでのJSFの動作を次に示します。

ValueChangeListener，ActionListener，AjaxBehaviorListener，ComponentSystemEventListenerとして動作するメソッドをEL式で指定した場合に，同じメソッド名で引数あり，引数なしが存在すると，引数ありのメソッドだけが呼ばれます。

<f:facet>タグの中に複数のコンポーネントがある場合，JSPページでは，最初に記述されているコンポーネントが処理されますが，Faceletsページでは，記述されているすべてのコンポーネントが処理されます。

<f:subview>タグが<f:view>タグの外に記述された場合，JSPページでは，<f:view>の値が<f:subview>の値に上書きされます。Faceletsページでは，<f:view>の値は変わらず，<f:view>および<f:subview>が一緒に表示されます。

<f:ajax>タグを利用する場合，<h:head>タグを記述しなければいけません。記述しないと，<f:ajax>が動作しません。

イベントの処理にvalueChangeListener属性または<f:valueChangeListener>タグを利用する場合に，<h:inputText>タグのvalue属性にValueExpressionを，scope属性にRequestScopedを設定した場合，入力値を変更しなくても，valueChangeListenerのメソッドが実行されます。

ユーザアプリケーションが"csfcfc"というCookieを登録し，FaceletsにFlashオブジェクトを利用して繰り返しリクエストをした場合，Flashオブジェクトのデータの読み込みが失敗して，例外処理（NullPointerException）が発生します。

<ui:repeat>タグの繰り返し回数は，size属性に設定された値より1回多くなります。

ブラウザの仕様によって，一部のタグの属性が無効になるおそれがあります。ブラウザの仕様をご確認ください。

<composite:attribute>タグ，<composite:facet>タグ，<composite:insertFacet>タグ，<composite:renderFacet>タグのrequierd属性を有効にする場合は，コンテキストパラメタjavax.faces.PROJECT_STAGE の値をDevelopment に設定してください。

コンテキストパラメタjavax.faces.FACELETS_REFRESH_PERIODの指定値は，Faceletsページへの最新のリクエストを受けてからFaceletsファイルの更新を確認するまでの時間になります。そのため，短時間のうちに多くのリクエストが送られる環境では，最新のリクエストに合わせて更新の確認までの時間が延長されてしまい，Faceletsファイルの更新が反映されない状態が続くおそれがあります。

アプリケーションサーバでは，Bean Validationの機能は常に有効になります。Bean Validationの機能を無効にする方法は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.5.1　JSFからBean Validationの利用手順」を参照してください。

<f:attribute>タグで値を指定する対象として，文字列（java.lang.String型）を指定値とする属性を指定してください。

JSFアプリケーションのクライアント画面からのPOSTデータに含まれるリクエストのパラメタ数は，使用するJSFタグの種類や使用方法によって異なります。webserver.connector.limit.max_parameter_countキーでリクエストパラメタ数の上限値を設定する場合は，本番環境と同等の環境で実際のJSFアプリケーションを使用して検証することをお勧めします。

アプリケーションのJARファイル内のMETA-INF/resourcesのリソースを更新した場合，リロード時にKDJE39556-Wのメッセージが出力されます。この状態でJSFからリソースにアクセスした場合，更新したリソースが取得できます。

3.3.2　JSTLの機能

JSTLでは，ページにタグを定義することで，アプリケーションで共通に使用する処理を実行できます。

JSTLには，値の設定，条件分岐，データベースへのアクセス，国際化，XML解析などに関するタグが含まれています。

3.3.3　アプリケーションサーバ独自の機能

JSFまたはJSTLで利用できるアプリケーションサーバ独自の機能を次の表に示します。

表3‒2　アプリケーションサーバ独自の機能

項番

機能

説明

1

ログの出力

実行時の情報をログファイルに記録する機能です。

2

性能解析トレースの出力

特定の機能(メソッド)の開始と終了をファイルにトレースする機能です。

この情報を使って，システム性能およびボトルネックを分析できます。性能解析トレースの出力の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。

3.3.4　アプリケーションサーバのほかの機能との関連

ここでは，JSFおよびJSTLとアプリケーションサーバのほかの機能との関連について説明します。

JSFまたはJSTLとあわせて利用する場合に，留意する必要がある機能を次の表に示します。

表3‒3　JSFまたはJSTLと合わせて利用する場合に留意する必要がある機能

項番

機能

機能についての参照先

1

明示管理ヒープ機能

マニュアル「機能解説 拡張編」の「7.　明示管理ヒープ機能を使用したFullGCの抑止」

2

セッションフェイルオーバ機能

マニュアル「機能解説 拡張編」の「5.2　セッションフェイルオーバ機能の概要」

3

リデプロイ機能とリロード機能

マニュアル「機能解説 基本・開発編(コンテナ共通機能)」の「18.　J2EEアプリケーションの形式とデプロイ」

4

JSP事前コンパイル機能

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

5

J2EEリソースへの別名付与（ユーザ指定名前空間機能）

マニュアル「機能解説 基本・開発編(コンテナ共通機能)」の「2.　ネーミング管理」

注　マニュアル名の「アプリケーションサーバ」は省略しています。

以降，JSFおよびJSTLと各機能との関連について説明します。

(1)　明示管理ヒープ機能

JSFでは，ユーザが作成したFaceletsファイルやJSPファイルを基に生成された次の情報およびオブジェクトを，HTTPセッションに登録します。

HTMLページの画面の情報（ビューの状態）

SessionScopeを定義したManagedBeanクラスのオブジェクト

これらの情報およびオブジェクトは，ほかのWebアプリケーションと同様に，明示管理ヒープ機能を使用して管理できます。

ただし，情報およびオブジェクトがHTTPセッションに登録されるかどうかには条件があります。また，HTTPセッションに登録されるすべての情報が明示管理ヒープを使用して管理されるわけではありません。HTTPセッションに情報またはオブジェクトが登録される条件と，それらの情報またはオブジェクトが明示管理ヒープ機能を使用して管理されるかどうかを次の表に示します。

表3‒4　HTTPセッションに情報またはオブジェクトが登録される条件

情報またはオブジェクト

HTTPセッションに登録される条件

明示管理ヒープ機能を使用して管理されるかどうか

UIComponentのビュー情報（テキストフィールド，ラジオボタン，サブミットボタンなどのユーザとの入出力インターフェースを構成するビューの情報）

JSF標準コンテキストパラメタのjavax.faces.STATE_SAVING_METHODの値が「server」（デフォルト値）の場合

使用しない

ManagedBeanオブジェクト

SessionScopeアノテーションが指定された場合，またはfaces-config.xmlの<managed-bean-scope>に「session」を指定した場合

使用する

ページで使用する文字コード

HTTPセッションが生成されていた場合

使用する

SessionMapに登録したオブジェクト

ユーザアプリケーションで使用した場合

使用する

また，明示管理ヒープ機能を使用する場合，JSFアプリケーションが明示管理ヒープ領域で使用するメモリサイズの概算は，次の式を使用して算出してください。

JSFアプリケーションが明示管理ヒープ領域で使用するメモリサイズ

1セッション当たりで明示管理ヒープ領域を使用するサイズ
＝(A※＋1) × 0.4キロバイト
＋ManagedBeanオブジェクトサイズ（HTTPセッションに登録される場合）
＋SeesionMapに登録した場合のオブジェクトサイズ

注※　AはJSFの論理ページの最大値を設定するプロパティ（com.sun.faces.numberOfLogicalViews）に指定した値です。デフォルトは15です。

JSFアプリケーションで明示管理ヒープ機能を使用する場合の注意事項

JSFでは，HTTPセッションの破棄（javax.servlet.http.HttpServletRequestインタフェースのinvalidateメソッド呼び出し）を実行しません。このため，ユーザアプリケーション内でHTTPセッションの破棄（javax.servlet.http.HttpServletRequestインタフェースのinvalidateメソッド呼び出し）を実行するか，または適切なセッションタイムアウトを設定してください。

(2)　セッションフェイルオーバ機能

JSFがHTTPセッションに登録するオブジェクトを利用して，ほかのWebアプリケーションと同様にセッションフェイルオーバ機能を使用できます。JSF固有の設定も不要です。

JSFアプリケーションがHTTPセッションに登録するオブジェクトサイズ

セッションフェイルオーバ機能を使用する場合，JSFアプリケーションがHTTPセッションに登録するオブジェクトサイズの概算は，次の表に示す値を使用して見積もってください。

表3‒5　JSFアプリケーションがHTTPセッションに登録するオブジェクトサイズ

ページ

メモリを使用する処理

使用メモリ

Faceletsページ

必須なオブジェクトと各タグ部分

1.3キロバイト

一つのFormタグのページ生成部分

0.2キロバイト※1

EL式を使用した場合※2

0.8キロバイト※3

JSPページ

必須なオブジェクトと各タグ部分

2.2キロバイト

一つのFormタグのページ生成部分

2.0キロバイト※1

EL式を使用した場合※2

0.8キロバイト※3

注※1　ManagedBeanの作り方やタグのID設定などによって，多少の増減があります。

注※2　リソース数ごとに見積もってください。

注※3　リソースの作り方によって，多少の増減があります。

なお，この表で示した値は概算値です。実際にHTTPセッションで利用するメモリサイズについては，アプリケーションを実行して得られた情報を基に見積もってください。

JSFアプリケーションでセッションフェイルオーバ機能を使用する場合の注意事項

セッションフェイルオーバ機能では，HTTPセッションの属性引き継ぎ時のシリアライズ処理でシリアライズできない情報がある場合，シリアライズに失敗して，その情報は保持できません。これは，JSFアプリケーションでも同様です。次の場合，シリアライズ処理に失敗して，セッションフェイルオーバ機能は使用できません。

SessionScopeアノテーションが指定されているか，faces-config.xmlの<managed-bean-scope>に「session」を指定していて，ManagedBeanにシリアライズできない情報が含まれていた場合

SessionMapにシリアライズできない情報を登録した場合

(3)　リデプロイ機能とリロード機能

リデプロイ機能について，JSFアプリケーションとして留意する点はありません。ほかのWebアプリケーションと同様に機能を使用できます。

リロード機能についても，コマンドによるリロードを実行する場合は，JSFアプリケーションとして留意する点はありません。ほかのWebアプリケーションと同様に機能を使用できます。

ただし，更新検知によるリロードについては，更新検知の対象となるファイルに次の制限があります。

JSPファイルの更新検知

ほかのWebアプリケーションの更新検知と差異はありません。

Faceletsファイルの更新検知

更新検知の対象外です。

次に，Faceletsに含まれるファイルが更新された場合に，どの範囲でリロード機能が実行されるかを示します。

表3‒6　Faceletsに含まれるファイルが更新された場合のリロード機能の適用範囲

更新検知の対象ファイル

リロード機能の適用範囲

app

web

jsp

Faceletsファイル

×

×

×

タグファイル

○

○

○

ManagedBeanコンパイル結果

○

○

○

静的コンテンツ

×

×

×

（凡例）○：適用される　×：適用されない

クラスローダによってロードされるファイルであるサーブレットやJSPファイルは，監視対象のファイルなので，更新されたときにJ2EEサーバが更新を検知してリロードが実行されます。しかし，Faceletsファイルはクラスローダによってロードされるファイルではありません。このため，Faceletsファイルを更新しても，J2EEサーバで更新が検知されないため，リロードも実行されません。

Faceletsファイルの更新を自動的に検知して反映したい場合は，標準コンテキストパラメタにjavax.faces.FACELETS_REFRESH_PERIODを指定してください。このパラメタに定義した時間間隔でFaceletsファイルの更新状態が監視され，更新が検知されると，その内容が反映されます。ただし，この機能は展開ディレクトリ形式のアプリケーションの場合だけ有効です。

なお，Faceletsファイルのページ出力を実行したあとでFaceletsファイルを更新した場合は，次にページにアクセスした時にJSFによってFaceletsファイルの更新が検知され，KDJE59227-Iメッセージが出力されます。

(4)　JSP事前コンパイル機能

JSFアプリケーション内のJSPファイルは，JSP事前コンパイル機能を使用してコンパイルできます。

(5)　J2EEリソースへの別名付与（ユーザ指定名前空間機能）

JSTLでは，J2EEリソースの別名は使用できません。

JSTLの<sql:setDataSource>タグのdatasource属性には，java:comp/envからの相対パスを指定してください。

3.4　DDでの定義

JSFアプリケーションを利用するためには，DD（web.xml）にコンテキストパラメタの設定が必要です。

この節では，DDでのJSFのコンテキストパラメタの設定について説明します。

3.4.1　アプリケーションサーバ独自のコンテキストパラメタ

アプリケーションサーバ独自のコンテキストパラメタを次の表に示します。

表3‒7　アプリケーションサーバ独自のコンテキストパラメタ

パラメタ名

データ型

指定可能値

不正な値の対処

省略値

説明

com.sun.faces.clientStateTimeout

Long

-9223372036854775808

〜9223372036854775807

タイムアウトは動作しない

タイムアウトは動作しない

ビューの状態に対するタイムアウト値を指定します。

ビューを表示してから次のビューを表示するまでの時間がタイムアウト値を超えるとビューは表示されません。

タイムアウト値を超えると，javax.faces.application.ViewExpiredExceptionがスローされます。

このパラメタはjavax.faces.STATE_SAVING_METHODの値が"client"の場合に有効になります。

このパラメタを設定しない場合，タイムアウトは発生しません。

このパラメタの値に1を加えた値がタイムアウト値として有効になります。

例えば，0が設定された場合は，1分でタイムアウトが発生します。

負の値を設定すると，サブミット後のビューは必ず表示されなくなります。

com.sun.faces.disableUnicodeEscaping※1

String

auto，trueまたはfalse

false

auto

クライアントへ返すレスポンスページの非ASCII文字の出力方法を決定します。

JSFの非ASCII文字の出力方法には，そのまま文字で出力するか，または文字参照で出力するかの2とおりがあります。

この機能はレスポンスページのエンコーディングの設定に影響を受けます。

また，この機能の影響する範囲はJSPとFaceletsで異なります。

JSPではJSFタグ（HTMLタグまたはコアタグ）に指定した文字が対象となります。

Faceletsではページに記載したすべての文字が対象となります。

com.sun.faces.numberOfLogicalViews

int

0〜

2147483647

15

15

論理ビュー※2の数を指定します。

このパラメタはjavax.faces.STATE_SAVING_METHODの値が"server"の場合に有効になります。

このパラメタに設定した値を超えるビューにアクセスすると，参照されていない時間が最も長い論理ビューが，現在アクセスした論理ビューに置換されます。

置換されたビューをサブミットしても結果のページは表示されません。

このパラメタに0を指定すると，サブミット後のビューは必ず表示されなくなります。

負の値を指定した場合は，JSPとFaceletsで挙動が異なります。

JSPの場合は，例外が発生しますが，ビューは表示され，サブミットもできます。ただし，ビューの状態は保存されません。

Faceletsの場合は，例外が発生します。ビューは表示されません。

com.sun.faces.numberOfViewsInSession

int

0〜2147483647

15

15

論理ビュー※2に登録できるビューの状態の数を指定します。

このパラメタはjavax.faces.STATE_SAVING_METHODの値が"server"の場合に有効になります。

同じビューをサブミットした回数がこのパラメタに設定した値を超えると，参照されていない時間が最も長いビューの状態が，現在アクセスしたビューの状態に置換されます。

置換された状態を持っていたビューをサブミットしても結果のページは表示されません。

このパラメタに0を指定すると，サブミット後のビューは必ず表示されなくなります。

負の値を指定した場合は，JSPとFaceletsで挙動が異なります。

JSPの場合は，例外が発生しますが，ビューは表示され，サブミットもできます。ただし，ビューの状態は保存されません。

Faceletsの場合は，例外が発生します。ビューは表示されません。

注※1

com.sum.faces.disableUnicode.Escapingの設定値およびレスポンスページの出力との対応を次の表に示します。

表3‒8　com.sum.faces.disableUnicode.Escapingの設定値とレスポンスページの出力との対応

com.sun.faces.disableUnicodeEscapingの設定値

レスポンスページのエンコーディングがUTF型，ISO-8859-1の場合

レスポンスページのエンコーディングがUTF型，ISO-8859-1以外の場合

true

文字

文字

false

文字参照

文字参照

auto

文字

文字参照

注※2

論理ビューとは，JSFが保存しているレスポンスページのことです。クライアントが今までにアクセスしたビューを識別するために使用します。クライアントがビューにアクセスした際に論理ビューは作成されます。また，論理ビューはビューの状態を保持します。ビューの状態は，同じビューをサブミットするごとに一つずつ増加していきます。

numberOfLogicalViewsおよびnumberOfViewsInSessionの指定値とビューの関係を次の図に示します。

図3‒2　numberOfLogicalViewsおよびnumberOfViewsInSessionの指定値とビューの関係

numberOfLogicalViewsに指定した数の論理ビューごとに，numberOfViewsInSessionに指定した数の状態が保持されます。

クライアントからサーバに値をサブミットすると，新しい状態のビューがサーバに保存されます。なお，状態とは，論理ビューで記述したUIコンポーネントの情報のことです。

JSFでは，ユーザが作成したFaceletsファイルやJSPファイルを基にして生成したHTMLページの画面の情報（ビューの状態）とSessionScopeを定義したManagedBeanクラスのオブジェクトをHTTPセッションに登録します。

3.4.2　Servletの設定

Servletの設定は，web.xmlに定義します。web.xmlの定義は，Servletのバージョンごとに異なります。

JSF 2.3を使用するには，web.xmlのバージョンが2.5以降であるか，またはweb.xmlを省略している必要があります。

(1)　Servlet2.5の場合

JSFアプリケーションが動作するためには，web.xmlに次のタグの定義が必要です。

<servlet>

<servlet>タグを使用して，FacesServletクラスをサーブレットとして登録してください。

web.xmlには，次の例のように設定してください。

<servlet>
<servlet-name>FacesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>

<servlet-mapping>

servlet-mappingの要素をweb.xmに定義する必要があります。

web.xmlには，次の例のように設定してください。

<servlet-mapping>
<servlet-name>FacesServlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>

(2)　Servlet3.0の場合

Servlet3.0の場合は，FacesServletクラスの登録やURLマッピングの定義はデフォルトで設定されます。このため，web.xmlの設定は必要ありません。web.xmlの作成は任意です。

次に，web.xmlでのFacesServletクラスの登録およびURLマッピングの定義の有無と，動作の関係を示します。

条件1：

条件

次のどちらかを満たす場合

web.xmlは作成しているが，FacesServletクラスの登録とURLマッピングの定義はしていない

web.xmlを作成していない

動作

FacesServletは自動的に初期化され，次のデフォルトURLにマッピングされます。マッピングされるURLはコンテキストパラメタjavax.faces.DISABLE_FACESSERVLET_TO_XHTMLに設定する値によって異なります。

コンテキストパラメタjavax.faces.DISABLE_FACESSERVLET_TO_XHTMLに設定する値

マッピングされるURL

false（デフォルト値）

/faces/*

*.jsf

*.faces

*.xhtml

true

/faces/*

*.jsf

*.faces

ユーザは，デフォルトURLを利用してFacesServletにアクセスします。

条件2：

条件

web.xmlを作成し，FacesServletクラスの登録，およびURLのマッピングの定義をweb.xmlで設定している場合

動作

ユーザは，web.xmlに設定した内容に従ってFacesServletにアクセスします。この場合，例1で示したデフォルトの設定は使用されません。

3.5　JSFアプリケーションの開発の流れ

この節では，JSFアプリケーションの開発の流れについて説明します。

JSFアプリケーションの開発では，次の図に示す作業を実施します。図中の番号に沿って，開発を進めてください。図中の1.では，2.〜6.を作成するために必要な共通の識別子を決定します。

図3‒3　JSFアプリケーションの開発の流れ

この手順は，JSFアプリケーションの作成までの開発手順です。実際にJSFアプリケーションを動作させるためには，上記で作成したファイルを基にEARファイルを作成し，アプリケーションサーバにJSFアプリケーションをデプロイする必要があります。

3.6　実行環境の設定

V9互換モードの場合，JSFおよびJSTLを使用したアプリケーションの実行環境の設定は，開発環境の設定と同じです。ライブラリをJ2EEサーバのクラスパスに設定する必要があります。

3.7　障害対応用の情報の出力および確認

JSFおよびJSTLを使用したアプリケーションで障害が発生した場合は，J2EEサーバの稼働ログに出力されるKDJE60401-E〜KDJE60402-Eのメッセージ本文，および例外ログに出力されるスタックトレースを参照して対処してください。詳細は，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「4.　トラブルシューティングで必要な資料の出力先と出力方法」および「5.　トラブルの分析」を参照してください。

3.8　JSFおよびJSTL使用時の注意事項

この節では，JSFおよびJSTL使用時の注意事項について説明します。

コンテキストパラメタに指定した値は，次の規則に従って扱われます。

boolean型のプロパティでは，小文字，大文字が区別されます。

すべてのコンテキストパラメタには，省略値があります。不正な値や指定できる範囲外の値を設定した場合は，省略値が利用され，誤ったコンテキストパラメタがメッセージに出力されます。

V9互換モードでJSFおよびJSTLのクラスパスを設定する場合，ライブラリのバージョンで注意しなければならない事項を次に示します。

動作させたいバージョンのライブラリと異なるバージョンのライブラリを同時にクラスパスに指定しないでください。アプリケーションが予期しない動作をするおそれがあります。

アプリケーションのバージョンに合わせたライブラリをクラスパスに指定してください。

アプリケーション作成時の注意事項を次に示します。

Component Container 09-50-02以降のJSFを使用する場合は，リクエストされる可能性があるすべてのxhtmlファイルにXML宣言，DOCTYPE宣言を記述してください。レスポンスには，リクエストされたxhtmlファイルのXML宣言，DOCTYPE宣言が出力されます。リクエストされたxhtmlファイルにXML宣言，DOCTYPE宣言が書かれていない場合は，レスポンスにどのXML宣言，DOCTYPE宣言が出力されるか保証されません。

アプリケーション実行時の注意事項を次に示します。

アプリケーションのJARファイル内のMETA-INF/resourcesのリソースを更新した場合，リロード時にKDJE39556-Wのメッセージが出力されます。しかし，この状態でJSFからリソースにアクセスした場合，更新後のリソースが取得できます。

JSFアプリケーションのページでは，scriptまたはstyleブロック内ではエスケープ処理が行われません。

JSF 2.2仕様で追加されたjavax.faces.flowパッケージ，およびそのサブパッケージ以下の全APIは使用できません。

推奨モードでは「<Application Serverのインストールディレクトリ>/CC/lib」ディレクトリ内にある「cjsf.jar」や「cjstl.jar」をクラスパスに追加しないでください。

<ui:repeat>のvalue属性または<h:dataTable>のvalue属性に，javax.faces.model.FacesDataModelアノテーションのforClass属性で定義されているクラス，またはその派生クラスを指定した場合，対応するjavax.faces.model.DataModelの派生クラスへのマッピングの解決は行わず，JSF2.2と同様に，常にjavax.faces.model.ScalarDataModelでラップします。

<ui:repeat>のvalue属性に，java.sql.ResultSetクラス，またはその派生クラスを指定した場合，該当のタグを含むページのレスポンス出力時に例外が発生することがあります。

4　JAX-RS 2.1の利用

この章では，JAX-RS 2.1の利用について説明します。

4.1　この章の構成

この章では，JAX-RS 2.1について説明します。

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

表4‒1　この章の構成（JAX-RS 2.1の利用）

分類

タイトル

参照先

解説

JAX-RS 2.1の概要

4.2

前提環境

4.3

実装

DDでの定義

4.4

クライアントAPIの通信タイムアウトの設定

4.5

設定

クラスパスの設定

4.6

J2EEサーバ単位の通信タイムアウトの設定

4.7

注意事項

JAX-RS 2.0利用時の注意事項

4.8

4.2　JAX-RS 2.1の概要

アプリケーションサーバおよびcjclstartapコマンドで起動したJavaアプリケーションでは，JSR 370 JavaTM API for RESTful Web Services （JAX-RS 2.1）をサポートします。

4.3　前提環境

JAX-RS 2.1の前提環境を次に示します。

4.3.1　J2EEサーバ上で使用する場合

アプリケーションサーバでは，JAX-RS 2.1の実装はデフォルトで無効になっています。有効化するには，「4.6　クラスパスの設定」に従ってクラスパスの追加が必要です。

「<Application Serverのインストールディレクトリ>/jaxrs/lib」ディレクトリ内にある「cjjaxrs.jar」をクラスパスに追加しないでください。11-00以降では，J2EEサーバのクラスパスに「cjjaxrs.jar」を追加した場合の動作は保証しません。

4.3.2　Javaアプリケーション（cjclstartapコマンド）上で使用する場合

Javaアプリケーションの開始コマンド（cjclstartapコマンド）では，JAX-RS 2.1の実装はデフォルトで無効になっています。有効化するには，「4.6　クラスパスの設定」に従ってクラスパスの追加が必要です。

「<Application Serverのインストールディレクトリ>/jaxrs/lib」ディレクトリ内にある「cjjaxrs.jar」をクラスパスに追加しないでください。11-00以降では，cjclstartapコマンドのクラスパスに「cjjaxrs.jar」を追加した場合の動作は保証しません。

4.3.3　デフォルトのJSON Providerについて

アプリケーションサーバおよびJavaアプリケーションの開始コマンド（cjclstartapコマンド）では，デフォルトのJSON Providerとして，JSON-BおよびJackson 2.17.1を提供します。ただし，デフォルトでは無効になっています。有効化するには，「4.6　クラスパスの設定」に従ってクラスパスの追加が必要です。

4.4　DDでの定義

JAX-RS 2.1を使用するには，DD（web.xml）のバージョンが2.5以降であるか，またはDDを省略している必要があります。

DDを省略していてバージョン3.0以降と認識されている場合や，バージョン3.0以降のDDを含んだWebアプリケーションの場合は，JAX-RS用のサーブレットマッピングはJAX-RS 2.1仕様に従って自動的に行われます。

DD（web.xml）のバージョン2.5を使用する場合や，web.xmlに独自のサーブレットマッピングを定義する場合は，JAX-RSのサーブレットクラス名またはフィルタクラス名として次に示すクラス名を指定してください。

org.glassfish.jersey.servlet.ServletContainer

DDに独自のサーブレットマッピングを定義する例を次に示します。

<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/webapp_2_5.xsd">
<servlet>
<servlet-name>MyJaxrsServlet</servlet-name>
<servlet-class>
org.glassfish.jersey.servlet.ServletContainer
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyJaxrsServlet</servlet-name>
<url-pattern>/myapp/rest/*</url-pattern>
</servlet-mapping>
</web-app>

4.5　クライアントAPIの通信タイムアウトの設定

JAX-RS 2.1のクライアントAPI（javax.ws.rs.client.Clientインタフェース）を用いてREST通信を行う際の各種タイムアウト値を指定できます。

タイムアウト時間の指定方法は，ClientBuilder／Client／WebTargetオブジェクト単位にAPIで指定する方法と，APIで指定されなかった場合のデフォルト値をJ2EEサーバ単位にユーザプロパティで指定する方法の2種類があります。

ClientBuilder／Client／WebTargetオブジェクトに渡すClient configuration propertyとしてサポートするプロパティを次の表に示します。

表4‒2　サポートするClient configuration property

プロパティのキー名

データ型

指定内容

デフォルト値

J2EEサーバ

cjclstartap

jersey.config.client.connectTimeout

Integer

JAX-RSのクライアントAPIでの，クライアントソケットの接続タイムアウト値を指定します（単位：ミリ秒）。

0を指定した場合，タイムアウトされません。

ユーザプロパティ「ejbserver.javaee.jaxrs.config.client.connectTimeout」の指定値

0

jersey.config.client.readTimeout

Integer

JAX-RSのクライアントAPIでの，クライアントソケットの読み込みタイムアウト値を指定します（単位：ミリ秒）。

0を指定した場合，タイムアウトされません。

ユーザプロパティ「ejbserver.javaee.jaxrs.config.client.readTimeout」の指定値

0

Client configuration propertyの使用例を次に示します。

Client client = ClientBuilder.newClient();
String result = client.target("http://example.com/example/rest")
    .property("jersey.config.client.connectTimeout", 3000) // 接続タイムアウト3秒
    .property("jersey.config.client.readTimeout", 10000) // 読み込みタイムアウト10秒
    .request(MediaType.TEXT_PLAIN)
    .get(String.class);

各種タイムアウトが発生した場合の動作を次の表に示します。

表4‒3　タイムアウトが発生した場合の動作

タイムアウト種別

対象メソッド

タイムアウト発生時の動作

接続タイムアウト

javax.ws.rs.client.SyncInvokerインタフェースの全メソッド

メッセージログにKDJE60311-Eが，例外ログにスタックトレースが出力され，java.net.SocketTimeoutExceptionを原因とするjavax.ws.rs.ProcessingExceptionがスローされます。

読み込みタイムアウト

javax.ws.rs.client.SyncInvokerインタフェースの全メソッド

メッセージログにKDJE60311-Eが，例外ログにスタックトレースが出力され，java.net.SocketTimeoutExceptionを原因とするjavax.ws.rs.ProcessingExceptionがスローされます。

OSによるタイムアウト

javax.ws.rs.client.SyncInvokerインタフェースの全メソッド

メッセージログにKDJE60312-Eが，例外ログにスタックトレースが出力され，java.io.IOExceptionまたはそのサブクラスを原因とするjavax.ws.rs.ProcessingExceptionがスローされます。

4.6　クラスパスの設定

アプリケーションサーバでは，JAX-RS 2.1はデフォルトでクラスパスに入っていません。JAX-RS 2.1を使用する場合は，J2EEサーバのusrconf.cfg（Javaアプリケーション用オプション定義ファイル）またはcjclstartapコマンドのusrconf.cfg（Javaアプリケーション用オプション定義ファイル）のadd.class.pathキーを使用して，次のJARファイルをクラスパスに追加する必要があります。

add.class.path=<cosminexus.home>/CC/javaee/1100/lib/jaxrs-impl.jar

また，JAX-RSのJSON ProviderとしてJSON-Bまたはアプリケーションサーバが提供するJacksonを使用する場合も，add.class.pathキーを使用して次のどちらかのJARファイルをクラスパスに追加する必要があります。両方のJARファイルを追加した場合は，JSON-Bが優先されます。

JSON-Bを使用する場合

add.class.path=<cosminexus.home>/CC/javaee/1100/lib/jaxrs-json-binding.jar

Jacksonを使用する場合

add.class.path=<cosminexus.home>/CC/javaee/1100/lib/jaxrs-jackson.jar

このJARファイルをクラスパスに追加しない場合は，ユーザ側で用意した任意のJSON Providerが使用可能となります。その場合，JAX-RSからJSON Providerを呼び出す処理は，JAX-RS仕様に従ってユーザアプリケーション側で実装する必要があります。

4.7　J2EEサーバ単位の通信タイムアウトの設定

J2EEサーバ単位でClient configuration propertyのデフォルト値を指定するため，次の表に示すプロパティをサポートします。Client configuration propertyが未指定だった場合のデフォルト値をJ2EEサーバ単位に設定できます。

表4‒4　J2EEサーバ単位の通信タイムアウトの設定プロパティ

プロパティ名

指定内容

デフォルト値

ejbserver.javaee.jaxrs.config.client.connectTimeout

JAX-RSのクライアントAPIでのClient configuration property「jersey.config.client.connectTimeout」のデフォルト値を，0〜2147483647の整数値で指定します（単位：ミリ秒）。

0を指定した場合，タイムアウトされません。

0

ejbserver.javaee.jaxrs.config.client.readTimeout

JAX-RSのクライアントAPIでのClient configuration property「jersey.config.client.readTimeout」のデフォルト値を，0〜2147483647の整数値で指定します（単位：ミリ秒）。

0を指定した場合，タイムアウトされません。

0

4.8　JAX-RS 2.1利用時の注意事項

JAX-RS 2.1利用時の注意事項を次に示します。

4.8.1　Cosminexus JAX-RSでサポートしていたCosminexus独自機能について

Cosminexus Version 11以降のJ2EEサーバでは，Version 9以前のCosminexus JAX-RSエンジンでサポートしていたCosminexus独自機能は使用できません。

ただし，JAX-RS 2.1仕様で規定されている機能は使用できます。

5　WebSocket

この章では，WebSocketについて説明します。

5.1　WebSocketの概要

JSR 356 Java API for WebSocket 1.1をサポートします。ServerEndpointはWebコンテナのリクエスト処理スレッド上で呼び出されます。スレッド数などのチューニング方法については，「7.　NIO HTTPサーバ」を参照してください。

5.2　WebSocketを利用する場合の注意事項

Spring WebSocketのAPI「org.springframework.web.socket.server.standard.ServerEndpointRegistration」を使用したプログラム型エンドポイント（programmatic endpoint）の登録はできません。登録しようとした場合，java.lang.IllegalStateExceptionが発生してアプリケーションの開始に失敗します。

6　EL

この章では，ELについて説明します。

6.1　ELの概要

JSR 341 Expression Language Specification (EL) 3.0をサポートします。

6.2　EL 3.0使用時の注意事項

EL 3.0を使用するときの注意事項について説明します。

6.2.1　ラムダ式実行時の注意事項

EL式でラムダ式を実行するには，次の例のようにラムダ式の実引数を指定してください。仮引数がないラムダ式の場合でも，実引数に空の括弧を指定してください。

${(x->x+1)(3)}
${v=(x,y)->x+y; v(2,1)}
${(()->64)()}

6.2.2　StreamのanyMatch/allMatch/noneMatchメソッドの注意事項

EL式のコレクション操作で使用できるStreamのanyMatch/allMatch/noneMatchメソッドは，日立独自仕様として戻り値にOptional型ではなくboolean型を返します。

7　NIO HTTPサーバ

この章では，NIO HTTPサーバ機能の設定について説明します。

7.1　この章の構成

アプリケーションサーバでは，J2EEサーバのインプロセスで動作するWebサーバ機能としてNIO HTTPサーバを提供しています。

NIO HTTPサーバの機能と参照先を次の表に示します。

表7‒1　NIO HTTPサーバの機能と参照先

機能

参照先

NIO HTTPサーバの概要

7.2

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

7.3

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

7.4

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

7.5

通信タイムアウト

7.6

IPアドレス指定

7.7

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

7.8

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

7.9

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

7.10

ログ・トレースの出力

7.11

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

7.2　NIO HTTPサーバの概要

この節では，NIO HTTPサーバの概要について説明します。

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

表7‒2　この節の構成（NIO HTTPサーバの概要）

分類

タイトル

参照先

解説

NIO HTTPサーバの使用

7.2.1

NIO HTTPサーバで使用できる機能

7.2.2

設定

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

7.2.3

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

7.2.1　NIO HTTPサーバの使用

NIO HTTPサーバは，J2EEサーバのプロセス上で動作するHTTPサーバ機能です。HTTP 1.0/1.1，HTTP/2，およびWebSocketプロトコルをサポートします。※

注※

WebSocket over HTTP/2はサポートしません。

非同期サーブレットやWebSocket通信を実現するため，NIO HTTPサーバではクライアントとのコネクションとリクエスト処理スレッドとは1対1で対応していません。そのため，最大同時接続数は最大同時実行スレッド数よりも多く確保できます。

NIO HTTPサーバの処理の流れを次の図に示します。

図7‒1　NIO HTTPサーバの処理の流れ

7.2.2　NIO HTTPサーバで使用できる機能

NIO HTTPサーバで使用できる機能と参照先を次の表に示します。

表7‒3　NIO HTTPサーバで使用できる機能と参照先

機能名

参照先

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

7.3

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

7.4

Webクライアントとの通信制御

Persistent Connectionによる通信制御

7.5

通信タイムアウト

7.6

IPアドレス指定※

7.7

Webクライアントからのアクセス制御

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

7.8

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

7.9

Webクライアントへのレスポンスのカスタマイズ

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

7.10

ログ・トレースの出力

7.11

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

ここでは，NIO HTTPサーバの設定手順について説明します。

設定手順を次に示します。

Webクライアントからの接続数の制御とリクエスト処理スレッド数の制御を設定します。

サーバを稼働するホストの性能やクライアントからのアクセス状況に合わせてリクエスト処理スレッド数を調節することで，NIO HTTPサーバのパフォーマンスを向上できます。設定については，「7.3　Webクライアントからの接続数の制御」および「7.4　リクエスト処理スレッド数の制御」を参照してください。

設定時の留意点を次に示します。

サーバ起動直後から大量のリクエストを処理する必要がある場合は，サーバ起動時に作成するリクエスト処理スレッド数に大きな値を指定してください。

予備スレッドの最大数を大きくすると急なアクセス増加にも迅速に対応できますが，リソースを多く消費するため注意してください。

Persistent ConnectionによるWebクライアントとの通信制御の設定をします。

WebクライアントとNIO HTTPサーバ間で確立したTCPコネクションを持続することで，コネクション接続に掛かる時間を短縮し，処理時間の短縮と通信トラフィックの軽減を図れます。デフォルトではリバースプロキシとのコネクションを常時接続状態にするのに適した設定となっています。NIO HTTPサーバに直接リクエストを行うシステムの場合は，有限のタイムアウトや上限回数を設定する必要があります。設定については，「7.5　Persistent ConnectionによるWebクライアントとの通信制御」を参照してください。

Webクライアントからのアクセス制御の設定をします。

クライアントからの接続や送信されるリクエストに対するセキュリティを強化することで，外部からの不正アクセスやサーバへの攻撃を防ぐことができます。設定については，「7.8　アクセスを許可するホストの制限によるアクセス制御」，「7.9　リクエストデータのサイズの制限によるアクセス制御」を参照してください。

必要に応じて，NIO HTTPサーバで使用できる各機能についても設定してください。

NIO HTTPサーバで使用できる機能については，「7.2.2　NIO HTTPサーバで使用できる機能」を参照してください。

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

Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。リクエスト処理スレッド数の制御については，「7.4　リクエスト処理スレッド数の制御」を参照してください。

この節では，Webクライアントからの接続数の制御について説明します。

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

表7‒4　この節の構成（Webクライアントからの接続数の制御）

分類

タイトル

参照先

解説

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

7.3.1

設定

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

7.3.2

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

NIO HTTPサーバでは，一度に接続できるWebクライアントの数を設定することで，NIO HTTPサーバで作成するリクエスト処理スレッド数を制御できます。また，処理を実行していないリクエスト処理スレッドを予備スレッドとして一定数プールしておくことで，リクエスト処理スレッドの追加・削除に掛かる処理を最小限に抑えられます。

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

NIO HTTPサーバでは，一度に接続するWebクライアントやリバースプロキシの数の最大値を制御します。

なお，クライアントからの接続要求は，TCP/IPのListenキューに登録されて，Acceptorスレッドに渡されます。接続数の上限を超えたクライアントからの接続要求は，Listenキューに蓄えられます。Listenキューに蓄えられたクライアントからの接続要求が指定した最大値を超えた場合，クライアントはサーバへの接続に失敗します。

リバースプロキシを配置し，NIO HTTPサーバと常設コネクションで接続する場合，Listenキューに蓄えられた接続要求はエラーとなるため，接続数をリバースプロキシからの接続数以上に設定してください。

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

Webクライアントからの接続数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのWebクライアントからの接続数の制御の定義について次の表に示します。

表7‒5　簡易構築定義ファイルでのWebクライアントからの接続数の制御の定義

指定するパラメタ

設定内容

webserver.connector.nio_http.max_connections

Webクライアントやリバースプロキシとの接続数の最大値を指定します。

リバースプロキシと常設コネクションで接続する場合は，リバースプロキシからの接続数以上に設定してください。

webserver.connector.nio_http.backlog

Webクライアントからの接続数の上限を超えたHTTPリクエストは，Listenキューに蓄えられます。ここでは，Listenキューの登録数の最大値を指定します。

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

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

Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。Webクライアントからの接続数の制御については，「7.3　Webクライアントからの接続数の制御」を参照してください。

この節では，リクエスト処理スレッド数の制御について説明します。この節の構成を次の表に示します。

表7‒6　この節の構成（リクエスト処理スレッド数の制御）

分類

タイトル

参照先

解説

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

7.4.1

設定

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

7.4.2

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

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

NIO HTTPサーバにはスレッドプールがあり，一度作成したスレッドを再利用することで効率よく処理できます。スレッドプール内のスレッド数は，最小値と最大値を調整できます。最小値と最大値を同じ値にした場合は，固定スレッド数のスレッドプールとなります。

NIO HTTPサーバでは，Webコンテナ管理の処理スレッド数はスレッドプールの最小サイズ，最大サイズとスレッドプールの持つキューとの相互作用によって，次のとおり推移します。

実行中のスレッド数がスレッドプールの現在のサイズ以下の値で，アイドルスレッド（処理を実行していないで待機状態の空きスレッド）がある場合，処理要求はキューに投入され，アイドルスレッドが処理要求を受け付けて実行します。

アイドルスレッドがない場合，新しいスレッドを生成して処理を実行します。生成されたスレッドの個数分，スレッドプールの現在のサイズが大きくなります。スレッドプールの現在のサイズは最大サイズを超えることはありません。

実行中のスレッド数がプールの最大サイズの値に達した場合，処理要求はキューに投入され，アイドルスレッドができるまで待ち，アイドル状態になったスレッドが処理要求を受け付けて実行します。

スレッドプールの現在のサイズが最小サイズより大きい場合，アイドル状態になってから一定時間（webserver.connector.nio_http.idle_thread_timeoutで指定した時間：デフォルト60秒）を超えたアイドルスレッドは削除されます。スレッドプールの現在のサイズが最小サイズより小さくなることはありません。

スレッドプールの持つキューのサイズに制限はありません（Integer.MAX_VALUE）。

NIO HTTPサーバでのスレッド数の遷移例を次の図に示します。この例では，プロパティを次のように設定しています。

webserver.connector.nio_http.min_threads：5

webserver.connector.nio_http.max_threads：10

webserver.connector.nio_http.max_connections：1024

webserver.connector.nio_http.idle_thread_timeout：60 (秒)

図7‒2　NIO HTTPサーバでのスレッド数の遷移例

図中の項番1〜6について説明します。

J2EEサーバ起動直後は，スレッド数最小値に指定した数のスレッドが生成され，アイドルスレッドとして待機します。

同時に3多重のリクエストが投入された場合，アイドルスレッドの中の三つが実行中スレッドとなります。

スレッド数最小値を超えるリクエストが同時に投入された場合は，必要数分のスレッドを新たに作成します。

実行中スレッド数が再びスレッド数最小値を下回った場合でも，未使用となったスレッドはidle_timeout_timeoutに指定した秒数（デフォルト60秒）は待機します。

idle_timeout_timeoutに指定した時間経過しても実行中にならなかったアイドルスレッドは破棄されます。ただし，スレッド数最小値分のスレッドは破棄されません。

クライアント接続数上限は下回るが，スレッド数最大値を超えるリクエストが同時に投入された場合は，最大値を超えた分のリクエスト処理要求は実行待ちキューで待たされます。先に処理を終えてスレッドに空きが出ると，キューから取り出されて処理されます。

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

リクエスト処理スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエスト処理スレッド数の制御の定義について次の表に示します。

表7‒7　簡易構築定義ファイルでのリクエスト処理スレッド数の制御の定義

指定するパラメタ

設定内容

webserver.connector.nio_http.min_threads

J2EEサーバ起動時に作成するNIO HTTPサーバの処理スレッド数の最小値を指定します。

webserver.connector.nio_http.max_threads

NIO HTTPサーバの処理スレッド数の最大値を指定します。

webserver.connector.nio_http.idle_thread_timeout

NIO HTTPサーバのスレッドプール内のスレッドがアイドル状態のままでいられる最長時間を秒単位で指定します。

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

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

この節では，Persistent ConnectionによるWebクライアントとの通信制御について説明します。

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

表7‒8　この節の構成（Persistent ConnectionによるWebクライアントとの通信制御）

分類

タイトル

参照先

解説

Persistent Connectionによる通信制御

7.5.1

設定

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

7.5.2

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

7.5.1　Persistent Connectionによる通信制御

Persistent Connectionは，WebクライアントやリバースプロキシとNIO HTTPサーバ間で確立したTCPコネクションを持続して，複数のHTTPリクエスト間で使用し続けるための機能です。Persistent Connectionを使用することによって，コネクション接続に掛かる時間を短縮し，処理時間の短縮と通信トラフィックの軽減を図れます。

NIO HTTPサーバでは，次に示す項目を設定することで，Persistent Connectionによる通信制御を実現します。

Persistent Connectionのリクエスト処理回数の上限値

Persistent Connectionのリクエスト処理回数の最大値を設定することで，同じWebクライアントから連続してリクエスト要求があった場合の処理を制御します。

Persistent Connectionのリクエスト処理回数が指定した上限値を超えた場合，リクエスト処理終了後にコネクションを切断します。これによってリクエスト処理スレッドを特定のクライアントに占有し続けられることを防げます。

Persistent Connectionのタイムアウト

Persistent Connectionのリクエスト待ち時間にタイムアウトを設定することで，Persistent Connectionのリクエスト待ち時間を制御します。指定したタイムアウト時間を超えてリクエスト処理要求がない場合は，TCPコネクションを切断します。これによって，使用されていない状態でTCPコネクションが占有され続けることを防げます。また，Persistent Connectionのリクエスト待ち時間に0を指定してタイムアウトをしない設定にしている場合でも，リクエスト処理回数の上限値を超えたリクエスト要求があるとコネクションが切断されます。

WebサーバとWebコンテナ間のTCPコネクションは，次の設定で常設コネクションとすることを推奨します。

webserver.connector.nio_http.keep_alive.max_requestsプロパティ（TCPコネクションを持続したままの連続接続回数の上限）を0（上限なし）に設定してください。デフォルト値は0です。

webserver.connector.nio_http.keep_alive.timeoutプロパティ（TCPコネクションを持続した状態での，リクエスト待ち時間）を0（タイムアウトなし）に設定してください。デフォルト値は0です。

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

Persistent Connectionによる通信制御を使用する場合，J2EEサーバの設定が必要です。

ここでは，Persistent Connectionによる通信制御の設定および設定例について説明します。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Persistent Connectionによる通信制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのPersistent Connectionによる通信制御の定義について次の表に示します。

表7‒9　簡易構築定義ファイルでのPersistent Connectionによる通信制御の定義

指定するパラメタ

設定内容

webserver.connector.nio_http.keep_alive.max_requests

同じWebクライアントから連続してリクエスト要求があった場合の処理を制御するため，Persistent Connectionのリクエスト処理回数の上限値を指定します。

webserver.connector.nio_http.keep_alive.timeout

Persistent Connectionのリクエスト待ち時間を制御するため，Persistent Connectionのタイムアウトを指定します。

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

(2)　設定例

Persistent Connectionによる通信制御の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.nio_http.keep_alive.max_requests</param-name>
  <param-value>100</param-value>
</param>
<param>
  <param-name>webserver.connector.nio_http.keep_alive.timeout</param-name>
  <param-value>15</param-value>
</param>
：

この設定例では，リクエスト処理回数が「100」を超えた場合には，リクエスト処理終了後にTCPコネクションを切断します。また，タイムアウト時間「15」秒を過ぎてもリクエスト処理要求がない場合は，TCPコネクションを切断します。

7.6　通信タイムアウト

この節では，NIO HTTPサーバでの通信タイムアウトによるWebクライアントとの通信制御について説明します。

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

表7‒10　この節の構成（通信タイムアウト（NIO HTTPサーバ））

分類

タイトル

参照先

解説

通信タイムアウトの概要

7.6.1

設定

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

7.6.2

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

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

NIO HTTPサーバを使用する場合，WebクライアントとNIO HTTPサーバ間での，リクエスト受信およびレスポンス送信，またはWebSocketでのメッセージの送受信に，通信タイムアウトを設定できます。ネットワークの障害やアプリケーションの障害などが発生し応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

NIO HTTPサーバを使用する場合，次に示す図中の二つの矢印が示す通信に対してタイムアウトを設定します。

図7‒3　タイムアウトを設定できる通信（NIO HTTPサーバを使用する場合）

図に示すように，通信タイムアウトはリクエスト受信とレスポンス送信に対して設定します。通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

なお，Webクライアントからのリクエスト受信，およびWebクライアントへのレスポンス送信でタイムアウトが発生した場合，Webクライアントまたはネットワークで障害が発生したと見なされて，Webクライアントとの接続が切断されるため，レスポンスは返されません。

(1)　リクエスト受信時の通信タイムアウト

リクエスト受信時の通信タイムアウトの設定場所を次の図に示します。

図7‒4　リクエスト受信時の通信タイムアウトの設定場所（NIO HTTPサーバを使用する場合）

NIO HTTPサーバを使用する場合，WebクライアントとNIO HTTPサーバ間の通信に，タイムアウトを設定します。

WebクライアントとNIO HTTPサーバ間の通信にタイムアウトを設定することによって，クライアント側で次に示す障害が発生したことを検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとNIO HTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

(2)　レスポンス送信時の通信タイムアウト

レスポンス送信時の通信タイムアウトの設定場所を次の図に示します。

図7‒5　レスポンス送信時の通信タイムアウトの設定場所（NIO HTTPサーバを使用する場合）

NIO HTTPサーバを使用する場合，NIO HTTPサーバとWebクライアント間の通信に，タイムアウトを設定します。

NIO HTTPサーバとWebクライアント間の通信にタイムアウトを設定することによって，次に示す障害を検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとNIO HTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

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

NIO HTTPサーバの通信タイムアウトの設定をする場合，J2EEサーバの設定が必要です。

ここでは，NIO HTTPサーバの通信タイムアウトの設定および設定例について説明します。

通信タイムアウトは，リクエストの受信時，またはレスポンスの送信時に設定します。リクエスト受信時およびレスポンス送信時の通信タイムアウトの設定についてそれぞれ説明します。

(1)　リクエスト受信時の通信タイムアウトの設定

リクエスト受信時の通信タイムアウトは，クライアント−NIO HTTPサーバ間に設定します。

NIO HTTPサーバでのリクエスト受信時の通信タイムアウトは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.nio_http.receive_timeout

クライアントからのリクエスト受信処理の待ち時間を指定します。

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

(2)　レスポンス送信時の通信タイムアウトの設定

レスポンス送信時の通信タイムアウトは，NIO HTTPサーバ−クライアント間に設定します。

NIO HTTPサーバでのレスポンス送信時の通信タイムアウトは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.nio_http.send_timeout

クライアントへのレスポンス送信処理の待ち時間を指定します。

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

(3)　設定例

NIO HTTPサーバの通信タイムアウトの設定例を次に示します。

：
<param>
  <param-name>webserver.connector.nio_http.receive_timeout</param-name>
  <param-value>300</param-value>
</param>
<param>
  <param-name>webserver.connector.nio_http.send_timeout</param-name>
  <param-value>600</param-value>
</param>
：

この設定例では，リクエスト受信のタイムアウトに「300」秒，リクエスト送信のタイムアウトに「600」秒を設定しています。

7.7　IPアドレス指定

この節では，NIO HTTPサーバでのIPアドレス指定によるWebクライアントとの通信制御について説明します。

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

表7‒11　この節の構成（IPアドレス指定）

分類

タイトル

参照先

解説

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

7.7.1

設定

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

7.7.2

注意事項

NIO HTTPサーバでのIPアドレス指定をする場合の注意事項

7.7.3

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

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

Webコンテナでは，NIO HTTPサーバで利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数のネットワークインタフェースを持つホストで，特定の一つのIPアドレスだけを使用するように設定できます。

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

NIO HTTPサーバのIPアドレスの設定をする場合，J2EEサーバの設定が必要です。

ここでは，NIO HTTPサーバのIPアドレスの設定について説明します。

NIO HTTPサーバのIPアドレスは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.nio_http.bind_host

NIO HTTPサーバで利用するホスト名またはIPアドレスを指定します。

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

7.7.3　NIO HTTPサーバでのIPアドレス指定をする場合の注意事項

NIO HTTPサーバでのIPアドレス指定をする場合の注意事項を次に示します。

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。デフォルトでは，ワイルドカードアドレスを使用する設定になっています。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

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

J2EEサーバへの不正アクセスを防ぐため，アクセスできるホストを制限できます。デフォルトでは，全ホストからのアクセスが可能な状態になっています。アクセスを許可するホストのホスト名やIPアドレスを設定しておくことで，特定のホストからのアクセスだけを許可して，不正アクセスを防止できます。

この節では，アクセスを許可するホストの制限によるアクセス制御について説明します。

表7‒12　この節の構成（アクセスを許可するホストの制限によるアクセス制御）

分類

タイトル

参照先

解説

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

7.8.1

設定

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

7.8.2

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

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

ホストを制限するには，アクセスを許可するホストの，ホスト名，またはIPアドレスを設定します。このとき，ホスト名やIPアドレスの代わりにアスタリスク（*）を指定すると，全ホストからのアクセスを許可する設定になります。アクセスを許可するホストをホスト名で指定した場合，J2EEサーバ起動時にホスト名が解決されます。なお，ローカルホストは明記しなくても常にアクセスが許可されます。通常，外部ネットワークからアクセスされるシステムでは，リバースプロキシのIPアドレスを指定します。

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

注意事項

hostsファイル，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定でサーバが起動されます。

ホスト名の解決をJ2EEサーバの起動時にするため，サーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

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

アクセスを許可するホストの制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，アクセスを許可するホストの制限の設定方法と設定例について説明します。

(1)　設定方法

アクセスを許可するホストの制限は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.nio_http.permitted.hosts

アクセスを許可するホストのホスト名やIPアドレスを指定します。

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

注意事項

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

hosts，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定（全ホストからのアクセスが可能な状態）でJ2EEサーバが起動されます。

J2EEサーバの起動時にホスト名を解決するため，J2EEサーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

(2)　設定例

アクセスを許可するホストの制限の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.nio_http.permitted.hosts</param-name>
  <param-value>host1,host2</param-value>
</param>
：

この設定例では，「host1」と「host2」からのアクセスだけを許可し，ほかのホストからのアクセスを許可しません。

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

NIO HTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

この節では，リクエストデータのサイズの制限によるアクセス制御について説明します。

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

表7‒13　この節の構成（リクエストデータのサイズの制限によるアクセス制御）

分類

タイトル

参照先

解説

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

7.9.1

設定

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

7.9.2

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

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

NIO HTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

次に示す項目を設定することで，リクエストデータのサイズ制限によるアクセス制御を実現します。

HTTPヘッダ数の制限

HTTPリクエストに含まれるHTTPヘッダ数の上限値を設定することで，アクセスを制御します。

受信したHTTPリクエストに含まれるHTTPヘッダ数が上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストヘッダサイズの制限

HTTPリクエストのリクエストヘッダのサイズに上限値を設定することによって，アクセスを制御します。

受信したHTTPリクエストのHTTPヘッダのサイズが上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストボディサイズの制限

HTTPリクエストのボディサイズに上限値を設定することによって，アクセスを制御します。NIO HTTPサーバでは，リクエストヘッダに含まれるContent-Lengthヘッダの値で判断します。

HTTPリクエストのボディサイズが上限値を超えた場合，Webクライアントに対してステータスコード413のエラーを返します。

なお，チャンク形式でリクエストボディが送信された場合，サーブレット内部では指定された上限値までのデータを読み込みます。上限値を超えるとサーブレットで例外（IOException）が発生しますが，サーブレットの処理は続行されます。リクエストを送信したクライアントには，指定された上限値までのデータを読み込んだ結果に基づいて，アプリケーションが作成したレスポンスを返します。

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，リバースプロキシを配置していて，ゲートウェイ機器やリバースプロキシにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

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

リクエストデータのサイズ制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，リクエストデータのサイズ制限の設定方法と設定例について説明します。

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。リクエストデータのサイズ制限の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエストデータのサイズ制限の定義について次の表に示します。

表7‒14　簡易構築定義ファイルでのリクエストデータのサイズ制限の定義

指定するパラメタ

設定内容

webserver.connector.nio_http.limit.max_headers

HTTPリクエストに含まれるHTTPヘッダ数の上限値を指定します。

webserver.connector.nio_http.limit.max_request_header

HTTPリクエストのリクエストヘッダのサイズの上限値を指定します。

webserver.connector.nio_http.limit.max_request_body

HTTPリクエストのボディサイズの上限値を指定します。

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

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，リバースプロキシを配置していて，ゲートウェイ機器やリバースプロキシにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

(2)　設定例

リクエストデータのサイズ制限の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.nio_http.limit.max_headers</param-name>
  <param-value>100</param-value>
</param>
<param>
  <param-name>webserver.connector.nio_http.limit.max_request_header</param-name>
  <param-value>8192</param-value>
</param>
<param>
  <param-name>webserver.connector.nio_http.limit.max_request_body</param-name>
  <param-value>16384</param-value>
</param>
：

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

この節では，HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズについて説明します。

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

表7‒15　この節の構成（HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ）

分類

タイトル

参照先

解説

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

7.10.1

設定

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

7.10.2

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

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

ここでは，HTTPレスポンスヘッダのカスタマイズについて説明します。

NIO HTTPサーバでは，HTTPレスポンスのServerヘッダに自動設定する情報をカスタマイズできます。デフォルトでは，「CosminexusComponentContainer」が自動設定されます。

Serverヘッダに自動設定する値は，RFC2616に規定されている値を使用する必要があります。サーブレット/JSPでServerヘッダを使用する設定にしている場合はその設定が優先されます。

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

HTTPレスポンスヘッダのカスタマイズの設定をする場合，J2EEサーバの設定が必要です。

ここでは，HTTPレスポンスヘッダのカスタマイズの設定方法と設定例について説明します。

(1)　設定方法

HTTPレスポンスヘッダのカスタマイズは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.nio_http.response.header.server

HTTPレスポンスのServerヘッダに自動設定する文字列を指定します。

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

(2)　設定例

HTTPレスポンスヘッダのカスタマイズの設定例を次に示します。

：
<param>
  <param-name>webserver.connector.nio_http.response.header.server</param-name>
  <param-value>GyoumuServer/1.0</param-value>
</param>
：

この設定例では，Serverヘッダの値として「GyoumuServer/1.0」を指定しています。

7.11　ログ・トレースの出力

この節では，NIO HTTPサーバが出力するログ・トレースについて説明します。

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

表7‒16　この節の構成（ログ・トレースの出力）

分類

タイトル

参照先

解説

NIO HTTPサーバが出力するログ・トレース

7.11.1

設定

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

7.11.2

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

7.11.1　NIO HTTPサーバが出力するログ・トレース

NIO HTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，次の表に示すログおよびトレースを出力します。

表7‒17　NIO HTTPサーバが出力するログ・トレース

ログ・トレースの種類

説明

アクセスログ

WebクライアントからのHTTPリクエストおよびレスポンスの処理結果や，WebSocketの送受信結果を出力します。Webクライアントとの通信の解析に使用します。

アクセスログを解析することによって，Webクライアントからリクエストされたファイルや，NIO HTTPサーバの性能情報，およびセッショントラッキング情報などを分析できます。

性能解析トレース

NIO HTTPサーバでリクエストを送受信するときの性能解析情報や，障害発生時のトラブルシュートのための情報を出力します。

性能解析トレースは，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて，システム全体のボトルネックの解析などに使用できます。性能解析トレースの詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.6　性能解析トレース」を参照してください。

7.11.2　NIO HTTPサーバのアクセスログのカスタマイズ

NIO HTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，アクセスログおよび性能解析トレースを出力します。これらのファイルは，ファイル面数やファイルサイズなどを変更できます。また，アクセスログでは，ログの出力形式をカスタマイズできます。

ここでは，NIO HTTPサーバのアクセスログの出力形式のカスタマイズについて，HTTPのアクセスログとWebSocketのアクセスログに分けて説明します。HTTPのアクセスログのファイル面数やファイルサイズなどの変更については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「3.3.9　NIO HTTPサーバのログ取得の設定」を参照してください。WebSocketのアクセスログのファイル面数やファイルサイズなどの変更については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「3.3.18　WebSocketコンテナのログ取得の設定」を参照してください。

(1)　HTTPのアクセスログ

HTTPのアクセスログの出力形式のカスタマイズについて説明します。

(a)　設定方法

HTTPのアクセスログの出力形式は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

ejbserver.logger.access_log.nio_http.format

NIO HTTPサーバで扱うHTTPのアクセスログのフォーマットの形式を指定します。

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

(b)　設定例

HTTPのアクセスログの出力形式の設定例を次に示します。

：
<param>
  <param-name>ejbserver.logger.access_log.nio_http.format</param-name>
  <param-value>%a %A</param-value>
</param>
：

この設定例では，WebクライアントのIPアドレスとJ2EEサーバのIPアドレスが出力されます。

(c)　指定できるフォーマット引数

HTTPのアクセスログの出力形式を定義するときに指定する，アクセスログのフォーマットの引数を次の表に示します。

表7‒18　HTTPのアクセスログのフォーマットの引数の一覧

フォーマットの引数

出力内容

出力例

%a

WebクライアントのIPアドレス。

10.20.30.40

%A

J2EEサーバのIPアドレス。

10.20.30.100

%b

レスポンスボディの送信バイト数。

0 byteのときは「-」になる。

2048

%B

レスポンスボディの送信バイト数。

0byteのときは「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.0

%s

最終ステータスコード。

200

%S※2

クッキー名JSESSIONIDの値を出力する。

クッキー名JSESSIONIDの値がない場合は「-」になる。

00455AFE4DA4E7B7789F247B8FE5D605

%t

Webクライアントのリクエスト処理を開始した時刻を秒精度で表示。

[dd/MMM/YYYY:HH:mm:ss Z]

[18/Jan/2005:13:06:10 +0900]

%T

Webクライアントのリクエストの処理に要した時間（秒単位）。

2

%d

Webクライアントのリクエスト処理を開始した時刻をミリ秒精度で表示。

[dd/MMM/YYYY:HH:mm:ss.nnn Z]（nnnはミリ秒）

[18/Jan/2005:13:06:10.152 +0900]

%D

Webクライアントのリクエストの処理に要した時間（ミリ秒単位）。

38

%u

ベーシック認証ユーザ名，フォーム認証ユーザ名。

認証ユーザ名がない場合は「-」になる。

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がない場合は「-」になる。

%{MYSESSIONID}cの場合

00455AFE4DA4E7B7789F247B8FE5D605

%{foo}o※3

レスポンスヘッダfooの内容。

fooヘッダが存在しない場合は「-」になる。

%{Server}oの場合

CosminexusComponentContainer

%rootap

ルートアプリケーション情報。

10.100.10.100/1234/0x0000000000000001

%clport

Webクライアントからのリクエストを送信したポート番号。

888

%push

HTTP/2のプッシュリクエストの場合「PUSH」が出力される。そうでない場合「-」になる。

PUSH

注※1

リモートログ名は，RFC1413で規定されているIdentificationプロトコルによって得られるWebクライアント側のユーザ名です。

注※2

%Sで表示される値は，標準でHTTPセッションIDとして使用するクッキー名JSESSIONIDの値です。Servlet3.0以降でクッキー名JSESSIONIDの名前を変更した場合は，%{foo}cを使用します。

注※3

一度のHTTPリクエストまたはHTTPレスポンスで同じヘッダ名を複数回送信する場合があります。この場合，すべてのヘッダの内容を「，」（コンマ）区切りで出力します。

注意事項

フォーマットの引数の指定に誤りがある場合には，デフォルトフォーマットが使用されます。デフォルトフォーマットが使用される例を次に示します。

フォーマットの引数の一覧にない文字列（例：%Gなど）を指定した場合

リクエストヘッダの内容，レスポンスヘッダの内容，Cookie名で0文字（%{}iなど）を指定した場合

(d)　デフォルトフォーマット

HTTPのアクセスログのデフォルトフォーマットを次に示します。

%h %{X-Forwarded-For}i %l %u %d %rootap "%r" %s %b %D %S %push

デフォルトフォーマットを用いた出力形式を次に示します。

Webクライアントのホスト名またはIPアドレス△X-Forwarded-Forヘッダ△リモートログ名△認証ユーザ名△Webクライアントのリクエスト処理を開始した時刻△ルートアプリケーション情報△”リクエストライン”△最終ステータスコード△HTTPヘッダを除く送信バイト数△Webクライアントのリクエストの処理に要した時間△HTTPセッションID△PUSHリクエスト

注

HTTPセッションIDのあとに改行されます。

（凡例）

△：半角スペース

デフォルトフォーマットを用いた場合の出力例を次に示します。

10.20.30.40 50.60.70.80 - user [18/Jan/2005:13:06:10.152 +0900] 10.100.10.100/1234/0x0000000000000001 "GET /index.html HTTP/1.0" 200 1024 38 00455AFE4DA4E7B7789F247B8FE5D605

(2)　WebSocketのアクセスログ

WebSocketのアクセスログの出力形式のカスタマイズについて説明します。

(a)　設定方法

WebSocketのアクセスログの出力形式は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

ejbserver.logger.access_log.websocket.format

NIO HTTPサーバで扱うWebSocketのアクセスログのフォーマットの形式を指定します。

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

(b)　設定例

WebSocketのアクセスログの出力形式の設定例を次に示します。

：
<param>
  <param-name>ejbserver.logger.access_log.websocket.format</param-name>
  <param-value>%TS %IO %PAYLOADDATALEN</param-value>
</param>
：

この設定例では，WebSocketフレームの送受信時刻，送受信方向，ペイロードデータ長が出力されます。

(c)　指定できるフォーマット引数

WebSocketのアクセスログの出力形式を定義するときに指定する，アクセスログのフォーマットの引数を次の表に示します。

表7‒19　WebSocketのアクセスログのフォーマットの引数の一覧

フォーマットの引数

出力内容

出力例

%TS

WebSocketフレームの送受信時刻。

2001/01/01 01:01:01.111 +0900

%IO

WebSocketフレームの送受信方向。INまたはOUTが出力される。

IN：

サーバインスタンスがWebSocketフレームを受信したことを示す。

OUT：

サーバインスタンスがWebSocketフレームを送信したことを示す。

IN

%OPCODE

WebSocketフレームの種別。Text，Binary，Ping，Pong，またはCloseが出力される。

Text

%URI

リクエストURI。

/websocket_server/test001

%FIN

WebSocketフレームの終端を示す識別子。CONTまたはFINALが出力される。

CONT：

WebSocketフレームの継続。

FINAL：

WebSocketフレームの終端。

CONT

%PAYLOADDATALEN

ペイロードデータ長。

100

%ROOTAP

ルートアプリケーション情報。

10.100.10.100/1234/0x0000000000000001

%CLIENTAP

クライアントアプリケーション情報。

10.100.10.100/1234/0x0000000000000001

%CLOSEREASON

WebSocketコネクションが切断された理由。

NORMAL_CLOSURE:closereason specified by WebSocketClient001

%CLIENTADDR

WebクライアントのIPアドレスとポート番号。

10.20.30.40:55555

%SERVERADDR

J2EEサーバのIPアドレスとポート番号。

10.20.30.100:44444

%SESSIONID

WebSocketセッションID。

11111111-2222-3333-4444-555555555555

%MASK

WebSocketフレームの情報に設定されたMASKを表す。

MASK：

MASKされている。

NOMASK：

MASKされていない。

MASK

%MASKKEY

WebSocketフレームの情報をMASKするためのキー。

MASKしない場合は「-」になる。

EEEEEEEE

%ISEXTENDED

エンドポイントがメッセージの送受信に設定されたフレームを表す。

BASE：

基本フレームを使用している。

EXTENDED：

拡張フレームを使用している。

BASE

%RSV

拡張のネゴシエーション中にクライアントエンドポイントによって設定された予約ビットを表す。

RSV-000

%FRAMEMAINTYPE

WebSocketフレームがデータフレームかコントロールフレームかを指定する。

Data：

データフレームを使用する。

Control：

コントロールフレームを使用する。

Data

%PAYLOADDATA※

ペイロードデータ。

データのサイズが65536文字を超える場合，最初と最後の32768文字だけを表示する。

バイナリの場合は常に「-」になる。

aaaaaa

%PAYLOADDATA(n)※

メッセージの最初と最後のn文字分だけを表示する場合のペイロードデータ。

nは1〜32768の整数が指定できる。

バイナリの場合は常に「-」になる。

aaaaaaaaaa....aaaaaaaaaa

注※

%PAYLOADDATAと%PAYLOADDATA(n)はどちらか一方だけを指定できます。

注意事項

フォーマットの引数の指定に誤りがある場合には，デフォルトフォーマットが使用されます。デフォルトフォーマットが使用される例を次に示します。

フォーマットの引数の一覧にない文字列（例：%Gなど）を指定した場合

%PAYLOADDATA(n)のnに指定可能範囲外の文字列を指定した場合

%PAYLOADDATAと%PAYLOADDATA(n)を同時に指定した場合

(d)　デフォルトフォーマット

WebSocketのアクセスログのデフォルトフォーマットを次に示します。

%TS %IO %OPCODE %ROOTAP %URI %FIN %PAYLOADDATALEN %CLIENTAP %CLOSEREASON

デフォルトフォーマットを用いた出力形式を次に示します。

WebSocketフレームの送受信時刻△WebSocketフレームの送受信方向△WebSocketフレームの種別△ルートアプリケーション情報△リクエストURI△WebSocketフレームの終端を示す識別子△ペイロードデータ長△クライアントアプリケーション情報△WebSocketコネクションが切断された理由

注

WebSocketコネクションが切断された理由のあとに改行されます。

（凡例）

△：半角スペース

デフォルトフォーマットを用いた場合の出力例を次に示します。

2020/01/01 01:01:01.111 +0900 IN Text 10.100.10.100/1234/0x0000000000000001  /websocket_server/test001 CONT 100 10.100.10.100/1234/0x0000000000000003 -

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

この章では，サーブレットおよびJSPを実装するときの注意事項について説明します。

8.1　Servlet仕様およびJSP仕様で追加，変更された機能のサポート範囲

ここでは，Servlet仕様およびJSP仕様で追加，変更された機能の概要と，アプリケーションサーバでのサポート範囲を示します。

各バージョンのServlet仕様およびJSP仕様で追加，変更された機能をアプリケーションサーバで使用する場合の動作や注意事項は，「8.2.4　Servlet 3.0/3.1仕様で追加，変更された仕様についての注意事項」以降を参照してください。

Servlet 4.0で追加，変更された機能の概要とサポート範囲を次の表に示します。

表8‒1　Servlet 4.0の機能の概要とサポート範囲

項番

機能名

機能概要

サポート

1

web.xml（Servlet 4.0）

Servlet 4.0に対応したweb.xmlを使用できます。

○

2

HTTP/2

HTTP/2プロトコルの通信ができます。

○

3

Servlet Mapping API

サーブレット実行時のURLマッピングを取得できます。

○

4

デフォルトコンテキストパスの設定

web.xmlにデフォルトコンテキストパスを設定できます。

○

5

Webアプリケーション単位のデフォルト文字エンコーディングの設定

web.xmlやServletContextからデフォルト文字エンコードを設定できます。

○

6

セッションタイムアウトの設定

ServletContextからセッションタイムアウトを設定できます。

○

7

動的JSP定義

APIでJSPを定義できます。

○

8

HTTP Trailer

HTTP Trailerを使用できます。

○

9

APIのエンハンス

Servlet 4.0で新規に追加または変更となったAPIが使用できます。

○

（凡例）

○：サポートする

Servlet 3.1で追加，変更された機能の概要とサポート範囲を次の表に示します。

表8‒2　Servlet 3.1の機能の概要とサポート範囲

項番

機能名

機能概要

サポート

1

web.xml（Servlet 3.1）

Servlet 3.1に対応したweb.xmlを使用できます。

○※1

2

非同期I/O

ReadListener/WriteListenerインタフェースを用いて非同期I/Oを実装できます。

○

3

Upgradeリクエスト

WebSocketプロトコルなどへのUpgradeリクエストに対応できます。

○

4

セキュリティエンハンス

セキュリティロールのロール名に"**"を指定できます。

リダイレクト成功時にステータスコード303が利用できます。

カバーされていないHTTPメソッドを拒否する設定ができます。

×

5

APIのエンハンス

新規に追加または変更となったAPIが使用できます。

△※2

（凡例）

○：サポートする　×：サポートしない　△：一部サポートする

注※1

Servlet 3.1に対応したweb.xmlは読み込めますが，Servlet 3.1で追加されたタグについては無視されます。

注※2

サポートする機能のAPIは使用できますが，サポートしない機能のAPIは使用できません。Servlet 3.1のAPIについては，「8.2.4(9)　APIについて」を参照してください。

Servlet 3.0で追加，変更された機能の概要とサポート範囲を次の表に示します。

表8‒3　Servlet 3.0の機能の概要とサポート範囲

項番

機能名

機能概要

サポート

1

web.xml（Servlet 3.0）と新規アノテーション

Servlet 3.0に対応したweb.xmlを使用できます。

○

アノテーションでサーブレットを定義できます（web.xmlを省略できます）。

○

web-fragment.xmlを使用できます。

×※1

2

動的サーブレット定義

APIでサーブレット，フィルタ，またはリスナを定義できます。

○

3

ファイルアップロード

content-typeがmultipart/form-dataのリクエストを処理できます。

○

4

静的リソースの配置

JARファイルのMETA-INF/resourcesに静的リソースやJSPを配置できます。

○

5

セキュリティエンハンス

アノテーションでセキュリティ設定ができます。

認証用のAPIが使えます。

○

6

非同期サーブレット

リクエストを受け付けたスレッドとは別のスレッドで，リクエスト処理やレスポンス生成ができます。

○

7

Servlet仕様のその他の変更

CookieにHttpOnly属性を付けられます。

○

HTTPセッションのセッションIDを示すHTTP Cookieの名前を変更できます。

○

HTTPダイジェスト認証が使えます。

×※2

ServletRequestの属性としてSSL Session IDが取得できます。

×※3

8

JSP仕様の変更

デフォルトのコンテンツタイプやバッファサイズなどをweb.xmlで指定できます。

○

9

ELパラメタ付きメソッド

パラメタ付きメソッドを呼び出せます。

○※4

10

APIのエンハンス

新規に追加または変更となったAPIが使用できます。

△※5

（凡例）

○：サポートする　×：サポートしない　△：一部サポートする

注※1

web-fragment.xmlがWebアプリケーションに含まれていた場合，無視されます。

注※2

DDでダイジェスト認証が設定された場合，動作は保証されません。

注※3

ServletRequestクラスで，「javax.servlet.request.ssl_session_id」を引数に指定してgetAttributeメソッドを呼び出すと，常にnullが返ります。

注※4

JSP 2.1仕様または2.0仕様のELの場合，JSP 2.2以降のEL式は使用できません。JSP 2.2以降のELのAPIを使用した場合，チェックされないため動作は保証されません。

注※5

サポートする機能のAPIは使用できますが，サポートしない機能のAPIは使用できません。Servlet 3.0のAPIについては，「8.2.4(9)　APIについて」を参照してください。

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

この節では，サーブレットおよびJSPの実装時の注意事項について説明します。

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

表8‒4　この節の構成（サーブレットおよびJSPの実装時の注意事項）

タイトル

参照先

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

8.2.1

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

8.2.2

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

8.2.3

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

8.2.4

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

8.2.5

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

8.2.6

JSP実装時の注意事項

8.2.7

JSP 2.2仕様およびJSP 2.3仕様に関する注意事項

8.2.8

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

8.2.9

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

8.2.10

JSP 1.2仕様のJSP実装時の注意事項

8.2.11

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

8.2.12

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

8.2.13

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

8.2.14

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

8.2.15

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

8.2.16

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

8.2.17

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

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

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

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

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

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

Webアプリケーションに対応するServlet仕様

4.0

3.1

3.0

2.5

2.4

2.3

2.2

Java EE 8

○

○

○

○

○

○

○

Java EE 7

×

○

○

○

○

○

○

Java EE 6

×

×

○

○

○

○

○

Java EE 5

×

×

×

○

○

○

○

J2EE1.4

×

×

×

×

○

○

○

J2EE1.3

×

×

×

×

△

○

○

J2EE1.2

×

×

×

×

△

△

○

（凡例）

○：使用できる

△：使用できる（J2EEアプリケーションのインポート時にJ2EE仕様のバージョンが1.4に更新されるため）

×：使用できない

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

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

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

表8‒6　Webアプリケーションのサポート範囲

Webアプリケーションのバージョン

Servlet

JSP

タグライブラリ※

4.0

3.1

3.0

2.5

2.4

2.3

2.2

2.3

2.2

2.1

2.0

1.2

1.1

2.1

2.0

1.2

1.1

4.0

○

○

○

○

○

○

○

〇

〇

○

○

○

○

○

○

○

○

3.1

×

○

○

○

○

○

○

〇

〇

○

○

○

○

○

○

○

○

3.0

×

×

○

○

○

○

○

×

〇

○

○

○

○

○

○

○

○

2.5

×

×

×

○

○

○

○

×

×

○

○

○

○

○

○

○

○

2.4

×

×

×

×

○

○

○

×

×

×

○

○

○

×

○

○

○

2.3

×

×

×

×

×

○

○

×

×

×

×

○

○

×

×

○

○

2.2

×

×

×

×

×

×

○

×

×

×

×

×

○

×

×

×

○

（凡例）○：使用できる　×：使用できない

注※

タグライブラリのバージョンとは，タブライブラリ・ディスクリプタ（TLDファイル）のバージョンを表します。

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

表8‒7　Servlet 2.2，2.3，2.4または2.5仕様に対応するWebアプリケーションからServlet 3.0/3.1の機能を使用した場合のエラー

仕様

使用する機能

エラー時の処理

Servlet 3.0/3.1

新規APIの呼び出し

Servlet 3.0/3.1仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

新規アノテーションの使用

アノテーションを使用してエラーとなった場合の処理については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.　アノテーションの使用」を参照してください。

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

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

仕様

使用する機能

エラー時の処理

Servlet 2.5

新規APIの呼び出し

Servlet 2.5仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

新規アノテーションの使用

アノテーションを使用してエラーとなった場合の処理については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.　アノテーションの使用」を参照してください。

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アプリケーションのバージョンアップする場合の作業，および注意事項については，「8.2.13　既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点」を参照してください。

表8‒9　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アプリケーションのバージョンアップする場合の作業，および注意事項については，「8.2.15　既存の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アプリケーション内のコードから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メソッドを使用する場合には，java.net.JarURLConnectionのgetJarFileメソッドが返すJarFileインスタンスの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からコンテナ拡張ライブラリを参照するように実装してください。コンテナ拡張ライブラリの作成については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「19.　コンテナ拡張ライブラリ」を参照してください。

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

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

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

サービスメソッドやinitメソッドの範囲内で動作させる。

サービスメソッドやinitメソッドのバックグラウンドで動作させる。

ユーザスレッドの使用条件

ユーザスレッドは，Enterprise Beanでは使用できません（EJB仕様で，Enterprise Beanからのスレッドの生成が禁止されているため）。

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

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

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

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

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

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

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

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

ユーザスレッドを生成したサービスメソッドやinitメソッドは，ユーザスレッドを生成したあと，処理の完了を待たないでリターンします。ただし，アプリケーションを停止したあとは，ユーザスレッドからJ2EEサービスを利用できなくなります。したがって，アプリケーションの停止によってjavax.servlet.ServletContextListenerのcontextDestroyedメソッドか，JSPまたはServletの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.servlet.ServletRequestインタフェースのgetServerNameメソッドおよびgetServerPortメソッドの戻り値について

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

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

表8‒10　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メソッドの戻り値については，「表8-10　getServerNameメソッド，およびgetServerPortメソッドの戻り値（Servlet 2.4仕様以降の場合）」を参照してください。

表8‒11　getServerNameメソッド，およびgetServerPortメソッドの戻り値（アプリケーションサーバの場合）

HTTPリクエスト

getServerNameメソッドの戻り値

getServerPortメソッドの戻り値

Hostヘッダの有無

リクエストラインのURIの種類

あり

絶対URI

リクエストラインのホスト名

リクエストラインのポート番号

相対URI

Hostヘッダのホスト名

Hostヘッダのポート番号

なし

絶対URI

リクエストラインのホスト名

リクエストラインのポート番号

相対URI

J2EEサーバのホスト名またはIPアドレス※

NIO HTTPサーバのポート番号

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

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

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

javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について説明します。

注意事項

根本原因の例外をgetCauseメソッドの実装によって取得できる場合，コンストラクタServletException(String, Throwable)またはServletException(Throwable)で生成したServletExceptionオブジェクトに対してinitCause(Throwable)を呼び出すことはできません。initCause(Throwable)を呼び出した場合，java.lang.IllegalStateException例外がスローされます。

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

アプリケーションサーバでは，javax.servlet.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パターンとのマッチング

(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ファイル転送方式による制約

11-10以前の，welcomeファイルの転送は，HTTPリダイレクト（HTTPステータスコード302でリダイレクトする）によって実現しています。この転送方式には制約があるため，URL設計の際に次のことに注意してください。11-20以降は，welcomeファイルの処理をフォワードによって実現します。レスポンス時のURLが，リダイレクトの場合はリダイレクト先のURLが表示されますが，フォワードの場合はリクエストで指定したURLが表示されます。また，相対パスの処理がフォワードとリダイレクトで異なるため，リダイレクトを期待して設計していたアプリケーションをフォワードで動作するように変更する必要があります。11-20-01以降は，リダイレクトのままにしたい場合はwebserver.container.redirectWelcomeFileプロパティにtrueを設定することで，welcomeファイル処理をHTTPリダイレクトするようになります。

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アプリケーションを開始すると，リクエストの受付を開始する前に次の順序で初期化処理をすることがServlet 2.4仕様で明確化されました。アプリケーションサーバでは，Servlet2.3以前のWebアプリケーションでも同じ順序で初期化処理をします。Webアプリケーション開始時のサーブレット，フィルタ，およびリスナは次の順序で開始されます。

リスナの開始（インスタンスの生成※1，@PostConstructアノテーションのメソッドおよびServletContextListenerのcontextInitializedメソッドの呼び出し※2）

フィルタの開始（インスタンスの生成※1，@PostConstructアノテーションのメソッドおよびinitメソッドの呼び出し）

load-on-startupタグで指定されたServlet/JSPの開始（インスタンスの生成※1，@PostConstructアノテーションのメソッドおよびinitメソッドの呼び出し）

注※1　Servlet 3.0以降では，API呼び出しによって動的にサーブレット，フィルタ，リスナを追加できますが，インスタンスを指定するAPI呼び出しによって定義を追加したサーブレット，フィルタ，リスナについては，インスタンス生成済みのため，Webコンテナではインスタンスを生成しません。

注※2　リスナのcontextInitialized()メソッドの呼び出しで例外が発生しても，KDJE39103-Eのメッセージを出力してWebアプリケーションの開始処理を継続します。

なお，web.xmlの<load-on-startup>要素によってWebアプリケーション開始時の初期化処理実行を指定しなかったサーブレットについては，初回リクエスト実行時にサーブレットのインスタンスの生成およびinit()メソッドを呼び出します。

このとき，サーブレットのインスタンスの生成およびinit()メソッドはフィルタより前に呼び出します。

Webアプリケーション終了時のサーブレット，フィルタ，およびリスナは次の順序で終了します。

開始済みのServlet/JSPの終了(destroyメソッド，@PreDestroyアノテーションのメソッド呼び出し)

フィルタの終了(destroyメソッド，@PreDestroyアノテーションのメソッド呼び出し)

リスナの終了(@PreDestroyアノテーションのメソッド呼び出し)

(28)　Webアプリケーション内の静的コンテンツへのアクセス

Webアプリケーション内の静的コンテンツへのアクセス時に使用できるメソッドは，GET，HEAD，POST，TRACE，OPTIONSのどれかです。

POSTメソッドを使用した場合，GETメソッド使用時と同様，静的コンテンツの内容を応答します。

(29)　文字エンコーディングに関する注意

同じWebアプリケーション内では，web.xmlで指定したエラーページと，HTTPレスポンスに文字エンコーディングを使用するサーブレットおよびJSPに，同じ文字エンコーディングを使用してください。

(30)　クエリ文字列にイコール（"="）以降だけ指定した場合の戻り値について

リクエストのクエリ文字列にイコール（"="）以降しか指定していない場合（例えば，http://localhost/application/getparam.jsp?=paramのような場合）の，javax.servlet.ServletRequestインタフェースのリクエストパラメタを取得するServlet APIの戻り値を次に示します。

getParameterメソッド

空文字（""）を指定してもnullを返します。

getParameterMapメソッド

空のjava.util.Mapオブジェクトを返します。

getParameterNamesメソッド

空のjava.util.Enumerationオブジェクトを返します。

getParameterValuesメソッド

空文字（""）を指定してもnullを返します。

(31)　javax.servlet.http.HttpServletResponseインタフェースのcontainsHeaderメソッドについて

以下のレスポンスヘッダはWebコンテナにより自動的にレスポンスにセットされる場合があります。このようなレスポンスヘッダは，javax.servlet.http.HttpServletResponseインタフェースのcontainsHeaderメソッドで，レスポンスにセットされているかどうかを確認できません。

Connection

Content-Language

Content-Length

Content-Type

Date

Server

Set-Cookie

Transfer-Encoding

(32)　アプリケーションサーバのライブラリに関する注意

アプリケーションサーバのライブラリをJ2EEアプリケーションに含めると，ライブラリのバージョン不整合などが原因で，アプリケーションのインポートや開始，実行で不正な動作になることがあります。そのため，製品が使用方法として明示している場合を除いて，アプリケーションサーバのライブラリはJ2EEアプリケーションに含めないようにしてください。

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

サーブレットを実装するときの注意事項を示します。

(1)　入出力ストリーム利用時の注意

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メソッド

また，Content-Typeがmultipart/form-dataのフォームデータを受信した場合は，上記のメソッドまたはHttpServletRequestクラスの次に示すメソッドの呼び出し時に，KDJE39336-E のメッセージの出力を伴うIllegalStateException例外が発生することがあります。この場合，受信したフォームデータのサイズが適切かどうかを確認し，適切なサイズのときはwebserver.connector.limit.max_post_form_dataの設定値を見直してください。

getPartメソッド

getPartsメソッド

(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サーバの設定の変更方法については，マニュアル「HTTP Server」を参照してください。

(9)　プロセス内で複数回実行してはならない処理を実装する場合の注意

1プロセス内で複数回実行してはならない処理をサーブレット中に記述する場合，サーブレットの実行とその処理が同期することがないようにしてください。特に，OTMとの通信を開始するための初期化処理の中には，インスタンスを削除しても終了しない常駐スレッドを生成するものがあります。例えば，TPBrokerの初期化関数であるORB.initメソッドは，呼び出されるたびにGC実行のための監視用常駐スレッドを生成し，このスレッドはプロセス終了まで消えません。そのため，1プロセス内でORB.initメソッドを必要以上に実行すると，不要なGC処理が増え，システム全体の性能が著しく低下するなどの悪影響があります。

このような事態を避けるため，プロセス中で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の設定については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

あるスレッドが条件フラグであるstatic変数の値を参照してから値を変更するまでの間に，ほかのスレッドが同様の処理を実行することがないよう，この処理を実行するメソッドにsynchronizedキーワードを指定してください。この方法を用いて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)　ServletContextオブジェクトに登録する製品独自の属性

Webコンテナは，Webアプリケーションの制御に必要な情報をjavax.servlet.ServletContextオブジェクトの属性に登録しています。WebアプリケーションでServletContextインタフェースのgetAttributeNamesメソッドによって取得する属性名には，Webコンテナによって登録された属性の名称も含まれます。

Webアプリケーション内でServletContextオブジェクトに属性を登録する時，次の文字列で開始するキー名称を使用しないでください。

org.apache.catalina

com.hitachi.software.web

jspx

また，ServletContextにはJava EEの仕様で定められた属性も追加されるため，これらと同じキー名称の属性を登録しないでください。

(11)　ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

次に示すjavax.servlet.ServletRequestクラスのメソッドは，リクエストを送信したクライアント，または最後に通ったプロキシの情報を取得するためのメソッドですが，リバースプロキシを使用した環境では，取得する情報がリバースプロキシの情報となります。

getRemoteAddrメソッド

getRemoteHostメソッド

getRemotePortメソッド

(12)　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で文字エンコーディングを設定できます。

(13)　setMaxInactiveIntervalメソッドの引数に0を指定した場合の動作

javax.servlet.http.HttpSessionインタフェースのsetMaxInactiveIntervalメソッドの引数に0を指定した場合，セッションがタイムアウトになることはありません。

(14)　java.io.BufferedReaderのmark操作について

javax.servlet.ServletRequestのgetReaderメソッドで得られるjava.io.BufferedReaderは，mark操作をサポートしていません。markSupportedメソッドではfalseが返されます。

(15)　setVersionメソッドの引数に1を指定した場合の動作

javax.servlet.http.CookieのsetVersionメソッドの引数に1を指定した場合，Set-Cookieヘッダが付加されます。

(16)　getRequestDispatcherメソッドでのパスの指定について

javax.servlet.ServletRequestのgetRequestDispatcherメソッドの引数に「/」ではじまらない相対パスを指定した場合，このサーブレットのサーブレットマッピングに指定したURLパターンからの相対パスになります。URLパターンが「/」で終わっている場合は，親のディレクトリからの相対パスになります。

例えば，サーブレットマッピングを"/a/b/"に指定したサーブレットから，"hello.html"を指定してgetRequestDispatcherメソッドを実行すると，"/a/hello.html"が得られます。

(17)　setBufferSizeメソッドを使用してバッファサイズを変更する場合の注意

レスポンス送信時に使用されるサーブレットのバッファは，リクエスト処理スレッドごとに保持されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを実行してバッファサイズを変更した場合，変更したバッファサイズは，同一J2EEサーバ上のほかのWebアプリケーションを含め，該当するスレッドが処理するすべてのリクエストに適用されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを使用してバッファサイズを変更する場合は，（バッファサイズ）×（リクエスト処理スレッド数）分のメモリが確保されることを考慮した上で，メモリ使用量を見積もってください。

なお，一度確保されたバッファは，処理スレッドごとにWebアプリケーションからsetBufferSizeメソッドで更新されるまで有効となります。

(18)　HTTPレスポンスのContent-Typeヘッダについての注意

サーブレットでは，javax.servlet.ServletResponseクラスのsetContentTypeメソッドで明示的にContent-Typeを設定していない場合，Content-Typeヘッダを作成しません。そのため，HTTPレスポンスの文字エンコーディングをContent-Typeヘッダの”charset=”フィールドから確認することはできません。

(19)　javax.servlet.http.HttpSessionクラスのgetIdメソッドについての注意事項

Servlet 2.4仕様以前に準拠したWebアプリケーションで，無効化されたjavax.servlet.http.HttpSessionオブジェクトのgetIdメソッドを呼び出した場合の動作がServlet仕様とアプリケーションサーバとで異なります。それぞれの動作を次に示します。

Servlet仕様

java.lang.IllegalStateException例外をスローする。

アプリケーションサーバ

nullを返す。

(20)　javax.servlet.ServletRequestクラスおよびjavax.servlet.http.HttpServletRequestクラスのメソッドについての注意事項

次の表に示すメソッドで取得した情報をレスポンスに出力する場合は，サニタイズする必要があります。

表8‒12　取得した情報をサニタイズする必要があるメソッド

クラス名

メソッド名

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()

(21)　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ヘッダがないと見なしてサーバのデフォルトロケールを返します。

(22)　javax.servlet.http.HttpServletRequestインタフェースのgetServerNameメソッドの戻り値

javax.servlet.http.HttpServletRequestインタフェースのgetServerNameメソッドの戻り値は，リバースプロキシでHostヘッダを書き換えた場合，HTTPクライアントが設定したHostヘッダの値と異なることがあります。

(23)　Servlet 2.4以前のinclude先のサーブレットでのレスポンスヘッダの設定

Servlet 2.4以前では，include先のサーブレットでのレスポンスヘッダの設定はすべて無視される仕様です。ただし，アプリケーションサーバでは，Servlet 2.4を使用した場合でも，getSessionでのレスポンスヘッダの設定は有効になります。

(24)　MIMEマッピングがない静的コンテンツのコンテンツ形式

MIMEマッピングがない静的コンテンツの場合，Content-Typeは付与されません。

(25)　HTTPセッションのアクセス時刻について

セッションIDの付加されたリクエストがWebコンテナに送信されたとき，HTTPセッションのアクセス時刻は現在時刻で更新されます。ただし，すでにセッションがタイムアウトしたり，無効化したりしている場合には該当しません。

HTTPセッションのアクセス時刻は次で使用されます。

javax.servlet.http.HttpSessionインタフェースのgetLastAccessedTime()メソッドの戻り値

javax.servlet.http.HttpSessionインタフェースのgetLastAccessedTime()メソッドは，前回更新時のHTTPセッションのアクセス時刻を返します。

HTTPセッションのタイムアウト

現在時刻とHTTPセッションのアクセス時刻の差がタイムアウト時間を超えたとき，HTTPセッションはタイムアウトします。なお，HTTPセッションのタイムアウト監視は30秒間隔で実行されるため，正確なタイムアウト時間にタイムアウトが発生するわけではありません。

(26)　Content-Lengthヘッダの値取得時の注意事項

HTTPリクエストにContent-Lengthヘッダが含まれていない場合，javax.servlet.ServletRequestのgetContentLength()メソッドの戻り値，およびjavax.servlet.http.HttpServletRequestのgetIntHeader()メソッドで引数に"Content-Length"を指定した場合の戻り値がServlet仕様とアプリケーションサーバとで異なります。それぞれの戻り値を次に示します。

Servlet仕様

-1を返す。

アプリケーションサーバ

0を返す。

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

Servlet 4.0仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。

(1)　APIについて

Servlet 4.0仕様で追加されたAPIを使用できます。APIの詳細については，Servlet 4.0の仕様書を参照してください。

(2)　HTTP/2の注意事項

J2EEサーバのNIO HTTPサーバ機能は，HTTPS通信をサポートしていないため，HTTP/1.1以前と同様にHTTP/2でHTTPS通信をする場合にも，J2EEサーバのフロントにリバースプロキシなどのHTTP/2に対応した製品を配置する必要があります。アプリケーションサーバ11-40に含まれているHTTP ServerはHTTP/2に対応していますが，サーバープッシュは非サポートです※。このため，J2EEサーバ上のHttpServletRequest#newPushBuilder()メソッドはnullを返します。サーバープッシュが無効な場合のHttpServletRequest#newPushBuilder()メソッドの動作の詳細は，Javadocを参照してください。サーバープッシュを有効にするには，別途サーバープッシュに対応したリバースプロキシ製品を用意する必要があります。

注※

HTTP ServerのHTTP/2サポート範囲については，マニュアル「HTTP Server」を参照してください。

HTTP/2で，javax.servlet.ServletInputStream.isFinished()メソッドが，HTTP/2のストリームの状態によってはtrueにならない場合があります。

HTTP Trailerの上限値に達しても，javax.servlet.ServletInputStream.read()で例外が発生しない場合があります。例外が発生しない場合，javax.servlet.ServletInputStream.read()の戻り値が-1になるので，例外と合わせて戻り値を確認してください。

(3)　Servlet Mapping APIの注意事項

web.xmlのservlet-mappingのurl-pattenに空文字を指定することはできません。空文字を指定した場合は，「/」に変換されます。このとき，HttpServletMapping APIのgetMappingMatch()の値はDEFAULTが設定されます。

なお，javax.servlet.ServletRegistrationインタフェースのaddMapping()メソッドを使用した場合は，空文字を指定した場合でも空文字が「/」に変換されません。その場合は，HttpServletMapping APIのgetMappingMatch()の値にはCONTEXT_ROOTが設定されます。

(4)　デフォルトコンテキストパスの注意事項

cjaddappコマンドでの，default-context-pathの設定はサポートしていません。cjaddappコマンドにWARファイルを指定する場合，WARファイルに含まれるweb.xmlでデフォルトコンテキストパスを指定しても，無視されます。

(5)　Webアプリケーション単位のデフォルト文字エンコーディングの設定の注意事項

Servlet 4.0から導入された，次のメソッドまたはタグに不正なエンコーディングを設定した場合，アプリケーションサーバの「デフォルトの文字エンコーディング設定機能」の指定があればその指定値，なければServletの仕様で規定された文字エンコーディングが設定されます。

javax.servlet.ServletContextインタフェースのsetRequestCharacterEncoding()メソッドもしくはsetResponseCharacterEncoding()メソッド

web.xmlの<web-app><request-character-encoding>タグもしくは<web-app><response-character-encoding>タグ

(6)　HTTP Trailerの注意事項

java.servlet.http.HttpServletRequestインタフェースのsetTrailerFields()メソッドは，レスポンスがすでにコミットされているか，HTTP Trailerがサポートされていない（例えばHTTP/1.0や，HTTP/1.1のchunkedではない）場合にjava.lang.IllegalStateExceptionを投げる仕様ですが，アプリケーションサーバではchunkedかどうかに関係なく，次の条件の場合にjava.lang.IllegalStateExceptionをthrowします。

プロトコルがHTTP Trailerをサポートしていない（HTTP1.0である）。

HTTP1.1でレスポンスがすでにコミットされている。

(7)　そのほかの注意事項

Servlet 3.0/JSP 2.2以降は，Webコンテナがweb.xmlと共にタグライブラリ・ディスクリプタ（TLDファイル）を解析してリスナを登録します。

addListener（Servlet 3.0以降）でリスナを登録した場合，「ServletContextListener#contextInitializedメソッド内で使用できないServletContextのメソッド」をTLDファイルで宣言したリスナで使用したとしても，java.lang.UnsupportedOperationExceptionは発生しません。

8.2.4　Servlet 3.0/3.1仕様で追加，変更された仕様についての注意事項

Servlet 3.0/3.1仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。Servlet 3.1仕様，Servlet 3.0仕様およびServlet 2.5仕様については，それぞれの仕様書（Servlet 3.1仕様書，Servlet 3.0仕様書，Servlet 2.5仕様書）を参照してください。

(1)　Servlet 3.0とアプリケーションサーバの機能を組み合わせた場合の仕様

Servlet 3.0で追加された機能と，アプリケーションサーバの機能を組み合わせた場合の仕様について説明します。

(a)　Webプリケーションのバージョン設定機能

Webアプリケーションのバージョン設定機能で，バージョンとして3.0以降は設定できません。

(b)　META-INF/resources以下のJSP事前コンパイル

Servlet 3.0仕様では，JSPファイルをJARファイルの中のMETA-INF/resourcesの階層に含めることができるようになりましたが，META-INF/resources内にJSPを含むWebアプリケーションの場合，JSPの事前コンパイルは実行できません。JSP事前コンパイルを実行した場合，META-INF/resources内のJSPは事前コンパイルされないで，リクエスト実行時にエラーとなります。

(c)　アプリケーションのリロード

Servlet 3.0/3.1仕様の機能を使用したアプリケーションをリロードする場合，次の制約があります。

META-INF/resourcesに静的コンテンツ（JSPも含む）を持つJARファイルを含むアプリケーションの場合，JARファイルを更新してリロードしても，JARファイルのMETA-INF/resources内の静的コンテンツは更新前のものにしかアクセスできません。META-INF/resourcesに静的コンテンツを持つJARファイルを含むアプリケーションをリロードした場合，KDJE39556-Wが出力されます。

注意事項

09-00-02より前のバージョンの場合，次のアプリケーションをリロードしたときの動作は保証されません。

ServletContainerInitializerインタフェースの実装クラスを含むアプリケーションの場合。

リロードした場合，KDJE39557-Wが出力されます。

動的サーブレット定義で追加したサーブレット，フィルタまたはリスナを含むアプリケーションの場合。

リロードした場合，KDJE39558-Wが出力されます。

(d)　APIで定義したサーブレットでのrun-as機能

APIで定義したサーブレットでrun-as機能を使用できません。次の設定をした場合，無視されます。

サーブレットのクラスで@RunAsアノテーションを使用する。

ServletRegistration.DynamicインタフェースのsetRunAsRoleメソッドを呼び出す。

(e)　APIで定義したサーブレットまたはフィルタの実行時間の監視

APIで定義したサーブレットまたはフィルタでは，J2EEアプリケーションの実行時間の監視機能を使用できません。cosminexus.xmlに<method-observation-timeout>タグが設定されていても無視されます。

(f)　Webアプリケーションの呼び出し時のHTTPセッションの継続

Webアプリケーションの呼び出し時のHTTPセッションの継続については，Servlet 2.5仕様の場合と同じ動作となります。詳細は，「8.2.5(6)　Webアプリケーションの呼び出し時のHTTPセッションの継続について」を参照してください。

(g)　アノテーション参照抑止機能

Servlet3.0で追加されたアノテーションのうち，@HandlesTypesアノテーションはアノテーション参照抑止機能の対象になりません。アノテーション参照抑止機能が有効な場合でも処理されます。

(2)　Servlet 3.0以降とCDIを組み合わせた場合について

Servlet 3.0以降とCDIを組み合わせて使用する場合，Servlet 3.0以降に対応したweb.xmlを使用してください。これ以外のバージョンのweb.xmlとCDIを組み合わせて使用できません。

(3)　APIで定義したフィルタまたはリスナと，@PostConstructアノテーションまたは@PreDestroyアノテーションを組み合わせた場合について

APIで定義したフィルタまたはリスナでは，@PostConstructアノテーションまたは@PreDestroyアノテーションを使用できません。これらのアノテーションを使用した場合，無視されます。

(4)　インクルード時に対象のコンテンツがない場合について

Servlet 3.0仕様では，インクルードの対象がデフォルトサーブレット（静的コンテンツを提供するためにコンテナが用意しているサーブレット）で，対象のコンテンツがない場合，FileNotFoundException例外をスローすることになっています。また，その例外がユーザプログラムで処理されなかった場合，レスポンスはコミットされないで，ステータスコード500を返すことなっています。

アプリケーションサーバでは，この仕様はサポートされません。08-70以前のバージョンと同様にステータスコード404が返されます。

(5)　エスケープシーケンスの使用について

Servlet 3.0以降で新規に追加されたAPIやプロパティの入力文字に，エスケープシーケンス（¥b，¥t,，¥n，¥f，¥r，¥"，¥'，¥¥）を使用しないでください。使用した場合，ログが途中で改行されるなど，表示が不正になることがあります。

(6)　動的サーブレット定義について

動的サーブレット定義について，アプリケーションサーバで使用した場合にServlet 3.0/3.1仕様と異なる点について説明します。

(a)　サーブレット，フィルタ，またはリスナの定義

APIおよびweb.xmlの両方でフィルタを追加した場合に，APIで定義されたほかのフィルタマッピングのisMatchAfterメソッドがfalseに設定されているときは，リクエスト処理の中でAPIの定義が先に呼ばれます。

APIおよびweb.xmlの両方でリスナを定義した場合，リスナの生成のときはアプリケーションの開始時にweb.xmlで定義されたリスナが先に読み込まれます。リスナを削除するときは，APIの定義が先に読み込まれます。

URLパターンに空文字（""）を指定してjavax.servlet.ServletRegistrationインタフェースのaddMapping(String... urlPatterns)メソッドを呼び出した場合，サーブレットはコンテキスト名だけでアクセスされます。コンテキスト名も空文字（""）の場合は，サーブレットにアクセスできません。

すでにweb.xmlで定義された名称，または@WebServletアノテーションでサーブレットクラスが生成された名称と同じサーブレット名を指定して，addServlet()メソッドを呼び出さないでください。

ユーザアプリケーションの中で，同じサーブレットに対してsetMultipartConfig()メソッドを呼び出し，@MultipartConfigアノテーションを指定した場合，setMultipartConfig()メソッドで指定した値が使用されます。

同様に，ユーザアプリケーションの中で，同じサーブレットに対してsetServletSecurity()メソッドを呼び出し，@ServletSecurityアノテーションを指定した場合，setServletSecurity()メソッドで指定した値が使用されます。

getRunAsRole()メソッドおよびsetRunAsRole(String roleName)メソッドを使用して，ロールの取得および設定はできません。また，ワーニングメッセージまたはエラーメッセージも出力されません。

すでに登録されている名称でサーブレットまたはフィルタを登録した場合，アプリケーションの開始時にKDJE39552-Wが出力され，処理は続行されます。

URLパターンに改行コードが含まれていた場合，アプリケーションの開始時にKDJE39555-Wが出力され，処理は続行されます。

(b)　ServletContainerInitializerインタフェースを使用した定義

アプリケーションサーバでのServletContainerInitializerインタフェースを使用した定義について，Servlet 3.0仕様と次の点が異なります。

ServletContainerInitializerインタフェースを実装したクラスを含むJARファイルは次の場所に配置できます。

アプリケーションに含まれるWARファイル内のWEB-INF/libディレクトリ

WEB-INF/libディレクトリ以外の場所

WEB-INF/libディレクトリ以外の場所に，ServletContainerInitializerインタフェースを実装したクラスを含むJARファイルを配置する場合，JARファイルの絶対パスをusrconf.propertiesの次のプロパティに指定します。WEB-INF/libディレクトリにあるJARファイルを指定した場合の動作は保証しません。

webserver.ServletContainerInitializer_jar.include.path

設定例

webserver.ServletContainerInitializer_jar.include.path=C:/Program Files/xxx/foo/lib/bar.jar

@HandlesTypesアノテーションのクラスの検索範囲は，ServletContainerInitializerインタフェースの実装クラスを含むWARの中です。WARのWEB-INF/classesディレクトリにあるクラス，およびWEB-INF/libディレクトリにあるJARファイルが対象となります。

ServletContainerInitializerインタフェースを実装したクラスを含むJARファイルが読み込めないか処理できない場合，アプリケーションの開始時にKDJE39548-Eが出力され，アプリケーションの開始に失敗します。

@HandlesTypesアノテーションで指定したクラスを継承(extends)や実装(implements)したクラス，または@HandlesTypesアノテーションで指定したクラスのアノテーションを付けているクラスを検索する際に，クラスのロードに失敗した場合，KDJE39549-Wが出力され，アプリケーションの開始処理は続行されます。

webserver.ServletContainerInitializer_jar.include.pathに指定した，ServletContainerInitializerインタフェースを実装したクラスを含むJARファイルが見つからない場合，またはJARファイルもしくはファイルが読み込めない場合，アプリケーションの開始時にKDJE39553-Wが出力され，処理は続行されます。このメッセージはwebserver.ServletContainerInitializer_jar.include.pathに指定されたJARファイルごとに出力されます。

webserver.ServletContainerInitializer_jar.include.pathに指定した，ServletContainerInitializerインタフェースを実装したクラスを含むJARファイルがクラスパスの中に見つからない場合，アプリケーションの開始時にKDJE39554-Wが出力され，処理は続行されます。このメッセージはwebserver.ServletContainerInitializer_jar.include.pathに指定されたJARファイルごとに出力されます。

(7)　ファイルアップロードについて

ファイルアップロードについて，アプリケーションサーバで使用した場合にServlet 3.0/3.1仕様と異なる点について説明します。

web.xmlおよび@MultipartConfigアノテーションの両方でmultipart config要素を設定した場合，web.xmlの定義が優先されます。

リクエストタイプがmultipart/form-data以外のリクエストでファイルアップロードを実施した場合，javax.servlet.ServletException例外がスローされます。ファイルアップロードを実施するリクエストのタイプと実行結果を次の表に示します。

表8‒13　ファイルアップロードを実施するリクエストのタイプと実行結果

web.xmlまたは@MultipartConfigアノテーションを指定したリクエストのタイプ

実行結果

mime-multipart以外

javax.servlet.ServletException例外がスローされます。

multipart/form-data以外のmime-multipart

javax.servlet.ServletException例外がスローされます。

multipart/form-data

ファイルアップロードが実行されます。例外は発生しません。

MultipartConfigElementがプログラムで定義された場合，web.xmlで定義された場合と同じ動作になります。ただし，空文字（""）がlocationに指定された場合，ファイルがWebアプリケーションの作業ディレクトリに格納されます。

アップロードされたファイルが，web.xmlの<file-size-threshold>タグまたは@MultipartConfigアノテーションのfileSizeThreshold属性で指定した値よりも大きいサイズの場合，リクエスト内のオブジェクトの一部分に対応する一時ファイルが生成されます。一時ファイルの名称は，「upload」から始まる，一意に識別される名称で，拡張子は「.tmp」です。

例：upload__5f8d5c62_1316c5ef08b__8000_00000012.tmp

一時ファイルはリクエストの処理の最後に削除されます。ただし，一時ファイルが開かれたままの場合，J2EEサーバが正常に停止されなかった場合，システムダウンした場合など，一時ファイルが削除されないケースがあります。このような場合は，locationで指定した場所から一時ファイルを手動で削除する必要があります。

ユーザが手動で作成したファイルと同じ名称の一時ファイルが生成された場合は，ユーザが作成したファイルが上書きされます。

Partオブジェクトはリクエスト内で利用できます。Partオブジェクトはリクエストが完了した時点で削除されます。あとで利用するためにセッションの中でPartオブジェクトを保持しても，動作は保証されません。

(8)　静的リソースの配置について

静的リソースの配置について，アプリケーションサーバで使用した場合にServlet 3.0/3.1仕様と異なる点について説明します。

静的リソースが含まれるJARファイルが読み込めないか処理できない場合，アプリケーションの開始時にKDJE39548-Eが出力され，アプリケーションの開始に失敗します。

指定したJARファイルに形式不正があった場合，アプリケーションの開始時にKDJE39550-Eが出力され，処理は続行されます。

WEB-INF/libに不正なJARファイル，または読み込めないファイルが含まれていた場合，アプリケーションの開始時にKDJE39551-Wが出力され，そのJARファイルを無視して処理が続行されます。

(9)　APIについて

APIについて，アプリケーションサーバで使用した場合にServlet 3.0/3.1仕様と異なる点について説明します。

アプリケーションサーバでは，Servlet 3.0/3.1仕様で追加されたAPIのうち，次の表に記載されていないAPIを使用できます。APIの詳細については，Servlet 3.1の仕様書を参照してください。

次の表に記載された非サポートのAPIを使用した場合の挙動は，表下の注釈を参照してください。

表8‒14　非サポートのAPI（Servlet 3.0/3.1）

項番

パッケージ

クラス

インタフェース/クラス

メソッド

機能

1

javax.servlet

ServletContext

インタフェース

getJspConfigDescriptor※1

JSP

2

getVirtualServerName※2

Servlet

3

javax.servlet.descriptor

JspConfigDescriptor

インタフェース

すべてのメソッド※3

JSP

4

JspPropertyGroupDescriptor

インタフェース

すべてのメソッド※3

JSP

5

TaglibDescriptor

インタフェース

すべてのメソッド※3

JSP

6

javax.servlet.http

HttpSessionIdListener

インタフェース

すべてのメソッド※4

Servlet

7

HttpServletRequest

インタフェース

changeSessionId※5

Servlet

8

HttpServletRequestWrapper

インタフェース

changeSessionId※5

Servlet

注※1

非サポートAPIを呼び出した場合は次の挙動となります。

プロパティwebserver.servlet_api.unsupported.throwUnsupportedOperationExceptionがtrueの場合：UnsupportedOperationExceptionが挙がる。

上記以外：nullを返す。

注※2

非サポートAPIを呼び出した場合は次の挙動となります。

プロパティwebserver.servlet_api.unsupported.throwUnsupportedOperationExceptionがtrueの場合：UnsupportedOperationExceptionが挙がる。

上記以外：空文字を返す。

注※3

非サポートAPIのインスタンスを取得する手段がありません。

注※4

非サポートAPIをアプリケーション側で実装しても，Webコンテナからコールバックされません。

注※5

非サポートAPIを呼び出した場合は次の挙動となります。

プロパティwebserver.servlet_api.unsupported.throwUnsupportedOperationExceptionがtrueの場合：UnsupportedOperationExceptionが挙がる。

上記以外：現在のHTTPセッションのセッションIDが返る。HTTPセッションが未作成の場合はIllegalStateExceptionが挙がる。

Servlet 2.5仕様に対応するWebアプリケーションで，Servlet 3.0以降で追加されたAPIは使用できません。使用した場合，チェックされないため動作は保証されません。

SessionTrackingModeでは，SSLは使用できません。アプリケーションサーバではCOOKIEとURLだけ使用できます。

(10)　web.xmlの省略について

Servlet 3.0/3.1仕様では，次のアプリケーションの場合，web.xmlを省略できます。

静的コンテンツおよびJSPだけを含むWebアプリケーション（サーブレット，フィルタ，およびリスナを含まない）

サーブレット，フィルタ，リスナをアノテーションで定義したWebアプリケーション

(11)　セッションIDを示すHTTP Cookie名の変更について

セッションIDを示すHTTP Cookie名を変更する場合，Cookie名に「csfcfc」を指定できません。

また，使用できる文字に次の条件があります。条件に違反した場合，KDJE39559-Wが出力されます。セッションの不正な動作の原因になることがあるため，条件に合った文字を使用してください。

ASCII文字を使用してください。ただし，次の文字は使用できません。

「#」，「(」，「)」，「<」，「>」，「@」，「,」，「;」，「:」，「¥」，「/」，「"」，「[」，「]」，「?」，「=」，「{」，「}」

空白，および制御文字は使用できません。

文字列の先頭に「$」は使用できません。

(12)　Webアプリケーションで使用できるHTTP Cookie名

WebアプリケーションでHTTP Cookieを使用する場合，次の名称を指定できません。なお，大文字と小文字は区別されません。

HTTPセッションのセッションIDで使用するHTTP Cookieの名称。デフォルトは「JSESSIONID」。

グローバルセッションを表すHTTP Cookieの名称。デフォルトは「GSESSIONID」。

J2EEサーバのサーバID付加機能によってサーバIDを付加したHTTP Cookieの名称と同じ名称。

J2EEサーバ内部で使用するHTTP Cookieの名称「csfcfc」。

(13)　<servlet-class>要素に指定するクラスについて

web.xmlの<servlet-class>要素を省略する場合，@WebServletアノテーションを指定したjavax.servlet.http.HttpServletのサブクラスをWebアプリケーションに含め，name属性に<servlet-class>要素を省略したサーブレットのサーブレット名を設定する必要があります。該当するHttpServletクラスがない場合は，KDJE39339-Eが出力され，サーブレットクラスのロードに失敗します。

(14)　<filter-class>要素に指定するクラスについて

web.xmlの<filter-class>要素を省略する場合，@WebFilterアノテーションを指定したjavax.servlet.Filterの実装クラスをWebアプリケーションに含め，filterName属性に<filter-class>要素を省略したフィルタのフィルタ名を設定する必要があります。該当するFilterクラスがない場合は，KDJE39340-Eが出力され，アプリケーションの開始に失敗します。

(15)　セッションIDを示すHTTP CookieのPath属性の変更について

セッションIDを示すHTTP CookieのPath属性を変更する場合，別のWebアプリケーションとセッションIDを示すHTTP Cookie名やPath属性が重複すると，HTTP CookieのセッションIDを示す値が上書きまたは削除されるなどの理由で，HTTPセッションが正しく引き継がれなくなることがあります。

(16)　セッションIDを示すHTTP CookieのPath属性とDomain属性に使用できる文字について

セッションIDを示すHTTP CookieのPath属性とDomain属性に使用できる文字には次の条件があります。条件に違反した場合，KDJE39559-Wが出力されます。セッションの不正な動作の原因になることがあるため，条件に合った文字を使用してください。

Path属性には，ASCII文字だけが使用できます。ただし，制御文字およびセミコロン（;）は使用できません。

Domain属性には，英数字，ハイフン（-）およびピリオド（.）だけが使用できます。

(17)　非同期サーブレットの場合の注意事項

ここでは，Servlet仕様に明記されていない挙動やServlet仕様と異なる挙動について説明します。

アプリケーションサーバではCDIが有効なアプリケーションで非同期サーブレットを実行できません。実行した場合，WELD-000335，WELD-000714，WELD-000715またはWELD-000717のメッセージが出力されることがあります。デフォルトではCDIが有効になります。非同期サーブレットを利用するには，ejbserver.javaee.cdi.beansXmlRequiredにtrueを指定して，アーカイブにbeans.xmlを含めないで，CDIを無効にしてください。CDIの無効化については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「9.3.1　CDIの対象となるアプリケーション」を参照してください。

Servlet仕様では，AsyncContext.complete()メソッドの呼び出しによってレスポンスをコミットすることが記載されていますが，そのタイミングについては明記されていません。アプリケーションサーバでは，別スレッドでAsyncListener.onComplete()を呼び出したあとにレスポンスをコミットします。このため，タイミングによってはAsyncContext.complete()を呼び出したあとに，レスポンスへの書き込みができる場合があります。AsyncContext.complete()を呼び出したあとに書き込んだ内容が，レスポンスに出力されるか，レスポンスバッファに残って意図しない出力をするかは，実行するタイミングに依存するため，AsyncContext.complete()を呼び出したあとのレスポンスへの書き込みは実装しないでください。

なお，startAsyncメソッドを呼び出したサーブレットのserviceメソッドが終了するまでは，complete()を呼び出したあとのレスポンスコミットとonCompleteメソッド呼び出しは実行されず，ServletRequest.isAsyncStarted()メソッドがtrueを返すことは，Servlet仕様に明記された仕様です。

Servlet仕様では，AsyncContext.start(Runnable)でコンテナ管理のスレッドに委譲した非同期処理で例外が発生した場合に，コンテナがAsyncListgener.onError(AsyncEvent)を呼ぶかどうかは明記されていません。アプリケーションサーバでは，AsyncContext.start(Runnable)を呼び出したサーブレットのserviceメソッドが終了したあとに例外が発生した場合は，AsyncListgener.onError(AsyncEvent)を呼び出しません。

Servlet仕様では，AsyncContextのdispatchメソッド実行中に例外が発生した場合のコンテナのふるまいについて，次の記述があります。

コンテナがAsyncListgener.onError(AsyncEvent)を呼び出す。

リスナーがcompleteメソッドもdispatchメソッドも呼ばない場合は，ステータスコード500でエラー遷移する。

対応するエラーページが見つからないか，エラーページでcompleteメソッドもdispatchメソッドも呼ばない場合は，コンテナがAsyncContext.complete()を呼び出す。

アプリケーションサーバでは，コンテナがonErrorメソッドを呼び出したあとに，web.xmlのerror-page要素に指定されたエラーページに遷移しません。dispatch先で発生した例外がerror-page要素のexception-typeの指定にマッチする場合は，onErrorメソッドを呼び出す前に指定されたエラーページに遷移します。また，例外が発生した場合には，error-page要素のerror-codeで指定したエラーページには遷移しません。

javax.servlet.AsyncContext.addListener(AsyncListener)実行後にjavax.servlet.AsyncEvent.getSuppliedRequest()またはgetSuppliedResponse()メソッドを実行すると，Servlet API仕様に記載の期待値と異なった値が返されます。

<期待値>

null

<実際の値>

javax.servlet.ServletRequestのstartAsyncメソッド実行時に使用されているjavax.servlet.ServletRequestまたはServletResponse実装クラスのインスタンス

次のメソッドについて，Servlet API仕様に記載されているjava.lang.IllegalStateExceptionが発生しない場合があります。

javax.servlet.AsyncContext.addListener(AsyncListener)

javax.servlet.AsyncContext.addListener(AsyncListener, ServletRequest, ServletResponse)

javax.servlet.AsyncContext.setTimeout(long)

javax.servlet.AsyncContext.getRequest()

javax.servlet.AsyncContext.getResponse()

javax.servlet.http.WebConnection.getInputStream()またはgetOutputStream()メソッドについて，Servlet API仕様に記載されているjava.io.IOExceptionが発生しない場合があります。

javax.servlet.AsyncContext.setTimeout(long)の引数に0以下の値（タイムアウトなし）を設定していて，アプリケーション停止時に，webserver.context.stop_asyncwait_timeoutに設定した待ち時間を経過しても非同期処理が完了していない場合，コンテナが非同期タイムアウトを試み，AsyncListenerが存在する場合はonTimeoutメソッドを呼び出します。

サーバ停止時に非同期処理が完了していない場合は，webserver.context.stop_asyncwait_timeoutやjavax.servlet.AsyncContext.setTimeout(long)の設定値に関わらず，コンテナが非同期タイムアウトを試み，AsyncListenerが存在する場合はonTimeoutメソッドを呼び出します。

次の条件をすべて満たす場合に，javax.servlet.ServletRequest.isAsyncStarted()メソッドはServlet API仕様に記載の期待値とは異なった値を返します。

非同期サイクルにリスナを登録する

javax.servlet.ServletRequestのstartAsyncメソッドを呼び出したのと同じjavax.servlet.Servlet.serviceメソッド内でjavax.servlet.AsyncContext.complete()メソッドを呼び出す

登録したリスナのonComplete()メソッドjavax.servlet.ServletRequest.isAsyncStarted()メソッドを呼び出す

<期待値>

false

<実際の値>

true

非同期サーブレットでは，次に示すメソッドの第二引数としてjavax.servlet.http.HttpServletResponseのインスタンスが渡されます。

HttpServletResponseが引数として渡される非同期サーブレットのメソッド

・doDelete(HttpServletRequest, HttpServletResponse)

・doGet(HttpServletRequest, HttpServletResponse)

・doHead(HttpServletRequest, HttpServletResponse)

・doOptions(HttpServletRequest, HttpServletResponse)

・doPost(HttpServletRequest, HttpServletResponse)

・doPut(HttpServletRequest, HttpServletResponse)

・doTrace(HttpServletRequest, HttpServletResponse)

・service(HttpServletRequest, HttpServletResponse)

・service(ServletRequest, ServletResponse)

上記のメソッドで，引数として渡されたjavax.servlet.http.HttpServletResponseのインスタンスに対して，次に示すメソッドの呼出しが無効となります。

呼出しが無効となるHttpServletResponseのメソッド

・addCookie(Cookie)

・addDateHeader(String, long)

・addHeader(String, String)

・addIntHeader(String, int)

・sendError(int)

・sendError(int, String)

・sendRedirect(String)

・setContentLength(int)

・setContentType(String)

・setDateHeader(String, long)

・setHeader(String, String)

・setIntHeader(String, int)

・setStatus(int)

・setStatus(int, String)

これらのメソッドを実行した場合，指定した値はレスポンスに設定されません。

非同期サーブレットでは，HttpServletResponseのインスタンスに対するsendError，setStatusメソッドの呼び出しが無効となるため，ステータスコードの設定はできませんが，非同期サーブレットから上位に例外をthrowした場合は，ステータスコードを500に設定します。

ただし，レスポンスがコミット済みの場合は，すでに返したステータスコードのまま通信を切断します。

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

Servlet 2.5仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。Servlet 2.5仕様およびServlet 2.4仕様については，それぞれの仕様書（Servlet 2.5仕様書，Servlet 2.4仕様書）を参照してください。

(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アプリケーション

実行環境でのWebアプリケーションのプロパティの設定

マッピングの設定

フィルタの使用

web.xmlの省略については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「16.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アプリケーションではフィルタを使用できません。そのため，アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）が必要な機能は使用できません。

(3)　<load-on-startup>要素への空文字列の指定

Servlet 2.5仕様で定義されたweb.xmlのスキーマでは，<load-on-startup>要素に指定できる値が変更されました。

アプリケーションサーバでは，<load-on-startup>要素に指定できる値はweb.xmlに記述するServlet仕様のバージョン情報に対応したサーブレットに従って制御されます。サーブレットのバージョンごとに<load-on-startup>要素に指定できる値について次の表に示します。

表8‒15　<load-on-startup>要素に指定できる値

サーブレットのバージョン

指定できる値

Servlet 2.5

整数，または空文字列。空文字列が指定された場合，<load-on-startup>要素が指定されなかった場合と同様に，サーブレットのロードを行わない。

なお，指定できない値を指定した場合，J2EEアプリケーションのインポートに失敗します。

(4)　<security-constraint>要素でのHTTPメソッドの指定範囲について

Servlet 2.5仕様で定義されたweb.xmlのスキーマでは，<security-constraint><web-resource-collection>要素内の<http-method>要素に指定できる内容について変更されました。指定できる内容について次の表に示します。

表8‒16　<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仕様のバージョン情報に対応したサーブレットでサポートする内容と同じです。アプリケーションサーバでサポートするリクエストのHTTPメソッドについて次に示します。

表8‒17　アプリケーションサーバでサポートするリクエストのHTTPメソッド

サーブレットのバージョン

指定できる内容

Servlet 2.5以降

HTTP1.1で使用可能なすべてのメソッド。

Servlet 2.4

GET，POST，PUT，DELETE，HEAD，OPTIONS，TRACEのどれか。

指定できない値を指定した場合，J2EEアプリケーションのインポートに失敗します。

(5)　アノテーションの使用

アプリケーションサーバでは，Servlet 2.5仕様で規定されたアノテーションをサポートします。アノテーションの使用については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.　アノテーションの使用」を参照してください。

(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メソッドの戻り値

(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仕様の場合はnullが戻り値となります。

(11)　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出しについて

サーブレットのバージョンが異なるWebアプリケーション間でクロスコンテキストを呼び出した場合，呼び出し元と呼び出し先のサーブレットのバージョンによって，呼び出し先の動作が異なるメソッドがあります。サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出しをした場合のクロスコンテキストの呼び出し先の動作について，メソッドごとに表に示します。

表8‒18　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出し先の動作（javax.servlet.http.HttpServletRequestインタフェースのgetRequestURLメソッド）

Webアプリケーションのサーブレットのバージョン

クロスコンテキストの呼び出し先の動作

参照先

呼び出し元

呼び出し先

Servlet 2.5以降

Servlet 2.4以前

Servlet 2.5仕様に従う。

8.2.5(9)

Servlet 2.4以前

Servlet 2.5以降

Servlet 2.4仕様に従う。

表8‒19　サーブレットのバージョンが異なるWebアプリケーション間でのクロスコンテキストの呼び出し先の動作（無効化されたjavax.servlet.http.HttpSessionオブジェクトのgetIdメソッド）

Webアプリケーションのサーブレットのバージョン

クロスコンテキストの呼び出し先の動作

参照先

呼び出し元

呼び出し先

Servlet 2.5以降

Servlet 2.4以前

Servlet 2.5仕様に従い，セッションIDを返す。

8.2.5(10)

Servlet 2.4以前

Servlet 2.5以降

Servlet 2.4仕様に従い，nullを返す。

(12)　include先のサーブレットでのレスポンスヘッダの設定について

Servlet 2.5仕様では，include先のサーブレットでのレスポンスヘッダの設定について，getSessionの場合だけ設定が有効となります。ただし，アプリケーションサーバでは，Servlet 2.4を使用した場合でも，getSessionでのレスポンスヘッダの設定は有効になります。

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

Servlet 2.4仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。Servlet 2.4仕様およびServlet 2.3仕様については，それぞれの仕様書（Servlet 2.4仕様書，Servlet 2.3仕様書）を参照してください。

(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したあとの動作を，次の表に示します。

表8‒20　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した場合を表します。

(13)　Servlet 2.4のWebアプリケーションからEJB 3.0のSession Beanを呼び出す場合

Servlet 2.4のWebアプリケーションからEJB 3.0のSession Beanを呼び出す場合は，

web.xmlに<ejb-ref>タグ，<ejb-local-ref>タグを指定しないで，サーブレットクラスに@EJBアノテーション，@EJBsアノテーションを指定してください。

J2EEサーバがサーブレットに対してEnterprise BeanのDIを実行します。

8.2.7　JSP実装時の注意事項

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メソッドを実装している場合には，後ろに記述された属性の値が有効になります。

タグライブラリ・ディスクリプタ（TLDファイル）では，タグの要素として空文字列を指定しないでください。空文字列を指定するとは，開始タグと終了タグ間に何も記述しない（例えば，<param-name></param-name>）または空要素タグを記述する（例えば，<param-name />）ことを言います。タグの要素として空文字列を指定した場合の動作は保証されません。

タグライブラリ・ディスクリプタ（TLD）ファイルでxsi:schemaLocation属性を指定する場合，絶対パスを指定してください。

TLDファイルでタグまたはタグライブラリの拡張要素を使用する際に，xsi:schemaLocation属性に相対パスを指定した場合の動作の保証はされません。

(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.の場合のディレクトリ構成の例を次に示します。

図8‒3　ディレクトリ構成（2.の場合）

このディレクトリ構成の場合のtaglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングを次の図に示します。

図8‒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.の場合のディレクトリ構成の例を次に示します。

図8‒5　ディレクトリ構成（3.の場合）

4.の場合，TLDファイルはライブラリJARの/META-INFディレクトリ以下に格納されています。4.の場合のディレクトリ構成の例を次に示します。

図8‒6　ディレクトリ構成（4.の場合）

3.または4.の場合のディレクトリ構成でのtaglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングを次の図に示します。

図8‒7　TLDファイルの<uri>要素で指定したURIと，そのTLDファイル自身のマッピング（3.または4.の場合）

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

タグのプリフィックスにtaglibディレクティブで指定したプリフィックスを指定します。

TLDファイルの<name>要素で指定した値を，JSPファイルのプリフィックスと対応づけます。

TLDファイルの<url>要素で，JSPファイルのtaglibディレクティブで指定したuriを指定します。

URIの重複が検出された場合，次のメッセージがWebアプリケーション単位で出力され，該当するマッピングは無視されます。

表8‒21　URI重複時に出力されるメッセージと出力条件

メッセージID

出力条件

KDJE39314-W

TLDファイルで記述した<uri>要素の内容が，web.xmlの<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ファイルのバージョンに関する注意事項

JSPトランスレーション時にTLDファイルのバージョン（TLDファイルが対応するJSPのバージョン）をチェックします。そのため，TLDファイルのバージョンが，Webアプリケーションのバージョンに対応しているJSPおよびTLDファイルのバージョンより上位のJSPの場合，JSPトランスレーションでエラーになります。また，JSP 1.2，およびJSP 2.0仕様以降では，TLDファイルにスキーマ言語を定義する必要があります。

TLDファイルのバージョンは，TLDファイルに記述されたスキーマ言語から判定します。ただし，スキーマ言語が定義されていない場合は，Webアプリケーションのバージョンから判定します。

TLDファイルにスキーマ言語を定義していない場合のTLDファイルのバージョンを次の表に示します。

表8‒22　スキーマ言語未定義時の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ドキュメントで使用できる文字エンコーディング

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属性に指定します。指定できる文字列は，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ドキュメントで使用する文字エンコーディングは，必ず一致するようにしてください。

注※　XML Processorがサポートしている文字エンコーディングについては，マニュアル「XML Processor ユーザーズガイド」の「1.3.2　処理できる文字コード」を参照してください。

(c)　JSPドキュメントの場合（Servlet 2.3仕様に準拠したWebアプリケーションの場合）

Servlet 2.3仕様に準拠したWebアプリケーション内のJSPドキュメントで使用できる文字エンコーディングと，使用する文字エンコーディングの指定方法について次に示します。

JSPドキュメントで使用できる文字エンコーディング

XML Processorがサポートしている文字エンコーディングが使用できます。XML Processorがサポートしている文字エンコーディングについては，マニュアル「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シンタックスのタグファイルで使用できる文字エンコーディングと，使用する文字エンコーディングの指定方法を示します。

タグファイルで使用できる文字エンコーディング

XML Processorがサポートしている文字エンコーディング※が使用できます。

文字エンコーディングの指定方法

タグファイルに使用する文字エンコーディングは，XML1.0仕様に従って指定してください。指定できる文字列は，XML Processorがサポートしている文字エンコーディング※です。

なお，指定する文字エンコーディングとタグファイルで使用する文字エンコーディングは，必ず一致するようにしてください。

注※　XML Processorがサポートしている文字エンコーディングについては，マニュアル「XML Processor ユーザーズガイド」の「1.3.2　処理できる文字コード」を参照してください。

(f)　デフォルトの文字エンコーディング

JSPファイル，またはタグファイルに文字エンコーディングを明示的に指定しない場合，デフォルトの文字エンコーディングでJSPを処理します。

なお，この場合も，デフォルトの文字エンコーディングと，タグファイルで使用する文字エンコーディングは，必ず一致するようにしてください。デフォルトの文字エンコーディングについて，ServletおよびJSPの仕様ごとに次の表に示します。

表8‒23　デフォルトの文字エンコーディング

仕様

JSPページ

JSPドキュメント

標準シンタックスのタグファイル

XMLシンタックスのタグファイル

Servlet 2.2/ JSP 1.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，JSP 2.1，JSP 2.2，JSP 2.3

ISO-8859-1

UTF-8

ISO-8859-1

UTF-8

（凡例）−：該当しない

デフォルトの文字エンコーディングは，デフォルトの文字エンコーディング設定機能を使用しても設定できます。詳細については，「2.6　デフォルトの文字エンコーディング設定機能」を参照してください。

(14)　setPropertyアクション使用時の注意事項

JSPページでのsetPropertyアクション，またはJSPドキュメントでの<jsp:setProperty>タグのname属性に，不正な値を指定しないでください。<jsp:setProperty>タグのname属性に不正な値を指定した場合の動作は保証されません。

(15)　JSPのタグの属性への空文字列の指定について

JSPページのディレクティブやアクションのタグ，およびJSPドキュメントの「jsp:」で始まるタグの属性に空文字列を指定しないでください。

(16)　JSPのテンプレートテキストの前後にスクリプトレットを記述する場合の注意

JSPのテンプレートテキストの前後にif文などの制御文を含むスクリプトレットを記載する場合は，明示的に"{}"（中括弧）で囲む必要があります。

JSPコンパイルの結果，1行のJSPのテンプレートテキストがJavaファイルでも1行のステートメントとなるとは限りません。複数行のステートメントとして出力される可能性があります。そのため，テンプレートテキストの前後のスクリプトレットでif文などの制御文を明示的に"{}"（中括弧）で囲んでいない場合は，意図しない動作となるおそれがあります。

(17)　スクリプトレット使用時の注意

JSPでスクリプトレットを使用してjavaコードを記述する場合に，スクリプトレットにreturn文またはthrow文を記述するときは，if文などのブロック内に記述するようにしてください。

(18)　ELが無効な場合のトランスレーションエラーについて

JSP内に"${aaa"のようにELとして不正な文字列を含む場合，ELを無効に設定しても，EL不正のトランスレーションエラーが発生します。

JSP仕様のバージョンごとに，トランスレーションエラーが発生するEL開始文字を次の表に示します。

表8‒24　トランスレーションエラーが発生するEL開始文字

JSP仕様のバージョン

EL開始文字

JSP 2.1以降

'$'，'#'

JSP 2.0

'$'

JSP 1.2

なし

(19)　TLDファイルのschemaLocationの記載について

TLDファイルに記述するschemaLocationは，TLDのバージョンに応じて，次の表に示すどちらかの値を指定する必要があります。

TLDのバージョン

schemaLocationに指定する値

2.0

"http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"

2.1

"http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd"

8.2.8　JSP 2.2仕様およびJSP 2.3仕様に関する注意事項

JSP 2.2仕様およびJSP 2.3仕様に関する注意事項を示します。

(1)　JSPのコンパイルエラーについて

11-00以前のバージョンでは，JSP 2.2で追加されたタグに関しては無視していましたが，11-10以降のバージョンでは，JSP 2.2で追加されたタグをサポートします。そのため，タグの指定内容に問題がある場合にはJSPのコンパイルに失敗することがあります。

JSP 2.2仕様およびJSP 2.3仕様では処理が追加になっているため，メソッドの処理内容が多いとコンパイル時にエラーとなるおそれがあります。エラーとなった場合は，JSPの処理をメソッド化して分けて1メソッドの処理内容を少なくしてください。

(2)　11-00以前のバージョンで作成したWebアプリケーションのバージョンが，3.0または3.1の場合のJSPの実行について

11-00以前のバージョンでは，Webアプリケーションのバージョンが3.0または3.1の場合，JSPのバージョンは2.1としてコンパイルしていました。11-10以降のバージョンの推奨モードでは，Webアプリケーションのバージョンが3.0または3.1の場合のJSPのバージョンは2.2または2.3となります。ただし，11-00以前のバージョンの環境で，事前コンパイル結果が存在する場合だけ，Webアプリケーションのバージョンが3.0または3.1であってもJSPのバージョンは2.1のままとなります。

(3)　JSP 2.2でのbean取得時の排他制御

jsp:useBean利用時の排他制御についての動作を次に示します。

表8‒25　jsp:useBean利用時の排他制御

Webアプリケーションのバージョン

内容

3.0以降

Application ScopeおよびSessionScopeの場合は，beanの取得および生成時にスコープごとの排他制御を実施します。

2.5以前

すべてのスコープで，beanの取得および生成時にスコープごとの排他制御を実施します。

(4)　JSP 2.3でのHTTPメソッドに対するJSPページの出力

HTTPメソッドに対するJSPページの出力についての動作を次に示します。

表8‒26　HTTPメソッドに対するJSPページの出力

Webアプリケーションのバージョン

内容

3.1以降

HTTPメソッドのGET，POST，HEAD，およびOPTIONに対してだけJSPページを出力します。

GET，POST，HEAD，およびOPTION以外のHTTPメソッドに対しては「405　Method Not Allowed」を返します。

3.0以前

すべてのHTTPメソッドに対してJSPページを出力します。

(5)　インポートしたパッケージ・クラス・staticフィールドのEL式使用について

JSPでEL3.0を利用する場合に，pageディレクティブやtagディレクティブでインポートしたパッケージ・クラスを，ImportHandlerでインポートしたパッケージ・クラスとしてEL式で使用できます。

ただし，staticインポートは適用されないため，pageディレクティブやtagディレクティブを用いたstaticインポート後にEL式にクラス名なしのstaticフィールドを記述しても使用できません。

使用できる例，使用できない例を次に示します。

使用できる例

<%@ page import="com.FooClass" %>

（中略）

${FooClass.FOO_VALUE}

使用できない例

<%@ page import="static com.FooClass.FOO_VALUE" %>

（中略）

${FOO_VALUE}

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

JSP 2.1仕様で追加，変更された仕様を，アプリケーションサーバ上で利用するときの注意事項を示します。JSP 2.1仕様およびJSP 2.0仕様については，それぞれの仕様書（JSP 2.1仕様書，JSP 2.0仕様書）を参照してください。

(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に対してトランスレーションエラーが発生するかどうかを次の表に示します。

表8‒27　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属性

ただし，ホワイトスペースではないテンプレートテキストと連続しているホワイトスペースは削除されません。

表8‒28　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以外の不正値を指定した場合，トランスレーションエラーとなります。

(a)　ホワイトスペースの削除例

次の図に，JSP要素の間に，ホワイトスペースだけのテンプレートテキストが存在する例を示します。

図8‒8　ホワイトスペースだけのテンプレートテキストが存在する例

1〜4行目のtaglibディレクティブは出力しないため無視し，1行目の復帰改行，2行目の復帰改行，および3行目の半角スペースから復帰改行がホワイトスペースだけのテンプレートテキストとなります。

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仕様で規定されたアノテーションをサポートします。アノテーションの使用については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.　アノテーションの使用」を参照してください。

(6)　タグファイルのバージョンの決定方法

JSP 2.1仕様でタグファイルに記述できる要素が追加されたため，タグファイルのバージョンの明確化が必要になりました。そのため，アプリケーションサーバでは，JSP 2.1仕様に従ってタグファイルのバージョンを決定します。

ただし，タグファイルのバージョンはタグファイルのファイル単位で一致する必要があります。異なるバージョンのTLDファイルを使用して同一のタグファイルを実行した場合の動作は保証されません。

なお，TLDファイルやimplicit.tldなど，バージョン決定要素となるもののバージョンが異なっていても，実際の使用方法で決定するバージョンがファイル単位で一致すれば問題なく動作します。

例えば，次のようにTLDファイルとimplicit.tldのバージョンが異なっていても，常にTLDを使ってタグファイルを使用する場合，または常にJSPからディレクトリを指定して使用する場合は問題なく動作します。

表8‒29　バージョン決定要素のバージョンが異なっている例

バージョン決定要素

バージョン

タグファイルを参照するTLDファイル

2.1

タグファイルを配置しているディレクトリのimplicit.tld

2.0

(7)　タグの属性に指定できる要素について

JSP 2.1仕様では，タグの属性の設定でrtexprvalueがfalseの場合，deferredValueまたはdeferredMethodがtrueのときでも，タグの属性にスクリプティング要素の式を指定できません。

アプリケーションサーバでは，タグの属性の設定でrtexprvalueがfalseの場合でも，deferredValueまたはdeferredMethodがtrueのときは，タグの属性にスクリプティング要素の式を指定できます。アプリケーションサーバでのタグの属性の設定と指定できる要素の対応について，次の表に示します。

表8‒30　タグの属性の設定と指定できる要素の対応

タグの属性の設定

指定できる要素

rtexprvalue

deferredValueまたはdeferredMethod

文字列

式(<%= %>)

EL(${})

EL(#{})

false

false

○

×

×

×

true

false

○

○

○

×

false

true

○

○

×

○

true

true

○

○

○

○

（凡例）○：指定できる　×：指定できない

(8)　エラーページの参照

JSPページのエラー発生時の遷移先としてpageディレクティブのerrorPage属性に自分自身を指定している場合の動作を次に示します。

表8‒31　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など，拡張子だけが異なる同じ名前のタグファイルは配置しないでください。

JSP 2.1仕様では，拡張子だけが異なる同じ名前のタグファイルが配置されている場合，タグライブラリが無効化されます。

アプリケーションサーバでは，拡張子だけが異なる同じ名前のタグファイルが配置されていても，タグライブラリは無効化されません。ただし，タグファイルはファイルシステムから検索されたファイルが使用されます。拡張子だけが異なる同じ名前のタグファイルの場合は，先に検索されたファイルが使用され，ファイルの検索順序については保証されないため，注意してください。

(10)　APIの仕様変更

アプリケーションサーバでは，JSP 2.1仕様でのAPIの仕様変更に従ってAPIの仕様を変更します。

なお，Webアプリケーションのクラスで総称を使用するようになったAPIについて，JSP 2.0以前に準拠しているタイプセーフではないメソッドを使用している場合，メソッドの動作に変更はなく，08-00以降でもそのままクラスを使用できます。なお，コンパイル時にjavacコマンドで警告メッセージ（unchecked warning）が発生するようになりますが，動作に影響する警告メッセージではありません。警告メッセージが発生した原因の個所にアノテーション@SuppressWarnings("unchecked")を適用することで警告メッセージが発生しなくなります。

(11)　JSPページおよびタグファイルの文字エンコーディングの設定方法

アプリケーションサーバでは，JSP 2.1仕様に従って，JSPページ，および標準シンタックスのタグファイルの文字エンコーディングの設定方法にBOMの付加での設定を追加します。

JSPページについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。タグファイルの場合は，タグファイルのバージョンに対応するJSP仕様に従って制御されます。JSPページおよびタグファイルの文字エンコーディングの判別方法について，次の表に示します。

表8‒32　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ファイルおよびタグファイルの文字エンコーディングの詳細は「8.2.7(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のマッピング方法を次の表に示します。

表8‒33　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仕様のバージョンごとに次の表に示します。

表8‒34　#を文字列として表すエスケープシーケンスへの制御

サーブレット仕様/JSP仕様のバージョン

仕様

ELの設定を有効にしている場合

ELの設定を無効にしている場合

¥$の出力

¥#の出力

¥$の出力

¥#の出力

Servlet 2.5/JSP 2.1

$

#

$

#

Servlet 2.4/JSP 2.0

$

¥#

$

¥#

Servlet 2.5仕様に準拠したWebアプリケーションの場合，"¥#"は"¥$"と同様に条件に関係なくエスケープシーケンスによって#と出力されます。そのため，"¥#"と出力したい場合は，"¥¥#"と記述する必要があります。

JSP 2.0仕様の"¥$"のエスケープシーケンスの仕様については「8.2.10(15)　EL（Expression Language）のエスケープシーケンスについて」を参照してください。

(14)　ELでのEnum型に対する処理の変更

JSP 2.1仕様のELから，Java SE 5仕様で規定されたEnum型のオブジェクトに対応した処理が追加されました。

JSPページおよびJSPドキュメントについては，Webアプリケーションが準拠するJSP仕様に従って制御されます。タグファイルの場合は，タグファイルのバージョンに対応するJSP仕様に従って制御されます。

アプリケーションサーバでのサーブレットおよびJSP仕様のバージョンごとのELでのEnum型に対する処理について，次の表に示します。

表8‒35　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仕様のバージョンごとに次の表に示します。

表8‒36　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が評価されます。

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

JSP 2.0仕様で追加，変更された仕様を，アプリケーションサーバ上で利用するときの注意事項を示します。JSP 2.0仕様およびJSP 1.2仕様については，それぞれの仕様書（JSP 2.0仕様書，JSP 1.2仕様書）を参照してください。

(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で動作する場合の"¥$"の出力結果を次の表に示します。

表8‒37　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コンテナでは，JSP 1.2で動作する場合でも"¥"は制御コードとして扱われるため，"$"と出力されます。ただし，JSPドキュメント形式の属性値で使用する場合は，"¥$"と出力されます。

JSP 1.2で動作する場合の"¥$"の出力結果を次の表に示します。

表8‒38　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に変換されます。

8.2.11　JSP 1.2仕様のJSP実装時の注意事項

JSP 1.2仕様でJSPを実装する場合の注意事項について説明します。JSP 2.0以降のJSPを実装する場合は，該当しません。

(1)　JSPドキュメント利用時の注意事項

JSPドキュメントを利用するときの注意事項を次に示します。

JSPドキュメントでは，<jsp:root>タグのxmlns:jsp属性にJSP 1.2仕様で規定された正しい値を指定してください。JSP 1.2仕様で規定された値以外を指定した場合，無視されます。

JSPドキュメントの<jsp:root>タグのversion属性には，必ず「1.2」を指定してください。

JSPドキュメントでは，タグの属性にJSP 1.2仕様で規定された正しい属性だけを指定してください。タグに不正な属性を指定した場合，無視されます。

JSPドキュメントでは，JSP 1.2仕様で必須と規定されているタグの属性は必ず指定してください。必須と規定されている属性を省略した場合の動作は保証されません。

JSPドキュメントで，子タグとして使用できないタグを子タグとして記述しないでください。子タグとして使用できないタグを子タグとして記述した場合の動作は保証されません。

文字エンコーディングがUTF-8でBOMが付加されたJSPドキュメントは使用できません。JSPドキュメントの文字エンコーディングにUTF-8を使用する場合，BOMは付加しないでください。JSPドキュメントの文字エンコーディングがUTF-8であり，BOMが付加されている場合，JSPコンパイル時にエラーとなります。

(2)　pageディレクティブのpageEncoding属性利用時の注意事項

JSPページのpageディレクティブまたはJSPドキュメントの<jsp:directive.page>タグのpageEncoding属性は正しい値を一度だけ記述してください。

ただし，JSPページのpageディレクティブまたはJSPドキュメントの<jsp:directive.page>タグのpageEncoding属性を複数記述した場合でも，エラーにはなりません。

(3)　標準アクション利用時の注意事項

JSP 1.2仕様で規定されたタグ以外の「jsp:」で始まるタグは記述できません。

(4)　カスタムタグ利用時の注意事項

タグ内に同一の属性を複数定義しないでください。JSPページでは，タグ内に同一の属性を複数定義した場合の動作は保証されません。

(5)　タグライブラリ利用時の注意事項

プロパティにwebserver.xml.validate=falseを設定した場合，タグライブラリ・ディスクリプタ（TLDファイル）の検証は実施されません。仕様（XMLのスキーマ定義）に従っていないTLDファイルを使用した場合，エラーとならないで動作することがありますが，動作は保証されません。

TLDファイルは仕様（XMLのスキーマ定義）に従って正しく記述してください。

(6)　pluginアクション利用時の注意事項

JSPページでのpluginアクションまたはJSPドキュメントでの<jsp:plugin>タグのtype属性に，JSP 1.2仕様で規定された値以外は指定しないでください。JSP 1.2仕様で規定された値以外を指定すると，出力されるtype属性の値が空文字列となります。

(7)　paramsアクション利用時の注意事項

必須タグとして<jsp:param>タグ要素を記述するように規定されているため，paramsアクションを記述した場合，または<jsp:params>タグを記述した場合は，必ず<jsp:param>タグ要素を記述してください。

ただし，JSPドキュメントのJSPページでparamsアクションを記述した場合，またはJSPドキュメントの<jsp:params>タグを記述した場合に，<jsp:param>タグ要素を記述していないときでも，エラーにはなりません。

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

Servlet 2.5仕様に対応したWebアプリケーションをServlet 3.0仕様にバージョンアップする場合に必要な作業，および注意事項を示します。なお，Servlet 3.0仕様の詳細については，Servlet 3.0仕様書を参照してください。

(1)　Servlet 3.0仕様，およびJSP 2.2仕様で追加された仕様，および変更された仕様について

Servlet 3.0仕様で追加，変更された仕様についての注意事項については，「8.2.4　Servlet 3.0/3.1仕様で追加，変更された仕様についての注意事項」を参照してください。

JSP 2.2仕様で追加された仕様はサポートされません。ただし，JSP 2.2のweb.xmlのスキーマには対応するため，web.xmlにJSP 2.2で追加されたタグを追加してもエラーとなりません。追加されたタグは無視されます。

(2)　web.xmlの移行について

web.xmlは，Servlet 3.0仕様に従った定義に修正します。詳細はJava Servlet Specification v3.0を参照してください。また，仕様変更については「8.2.4　Servlet 3.0/3.1仕様で追加，変更された仕様についての注意事項」を参照してください。

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

Servlet 2.4仕様に対応したWebアプリケーションをServlet 2.5仕様にバージョンアップする場合に必要な作業，および注意事項を示します。なお，Servlet 2.5仕様の詳細については，Servlet 2.5仕様書を参照してください。

(1)　Servlet 2.5仕様，およびJSP 2.1仕様で追加された仕様，および変更された仕様について

Servlet 2.5仕様およびJSP 2.1仕様で追加，変更された仕様についての注意事項については，それぞれ「8.2.5　Servlet 2.5仕様で追加，変更された仕様についての注意事項」または「8.2.9　JSP 2.1仕様で追加，変更された仕様についての注意事項」を参照してください。

(2)　web.xmlの移行について

web.xmlは，Servlet 2.5仕様に従った定義に修正します。詳細はJava Servlet Specification v2.5を参照してください。また，仕様変更については「8.2.5　Servlet 2.5仕様で追加，変更された仕様についての注意事項」を参照してください。

(3)　JSPから生成するクラスのサイズについて

Servlet 2.5仕様に準拠したWebアプリケーションに含まれるJSPから生成したクラスは，JSP 2.1仕様の機能が適用されるようになります。そのため，JSPから生成したJavaソースファイル，クラスファイルの内容が変わります。

この場合，Javaソースファイルの行数，JSPから生成したクラスに含まれるメソッドのサイズ，またはMetaspace領域の使用量が増加することがあるため，注意してください。

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

前バージョンからV11へ移行する場合の，Webアプリケーションに関する注意事項を示します。

(1)　Webコンテナがサポートするバージョン情報取得API

次の表に示すServlet APIでは，WebコンテナがサポートするServlet仕様のバージョン情報を取得できます。

表8‒39　Webコンテナがサポートするバージョン情報取得API

クラス名

メソッド名

javax.servlet.ServletContext

getMajorVersion

getMinorVersion

javax.servlet.jsp.JspEngineInfo

getSpecificationVersion

WebアプリケーションのバージョンがServlet 3.0/JSP 2.0以前であっても，WebコンテナがサポートするServlet仕様のバージョンは，Servlet 3.1/JSP 2.1となります。そのため，これらのServlet APIはServlet仕様のバージョンとしてServlet 3.1/JSP 2.1の情報を返します。

(2)　リクエストパラメタ数の上限値の変更

リクエストパラメタ数の上限値が09-00より前のバージョンと09-00以降で異なります。バージョンごとの動作の差異を次に示します。

09-00以降

リクエストパラメタ数の上限値は2,147,483,647個です。デフォルトは10,000個です。

09-00より前

リクエストパラメタ数の上限値を設定しません。

09-00より前のバージョンから09-00以降へアップグレードインストールした場合，セットアップ済のJ2EEサーバの設定に，次のパラメタの設定を追加することで，09-00より前のバージョンと同様の動作になります。

webserver.connector.limit.max_parameter_count=-1

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

Servlet 2.2仕様またはServlet 2.3仕様に対応したWebアプリケーションをServlet 2.4仕様にバージョンアップする場合に必要な作業，および注意事項を示します。なお，Servlet 2.4仕様の詳細については，Servlet 2.4仕様書を参照してください。

(1)　web.xmlの移行

Servlet 2.2仕様またはServlet 2.3仕様に従って作成したweb.xmlは，Servlet 2.4仕様に従った定義に修正します。Servlet 2.4仕様で変更された点については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」の「5.2.5　Servlet 2.4以降で追加，変更された仕様についての注意事項（web.xml）」を参照してください。

(2)　Servlet 2.4仕様に対応したコードへの修正

Servlet 2.4仕様では，Servlet 2.2仕様およびServlet 2.3仕様から仕様が追加，変更されています。追加，変更された点を確認し，Servlet 2.4仕様に対応したコードに修正してください。

また，JSP 2.0仕様でもJSP 1.2仕様から仕様が追加，変更されています。追加，変更された点を確認し，JSP 2.0仕様に対応したコードに修正してください。JSP 2.0仕様で追加，変更された点については，「8.2.10　JSP 2.0仕様で追加，変更された仕様についての注意事項」を参照してください。

(3)　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事前コンパイルの方法」を参照してください。

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

アプリケーションサーバでは，サーブレットでアノテーションを使用できます。アプリケーションサーバが対応しているアノテーションについては，マニュアル「アプリケーションサーバ リファレンス API編」の「2.　アプリケーションサーバで使用するアノテーションおよびDependency Injection」を参照してください。

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

JavaVMでは，64KBを超えるメソッドが存在すると，クラスファイル生成時にエラーとなるか，クラスのロード時にjava.lang.LinkageError例外が発生します。そのため，1メソッドのバイトコードは64KB以内のサイズにする必要があります。

また，64KB以内であっても，非常に大きいサイズのメソッドが存在する場合は，次のような弊害が発生するおそれがあります。

GC処理の実行に非常に時間が掛かる。

JITコンパイルに非常に時間が掛かる。

JITコンパイルに非常に多くのメモリを消費する。

クラスのロード処理に非常に時間が掛かる。

クラスのロード処理で一時的に非常に多くのMetaspace領域を消費する。

Webアプリケーションでは，自動生成されるjavaソースコードによって，1メソッドのバイトコードが64KBを超える場合があります。javaソースコードの自動生成と，メソッドサイズが大きい場合の見直し方法について説明します。

(1)　javaソースコードの自動生成

javaソースコードの自動生成について説明します。

JSP仕様での自動生成

JSP仕様では，JSPファイル，またはタグファイルに記述した内容から，_jspServiceメソッドまたはdoTagメソッド内にjavaソースコードが自動生成されます。

アプリケーションサーバでのカスタムタグ使用時の自動生成

アプリケーションサーバでは，カスタムタグを使用している場合，カスタムタグの処理やボディに記述した内容がメソッド化され，javaソースコードが自動生成されます。

なお，カスタムタグをメソッド化できるのは，カスタムタグの処理またはボディに含まれるすべてのカスタムタグが次の条件を満たす場合です。

属性やボディがスクリプトレスである。

スクリプト変数を定義していない。

(2)　メソッドサイズが大きい場合の見直し方法

自動生成されたjavaソースコードのメソッドの行数が，コメントおよび空行を含めて1000行を超える場合，KDJE39231-WおよびKDJE39333-Wのメッセージが出力されます。

メッセージが出力された場合は，JSPファイル，タグファイル，またはカスタムタグのボディの内容を見直してください。

見直す個所ごとに，見直す方法を次に示します。

JSPファイルの内容のサイズが大きい場合

動的インクルード（インクルードアクション）でJSPファイルを分割する。

タグファイルの内容のサイズが大きい場合

次のどちらかを実施します。

JSPファイルから使用するタグファイルを複数のタグファイルに分割する。

タグファイルから別のタグファイルを呼び出すように分割する。

カスタムタグのボディのサイズが大きい場合

動的インクルード（インクルードアクション）でカスタムタグを分割する。

付録

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

ここでは，Webコンテナ，HTTP Server，およびNIO HTTPサーバが返すエラーステータスコードについて示します。

使用するWebサーバによって，エラーが発生する個所が異なります。エラーが発生する個所に応じたエラーステータスコードを参照してください。使用するWebサーバとエラーが発生する個所の対応について次の表に示します。

表A‒1　使用するWebサーバとエラーが発生する個所の対応

使用するWebサーバ

エラーが発生する個所

Webコンテナ

HTTP Server

NIO HTTPサーバ

HTTP Server

○

○

○

NIO 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でアクセスされた場合

404　Not Found

次のどちらかのアクセスがあった場合，エラーステータスコード404が返ります。

存在しないリソースにアクセスされた場合

javax.servlet.UnavailableExceptionが発生しているサーブレット，またはJSPファイルにアクセスされた場合※2

405　Method Not Allowed

次の三つの条件をすべて満たしているアクセスの場合，エラーステータスコード405が返ります。

HTTPのバージョンが"HTTP/1.1"の場合

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承している場合

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていない場合

JSPにGET，POST，HEAD，OPTION以外のメソッドでアクセスがあった場合，エラーステータスコード405が返ります※8。

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ファイルにアクセスされた場合※3

コンパイルに失敗したJSPファイルにアクセスされた場合

削除された静的コンテンツにアクセスされた場合※4

静的コンテンツへのアクセスでI/Oエラーが発生した場合

web.xmlの定義が不正な状態で，<auth-constraint>要素で保護されたリソースにアクセスされた場合※5

501　Not Implemented

静的コンテンツまたはjavax.servlet.http.HttpServletを継承したサーブレットに対して，GET，HEAD，POST，PUT，DELETE，OPTIONS，TRACEメソッド以外のHTTPメソッドでアクセスされた場合，エラーステータスコード501が返ります。

503　Service Unavailable

次のどれかに該当する場合，エラーステータスコード503が返ります。

リクエストの実行待ちキューに空きがない場合※6

javax.servlet.UnavailableExceptionが発生しているサーブレットまたはJSPファイルにアクセスされた場合※7

終了処理中のWebコンテナに対してアクセスされた場合

予期しないエラーまたは例外によって，異常な状態になったWebアプリケーションにアクセスされた場合

Webコンテナサーバで，Webコンテナサーバだけが起動して，Webアプリケーションが起動していない場合に，起動しなかったWebアプリケーションにアクセスされたとき

注※1　Webアプリケーションのバージョンが2.4以降の場合に該当します。

注※2　Webアプリケーションのバージョンが2.4以降の場合で，永久的に利用できないことを示すjavax.servlet.UnavailableExceptionが発生し，サーブレットおよびJSPファイルで例外をcatchしていないときが該当します。

注※3　次のような場合が該当します。

Webアプリケーションのバージョンが2.4以降の場合

サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合

web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

注※4　Webアプリケーションのリロード機能，JSPファイルの再コンパイル機能，またはJ2EEアプリケーションのリロード機能を使用しない場合が該当します。

注※5　web.xmlで<auth-constraint>要素に<role-name>要素が定義され，<login-config>要素が定義されていない場合に該当します。この状態でアプリケーションを開始すると，KDJE39150-Wの警告メッセージがコンソール画面，およびメッセージログに出力されます。

注※6　Webアプリケーション単位の同時実行スレッド数制御，またはURLグループ単位の同時実行スレッド数制御を設定している場合が該当します。

注※7　次のような場合が該当します。

Webアプリケーションのバージョンが2.4以降の場合

一時的に利用できないことを示す，javax.servlet.UnavailableExceptionが発生し，サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合

web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

注※8　Webアプリケーションのバージョンが3.1以降の場合が該当します。

付録A.2　HTTP Serverが返すエラーステータスコード

マニュアル「Cosminexus HTTP Server」の「付録A　ステータスコード」を参照してください。

付録A.3　NIO HTTPサーバが返すエラーステータスコード

クライアントからのリクエストのサイズが上限値を超えたり，値が不正だったりした場合，NIO HTTPサーバはエラーステータスコードを返します。NIO HTTPサーバが返すエラーステータスコードとエラーステータスコードを返す条件を次の表に示します。

表A‒3　NIO HTTPサーバが返すエラーステータスコードと条件

エラーステータスコード

エラーステータスコードを返す条件

400　Bad Request

リクエストの状態が次のどれかの場合，エラーステータスコード400が返ります。

リクエストのHostヘッダが複数指定されている場合

リクエストのHostヘッダがリクエストラインに指定されたホストと一致しない場合

リクエストのHTTPバージョンが1.1かつHostヘッダがない場合

リクエストのHostヘッダのポート番号が不正な場合

リクエストURIが不正な場合

リクエストヘッダのサイズが上限値を超えた場合

リクエストヘッダの数が上限値を超えた場合

リクエストURIのデコードに失敗した場合

リクエストURIを正規化できなかった場合

404　Not Found

リクエストの状態が次のどちらかの場合，エラーステータスコード404が返ります。

存在しないリソースにアクセスした場合

ejbまたはwebが先頭となるようなURLにアクセスした場合

405　Method Not Allowed

次の条件をすべて満たす場合，エラーステータスコード405が返ります。

HTTPのバージョンが"HTTP/2"

アクセス対象がjavax.servlet.http.HttpServletを継承したサーブレット

アクセス時のHTTPメソッドが当該サーブレットにてオーバライドされていない

413　Request entity too large

リクエストボディのサイズが上限値を超えた場合，エラーステータスコード413が返ります（リクエストのtransfer-encodingがchunkedの場合を除く）。

417　Expectation Failed

リクエストのexpectヘッダの値が「100-continue」以外の場合，エラーステータスコード417が返ります。

500　Internal Server Error

リクエストの状態が次のどれかの場合，エラーステータスコード500が返ります。

非同期サーブレットやノンブロッキングIOのReadListener,WriteListenerで例外が発生した場合

リクエストのContent-Lengthヘッダの値が数値以外の場合

リクエストのContent-Lengthヘッダが複数指定されている場合

501　Not implemented

リクエストのtransfer-encodingヘッダの値がサポートされていない場合，エラーステータスコード501が返ります。

503　Service Unavailable

流量制御の上限を超えてリクエスト処理を実行しようとした場合（同期だけ），エラーステータスコード503が返ります。

505　HTTP Version Not Supported

リクエストラインのHTTPバージョンがサポートされていない場合，エラーステータスコード505が返ります。

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

ここでは，11-50よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。11-50での主な機能変更については，「1.4　アプリケーションサーバ 11-50での主な機能変更」を参照してください。

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

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

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

付録B.1　11-40での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

Java SE 17への対応

Java SE 17の機能が使用できるようになりました。

システム設計ガイド

2.1

機能解説 保守／移行編

9章

メモリ管理方式にZGCを追加

メモリ管理方式にZGCを追加しました。

システム設計ガイド

7.17

接続できるデータベースにAzure SQL Databaseを追加

DB Connectorを使用して接続できるデータベースにAzure SQL Databaseを追加しました。

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

3.6.18

付録B.2　11-30での主な機能変更

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

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

表B‒2　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC4.3への対応

JDBC4.3に対応しました。

アプリケーションサーバ & BPM/ESB基盤 概説

4.6.2

接続できるデータベースにMySQL，PostgreSQLを追加

DB Connectorを使用して接続できるデータベースに，MySQL，PostgreSQLを追加しました。

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

3.6

パッケージ名変換機能の追加

jakartaパッケージ名を前提とするアプリケーションをアプリケーションサーバで動作させる機能を追加しました。

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

20章

付録B.3　11-20での主な機能変更

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

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

表B‒3　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSF 2.3への対応

JSF 2.3に対応しました。

このマニュアル

3章

JAX-RS 2.1への対応

JAX-RS 2.1に対応しました。

このマニュアル

4章

WebSocket 1.1への対応

WebSocket 1.1に対応しました。

このマニュアル

5章

Servlet 4.0への対応

Servlet 4.0に対応しました。これに伴い，NIO HTTPサーバでHTTP/2に対応しました。

このマニュアル

8章

CDI Managed BeanでのJPA利用

CDI Managed BeanでのJPA利用に対応しました。

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

5章

JPA 2.2への対応

JPA 2.2に対応しました。

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

6章

CDI 2.0への対応

CDI 2.0に対応しました。

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

9章

WEB-INF/lib内のCDIへの対応

WARファイルのWEB-INF/lib以下のJARファイルからCDIを利用できるようにしました。

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

9章

BV 2.0への対応

BV 2.0に対応しました。

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

10章

JSON-P 1.1への対応

JSON-P 1.1に対応しました。

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

12章

JSON-B 1.0への対応

JSON-B 1.0に対応しました。

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

13章

付録B.4　11-10での主な機能変更

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

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

表B‒4　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ライブラリ競合回避機能の追加

クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能を追加しました。

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

付録B.4

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

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

表B‒5　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSP 2.3への対応

JSP 2.3に対応しました。

このマニュアル

8章

コンテナ管理のEntityManagerへの対応

JPA 2.1に対応したコンテナ管理のEntityManagerに対応しました。

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

5章

Interceptors 1.2への対応

Interceptors 1.2に対応しました。

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

15章

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

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

表B‒6　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッションマネージャの指定機能の追加

クラウド環境利用時にHTTPセッションのセッションフェイルオーバを利用できるようにする機能を追加しました。

このマニュアル

2.22

付録B.5　11-00での主な機能変更

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

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

表B‒7　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

開発環境のWindows Server対応

クラウド環境上にアプリケーション開発環境を構築できるよう，uCosminexus DeveloperのサポートOSにWindows Server OSを追加しました。

−

−

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

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

表B‒8　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0/3.1への対応

Servlet 3.0の非同期サーブレット，およびServlet 3.1の非同期I/O系APIに対応しました。

このマニュアル

8.1

EL 3.0への対応

EL 3.0に対応しました。

このマニュアル

2.3.3

JSF 2.2への対応

JSF 2.2に対応しました。

このマニュアル

3章

JAX-RS 2.0への対応

JAX-RS 2.0に対応しました。

このマニュアル

4章

WebSocket 1.0への対応

WebSocket 1.0に対応しました。

このマニュアル

5章

NIO HTTPサーバ機能の追加

従来のリダイレクタ機能やインプロセスHTTPサーバ機能に代わり，非同期サーブレットやWebSocketなどのノンブロッキングI/O処理に対応したインプロセスのHTTPサーバとして，NIO HTTPサーバ機能を追加しました。

このマニュアル

7章

JPA 2.1への対応

JPA 2.1に対応し，JPA 2.1対応のJPAプロバイダを利用できるようになりました。

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

6章

CDI 1.2への対応

CDI 1.2に対応しました。

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

9章

BV 1.1への対応

Bean Validation 1.1に対応しました。

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

10章

Java Batch 1.0への対応

Batch Applications for the Java Platform （Java Batch） 1.0に対応しました。

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

11章

JSON-P 1.0への対応

Java API for JSON Processing（JSON-P） 1.0に対応しました。

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

12章

Concurrency Utilities 1.0への対応

Concurrency Utilities for Java EE 1.0に対応しました。

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

14章

WebSocket通信への対応

HTTP ServerからJ2EEサーバにWebSocket通信を中継する機能を追加しました。

HTTP Server

4.15

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

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

表B‒9　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

暗号化通信モジュールの変更

HTTP Serverの暗号化通信モジュールとしてmod_sslを採用しました。

HTTP Server

5章，付録D

(4)　そのほかの目的

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

表B‒10　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

V9互換モードの追加

Version 9以前のJ2EEサーバから移行するユーザ向けに，Version 9との互換性を維持するためのV9互換モードを追加しました。

機能解説 保守／移行編

10.3.4

付録B.6　09-87での主な機能変更

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

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

表B‒11　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Java SE 11への対応

Java SE 11の機能が使用できるようになりました。

機能解説 保守／移行編

9章

付録B.7　09-80での主な機能変更

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

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

表B‒12　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JAX-RS機能におけるラムダ式の使用

web.xmlのサーブレット初期化パラメタに指定したパッケージとそのサブパッケージに含まれるクラスで，ラムダ式が使用できるようになりました。

Webサービス開発ガイド

11.2

Java SE 9への対応

Java SE 9の機能が使用できるようになりました。

機能解説 保守／移行編

9章

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

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

表B‒13　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

WebサーバのApache2.4のサポート

WebサーバのベースバージョンとしてApache2.4をサポートしました。

HTTP Server

6章，付録C

SSL通信での楕円曲線暗号の利用

楕円曲線暗号を利用したSSL通信ができるようになりました。

HTTP Server

5章，付録C

SSLライブラリの変更

SSL機能を提供するSSLライブラリをOpenSSLに変更しました。

HTTP Server

5章，付録C

付録B.8　09-70での主な機能変更

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

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

表B‒14　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのJSPコンパイルバージョンの追加

J2EEサーバでのJSPから生成されたサーブレットのコンパイル方法に「JDK1.7の仕様に従ったコンパイル」と「JDK7の仕様に従ったコンパイル」を追加する。

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

10.8.4

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

4.11.2

JDK8でのメタスペース対応

JavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する。

システム構築・運用ガイド

付録A.2

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

10.8.7

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

5.2.1，5.2.2，8.2.3

統合ユーザ管理でのユーザ認証のSHA-2対応

統合ユーザ管理でのユーザ認証のハッシュアルゴリズムとしてSHA-224，SHA-256，SHA-384，SHA-512を追加する。

機能解説 セキュリティ管理機能編

5.3.1，5.3.9，5.10.7，11.4.3，12.4.3，12.5.3，13.2，14.2.2

Red Hat Enterprise Linux Server 7での自動起動と自動再起動および自動停止の追加

Red Hat Enterprise Linux Server 7でのManagement Serverと運用管理エージェントの自動起動と自動再起動および自動停止方法を追加する。

機能解説 運用／監視／連携編

2.6.3，2.6.4，2.6.5

リファレンス コマンド編

7.2

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

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

表B‒15　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

V9.7へのバージョンアップ対応

バージョンアップ時のJavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する手順を追加する。

機能解説 保守／移行編

10.3.1，10.3.2，10.3.5

(3)　そのほかの目的

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

表B‒16　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

snapshotログの収集対象

snapshotログの収集対象としてJavaVMイベントログとManagement Serverのスレッドダンプを追加する。

機能解説 保守／移行編

付録A.2

付録B.9　09-60での主な機能変更

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

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

表B‒17　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

G1GCへの対応

G1GCを選択できるようになりました。

システム設計ガイド

7.15

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

14.5

圧縮オブジェクトポインタ機能への対応

圧縮オブジェクトポインタ機能を使用できるようになりました。

機能解説 保守／移行編

9.18

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

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

表B‒18　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ファイナライズ滞留解消機能の追加

ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できるようになりました。

機能解説 保守／移行編

9.16

(3)　そのほかの目的

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

表B‒19　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログファイルの非同期出力機能の追加

ログのファイル出力を非同期でできるようになりました。

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

14.2

付録B.10　09-50での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表B‒20　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Eclipseセットアップの簡略化

GUIを利用してEclipse環境をセットアップできるようになりました。

アプリケーション開発ガイド

1.1.5，2.4

ユーザ拡張性能解析トレースを使ったデバッグ支援

ユーザ拡張性能解析トレース設定ファイルを開発環境で作成できるようになりました。

アプリケーション開発ガイド

1.1.3，6.4

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

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

表B‒21　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのシステム構成パターンの拡充

仮想化環境で使用できるティアの種類（http-tier，j2ee-tierおよびctm-tier）が増えました。これによって，次のシステム構成パターンが構築できるようになりました。

WebサーバとJ2EEサーバを別のホストに配置するパターン

フロントエンド（サーブレット，JSP）とバックエンド（EJB）を分けて配置するパターン

CTMを使用するパターン

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

1.1.2

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

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

表B‒22　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC 4.0仕様への対応

DB ConnectorでJDBC 4.0仕様のHiRDB Type4 JDBC Driver，およびSQL ServerのJDBCドライバに対応しました。

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

3.6.3

Portable Global JNDI名での命名規則の緩和

Portable Global JNDI名に使用できる文字を追加しました。

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

2.4.3

Servlet 3.0仕様への対応

Servlet 3.0のHTTP Cookieの名称，およびURLのパスパラメタ名の変更が，Servlet 2.5以前のバージョンでも使用できるようになりました。

このマニュアル

2.7

Bean Validationと連携できるアプリケーションの適用拡大

CDIやユーザアプリケーションでもBean Validationを使って検証できるようになりました。

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

10章

JavaMailへの対応

JavaMail 1.4に準拠したAPIを使用したメール送受信機能を利用できるようになりました。

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

8章

javacoreコマンドが使用できるOSの適用拡大

javacoreコマンドを使って，Windowsのスレッドダンプを取得できるようになりました。

リファレンス コマンド編

javacore（スレッドダンプの取得／Windowsの場合）

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

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

表B‒23　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

コードキャッシュ領域の枯渇回避

システムで使用しているコードキャッシュ領域のサイズを確認して，領域が枯渇する前にしきい値を変更して領域枯渇するのを回避できるようになりました。

システム設計ガイド

7.2.6

機能解説 保守／移行編

5.7.2，5.7.3

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

14.1，14.2，14.4

明示管理ヒープ機能の効率的な適用への対応

自動解放処理時間を短縮し，明示管理ヒープ機能を効率的に適用するための機能として，Explicitヒープに移動するオブジェクトを制御できる機能を追加しました。

Explicitメモリブロックへのオブジェクト移動制御機能

明示管理ヒープ機能適用除外クラス指定機能

Explicitヒープ情報へのオブジェクト解放率情報の出力

システム設計ガイド

7.14.6

機能解説 拡張編

7.2.2，7.6.5，7.10，7.13.1，7.13.3

機能解説 保守／移行編

5.5

クラス別統計情報の出力範囲拡大

クラス別統計情報を含んだ拡張スレッドダンプに，staticフィールドを基点とした参照関係を出力できるようになりました。

機能解説 保守／移行編

9.6

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

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

表B‒24　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

EADsセッションフェイルオーバ機能のサポート

EADsと連携してセッションフェイルオーバ機能を実現するEADsセッションフェイルオーバ機能をサポートしました。

機能解説 拡張編

5章

WARによる運用

WARファイルだけで構成されたWARアプリケーションをJ2EEサーバにデプロイできるようになりました。

このマニュアル

2.2.1

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

18.9

リファレンス コマンド編

cjimportwar（WARアプリケーションのインポート）

運用管理機能の同期実行による起動と停止

運用管理機能（Management Serverおよび運用管理エージェント）の起動および停止を，同期実行するオプションを追加しました。

機能解説 運用／監視／連携編

2.6.1，2.6.2，2.6.3，2.6.4

リファレンス コマンド編

adminagentctl（運用管理エージェントの起動と停止），mngautorun（自動起動および自動再起動の設定／設定解除），mngsvrctl（Management Serverの起動／停止／セットアップ）

明示管理ヒープ機能でのExplicitメモリブロックの強制解放

javagcコマンドで，Explicitメモリブロックの解放処理を任意のタイミングで実行できるようになりました。

機能解説 拡張編

7.6.1，7.9

リファレンス コマンド編

javagc（GCの強制発生）

(6)　そのほかの目的

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

表B‒25　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

定義情報の取得

snapshotlog（snapshotログの収集）コマンドで定義ファイルだけを収集できるようになりました。

機能解説 保守／移行編

2.3

リファレンス コマンド編

snapshotlog（snapshotログの収集）

cjenvsetupコマンドのログ出力

Component Container管理者のセットアップ（cjenvsetupコマンド）の実行情報がメッセージログに出力されるようになりました。

システム構築・運用ガイド

4.1.4

機能解説 保守／移行編

4.20

リファレンス コマンド編

cjenvsetup（Component Container管理者のセットアップ）

BIG-IP v11のサポート

使用できる負荷分散機の種類にBIG-IP v11が追加になりました。

システム構築・運用ガイド

4.7.2

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

2.1

明示管理ヒープ機能のイベントログへのCPU時間の出力

Explicitメモリブロック解放処理に掛かったCPU時間が，明示管理ヒープ機能のイベントログに出力されるようになりました。

機能解説 保守／移行編

5.11.3

ユーザ拡張性能解析トレースの機能拡張

ユーザ拡張性能解析トレースで，次の機能を追加しました。

トレース対象の指定方法を通常のメソッド単位の指定方法に加えて，パッケージ単位またはクラス単位で指定できるようになりました。

使用できるイベントIDの範囲を拡張しました。

ユーザ拡張性能解析トレース設定ファイルに指定できる行数の制限を緩和しました。

ユーザ拡張性能解析トレース設定ファイルでトレース取得レベルを指定できるようになりました。

機能解説 保守／移行編

7.5.2，7.5.3，8.25.1

Session Beanの非同期呼び出し使用時の情報解析向上

PRFトレースのルートアプリケーション情報を使用して，呼び出し元と呼び出し先のリクエストを突き合わせることができるようになりました。

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

2.17.3

付録B.11　09-00での主な機能変更

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

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

表B‒26　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境での構築・運用の操作対象単位の変更

仮想化環境の構築・運用時の操作対象単位が仮想サーバから仮想サーバグループへ変更になりました。仮想サーバグループの情報を定義したファイルを使用して，複数の仮想サーバを管理ユニットへ一括で登録できるようになりました。

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

1.1.2

セットアップウィザードによる構築環境の制限解除

セットアップウィザードを使用して構築できる環境の制限が解除されました。ほかの機能で構築した環境があってもアンセットアップされて，セットアップウィザードで構築できるようになりました。

システム構築・運用ガイド

2.2.7

構築環境の削除手順の簡略化

Management Serverを使用して構築したシステム環境を削除する機能（mngunsetupコマンド）の追加によって，削除手順を簡略化しました。

システム構築・運用ガイド

4.1.37

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

3.6，5.4

リファレンス コマンド編

mngunsetup（Management Serverの構築環境の削除）

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

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

表B‒27　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0への対応

Servlet 3.0に対応しました。

このマニュアル

8章

EJB 3.1への対応

EJB 3.1に対応しました。

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

2章

JSF 2.1への対応

JSF 2.1に対応しました。

このマニュアル

3章

JSTL 1.2への対応

JSTL 1.2に対応しました。

このマニュアル

3章

CDI 1.0への対応

CDI 1.0に対応しました。

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

9章

Portable Global JNDI名の利用

Portable Global JNDI名を利用したオブジェクトのルックアップができるようになりました。

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

2.4

JAX-WS 2.2への対応

JAX-WS 2.2に対応しました。

Webサービス開発ガイド

1.1，16.1.5，16.1.7，16.2.1，16.2.6，16.2.10，16.2.12，16.2.13，16.2.14，16.2.16，16.2.17，16.2.18，16.2.20，16.2.22，19.1，19.2.3，37.2，37.6.1，37.6.2，37.6.3

JAX-RS 1.1への対応

JAX-RS 1.1に対応しました。

Webサービス開発ガイド

1.1，1.2.2，1.3.2，1.4.2，1.5.1，1.6，2.3，11章，12章，13章，17章，24章，39章

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

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

表B‒28　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

SSL/TLS通信でのTLSv1.2の使用

RSA BSAFE SSL-Jを使用して，TLSv1.2を含むセキュリティ・プロトコルでSSL/TLS通信ができるようになりました。

−

−

（凡例）−：09-70で削除された機能です。

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

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

表B‒29　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webコンテナ全体の実行待ちキューの総和の監視

Webコンテナ全体の実行待ちキューの総和を稼働情報に出力して監視できるようになりました。

機能解説 運用／監視／連携編

3章

アプリケーションの性能解析トレース（ユーザ拡張トレース）の出力

ユーザが開発したアプリケーションの処理性能を解析するための性能解析トレースを，アプリケーションの変更をしないで出力できるようになりました。

機能解説 保守／移行編

7章

仮想化環境でのユーザスクリプトを使用した運用

任意のタイミングでユーザ作成のスクリプト（ユーザスクリプト）を仮想サーバ上で実行できるようになりました。

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

7.8

運用管理ポータル改善

運用管理ポータルの次の画面で，手順を示すメッセージを画面に表示するように変更しました。

［設定情報の配布］画面

Webサーバ，J2EEサーバおよびSFOサーバの起動画面

WebサーバクラスタとJ2EEサーバクラスタの一括起動，一括再起動および起動画面

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

10.10.1，11.9.2，11.10.2，11.10.4，11.10.6，11.11.2，11.12.2，11.12.4，11.12.6

運用管理機能の再起動機能の追加

運用管理機能（Management Serverおよび運用管理エージェント）で自動再起動が設定できるようになり，運用管理機能で障害が発生した場合でも運用が継続できるようになりました。また，自動起動の設定方法も変更になりました。

機能解説 運用／監視／連携編

2.4.1，2.4.2，2.6.3，2.6.4

リファレンス コマンド編

mngautorun（自動起動および自動再起動の設定／設定解除）

(5)　そのほかの目的

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

表B‒30　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログ出力時のファイル切り替え単位の変更

ログ出力時に，日付ごとに出力先のファイルを切り替えられるようになりました。

機能解説 保守／移行編

3.2.1

Webサーバの名称の変更

アプリケーションサーバに含まれるWebサーバの名称をHTTP Serverに変更しました。

HTTP Server

−

BIG-IPのAPI（SOAPアーキテクチャ）を使用した直接接続への対応

BIG-IP（負荷分散機）でAPI（SOAPアーキテクチャ）を使用した直接接続に対応しました。

また，APIを使用した直接接続を使用する場合に，負荷分散機の接続環境を設定する方法が変更になりました。

システム構築・運用ガイド

4.7.3，付録J

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

2.1，付録C

機能解説 セキュリティ管理機能編

8.2，8.4，8.5，8.6，18.2.1，18.2.2，18.2.3

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

付録B.12　08-70での主な機能変更

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

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

表B‒31　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータル改善

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

ファーストステップガイド

3.5

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

−

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

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

このマニュアル

2.3.7

仮想化環境でのJP1製品に対する環境設定の自動化対応

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

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

7.7.2

統合ユーザ管理機能の改善

ユーザ情報リポジトリでデータベースを使用する場合に，データベース製品のJDBCドライバを使用して，データベースに接続できるようになりました。DABroker LibraryのJDBCドライバによるデータベース接続はサポート外になりました。

簡易構築定義ファイルおよび運用管理ポータルの画面で，統合ユーザ管理機能に関する設定ができるようになりました。

また，Active Directoryの場合，DNで日本語などの2バイト文字に対応しました。

機能解説 セキュリティ管理機能編

5章，14.2.2

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

3.5，10.8.1

HTTP Server設定項目の拡充

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

システム構築・運用ガイド

4.1.21

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

10.9.1

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

4.10

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

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

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

表B‒32　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ejb-jar.xmlの指定項目の追加

ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。

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

2.15

パラレルコピーガーベージコレクションへの対応

パラレルコピーガーベージコレクションを選択できるようになりました。

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

14.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)　信頼性の維持・向上

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

表B‒33　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

データベースセッションフェイルオーバ機能の改善

性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。

機能解説 拡張編

6章

OutOfMemoryハンドリング機能の対象となる処理の拡大

OutOfMemoryハンドリング機能の対象となる処理を追加しました。

機能解説 保守／移行編

2.5.4

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

14.2

HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加

HTTPセッションで利用するExplicitヒープのメモリ使用量を抑止する機能を追加しました。

機能解説 拡張編

7.11

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

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

表B‒34　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応）

JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。

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

1.2.2，3章，4章，5章，6章，7.9

(5)　そのほかの目的

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

表B‒35　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。

また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3

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

2.1

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

4.2.4

snapshotログ収集時のタイムアウトへの対応と収集対象の改善

snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。

機能解説 保守／移行編

付録A

付録B.13　08-53での主な機能変更

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

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

表B‒36　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築

さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。

また，複数のハイパーバイザが混在する環境にも対応しました。

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

2章，3章，5章

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

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

表B‒37　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

トランザクション連携に対応したOpenTP1からの呼び出し

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。

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

4章

JavaMail

POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。

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

8章

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

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

表B‒38　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JavaVMのトラブルシュート機能強化

JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行編

4章，5章，9章

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

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

表B‒39　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JP1/ITRMへの対応

ITリソースを一元管理する製品であるJP1/ITRMに対応しました。

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

1.3，2.1

(5)　そのほかの目的

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

表B‒40　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

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章

（凡例）−：該当なし。

付録B.14　08-50での主な機能変更

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

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

表B‒41　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webサービスプロバイダ側でのweb.xmlの指定必須タグの変更

Webサービスプロバイダ側でのweb.xmlで，listenerタグ，servletタグおよびservlet-mappingタグの指定を必須から任意に変更しました。

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

2.2.3

論理サーバのネットワークリソース使用

J2EEアプリケーションからほかのホスト上にあるネットワークリソースやネットワークドライブにアクセスするための機能を追加しました。

機能解説 運用／監視／連携編

1.2.3，5.2，5.7

サンプルプログラムの実行手順の簡略化

一部のサンプルプログラムをEAR形式で提供することによって，サンプルプログラムの実行手順を簡略化しました。

ファーストステップガイド

3.5

システム構築・運用ガイド

付録L

運用管理ポータルの画面の動作の改善

画面の更新間隔を「更新しない」から「3秒」に変更しました。

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

7.4.1

セットアップウィザードの完了画面の改善

セットアップウィザード完了時の画面に，セットアップで使用した簡易構築定義ファイルおよびConnector属性ファイルが表示されるようになりました。

システム構築・運用ガイド

2.2.6

仮想化環境の構築

ハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築する手順を追加しました。

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

3章，5章

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

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

表B‒42　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

OpenTP1からの呼び出しへの対応

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。

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

4章

JMSへの対応

JMS 1.1仕様に対応したCJMSプロバイダ機能を使用できるようになりました。

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

7章

Java SE 6への対応

Java SE 6の機能が使用できるようになりました。

機能解説 保守／移行編

5.5，5.8.1

ジェネリクスの使用への対応

EJBでジェネリクスを使用できるようになりました。

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

4.2.18

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

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

表B‒43　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

明示管理ヒープ機能の使用性向上

自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。

システム設計ガイド

7.2，7.7.3，7.11.4，7.12.1

機能解説 拡張編

7章

データベースセッションフェイルオーバ機能のURI単位での抑止

データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。

機能解説 拡張編

5.6.1

仮想化環境での障害監視

仮想化システムで，仮想サーバを監視し，障害の発生を検知できるようになりました。

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

−

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

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

表B‒44　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

管理ユーザアカウントの省略

運用管理ポータル，Management Serverのコマンド，Smart Composer機能のコマンドで，ユーザのログインIDおよびパスワードの入力を省略できるようになりました。

システム構築・運用ガイド

4.1.15

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

2.2，7.1.1，7.1.2，7.1.3，8.1，8.2.1，付録E.2

リファレンス コマンド編

1.4，mngsvrctl（Management Serverの起動／停止／セットアップ），mngsvrutil（Management Serverの運用管理コマンド），8.3，cmx_admin_passwd（Management Serverの管理ユーザアカウントの設定）

仮想化環境の運用

仮想化システムで，複数の仮想サーバを対象にした一括起動・一括停止，スケールイン・スケールアウトなどを実行する手順を追加しました。

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

4章，6章

(5)　そのほかの目的

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

表B‒45　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Tenured領域内不要オブジェクト統計機能

Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。

機能解説 保守／移行編

9.8

Tenured増加要因の基点オブジェクトリスト出力機能

Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。

9.9

クラス別統計情報解析機能

クラス別統計情報をCSV形式で出力できるようになりました。

9.10

論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え

Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。

機能解説 運用／監視／連携編

18.4.3，18.5.3，16.2.2，16.3.3，16.3.4

ホスト単位管理モデルを対象とした系切り替えシステム

クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。

16章

ACOS（AX2000，BS320）のサポート

使用できる負荷分散機の種類にACOS（AX2000，BS320）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3，4.7.5，4.7.6，付録J，付録J.2

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

4.2.4，4.3.2，4.3.4，4.3.5，4.3.6，4.7.1

CMTでトランザクション管理をする場合にStateful Session Bean（SessionSynchronization）に指定できるトランザクション属性の追加

CMTでトランザクション管理をする場合に，Stateful Session Bean（SessionSynchronization）にトランザクション属性としてSupports，NotSupportedおよびNeverを指定できるようになりました。

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

2.7.3

OutOfMemoryError発生時の運用管理エージェントの強制終了

JavaVMでOutOfMemoryErrorが発生したときに，運用管理エージェントが強制終了するようになりました。

機能解説 保守／移行編

2.5.5

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

TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。

機能解説 拡張編

−

付録B.15　08-00での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表B‒46　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ほかのアプリケーションサーバ製品からの移行容易化

ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

このマニュアル

2.3，2.7.5

cosminexus.xmlの提供

アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。

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

16.3

(2)　標準機能への対応

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

表B‒47　標準機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 2.5への対応

Servlet 2.5に対応しました。

このマニュアル

2.2，2.5.4，2.6，8章

JSP 2.1への対応

JSP 2.1に対応しました。

このマニュアル

2.3.1，2.3.3，2.5，2.6，8章

JSPデバッグ

MyEclipseを使用した開発環境でJSPデバッグができるようになりました。※

このマニュアル

2.4

タグライブラリのライブラリJARへの格納とTLDのマッピング

タグライブラリをライブラリJARに格納した場合に，Webアプリケーション開始時にWebコンテナによってライブラリJAR内のTLDファイルを検索し，自動的にマッピングできるようになりました。

このマニュアル

2.3.4

application.xmlの省略

J2EEアプリケーションでapplication.xmlが省略できるようになりました。

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

16.4

アノテーションとDDの併用

アノテーションとDDを併用できるようになり，アノテーションで指定した内容をDDで更新できるようになりました。

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

17.5

アノテーションのJava EE 5標準準拠（デフォルトインターセプタ）

デフォルトインターセプタをライブラリJARに格納できるようになりました。また，デフォルトインターセプタからDIできるようになりました。

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

16.4

@Resourceの参照解決

@Resourceでリソースの参照解決ができるようになりました。

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

17.4

JPAへの対応

JPA仕様に対応しました。

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

6章

注※　09-00以降では，WTPを使用した開発環境でJSPデバッグ機能を使用できます。

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

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

表B‒48　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッション情報の永続化

HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。

機能解説 拡張編

5章，6章

FullGCの抑止

FullGCの要因となるオブジェクトをJavaヒープ外に配置することで，FullGC発生を抑止できるようになりました。

機能解説 拡張編

7章

クライアント性能モニタ

クライアント処理に掛かった時間を調査・分析できるようになりました。

−

−

（凡例）−：09-00で削除された機能です。

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

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

表B‒49　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのアプリケーション操作性向上

アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。

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

1.1.3

(5)　そのほかの目的

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

表B‒50　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

無効なHTTP Cookieの削除

無効なHTTP Cookieを削除できるようになりました。

このマニュアル

2.7.4

ネーミングサービスの障害検知

ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できるようになりました。

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

2.9

コネクション障害検知タイムアウト

コネクション障害検知タイムアウトのタイムアウト時間を指定できるようになりました。

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

3.15.1

Oracle11gへの対応

データベースとしてOracle11gが使用できるようになりました。

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

3章

バッチ処理のスケジューリング

バッチアプリケーションの実行をCTMによってスケジューリングできるようになりました。

機能解説 拡張編

4章

バッチ処理のログ

バッチ実行コマンドのログファイルのサイズ，面数，ログの排他処理失敗時のリトライ回数とリトライ間隔を指定できるようになりました。

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

3.2.5

snapshotログ

snapshotログの収集内容が変更されました。

機能解説 保守／移行編

付録A.1，付録A.2

メソッドキャンセルの保護区公開

メソッドキャンセルの対象外となる保護区リストの内容を公開しました。

機能解説 運用／監視／連携編

付録C

統計前のガーベージコレクション選択機能

クラス別統計情報を出力する前に，ガーベージコレクションを実行するかどうかを選択できるようになりました。

機能解説 保守／移行編

9.7

Survivor領域の年齢分布情報出力機能

Survivor領域のJavaオブジェクトの年齢分布情報をJavaVMログファイルに出力できるようになりました。

機能解説 保守／移行編

9.11

ファイナライズ滞留解消機能

JavaVMのファイナライズ処理の状態を監視して，処理の滞留を解消できるようになりました。

−

−

サーバ管理コマンドの最大ヒープサイズの変更

サーバ管理コマンドが使用する最大ヒープサイズが変更されました。

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

5.2.1，5.2.2

推奨しない表示名を指定された場合の対応

J2EEアプリケーションで推奨しない表示名を指定された場合にメッセージが出力されるようになりました。

メッセージ(構築／運用／開発用)

KDJE42374-W

（凡例）−：09-00で削除された機能です。

付録C　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

記号

<%=%>タグ記述時の注意[1]

<jsp:plugin>タグ利用時の注意[1]

数字

08-00での主な機能変更[1]

08-50での主な機能変更[1]

08-53での主な機能変更[1]

08-70での主な機能変更[1]

09-00での主な機能変更[1]

09-50での主な機能変更[1]

09-60での主な機能変更[1]

09-70での主な機能変更[1]

09-80での主な機能変更[1]

09-87での主な機能変更[1]

11-00での主な機能変更[1]

11-10での主な機能変更[1]

11-20での主な機能変更[1]

11-30での主な機能変更[1]

11-40での主な機能変更[1]

B

Bean Validation[1]

C

cjjspcコマンドによるJSP事前コンパイル[1]

cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル[1]

CookieへのサーバID付加[1]

Cookie利用時の注意[1]

E

EJBコンテナとの連携[1]、[2]

EL（Expression Language）のエスケープシーケンスについて[1]

EL 3.0使用時の注意事項[1]

EL式[1]

ELの概要[1]

ELの評価結果の型について[1]

Enterprise Beanの呼び出し方法[1]

H

HttpSessionオブジェクト[1]

HttpSessionオブジェクト数の上限値の設定[1]、[2]

HttpSessionのセッションIDへのサーバID付加[1]

HTTPステータスコード302のステータスメッセージについて[1]

HTTPレスポンスヘッダのカスタマイズ[1]

HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ[1]、[2]

I

includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて[1]

includeディレクティブ利用時の注意[1]

IPアドレス指定[1]

IPアドレス指定（NIO HTTPサーバ）[1]

J

J2EEサーバ単位の設定[1]

java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意[1]

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

javax.servlet.error.XXXXXによるエラー情報参照時の注意[1]

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

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて[1]

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて[1]

javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について[1]

javax.servlet.ServletResponseインタフェースのresetメソッド実行時の注意[1]

javax.servlet.ServletResponseクラスのsetLocaleメソッドについて[1]

javax.servlet.SingleThreadModelインタフェースの非推奨化について[1]

javax.servlet.UnavailableExceptionについて[1]

JSF[1]

JSFアプリケーション[1]

JSFアプリケーションがHTTPセッションに登録するオブジェクトサイズ[1]

JSFアプリケーションが明示管理ヒープ領域で使用するメモリサイズ[1]

JSFアプリケーションでセッションフェイルオーバ機能を使用する場合の注意事項[1]

JSFアプリケーションで明示管理ヒープ機能を使用する場合の注意事項[1]

JSFおよびJSTLの機能[1]

JSP[1]

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

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

JSP 2.2仕様およびJSP 2.3仕様に関する注意事項[1]

JSP EL式の評価APIの複数指定[1]

JSP ELの実行[1]

JSPコンパイル結果[1]

JSPコンパイル結果の出力先[1]

JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行していない場合）[1]

JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行している場合）[1]

JSPコンパイル結果のバージョンチェック[1]

JSPコンパイル結果のライフサイクル[1]、[2]

JSP事前コンパイル機能[1]

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

JSP事前コンパイル機能の概要[1]

JSP事前コンパイル機能の注意[1]

JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い[1]

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

JSP事前コンパイル時に検証されるweb.xmlの要素[1]

JSP事前コンパイルで実施されるチェック[1]

JSP事前コンパイルの実行時の処理[1]

JSP事前コンパイルの適用場面と使用するコマンドの対応[1]

JSP事前コンパイルの適用例[1]

JSP事前コンパイルの方法[1]

JSP実装時の注意事項[1]

JSPデバッグ機能[1]、[2]

JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について[1]

JSPドキュメント内のversion属性について[1]

JSPドキュメント内の矛盾する文字コードについて[1]

JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について[1]

JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について[1]

JSPドキュメントのデフォルト拡張子[1]

JSPドキュメントの文字コードについて[1]

JSPトランスレーション[1]

JSPの実行機能[1]、[2]

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

JSPファイルのコンパイル結果の保持[1]

JSTL[1]

M

ManagedBean[1]

N

NIO HTTPサーバ[1]

NIO HTTPサーバが出力するログ・トレース[1]

NIO HTTPサーバで使用できる機能[1]

NIO HTTPサーバのアクセスログのカスタマイズ[1]

NIO HTTPサーバの概要[1]

NIO HTTPサーバの機能[1]

NIO HTTPサーバの使用[1]

P

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

pageディレクティブのisThreadSafe属性の非推奨化について[1]

pageディレクティブのpageEncoding属性の複数回指定について[1]

Persistent Connection[1]

Persistent ConnectionによるWebクライアントとの通信制御[1]、[2]

Persistent Connectionによる通信制御[1]

POSTデータの読み込み失敗時の動作について[1]

PrintWriter，JSPWriterクラス利用時の性能向上について[1]

S

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

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

ServletContextインタフェース利用時の注意[1]

ServletContextオブジェクトに登録する製品独自の属性[1]

ServletRequestインタフェース利用時の注意[1]

ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意[1]

Servlet仕様で規定された文字エンコーディング（JSPファイル）[1]

Servlet仕様で規定された文字エンコーディング（レスポンス）[1]

Servlet仕様で規定されている文字エンコーディング[1]

Servlet仕様での文字エンコーディングの設定方法[1]

Servlet仕様での文字エンコーディングの設定方法（Servlet 2.3/JSP 1.2）[1]

Servlet仕様での文字エンコーディングの設定方法（Servlet 2.4/JSP 2.0）[1]

T

TLDファイルのバージョンに関する注意事項[1]

U

URI取得時の注意[1]

URLConnectionクラス使用時の注意[1]

URL書き換えを実行するServlet APIの引数ごとの戻り値[1]

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

URLグループ単位の最大同時実行スレッド数[1]

URLグループ単位の実行待ちキュー[1]

URLグループ単位の占有スレッド数[1]

URL指定とマッピング定義によるアクセスについて[1]

URLパターンの設定[1]

URLパターンのマッピング処理[1]

W

webserver.container.server_id.enabled[1]

webserver.container.server_id.name[1]

webserver.container.server_id.value[1]

webserver.session.cookie_config.http_only[1]

webserver.session.cookie_config.name[1]

webserver.session.max.log_interval[1]

webserver.session.max.throwHttpSessionLimitExceededException[1]

webserver.session.server_id.enabled[1]

webserver.session.server_id.value[1]

webserver.session.tracking_mode[1]

WebSocketの概要[1]

WebSocketを利用する場合の注意事項[1]

Webアプリケーション[1]

Webアプリケーション（WebAP1）の最大同時実行スレッド数の動的変更の設定例[1]

Webアプリケーションアンデプロイ時の注意[1]

Webアプリケーション開発でのJSP事前コンパイルの適用例[1]

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

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

Webアプリケーション単位の稼働状態でのパフォーマンスチューニング[1]

Webアプリケーション単位の設定[1]

Webアプリケーションに含まれるディレクトリにアクセスするときの注意[1]

Webアプリケーションの稼働状況の確認[1]

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定していない場合）[1]

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定している場合）[1]

Webアプリケーションの最大同時実行スレッド数[1]

Webアプリケーションの最大同時実行スレッド数の設定変更[1]

Webアプリケーションの最大同時実行スレッド数を変更する場合に参考になる情報[1]

Webアプリケーションの実行機能[1]、[2]

Webアプリケーションの実行待ちキューサイズ[1]

Webアプリケーションの占有スレッド数[1]

Webアプリケーションのデプロイとアンデプロイ[1]

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

Webアプリケーションのバージョン設定機能[1]、[2]

Webクライアントからの接続数の制御[1]、[2]

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

Webコンテナ[1]、[2]

Webコンテナが返すエラーステータスコード[1]

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

Webコンテナによるスレッドの作成[1]、[2]

Webコンテナの機能[1]

Webコンテナの共有スレッド数[1]

X

X-Powered-Byヘッダの利用[1]

あ

アクセス状況に応じた一時的なWebアプリケーション単位の最大同時実行スレッド数の変更[1]

アクセスを許可するホストの制限[1]

アクセスを許可するホストの制限によるアクセス制御[1]、[2]

アプリケーションサーバ 11-50での主な機能変更[1]

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

アプリケーションのイベントリスナ[1]、[2]

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

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

え

エラーページのカスタマイズ[1]、[2]

き

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

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

機能とマニュアルの対応[1]

機能の分類[1]

共通で使用する外部のライブラリ（Extension）について[1]

共有スレッド数[1]

共有スレッド数の算出のしかた[1]

く

クエリ文字列の解析について[1]

クラスローダの取得に関する注意[1]

こ

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

コミット後のエラーページの表示に関する注意[1]

コンパイル結果の削除[1]、[2]

コンパイル結果の生成[1]、[2]

コンパイル結果の保持[1]

さ

サーバID付加機能[1]

サーブレット[1]

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

サーブレットおよびJSPの実装[1]

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

サーブレット実装時の注意事項[1]

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

サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング[1]

サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト[1]

サーブレットマッピング[1]

最大同時実行スレッド数[1]

作成するスレッドの種類と数[1]

し

時間帯に応じた計画的なWebアプリケーション単位の最大同時実行スレッド数の変更[1]

システム運用でのJSP事前コンパイルの適用[1]

システムの目的と機能の対応[1]

実行待ちキューサイズ[1]

す

スレッド数を制御する単位[1]

せ

静的コンテンツのキャッシュ[1]、[2]

静的コンテンツのキャッシュの制御[1]

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

セッションID[1]

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

セッション管理機能[1]、[2]

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

セッションパラメタのカスタマイズ[1]

セッションマネージャの指定機能[1]、[2]

設定できる文字エンコーディング[1]

前提条件[1]

前バージョンからV11へ移行する場合のWebアプリケーションに関する注意事項[1]

占有スレッド数[1]、[2]、[3]

占有スレッド数と最大同時接続数[1]

そ

属性の変更に対するイベント通知時の注意[1]

た

タグファイルのJavaソースファイルとクラスファイルの出力先[1]

タグファイルの実行[1]

タグライブラリ利用時の注意[1]

タグライブラリ・ディスクリプタ（TLDファイル）の配置について[1]

つ

通信タイムアウト[1]

通信タイムアウト（NIO HTTPサーバ）[1]

通信タイムアウトの概要[1]

て

データベースとの接続[1]、[2]

適用個所[1]

適用条件[1]

デフォルトの実行待ちキューサイズ[1]

デフォルトの文字エンコーディング設定機能[1]、[2]

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

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

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

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

デフォルトマッピング[1]

と

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

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

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

同時実行スレッド数の制御[1]

同時実行スレッド数の制御の概要[1]

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

同時実行スレッド数の動的変更[1]

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

特別な意味を持つ入力値の表示に関する注意[1]

トランザクションとJDBCコネクション利用時の注意[1]

トランスレーションエラー[1]

に

入出力ストリーム利用時の注意[1]

ね

ネイティブライブラリのロードに関する注意[1]

は

バインド先アドレス設定機能[1]、[2]

パッケージ名の指定に関する注意[1]

ふ

ファイルアクセス時の注意[1]

複数のWebアプリケーションのデプロイ[1]

複数の範囲で文字エンコーディングを設定している場合の動作[1]

プロセス内で複数回実行してはならない処理を実装する場合の注意[1]

ほ

ホワイトスペース[1]

ま

マッピングの順序[1]

も

文字エンコーディング設定の組み合わせと有効になる設定[1]

文字エンコーディングの設定範囲[1]

ゆ

ユーザスレッド[1]

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

ユーザスレッドの使用[1]、[2]

ユーザスレッドの使用方法[1]

り

リクエストURIの正規化[1]

リクエスト受信時の通信タイムアウト[1]

リクエスト処理スレッド数の制御[1]、[2]

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

リクエストデータのサイズの制限[1]

リクエストデータのサイズの制限によるアクセス制御[1]、[2]

リスナで例外が発生した場合の制御について[1]

れ

例外発生時のエラーページの設定について[1]

レスポンス送信時に使用されるサーブレットのバッファ[1]

レスポンス送信時の通信タイムアウト[1]

ろ

ログ・トレースの出力[1]、[2]

ロケール設定時の注意[1]

論理ビュー[1]