Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発

11gリリース1 (10.3.6)

B60993-05(原本部品番号:E13712-06)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- Webアプリケーション開発者向けのサンプル

- Avitek Medical Recordsアプリケーション(MedRec)

- WebLogic Server配布キットのWebアプリケーション・サンプル

- このリリースでの新機能と変更点

2 Webアプリケーション、サーブレット、およびJSPの理解

- Webアプリケーション・コンテナ

- WebアプリケーションとJava EE

- Webアプリケーション開発の要点

- サーブレット

- サーブレットとJava EE

- サーブレットの特長

- サーブレット開発の要点

- JavaServer Pages

- JSPとJava EE

- JSPの特長

- JSPリクエストの処理方法の概要

- Webアプリケーション開発者向けツール

- その他のツール

- Webアプリケーションのセキュリティ

- リダイレクト攻撃の回避

- P3Pプライバシ・プロトコル

- Linuxブラウザでの特殊文字の表示

3 Webアプリケーションの作成と構成

- WebLogic WebアプリケーションとJava EE

- ディレクトリ構造

- WEB-INFの情報へのアクセス

- ディレクトリ構造の例

- Webアプリケーションの作成と構成の主な手順

- ステップ1: エンタープライズ・アプリケーション・ラッパーの作成

- ステップ2: Webアプリケーションの作成

- ステップ3: build.xmlファイルの作成

- ステップ4: 分割開発ディレクトリ構造におけるAntタスクの実行

- クライアントによるWebアプリケーションへのアクセス方法の構成

- Webアプリケーション用の仮想ホストの構成

- チャネル・ベースの仮想ホストの構成

- ホスト・ベースの仮想ホストの構成

- 仮想ホストへのWebアプリケーションの割当て

- サーブレット、コンテキスト・リスナー、およびフィルタのロード

- 共有Java EE Webアプリケーション・ライブラリ

4 サーブレットの作成と構成

- サーブレットの構成

- サーブレット・マッピング

- デフォルト・サーブレットの設定

- サーブレット初期化属性

- 単純なHTTPサーブレットの記述

- 高度な機能

- HelloWorldServletサンプルの全文

- サーブレット・コンテナのデバッグ

- アクセス・ロギングの無効化

- 使用方法

- 例

- 特定セッションのデバッグ

- 使用方法

- リクエスト・ハンドルの処理内容の追跡

- 使用方法

5 JSPの作成と構成

- WebLogic JSPとJava EE

- Java Server Pages (JSP)の構成

- JSPのサーブレットとしての登録

- JSPタグ・ライブラリの構成

- ウェルカム・ファイルの構成

- HTTPエラー・レスポンスのカスタマイズ

- HTTPリクエストのエンコーディングの識別

- IANA文字セットのJava文字セットへのマッピング

- JSPの最初と最後での暗黙的インクルードの構成

- JSPプロパティ・グループの構成

- JSPプロパティ・グループのルール

- JSPプロパティ・グループの特長

- XML構文を使用したJSPドキュメントの記述

- JSPドキュメントの使用方法

- JSPドキュメントについての重要な情報

6 JSFおよびJSTLライブラリの構成

- WebアプリケーションでのJSFおよびJSTLの構成

- JavaServer Faces (JSF)

- JavaServer Pages Standard Tag Libraries (JSTL)

- JSFおよびJSTLライブラリ

- JSF 2.0ライブラリ

- JSTL 1.2ライブラリ

- JSFおよびJSTLライブラリのデプロイメント

- JSFまたはJSTLライブラリの参照

- JSF 1.xおよびJSTL 1.xライブラリのサポート

7 Webアプリケーションのリソースの構成

- Webアプリケーションのリソースの構成

- リソースの構成

- 外部EJBの参照

- ejb-ref*要素についての詳細

- アプリケーション・スコープのEJBの参照

- ClasspathServletによるCLASSPATHからのリソースの提供

- WebLogic ServerでのCGIの使用

- CGIを使用するためのWebLogic Serverの構成

- CGIスクリプトのリクエスト

- CGIのベスト・プラクティス

8 Webコンポーネント用のWebLogicアノテーション

- サーブレット・アノテーションと依存関係インジェクション

- アノテーションをサポートするWebコンポーネント・クラス

- Webコンテナによってサポートされるアノテーション

- フォルトの検出とリカバリ

- 制限事項

- アノテーションによるサーブレットの記述

- WLServlet

- 属性

- フォルトの検出とリカバリ

- WLFilter

- 属性

- フォルトの検出とリカバリ

- WLInitParam

- 属性

9 サーブレット・プログラミング・タスク

- サーブレットの初期化

- WebLogic Server起動時のサーブレットの初期化

- init()メソッドのオーバーライド

- HTTPレスポンスの提供

- クライアント入力の取得

- HTTPリクエストを使用するメソッド

- 例: 問合せパラメータによる入力の取得

- サーブレットでのクライアント入力のセキュリティ

- WebLogic Serverユーティリティ・メソッドを使用する

- サーブレットでのCookieの使用方法

- HTTPサーブレットでのCookieの設定

- HTTPサーブレットでのCookieの取得

- HTTPとHTTPSの両方で送信されるCookieの使用方法

- アプリケーションのセキュリティとCookie

- レスポンスのキャッシュ

- 初期化パラメータ

- HTTPサーブレットからのWebLogicサービスの使用方法

- データベースへのアクセス

- DataSourceオブジェクトを用いたデータベースへの接続

- サーブレットでDataSourceを使用する

- JDBCドライバを用いたデータベースへの直接接続

- HTTPサーブレットにおけるスレッドの問題

- 別のリソースへのリクエストのディスパッチ

- リクエストの転送

- リクエストのインクルード

- RequestDispatcherとフィルタ

- 別のWebサーバーへのリクエストのプロキシ

- 別のWebサーバーへのリクエストのプロキシの概要

- セカンダリWebサーバーへのプロキシの設定

- プロキシ・サーブレットのデプロイメント記述子のサンプル

- サーブレットのクラスタリング

- Webアプリケーションでのサーブレットの参照

- URLパターン・マッチング

- SimpleApacheURLMatchMapユーティリティ

- HTTPサーブレットの将来的レスポンス・モデル

- 抽象非同期サーブレット

- doRequest

- doResponse

- doTimeOut

- 将来的レスポンス・サーブレット

10 セッションとセッション永続性の使用

- HTTPセッションの概要

- セッション管理の設定

- HTTPセッション・プロパティ

- セッション・タイムアウト

- WebLogic ServerセッションCookieの構成

- セッションより長く存続するアプリケーションCookieの構成

- ログアウト

- Webアプリケーション間の同一セッション共有の有効化

- セッションの永続性の構成

- 各種のセッション永続性の共有属性

- メモリー・ベース、単一サーバー、非レプリケート永続ストレージの使用方法

- ファイル・ベースの永続ストレージの使用方法

- 永続記憶域用データベースの使用方法(JDBC永続性)

- JDBCベースの永続ストレージを構成する

- JDBCセッション永続性のためにキャッシングおよびデータベース更新を行う

- Cookieベースのセッション永続性の使用

- Cookieに代わるURL書換えの使用

- URL書換えのコーディングに関するガイドライン

- URL書換えとWireless Access Protocol (WAP)

- サーブレットからのセッション・トラッキング

- セッション・トラッキングの履歴

- HttpSessionオブジェクトを用いたセッションのトラッキング

- セッションの存続期間

- セッション・トラッキングの仕組み

- セッションの開始の検出

- セッション名/値の属性の設定と取得

- セッションのログアウトと終了

- 単一のWebアプリケーションに対しsession.invalidate()を使用する

- 複数のアプリケーションに対するシングル・サインオンを実装する

- シングル・サインオンからWebアプリケーションを除外する

- セッション・トラッキングの構成

- Cookieに代わるURL書換えの使用

- URL書換えとWireless Access Protocol (WAP)

- セッションの永続化

- セッション使用時に避けるべき状況

- シリアライズ可能な属性値を使用する

- セッションの永続性の構成

- インメモリー・サーブレット・セッションに対する最大の制限の構成

- セッション・メモリー過負荷保護の有効化

11 アプリケーション・イベントとイベント・リスナー・クラス

- アプリケーション・イベント・リスナー・クラスの概要

- サーブレット・コンテキスト・イベント

- HTTPセッション・イベント

- サーブレット・リクエスト・イベント

- イベント・リスナー・クラスの構成

- イベント・リスナー・クラスの作成

- イベント・リスナー・クラスのテンプレート

- サーブレット・コンテキスト・イベント・リスナー・クラスの例

- HTTPセッション属性イベント・リスナー・クラスの例

- その他の情報源

12 HTTPパブリッシュ/サブスクライブ・サーバーの使用

- HTTPパブリッシュ/サブスクライブ・サーバーの概要

- Pub-Subサーバーの仕組み

- チャネル

- メッセージ配信と配信順序の保証

- HTTPパブリッシュ/サブスクライブ・サーバーの使用例

- HTTPパブリッシュ/サブスクライブ・サーバーの使用: 標準の手順

- weblogic-pubsub.xmlファイルの作成

- サーバー側のPub-Sub APIによるプログラミング

- APIの主なクラスおよびインタフェースの概要

- Pub-Subサーバー・インスタンスの取得とローカル・クライアントの作成

- チャネルへのメッセージのパブリッシュ

- チャネルのサブスクライブ

- メッセージ・フィルタ・チェーンの構成とプログラミング

- メッセージ・フィルタ・クラスのプログラミング

- メッセージ・フィルタ・チェーンの構成

- Pub-Subサーバーと通信するためのブラウザ・クライアントの更新

- pubsub Java EEライブラリのデフォルト・サーブレット・マッピングのオーバーライド

- Pub-Subサーバーおよびチャネルの実行時情報の取得

- セキュリティの有効化

- パブリッシュ/サブスクライブの制約の使用

- チャネル操作へのアクセスの指定

- すべてのチャネル操作へのアクセスの制限

- すべてのチャネル操作へのアクセスの許可

- Webアプリケーションの再デプロイによる制約の更新

- プリンシパルへのロールのマップ

- パブリッシュ/サブスクライブ通信でのSSLの構成

- セキュリティのその他の考慮事項

- AuthCookieEnabledによるリソースへのアクセス

- Pub-Subサーバーのロック

- 高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

- ハンドラとしてのJMSの構成

- クライアント・セッション・フェイルオーバーの構成

- 高度なトピック: 物理ストレージへのメッセージの永続化

- 永続チャネルの構成

13 WebLogic JSPリファレンス

- JSPタグ

- JSPバージョンの定義

- JSPファイル・バージョンの定義ルール

- タグ・ファイル・バージョンの定義ルール

- 暗黙的オブジェクト用の予約語

- WebLogic JSPのディレクティブ

- ページ・ディレクティブを使用した文字エンコーディングの設定

- taglibディレクティブの使用方法

- 宣言

- スクリプトレット

- 式

- HTMLと埋め込みJavaを使用したJSPの例

- アクション

- JSPでのJavaBeanの使用方法

- JavaBeanオブジェクトをインスタンス化する

- JavaBeanインスタンス化のセット・アップ作業を行う

- JavaBeanオブジェクトを使用する

- JavaBeanオブジェクトのスコープを定義する

- リクエストの転送

- リクエストのインクルード

- JSP式言語

- 式および属性値

- 式およびテンプレート・テキスト

- JSP式言語の暗黙的オブジェクト

- JSP式言語のリテラルと演算子

- リテラル

- エラー、警告、デフォルト値

- 演算子

- 演算子の優先順位

- JSP式言語の予約語

- JSP式言語の名前付き変数

- JSPでのユーザー入力データのセキュリティ

- WebLogic Serverユーティリティ・メソッドを使用する

- JSPでのセッションの使用方法

- JSPからのアプレットのデプロイメント

- WebLogic JSPコンパイラの使用方法

- JSPコンパイラの構文

- JSPコンパイラ・オプション

- JSPのプリコンパイル

- JSPClassServletの使用

14 フィルタ

- フィルタの概要

- フィルタの動作と仕組み

- フィルタの用途

- フィルタ・クラスの作成

- フィルタの構成

- フィルタの構成

- フィルタのチェーンの構成

- サーブレット・レスポンス・オブジェクトでのフィルタ処理

- その他の情報源

15 WebLogic JSPフォーム検証タグの使用方法

- WebLogic JSPフォーム検証タグの概要

- 検証タグ属性のリファレンス

- <wl:summary>

- <wl:form>

- <wl:validator>

- WebLogic JSPフォーム検証タグのJSP内での使用方法

- <wl:form>タグを使用したHTMLフォームの作成

- 単一のフォームの定義

- 複数のフォームの定義

- 検証によってエラーが返されたときのフィールド内の値の再表示

- <input>タグを使用して値を再表示する

- Apache Jakarta <input:text>タグを使用して値を再表示する

- カスタム・バリデータ・クラスの使用方法

- CustomizableAdapterクラスの拡張

- ユーザーの記述によるバリデータ・クラスのサンプル

- 検証タグを使用したサンプルJSP

16 カスタムWebLogic JSPタグ(cache、process、repeat)の使用方法

- WebLogicカスタムJSPタグの概要

- WebアプリケーションでのWebLogicカスタム・タグの使用方法

- cacheタグ

- キャッシュのリフレッシュ

- キャッシュのフラッシュ

- processタグ

- repeatタグ

17 WebLogic EJB-to-JSP統合ツールの使用方法

- WebLogic EJB-to-JSP統合ツールの概要

- 基本的な処理

- インタフェース・ソース・ファイル

- 「Build Options」パネル

- トラブルシューティング

- JSPページでのEJBタグの使用方法

- EJBホーム・メソッド

- ステートフル・セッションBeanとエンティティBean

- デフォルト属性

A web.xmlデプロイメント記述子の要素

- web.xmlのネームスペース宣言とスキーマの場所

- icon

- display-name

- description

- distributable

- context-param

- filter

- filter-mapping

- listener

- servlet

- icon

- init-param

- security-role-ref

- servlet-mapping

- session-config

- mime-mapping

- welcome-file-list

- error-page

- jsp-config

- taglib

- jsp-property-group

- resource-env-ref

- resource-ref

- security-constraint

- web-resource-collection

- auth-constraint

- user-data-constraint

- login-config

- form-login-config

- security-role

- env-entry

- ejb-ref

- ejb-local-ref

- web-app

B weblogic.xmlデプロイメント記述子の要素

- weblogic.xmlのネームスペース宣言とスキーマの場所

- description

- weblogic-version

- security-role-assignment

- run-as-role-assignment

- resource-description

- resource-env-description

- ejb-reference-description

- service-reference-description

- session-descriptor

- jsp-descriptor

- auth-filter

- container-descriptor

- check-auth-on-forward

- filter-dispatched-requests-enabled

- redirect-with-absolute-url

- index-directory-enabled

- index-directory-sort-by

- servlet-reload-check-secs

- resource-reload-check-secs

- single-threaded-servlet-pool-size

- session-monitoring-enabled

- save-sessions-enabled

- prefer-web-inf-classes

- prefer-application-packages

- prefer-application-resources

- default-mime-type

- client-cert-proxy-enabled

- relogin-enabled

- allow-all-roles

- native-io-enabled

- minimum-native-file-size

- disable-implicit-servlet-mappings

- temp-dir

- optimistic-serialization

- show-archived-real-path-enabled

- require-admin-traffic

- access-logging-disabled

- prefer-forward-query-string

- charset-params

- input-charset

- charset-mapping

- virtual-directory-mapping

- url-match-map

- security-permission

- context-root

- wl-dispatch-policy

- servlet-descriptor

- work-manager

- logging

- library-ref

- fast-swap

- 後方互換性フラグ

- JSP 2.0 Webアプリケーションとの互換性

- JSPの動作とバッファ接尾辞

- Servlet 2.5パッケージの暗黙的なインポート

- Webコンテナのグローバル構成

C GlassFishデプロイメント記述子のサポート

D Webアプリケーションのベスト・プラクティス

- CGIのベスト・プラクティス

- サーブレットのベスト・プラクティス

- JSPのベスト・プラクティス

- ServletResponseWrapperをサブクラス化する際のベスト・プラクティス

Oracle® Fusion Middleware

Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発

11gリリース1 (10.3.6)

B60993-05(原本部品番号:E13712-06)

2011年11月

このドキュメントは、WebLogic ServerにデプロイするWebアプリケーションや、HTTPサーブレット、JavaServer Page (JSP)などのコンポーネントを開発するソフトウェア開発者向けの情報源です。

Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発, 11gリリース1 (10.3.6)

B60993-05

Copyright © 2007, 2011, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この項では、このガイド『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- Webアプリケーション開発者向けのサンプル

- このリリースでの新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは、WebLogic ServerにデプロイするWebアプリケーションや、HTTPサーブレット、JavaServer Page (JSP)などのコンポーネントを開発するソフトウェア開発者向けの情報源です。Webアプリケーションのユーザーおよびデプロイヤ向けの情報も提供しています。また、WebLogic Serverを評価するビジネス・アナリストや、特定のアプリケーションでWebLogic Server Webアプリケーションの使用を考えているシステム設計者にとって便利な情報も掲載されています。

このドキュメントのトピックでは、ソフトウェア・プロジェクトの設計および開発フェーズに関連する情報を提供します。また、プロジェクトのテストおよび本番前のフェーズで見つかるアプリケーションの問題を解決するうえで便利なトピックもあります。

このドキュメントでは、本番フェーズでの管理、モニター、パフォーマンス・チューニングについては扱いません。これらのトピックに関するWebLogic Serverのドキュメントとリソースへのリンクについては、「関連ドキュメント」を参照してください。

このドキュメントは、読者がJava EEおよびWebアプリケーションの概念に精通していることを前提にしています。このドキュメントでは、WebLogic Server Webアプリケーションが提供する付加価値機能と、Webアプリケーションを実行するWebLogic Server機能の使用方法に関する主要な情報が重点的に扱われています。

このドキュメントの手引き

- この章第1章「概要とロードマップ」では、このドキュメントの構成を紹介します。

- 第2章「Webアプリケーション、サーブレット、およびJSPの理解」では、WebLogic Server Webアプリケーション、サーブレット、およびJava Server Page (JSP)の概要を示します。

- 第3章「Webアプリケーションの作成と構成」では、Webアプリケーション・リソースの作成および構成の方法について説明します。

- 第4章「サーブレットの作成と構成」ではサーブレットの作成と構成の方法について説明します。

- 第5章「JSPの作成と構成」では、JSPの作成および構成の方法について説明します。

- 第6章「JSFおよびJSTLライブラリの構成」では、JavaServer Faces (JSF)およびJSP Tag Standard Library (JSTL)を構成する方法について説明します。

- 第7章「Webアプリケーションのリソースの構成」では、Webアプリケーション・リソースの構成方法について説明します。

- 第8章「Webコンポーネント用のWebLogicアノテーション」では、Webコンポーネントでアノテーションとリソース注入を使用して開発を簡略化する方法について説明します。

- 第9章「サーブレット・プログラミング・タスク」では、WebLogic Server環境でのHTTPサーブレットの記述方法について説明します。

- 第10章「セッションとセッション永続性の使用」では、セッションおよびセッション永続性の設定方法について説明します。

- 第11章「アプリケーション・イベントとイベント・リスナー・クラス」では、アプリケーション・イベントおよびイベント・リスナー・クラスについて説明します。

- 第12章「HTTPパブリッシュ/サブスクライブ・サーバーの使用」では、HTTPパブリッシュ/サブスクライブ・サーバーの概要と、Webアプリケーションにおけるこのサーバーの使用方法を示します

- 第13章「WebLogic JSPリファレンス」では、JavaServer Page (JSP)を記述するためのリファレンス情報を提供します。

- 第14章「フィルタ」では、Webアプリケーションでのフィルタの使用方法について説明します。

- 第15章「WebLogic JSPフォーム検証タグの使用方法」では、WebLogic JSPフォーム検証タグの使用方法について説明します。

- 第16章「カスタムWebLogic JSPタグ(cache、process、repeat)の使用方法」では、WebLogic Server配布キットに含まれる3つのカスタムJSPタグ(cache、repeat、およびprocess)の使用方法について説明します。

- 第17章「WebLogic EJB-to-JSP統合ツールの使用方法」では、WebLogic EJB-to-JSP統合ツールを使用して、JavaServer Page (JSP)でEJBを呼び出すためのJSPタグ・ライブラリを作成する方法について説明します。ここでは、読者が少なくともEJBとJSPの両方についてある程度の知識を持っていることを前提としています。

- 付録A「web.xmlデプロイメント記述子の要素」では、web.xmlスキーマで定義される、ルート要素<web-app>の下のデプロイメント記述子の要素について説明します。

- 付録B「weblogic.xmlデプロイメント記述子の要素」は、WebLogic Server固有のデプロイメント記述子weblogic.xmlのスキーマに関する詳細なリファレンスです。

- 付録C「GlassFishデプロイメント記述子のサポート」には、WebLogic ServerでサポートされているGlassFishデプロイメント記述子のリストが記載されています。

- 付録D「Webアプリケーションのベスト・プラクティス」では、WebLogic ServerのWebアプリケーションおよびアプリケーション・リソースを設計、開発およびデプロイするためのベスト・プラクティスを示します。

関連ドキュメント

このドキュメントには、Webアプリケーションに固有の設計および開発上の情報が含まれています。

WebLogic Serverアプリケーションを開発、デプロイ、およびモニターするための包括的なガイドラインについては、以下のドキュメントを参照してください。

- 『Oracle WebLogic Serverアプリケーションの開発』は、WebLogic Serverアプリケーションの開発用ガイドです。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、WebLogic Serverアプリケーションのデプロイメントについての情報のプライマリ・ソースです。

- 『Oracle WebLogic Serverアップグレード・ガイド』には、Webアプリケーション、JSP、およびサーブレットの以前のWebLogic Serverリリースとの互換性に関する情報が含まれています。

- サーブレットの製品概要(http://www.oracle.com/technetwork/java/javaee/servlet/index.html)

- JavaServer Pages (JSP)の製品概要(http://www.oracle.com/technetwork/java/javaee/jsp/index.htm)

- JavaServer Faces (JSF)の製品概要(http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html)

- JavaServer Pages Standard Tag Library (JSTL)の製品概要(http://www.oracle.com/technetwork/java/index-jsp-135995.html)

- Javaアプリケーション開発一般の詳細は、http://www.oracle.com/technetwork/java/javaee/overview/index.htmlを参照してください。

Webアプリケーション開発者向けのサンプル

このドキュメントに加えて、次の項で説明するAvitek Medical Recordsアプリケーション(MedRec)サンプルのコンテキスト内で、ソフトウェア開発者向けのサンプルが用意されています。

Avitek Medical Recordsアプリケーション(MedRec)

MedRecはWebLogic Serverに付属したエンド・ツー・エンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecは、必要に応じてWebLogicサーバー配布とともにインストールされ(カスタム・インストールでは「サーバー例」を選択します)、Windowsマシン上の「スタート」メニューからアクセスできます。Linuxおよびその他のプラットフォームでは、WL_HOME\samples\domains\medrecディレクトリからMedRecを起動できます。WL_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリです。

WebLogic Server配布キットのWebアプリケーション・サンプル

WebLogic Serverは必要に応じて、APIコード・サンプルをWL_HOME\samples\server\examples\src\examplesにインストールします。WL_HOMEは、WebLogic Serverインストールの最上位のディレクトリです。カスタム・インストールでは、「Serverサンプル」を選択します。サンプル・サーバーを起動し、サンプルおよびそれらの実行方法に関する情報をWebLogic Serverの「スタート」メニューから取得できます。

このリリースのWebLogic Serverでは、複数のWebアプリケーション、サーブレット、およびJSPサンプルが用意されています。独自のWebアプリケーションを開発する前に、まずこれらのWebアプリケーション・サンプルを実行することをお薦めします。

このリリースでの新機能と変更点

このリリースのWebLogic Serverでは一部のGlassFishデプロイメント記述子がサポートされるため、GlassFish Serverにデプロイされて実行される基本的なWebアプリケーションは、WebLogic Serverにデプロイできます。サポートされているデプロイメント記述子のリストについては、付録C「GlassFishデプロイメント記述子のサポート」を参照してください。

このリリースで導入されたWebLogic Serverの包括的な新機能一覧は、『Oracle WebLogic Serverの新機能』を参照してください。

2 Webアプリケーション、サーブレット、およびJSPの理解

次の項では、WebLogic Server Webアプリケーション、サーブレット、およびJavaServer Page (JSP)の概要を説明します。

- Webアプリケーション・コンテナ

- サーブレット

- JavaServer Pages

- Webアプリケーション開発者向けツール

- Webアプリケーションのセキュリティ

- リダイレクト攻撃の回避

- P3Pプライバシ・プロトコル

- Linuxブラウザでの特殊文字の表示

Webアプリケーション・コンテナ

Webアプリケーションには、サーブレット、JavaServer Pages (JSP)、JSPタグ・ライブラリなどのアプリケーションのリソースと、HTMLページや画像ファイルなどの静的リソースが組み込まれています。Webアプリケーションにより、アプリケーションにservice-ref (Webサービス)およびmessage-destination-ref (JMS宛先/キュー)が追加されます。また、Enterprise JavaBeans (EJB)などの外部リソースへのリンクも定義できます。

WebアプリケーションとJava EE

Java Platform, Enterprise Edition (Java EE)バージョン5.0プログラミング・モデル(http://www.oracle.com/technetwork/java/javaee/documentation/index.htmlを参照)の重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。

Java EEアノテーションの使用により、標準のapplication.xmlおよびweb.xmlデプロイメント記述子は省略可能になりました。Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDK 5.0アノテーション機能を採用しています。第8章「Webコンポーネント用のWebLogicアノテーション」およびhttp://download.oracle.com/javaee/5/api/を参照してください。

ただし、WebLogic ServerにデプロイされるWebアプリケーションは、標準のJava EEデプロイメント記述子ファイルとWebLogic固有のデプロイメント記述子ファイルを引き続き使用して、それらのリソースと操作属性を定義できます。

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

JSPとHTTPサーブレットは、WebLogic Serverで使用可能なすべてのサービスとAPIにアクセスできます。これらのサービスには、EJB、Java Database Connectivity (JDBC)によるデータベース接続、Java Messaging Service (JMS)、XMLなどがあります。

Webアーカイブ(WARファイル)には、Webアプリケーションを構成するファイルが格納されます。WARファイルは、1つまたは複数のWebLogic Serverインスタンスに1つの単位としてデプロイされます。WebLogic ServerにデプロイされるWARファイルには、常に次のファイルが含まれます。

- 1つのサーブレットまたはJava Server Page (JSP)、およびヘルパー・クラス。

- (オプション) web.xmlデプロイメント記述子(WARファイルの内容を記述するJava EE標準のXMLドキュメント)。

- weblogic.xmlデプロイメント記述子(Webアプリケーション用のWebLogic Server固有の要素が格納されるXMLドキュメント)。

- WARファイルには、HTMLページまたはXMLページ、およびそれらに付属する画像やマルチメディア・ファイルなどのサポート・ファイルを含めることもできます。

WARファイルは、単独でデプロイすることも、他のアプリケーション・コンポーネントとともにエンタープライズ・アプリケーション・アーカイブ(EARファイル)にパッケージ化することもできます。単独でデプロイする場合、アーカイブは.war拡張子で終わる必要があります。EARファイルにデプロイする場合、アーカイブは.ear拡張子で終わる必要があります。

スタンドアロンWebアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。

注意:

ディレクトリを展開形式(非アーカイブ形式)でデプロイする場合は、ディレクトリに.ear、.jarなどの名前を付けないでください。アーカイブ形式の詳細は、「Webアプリケーション開発者向けツール」を参照してください。

サーブレット

サーブレットとは、Javaに対応したサーバーで実行されるJavaクラスです。HTTPサーブレットは、HTTPリクエストを処理し、通常はHTMLページの形式でHTTPレスポンスを送信する特殊なサーブレットです。WebLogic HTTPサーブレットの最も一般的な使用方法は、クライアント側のプレゼンテーションに標準的なWebブラウザを使い、WebLogic Serverではサーバー側のプロセスとしてビジネス・ロジックを処理する、対話型アプリケーションを作成することです。WebLogic HTTPサーブレットは、データベース、Enterprise JavaBeans、メッセージングAPI、HTTPセッションなどのWebLogic Serverの機能にアクセスできます。

サーブレットとJava EE

WebLogic Serverでは、Servlet 2.5仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html)に定義されているように、HTTPサーブレットを完全にサポートしています。HTTPサーブレットは、Java EE規格の不可欠な部分です。

Java EEメタデータ・アノテーションの使用により、標準のweb.xmlデプロイメント記述子は省略可能になりました。Servlet 2.5仕様では、サーブレット、フィルタ、リスナー、タグ・ハンドラなどの特定のWebコンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存関係を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル・メソッドが呼び出される前に必要な依存関係を注入します。第8章「Webコンポーネント用のWebLogicアノテーション」を参照してください。

Servlet 2.5仕様は、サーブレットAPIの実装と、エンタープライズ・アプリケーションでのサーブレットのデプロイ方法を定義しています。WebLogic ServerなどJava EE準拠のサーバーでサーブレットをデプロイするには、エンタープライズ・アプリケーションを構成するサーブレットなどのリソースをWebアプリケーションという1つの単位にパッケージ化します。Webアプリケーションでは、リソースを格納する特定のディレクトリ構造と、これらのリソースが対話する方法や、クライアントによるアプリケーションへのアクセス方法を定義する、デプロイメント記述子を利用します。「Webアプリケーション・コンテナ」を参照してください。

サーブレットの特長

- HTMLフォームを使用してエンドユーザーの入力を取得し、その入力に応答するHTMLページを表示する、動的なWebページを作成します。たとえば、オンライン・ショッピング・カート、金融サービス、パーソナライズされたコンテンツなどに使用できます。

- オンライン会議などのコラボレーション・システムを作成します。

- WebLogic Serverで実行されるサーブレットを使用することで、様々なAPIや機能にアクセス。例:

- セッション・トラッキング - Webサイトで複数のWebページにわたるユーザーの動きを追跡できます。この機能は、ショッピング・カートを使用するeコマース・サイトなどのWebサイトをサポートします。WebLogic Serverはデータベースへのセッション永続性をサポートしており、サーバーのダウンタイム中のフェイルオーバー、およびクラスタリングされたサーバー間のセッションの共有を提供します。詳細は、「サーブレットからのセッション・トラッキング」を参照してください。

- JDBCドライバ - JDBCドライバにより、基本的なデータベース・アクセスが提供されます。WebLogic Serverの複数層JDBC実装により、接続プール、サーバー側のデータ・キャッシュ、およびトランザクションを利用できます。詳細は、「データベースへのアクセス」を参照してください。

- Enterprise JavaBeans - サーブレットでEnterprise JavaBeans (EJB)を使用して、セッション、データベースのデータ、その他の機能をカプセル化できます。「外部EJBの参照」、「ejb-ref*要素についての詳細」および「アプリケーション・スコープのEJBの参照」を参照してください。

- Java Messaging Service (JMS) - サーブレットは、JMSを使用して他のサーブレットやJavaプログラムとメッセージを交換できます。『Oracle WebLogic Server JMSのプログラミング』を参照してください。

- Java JDK API - サーブレットでは、標準的なJava JDK APIを使用できます。

- リクエストの転送 - サーブレットでは、リクエストを別のサーブレットまたは別のリソースに転送できます。「リクエストの転送」を参照してください。

- 任意のJava EE準拠のサーブレット・エンジン用に作成されたサーブレットをWebLogic Serverに簡単にデプロイ。

サーブレット開発の要点

以下に、サーブレット開発に関連するいくつかの要点を挙げます。

- HTTPサーブレットのプログラマは、標準Java APIであるjavax.servlet.httpを利用して対話型のアプリケーションを作成します。

- HTTPサーブレットはHTTPヘッダーを読み取り、HTMLコードを書き出してブラウザ・クライアントへレスポンスを送り出すことができます。

- サーブレットは、Webアプリケーションの一部としてWebLogic Serverにデプロイされます。Webアプリケーションとは、サーブレット・クラス、JavaServer Pages (JSP)、静的なHTMLページ、画像、セキュリティなどのアプリケーション・コンポーネントをグループ化したものです。

JavaServer Pages

JavaServer Pages (JSP)は、JavaをHTMLと組み合わせてWebページで動的コンテンツを提供するための仕様です。動的コンテンツを作成する場合、JSPではHTMLページに直接Javaコードを埋め込むことができるのに対し、HTTPサーブレットではHTMLをJavaコードに埋め込むので、JSPの方がHTTPサーブレットよりコーディングが容易です。

JSPは、JavaコードをWebページに埋め込むことができる拡張HTMLで記述されたWebページです。JSPでは、HTMLに似たタグを使用して、taglibと呼ばれるカスタムJavaクラスを呼び出すことができます。WebLogicのappcコンパイラ(weblogic.appc)では、JSPの生成と記述子の検証が行われます。また、JSPをWEB-INF/classes/ディレクトリ内にプリコンパイルするか、WEB-INF/lib/の下でJARファイルとしてプリコンパイルし、サーブレット・クラスをWebアーカイブにパッケージ化して、サーバー内でのコンパイルを回避することも可能です。サーブレットおよびJSPでは、Webアプリケーションとともにデプロイするヘルパー・クラスがさらに必要な場合があります。

JSPを使用すると、Webページの動的コンテンツとその表現方法を分離できます。これにより、ページの視覚デザインを担当するHTML開発者と、動的コンテンツを作成するソフトウェアの開発を担当するJava開発者という2種類の開発者の要望に応えます。

JSPとJava EE

WebLogic JSPでは、JSP 2.1仕様(http://www.oracle.com/technetwork/java/javaee/jsp/index.html)をサポートしています。Java EEの主要なテーマは、開発の容易さです。プラットフォームのWeb層では、以下の2つの点で開発の容易さが大幅に向上しています。1つめは、プラットフォームにJavaServer Pages Standard Tag Library (JSTL)技術とJavaServer Faces技術が組み込まれていることです。2つめは、Java EEでのWebアプリケーション開発を非常に容易にする以下のような機能がすべてのWeb層技術で提供されることです。

- 新しい式言語(EL)構文。これにより、式の評価を遅延できるようになり、式を使用してデータを取得および設定したりメソッドを呼び出したりできるようになりました。さらに、式によって参照される変数やプロパティの解決がカスタマイズしやすくなりました。

- アノテーションを介したリソース注入のサポート。これにより、リソースや環境データへのアクセスの構成が簡略化されました。

- JavaServer Faces技術タグとJavaServer Pages (JSP)ソフトウェア・コードとの緊密な連携。

JSPはJava EE標準の一部であるので、WebLogic Serverを含む様々なプラットフォームでJSPをデプロイすることが可能です。さらに、サード・パーティ・ベンダーやアプリケーション開発者は、動的コンテンツを構成するためにJSPページから参照できるカスタムJSPタグを定義したり、JavaBeanコンポーネントを配布したりできます。

JSPの特長

- JavaとHTMLを組み合わせてWebページで動的なコンテンツを提供します。

- HTMLに似たタグを使用して、taglibと呼ばれるカスタムJavaクラスを呼び出します。

- HTTPサーブレット(HTMLをJavaコード内に埋め込む)とは対照的に、HTMLページにJavaコードを直接埋め込みます。

- Webページで動的コンテンツを表現要素から分離します。

JSPリクエストの処理方法の概要

WebLogic Serverは、次の順序でJSPリクエストを処理します。

1. ブラウザが、.jspファイルをWebLogic Serverにリクエストします。

2. WebLogic Serverがリクエストを読み取ります。

3. WebLogic Serverは、JSPコンパイラを使ってJSPをjavax.servlet.jsp.JspPageインタフェースを実装するサーブレット・クラスに変換します。JSPファイルは、ページが初めてリクエストされたとき、あるいはJSPファイルが更新されてそのタイムスタンプが新しくなった場合にのみコンパイルされます。そうでない場合、以前に編集されたJSPサーブレット・クラスが再利用されるので、次のレスポンスは非常に高速になります。

4. 生成されたJspPageサーブレット・クラスが呼び出され、ブラウザからのリクエストを処理します。

また、ブラウザからリクエストせずに直接JSPコンパイラを呼び出すこともできます。詳細は、「WebLogic JSPコンパイラの使用方法」を参照してください。

JSPコンパイラはまずJavaサーブレットを作成するので、コンパイラが生成するJavaファイルを見ることもでき、生成されたJspPageサーブレット・クラスをHTTPサーブレットとして登録することもできます。「サーブレット」を参照してください。

Webアプリケーション開発者向けツール

Oracleは、サーブレット、JSP、JSFベースのWebアプリケーションを容易に作成、テスト/デバッグ、およびデプロイできるいくつかのツールを提供しています。

- Oracle JDeveloperは、Oracle Fusion Middleware製品の統合開発環境を提供するエンタープライズIDEです。詳細は、http://www.oracle.com/technology/products/jdev/index.htmlを参照してください。

- Oracle Enterprise Pack for Eclipseは、OracleプラットフォームをターゲットにしたWebアプリケーション用の事前パッケージ・ツールを備えたEclipseベースの開発環境です。詳細は、http://www.oracle.com/technology/products/enterprise-pack-for-eclipse/index.htmlを参照してください。

どちらのツールも、高度なコード編集機能、コラボレーティブなチームワーク開発環境、ビジュアルな開発とデバッグ機能、および効率的なデプロイメント機能を備えています。

その他のツール

スケルトン・デプロイメント記述子を作成するときに、WebLogic Antユーティリティを使用できます。これらのユーティリティは、WebLogic Server配布キットとともに出荷されているJavaクラスです。ANTタスクによって、Webアプリケーションを含むディレクトリが調べられ、そのWebアプリケーションで検出されたファイルを基にデプロイメント記述子が作成されます。ANTユーティリティは、個別のWebアプリケーションに必要な構成やマッピングに関する情報をすべて備えているわけではないので、ANTユーティリティによって作成されるスケルトン・デプロイメント記述子は不完全なものです。ユーティリティがスケルトン・デプロイメント記述子を作成した後で、テキスト・エディタ、XMLエディタ、または管理コンソールを使ってデプロイメント記述子を編集し、Webアプリケーションの構成を完全なものにしてください。

Webアプリケーションのセキュリティ

Webアプリケーションにセキュリティを設定するには、Webアプリケーション内の特定のURLパターンへのアクセスを制限するか、またはサーブレット・コードをプログラミングすることでセキュリティの呼出しを使用します。

実行時には、ユーザー名とパスワードがWebアプリケーションに該当するセキュリティ・レルムを使用して認証されます。web.xmlまたは、Webアプリケーションの管理コンソールを使用して作成された外部ポリシーで構成されているセキュリティ制約にしたがって、認可が確認されます。

実行時には、WebLogic Serverのアクティブなセキュリティ・レルムによって、Webアプリケーション・セキュリティ制約が指定のWebアプリケーション・リソースに適用されます。セキュリティ・レルムは複数の仮想ホスト間で共有されることに注意してください。

Webアプリケーションのセキュリティ構成の詳細な手順や例は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。WebLogicセキュリティの詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』を参照してください。

リダイレクト攻撃の回避

Webアプリケーション上のリクエストが別の場所にリダイレクトされる場合、レスポンス用に生成されるLocationヘッダーには、そのリクエストに格納されているHostヘッダーがデフォルトで使用されます。Hostヘッダーには、別のホスト名や別のパラメータを格納してなりすますことができるため、この動作を悪用して、サード・パーティに対してリダイレクト攻撃をしかけることができます。

こうした危険を回避するため、FrontendHost属性をWebServerMBeanまたはClusterMBeanで設定し、すべてのリダイレクトURLの送信先ホストを指定します。レスポンスのLocationヘッダーではFrontendHost属性で指定したホストが使用され、元のリクエストに格納されていたホスト情報は使用されません。

詳細は、Oracle WebLogic Server MBean リファレンスのFrontendHostを参照してください。

P3Pプライバシ・プロトコル

Platform for Privacy Preferences (P3P)は、Webサイトにおいて機械可読形式の構文によるプライバシ・ポリシーを公開できる方法を提供します。WebLogic Server Webアプリケーション・コンテナは、P3Pをサポートできます。

p3p.xmlファイルの場所をブラウザに伝える方法は3つあります。

- ポリシー参照ファイルを「周知の場所(well-known location)」(サイト上の場所/w3c/p3p.xml)に置きます。

- Webサイトからの各レスポンスに、ポリシー参照ファイルの場所を示す特別なHTTPヘッダーを追加します。

- サイト上の各HTMLページ内にポリシー参照ファイルへのリンクを設けます。

詳細は、http://www.w3.org/TR/p3pdeployment#Locating_PRFを参照してください。

Linuxブラウザでの特殊文字の表示

Linuxブラウザで特殊文字を表示するには、JVMのfile.encodingシステム・プロパティをISO8859_1に設定します。たとえば、java -Dfile.encoding=ISO8859_1 weblogic.Serverのように指定します。詳細なリストについては、http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.htmlを参照してください。

3 Webアプリケーションの作成と構成

次の項では、Webアプリケーション・リソースを作成および構成する方法について説明します。

- WebLogic WebアプリケーションとJava EE

- ディレクトリ構造

- Webアプリケーションの作成と構成の主な手順

- クライアントによるWebアプリケーションへのアクセス方法の構成

- Webアプリケーション用の仮想ホストの構成

- 仮想ホストへのWebアプリケーションの割当て

- サーブレット、コンテキスト・リスナー、およびフィルタのロード

- 共有Java EE Webアプリケーション・ライブラリ

WebLogic WebアプリケーションとJava EE

Java Platform, Enterprise Edition (Java EE)バージョン5.0プログラミング・モデルの重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。詳細は、http://www.oracle.com/technetwork/java/javaee/documentation/index.htmlを参照してください。

Java EEアノテーションの使用により、標準のapplication.xmlおよびweb.xmlデプロイメント記述子は省略可能になりました。Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDK 5.0アノテーション機能を採用しています。第8章「Webコンポーネント用のWebLogicアノテーション」およびhttp://download.oracle.com/javaee/5/api/を参照してください。

ただし、WebLogic ServerにデプロイされるWebアプリケーションは、標準のJava EEデプロイメント記述子ファイルとWebLogic固有のデプロイメント記述子ファイルを引き続き使用して、それらのリソースと操作属性を定義できます。

ディレクトリ構造

Webアプリケーションは、Java EE仕様で定義されている標準ディレクトリ構造を採用しています。Webアプリケーションは、このディレクトリ構造を使用するファイルの集合としてデプロイする(展開ディレクトリ形式)か、WARファイルと呼ばれるアーカイブ・ファイルとしてデプロイできます。展開されたWebアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、Webアプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。

WEB-INFディレクトリには、Webアプリケーションのデプロイメント記述子(web.xmlおよびweblogic.xml)と、コンパイル済みJavaクラスおよびライブラリJARファイルを格納するための2つのサブディレクトリが格納されます。サブディレクトリの名前はclassesとlibです。JSP taglibは、ステージング・ディレクトリの最上位のWEB-INFディレクトリに格納されます。Javaクラスには、サーブレット、ヘルパー・クラス、およびコンパイル済みのJSP (必要に応じて)などがあります。

Webアプリケーションに属するすべてのサーブレット、クラス、静的ファイル、およびその他のリソースは、ディレクトリ階層に基づいて配置されます。

ステージングが終了したら、jarコマンドを使用してディレクトリ全体をWARファイルにまとめます。WARファイルは、それのみでデプロイすることも、他のWebアプリケーション、EJBコンポーネント、WebLogic Serverコンポーネントといった他のアプリケーション・コンポーネントとともにエンタープライズ・アプリケーションの一部としてデプロイする(推奨)こともできます。

JSPページとHTTPサーブレットは、WebLogic Serverで使用可能なすべてのサービスとAPIにアクセスできます。これらのサービスには、EJB、Java Database Connectivity (JDBC)を介したデータベース接続、JavaMessaging Service (JMS)、XMLなどがあります。

WEB-INFの情報へのアクセス

WEB-INFディレクトリは、アプリケーションのパブリック・ドキュメント・ツリーの一部ではありません。WEB-INFディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INFディレクトリのコンテンツは、ServletContextに対するgetResourceおよびgetResourceAsStream()メソッド呼出しを使用するサーブレット・コードや、RequestDispatcherでのinclude/forwardから認識できます。したがって、サーブレット・コードから、Webクライアントに直接公開されるべきでないアプリケーション固有の構成情報へのアクセスを必要とする場合、アプリケーション開発者はこれをこのディレクトリの下に置くことができます。

リクエストは、大文字と小文字を区別してリソース・マッピングと照合されるので、たとえば「/WEB-INF/foo」、「/WEb-iNf/foo」に対するクライアント・リクエストの結果として、/WEB-INFの下に置かれたWebアプリケーションのコンテンツや、なんらかの形のそのディレクトリ・リストが返されることはありません。

ディレクトリ構造の例

次にWebアプリケーションのディレクトリ構造の例を示します。ここでは、myWebApp/がステージング・ディレクトリです。

例3-1 Webアプリケーションのディレクトリ構造

myWebApp/
WEB-INF/
web.xml
weblogic.xml
lib/
MyLib.jar
classes/
MyPackage/
MyServlet.class
index.html
index.jsp

Webアプリケーションの作成と構成の主な手順

分割開発ディレクトリ構造を使用し、エンタープライズ・アプリケーションの一部としてWebアプリケーションを作成する手順を次に示します。『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の作成に関する項、分割開発ディレクトリでのアプリケーションのビルドに関する項、および分割開発ディレクトリからのデプロイメントとパッケージ化に関する項を参照してください。

WebLogic Serverに付属の開発者向けツールを使用してWebアプリケーションを作成および構成できます。「Webアプリケーション開発者向けツール」を参照してください。

ステップ1: エンタープライズ・アプリケーション・ラッパーの作成

1. ルートEARファイルのディレクトリを作成します。

\src\myEAR\

2. 次のように環境を設定します。

- Windowsの場合は、server\bin\ディレクトリにあるsetWLSEnv.cmdコマンドを実行します。serverはWebLogic Serverがインストールされている最上位ディレクトリです。

- UNIXの場合は、server/bin/ディレクトリにあるsetWLSEnv.shコマンドを実行します。serverはWebLogic Serverがインストールされている最上位ディレクトリで、domainはドメインの名前です。

3. 次のように、\src\myEAR\ディレクトリにエンタープライズ・アプリケーションをパッケージ化します。

1. エンタープライズ・アプリケーション記述子(application.xmlおよびweblogic-application.xml)をMETA-INF\ディレクトリに入れます。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子に関する項を参照してください。

2. 必要に応じてデプロイメント記述子を編集し、エンタープライズ・アプリケーションの動作を微調整します。「Webアプリケーション開発者向けツール」を参照してください。

3. 次の場所にエンタープライズ・アプリケーションの.jarファイルを置きます。

\src\myEAR\APP-INF\lib\

ステップ2: Webアプリケーションの作成

1. EARファイルのルートにWebアプリケーションのディレクトリを作成します。

\src\myEAR\myWebApp

2. 次のように、\src\myEAR\myWebApp\ディレクトリにWebアプリケーションをパッケージ化します。

1. Webアプリケーション記述子(web.xmlおよびweblogic.xml)を\src\myEAR\myWebApp\WEB-INF\ディレクトリに入れます。付録B「weblogic.xmlデプロイメント記述子の要素」を参照してください。

2. 必要に応じてデプロイメント記述子を編集し、エンタープライズ・アプリケーションの動作を微調整します。「Webアプリケーション開発者向けツール」を参照してください。

3. すべてのHTMLファイル、JSP、イメージ、その他Webアプリケーションによって参照されるすべてのファイルを、Webアプリケーションのルートに置きます。

\src\myEAR\myWebApp\images\myimage.jpg
\src\myEAR\myWebApp\login.jsp
\src\myEAR\myWebApp\index.html

4. 次の場所に、WebアプリケーションのJavaソース・ファイル(サーブレット、タグ・ライブラリ、サーブレットまたはタグ・ライブラリによって参照されるその他のクラス)を置きます。

\src\myEAR\myWebApp\WEB-INF\src\

ステップ3: build.xmlファイルの作成

ディレクトリ構造を設定したら、weblogic.BuildXMLGenユーティリティを使用してbuild.xmlファイルを作成します。

ステップ4: 分割開発ディレクトリ構造におけるAntタスクの実行

1. wlcompile Antタスクを実行してjavacコンパイラを呼び出します。これにより、WebアプリケーションのJavaコンポーネントが出力ディレクトリ/build/myEAR/WEB-INF/classesにコンパイルされます。

2. wlappc Antタスクを実行してappcコンパイラを起動します。これにより、デプロイメントのためのJSPおよびコンテナ固有のEJBクラスがすべてコンパイルされます。

3. wldeploy Antタスクを実行して、Webアプリケーションをアーカイブされた、または展開されたEARの一部として、WebLogic Serverにデプロイします。

4. 本番環境(開発環境でなく)の場合は、wlpackage Antタスクを実行してWebアプリケーションをアーカイブされた、または展開されたEARの一部としてパッケージ化します。

注意:

wlpackage Antタスクは、構築ディレクトリにコンパイルされたバージョンのJavaソース・ファイルを配置します。例: /build/myEAR/myWebApp/classes

クライアントによるWebアプリケーションへのアクセス方法の構成

クライアントがWebアプリケーションにアクセスするために使用するURLは、次のパターンで作成します。

http://hoststring/ContextPath/servletPath/pathInfo

ここで

- hoststringは、hostname:portNumberまたは仮想ホストにマップされるホスト名。

- ContextPathは、Webアプリケーションの名前。

- servletPathは、servletPathにマップされるサーブレット。

- pathInfoは、URLの残りの部分(通常はファイル名)。

仮想ホスティングを使用している場合、URLのhoststringの部分を仮想ホスト名に置き換えることができます。

Webアプリケーション用の仮想ホストの構成

WebLogic Serverでは、Webアプリケーション用の仮想ホストを構成する2つの方法をサポートしています。

- チャネル・ベースの仮想ホストの構成

- ホスト・ベースの仮想ホストの構成

チャネル・ベースの仮想ホストの構成

以下は、チャネル・ベースの仮想ホストの構成方法のサンプルです。

<VirtualHost Name="channel1vh" NetworkAccessPoint="Channel1" Targets="myserver"/>
<VirtualHost Name="channel2vh" NetworkAccessPoint="Channel2" Targets="myserver"/>

Channel1およびChannel2は、config.xmlファイル内で構成されるNetworkAccessPointの名前です。NetworkAccessPointは、仮想ホストがHTTPリクエストを処理する専用のサーバー・チャネル名を表します。特定のHTTPリクエストのNetworkAccessPointがどの仮想ホストのNetworkAccessPointとも一致しない場合は、正しい仮想ホストを解決するため、受信HOSTヘッダーはVirtualHostNamesと比較されます。受信したリクエストが仮想ホストと一致しない場合、それはデフォルトのWebサーバーによって処理されます。

ホスト・ベースの仮想ホストの構成

以下は、ホスト・ベースの仮想ホストの構成方法のサンプルです。

<VirtualHost Name="cokevh" Targets="myserver" VirtualHostNames="coke"/>
<VirtualHost Name="pepsivh" Targets="myserver" VirtualHostNames="pepsi"/>

仮想ホストへのWebアプリケーションの割当て

Webアプリケーション・コンポーネントは、WebLogic 管理コンソールを使用してサーバーおよび仮想ホストに割り当てることができます。

以前のバージョンのWebLogic Serverから移行している場合は、config.xmlファイルのtargets属性で、すべてのWebアプリケーションのターゲットを指定する必要があります。targets属性は、仮想ホスト属性に取って代わっており、仮想ホストは同一ドメイン内でサーバーまたはクラスタと同じ名前を持つことはできません。以下は、Webアプリケーションを仮想ホストに割り当てる方法の例です。

<AppDeployment name="test-app" Sourcepath="/myapps/test-app.ear">
<SubDeployment Name="test-webapp1.war" Targets="virutalhost-1"/>
<SubDeployment Name="test-webapp2.war" Targets="virtualhost-2"/>
...
</AppDeployment>

サーブレット、コンテキスト・リスナー、およびフィルタのロード

サーブレット、コンテキスト・リスナー、およびフィルタは、次の順序でロードおよび破棄されます。

ロードの順序:

1. コンテキスト・リスナー

2. フィルタ

3. サーブレット

破棄の順序:

1. サーブレット

2. フィルタ

3. コンテキスト・リスナー

サーブレットおよびフィルタは、web.xmlファイルでの定義順と同じ順序でロードされ、その逆の順序でアンロードされます。コンテキスト・リスナーは、次の順序でロードされます。

1. web.xmlファイル内のすべてのコンテキスト・リスナー(ファイルでの指定順)

2. タグ・ライブラリ記述子が含まれるパッケージ化されたJARファイル

3. WEB-INFディレクトリ内のタグ・ライブラリ記述子

共有Java EE Webアプリケーション・ライブラリ

Java EE Webアプリケーション・ライブラリは、デプロイメント時にJava EEアプリケーション・コンテナに登録されるスタンドアロンWebアプリケーション・モジュールです。WebLogic Serverを使用すると、複数のWebアプリケーションで簡単に単一のWebアプリケーション・モジュールまたはモジュールの集合を共有できます。

Webアプリケーションは、1つ以上のWebアプリケーション・ライブラリを参照できますが、その他の種類のライブラリ(EJB、EARファイル、プレーンJARファイル)は参照できません。Webアプリケーション・ライブラリは、ライブラリとしてデプロイされるWebアプリケーション・モジュールです。これらは、weblogic-application.xmlファイル内のアプリケーション・ライブラリの参照に使用されるものと同じ構文を用いてweblogic.xmlファイルから参照されます。ただし、<context-root>要素は無視されます。

デプロイメント時に、参照された各ライブラリのクラスパスが、Webアプリケーションのクラスパスに付加されます。したがって、すべてのリソースおよびクラスに対する検索は、まず元のWebアプリケーション内で行われ、次に参照されたライブラリ内で行われます。

デプロイメント・ツール、appc、wlcompile、およびBuildXMLGenは、アプリケーション・レベルでライブラリをサポートするのと同じように、Webアプリケーション・レベルでライブラリをサポートします。共有J2EEライブラリとそのデプロイメントの詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有J2EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

4 サーブレットの作成と構成

次の項では、サーブレットを作成および構成する方法について説明します。

- サーブレットの構成

- デフォルト・サーブレットの設定

- サーブレット初期化属性

- 単純なHTTPサーブレットの記述

- 高度な機能

- HelloWorldServletサンプルの全文

- サーブレット・コンテナのデバッグ

サーブレットの構成

Java EEメタデータ・アノテーションの使用により、標準のweb.xmlデプロイメント記述子は省略可能になりました。Servlet 2.5仕様では、サーブレット、フィルタ、リスナー、タグ・ハンドラなどの特定のWebコンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存関係を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル・メソッドが呼び出される前に必要な依存関係を注入します。第8章「Webコンポーネント用のWebLogicアノテーション」を参照してください。

ただし、サーブレットは、標準のWebアプリケーション・デプロイメント記述子web.xmlの複数のエントリでWebアプリケーションの一部としても定義できます。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。

web.xmlのルートservlet要素の下の最初のエントリには、サーブレットの名前が定義され、そのサーブレットを実行するコンパイル済みクラスが指定されます。あるいは、サーブレット・クラスを指定するかわりに、JSPを指定することもできます。servlet要素には、サーブレットの初期化属性とセキュリティ・ロール用の定義も含まれています。

web.xml内のservlet-mapping要素の下の2番目のエントリには、このサーブレットを呼び出すURLパターンが定義されています。

サーブレット・マッピング

サーブレット・マッピングとは、サーブレットへのアクセス方法を制御することです。次の例は、Webアプリケーションでサーブレット・マッピングを使用する方法を示しています。この例には、(web.xmlデプロイメント記述子の)サーブレット構成とマッピングがあり、その後にこれらのサーブレットの起動に使用するURLを示す表(「url-patternと呼び出されるサーブレット」を参照)があります。

一般的なサーブレット・マッピングのルールや規約など、サーブレット・マッピングの詳細は、Servlet 2.5仕様のセクション11を参照してください。

例4-1 サーブレット・マッピングの例

<servlet>
<servlet-name>watermelon</servlet-name>
<servlet-class>myservlets.watermelon</servlet-class>
</servlet>
<servlet>
<servlet-name>garden</servlet-name>
<servlet-class>myservlets.garden</servlet-class>
</servlet>
<servlet>
<servlet-name>list</servlet-name>
<servlet-class>myservlets.list</servlet-class>
</servlet>
<servlet>
<servlet-name>kiwi</servlet-name>
<servlet-class>myservlets.kiwi</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>watermelon</servlet-name>
<url-pattern>/fruit/summer/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>garden</servlet-name>
<url-pattern>/seeds/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>list</servlet-name>
<url-pattern>/seedlist</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>kiwi</servlet-name>
<url-pattern>*.abc</url-pattern>
</servlet-mapping>

表4-1 url-patternと呼び出されるサーブレット

URL

呼び出されるサーブレット

http://host:port/mywebapp/fruit/summer/index.html

watermelon

http://host:port/mywebapp/fruit/summer/index.abc

watermelon

http://host:port/mywebapp/seedlist

list

http://host:port/mywebapp/seedlist/index.html

デフォルト・サーバー(構成されている場合)、またはHTTP 404エラー・メッセージ(「File not found」)。

listサーブレットが/seedlist*にマップされていた場合、listサーブレットが呼び出されます。

http://host:port/mywebapp/seedlist/pear.abc

kiwi

listサーブレットが/seedlist*にマップされていた場合、listサーブレットが呼び出されます。

http://host:port/mywebapp/seeds

garden

http://host:port/mywebapp/seeds/index.html

garden

http://host:port/mywebapp/index.abc

kiwi

ServletServletは、サーブレットのデフォルト・マッピングの作成に使用できます。たとえば、http://host:port/web-app-name/myservlet/com/foo/FooServletを使用してサーブレットを呼び出せるように/myservlet/*に対するすべてのサーブレットにマップするデフォルト・マッピングを作成するには、web.xmlファイルに以下の部分を追記します。(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)

<servlet>
<servlet-name>ServletServlet</servlet-name>
<servlet-class>weblogic.servlet.ServletServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ServletServlet</servlet-name>
<url-pattern>/myservlet/*</url-pattern>
</servlet-mapping>

デフォルト・サーブレットの設定

各Webアプリケーションには、デフォルト・サーブレットがあります。このデフォルト・サーブレットは管理者が指定できますが、指定しない場合、WebLogic ServerではFileServletという内部サーブレットがデフォルト・サーブレットとして使用されます。

どのサーブレットでも、デフォルト・サーブレットとして登録できます。独自のデフォルト・サーブレットを作成すれば、独自のロジックを使用して、デフォルト・サーブレットに送られるリクエストの処理方法を定義できます。

設定したデフォルト・サーブレットは、FileServletに取って代わります。FileServletはほとんどのファイル(テキスト・ファイル、HTMLファイル、イメージ・ファイルなど)を提供するために使用されるので、デフォルト・サーブレットの設定は注意深く行う必要があります。デフォルト・サーブレットでこれらのファイルを提供するには、その機能をデフォルト・サーブレットに記述する必要があります。

ユーザー定義のデフォルト・サーブレットを設定するには:

1. 「クライアントによるWebアプリケーションへのアクセス方法の構成」の説明に従い、サーブレットを定義します。

2. 次のように、servlet-mappingにurl-pattern = "/"を付けて追加します。

<servlet-mapping>
<servlet-name>MyOwnDefaultServlet</servlet-name>
<url-pattern>/myservlet/*(</url-pattern>
</servlet-mapping>

3. FileServletで他の拡張子付きのファイルを提供する場合は、次の手順に従います。

1. サーブレットを定義し、myFileServletなどの<servlet-name>を指定します。

2. <servlet-class>をweblogic.servlet.FileServletと定義します。

3. <servlet-mapping>要素を使ってファイル拡張子をmyFileServletにマップします(デフォルト・サーブレット用のマッピングに追加して)。たとえば、myFileServletで.gifファイルを提供するには、*.gifをmyFileServletにマップします。

注意:

docHomeパラメータ(このリリースで非推奨になった)が指定されていない場合、ソース・ファイル名決定時のFileServletには、SERVLET_PATHが含まれています。そのため、FileServletを/dir/*などにマップすることで、特定のディレクトリからのファイルのみを明示的に提供できます。

サーブレット初期化属性

サーブレットの初期化属性は、Webアプリケーションのデプロイメント記述子web.xmlの中のservlet要素のinit-param要素に、param-nameタグとparam-valueタグを使って定義します。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。例:

例4-2 web.xml内のサーブレット初期化属性の構成例

<servlet>
<servlet-name>HelloWorld2</servlet-name>
<servlet-class>examples.servlets.HelloWorld2</servlet-class>
<init-param>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
</init-param>
<init-param>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
</init-param>
</servlet>

単純なHTTPサーブレットの記述

この項では、Hello Worldというメッセージを出力する単純なHTTPサーブレットを記述する手順について説明します。これらの手順を示すサンプル・コード(HelloWorldServlet)の全文がこの項の最後にあります。JDBC、RMI、JMSなど各種のJava EEおよびWebLogic Serverサービスをサーブレットで使用する方法の詳細は、このドキュメントで後述します。

1. 以下の適切なパッケージおよびクラスをインポートします。

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

2. javax.servlet.http.HttpServletを拡張します。例:

public class HelloWorldServlet extends HttpServlet{

3. service()メソッドを実装します。
サーブレットの主要な機能は、WebブラウザからのHTTPリクエストを受け取って、HTTPレスポンスを戻すことです。この処理は、サーブレットのservice()メソッドによって行われます。サービス・メソッドには、出力を生成するレスポンス・オブジェクトと、クライアントからのデータを受け取るリクエスト・オブジェクトがあります。

ほかにも、doPost()メソッドまたはdoGet()メソッドを実装したサーブレットのサンプルを見たことがあるかもしれません。これらのメソッドは、POSTまたはGETリクエストにのみ応答するものです。service()メソッドを実装しておけば、1つのメソッドですべてのリクエスト・タイプを処理できます。(ただし、service()メソッドを実装する場合、service()メソッドの最初でsuper.service()を呼び出さない限り、doPost()メソッドまたはdoGet()メソッドを実装することはできません。)HTTPサーブレットの仕様には、他のリクエスト・タイプの処理に使用される他のメソッドも記述されていますが、これらのメソッドは全部まとめてserviceメソッドと総称されています。

サービス・メソッドはすべて、同じパラメータ引数を取ります。HttpServletRequestは、リクエストの情報を提供し、HttpServletResponseはHTTPクライアントに応答する際にサーブレットによって使用されます。サービス・メソッドは次のようになります。

public void service(HttpServletRequest req,
HttpServletResponse res) throws IOException
{

4. 次のように、コンテンツ・タイプを設定します。

res.setContentType("text/html");

5. 次のように、出力に使用するjava.io.PrintWriterオブジェクトへの参照を取得します。

PrintWriter out = res.getWriter();

6. 次の例に示すように、PrintWriterオブジェクトに対しprintln()メソッドを使用して、HTMLを生成します。

out.println("<html><head><title>Hello World!</title></head>");
out.println("<body><h1>Hello World!</h1></body></html>");
}
}

7. サーブレットを次のようにコンパイルします。

1. 開発環境シェルの設定を、クラスパスとパスを正しく指定して行います。

2. サーブレットのJavaソース・コードが格納されているディレクトリから、サーブレットが格納されているWebアプリケーションのWEB-INF/classesディレクトリに、サーブレットをコンパイルします。例:

javac -d /myWebApplication/WEB-INF/classes myServlet.java

8. WebLogic ServerにホストされるWebアプリケーションの一部として、サーブレットをデプロイします。

9. ブラウザからサーブレットを呼び出します。
サーブレットの呼出しに使用するURLは、以下によって決まります。

- そのサーブレットを含むWebアプリケーションの名前、および

- Webアプリケーションのデプロイメント記述子にマップされるサーブレットの名前。リクエスト・パラメータも、サーブレットを呼び出すURLに含まれます。

一般的には、サーブレットのURLは以下のパターンに従います。

http://host:port/webApplicationName/mappedServletName?parameter

URLの各要素は次のように定義します。

- hostは、WebLogic Serverが稼動しているマシンの名前。

- portは、上記マシンがHTTPリクエストをリスニングしているポート。

- webApplicationNameは、サーブレットが含まれるWebアプリケーションの名前。

- parameterは、サーブレットで使用できるブラウザから送信された情報が含まれる、1つまたは複数の名前と値の組み合わせ。

たとえば、examplesWebAppにデプロイされ、使用中のマシンで稼動しているWebLogic Serverから提供されるHelloWorldServlet (このドキュメントで使われているサンプル)をWebブラウザで呼び出す場合、次のようなURLを入力します。

http://localhost:7001/examplesWebApp/HelloWorldServlet

URLのhost:port部分は、WebLogic ServerにマップされているDNS名に置き換えることもできます。

高度な機能

上記の手順で、基本的なサーブレットが作成できます。サーブレットでは、さらに高度な機能を使用することもできます。

- HTML形式のデータ処理 - HTTPサーブレットでは、ブラウザ・クライアントからのHTMLフォームによるデータを受け取り、処理できます。

- クライアント入力の取得

- アプリケーションの設計 - HTTPサーブレットでは、様々な方法でアプリケーションを設計できます。サーブレットの記述に関する詳細は、次の項を参照してください。

- HTTPレスポンスの提供

- HTTPサーブレットにおけるスレッドの問題

- 別のリソースへのリクエストのディスパッチ

- サーブレットの初期化 - サーブレットの初期化時に、データを初期化する、初期化引数を受け取るなどのアクションを実行する必要がある場合は、init()メソッドをオーバーライドできます。

- サーブレットの初期化

- サーブレットにおけるセッションおよび永続性の使用 - セッションと永続性により、HTTPセッション中、およびHTTPセッション間でユーザーを追跡できます。セッション管理には、Cookieの使用も含まれます。詳細は、次の項を参照してください。

- サーブレットからのセッション・トラッキング

- サーブレットでのCookieの使用方法

- セッションの永続性の構成

- サーブレットにおけるWebLogicサービスの使用 - WebLogic Serverが提供する様々なサービスやAPIをWebアプリケーションで使用できます。サービスには、Java Database Connectivity (JDBC)ドライバ、JDBCデータベース接続プール、Java Messaging Service (JMS)、Enterprise JavaBeans (EJB)、Remote Method Invocation (RMI)などがあります。詳細は、次の項を参照してください。

- HTTPサーブレットからのWebLogicサービスの使用方法

- データベースへのアクセス

HelloWorldServletサンプルの全文

この項では、前述の手順で使用したサンプルJavaソース・コードの全文を示します。このサンプルはHTTPリクエストにレスポンスする簡単なサーブレットです。このドキュメントの後半では、このサンプルを拡張することにより、HTTPパラメータ、Cookie、およびセッション・トラッキングの使用方法を説明します。

例4-3 HelloWorldServlet.java

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class HelloWorldServlet extends HttpServlet {
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException
{
// Must set the content type first
res.setContentType("text/html");
// Now obtain a PrintWriter to insert HTML into
PrintWriter out = res.getWriter();
out.println("<html><head><title>" +
"Hello World!</title></head>");
out.println("<body><h1>Hello World!</h1></body></html>");
}
}

WebLogic Server配布キットのsamples/examples/servletsディレクトリに、このソース・コードと、サンプルをコンパイルして実行するための手順説明があります。

サーブレット・コンテナのデバッグ

次の項では、WebLogic Serverサーブレット・コンテナで利用可能なデバッグ・オプションについて説明します。

- アクセス・ロギングの無効化

- 特定セッションのデバッグ

- リクエスト・ハンドルの処理内容の追跡

アクセス・ロギングの無効化

サーブレットのアクセスのロギングは、サーバーのパフォーマンスに関してはコスト高となる場合があります。したがって、アクセス・ロギングが不要な場合は、アクセス・ログ・ファイルへのロギングを無効化することによりパフォーマンスを向上できます。

使用方法

weblogic.xmlのcontainer-descriptorで指定可能なaccess-logging-disabledプロパティは、基底のWebアプリケーションのアクセス・ロギングを無効化するかどうか指定する際に使用することができます。

- このプロパティをtrueに設定すると、アプリケーション・アクセスはロギングされません。

- このプロパティを指定しないか、falseに設定すると、アプリケーション・アクセスがロギングされます。

注意:

disable-access-loggingプロパティは、Webアプリケーション・レベルで機能します。したがって、このプロパティを1つのWebアプリケーションで定義しても、他のWebアプリケーションには影響しません。このプロパティは、開発モードと本番モードの両方で機能します。

例

次に、アクセス・ロギングを無効化する方法の例を示します。

<?xml version="1.0" encoding="ISO-8859-1"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<container-descriptor>
<access-logging-disabled>true</access-logging-disabled>
</container-descriptor>
</weblogic-web-app>

特定セッションのデバッグ

セッション変化の追跡は、特にレプリケートされるセッションに関して、アプリケーションの開発時に大いに役立ちます。HttpSessionAttributeListenerを利用すると、セッションの変化をWebアプリケーション・レベルで追跡できますが、開発者は、特定のリクエスト時にセッション変化を追跡するため、より詳細なデバッグ・オプションを指定する必要があります。

使用方法

wl_debug_sessionリクエスト属性または同じ名前のセッション属性は、現在のセッションにおける属性の変化をロギングすることができます。いずれかのフラグを使用すると、基底のセッションの変更がコンテナによってサーバー・ログに記録されます。

以下のいずれかの方法で特定セッションのデバッグを有効化することができます。

- 次に示すように、wl_debug_session属性を現在のセッションに設定します。

- session.setAttribute('wl_debug_session', Boolean.TRUE);

- wl_debug_session属性を、リクエスト問合せ文字列でインジケータとして使用します。wl_debug_sessionセッション属性は、コンテナにより現在のセッションに追加されます。次の例を参照してください。

http://localhost/foocontext/foo?wl_debug_session

セッションのデバッグを停止するには、単にwl_debug_session属性を削除します。

注意:

この機能は開発モードでのみ使用できます。デバッグ・メッセージの重大度は、debugレベルです。システム・ロガーがデバッグ・メッセージをサーバー・ログ・ファイルに出力できるように、ロガーの重大度はdebug以下に調整する必要があります。

リクエスト・ハンドルの処理内容の追跡

リクエスト・ハンドルの処理内容の追跡は、アプリケーション開発モードの場合に大いに役立ちます。たとえば、アプリケーションのデバッグ時には多くの情報が必要になります。これには、どのようなリクエストを受信したか、そのリクエストがどのようにディスパッチされたか、どのセッションにバインドされたか、サーブレットがいつ関与したか、どのようなレスポンスが送信されたかなどの情報が含まれます。最後に、ServletExceptionが発生したら、エラーの原因を探るため、その例外を対応するリクエストに結び付ける方法が必要となります。

使用方法

WebLogic Serverサーブレット・コンテナでは、より詳細なログ・メッセージがリクエストの処理時に提供されるため、リクエスト・フロー内の各マイルストンがより詳細に表現されます。DebugHttpロガーを有効化する以外、構成を変更する必要はありません。

このようにすると、リクエスト・ハンドルの処理内容をサーバー・ログで見つけることができます。本番モードに移行したら、DebugHttpロガーを無効化し、サーバーのパフォーマンスを最大化する必要があります。

5 JSPの作成と構成

次の項では、JSPを作成および構成する方法について説明します。

- WebLogic JSPとJava EE

- Java Server Pages (JSP)の構成

- JSPのサーブレットとしての登録

- JSPタグ・ライブラリの構成

- ウェルカム・ファイルの構成

- HTTPエラー・レスポンスのカスタマイズ

- HTTPリクエストのエンコーディングの識別

- IANA文字セットのJava文字セットへのマッピング

- JSPの最初と最後での暗黙的インクルードの構成

- JSPプロパティ・グループの構成

- XML構文を使用したJSPドキュメントの記述

WebLogic JSPとJava EE

WebLogic JSPでは、JSP 2.1仕様(http://www.oracle.com/technetwork/java/javaee/jsp/index.html)をサポートしています。Java EEの主要なテーマは、開発の容易さです。プラットフォームのWeb層では、以下の2つの点で開発の容易さが大幅に向上しています。1つめは、プラットフォームにJavaServer Pages Standard Tag Library (JSTL)技術とJavaServer Faces技術が組み込まれていることです。2つめは、Java EEでのWebアプリケーション開発を非常に容易にする一連の機能(JavaServer Faces技術タグとJavaServer Pages (JSP)ソフトウェア・コードとの緊密な連携など)がすべてのWeb層技術で提供されることです。

Java Server Pages (JSP)の構成

Java Server Pages (JSP)ファイルをデプロイするには、Webアプリケーションのルート(またはルートの下のサブディレクトリ)に格納する必要があります。JSP構成パラメータは、WebLogic固有のデプロイメント記述子であるweblogic.xmlのjsp-descriptor要素の下位要素に定義します。これらのパラメータは次の機能を定義します。

- JSPコンパイラのオプション

- デバッグ

- 再コンパイルが必要になる更新したJSPをWebLogic Serverがチェックする頻度

- 文字エンコーディング

これらの下位要素の詳細は、付録B「jsp-descriptor」を参照してください。

JSPのサーブレットとしての登録

JSPは、Java EE標準のデプロイメント記述子web.xmlのservlet要素を使用して、サーブレットとして登録できます。(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)サーブレット・コンテナは、既知のサーブレットのマップを保持します。このマップは、コンテナに対するリクエストを解決するために使われます。このマップにエントリを追加することを、サーブレットを「登録する」と言います。このマップへのエントリの追加は、web.xmlのservlet-mappingエントリでservlet要素を参照することによって行います。

JSPはサーブレットの一種です。JSPの登録は、サーブレット登録の特別なケースです。通常、JSPは最初の呼出し時にJSPファイルの名前に基づいて暗黙的に登録されます。したがって、myJSPfile.jspファイルはmyJSPfile.jspとしてマッピング表に登録されます。次の例に示すように、JSPを暗黙的に登録することができます。次の例では、myJSPfile.jspという暗黙的な名前ではなく、/mainという名前を指定してJSPをリクエストしています。

次の例で、/mainを含むURLはmyJSPfile.jspを起動します。

<servlet>
<servlet-name>myFoo</servlet-name>
<jsp-file>myJSPfile.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>myFoo</servlet-name>
<url-pattern>/main</url-pattern>
</servlet-mapping>

JSPをサーブレットとして登録することによって、サーブレットに対して行うのと同様に、ロード順、初期化属性、およびセキュリティ・ロールをJSPに指定できます。

JSPタグ・ライブラリの構成

WebLogic Serverでは、カスタムJSPタグを作成および使用できます。カスタムJSPタグは、JSPページ内から呼び出すことができるJavaクラスです。カスタムJSPタグを作成するには、それらをタグ・ライブラリに登録して、それらの動作をタグ・ライブラリ記述子(TLD)ファイルに定義します。このTLDは、JSPが組み込まれているWebアプリケーションで使用できなければなりません。そのためには、Webアプリケーション・デプロイメント記述子にそのTLDを定義します。TLDファイルは、WebアプリケーションのWEB-INFディレクトリに格納してください。このディレクトリは、外部には公開されません。

Webアプリケーション・デプロイメント記述子には、タグ・ライブラリのURIパターンを定義します。このURIパターンは、JSPページのtaglibディレクティブの値と一致する必要があります。また、TLDの格納場所も定義します。たとえば、JSPページに次のtaglibディレクティブがあるとします。

<%@ taglib uri="myTaglib" prefix="taglib" %>

また、TLDがWebアプリケーションのWEB-INFディレクトリに格納されているとします。この場合、Webアプリケーション・デプロイメント記述子に次のエントリを作成します。

<jsp-config>
<taglib>
<taglib-uri>myTaglib</taglib-uri>
<tablig-location>WEB-INF/myTLD.tld</taglib-location>
</taglib>
</jsp-config>

タグ・ライブラリは、.jarファイルとしてもデプロイできます。

カスタムJSPタグ・ライブラリの作成については、Oracle WebLogic Server JSPタグ拡張のプログラミングを参照してください。

WebLogic Serverには、アプリケーションで使用できるカスタムJSPタグがいくつか付属しています。これらのタグを使用すると、キャッシング、問合せ属性ベースのフロー制御の効率化、およびオブジェクト・セットに対する反復処理の効率化を行うことができます。詳細は、次を参照してください。

- 第16章「カスタムWebLogic JSPタグ(cache、process、repeat)の使用方法」

- 第15章「WebLogic JSPフォーム検証タグの使用方法」

ウェルカム・ファイルの構成

Webアプリケーション開発者は、Webアプリケーション・デプロイメント記述子内で、ウェルカム・ファイルと呼ばれる部分URIの順序付けされたリストを定義できます。このメカニズムの目的は、WebコンポーネントにマップされていないWAR内のディレクトリ・エントリに対応するURIに対するリクエストがあった場合に、コンテナがURIに付加するために使用する部分URIの順序付けされたリストを、デプロイヤが指定できるようにすることです。ユーザーは特定のファイル名を指定せずにURLを入力できるため、この機能によってサイトが使いやすくなります。

注意:

ウェルカム・ファイルは、JSP、静的ページ、またはサーブレットとすることができます。

ウェルカム・ファイルは、Webアプリケーション・レベルで定義します。サーバーが複数のWebアプリケーションのホストになっている場合は、Webアプリケーションごとに別個のウェルカム・ファイルを定義する必要があります。ウェルカム・ファイルは、web.xml内でwelcome-file-list要素を使用して定義します(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)ウェルカム・ファイルの構成例を次に示します。

例5-1 ウェルカム・ファイル例

<servlet>
<servlet-name>WelcomeServlet</servlet-name>
<servlet-class>foo.bar.WelcomeServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>WelcomeServlet</servlet-name>
<url-pattern>*.foo</url-pattern>
</servlet-mapping>

<welcome-file-list>
<welcome-file>/welcome.foo</welcome-file>
</welcome-file-list>

詳細は、http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specsの9.10項を参照してください。

HTTPエラー・レスポンスのカスタマイズ

WebLogic Serverを構成すると、特定のHTTPエラーまたはJava例外が発生したときに、標準のWebLogic Serverエラー・レスポンス・ページを使用するかわりに、カスタムWebページなどのHTTPリソースを使って応答させることができます。

カスタム・エラー・ページは、Java EE標準のWebアプリケーション・デプロイメント記述子(web.xml)のerror-page要素で定義します(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)

HTTPリクエストのエンコーディングの識別

WebLogic Serverは、HTTPリクエストに含まれるバイナリ(バイト)データを、サーブレットで予期される正しいエンコーディングに変換します。着信するPOSTデータは、request.getParameter(..)などのメソッドで使用するためにサーバー側で正しいエンコーディングに変換される必要のある、特定のエンコーディングでコード化されている場合があります。

コード・セットを定義する方法は2種類あります。

- POST処理では、HTML <form>タグでエンコーディングを設定できます。たとえば、次のformタグはコンテンツの文字セットにSJISを設定しています。

<form action="http://some.host.com/myWebApp/foo/index.html">
<input type="application/x-www-form-urlencoded; charset=SJIS">
</form>

フォームは、WebLogic Serverに読み込まれると、SJIS文字セットを使ってデータを処理します。

- 前述の例で、セミコロンの後ろにある情報はすべてのWebクライアントが転送するわけではないので、WebLogic固有のデプロイメント記述子であるweblogic.xmlにあるinput-charset要素を使って、リクエストに使用するコード・セットを設定できます。
java-charset-name下位要素は、リクエストのURLがresource-path下位要素で指定したパスを含んでいるときにデータを変換するエンコーディングを定義します。

以下の例では、パターン/foo/*にマップされるすべてのリクエスト・パラメータが、Java文字セットSJISを使用して確実にコード化されるようになっています。

<input-charset>
<resource-path>/foo/*</resource-path>
<java-charset-name>SJIS</java-charset-name>
</input-charset>

この方法はGET処理とPOST処理の両方で使用できます。

IANA文字セットのJava文字セットへのマッピング

文字セットを記述するためにInternet Assigned Numbers Authority (IANA)によって割り当てられる名前は、Javaで使用される名前とは異なることがあります。すべてのHTTP通信がIANA文字セット名を使用し、これらの名前は常に同じとは限らないので、WebLogic ServerはIANA文字セット名をJava文字セット名に内部でマップし、通常は正しいマッピングを判断できます。ただし、IANA文字セットをJava文字セットの名前に明示的にマッピングすると、あいまいさを解決することができます。

IANA文字セットをJava文字セットにマップするには、WebLogic固有のデプロイメント記述子であるweblogic.xmlのcharset-mapping要素で文字セット名を設定します。iana-charset-name要素にIANA文字セット名を定義し、java-charset-name要素にJava文字セット名を定義します。付録B「charset-mapping」を参照してください。

例:

<charset-mapping>
<iana-charset-name>Shift-JIS</iana-charset-name>
<java-charset-name>SJIS</java-charset-name>
</charset-mapping>

JSPの最初と最後での暗黙的インクルードの構成

Webアプリケーションのweb.xmlデプロイメント記述子の<jsp-property-group>要素内に、<include-prelude>要素と<include-coda>要素をそれぞれ追加することで、JSPページのグループに対しprelude (ヘッダーとも言います)およびcoda (フッターとも言います)を暗黙的にインクルードできます。それらの値は、コンテキストに相対的なパスであり、Webアプリケーション内の要素に対応している必要があります。それらの要素が存在する場合、指定されたパスが、プロパティ・グループ内の各JSPページの最初と最後に、それぞれ自動的に(includeディレクティブの場合のように)インクルードされます。グループ内に複数のincludeまたはcoda要素がある場合、それらは登場順にインクルードされます。複数のJSPプロパティ・グループがJSPページに適用される場合、対応する要素はJSP構成セクションに登場するのと同じ順序で処理されます。

ファイル/template/prelude.jspfおよび/template/coda.jspfについて考えてみます。次の例において、これらのファイルは各ファイルの最初と最後にコードを挿入するために使用されています。

例5-2 暗黙的インクルード

<jsp-config>
<jsp-property-group>
<display-name>WebLogicServer</display-name>
<url-pattern>*.jsp</url-pattern>
<el-ignored>false</el-ignored>
<scripting-invalid>false</scripting-invalid>
<is-xml>false</is-xml>
<include-prelude>/template/prelude.jspf</include-prelude>
<include-coda>/template/coda.jspf</include-coda>
</jsp-property-group>
</jsp-config>

JSPプロパティ・グループの構成

JSPプロパティ・グループとは、JSPページを表す一連のファイルに適用される、プロパティの集合です。これらのプロパティは、web.xmlデプロイメント記述子のjsp-property-group要素における1つまたは複数の下位要素で定義します。

JSPプロパティ・グループで定義されるほとんどのプロパティは、変換単位全体、つまりURLパターンによって照合されるリクエストされたJSPファイルと、includeディレクティブを使用してそこにインクルードされるすべてのファイルに対して、適用されます。例外は、page-encodingプロパティです。このプロパティは、URLパターンによって照合される各JSPファイルに個別に適用されます。JSPプロパティ・グループにおける適用可能性は、1つまたは複数のURLパターンによって定義されます。URLパターンには、Servlet 2.5仕様の第11章「Mapping Requests to Servlets」で定義されているものと同じ構文が使用されますが、これらのURLパターンがバインドされるのは変換時です。プロパティ・グループ内のすべてのプロパティは、URLパターンのいずれかに一致するWebアプリケーション内のリソースに適用されます。また、(JSPファイルのものであるという)暗黙的なプロパティが存在します。JSPプロパティ・グループは、タグ・ファイルには影響を与えません。

JSPプロパティ・グループのルール

以下は、JSPプロパティ・グループに適用されるルールの一部です。

- リソースが、servlet-mappingとjsp-property-groupの両方でURLパターンに一致している場合、最も特定的なパターンが適用される(Servlet仕様と同じルールに準拠)。

- URLパターンが同一の場合、servlet-mappingよりもjsp-property-groupが優先されます。

- 少なくとも1つのjsp-property-groupに、最も特定的な一致するURLパターンが含まれている場合、そのリソースはJSPファイルであると見なされ、そのjsp-property-groupのプロパティが適用されます。

- リソースがJSPファイルと見なされている場合、すべてのinclude-preludeおよびinclude-codaプロパティは、一致するURLパターンを備えたjsp-property-group要素から適用されます。「JSPの最初と最後での暗黙的インクルードの構成」を参照してください。

JSPプロパティ・グループの特長

次の目的のために、jsp-property-groupを構成できます。

- リソースがJSPファイルであることを示します(暗黙的)。

- JSP式言語(JSP EL)評価の無効化を制御します。

- スクリプト記述要素の無効化を制御します。

- ページのエンコーディング情報を示します。

- PreludeおよびCodaを自動的にインクルードします。

- リソースがJSPドキュメントであることを示します。

JSPプロパティ・グループの詳細は、http://www.oracle.com/technetwork/java/javaee/jsp/index.htmlのJSP 2.1仕様の第3章「JSP Configuration」を参照してください。

XML構文を使用したJSPドキュメントの記述

JSP 2.1仕様では、XML構文を活用できるようにすることで、JSPドキュメントのコンセプトの面で改良がなされています。また、JSPドキュメントは、プロパティ・グループを使用するように拡張されています。JSPドキュメントとは、XML構文を用いて記述されたJSPページです。JSPドキュメントは、暗黙的または明示的に、SPコンテナに対してそのようにJ記述される必要があり、その後JSPコンテナはそれらをXMLドキュメントとして処理し、整形式であるかどうかをチェックして、エンティティ宣言のようなリクエストがあればそれを適用します。JSPドキュメントは、標準的なJSPセマンティクスで動的コンテンツを生成するのに使用されます。

以下は、JSP標準タグ・ライブラリを使用して、ルート要素として表を有するXMLドキュメントを生成する、単純なJSPドキュメントの一例です。table要素には、値1、2、および3を格納する3つのrow下位要素があります。詳細およびその他のサンプルについては、http://www.oracle.com/technetwork/java/javaee/jsp/index.htmlの6.4項「Examples of JSP Documents」を参照してください。

例5-3 単純なJSPドキュメント

<table>
<c:forEach
xmlns:c="http://java.sun.com/jsp/jstl/core"
var="counter" begin="1" end="3">
<row>${counter}</row>
</c:forEach>
</table>

JSPドキュメントの使用方法

JSPドキュメントは、以下を含むいくつかの使用方法ができます。

- JSPドキュメントは、JSPコンテナに直接渡すことができます。これは、ますます多くのコンテンツがXMLで作成されるようになってきているため、いっそう重要になってきています。生成されたコンテンツは、クライアントに直接送信することも、なんらかのXML処理パイプラインの一部とすることもできます。

- JSPドキュメントは、XML対応ツールで操作できます。

- JSPドキュメントは、XSLTなどXMLトランスフォーメーションを適用することによって、テキスト表現から生成できます。

- JSPドキュメントは、たとえばなんらかのオブジェクトをシリアライズすることで、自動的に生成できます。

JSPドキュメントについての重要な情報

以下は、JSPドキュメントに関連するいくつかの重要な情報です。

- デフォルトでは、ファイル名に拡張.jspxまたは.tagxの付いたファイルは、XML構文のJSPドキュメントとして扱われます。

- web.xmlデプロイメント記述子で定義されるJSPプロパティ・グループは、Webアプリケーション内のどのファイルを、XML構文のものとして扱うことができるかを制御できます。「JSPプロパティ・グループの構成」を参照してください。

- JSPファイルの最初が<jsp:root>である場合、これはXML構文内で使用されます。

- <%@taglib%> taglibタグのかわりに、XMLネームスペースが使用されます(xmlns:prefix="...")。

- <%...%>、<%!...%>、および<%=...%>のかわりに、<jsp:scriptlet>、<jsp:declaration>および<jsp:expression>タグが使用されます。

- <%@page%>および<%@include%>のかわりに、<jsp:directive.page>および<jsp:directive.include>タグが使用されます。

- 属性値内では、式を示すためには<%=...%>ではなく、%...%のみを使用します。

JSPドキュメントの詳細は、http://www.oracle.com/technetwork/java/javaee/jsp/index.htmlのJSP 2.1仕様の第6章「JSP Documents」を参照してください。

6 JSFおよびJSTLライブラリの構成

次の項では、WebLogic ServerでJavaServer Faces (JSF)およびJSP Tag Standard Library (JSTL)を構成する方法について説明します。

- WebアプリケーションでのJSFおよびJSTLの構成

- JSFおよびJSTLライブラリ

- JSFおよびJSTLライブラリのデプロイメント

- JSF 1.xおよびJSTL 1.xライブラリのサポート

WebアプリケーションでのJSFおよびJSTLの構成

JSF 2.0 (JavaServer(tm) Faces)およびJSTL 1.2 (JSP(tm) Standard Tag Library)パッケージが、共有Webアプリケーション・ライブラリとしてWebLogic Serverにバンドルされています。これらのライブラリは、JSFまたはJSTL機能を使用する標準のWebアプリケーションから参照できます。

Webアプリケーションでのこれらの共有ライブラリの参照については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

JavaServer Faces (JSF)

JavaServer Facesは、JavaServerアプリケーションのユーザー・インタフェースの構築を容易にするための技術です。ページ内で再利用可能なUIコンポーネントを組み立て、それらのコンポーネントとアプリケーションのデータ・ソースを結合し、クライアント生成のイベントをサーバー側のイベント・ハンドラに関連付けることで、開発者はそのスキル・レベルに関係なく、Webアプリケーションを迅速に構築できます。

JSFテクノロジの詳細は、http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.htmlのJavaServer Faces (JSF)製品概要を参照してください。

JavaServer Pages Standard Tag Libraries (JSTL)

JavaServer Pages Standard Tag Library (JSTL)は、多くのWebアプリケーションに共通の中核機能を単純なタグとしてカプセル化するための技術です。JSTLでは、反復や条件文などの共通の構造的なタスク、XMLドキュメントを操作するためのタグ、国際化タグ、およびSQLタグがサポートされています。また、既存のカスタム・タグとJSTLタグを統合するためのフレームワークも提供されています。

JSTLテクノロジの詳細は、http://www.oracle.com/technetwork/java/index-jsp-135995.htmlのJavaServer Pages Standard Tag Library (JSTL)製品概要を参照してください。

JSFおよびJSTLライブラリ

以下のパッケージを、共有ライブラリとして使用できます。

- JSFライブラリ(SunのGlassfishコミュニティ) - https://javaserverfaces.dev.java.net

- JSTLライブラリ - http://jstl.java.net/

これらのライブラリはWARファイルとしてバンドルされており、WL_HOME/common/deployable-librariesディレクトリにあります。JSFライブラリには、簡便性を考慮してJSTL JARファイルが含まれています。これによって、アプリケーションはJSFライブラリを参照する際に、JSTLサポートも自動的に得ることができます。

JSF 2.0とJSTL 1.2の個々のJARファイルおよび実装JARファイルも、WL_HOME/server/lib/api.jarファイル内に提供されています。これらのJARファイルは、コンパイル目的またはWebアプリケーションの開発時に他のユーティリティを使用する場合に参照できます。

JSF 2.0ライブラリ

次の表に、JSF 2.0ライブラリのファイル名とそのMANIFESTエントリを示します。

表6-1 jsf-2.0.war

属性

説明

Extension-Name

jsf

Specification-Title

JavaServer Faces

Specification-Version

2.0.4-b05

Implementation-Title

JSF参照実装

Implementation-Version

1.0.0.0_2-0-2

Implementation-Vendor

Sun Microsystems

JSTL 1.2ライブラリ

次の表に、JSTL 1.2ライブラリのファイル名とそのMANIFESTエントリを示します。

表6-2 jstl-1.2.war

属性

説明

Extension-Name

jstl

Specification-Title

JavaServer Pages Standard Tag Library (JSTL)

Specification-Version

1.2

Implementation-Title

Sun Java System Application Server

Implementation-Version

1.2.0

Implementation-Vendor

Sun Microsystems

JSFおよびJSTLライブラリのデプロイメント

JSFおよびJSTLライブラリはWebアプリケーション・ライブラリとして提供されるため、JSFまたはJSTL機能を使用するWebアプリケーションより前にデプロイされなければなりません。これらのライブラリは、管理コンソールを使用するか、またはコマンド・ラインでweblogic.Deployerツールを使用してデプロイすることができます。

次に、weblogic.Deployerコマンド・ライン・ツールを使用してJSF 2.0ライブラリをデプロイする例を示します。

java weblogic.Deployer -adminurl t3://localhost:7001
-user weblogic -password weblogic
-deploy -library
d:/beahome/wlserver_10.0/common/deployable-libraries/jsf-2.0.war

このコマンドでは、ライブラリのMANIFEST.MFで定義されているデフォルトのlibrary-name、specification-version、およびimplementation-versionを使用してJSF 2.0ライブラリがデプロイされます。

ライブラリのデプロイ後は、ライブラリのextension-name、specification-version、およびimplementation-versionが管理コンソールに表示されます。こうした情報は、ライブラリWARファイルのMANIFEST.MFファイルでも確認できます。

Webモジュールのデプロイメントの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーションおよびモジュールのデプロイメント準備に関する項を参照してください。

JSFまたはJSTLライブラリの参照

JSFまたはJSTLライブラリを参照するには、標準のWebアプリケーションでは、アプリケーションのweblogic.xmlファイルで<library-ref>記述子を定義します。次に例を示します。

<library-ref>
<library-name>jsf</library-name>
<specification-version>2.0</specification-version>
<implementation-version>2.0</implementation-version>
<exact-match>false</exact-match>
</library-ref>

Webアプリケーション・ライブラリの参照の詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

JSF 1.xおよびJSTL 1.xライブラリのサポート

JSF 1.xおよびJSTL 1.xパッケージも共有ライブラリとしてWebLogic Serverにバンドルされています。JSF 1.xおよびJSTL 1.xの機能を使用する既存のWebアプリケーションもWebLogic Serverで実行できます。Webアプリケーションに基づいた適切なJSFまたはJSTLライブラリを選択できます。

サポートされているJSF 1.xおよびJSTL 1.xライブラリの詳細は、WebLogic Server 9.2ドキュメントではhttp://docs.oracle.com/cd/E13222_01/wls/docs92/webapp/configurewebapp.html、WebLogic Server 10.0ドキュメントではhttp://docs.oracle.com/cd/E11035_01/wls100/webapp/configurejsfandjtsl.htmlにある、WebアプリケーションでのJSFおよびJSTLの使用に関する説明を参照してください。

7 Webアプリケーションのリソースの構成

次の項では、Webアプリケーション・リソースを構成する方法について説明します。

- Webアプリケーションのリソースの構成

- リソースの構成

- 外部EJBの参照

- ejb-ref*要素についての詳細

- アプリケーション・スコープのEJBの参照

- ClasspathServletによるCLASSPATHからのリソースの提供

- WebLogic ServerでのCGIの使用

Webアプリケーションのリソースの構成

Webアプリケーションで使用するリソースは、通常Webアプリケーションの外部にデプロイされます。オプションとして、JDBCデータ・ソースをEARファイルの一部としてWebアプリケーションのスコープの中でデプロイできます。

Webアプリケーションで外部リソースを使用するには、web.xmlおよびweblogic.xmlデプロイメント記述子を使用して、アプリケーションが使用するJNDIリソース名をグローバルJNDIリソース名で解決する必要があります。(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)詳細は、「リソースの構成」を参照してください。

JDBCデータ・ソースは、weblogic-application.xmlデプロイメント記述子内でそれらのリソースを構成することによって、WebアプリケーションEARファイルの一部としてデプロイすることもできます。スコープがアプリケーションとして定義された、EARファイルの一部としてデプロイされるリソースをアプリケーション・スコープ・リソースと呼びます。これらのリソースは、アプリケーションに対してはプライベートなままであり、アプリケーション・コンポーネントは「リソースの構成」で説明されているように<resource-ref>を追加することで、リソース名にアクセスできます。

リソースの構成

WebアプリケーションからJNDI (Java Naming and Directory Interface)を介してデータ・ソースなどのリソースにアクセスする場合、コード内でルックアップするJNDI名を、グローバルJNDIツリーにバインドされている実際のJNDI名にマップできます。このマッピングを行うには、web.xmlとweblogic.xmlの両方のデプロイメント記述子を使用します。このマッピングにより、アプリケーション・コードを変更せずにこれらのリソースを変更できるようになります。デプロイメント記述子には、Javaコードで使用される名前、JNDIツリーにバインドされているとおりのリソースの名前、リソースのJavaタイプを指定します。また、リソースのセキュリティをサーブレットによってプログラム的に処理するか、またはHTTPリクエストに関連付けられる資格証明に基づいて処理するかを指定します。また、JMSモジュールのリソース(キュー、トピック、接続ファクトリなど)にアクセスすることもできます。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMSアプリケーション・モジュールのデプロイメントの構成に関する項を参照してください。

リソースを構成するには:

1. コードで使用するリソース名、Javaタイプ、およびセキュリティ認可タイプをデプロイメント記述子に入力します。

2. リソース名をJNDI名にマップします。
次の例に、外部データ・ソースの使用方法を示します。この例は、accountDataSourceというデータ・ソースが定義されていることを前提としています。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースに関する項を参照してください。

例7-1 外部データ・ソースの使用例

servlet code:

javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup
("myDataSource");
web.xml entries:

<resource-ref>
. . .
<res-ref-name>myDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
. . .
</resource-ref>
weblogic.xml entries:
<resource-description>
<res-ref-name>myDataSource</res-ref-name>
<jndi-name>accountDataSource</jndi-name>
</resource-description>

外部EJBの参照

Webアプリケーションは、外部参照を使用することによって、異なるアプリケーション(異なるEARファイル)の一部としてデプロイされたEJBにアクセスできます。参照されるEJBは、そのweblogic-ejb-jar.xmlデプロイメント記述子のグローバルJNDIツリーに名前をエクスポートします。Webアプリケーション・モジュールでのEJB参照は、ejb-reference-description要素をそのweblogic.xmlデプロイメント記述子に追加することによって、このグローバルJNDI名にリンクできます。

この手順では、WebアプリケーションとEJB間の一定レベルのインダイレクションを提供しており、サード・パーティのEJBやWebアプリケーションを使用していてEJBを直接呼び出すようにコードを変更できない場合に便利です。ほとんどの場合、このインダイレクションを使用しなくてもEJBを直接呼び出すことができます。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』を参照してください。

Webアプリケーションで使用するために外部EJBを参照するには:

1. コード内でEJBをルックアップするために使用するEJB参照名、Javaクラス名、EJBのホームおよびリモート・インタフェースのクラス名を、Java EE標準のデプロイメント記述子web.xmlのejb-ref要素に入力します(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)

2. WebLogic固有のデプロイメント記述子であるweblogic.xmlのejb-reference-description要素にある参照名を、weblogic-ejb-jar.xmlファイルに定義されたJNDI名にマップします。
WebアプリケーションがEnterprise Application Archive (EARファイル)の一部である場合は、Java EE標準のデプロイメント記述子web.xmlのejb-ref要素を使用して、そのEARで使用されている名前によってEJBを参照できます。

ejb-ref*要素についての詳細

web.xmlデプロイメント記述子のejb-ref要素では、サーブレットまたはJSPのいずれかが特定のEJBを使用することを宣言します。weblogic.xmlデプロイメント記述子のejb-reference-description要素で、その参照をEJBにバインドします。バインドされたEJBはグローバルJNDIツリーに通知されます。

ejb-reference-descriptor要素は、ejb-ref-name要素を使って解決するejb-ref要素を示します。つまり、同じejb-ref-name要素を持つejb-reference-descriptor要素とejb-ref要素を同時に使用できます。

ejb-link構文が追加されたことによって、EJBを使用するサーブレットまたはJSPと使用されるEJBが同じアプリケーション内にある場合には、ejb-reference-descriptor要素は不要になりました。

ejb-ref-name要素は、web.xmlデプロイメント記述子内で次の2つの役割を果たします。

- ユーザー・コード(サーブレットまたはJSP)がEJBのルックアップに使用する名前。したがって、ejb-ref-name要素がejb1である場合は、java:comp/envを基準とした相対的なejb1のJNDI名ルックアップを行います。ejb-ref-name要素は、サーブレットまたはJSPが組み込まれたWebアプリケーションのコンポーネント環境(java:comp/env)にバインドされます。
ejb-ref-name要素をejb1とした場合、サーブレットまたはJSPのコードは次のようになります。

Context ctx = new InitialContext();
ctx = (Context)ctx.lookup("java:comp/env");
Object o = ctx.lookup("ejb1");
Ejb1Home home = (Ejb1Home) PortableRemoteObject.narrow(o, Ejb1Home.class);

- ejb-ref要素とejb-reference-descriptor要素のリンク。

アプリケーション・スコープのEJBの参照

アプリケーション内で、WebLogic Serverは他のアプリケーション・コンポーネントから参照されるEJBを参照するコンポーネントに関連付けられた環境にバインドします。これらのリソースは、java:comp/envを基準とした相対的なJNDI名のルックアップを通じて、実行時にアクセスされます。

EJBとWebアプリケーションを含むアプリケーション(エンタープライズ・アプリケーションとも呼ばれる)のアプリケーション・デプロイメント記述子(application.xml)の例を以下に示します(簡潔に示すために、この例ではXMLヘッダーは省略しています。)

例7-2 デプロイメント記述子の例

<application>
<display-name>MyApp</display-name>
<module>
<web>
<web-uri>myapp.war</web-uri>
<context-root>myapp</context-root>
</web>
</module>
<module>
<ejb>ejb1.jar</ejb>
</module>
</application>

Webアプリケーションのコードでejb1.jar内のEJBを使用できるようにするには、Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlに、JARファイルを参照するejb-linkと、呼び出されるEJBの名前を含むejb-refスタンザが含まれている必要があります。

ejb-linkエントリのフォーマットは以下のようにする必要があります。

filename#ejbname

filenameはWebアプリケーションに対する相対的なJARファイル名、ejbnameはそのJARファイル内のEJBです。ejb-link要素は以下のようになります。

<ejb-link>../ejb1.jar#myejb</ejb-link>

JARのパスはWARファイルに対して相対的なので、「../」で始まります。また、ejbnameがそのアプリケーション全体で一意の場合、JARのパスは省略してもかまいません。その結果、エントリは以下のようになります。

<ejb-link>myejb</ejb-link>

ejb-link要素は、Webアプリケーションのweb.xml記述子に含まれるejb-ref要素の下位要素です。ejb-ref要素は以下のようになります。

例7-3 <ejb-ref>要素

<web-app>
...
<ejb-ref>
<ejb-ref-name>ejb1</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>mypackage.ejb1.MyHome</home>
<remote>mypackage.ejb1.MyRemote</remote>
<ejb-link>../ejb1.jar#myejb</ejb-link>
</ejb-ref>
...
</web-app>

この例でejb-link要素の構文は次のとおりです。

<ejb-link>../ejb1.jar#ejb1</ejb-link>,

この構文で#の左側の部分は、参照されるEJBモジュールの相対パスです。#の右側の構文は、そのモジュールで参照される特定のEJBです。上記の例では、EJBのJARファイルとWARファイルが同じレベルにあります。

ejb-linkで参照される名前(この例ではmyejb)は、参照されるEJBの記述子のejb-name要素に対応しています。その結果、このejb-refが参照しているEJBモジュールのデプロイメント記述子(ejb-jar.xml)には、以下のようなエントリが必要です。

例7-4 <ejb-jar>要素

<ejb-jar>
...
<enterprise-beans>
<session>
<ejb-name>myejb</ejb-name>
<home>mypackage.ejb1.MyHome</home>
<remote>mypackage.ejb1.MyRemote</remote>
<ejb-class>mypackage.ejb1.MyBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
...
</ejb-jar>

ejb-name要素はmyejbに設定されています。

実行時に、Webアプリケーション・コードはjava:/comp/envに基づいてEJBのJNDI名をルックアップします。サーブレット・コードの例は次のとおりです。

MyHome home = (MyHome)ctx.lookup("java:/comp/env/ejb1");

この例で使用される名前(ejb1)は、上記のweb.xmlの抜粋のejb-ref要素で定義されるejb-ref-nameです。

ClasspathServletによるCLASSPATHからのリソースの提供

システムCLASSPATHから、またはWebアプリケーションのWEB-INF/classesディレクトリからクラスまたは他のリソースを提供する必要がある場合、ClasspathServletと呼ばれる特殊なサーブレットを使用できます。ClasspathServletはアプレットまたはRMIクライアントを使用し、サーバー側クラスへのアクセスを必要とするアプリケーションで役に立ちます。ClasspathServletは暗黙的に登録され、任意のアプリケーションから利用できます。

ClasspathServletは、デフォルトでは常に有効です。無効にするには、ServerMBeanのパラメータClassPathServletDisabledをtrueに設定します(デフォルトはfalse)。

ClasspathServletはシステムCLASSPATHから次の順序でクラスまたはリソースを返します。

1. WEB-INF/classes

2. WEB-INF/lib/*の下のjarファイル

3. システムCLASSPATH

WebアプリケーションのWEB-INF/classesディレクトリからリソースを提供する場合、次のようなURLでリソースを呼び出します。

http://server:port/myWebApp/classes/my/resource/myClass.class

この場合、リソースはWebアプリケーションのルートを基準にした次のディレクトリにあります。

WEB-INF/classes/my/resource/myClass.class

注意:

ClasspathServletはシステムCLASSPATHにあるすべてのリソースを提供するので、システムCLASSPATHには公開できないリソースは置かないでください。

WebLogic ServerでのCGIの使用

注意:

WebLogic Serverには、レガシーCGI (Common Gateway Interface)スクリプトのサポート機能が用意されています。しかし、新しいプロジェクトでは、HTTPサーブレットまたはJavaServer Pagesを使用することをお薦めします。

WebLogic Serverは、CGIServletという内部WebLogicサーブレットを介してすべてのCGIスクリプトをサポートします。CGIを使用するには、このCGIServletをWebアプリケーション・デプロイメント記述子に登録します。「クライアントによるWebアプリケーションへのアクセス方法の構成」を参照してください。

CGIを使用するためのWebLogic Serverの構成

WebLogic ServerでCGIを構成するには:

1. Java EE標準のWebアプリケーション・デプロイメント記述子web.xml内でservletおよびservlet-mapping要素を使用して、Webアプリケーション内でCGIServletを宣言します。(web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。)CGIServletのクラス名は、weblogic.servlet.CGIServletです。このクラスをWebアプリケーションにパッケージ化する必要はありません。

2. 次のinit-param要素を定義して、CGIServlet用の次の初期化属性を登録します。

- cgiDir - CGIスクリプトが存在するディレクトリのパス。複数のディレクトリを指定するには、";" (Windows)または":" (UNIX)で区切ります。cgiDirを指定しない場合、Webアプリケーション・ルートの下のcgi-binがデフォルトのディレクトリとなります。

- useByteStream - デフォルトでは、CGIスクリプトの出力の読取りには、文字ストリームが使用されます。スクリプトによりバイナリ・データが生成される際、文字エンコーディングのせいでストリームが破損する場合があります。ストリームが破損しないようにするには、useByteStreamパラメータを使用します。このパラメータをASCII出力に使用すると、パフォーマンスの向上にもつながります。

- extension mapping - スクリプトを実行する実行可能ファイルまたはインタープリタにファイル拡張子をマップします。スクリプトが実行可能ファイルを必要としない場合、この初期化属性は省略可能です。

- 拡張子マッピング用のparam-nameは、*.plのように、アスタリスク、ドット、ファイル拡張子の順で指定する必要があります。

- param-valueは、スクリプトを実行するインタープリタまたは実行可能ファイルへのパスを含んでいます。個別のマッピングに独立したinit-param要素を作成すると、複数のマッピングを作成できます。

例7-5 CGIServletの登録に使用するWebアプリケーション・デプロイメント記述子エントリの例

<servlet>
<servlet-name>CGIServlet</servlet-name>
<servlet-class>weblogic.servlet.CGIServlet</servlet-class>
<init-param>
<param-name>cgiDir</param-name>
<param-value>
/bea/wlserver6.0/config/mydomain/applications/myWebApp/cgi-bin
</param-value>
</init-param>
<init-param>
<param-name>*.pl</param-name>
<param-value>/bin/perl.exe</param-value>
</init-param>
</servlet>
...
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>

CGIスクリプトのリクエスト

Perlスクリプトをリクエストするために使用するURLは、次のパターンに従う必要があります。

http://host:port/myWebApp/cgi-bin/myscript.pl

ここで

host:port - WebLogic Serverのホスト名とポート番号

myWebApp - Webアプリケーションの名前

cgi-bin - CGIServletにマップされるurl-pattern名

myscript.pl - cgiDir初期化属性で指定したディレクトリに存在するPerlスクリプトの名前

CGIのベスト・プラクティス

CGIのベスト・プラクティスのリストについては、「CGIのベスト・プラクティス」を参照してください。

8 Webコンポーネント用のWebLogicアノテーション

次の項では、アノテーションを使用してWebコンポーネントを記述する方法について説明します。

- サーブレット・アノテーションと依存関係インジェクション

- アノテーションによるサーブレットの記述

サーブレット・アノテーションと依存関係インジェクション

Java EEメタデータ・アノテーションの使用により、標準のweb.xmlデプロイメント記述子は省略可能になりました。Servlet 2.5仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.htmlを参照)では、サーブレット、フィルタ、リスナー、タグ・ハンドラなどの特定のWebコンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存関係を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル・メソッドが呼び出される前に必要な依存関係を注入します。依存関係インジェクション(DI)は特定のコンポーネントに対してのみ行われます。「アノテーションをサポートするWebコンポーネント・クラス」を参照してください。

アノテーション処理とDIは、バージョンが2.5に設定されているすべてのWebアプリケーションで実行されます。ただし、アノテーション処理は負荷が大きく、含まれるクラスのサイズによってはWebアプリケーションのデプロイメント時間が長くなる場合があります。Webアプリケーションにアノテーションがなく、またバージョンが2.5に設定されている場合は、web.xml記述子でmetadata-complete属性をtrueに設定することで、Webアプリケーション・クラスの不要なアノテーション・スキャンを回避できます。または、WebLogic Serverの起動時に-Dweblogic.servlet.DIDisabled=trueフラグを設定して、すべてのWebアプリケーションに対してアノテーション処理とDIを無効にすることもできます。

WebLogic ServerアプリケーションでのJava EEアノテーションと依存関係インジェクションの使用方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のJava EEアノテーションと依存関係インジェクションの使用を参照してください。WebLogic Server Enterprise JavaBeansに対するEJB固有のアノテーションの詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansバージョン3.0のプログラミング』を参照してください。

アノテーションをサポートするWebコンポーネント・クラス

この項では、Java EEに準拠したWebコンテナにおける、リソースに対するアノテーションおよび依存関係インジェクション(DI)の動作について説明します。

Webコンテナでは、表8-1に示されているクラスの型に対してのみアノテーションが処理されます。

表8-1 アノテーションおよび依存関係インジェクションをサポートするWebコンポーネントとインタフェース

コンポーネント・タイプ

インタフェース

サーブレット

javax.servlet.Servlet

フィルタ

javax.servlet.Filter

リスナー

javax.servlet.ServletContextListener
javax.servlet.ServletContextAttributeListener
javax.servlet.ServletRequestListener
javax.servlet.ServletRequestAttributeListener
javax.servlet.http.HttpSessionListener
javax.servlet.http.HttpSessionAttributeListener

タグ・ハンドラ

javax.servlet.jsp.tagext.SimpleTag
javax.servlet.jsp.tagext.BodyTag

Webコンテナは、Java Beanのようなクラスおよびその他のヘルパー・クラスに対しては、アノテーションを処理しません。Webコンテナでは、DIを実現するために次の手順が行われます。

1. アノテーション処理 - アノテーションは、Webアプリケーションのデプロイメント・フェーズ中にWebコンテナによって処理されます。コンテナはアノテーションを処理しながら、アノテーションによって影響を受ける記述子内の関連エントリを割り出し、記述子ツリーを更新します。Servlet 2.5仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html)では、インジェクション対象を定義することですべてのアノテーションを記述子内に宣言できると規定されています。Webコンテナは、注入対象で記述子ツリーを更新します。この結果、デプロイメントを継続しながらjava:comp/envツリーが必要なエントリで更新されます。

2. 依存関係インジェクション(DI) - DIはインスタンスの作成時に(表8-1で示された型に対して)行われます。これは、リスナーとフィルタに対してはデプロイメント・フェーズで発生します。サーブレットに対してはデプロイメント中または実行時に発生する可能性があります。

注意:

Webアプリケーション・コンポーネントでは、1つのDIが失敗すると、同じコンポーネントに対する以後のすべてのDIが無視されます。

Webコンテナによってサポートされるアノテーション

表8-2に、Webコンテナによってサポートされる必要のあるすべてのアノテーションを示します。

表8-2 サポートされるアノテーションのリスト

@アノテーション

仕様の参照先

DeclaresRoles

14.5.1

EJB

14.5.2

EJB

14.5.3

PersistenceContext

14.5.5

PersistenceUnit

14.5.7

PersistenceUnits

14.5.8

PersistenceContexts

14.5.6

PostConstruct

14.5.9

PreDestroy

14.5.10

Resource

14.5.4

Resources

14.5.11

WebServiceRef

14.5.13

WebServiceRefs

14.5.14

RunAs

14.5.12

Webコンテナは、Java EEコンテナのアノテーション処理および依存関係インジェクションのメカニズムを利用して、この機能を実現します。

Servlet 2.5仕様では、web.xml記述子でmetadata-complete属性がtrueに設定されている場合、Webコンテナはアノテーションを処理できないと規定されています。アノテーションが適切に定義され、アノテーション処理が成功し、依存関係が正常に注入されると、アノテーションで記述されたフィールドは正常に初期化され、アノテーションで記述されたメソッドはライフサイクルの適切なフェーズで呼び出されます。DIが失敗すると、これらのアノテーションで記述されたフィールドはnullになります。

注意:

サーブレットやフィルタなどのWebコンポーネント・クラス内の複数のメソッドにPostConstructまたはPreDestroyアノテーションが付けられている場合、Webコンポーネントではそのようなアプリケーションのデプロイメントに失敗します。同様に、セッションBeanなどのEJBコンポーネント・クラスにPostConstructまたはPreDestroyアノテーションが付けられている場合や、EJBインターセプタにPostConstruct、PreDestroy、PostActivateまたはPrePassivateアノテーションが付けられている場合、EJBコンポーネントでもそのようなアプリケーションのデプロイメントに失敗します。

フォルトの検出とリカバリ

アノテーション処理中に障害が発生した場合には、デプロイメント例外が生成され、そのWebアプリケーションのデプロイメントは回避されます。DI中に障害が発生した場合には、その障害の理由を示す警告メッセージがコンテナによってサーバー・ログに書き込まれます。DI障害の発生時には、クラスのインスタンスにあるアノテーションで記述されたフィールドはnullになり、アノテーションで記述されたライフサイクル・メソッドは一切呼び出されません。

制限事項

WebLogicサーブレット・コンテナでは、web.xml記述子で宣言されるWebコンポーネントに対するアノテーションがサポートされています。weblogic.servlet.WeblogicServletContextメソッドを介して動的に登録されたリスナー、フィルタ、およびサーブレットに対してはアノテーションは処理されず、そのようなコンポーネントに対してDIは行われません。

アノテーションによるサーブレットの記述

WebLogicサーブレット・コンテナには、サーブレット用の@WLServletアノテーション、およびフィルタ用のWLFilterアノテーションが用意されています。これらのアノテーションを使用すると、Webアプリケーション内でサーブレットおよびフィルタを開発でき、web.xml記述子でそれらを宣言する必要がなくなります。WebLogicサーブレット・コンテナには、WLServletおよびWLFilterアノテーションを使用して宣言されたサーブレットおよびフィルタの初期化パラメータを指定するためのWLInitParamアノテーションも用意されています。

必要なメタデータはすべて、サーブレットまたはフィルタ内にアノテーションで記述できます。コンテナはそれらを検出し、そのアノテーションで記述されたサーブレットまたはフィルタがデプロイされるように記述子ツリーを更新します。

WLServlet

WLServletアノテーション(weblogic.servlet.annotation.WLServlet)を使用してサーブレット・クラスを記述できます。このアノテーションには、サーブレットのパラメータを宣言するための様々な属性を定義します。このアノテーションのすべての属性は、省略可能です。

属性

表8-3 WLServletアノテーションの属性

名前

説明

データ型

必須?

displayName

デプロイメント後のサーブレットの表示名

String

いいえ

description

サーブレットの説明

String

いいえ

icon

アイコンの場所

String

いいえ

name

サーブレットの名前

String

いいえ

initParams

サーブレットの初期化パラメータ

WLInitParam[]

いいえ

loadOnStartup

サーブレットを起動時にロードすべきかどうか

int

いいえ

runAs

サーブレットのrun-asユーザー

String

いいえ

mapping

サーブレットのURLパターン

String[]

いいえ

例8-1に、サーブレット・クラスでのアノテーションの使用方法を示します。

例8-1 WLServletアノテーション

@WLServlet (
name = "FOO",
runAs = "SuperUser"
initParams = { @WLInitParam (name="one", value="1") }
mapping = {"/foo/*"}
)
. . .

WebLogicサーブレット・コンテナは、アノテーションを検出し、デプロイメントのためにこのサーブレットをインストールします。Webアプリケーション・デプロイメントのアノテーション処理フェーズ中に、web.xml記述子に対応する記述子Beanが、このアノテーションに対応する関連エントリで更新されます。

例8-2に、更新後の記述子Beanを示します。

例8-2 更新されたweb.xml記述子

<web-app>
. . .
<servlet>
<servlet-name>FOO</servlet-name>
<servlet-class>my.TestServlet</servlet-class>
<init-param>
<param-name>one</param-name>
<param-value>1</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>FOO</servlet-name>
<url-pattern>/foo/*</url-pattern>
</servlet-mapping>
. . .
</web-app>

フォルトの検出とリカバリ

このアノテーションの処理中にエラーが発生した場合には、デプロイメント・エラーとなり、サーバー・ログに適切なメッセージが書き込まれます。

WLFilter

WLFilterアノテーション(weblogic.servlet.annotation.WLFilter)を使用してフィルタ・クラスを記述できます。このアノテーションには、フィルタのパラメータを宣言するための様々な属性を定義します。このアノテーションのすべての属性は、省略可能です。

属性

表8-4 WLFilterアノテーションの属性

名前

説明

データ型

必須?

displayName

デプロイメント後のフィルタの表示名

String

いいえ

description

フィルタの説明

String

いいえ

icon

アイコンの場所

String

いいえ

name

フィルタの名前

String

いいえ

initParams

フィルタの初期化パラメータ

WLInitParam[]

いいえ

mapping

フィルタのURLパターン

String[]

いいえ

例8-3に、フィルタ・クラスでのアノテーションの使用方法を示します。

例8-3 WLFilterアノテーション

@WLFilter (
name = "BAR",
initParams = { @WLInitParam (name="one", value="1") }
Mapping = {"/bar/*"}
)
. . .

WebLogicサーブレット・コンテナは、アノテーションを検出し、デプロイメントのためにこのフィルタをインストールします。Webアプリケーション・デプロイメントのアノテーション処理フェーズ中に、web.xml記述子に対応する記述子Beanが、このアノテーションに対応する関連エントリで更新されます。

例8-4に、更新後の記述子Beanを示します。

例8-4 更新されたweb.xml記述子

<web-app>
. . .
<filter>
<filter-name>BAR</filter-name>
<filter-class>my.TestFilter</filter-class>
<init-param>
<param-name>one</param-name>
<param-value>1</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>BAR</filter-name>
<url-pattern>/bar/*</url-pattern>
</filter-mapping>
. . .
</web-app>

フォルトの検出とリカバリ

このアノテーションの処理中にエラーが発生した場合には、デプロイメント・エラーとなり、サーバー・ログに適切なメッセージが書き込まれます。

WLInitParam

@WLInitParamアノテーション(weblogic.servlet.annotation.WLInitParam)を使用して、@WLServletおよび@WLFilterアノテーションを使用して宣言されたサーブレットおよびフィルタの初期化パラメータを指定できます。

属性

表8-5 WLFilterアノテーションの属性

名前

説明

データ型

必須?

name

初期化パラメータの名前

String

いいえ

value

初期化パラメータの値

String

いいえ

例8-5に、WLInitParamアノテーションの例を示します。

例8-5 WLInitParamアノテーションの例

initParams = {@WLInitParam(name="one", value="1"),
@WLInitParam(name="two", value="2")}

前述のアノテーションを使用してサーブレット・クラスまたはフィルタ・クラスを記述することは、web.xml記述子で例8-6のように初期化パラメータを宣言することと同じです。

例8-6 web.xmlでの初期化パラメータ

. . .
<init-param>
<param-name>one</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>two</param-name>
<param-value>2</param-value>
</init-param>
. . .

9 サーブレット・プログラミング・タスク

次の項では、WebLogic Server環境でHTTPサーブレットを記述する方法について説明します。

- サーブレットの初期化

- HTTPレスポンスの提供

- クライアント入力の取得

- サーブレットでのクライアント入力のセキュリティ

- サーブレットでのCookieの使用方法

- レスポンスのキャッシュ

- HTTPサーブレットからのWebLogicサービスの使用方法

- データベースへのアクセス

- HTTPサーブレットにおけるスレッドの問題

- 別のリソースへのリクエストのディスパッチ

- 別のWebサーバーへのリクエストのプロキシ

- サーブレットのクラスタリング

- Webアプリケーションでのサーブレットの参照

- URLパターン・マッチング

- SimpleApacheURLMatchMapユーティリティ

- HTTPサーブレットの将来的レスポンス・モデル

サーブレットの初期化

通常、WebLogic Serverによってサーブレットが初期化されるのは、そのサーブレットに対して最初のリクエストが出されたときです。その後、そのサーブレットが変更されると、既存のバージョンのサーブレットに対してdestroy()メソッドが呼び出されます。変更後のサーブレットにリクエストが送信されると、変更後のサーブレットのinit()メソッドが実行されます。詳細は、「サーブレットのベスト・プラクティス」を参照してください。

サーブレットが初期化されるとき、WebLogic Serverはサーブレットのinit()メソッドを実行します。サーブレットは一度初期化されると、WebLogic Serverを再起動するまで、またはサーブレット・コードが変更されるまで、再び初期化されることはありません。init()メソッドをオーバーライドすると、データベース接続の確立など、サーブレットの初期化時に特定のタスクを実行させることができます(「init()メソッドのオーバーライド」を参照。)

WebLogic Server起動時のサーブレットの初期化

サーブレットに最初のリクエストが送信された時にWebLogic Serverがサーブレットを初期化するのではなく、サーバーの起動時に初期化するように、最初にWebLogic Serverを構成できます。これを行うには、Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlのload-on-startup要素内にサーブレット・クラスを指定します。Webアプリケーション内でのリソースの初期化の順序は、次のとおりです。

1. ServletContextListeners - このWebアプリケーションについて登録されたServletContextListenersに対するcontextCreated()コールバック。

2. ServletFilters init()メソッド。

3. Servlet init()メソッド(web.xml内ではload-on-startupとしてマーク)。

初期化中にHTTPサーブレットにパラメータを渡すには、サーブレットを含むWebアプリケーションでパラメータを定義します。このパラメータを使用すると、サーブレットが初期化されるたびに書き換えることなくサーブレットへ値を渡せます。

たとえば、Java EE標準のWebアプリケーション・デプロイメント記述子web.xml内に次のようなエントリを作成すると、Welcomeの値を持つgreetingおよびWebLogic Developerの値を持つpersonの2つの初期化パラメータが定義されます。

<servlet>
...
<init-param>
<description>The salutation</description>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
</init-param>
<init-param>
<description>name</description>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
</init-param>
</servlet>

初期化パラメータを取得するには、親javax.servlet.GenericServletクラスからgetInitParameter(String name)メソッドを呼び出します。パラメータ名を渡されると、このメソッドはパラメータの値をStringとして返します。

init()メソッドのオーバーライド

init()メソッドをオーバーライドすることで、初期化時にサーブレットにタスクを実行させることができます。次のコードでは、Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlの中で挨拶文と名前を定義する<init-param>タグを読み込みます。

String defaultGreeting;
String defaultName;

public void init(ServletConfig config)
throws ServletException {
if ((defaultGreeting = getInitParameter("greeting")) == null)
defaultGreeting = "Hello";

if ((defaultName = getInitParameter("person")) == null)
defaultName = "World";
}

各パラメータの値は、クラス・インスタンス変数defaultGreetingおよびdefaultNameに格納されます。最初にパラメータがnull値を持つかどうかをテストして、null値が返されれば、適切なデフォルト値を提供します。

これで、service()メソッドを使用して、レスポンスの中にこれらの変数を含めることができます。例:

out.print("<body><h1>");
out.println(defaultGreeting + " " + defaultName + "!");
out.println("</h1></body></html>");

サーブレットのinit()メソッドは、WebLogic Serverがサーブレットをロードするときに必要となるすべての初期化を行います。デフォルトのinit()メソッドはWebLogic Serverが必要とする初期作業をすべて行うので、特別な初期化を行う場合を除いて、このメソッドをオーバーライドする必要はありません。init()をオーバーライドする場合は、デフォルトの初期化アクションが先に実行されるように、まずsuper.init()を呼び出します。

HTTPレスポンスの提供

この項では、HTTPサーブレットでクライアントへのレスポンスを提供する方法について説明します。レスポンスはすべて、サーブレットのservice()メソッドにパラメータとして渡されるHttpServletResponseオブジェクトを使用して渡さなければなりません。

1. HttpServletResponseを構成します。
HttpServletResponseオブジェクトを使用して、HTTPヘッダー情報に変換される複数のサーブレット・プロパティを設定できます。

- 少なくとも、ページのコンテンツを書き込む出力ストリームを取得する前に、setContentType()メソッドを使用してコンテンツ・タイプを設定します。HTMLページの場合、コンテンツ・タイプはtext/htmlに設定します。例:

res.setContentType("text/html");

- (オプション) setContentType()メソッドを使用して文字エンコードを設定することもできます。例:

res.setContentType("text/html;ISO-88859-4");

- setHeader()メソッドを使用して、ヘッダー属性を設定します。動的なレスポンスの場合は、Pragma属性をno-cacheに設定するとよいでしょう。こうするとブラウザは常にページを再ロードし、確実に最新データを表示します。例:

res.setHeader("Pragma", "no-cache");

2. HTMLページを作成します。
サーブレットがクライアントに送り返すレスポンスは、通常のHTTPコンテンツ(基本的にはHTML形式)のように見える必要があります。サーブレットは、service()メソッドのレスポンス・パラメータを使用して取得した出力ストリームを通じて、HTTPレスポンスを送り返します。HTTPレスポンスを送信するには、次の手順に従います。

1. HttpServletResponseオブジェクトおよび次の例のいずれかのメソッドを使用して、出力ストリームを取得します。

- PrintWriter out = res.getWriter();

- ServletOutputStream out = res.getOutputStream();

同じサーブレット内(または、サーブレットの中にインクルードされた別のサーブレット内)で、PrintWriterとServletOutputStreamを両方とも使用できます。どちらの出力も、同じバッファに書き込まれます。

2. print()メソッドを使用して、レスポンスの内容を出力ストリームに書き出します。これらの文では、HTMLタグを使用することができます。例:

out.print("<html><head><title>My Servlet</title>");
out.print("</head><body><h1>");
out.print("Welcome");
out.print("</h1></body></html>");

ユーザーが以前に入力したデータを出力する場合、HTML特殊文字が入力されていればすべて削除することをお薦めします。これらの文字を削除しない場合、クロス・サイト・スクリプティングによってWebサイトが損なわれるおそれがあります。詳細は、「サーブレットでのクライアント入力のセキュリティ」を参照してください。

出力ストリームはclose()メソッドでクローズしないでください。また、ストリームのコンテンツをフラッシュすることも避けてください。出力ストリームをクローズしたりフラッシュしたりしないことによって、次の手順で説明する永続的HTTP接続の利点を活かすことができます。

3. レスポンスを最適化します。
デフォルトでは、WebLogic Serverは、可能な限りHTTPの永続的接続を使用しようとします。永続的接続は、クライアントとサーバー間の一連の通信のために、同一のHTTP TCP/IP接続を再利用しようとします。各リクエストでは新規接続を開く必要はないため、アプリケーションのパフォーマンスが向上します。永続的接続は、HTMLページにインライン画像が多く含まれる場合に便利です。そうしないと、画像が要求されるごとに新しいTCP/IP接続が必要になるためです。

WebLogic Server 管理コンソールを使用すると、WebLogic ServerがHTTP接続をオープンに保つ時間を構成できます。

永続的接続を確立するために、WebLogic ServerはHTTPレスポンスの長さを知る必要があるので、HTTPレスポンス・ヘッダーにContent-Lengthプロパティを自動的に追加します。コンテンツ長を確認するために、WebLogic Serverではレスポンスをバッファリングする必要があります。ただし、サーブレットがServletOutputStreamを明示的にフラッシュすると、WebLogic Serverではレスポンスの長さを判別できないため、永続的接続を使用できません。このため、サーブレットでHTTPレスポンスを明示的にフラッシュすることは避けます。

場合によっては、ページ完成前にクライアントに情報を表示するためにレスポンスを早くフラッシュした方がよいこともあります。たとえば、時間のかかるページのコンテンツを計算している途中で、バナー広告を表示する場合などです。逆に、サーブレット・エンジンが使用するバッファ・サイズを増やして、フラッシュする前に、もっと長いレスポンスを入れておきたいという場合もあります。javax.servlet.ServletResponseインタフェースの関連メソッドを使用して、レスポンス・バッファのサイズを操作することができます。詳細は、http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specsのServlet 2.4仕様を参照してください。

WebLogic Serverのレスポンス・バッファのデフォルト値は12Kで、バッファ・サイズは、CHUNK_SIZE (CHUNK_SIZE = 4088 バイト)に基づいて内部で計算されます。たとえば、ユーザーが5KBに設定すると、バッファ・サイズは、それを切り上げた最も近いCHUNK_SIZEの倍数(この場合は2)である8176バイトに設定されます。

クライアント入力の取得

HTTPサーブレットAPIは、Webページからユーザー入力を取得するためのインタフェースを提供しています。

WebブラウザからのHTTPリクエストには、クライアント、ブラウザ、Cookie、およびユーザーの問合せパラメータに関する情報といった、URL以外の情報も含めることができます。ブラウザからのユーザー入力を渡すには、問合せパラメータを使用します。GETメソッドはURLアドレスにパラメータを付加し、POSTメソッドはそれらをHTTPリクエスト本文の中に含めます。

HTTPサーブレットでは、これらの細部を扱う必要はありません。リクエストの中の情報は、送った方法に関係なく、HttpServletRequestオブジェクトを通じて取得され、request.getParameter()メソッドを使用してアクセスできるようになります。

問合せパラメータをクライアントから送る方法については、次を参照してください。

- ページのリンクのURLに、パラメータを直接エンコードします。この方法では、GETメソッドを使用してパラメータを送ります。パラメータはURLの後ろに?を付けてその後に追加します。パラメータが複数ある場合は&で区切ります。パラメータは、常に名前=値のペアで指定されます。指定される順序は重要ではありません。たとえば、次のようなリンクをWebページに入れる場合、ここではColorServletと呼ばれるHTTPサーブレットに、パラメータcolorの値をpurpleにして送ります。

<a href=
"http://localhost:7001/myWebApp/ColorServlet?color=purple">
Click Here For Purple!</a>

- 問合せパラメータを付けたURLをブラウザの場所フィールドに手動で入力します。これは前の例で示したリンクをクリックするのと同じことです。

- HTMLフォームで、ユーザーに入力を要求します。このフォームの送信ボタンがクリックされると、フォーム上の各ユーザー入力フィールドの内容が、問合せパラメータとして送られます。このフォームが問合せパラメータを送るために使用するメソッド(POSTまたはGET)を、METHOD="GET|POST"属性を使用して<FORM>タグに指定します。

問合せパラメータは常に名前=値のペアで送られ、HttpServletRequestオブジェクトを通じてアクセスされます。問合せのすべてのパラメータ名のEnumerationを取得し、そのパラメータ名を使用して各パラメータの値を取得できます。1つのパラメータの値は通常1つのみですが、値の配列を持つこともできます。パラメータの値は常にStringとして読み取られるので、より適切な型にキャストすることが必要な場合もあります。

service()メソッドからの次のサンプルでは、フォームから得た問合せパラメータ名とその値を調べます。requestはHttpServletRequestオブジェクトであることに注意してください。

Enumeration params = request.getParameterNames();
String paramName = null;
String[] paramValues = null;

while (params.hasMoreElements()) {
paramName = (String) params.nextElement();
paramValues = request.getParameterValues(paramName);
System.out.println("\nParameter name is " + paramName);
for (int i = 0; i < paramValues.length; i++) {
System.out.println(", value " + i + " is " +
paramValues[i].toString());
}
}

注意:

ユーザーが入力したデータを出力する場合、HTML特殊文字が入力されていればすべて削除することをお薦めします。これらの文字を削除しない場合、クロス・サイト・スクリプティングによってWebサイトが損なわれるおそれがあります。詳細は、「サーブレットでのクライアント入力のセキュリティ」を参照してください。

HTTPリクエストを使用するメソッド

この項では、リクエスト・オブジェクトからデータを取得できるjavax.servlet.HttpServletRequestインタフェースのメソッドを定義します。次の制限事項に注意してください。

- 次の項のgetParameter()メソッドを使用してリクエスト・パラメータを読み込んだ後に、getInputStream()メソッドでリクエストを読もうとすることはできません。

- getInputStream()でリクエストを読み込んだ後に、getParameter()メソッドの1つを使ってリクエスト・パラメータを読み込もうとすることもできません。

上のいずれかの手順を実行しようとすると、illegalStateExceptionがスローされます。

javax.servlet.HttpServeletRequestの次のメソッドを使用して、リクエスト・オブジェクトからデータを取得できます。

- HttpServletRequest.getMethod() - GETやPOSTなどのリクエスト・メソッドを決定できます。

- HttpServletRequest.getQueryString() - 問合せ文字列へのアクセスを可能にします。(?の後に続く、要求されたURLの残りの部分。)

- HttpServletRequest.getParameter() - パラメータの値を返します。

- HttpServletRequest.getParameterNames() - パラメータ名の配列を返します。

- HttpServletRequest.getParameterValues() - パラメータの値の配列を返します。

- HttpServletRequest.getInputStream() - リクエスト本体をバイナリ・データとして読み込みます。リクエスト・パラメータをgetParameter()、getParameterNames()、またはgetParameterValues()で読み込んだ後にこのメソッドを呼び出すと、illegalStateExceptionがスローされます。

例: 問合せパラメータによる入力の取得

例9-1では、より個人的な挨拶文を表示するために、問合せパラメータとしてユーザー名を受け付けるようにHelloWorld2.javaサーブレットのサンプルを修正しています。service()メソッドを次に示します。

例9-1 service()メソッドによる入力の取得

public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException
{
String name, paramName[];
if ((paramName = req.getParameterValues("name"))
!= null) {
name = paramName[0];
}
else {
name = defaultName;
}

// Set the content type first
res.setContentType("text/html");
// Obtain a PrintWriter as an output stream
PrintWriter out = res.getWriter();

out.print("<html><head><title>" +
"Hello World!" + </title></head>");
out.print("<body><h1>");
out.print(defaultGreeting + " " + name + "!");
out.print("</h1></body></html>");
}

getParameterValues()メソッドは、HTTP問合せパラメータからnameパラメータの値を取得します。これらの値は、Stringタイプの配列で取得します。このパラメータに1つの値が返され、name配列の第1要素に割り当てられます。問合せデータにこのパラメータがなければ、戻り値はnullになります。この場合は、init()メソッドによって<init-param>から読み込んだデフォルトの名前にnameを割り当てます。

パラメータがHTTPリクエストに含まれていると仮定してサーブレット・コードを記述しないでください。getParameter()メソッドは非推奨となったため、配列の添え字にその末尾までタグ付けすることによって、getParameterValues()メソッドを略記しようとする場合があります。しかし、このメソッドは指定したパラメータが有効でないとnullを戻すことがあり、NullPointerExceptionが発生します。

たとえば、次のコードではNullPointerExceptionが発生します。

String myStr = req.getParameterValues("paramName")[0];

かわりに、次のコードを使用します。

if ((String myStr[] =
req.getParameterValues("paramName"))!=null) {
// Now you can use the myStr[0];
}
else {
// paramName was not in the query parameters!
}

サーブレットでのクライアント入力のセキュリティ

ユーザーが入力したデータを取得して返す機能があると、クロス・サイト・スクリプティングと呼ばれるセキュリティの脆弱性がもたらされます。これは、ユーザーのセキュリティ認可を盗用するために利用される可能性があります。クロス・サイト・スクリプティングの詳細については、http://www.cert.org/tech_tips/malicious_code_mitigation.htmlの「Understanding Malicious Content Mitigation for Web Developers」(CERTのセキュリティ勧告)を参照してください。

セキュリティの脆弱性をなくすには、ユーザーが入力したデータを戻す前に、そのデータをスキャンして、表9-1に示すHTML特殊文字があるかどうかを調べます。特殊文字が見つかった場合、HTMLのエンティティ参照または文字参照と置き換えます。文字を置換することで、ブラウザでユーザー入力によるデータがHTMLとして実行されることを回避します。

表9-1 置換えの必要があるHTMLの特殊文字

置き換える特殊文字

置換え後のエンティティ/文字参照

<

&lt;

>

&gt;

(

&40;

)

&41;

#

&35;

&

&38;

WebLogic Serverユーティリティ・メソッドを使用する

WebLogic Serverには、ユーザーが入力したデータ内の特殊文字を置き換えるweblogic.servlet.security.Utils.encodeXSS()メソッドが用意されています。このメソッドを使用するには、ユーザー入力データを入力として提供します。例9-1でユーザーが指定したデータを保護するには、次の行

out.print(defaultGreeting + " " + name + "!");

を、以下の行と置き換えます。

out.print(defaultGreeting + " " +
weblogic.security.servlet.encodeXSS(name) + "!");

アプリケーション全体を保護するため、ユーザーが入力したデータを戻すたびに、encodeXSS()メソッドを使用する必要があります。前述の例9-1での例は、encodeXSS()メソッドを使用すべき場所の1つですが、表9-2ではこのメソッドを使用すべきかどうかを検討すべきその他の場所を示します。

表9-2 ユーザー入力データを戻すコード

ページのタイプ

ユーザー入力データ

例

エラー・ページ

誤りのある入力文字列、無効なURLやユーザー名

ユーザー名はアクセスを許可されていませんと表示するエラー・ページ

ステータス・ページ

ユーザー名、以前のページでの入力の要約

以前のページでの入力を確認するようユーザーに求める要約ページ

データベース表示

データベースから提示されたデータ

以前にユーザーによって入力されたデータベース・エントリのリストを表示するページ

サーブレットでのCookieの使用方法

Cookieは、クライアントからサーバーに戻されるので、そのクライアントを識別するために便利なものです。ブラウザは、同じサーバーにアクセスするたび、HTTPリクエストと共にそのサーバーに関連したCookieをすべて送ります。Cookieは、クライアントからサーバーに戻されるので、そのクライアントを識別するために便利なものです。

各Cookieは名前と値を保持しています。通常、Cookieをサポートしているブラウザでは、各サーバーのドメインに、1つあたり最大4KのCookieを20まで格納することができます。

HTTPサーブレットでのCookieの設定

ブラウザ上にCookieを設定するには、Cookieを作成し、値を与え、サーブレットのサービス・メソッドの2番目のパラメータであるHttpServletResponseオブジェクトに追加します。例:

Cookie myCookie = new Cookie("ChocolateChip", "100");
myCookie.setMaxAge(Integer.MAX_VALUE);
response.addCookie(myCookie);

上記の例では、値が100のChocolateChipと呼ばれるCookieを、レスポンスの送信時にブラウザ・クライアントに追加します。Cookieの有効期限は指定できる最大値に設定されているため、Cookieは永久に有効です。Cookieは文字列型の値のみを受け入れるので、Cookieに格納するための必要な型との間でキャストします。EJBの場合、一般的にはCookieの値に対するEJBインスタンスのホーム・ハンドルを使用し、EJBにユーザーの詳細情報を格納して、後で参照できるようにします。

HTTPサーブレットでのCookieの取得

service()メソッドへの引数としてサーブレットに渡されるHttpServletRequestから、Cookieオブジェクトを取得することができます。Cookieそのものは、javax.servlet.http.Cookieオブジェクトとして示されます。

サーブレット・コードでは、getCookies()メソッドを呼び出すことにより、ブラウザから送られたすべてのCookieを取得することができます。例:

Cookie[] cookies = request.getCookies();

このメソッドは、ブラウザから送られたすべてのCookieの配列を戻すか、またはブラウザから送られたCookieがない場合、nullを返します。サーブレットは、その配列を処理して正しい名前のCookieを探す必要があります。Cookieの名前は、Cookie.getName()メソッドを使って取得することができます。同一の名前で、パス属性の異なるCookieが複数ある可能性があります。サーブレットが、同一の名前でパス属性の異なる複数のCookieを設定した場合、Cookie.getPath()メソッドを使ってこれらを比較することも必要です。以下のコードは、ブラウザから送られたCookieの詳細にアクセスする方法を示しています。このサーバーに送られたCookieはすべて一意の名前を持ち、ブラウザ・クライアントで以前に設定したと考えられるChocolateChipというCookieを探しているという前提です。

Cookie[] cookies = request.getCookies();
boolean cookieFound = false;

for(int i=0; i < cookies.length; i++) {
thisCookie = cookies[i];
if (thisCookie.getName().equals("ChocolateChip")) {
cookieFound = true;
break;
}
}

if (cookieFound) {
// We found the cookie! Now get its value
int cookieOrder = String.parseInt(thisCookie.getValue());
}

HTTPとHTTPSの両方で送信されるCookieの使用方法

HTTPリクエストとHTTPSリクエストは異なるポートに送られるので、ブラウザによっては、HTTPリクエストに入れて送られてきたCookieを、その後続のHTTPSリクエストに包含しない(あるいはその逆)ことがあります。このような場合には、サーブレット・リクエストがHTTPとHTTPSの間で切り替わると、新しいセッションが作成されることになります。セッション内でリクエストが行われるたびに、特定のドメインによって設定されるすべてのCookieがサーバーに送られるようにするには、cookie-domain要素をドメイン名に設定します。cookie-domain要素は、WebLogic固有のデプロイメント記述子weblogic.xmlのsession-descriptor要素の下位要素です。例:

<session-descriptor>
<cookie-domain>mydomain.com</cookie-domain>
</session-descriptor>

cookie-domain要素は、mydomain.comによって指定されたドメイン内のホストに、すべてのリクエストについて適切なCookieを入れるようブラウザに指示します。このプロパティやセッションCookieの構成の詳細は、「セッション管理の設定」を参照してください。

アプリケーションのセキュリティとCookie

Cookieの使用は、マシン上での自動的なアカウント・アクセスを可能にして便利ですが、セキュリティの観点からは望ましくない場合があります。Cookieを使用するアプリケーション設計時には、以下のガイドラインに従ってください。

- Cookieが常にユーザーに対して正確であると考えないようにします。マシンが共有されている場合や、同一のユーザーが異なるアカウントにアクセスしようとする場合もあります。

- ユーザーが、サーバー上にCookieを残すかどうか選択できるようにします。共有マシンでは、ユーザーがそのアカウントに対する自動的なログインをそのままにしておくことを望まない場合があります。ユーザーがCookieについて理解していると仮定せずに、以下のような質問をします。

Automatically login from this computer?

- 機密データを取得するためにログオンするユーザーに対しては、常にパスワード入力を求めます。ユーザーが拒否しない限り、このプリファレンスとパスワードをユーザーのセッション・データに格納できます。セッションのCookieは、ユーザーがブラウザを終了したときに期限切れになるように構成します。

レスポンスのキャッシュ

キャッシュ・フィルタは、次の例外を除いて、キャッシュ・タグと同様に動作します。

- JSPフラグメント・レベルではなく、ページ・レベル(インクルードされたページ)でキャッシュします。

- ドキュメント内でキャッシュ・パラメータを宣言するかわりに、Webアプリケーションの構成内でパラメータを宣言できます。

キャッシュ・フィルタには、別のページに含まれていなかったページのためのキャッシュ・タグにはないデフォルト動作があります。キャッシュ・フィルタは、レスポンス・ヘッダーContent-TypeとLast-Modifiedを自動的にキャッシュします。キャッシュ・フィルタは、キャッシュ内に存在しているページのリクエストを受け取ると、リクエストのIf-Modified-SinceヘッダーとLast-Modifiedレスポンス・ヘッダーを比較して、実際にコンテンツを提供するか、302 SC_NOT_MODIFEDステータスと空のコンテンツを送信するかを決定します。

次の例は、Java EE標準のデプロイメント記述子web.xmlのfilter要素を使用して、Webアプリケーション内のすべてのHTMLページをキャッシュするキャッシュ・フィルタを登録する方法を示しています。

<filter>
<filter-name>HTML</filter-name>
<filter-class>weblogic.cache.filter.CacheFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>HTML</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>

このキャッシュ・システムは、ソフト・リファレンスを使用してキャッシュを格納します。そのため、ガベージ・コレクタは、キャッシュが作成または最終アクセスされてから経過した時間に基づいて、キャッシュを再要求するかどうか決定します。そして、OutOfMemoryErrorが発生しないように、ソフト・リファレンスをクリアします。

初期化パラメータ

Webページが更新されたときに確実に新しいコピーをキャッシュに取り込むには、フィルタにタイムアウトを追加します。キャッシュ・フィルタには、キャッシュ・タグと同じような初期化パラメータが多数用意されています。

初期化パラメータは次のとおりです。

- Name - キャッシュ名。*.拡張子のURLパターンとの互換性を考慮して、リクエストURIがデフォルト名になります。

- Timeout - キャッシュの最終更新時から、次にキャッシュ内のコンテンツを更新するまでの時間。デフォルトの単位は「秒」ですが、ms(ミリ秒)、s(秒)、m(分)、h(時)、d(日)のいずれかの単位を指定することもできます。

- Scope - キャッシュのスコープには、request、session、application、clusterのいずれかを指定できます。requestスコープを使用すると、ページ内でループ構造がある場合に便利なこともありますが、それ以外ではあまりメリットはありません。デフォルトでは、スコープはapplicationに設定されています。clusterスコープを使用するには、ClusterListenerを設定する必要があります。

- Key - キャッシュがnameのみでなく、スコープ内の様々なエントリの値で指定されていることを示します。CacheTagのキーと同様に指定されますが、pageスコープを使用することはできません。

- Vars - キャッシュするページにより自動的に計算される変数。一般的に、入力パラメータに基づいてデータベースから情報を引き出すサーブレットで使用されます。

- Size - キャッシュされる一意のキー値の最大数。デフォルトでは、無制限になっています。
次の例は、フィルタ・コード内の初期化パラメータの指定場所を示します。

<filter>
<filter-name>HTML</filter-name>
<filter-class>weblogic.cache.filter.CacheFilter</filter-class>
<init-param>

- Max-cache-size - キャッシュに追加される要素の最大サイズ。デフォルトは64Kです。

HTTPサーブレットからのWebLogicサービスの使用方法

HTTPサーブレットを記述する際には、JNDI、JMS、EJB、JDBC接続など、WebLogic Serverの豊富な機能を利用できます。

以下のドキュメントには、これらの機能の詳細が記載されています。

- Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング

- Oracle WebLogic Server JDBCのプログラミング

- Oracle WebLogic Server JNDIのプログラミング

- Oracle WebLogic Server JMSのプログラミング

データベースへのアクセス

WebLogic Serverは、サーブレットを含むサーバー側JavaクラスからのJava Database Connectivity (JDBC)の使用をサポートしています。JDBCを使用すると、JavaクラスからSQLクエリを実行し、クエリの結果を処理できます。JDBCおよびWebLogic Serverの詳細は、『Oracle WebLogic Server JDBCのプログラミング』を参照してください。

次の項で説明するように、JDBCはサーブレットで使用できます。

- DataSourceオブジェクトを用いたデータベースへの接続

- JDBCドライバを用いたデータベースへの直接接続

DataSourceオブジェクトを用いたデータベースへの接続

DataSourceは、接続プールを参照するサーバー側オブジェクトです。接続プールの登録により、JDBCドライバ、データベース、ログインなど、データベース接続と関連するパラメータが定義されます。DataSourceオブジェクトおよび接続プールは、管理コンソールで作成します。

ヒント:

Java EE準拠のアプリケーションを作成する場合は、DataSourceオブジェクトの使用をお薦めします。

サーブレットでDataSourceを使用する

1. 管理コンソールを使用して接続プールを登録します。詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。

2. 接続プールを指すDataSourceオブジェクトを登録します。

3. JNDIツリーで、DataSourceオブジェクトをルックアップします。例:

Context ctx = null;
// Get a context for the JNDI look up
ctx = new InitialContext(ht);
// Look up the DataSource object
javax.sql.DataSource ds
= (javax.sql.DataSource) ctx.lookup ("myDataSource");

4. DataSourceを使用して、JDBC接続を作成します。例:

java.sql.Connection conn = ds.getConnection();

5. 接続を使用して、SQL文を実行します。例:

Statement stmt = conn.createStatement();
stmt.execute("select * from emp");
. . .

JDBCドライバを用いたデータベースへの直接接続

データベースへの直接接続は、データベース接続を確立する方法としては、最も効率の悪いものです。リクエストごとに新しいデータベース接続を確立しなければならないからです。データベースへの接続には、どのJDBCドライバも使用できます。Oracleでは、OracleおよびMicrosoft SQL Server用のJDBCドライバを提供しています。詳細は、『Oracle WebLogic Server JDBCのプログラミング』を参照してください。

HTTPサーブレットにおけるスレッドの問題

サーブレットの設計時に、高い負荷のもとで、WebLogic Serverがサーブレットをどのように呼び出すか検討する必要があります。複数のクライアントが同時にサーブレットをヒットすることは避けられません。したがって、サーブレットのコードは、共有リソースやインスタンス変数の共有違反を防ぐように記述します。

共有リソースの問題は、個々のサーブレットごとに処理することをお薦めします。次のガイドラインを念頭に置いてください。

- 可能な限り、同期を避けます。引き続き発生するサーブレットのリクエストが、現行のスレッドが完了するまで、ボトルネックになるためです。

- 各サーブレット・リクエストに固有の変数は、サービス・メソッドのスコープ内で定義します。ローカル・スコープ変数は、スタックに保存されるため、同一のメソッド内で実行されている複数のスレッドで共有されることはありません。したがって、同期の必要性はなくなります。

- 外部リソースへのアクセスは、Classレベルで同期を取るか、トランザクションにカプセル化します。

別のリソースへのリクエストのディスパッチ

この項では、リクエストをサーブレットから別のリソースへディスパッチするのによく使用されるメソッドの概要を説明します。

サーブレットでは、リクエストを別のリソース(サーブレット、JSP、またはHTMLページなど)に渡すことができます。このプロセスは、リクエストのディスパッチと呼ばれます。リクエストをディスパッチする場合は、RequestDispatcherインタフェースのinclude()メソッドまたはforward()メソッドを使用します。

リクエストのディスパッチに関する詳細な説明については、Servlet 2.4仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specsを参照)の8.2項を参照してください。

RequestDispatcherを使用すると、HTTPリダイレクト・レスポンスをクライアントに送り返す必要がなくなります。RequestDispatcherは、リクエストされたリソースにHTTPリクエストを渡します。

リクエストを特定のリソースにディスパッチするには:

1. 次のように、ServletContextへの参照を取得します。

ServletContext sc = getServletConfig().getServletContext();

2. 以下のメソッドの1つを用いて、RequestDispatcherオブジェクトをルックアップします。

- RequestDispatcher rd = sc.getRequestDispatcher(String path);

- pathは、Webアプリケーションのルートに対する相対パスである必要があります。

- RequestDispatcher rd = sc.getNamedDispatcher(String name);
nameを、Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlの中で<servlet-name>要素によってそのサーブレットに割り当てられた名前で置き換えます。

- RequestDispatcher rd = ServletRequest.getRequestDispatcher(String path);
このメソッドはRequestDispatcherオブジェクトを返すものであって、ServletContext.getRequestDispatcher(String path)メソッドに似ています。ただし、ここでは、pathを現在のサーブレットに対して相対的になるように指定することができます。/記号で始まるパスは、Webアプリケーションに対して相対的であると解釈されます。

HTTPサーブレット、JSPページ、通常のHTMLページなど、Webアプリケーション内のどのHTTPリソースについても、getRequestDispatcher()メソッドでリソースの適切なURLをリクエストすることによって、RequestDispatcherを取得できます。戻されたRequestDispatcherオブジェクトを使用して、リクエストを別のサーブレットに転送します。

3. 適切なメソッドを使用して、リクエストを転送またはインクルードします。

- rd.forward(request,response); (「リクエストの転送」を参照)

- rd.include(request,response); (「リクエストのインクルード」を参照)

リクエストの転送

一度、正しいRequestDispatcherが得られると、サーブレットは、引数として、HTTPServletRequestとHTTPServletResponseを渡し、RequestDispatcher.forward()メソッドを使用して、リクエストを転送します。出力がすでにクライアントに送られた状態でこのメソッドを呼び出すと、IllegalStateExceptionがスローされます。レスポンス・バッファの中に、コミットされていない保留中の出力がある場合には、バッファはリセットされます。

サーブレットは、レスポンスに対する以前の出力を書き込もうとしてはいけません。リクエストを転送する前に、レスポンスのためにサーブレットがServletOutputStreamまたはPrintWriterを取得すると、IllegalStateExceptionがスローされます。

元のサーブレットからのそれ以外の出力はすべて、リクエストが転送された後は無視されます。

どのタイプの認証を使用する場合でも、転送されたリクエストは、デフォルトではユーザーに再認証をリクエストしません。この動作を変更して、転送されたリクエストの認証を実行するには、check-auth-on-forward/要素をWebLogic固有のデプロイメント記述子(weblogic.xml)のcontainer-descriptor要素に追加します。例:

<container-descriptor>
<check-auth-on-forward/>
</container-descriptor>

リクエストのインクルード

サーブレットでは、RequestDispatcher.include()メソッドを使用して、引数としてHTTPServletRequestとHTTPServletResponseを渡すことにより、他のリソースからの出力をインクルードすることができます。その場合、インクルードされたリソースは、リクエスト・オブジェクトにアクセスできます。

インクルードされたリソースは、レスポンス・オブジェクトのServletOutputStreamまたはWriterオブジェクトにデータを書き戻すことができ、その後、レスポンス・バッファにデータを追加するか、またはレスポンス・オブジェクトに対しflush()メソッドを呼び出すかのいずれかを行うことができます。レスポンスのステータス・コード、またはインクルードされたサーブレットのレスポンスからのHTTPヘッダー情報を設定しようとすると、すべて無視されます。

実際には、include()メソッドを使用して、サーブレット・コードから他のHTTPリソースの「サーバー側インクルード」を実現できます。

RequestDispatcherとフィルタ

Servlet 2.3仕様では、転送やインクルードに対してフィルタを適用するかどうかを指定していませんでした。Servlet 2.4仕様では、web.xmlデプロイメント記述子に新しくdispatcher要素を導入することにより、これを明確化しています。このdispatcher要素を使用することで、REQUEST/FORWARD/INCLUDE/ERRORに対して適用されるフィルタ・マッピング(filter-mapping)を構成できます。WebLogic Server 8.1では、デフォルトはREQUEST+FORWARD+INCLUDEでした。古いDTDベースのデプロイメント記述子については、後方互換性を維持するため、デフォルト値は変更されていません。新しい記述子(スキーマ・ベース)については、デフォルトはREQUESTです。

ディスパッチされたリクエストのデフォルトの動作は、weblogic.xmlでfilter-dispatched-requests-enabled要素を設定することで、変更できます。この要素は、ディスパッチされた(転送またはインクルード)リクエストにフィルタを適用するかどうかを制御するものです。古いDTDベースのデプロイメント記述子のデフォルト値はtrueです。新しいスキーマ・ベースの記述子のデフォルトはfalseです。

RequestDispatcherとフィルタの詳細は、http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specsのServlet 2.4仕様の6.2.5項を参照してください。WebLogic Server用のフィルタの記述と構成の詳細は、第14章「フィルタ」を参照してください。

別のWebサーバーへのリクエストのプロキシ

次の項では、別のWebサーバーにHTTPリクエストをプロキシする方法について説明します。

- 別のWebサーバーへのリクエストのプロキシの概要

- セカンダリWebサーバーへのプロキシの設定

- プロキシ・サーブレットのデプロイメント記述子のサンプル

別のWebサーバーへのリクエストのプロキシの概要

WebLogic ServerをプライマリWebサーバーとして使用する場合、特定のリクエストをセカンダリWebサーバー(Netscape Enterprise Server、Apache、Microsoft Internet Information Serverなど)に引き渡す(プロキシする)ようにWebLogic Serverを構成することもあります。プロキシされる要求はすべて、特定のURLにリダイレクトされます。要求は、別のマシン上の別のWebサーバーにプロキシすることもできます。プロキシは、受信する要求のURLに基づいて行います。

HttpProxyServlet(配布キットの一部として提供)は、WebLogic Serverを介してHTTPリクエストを取得し、プロキシURLにリダイレクトして、そのレスポンスをクライアントのブラウザに送信します。HttpProxyServletを使用するには、Webアプリケーションでそれを構成して、リクエストをリダイレクトするWebLogic ServerにそのWebアプリケーションをデプロイします。

セカンダリWebサーバーへのプロキシの設定

セカンダリHTTPサーバーのプロキシを設定するには:

1. proxyサーブレットをWebアプリケーション・デプロイメント記述子に登録します(ProxyServletで使用するweb.xmlのサンプルを参照)。Webアプリケーションは、リクエストに応答するサーバー・インスタンスのデフォルトWebアプリケーションである必要があります。プロキシ・サーブレットのクラス名は、weblogic.servlet.proxy.HttpProxyServletです。

2. <param-name>にredirectURLを指定し、<param-value>にプロキシされるリクエストのリダイレクト先サーバーのURLを指定して、ProxyServletの初期化パラメータを定義します。

3. 独自のID証明書とキーで双方向SSLを使用する場合は、必要に応じて以下の<KeyStore>初期化パラメータを定義します。デプロイメント記述子に<KeyStore>が指定されていない場合、プロキシでは一方向SSLと見なされます。

- <KeyStore> - Webアプリケーションのキーストアの場所。

- <KeyStoreType> - キーストアのタイプ。定義されていない場合、デフォルトのタイプが使用されます。

- <PrivateKeyAlias> - 秘密鍵の別名。

- <KeyStorePasswordProperties> - Webアプリケーション内のプロパティ・ファイル。キーストアおよび秘密鍵の別名にアクセスするための暗号化されたパスワードを定義します。このファイルの内容は次のとおりです。このファイルは次のような内容を持ちます。

KeyStorePassword={3DES}i4+50LCKenQO8BBvlsXTrg\=\=
PrivateKeyPassword={3DES}a4TcG4mtVVBRKtZwH3p7yA\=\=

パスワードを暗号化するためにweblogic.security.Encryptコマンド・ライン・ユーティリティを使用する必要があります。EncryptユーティリティおよびCertGenとder2pemユーティリティの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のWebLogic Server Javaユーティリティの使用に関する項を参照してください。

4. ProxyServletを<url-pattern>にマップします。特に、プロキシするファイルの拡張子(*.jsp、*.htmlなど)をマップします。Webアプリケーション・デプロイメント記述子web.xmlで<servlet-mapping>要素を使用します。
<url-pattern>を「/」に設定した場合、WebLogic Serverによって解決できないリクエストはすべてリモート・サーバーにプロキシされます。しかし、拡張子が*.jsp、*.htm、および*.htmlのファイルをプロキシする場合、これらの拡張子もマップする必要があります。

5. 受信するリクエストをリダイレクトするWebLogic ServerインスタンスにWebアプリケーションをデプロイします。

プロキシ・サーブレットのデプロイメント記述子のサンプル

ProxyServletを使用するためのWebアプリケーション・デプロイメント記述子のサンプルを次に示します。

例9-2 ProxyServletとともに使用するweb.xmlのサンプル

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://java.sun.com/xml/ns/j2ee"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="2.4">

<web-app>

<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>weblogic.servlet.proxy.HttpProxyServlet</servlet-class>

<init-param>
<param-name>redirectURL</param-name>
<param-value>http://server:port</param-value>
</init-param>

<init-param>
<param-name>KeyStore</param-name>
<param-value>/mykeystore</param-value>
</init-param>

<init-param>
<param-name>KeyStoreType</param-name>
<param-value>jks</param-value>
</init-param>

<init-param>
<param-name>PrivateKeyAlias</param-name>
<param-value>passalias</param-value>
</init-param>

<init-param>
<param-name>KeyStorePasswordProperties</param-name>
<param-value>mykeystore.properties</param-value>
</init-param>

</servlet>

<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>

</web-app>

サーブレットのクラスタリング

サーブレットをクラスタリングすると、フェイルオーバーとロード・バランシングのメリットを活かせます。WebLogic Serverのクラスタにサーブレットをデプロイするには、サーブレットを含むWebアプリケーションをクラスタ内のすべてのサーバーにデプロイします。

サーブレットのクラスタリングに関する要件と、クラスタリングされたサーブレットに送信されるリクエストのフェイルオーバー・プロセスの詳細は、『Oracle WebLogic Serverクラスタの使用』のサーブレットとJSPのレプリケーションとフェイルオーバーに関する項を参照してください。

注意:

サーブレットの自動フェイルオーバーでは、サーブレット・セッション状態をメモリー内にレプリケートする必要があります。手順は、『Oracle WebLogic Serverクラスタの使用』のインメモリーHTTPレプリケーションの構成に関する項を参照してください。

サーブレットに関してWebLogic Serverクラスタがサポートしているロード・バランシングと、関連するプランニングと構成に関する開発者および管理者向け考慮事項の詳細は、『Oracle WebLogic Serverクラスタの使用』のサーブレットとJSPのロード・バランシングに関する項を参照してください。

Webアプリケーションでのサーブレットの参照

Webアプリケーションでサーブレットを参照するためのURLは、次のように構成されます。

http://myHostName:port/myContextPath/myRequest/myRequestParameters

URLの各要素は次のように定義します。

- myHostName: WebLogic Server管理コンソールで定義される、WebLogic ServerにマップされるDNS名です。URLのこの部分は、host:portに置き換えることができます。hostは、WebLogic Serverが実行されているマシン名、portはWebLogic Serverがリクエストをリスニングしているポートです。

- port - WebLogic Serverがリクエストをリスニングしているポートです。サーブレットは、Server MBeanとSSL MBean上のlistenPortポートを通じてのみプロキシと通信できます。

- myContextPath - weblogic.xmlファイルで指定されるコンテキスト・ルート名、またはconfig.xmlファイルで指定されるWebモジュールのURIです。

- myRequest - web.xmlファイルで定義されるサーブレット名です。

- myRequestParameters - URLにエンコードされるHTTPリクエスト・パラメータです(オプション)。HTTPサーブレットで読取り可能です。

URLパターン・マッチング

WebLogic Serverには、Java EEのマッチング・ルールに適合していないURLマッチング・ユーティリティを実装する機能があります。マッチング・ユーティリティは、デフォルトで実装されるURLMatchMapとは異なり、web.xmlデプロイメント記述子ではなく、weblogic.xmlデプロイメント記述子で構成する必要があります。

URLマッチング・ユーティリティをWebLogic Serverで使用するには、次のインタフェースを実装する必要があります。

Package weblogic.servlet.utils;
public interface URLMapping {
public void put(String pattern, Object value);
public Object get(String uri);
public void remove(String pattern)
public void setDefault(Object defaultObject);
public Object getDefault();
public void setCaseInsensitive(boolean ci);
public boolean isCaseInsensitive();
public int size();
public Object[] values();
public String[] keys();
}

SimpleApacheURLMatchMapユーティリティ

同梱されているSimpleApacheURLMatchMapユーティリティは、Java EE固有のユーティリティではありません。このユーティリティは、weblogic.xmlデプロイメント記述子ファイルで構成します。このユーティリティを使用すると、ユーザーは、web.xmlデプロイメント記述子に指定されたデフォルトのURLパターン・マッチングではなく、Apacheスタイルのパターン・マッチングを指定することができます。詳細については、「url-match-map」を参照してください。

HTTPサーブレットの将来的レスポンス・モデル

一般的に、WebLogic Serverが着信するHTTPリクエストを処理すると、レスポンスは即座にクライアントに返されます。そのような接続は、同じスレッドによって同期的に処理されます。しかし、一部のHTTPリクエストでは、より長い処理時間が必要となることがあります。たとえばデータベース接続で生じるレスポンス時間は、より長くなる場合があります。これらのリクエストの同期的な処理では、そのリクエストが処理されてレスポンスが送信されるまで待機が行われ、スレッドが保持されます。

このようにスレッドがハングしてしまう状況を回避するため、WebLogic Serverでは、着信するリクエストを処理するスレッドからレスポンスを切り離すことによって、HTTPリクエストを非同期に処理する、2つのクラスが用意されています。次の項で、これらのクラスについて説明します。

抽象非同期サーブレット

抽象非同期サーブレットを使用すると、着信するリクエストとサーブレット・レスポンスを、別々のスレッドで処理できます。このクラスはスレッド処理を含めて、将来的レスポンス・サーブレットよりもレスポンスを処理するための全般的なフレームワークが優れています。

抽象非同期サーブレットを実装するには、weblogic.servlet.http.AbstractAsyncServlet.javaクラスを拡張します。このクラスにより、拡張クラスでオーバーライドする必要のある以下の抽象メソッドが提供されます。

doRequest

このメソッドは、サーブレット・リクエストを処理します。次のサンプル・コードでは、このメソッドをオーバーライドする方法を示します。

例9-3 AbstractAsynchServlet.javaのdoRequestのオーバーライド

public boolean doRequest(RequestResponseKey rrk)
throws ServletException, IOException {
HttpServletRequest req = rrk.getRequest();
HttpServletResponse res = rrk.getResponse();

if (req.getParameter("immediate") != null) {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.println("Hello World Immediately!");
return false ;
}
else {
TimerManagerFactory.getTimerManagerFactory()
.getDefaultTimerManager().schedule
(new TimerListener() {
public void timerExpired(Timer timer)
{try {
AbstractAsyncServlet.notify(rrk, null);
}
catch (Exception e) {
e.printStackTrace();
}
}
}, 2000);
return true;
}
}

doResponse

このメソッドは、サーブレット・レスポンスを処理します。

注意:

元の着信リクエスト・メソッドの処理に使用されるdoRequest()メソッドを処理していたサーブレット・インスタンスが、必ずしもdoResponse()メソッドを処理するとは限りません。

処理中に例外が発生した場合、コンテナはクライアントにエラーを返します。次のサンプル・コードでは、このメソッドをオーバーライドする方法を示します。

例9-4 AbstractAsyncServlet.javaのdoResponse()のオーバーライド

public void doResponse (RequestResponseKey rrk, Object context)
throws ServletException, IOException
{
HttpServletRequest req = rrk.getRequest();
HttpServletResponse res = rrk.getResponse();

res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.println("Hello World!");
}

doTimeOut

このメソッドは、タイムアウト期間中にnotify()メソッドが呼び出されなかった場合に、サーブレット・レスポンス・エラーを送信します。

注意:

元の着信リクエスト・メソッドの処理に使用されるdoRequest()メソッドを処理していたサーブレット・インスタンスが、必ずしもdoTimeOut()メソッドを処理するとは限りません。

例9-5 AbstractAsyncServlet.javaのdoTimeOut()のオーバーライド

public void doTimeout (RequestResponseKey rrk)
throws ServletException, IOException
{
HttpServletRequest req = rrk.getRequest();
HttpServletResponse res = rrk.getResponse();

res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.println("Timeout!");
}

将来的レスポンス・サーブレット

抽象非同期サーブレットを使用することをお薦めしますが、着信するリクエストを処理するスレッドとは別のスレッドでサーブレット・レスポンスを処理するには、将来的レスポンス・サーブレットを使用できます。このサーブレットを有効化するには、weblogic.servlet.FutureResponseServlet.javaを拡張します。これにより、レスポンスの処理方法が完全に制御され、スレッドの処理をより詳細に管理できます。ただし、このクラスを使用してスレッドのハングを防ぐためには、コードのほとんどを指定する必要があります。

正確な実装は、ニーズに応じて変わりますが、少なくともこのクラスのservice()メソッドをオーバーライドする必要があります。以下の例では、サービス・メソッドをオーバーライドする方法を示します。

例9-6 FutureResponseServlet.javaのservice()メソッドのオーバーライド

public void service(HttpServletRequest req, FutureServletResponse rsp)
throws IOException, ServletException {
if(req.getParameter("immediate") != null){
PrintWriter out = rsp.getWriter();
out.println("Immediate response!");
rsp.send();
} else {
Timer myTimer = new Timer();
MyTimerTask mt = new MyTimerTask(rsp, myTimer);
myTimer.schedule(mt, 100);
}
}

private static class MyTimerTask extends TimerTask{
private FutureServletResponse rsp;
Timer timer;
MyTimerTask(FutureServletResponse rsp, Timer timer){
this.rsp = rsp;
this.timer = timer;
}
public void run(){
try{
PrintWriter out = rsp.getWriter();
out.println("Delayed Response");
rsp.send();
timer.cancel();
}
catch(IOException e){
e.printStackTrace();
}
}
}

10 セッションとセッション永続性の使用

この章では、セッションとセッションの永続性を設定および使用する方法について説明します。

- HTTPセッションの概要

- セッション管理の設定

- セッションの永続性の構成

- 永続記憶域用データベースの使用方法(JDBC永続性)

- Cookieに代わるURL書換えの使用

- サーブレットからのセッション・トラッキング

HTTPセッションの概要

セッション・トラッキングを使用すると、複数のサーブレットかHTMLページにわたって、本来はステートレスであるユーザーの状況を追跡できます。セッションとは、ある期間中に同じクライアントから出される一連の関連性のあるブラウザ・リクエストのことです。セッション・トラッキングは、ショッピング・カート・アプリケーションのように、全体としてなんらかの意味を持つ一連のブラウザ・リクエスト(これをページと見なす)を結合します。

セッション管理の設定

WebLogic Serverは、デフォルトによってセッション・トラッキングを処理するよう設定されています。セッション・トラッキングを使用する際にプロパティを設定する必要はありません。ただし、WebLogic Serverがどのようにセッションを管理するかを構成することは、最高のパフォーマンスを実現するためにアプリケーションをチューニングするときの重要な鍵となります。セッション管理を設定するときは、次のような要素を決定します。

- サーブレットをヒットする予定ユーザー数

- 各セッションの継続時間

- 各ユーザーに対する予定格納データ量

- WebLogic Serverインスタンスに割り当てられるヒープ・サイズ

HTTPセッションのデータを永続的に格納することもできます。「セッションの永続性の構成」を参照してください。

HTTPセッション・プロパティ

WebLogic Serverのセッション・トラッキングは、WebLogic固有のデプロイメント記述子であるweblogic.xmlにプロパティを定義することによって構成します。セッション属性の全リストについては、「session-descriptor」を参照してください。

以前のリリースのWebLogic Serverでは、SessionIDの形式が変更されたことで、ロード・バランサがセッションの固定を保持できなくなっていました。サーバー起動フラグ(-Dweblogic.servlet.useExtendedSessionFormat=true)に、ロード・バランシング・アプリケーションがセッションを固定するために必要な情報が保持されるようになりました。URLの書換えがアクティブになっていると、拡張されたセッションIDの形式はURLの一部になり、起動フラグがtrueに設定されます。

セッション・タイムアウト

HTTPセッションが期限切れになるまでの間隔を指定できます。セッションが期限切れになると、そのセッションに格納されたデータは破棄されます。この間隔は、次のとおりweb.xmlまたはweblogic.xmlに設定できます。

- WebLogic固有のデプロイメント記述子であるweblogic.xmlのsession-descriptor要素のtimeout-secsパラメータ値を設定します。この値は秒単位で設定します。詳細は、「session-descriptor」を参照してください。

- Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlでsession-timeout要素を設定します。

WebLogic ServerセッションCookieの構成

WebLogic Serverは、Cookieがクライアント・ブラウザによってサポートされる場合、Cookieを使用してセッション管理を行います。

WebLogic Serverがセッション・トラッキングに使用するCookieは、デフォルトによって一時的なものとして設定されているため、セッションより長く存続することはありません。ユーザーがブラウザを終了すると、Cookieは失われ、セッションが終了します。この動作はセッションの用途の基本であり、このようにセッションを使用することをお薦めします。

Cookieのセッション・トラッキング・パラメータは、WebLogic固有のデプロイメント記述子であるweblogic.xmlで構成できます。セッションとCookieに関連するパラメータの全リストについては、「session-descriptor」を参照してください。

セッションより長く存続するアプリケーションCookieの構成

長く存続するクライアント側のユーザー・データの場合、アプリケーションをプログラムして、HTTPサーブレットAPIによってブラウザ上で独自のCookieを作成して構成します。アプリケーションは、HTTPセッションに関連付けられたCookieを使用するよう試行しません。アプリケーションがCookieを使用して特定のマシンのユーザーの自動ログインを行う場合、新しいCookieの存続期間を長く設定します。Cookieは、クライアント・マシンだけから送ることができます。アプリケーションは、そのユーザーが複数の場所からアクセスする必要がある場合、サーバーにデータを格納する必要があります。

ブラウザCookieの存続期間を直接セッションの長さに関連付けることはできません。Cookieがそれに関連付けられているセッションより早く期限切れになった場合、そのセッションは切り離されてしまいます。セッションがそれに関連付けられているCookieより早く期限切れになった場合、サーブレットはそのセッションを見つけることができません。この場合、新しいセッションはrequest.getSession(true)メソッドが呼び出されるときに自動的に割り当てられます。

Cookieの最大存続時間は、weblogic.xmlデプロイメント記述子のセッション記述子にあるcookie-max-age-secs要素で設定できます。「session-descriptor」を参照してください。

ログアウト

ユーザー認証情報は、ユーザーのセッション・データと、Webアプリケーションのターゲットとなるサーバーまたは仮想ホストのコンテキストの両方に格納されます。ユーザーのログアウトに多く使われるsession.invalidate()メソッドでは、ユーザーの現在のセッションのみが無効になり、ユーザーの認証情報は有効なまま、サーバーまたは仮想ホストのコンテキストに格納されます。サーバーまたは仮想ホストが1つのWebアプリケーションのみのホストである場合、実際にはsession.invalidate()メソッドでユーザーをログアウトします。

複数のWebアプリケーションで認証を使用するときには、複数のJavaメソッドと方式を使用できます。詳細は、「セッションのログアウトと終了」を参照してください。

Webアプリケーション間の同一セッション共有の有効化

デフォルトでは、Webアプリケーション間で同じセッションが共有されることはありません。Webアプリケーション間で同じセッションを共有する場合は、weblogic-application.xmlデプロイメント記述子において、アプリケーション・レベルでセッション記述子を構成できます。Webアプリケーション間で同じセッションを共有するには、weblogic-application.xmlデプロイメント記述子内で、セッション記述子のsharing-enabled属性をtrueに設定します。「session-descriptor」の「sharing-enabled」を参照してください。

アプリケーション・レベルで指定したセッション記述子の構成は、アプリケーション内のすべてのWebアプリケーションについて、Webアプリケーション・レベルで指定したすべてのセッション記述子構成をオーバーライドします。Webアプリケーション・レベルでsharing-enabled属性をtrueに設定しても、これは無視されます。

アプリケーション内のすべてのWebアプリケーションは、次の例のようにweblogic-application.xmlデプロイメント記述子内でセッション記述子を指定して、sharing-enabled属性をtrueに設定した場合、同じセッション・インスタンスを使用して自動的に起動されます。

<?xml version="1.0" encoding="ISO-8859-1"?>

<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application";;>
...
<session-descriptor>
<persistent-store-type>memory</persistent-store-type>
<sharing-enabled>true</sharing-enabled>
...
</session-descriptor>
...
</weblogic-application>

セッションの永続性の構成

セッションの永続性を使用して、HTTPセッション・オブジェクトにデータを永続的に格納し、WebLogic Serverのクラスタ全体のフェイルオーバーとロード・バランシングを有効にします。アプリケーションがHTTPセッション・オブジェクトにデータを格納するとき、データをシリアライズ可能にする必要があります。

セッションの永続性の実装は、以下の5つです。

- メモリー(単一サーバー、非レプリケート)

- ファイル・システムの永続性

- JDBCの永続性

- Cookieベースの永続性

- インメモリー・レプリケーション(クラスタ全体)

最初の4つについてはここで説明します。インメモリー・レプリケーションの詳細は、『Oracle WebLogic Serverクラスタの使用』のHTTPセッション状態のレプリケーションに関する項を参照してください。

ファイル、JDBC、Cookieベース、およびメモリー(単一サーバー、非レプリケート)のセッション永続性には、共通のプロパティがいくつか存在します。以次の項で説明するとおり、各永続性メソッドはそれぞれ独自の構成可能なパラメータ・セットを持っています。これらのパラメータは、weblogic.xmlデプロイメント記述子ファイルのsession-descriptor要素の下位要素です。

各種のセッション永続性の共有属性

この項では、ファイル・ベースの永続性とJDBCベースの永続性に共通するパラメータについて説明します。weblogic.xmlデプロイメント記述子ファイルのsession-descriptor要素で次のパラメータを定義することにより、メモリー内に保持されるセッション数を構成できます。これらのパラメータは、セッション永続性を使用している場合にのみ適用できます。

- cache-size - メモリー内で一度にアクティブにできるキャッシュしたセッションの数を制限します。同時に大量のアクティブ・セッションが予想される場合、仮想メモリーとのスワップにより、パフォーマンスが低下する可能性があるため、これらのセッションでサーバーのRAMを取り込む必要はありません。キャッシュがいっぱいになった場合、最低使用頻度セッションは永続ストアに格納され、必要に応じて自動的にリコールされます。永続性を使用しない場合、このプロパティは無視され、メイン・メモリーに許可されるセッションの数にソフト制限はありません。デフォルトでは、キャッシュしたセッションの数は1028です。キャッシュをオフにするには、この数を0に設定します。session-descriptorのcache-sizeに関する項を参照してください。

注意:

cache-sizeは、JDBCおよびファイル・ベースのセッションによって、インメモリー・バブル・キャッシュを保持する目的にのみ使用されます。他の永続性タイプには適用されません。

- invalidation-interval-secsは、タイムアウトの無効なセッションに対してハウスクリーニング・チェックを実行してから古いセッションを削除してメモリーを解放するまでWebLogicサーバーが待機する時間(秒)を設定します。この要素を使用して、トラフィックの多いサイトでWebLogic Serverのパフォーマンスが最適化されるようにチューニングします。session-descriptorの「invalidation-interval-secs」を参照してください。
最小値は毎秒(1)です。最大値は、週に1回(604,800秒)です。この属性を設定しない場合、デフォルトは60秒になります。

メモリー・ベース、単一サーバー、非レプリケート永続ストレージの使用方法

メモリー・ベースのストレージを使用する場合、すべてのセッション情報はメモリーに格納され、WebLogic Serverを終了して再起動すると失われます。メモリー・ベース、単一サーバー、非レプリケート永続ストレージを使用するには、weblogic.xmlデプロイメント記述子ファイルのsession-descriptor要素にあるpersistent-store-typeパラメータをmemoryに設定します。「session-descriptor」を参照してください。

注意:

WebLogic Serverを実行するときに十分なヒープ・サイズを割り当てないと、負荷がかかったときにサーバーのメモリーが足りなくなることがあります。

ファイル・ベースの永続ストレージの使用方法

ファイル・ベースの永続ストレージをセッション用に構成するには:

- デプロイメント記述子ファイルweblogic.xmlで、session-descriptor要素内のpersistent-store-typeパラメータをfileに設定します。『session-descriptor』の「persistent-store-type」を参照してください。

- WebLogic Serverがセッションを格納するディレクトリを設定します。session-descriptorの「persistent-store-dir」を参照してください。

注意:

このディレクトリは作成する必要があります。また、適切なアクセス権限がディレクトリに割り当てられていることを確認します。

永続記憶域用データベースの使用方法(JDBC永続性)

JDBCの永続性は、この目的のために提供されたスキーマを使ってデータベース表にセッション・データを格納します。JDBCドライバを備えたデータベースはすべて使用できます。データベース・アクセスは、接続プールを使って構成します。

JDBCセッションの永続性を利用している場合、WebLogic Serverはシステム時間を使用してセッションのセッション・ライフ時間を判別するため、同じクラスタ内でサーバーが実行されているすべてのマシン上のシステム・クロックを同期する必要があります。

JDBCベースの永続ストレージを構成する

JDBCベースの永続ストレージをセッション用に構成するには:

- weblogic.xmlデプロイメント記述子ファイルのsession-descriptor要素にあるpersistent-store-typeパラメータをjdbcに設定します。「session-descriptor」を参照してください。

- weblogic.xmlデプロイメント記述子ファイルのsession-descriptor要素にあるpersistent-store-poolパラメータを使用して、永続ストレージに使用されるJDBC接続プールを設定します。WebLogic Server 管理コンソールで定義される接続プールの名前を使用します。「session-descriptor」を参照してください。

- JDBCベースの永続性のためのwl_servlet_sessionsというデータベース表を設定します。データベースに接続する接続プールは、この表の読取り/書込みアクセス権を保有する必要があります。

注意:

データベースで自動的に作成されない場合は、wl_idおよびwl_context_pathに索引を作成します。一部のデータベースでは、主キーの索引が自動的に作成されます。

列名とデータ型を次のように設定します。

表10-1 wl_servlet_sessionsの作成

列名

データ型

wl_id

最大100文字の可変長の英数字列。例: Oracle VARCHAR2(100)。

主キーは次のように設定します。

wl_id + wl_context_path

wl_context_path

最大100文字の可変長の英数字列; 例: Oracle VARCHAR2(100)。この列は主キーの一部として使用します。(wl_id列の説明を参照。)

wl_is_new

1文字の列。例: Oracle CHAR(1)。

wl_create_time

20桁の数値列。例: Oracle NUMBER(20)。

wl_is_valid

1文字の列。例: Oracle CHAR(1)。

wl_session_values

ラージ・バイナリ・列。例: Oracle LONG RAW。

wl_access_time

20桁の数値列。例: NUMBER(20)。

wl_max_inactive_interval

整数列。例: Oracle Integer。クライアント・リクエストのセッションが無効になるまでの秒数。時間値が負の場合は、セッションがタイムアウトしないことを示します。

Oracle DBMSを使用している場合、次のSQL文を使ってwl_servlet_sessions表を作成できます。このSQL文をユーザーのDBMSにあわせて変更します。

例10-1 Oracle DBMSを使用したwl_servlet_sessions表の作成

create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new CHAR(1),
wl_create_time NUMBER(20),
wl_is_valid CHAR(1),
wl_session_values LONG RAW,
wl_access_time NUMBER(20),
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) );

注意:

ユーザーは、jdbc-connection-timeout-secsパラメータを使用して、JDBCセッション永続性がセッション・データのロードに失敗するまで、接続プールからのJDBC接続を待つ最大の期間を構成できます。詳細は、「session-descriptor」を参照してください。

SqlServer2000を使用している場合、次のSQL文を使ってwl_servlet_sessions表を作成できます。このSQL文をユーザーのDBMSにあわせて変更します。

例10-2 SqlServer 2000を使用したwl_servlet_sessions表の作成

create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new VARCHAR(1),
wl_create_time DECIMAL,
wl_is_valid VARCHAR(1),
wl_session_values IMAGE,
wl_access_time DECIMAL,
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) );

DB2を使用している場合、次のSQL文を使ってwl_servlet_sessions表を作成できます。このSQL文をユーザーのDBMSにあわせて変更します。

例10-3 DB2を使用したwl_servlet_sessions表の作成

CREATE TABLE WL_SERVLET_SESSIONS
(
WL_ID VARCHAR(100) not null,
WL_CONTEXT_PATH VARCHAR(100) not null,
WL_IS_NEW SMALLINT,
WL_CREATE_TIME DECIMAL(16),
WL_IS_VALID SMALLINT,
wl_session_values BLOB(10M) NOT LOGGED,
WL_ACCESS_TIME DECIMAL(16),
WL_MAX_INACTIVE_INTERVAL INTEGER,
PRIMARY KEY (WL_ID,WL_CONTEXT_PATH)
);

Sybaseを使用している場合、次のSQL文を使ってwl_servlet_sessions表を作成できます。このSQL文をユーザーのDBMSにあわせて変更します。

例10-4 Sybaseを使用したwl_servlet_sessions表の作成

create table WL_SERVLET_SESSIONS (
WL_ID                         varchar(100)                   not null  ,
WL_CONTEXT_PATH               varchar(100)                   not null  ,
WL_IS_NEW                     CHAR(1)                           null  ,
WL_CREATE_TIME                decimal(16,0)                      null  ,
WL_IS_VALID                   CHAR(1)                           null  ,
WL_SESSION_VALUES             image                              null  ,
WL_ACCESS_TIME                decimal(16,0)                      null  ,
WL_MAX_INACTIVE_INTERVAL      int                                null  ,
)
go

alter table WL_SERVLET_SESSIONS
add PRIMARY KEY CLUSTERED (WL_ID, WL_CONTEXT_PATH)
go

JDBCセッション永続性のためにキャッシングおよびデータベース更新を行う

WebLogic Serverは、リクエストが読取り専用の場合は、HTTPセッション状態をディスクに書き込みません。つまりリクエストによってHTTPセッションに変更が加えられることはありません。セッションがアクセスされると、データベース内ではwl_access_time列のみが更新されます。

読取り専用でないリクエストの場合、Webアプリケーション・コンテナは、HTTPリクエストのたびに、セッション状態の変更についてデータベースを更新します。これが行われるのは、クラスタ内のすべてのサーバーが、フェイルオーバーに際してリクエストを処理し、データベースから最新のセッション状態を取得できるようにするためです。

複数のデータベース・問合せが生じることを回避するため、WebLogic Serverでは最近使用されたセッションがキャッシュされます。最近使用されたセッションは、リクエストごとにデータベースからリフレッシュされることはありません。キャッシュ内のセッション数は、WebLogic Server固有のデプロイメント記述子weblogic.xmlのsession-descriptor要素内のcache-sizeパラメータによって規定されます。「session-descriptor」を参照してください。

Cookieベースのセッション永続性の使用

Cookieベースのセッション永続性は、ユーザーのブラウザのCookieにすべてのセッション・データを格納することで、セッション永続性のステートレスなソリューションを提供します。Cookieベースのセッション永続性が最も役に立つのは、セッションに大量のデータを格納する必要がないときです。Cookieベースのセッション永続性は、クラスタ・フェイルオーバー・ロジックが必要ないので、WebLogic Serverのインストール環境をより簡単に管理できます。セッションが格納されるのはブラウザ内であって、サーバー上ではありません。WebLogic Serverの起動と停止は、セッションを失わずに行うことができます。

Cookieベースのセッション永続性には、次に示すいくつかの制限事項があります。

- セッションに格納できるのは文字列属性のみです。セッションに他の種類のオブジェクトを格納した場合、IllegalArgument例外がスローされます。

- HTTPレスポンスはフラッシュできません(Cookieはレスポンスが発行される前にヘッダー・データに書き込まれる必要があるため)。

- レスポンスのコンテンツの長さがバッファ・サイズを超える場合、レスポンスは自動的にフラッシュされ、セッション・データはCookie内では更新できません。バッファ・サイズはデフォルトで8192バイトです。バッファ・サイズはjavax.servlet.ServletResponse.setBufferSize()メソッドで変更できます。

- 使用できる認証は基本的なもの(ブラウザ・ベース)のみです。

- セッション・データはクリア・テキストでブラウザに送信されます。

- ユーザーのブラウザを、Cookieを受け付けるように構成する必要があります。

- Cookieベースのセッション永続性を使用する場合、文字列でカンマ(,)を使用することはできません。これに従わない場合は例外が発生します。

Cookieベースのセッション永続性を設定するには:

- weblogic.xmlデプロイメント記述子ファイルのsession-descriptor要素にあるpersistent-store-typeパラメータをcookieに設定します。「session-descriptor」を参照してください。

- 必要な場合は、persistent-store-cookie-name要素を使ってCookieに名前を設定します。デフォルトはWLCOOKIEです。「session-descriptor」を参照してください。

Cookieに代わるURL書換えの使用

状況によっては、ブラウザまたは無線デバイスがCookieを受け入れないこともあります。この場合、Cookieによるセッション・トラッキングを行うことができません。URL書換えを使用すると、ブラウザがCookieを受け入れないことをWebLogic Serverが検出したときに、こうした状況を自動的に置き換えることができます。URL書換えでは、セッションIDをWebページのハイパーリンクにエンコードし、サーブレットはそれらをブラウザに送り返します。ユーザーが以後これらのリンクをクリックすると、WebLogic ServerはURLアドレスからそのIDを抽出し、サーブレットがgetSession()メソッドを呼び出すと適切なHttpSessionを見つけ出します。

WebLogic固有のデプロイメント記述子であるweblogic.xmlのsession-descriptor要素にurl-rewriting-enabledパラメータを設定することで、URL書換えを有効にします。この属性のデフォルト値はtrueです。「session-descriptor」を参照してください。

URL書換えのコーディングに関するガイドライン

URL書換えのサポートに関するガイドライン

- 次に示すように、URLを出力ストリームに直接書き出すことは避けます。

out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");

かわりに、HttpServletResponse.encodeURL()メソッドを使用します。例:

out.println("<a href=\"
+ response.encodeURL("myshop/catalog.jsp")
+ "\">catalog</a>");

encodeURL()メソッドを呼び出すと、URLを書き換える必要があるかどうかが調べられます。書換えが必要な場合、WebLogic Serverは、セミコロンで始まるセッションIDをURLに追加することによって、URLを書き換えます。

- WebLogic Serverへのレスポンスとして返されるURLに加えて、リダイレクトを送信するURLをエンコードします。例:

if (session.isNew())
response.sendRedirect (response.encodeRedirectUrl(welcomeURL));

WebLogic Serverはセッションが新しいときには、ブラウザがCookieを受け入れる場合でもURL書換えを使用します。これは、セッションの最初ではサーバーはブラウザがCookieを受け入れるかどうかを判断できないからです。

プラグイン(Apache、NSAPI、ISAPI、HttpClusterServlet、またはHttpProxyServlet)を使用しており、バックエンド・サーバーでURL書換え(response.sendRedirect(url)またはresponse.encodeRedirectURL(url))を使用している場合は、一定の条件を満たすと、URLにPathTrimパラメータとPathPrependパラメータの両方が適用されます。一定の条件とは、「PathPrependがnullであるか、PathPrependがすでに適用されている」というもので、PathTrimはこのいずれかを満たす場合にのみ適用されます。

- サーブレットは、HttpServletRequest.isRequestedSessionIdFromCookie()メソッドから返されるブール値をチェックすることによって、特定のセッションIDがCookieから受け取られたかどうかを確認できます。rアプリケーションは適切に応答するか、または、WebLogic ServerによるURL書換えに依存します。

注意:

CISCO Local Directorロード・バランサでは、疑問符"?"がURLの書換えのデリミタとして想定されています。WebLogic ServerのURLの書換えメカニズムではデリミタとしてセミコロン(;)を使用するため、WebLogic Serverの書換えとこのロード・バランサの間には互換性がありません。

URL書換えとWireless Access Protocol (WAP)

WAPアプリケーションを作成する場合、WAPプロトコルはCookieをサポートしていないため、URLを書き換える必要があります。また、一部のWAPデバイスでは、URLの長さが128文字(属性も含む)に制限されます。これにより、URL書換えによって転送できるデータ・サイズが制限されます。属性用の領域を大きくするために、WebLogic Serverでランダムに生成されるセッションIDのサイズを制限できます。

WAPEnabled属性を使用するには、管理コンソールを「サーバー」>「プロトコル」>「HTTP」>「拡張オプション」で使用します。WAPEnabled属性を使用すると、セッションIDのサイズが52文字までに制限され、!および#などの特殊文字の使用が禁止されます。weblogic.xmlのIDLengthパラメータを使用して、セッションIDのサイズをさらに制限することもできます。詳細は、session-descriptorの「id-length」を参照してください。

サーブレットからのセッション・トラッキング

セッション・トラッキングを使用すると、複数のサーブレットかHTMLページにわたって、本来はステートレスであるユーザーの状況を追跡できます。セッションとは、ある期間中に同じクライアントから出される一連の関連性のあるブラウザ・リクエストのことです。セッション・トラッキングは、ショッピング・カート・アプリケーションのように、全体としてなんらかの意味を持つ一連のブラウザ・リクエスト(これをページと見なす)を結合します。

次の項では、HTTPサーブレットからのセッション・トラッキングについて、様々な観点から説明します。

- セッション・トラッキングの履歴

- HttpSessionオブジェクトを用いたセッションのトラッキング

- セッションの存続期間

- セッション・トラッキングの仕組み

- セッションの開始の検出

- セッション名/値の属性の設定と取得

- セッションのログアウトと終了

- セッション・トラッキングの構成

- Cookieに代わるURL書換えの使用

- URL書換えとWireless Access Protocol (WAP)

- セッションの永続化

セッション・トラッキングの履歴

セッション・トラッキングという概念が発展する前は、ページの非表示フィールドに情報を詰め込むか、長い文字列をリンクで使われるURLに追加してユーザーの選択内容を埋め込むことで、ページに状態を組み込んでいました。このよい例が、サーチ・エンジン・サイトです。サーチ・エンジン・サイトの多くはいまだにCGIに依存しています。これらのサイトは、URLの後にHTTPで予約されている?記号を付け、その後に続くURLパラメータの名前=値のペアを使用して、ユーザーの選択を追跡します。このようにすると、URLは非常に長いものになることがあり、CGIスクリプトはこれを慎重に解析し、管理する必要があります。この手法の問題点は、情報をセッションからセッションへと渡せないことです。URLの制御を失うと、つまりユーザーがページから離れると、ユーザー情報は永久に失われます。

その後、NetscapeはブラウザのCookieを導入しました。これを使用してサーバーごとにクライアント上のユーザー関連情報を格納することができます。しかし、ブラウザによってはまだCookieを完全にサポートしていないものもあり、またブラウザのCookieオプションをオフにしておくことを選ぶユーザーもいます。もう1つの考慮すべき要因は、ほとんどのブラウザではCookieで格納できるデータ量を制限しているということです。

CGIの手法とは異なり、HTTPサーブレットの仕様では、サーバーがサーバー上のユーザーの詳細情報を単一のセッションを超えて格納できる方法が定義されており、セッションのトラッキングによるコードの複雑化を避けることが可能です。サーブレットを使用すると、HttpSessionオブジェクトによって単一のセッションを超える範囲でユーザー入力を追跡し、セッションの詳細を複数のサーブレットで共有できます。セッション・データは、WebLogicサービスで使用できる様々なメソッドを使用して保持することができます。

HttpSessionオブジェクトを用いたセッションのトラッキング

WebLogicが実装してサポートしているJava Servlet APIでは、各サーブレットはHttpSessionオブジェクトを使用して、サーバー側セッションにアクセスすることができます。HttpServletRequestオブジェクトを使用して、サーブレットのservice()メソッド内のHttpSessionオブジェクトにアクセスできます。次の例のように変数requestを使用します。

HttpSession session = request.getSession(true);

引数trueでrequest.getSession(true)メソッドが呼び出されると、そのクライアントに対して既存のHttpSessionオブジェクトがない場合には、HttpSessionオブジェクトが生成されます。セッション・オブジェクトは、そのセッションの存続期間の間WebLogic Serverに存在し、そのクライアントに関連した情報を蓄積します。サーブレットは、必要に応じて、セッション・オブジェクトで情報の追加や削除を行います。セッションは特定のクライアントに関連付けられます。クライアントがサーブレットを訪れると、毎回、getSession()メソッドが呼び出されたときに関連する同じHttpSessionオブジェクトが取得されます。

HttpSessionでサポートされるメソッドの詳細については、http://download.oracle.com/javaee/5/api/javax/servlet/http/HttpSession.htmlのHttpServlet APIを参照してください。

次の例では、service()メソッドが、セッション中にユーザーがサーブレットをリクエストする回数を数えます。

public void service(HttpServletRequest request,
HttpServletResponse, response)
throws IOException
{
// Get the session and the counter param attribute
HttpSession session = request.getSession (true);
Integer ival = (Integer)
session.getAttribute("simplesession.counter");
if (ival == null) // Initialize the counter
ival = new Integer (1);
else // Increment the counter
ival = new Integer (ival.intValue () + 1);
// Set the new attribute value in the session
session.setAttribute("simplesession.counter", ival);
// Output the HTML page
out.print("<HTML><body>");
out.print("<center> You have hit this page ");
out.print(ival + " times!");
out.print("</body></html>");
}

セッションの存続期間

セッションは、1つのトランザクションの一連のページにわたるユーザーの選択を追跡します。1つのトランザクションは、ある品物を閲覧し、それをショッピング・カートに追加した後、支払手続きをするといった複数のタスクで構成されます。セッションは永続的なものではなく、以下のいずれかの時点で、その存続期間は終了します。

- ユーザーがサイトを離れ、ブラウザがCookieを受け入れない場合。

- ユーザーがブラウザを終了した場合。

- 動作がないため、セッションがタイムアウトになった場合。

- セッションが完了し、サーブレットによって無効にされた場合。

- ユーザーがログアウトし、サーブレットによって無効にされた場合。

より永続的に長時間データを保存するには、サーブレットでJDBCまたはEJBを使用して詳細をデータベースに書き込み、存続期間が長いCookieやユーザー名とパスワードによって、そのデータとクライアントとを関連付ける必要があります。

注意:

このドキュメントでは、セッションが内部的にCookieや永続性を使用すると説明していますが、セッションをユーザーに関するデータ格納のための一般的なメカニズムとして使用してはいけません。

セッション・トラッキングの仕組み

WebLogic Serverでは、各クライアントにどのセッションが関連付けられているのかが、どのようにして認識されるのでしょうか。HttpSessionがサーブレットで生成されると、一意のIDと関連付けられます。ブラウザは、このセッションIDをそのリクエストに付与し、サーバーが再びセッション・データを見つけられるようにする必要があります。サーバーは、クライアントにCookieを設定することによって、このIDを保存しようとします。一度Cookieが設定されると、ブラウザがサーバーにリクエストを送るたびに、リクエストにはそのIDを内包したCookieが含まれます。サーバーは自動的にCookieを解析し、サーブレットがgetSession()メソッドを呼び出すと、セッション・データを提供します。

クライアントがCookieを受け入れない場合、代わりの方法としては、クライアントへ送り返されるページの中で、URLリンクにそのIDをエンコードするしかありません。このため、サーブレットのレスポンスにURLを入れる場合は、必ずencodeURL()メソッドを使用します。WebLogic ServerはブラウザがCookieを受け入れるかどうかを検出して、不必要なURLのエンコードは行いません。自動的に、エンコードされたURLからセッションIDを解析し、getSession()メソッドを呼び出すと、正しいセッション・データを取得します。encodeURL()メソッドを使用すると、セッション・トラッキングにどの手順を使用しても、サーブレットのコードが破壊されることはありません。詳細は、「Cookieに代わるURL書換えの使用」を参照してください。

セッションの開始の検出

getSession(true)メソッドを使用してセッションを取得した後、HttpSession.isNew()メソッドを呼び出すことにより、そのセッションが生成されたばかりかどうかがわかります。このメソッドがtrueを返した場合、クライアントはまだ有効なセッションを持っておらず、またこの時点では新規のセッションを認識しません。クライアントが新規のセッションを認識するのは、サーバーからレスポンスがポストされて戻ってからです。

ビジネス・ロジックに合った方法で、新規または既存のセッションに適応するようにアプリケーションを設計してください。たとえば、セッションがまだ開始していないと判断すれば、次のサンプル・コードのように、アプリケーションでクライアントのURLをログイン/パスワードのページにリダイレクトしてもよいでしょう。

HttpSession session = request.getSession(true);
if (session.isNew()) {
response.sendRedirect(welcomeURL);
}

ログインのページでは、システムにログインするか、新規アカウントを作成するかを選択できます。また、Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlのlogin-config要素を使用して、Webアプリケーションでログイン・ページを指定することもできます。

セッション名/値の属性の設定と取得

名前=値のペアを使用して、HttpSessionオブジェクトにデータを格納できます。セッションに格納されたデータは、そのセッションを通じて利用することができます。セッションにデータを格納するには、次のメソッドをHttpSessionインタフェースから使用します。

getAttribute()
getAttributeNames()
setAttribute()
removeAttribute()
The following code fragment shows how to get all the existing name=value pairs:
Enumeration sessionNames = session.getAttributeNames();
String sessionName = null;
Object sessionValue = null;

while (sessionNames.hasMoreElements()) {
sessionName = (String)sessionNames.nextElement();
sessionValue = session.getAttribute(sessionName);
System.out.println("Session name is " + sessionName +
", value is " + sessionValue);
}

名前の付いた属性を追加または上書きするには、setAttribute()メソッドを使用します。名前の付いた属性を完全に削除するには、removeAttribute()メソッドを使用します。

注意:

JavaのObjectの子孫をセッション属性として追加し、それに名前を関連付けることができます。ただし、セッション永続性を利用している場合、属性値オブジェクトはjava.io.Serializableを実装する必要があります。

セッションのログアウトと終了

アプリケーションがデリケートな情報を扱う場合は、セッションからログアウトする機能の提供を検討します。これは、ショッピング・カートやインターネットの電子メール・アカウントを使用する際には一般的な機能です。同一のブラウザがサービスに戻るとき、ユーザーはシステムにログインし直さなければなりません。

単一のWebアプリケーションに対しsession.invalidate()を使用する

ユーザー認証情報は、ユーザーのセッション・データと、Webアプリケーションのターゲットとなるサーバーまたは仮想ホストのコンテキストの両方に格納されます。ユーザーのログアウトに多く使われるsession.invalidate()メソッドでは、ユーザーの現在のセッションのみが無効になり、ユーザーの認証情報は有効なまま、サーバーまたは仮想ホストのコンテキストに格納されます。サーバーまたは仮想ホストが1つのWebアプリケーションのみをホストしている場合は、session.invalidate()メソッドを実行するとユーザーはログアウトされます。

session.invalidate()を呼び出した後、無効にされたセッションを参照しないでください。参照した場合、IllegalStateExceptionがスローされます。ユーザーが次に同じブラウザからサーブレットにアクセスしたときには、セッション・データは失われています。getSession(true)メソッドを呼び出すと、新しいセッションが作成されます。この時点で、ユーザーに再度ログイン・ページを送信できます。

複数のアプリケーションに対するシングル・サインオンを実装する

サーバーまたは仮想ホストが複数のWebアプリケーションによって割り当てられている場合、すべてのWebアプリケーションからユーザーをログアウトするには、別の方法が必要になります。サーブレット仕様では、すべてのWebアプリケーションからユーザーをログアウトするためのAPIが用意されていないため、次のメソッドを使用します。

- weblogic.servlet.security.ServletAuthentication.logout() - 認証データをユーザーのセッション・データから削除します。これにより、ユーザーはログアウトされますが、セッションは引き続き有効です。

- weblogic.servlet.security.ServletAuthentication.invalidateAll() - すべてのセッションを無効にして、現在のユーザーの認証データを削除します。Cookieも無効になります。

- weblogic.servlet.security.ServletAuthentication.killCookie() - レスポンスがブラウザに送信された直後に有効期限が切れるようにCookieを設定して、現在のCookieを無効にします。このメソッドでは、レスポンスがユーザーのブラウザに正常に届く必要があります。セッションはタイムアウトするまで維持されます。

シングル・サインオンからWebアプリケーションを除外する

シングル・サインオンへの参加からWebアプリケーションを除外するには、除外するWebアプリケーションに異なるCookie名を定義します。詳細は、「WebLogic ServerセッションCookieの構成」を参照してください。

セッション・トラッキングの構成

WebLogic Serverでは、セッション・トラッキングの処理方法を決定する様々な属性を構成できます。これらのセッション・トラッキング属性の構成の詳細は、「session-descriptor」を参照してください。

Cookieに代わるURL書換えの使用

状況によっては、ブラウザがCookieを受け入れないこともあります。この場合、Cookieによるセッション・トラッキングができません。代わりにURL書換えを使用すると、ブラウザがCookieを受け入れないことをWebLogic Serverが検出したときに、こうした状況を自動的に置き換えることができます。URL書換えでは、セッションIDをWebページのハイパーリンクにエンコードし、サーブレットはそれらをブラウザに送り返します。ユーザーが以後これらのリンクをクリックすると、WebLogic ServerはURLからそのIDを抽出し、適切なHttpSessionを見つけます。次にgetSession()メソッドを使用してセッション・データにアクセスします。

WebLogic ServerでURL書換えを有効にするには、WebLogic Server固有のデプロイメント記述子weblogic.xmlのsession-descriptor要素でURL-rewriting-enabledパラメータをtrueに設定します。「session-descriptor」を参照してください。

URL書換えをサポートするために、コードでURLを適切に処理するには、以下のガイドラインに従います。

- 次に示すように、URLを出力ストリームに直接書き出すことは避けます。

out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");

かわりに、HttpServletResponse.encodeURL()メソッドを使用します。例:

out.println("<a href=\""
+ response.encodeURL("myshop/catalog.jsp")
+ "\">catalog</a>");

- encodeURL()メソッドを呼び出すと、URLを書き換える必要があるかどうかが調べられます。必要である場合、URLにセッションIDを組み込むことによって書換えを行います。

- WebLogic Serverへのレスポンスとして返されるURLに加えて、リダイレクトを送信するURLをエンコードします。例:

if (session.isNew())
response.sendRedirect(response.encodeRedirectUrl(welcomeURL));

WebLogic Serverはセッションが新しいときには、ブラウザがCookieを受け入れる場合でもURL書換えを使用します。これは、セッションの最初ではサーバーはブラウザがCookieを受け入れるかどうかを判断できないからです。

サーブレットは、HttpServletRequest.isRequestedSessionIdFromCookie()メソッドから返されるブール値をチェックすることによって、所定のセッションがCookieから返されたかを確認できます。アプリケーションは適切に応答するか、WebLogic ServerによるURL書換えに依存します。

注意:

CISCO Local Directorロード・バランサでは、疑問符"?"がURLの書換えのデリミタとして想定されています。WebLogic ServerのURLの書換えメカニズムはデリミタとしてセミコロン";"を使用するため、WebLogic Serverの書換えとこのロード・バランサの間には互換性がありません。

URL書換えとWireless Access Protocol (WAP)

WAPアプリケーションを作成する場合、WAPプロトコルはCookieをサポートしていないため、URLを書き換える必要があります。また、一部のWAPデバイスでは、URLの長さが128文字(パラメータも含む)に制限されます。これにより、URL書換えによって転送できるデータ・サイズが制限されます。パラメータ用に使えるスペースを増やすには、WebLogic Server固有のデプロイメント記述子weblogic.xmlのsession-descriptor要素でid-lengthパラメータを使用してバイト数を指定し、WebLogic Serverによってランダムに生成されるセッションIDのサイズを制限できます。「session-descriptor」を参照してください。

最小値は8バイト、デフォルト値は52バイト、最大値はInteger.MAX_VALUEです。

セッションの永続化

WebLogic Serverは、セッション・データを永続ストレージに記録するように設定できます。セッション永続性を使用すると、以下の特性を利用できます。

- フェイルオーバーのよさ。サーバーに障害が発生してもセッションが保存されるためです。

- ロード・バランシングのよさ。どのサーバーでも、セッションがいくつあってもそのリクエストを処理し、キャッシュを使用して、パフォーマンスを最適化できるためです。詳細については、「セッションの永続性の構成」でcache-sizeプロパティを参照してください。

- セッションを、クラスタリングされたWebLogic Server間で共有できます。WebLogicクラスタではセッション永続性は必要条件ではなくなりました。そのかわりに、状態のインメモリー・レプリケーションを使用できます。詳細は、『Oracle WebLogic Serverクラスタの使用』を参照してください。

- 顧客が最高品質のサーブレット・セッション永続性を求めている場合は、JDBCベースの永続性が最適。セッション永続性はある程度犠牲にしても、パフォーマンスを大幅に高めたい顧客の場合には、インメモリー・レプリケーションが適切な選択です。JDBCベースの永続性は、インメモリー・レプリケーションよりも著しく低速です。サーブレット・セッションに対して、インメモリー・レプリケーションがJDBCベースの永続性よりも8倍高いパフォーマンスを提供したケースもあります。

- どの種類のJavaオブジェクトでもセッションに入れることができますが、ファイル、JDBC、およびインメモリー・レプリケーションに関しては、java.io.Serializableであるオブジェクトのみがセッションに格納されます。詳細は、「セッションの永続性の構成」を参照してください。

セッション使用時に避けるべき状況

セッション永続性を、セッション間の長期データを格納する目的には使わないでください。つまり、後日クライアントがサイトに戻ったときに、アクティブなままのセッションがあっても、それに依存してはいけません。むしろアプリケーションでは、長期にわたる情報や重要な情報は、データベースの中に記録すべきです。

セッションはCookieのコンビニエンス・ラッパーではありません。セッションには長期間であろうと一定期間であろうと、クライアント・データを格納しようとしてはいけません。それよりも、アプリケーションのほうでCookieをブラウザ上に作成し設定すべきです。例として、Cookieが長期間存続できる自動ログイン機能、Cookieが短期間で失効する自動ログアウト機能などがあります。この場合、HTTPセッションを使用しないでください。かわりに、アプリケーション固有のロジックを記述します。

シリアライズ可能な属性値を使用する

永続セッションを使用する場合、セッションに追加するすべての属性値オブジェクトはjava.io.Serializableを実装する必要があります。

独自のシリアライズ可能なクラスを永続セッションに加える場合は、クラスの各インスタンス変数もシリアライズ可能になっているかに注意してください。そうでない場合は、それをtransientとして宣言できます。一時的とするべきインスタンス変数の一般的な例としては、HttpSessionオブジェクトが挙げられます。(「セッションの永続化」の、セッションにおけるシリアライズされたオブジェクトの使用に関する注意を参照してください。)

HttpServletRequest属性、ServletContext属性、およびHttpSession属性は、WebLogic ServerインスタンスがWebアプリケーション・クラスローダーで変更を検出するとシリアライズされます。クラスローダーは、Webアプリケーションが再デプロイされた場合、サーブレットで動的な変更があった場合、またはWebアプリケーション間で転送またはインクルードがあった場合に変更されます。

サーブレットの動的な変更時に属性がシリアライズされないようにするには、weblogic.xmlでservlet-reload-check-secsを無効にします。Webアプリケーション間のディスパッチやWebアプリケーションの再デプロイメントの場合、属性のシリアライゼーションを回避する方法はありません。「servlet-reload-check-secs」を参照してください。

セッションの永続性の構成

永続セッションの設定の詳細は、「セッションの永続性の構成」を参照してください。

インメモリー・サーブレット・セッションに対する最大の制限の構成

新しいセッションが作成され続けているのに、インメモリー・サーブレット・セッションの使用を構成することができなければ、サーバーはやがて、メモリー不足をスローします。これを回避するため、WebLogic Serverでは作成されるセッション数に対して、構成可能な制限を設けています。この数を超えると、新しいセッションの作成が試行されるたびに、weblogic.servlet.SessionCreationExceptionが発生します。この機能は、レプリケートされたインメモリー・セッションと、レプリケートされないインメモリー・セッションの双方に適用されます。

制限されたインメモリー・サーブレット・セッションの使用を構成するには、weblogic.xmlデプロイメント記述子のmax-in-memory-sessions要素で、制限を設定します。「session-descriptor」を参照してください。

セッション・メモリー過負荷保護の有効化

メモリーが過負荷になると、すべてのgetSession(true)の試行に対して、weblogic.servlet.SessionCreationException (RuntimeException)が発生します。サーブレット開発者は、次のようにしてこの例外に対処します。

- 例外発生時に、ユーザーに状況を説明する適切なエラー・メッセージを戻します。

- Java EE標準のWebアプリケーション・デプロイメント記述子web.xmlで、weblogic.servlet.SessionCreationExceptionをエラー・ページにマップします。

デフォルトでは、メモリー過負荷保護は無効になっています。これはドメイン・レベルのフラグで有効化できます。

weblogic.management.configuration.WebAppContainerMBean.OverloadProtectionEnabled

11 アプリケーション・イベントとイベント・リスナー・クラス

次の項では、アプリケーション・イベントとイベント・リスナー・クラスについて説明します。

- アプリケーション・イベント・リスナー・クラスの概要

- サーブレット・コンテキスト・イベント

- HTTPセッション・イベント

- サーブレット・リクエスト・イベント

- イベント・リスナー・クラスの構成

- イベント・リスナー・クラスの作成

- イベント・リスナー・クラスのテンプレート

- その他の情報源

アプリケーション・イベント・リスナー・クラスの概要

アプリケーション・イベントとは、サーブレット・コンテキストの状態の変更(各Webアプリケーションは独自のサーブレット・コンテキストを使用します)、またはHTTPセッション・オブジェクトの状態の変更を通知するものです。これらの状態の変更に応答するイベント・リスナー・クラスを作成して、Webアプリケーションでそれらを構成およびデプロイします。サーブレット・コンテナはイベント・リスナー・クラスになんらかの処理を実行させるイベントを生成します。つまり、サーブレット・コンテナはイベント・リスナー・クラスのメソッドを呼び出します。

この処理の概要は次のとおりです。

1. ユーザーが、いずれかのリスナー・インタフェースを実装するイベント・リスナー・クラスを作成します。

2. この実装がデプロイメント記述子に登録されます。

3. デプロイメント時、サーブレット・コンテナはイベント・リスナー・クラスのインスタンスを作成します。(このために、パブリック・コンストラクタが存在している必要があります。「イベント・リスナー・クラスの作成」を参照してください。)

4. 実行時、サーブレット・コンテナはリスナー・クラスのインスタンスを呼び出します。

サーブレット・コンテキスト・イベントの場合、イベント・リスナー・クラスは、Webアプリケーションがデプロイされるときやアンデプロイされるとき(またはWebLogic Serverが停止するとき)、および、属性が追加、削除、置換されるときに、通知を受け取ることができます。

HTTPセッション・イベントの場合、イベント・リスナー・クラスは、HTTPセッションがアクティブ化されるかパッシブ化されようとしているとき、および、HTTPセッション属性が追加、削除、置換されるときに、通知を受け取ることができます。

Webアプリケーション・イベント・リスナー・クラスは次の目的で使用します。

- Webアプリケーションがデプロイされるときや停止されるときにデータベース接続を管理する

- 標準カウンタ・ユーティリティを作成する

- HTTPセッションとその属性の状態をモニターします

サーブレット・コンテキスト・イベント

次の表は、サーブレット・コンテキスト・イベントのタイプ、イベント・リスナー・クラスが個々のサーブレット・コンテキスト・イベントに応答するために実装すべきインタフェース、およびサーブレット・コンテキスト・イベントが発生したときに起動されるメソッドを示しています。

表11-1 サーブレット・コンテキスト・イベント

イベントのタイプ

インタフェース

メソッド

サーブレット・コンテキストが作成されます。

javax.servlet.ServletContextListener

contextInitialized()

サーブレット・コンテキストが停止されようとしています。

javax.servlet.ServletContextListener

contextDestroyed()

属性が追加されます。

javax.servlet.
ServletContextAttributesListener

attributeAdded()

属性が削除されます。

javax.servlet.
ServletContextAttributesListener

attributeRemoved()

属性が置き換えられます。

javax.servlet.
ServletContextAttributesListener

attributeReplaced()

HTTPセッション・イベント

次の表は、イベント・リスナー・クラスがHTTPセッション・イベントに応答するために実装すべきHTTPセッション・イベントのタイプ、およびHTTPセッション・イベントが発生したときに起動されるメソッドを示しています。

表11-2 HTTPセッション・イベント

イベントのタイプ

インタフェース

メソッド

HTTPセッションがアクティブ化されます。

javax.servlet.http.HttpSessionListener

sessionCreated()

HTTPセッションがパッシブ化されようとしています。

javax.servlet.http.HttpSessionListener

sessionDestroyed()

属性が追加されます。

javax.servlet.http.HttpSessionAttributeListener

attributeAdded()

属性が削除されます。

javax.servlet.http.HttpSessionAttributeListener

attributeRemoved()

属性が置き換えられます。

javax.servlet.http.HttpSessionAttributeListener

attributeReplaced()

注意:

Servlet 2.5仕様にもjavax.servlet.http.HttpSessionBindingListenerインタフェースとjavax.servlet.http.HttpSessionActivationListenerインタフェースが含まれています。これらのインタフェースは、セッション属性として格納されるオブジェクトによって実装され、web.xmlへのイベント・リスナーの登録を必要としません。

サーブレット・リクエスト・イベント

次の表は、サーブレット・リクエスト・イベントのタイプ、イベント・リスナー・クラスがサーブレット・リクエストのライフサイクルに渡って状態を管理するために実装する必要があるインタフェース、およびリクエスト・イベントの発生時に呼び出されるメソッドについて示しています。

表11-3 サーブレット・リクエスト・イベント

イベントのタイプ

インタフェース

メソッド

リクエストがWebアプリケーションのスコープ外に移ろうとしています。

javax.servlet.ServletRequestListener

requestDestroyed()

リクエストがWebアプリケーションのスコープ内に移ろうとしています。

javax.servlet.ServletRequestListener

requestInitialized()

サーブレット・リクエストに新しく属性が追加されたという通知。属性の追加後に呼び出されます。

javax.servlet.ServletRequestAttributeListener

attributeAdded()

サーブレット・リクエストから新しく属性が削除されたという通知。属性の削除後に呼び出されます。

javax.servlet.ServletRequestAttributeListener

attributeRemoved()

サーブレット・リクエストで属性が置き換えられたという通知。属性の置換後に呼び出されます。

javax.servlet.ServletRequestAttributeListener

attributeReplaced()

イベント・リスナー・クラスの構成

イベント・リスナー・クラスを構成するには:

1. イベント・リスナー・クラスを作成するWebアプリケーションのweb.xmlデプロイメント記述子をテキスト・エディタで開きます。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。

2. web.xmlデプロイメント記述子のlistener要素を使用してイベント宣言を追加します。イベント宣言は、イベントが発生するときに起動されるイベント・リスナー・クラスを定義します。listener要素は、filter要素とfilter-mapping要素のすぐ後ろで、servlet要素のすぐ前に指定します。それぞれのイベント・タイプに複数のイベント・リスナー・クラスを指定できます。WebLogic Serverは、デプロイメント記述子に記述されている順にイベント・リスナー・クラスを起動します(停止イベントのみは、逆順で起動されます)。例:

<listener>
<listener-class>myApp.MyContextListenerClass</listener-class>
</listener>
<listener>
<listener-class>myApp.MySessionAttributeListenerClass</listener-class>
</listener>

3. イベント・リスナー・クラスを作成し、デプロイします。詳細は、「イベント・リスナー・クラスの作成」の項を参照してください。

イベント・リスナー・クラスの作成

イベント・リスナー・クラスを作成するには:

1. クラスが応答するイベントのタイプに対して適切なインタフェースを実装する新しいイベント・リスナー・クラスを作成します。これらのインタフェースのリストについては、「サーブレット・コンテキスト・イベント」または「HTTPセッション・イベント」を参照してください。作業の開始に利用できるサンプルのテンプレートについては、「イベント・リスナー・クラスのテンプレート」を参照してください。

2. 引数をとらないパブリック・コンストラクタを作成します。例:

public class MyListener {
// public constructor
public MyListener() { /* ... */ }
}

3. インタフェースの必須メソッドを実装します。詳細は、http://download.oracle.com/javaee/5/api/のJava EE 5 APIリファレンス(Javadoc)を参照してください。

4. コンパイル済みのイベント・リスナー・クラスをWebアプリケーションのWEB-INF/classesディレクトリにコピーするか、または、それらをJARファイルにパッケージ化してからそのJARファイルをWebアプリケーションのWEB-INF/libディレクトリにコピーします。
次の便利なクラスは、イベント・リスナー・クラスのメソッドに渡されます。

- javax.servlet.http.HttpSessionEvent - HTTPセッション・オブジェクトへのアクセスを提供します

- javax.servlet.ServletContextEvent - サーブレット・コンテキスト・オブジェクトへのアクセスを提供します。

- javax.servlet.ServletContextAttributeEvent - サーブレット・コンテキストとその属性へのアクセスを提供します

- javax.servlet.http.HttpSessionBindingEvent - HTTPセッションとその属性へのアクセスを提供します

イベント・リスナー・クラスのテンプレート

次の例は、イベント・リスナー・クラスの基本的なテンプレートです。

サーブレット・コンテキスト・イベント・リスナー・クラスの例

package myApp;
import javax.servlet.http.*;
public final class MyContextListenerClass implements
ServletContextListener {
public void contextInitialized(ServletContextEvent event) {

/* This method is called prior to the servlet context being
initialized (when the Web application is deployed).
You can initialize servlet context related data here.
*/

}
public void contextDestroyed(ServletContextEvent event) {

/* This method is invoked when the Servlet Context
(the Web application) is undeployed or
WebLogic Server shuts down.
*/

}
}

HTTPセッション属性イベント・リスナー・クラスの例

package myApp;
import javax.servlet.*;

public final class MySessionAttributeListenerClass implements
HttpSessionAttributeListener {

public void attributeAdded(HttpSessionBindingEvent sbe) {
/* This method is called when an attribute
is added to a session.
*/
}
public void attributeRemoved(HttpSessionBindingEvent sbe) {
/* This method is called when an attribute
is removed from a session.
*/
}
public void attributeReplaced(HttpSessionBindingEvent sbe) {
/* This method is invoked when an attibute
is replaced in a session.
*/
}
}

その他の情報源

- Servlet 2.5仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html)

- Java EE 5 APIリファレンス(Javadoc) (http://download.oracle.com/javaee/5/api/)

- Java EE 5チュートリアル(http://download.oracle.com/javaee/5/tutorial/doc/)

12 HTTPパブリッシュ/サブスクライブ・サーバーの使用

次の項では、WebLogic Serverに含まれているHTTPパブリッシュ/サブスクライブ・サーバーの概要と、Webアプリケーションにおけるこのサーバーの使用方法を示します。

- HTTPパブリッシュ/サブスクライブ・サーバーの概要

- HTTPパブリッシュ/サブスクライブ・サーバーの使用例

- HTTPパブリッシュ/サブスクライブ・サーバーの使用: 標準の手順

- Pub-Subサーバーおよびチャネルの実行時情報の取得

- セキュリティの有効化

- 高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

- 高度なトピック: 物理ストレージへのメッセージの永続化

HTTPパブリッシュ/サブスクライブ・サーバーの概要

HTTPパブリッシュ/サブスクライブ・サーバー(pub-subサーバーともいう)は、WebクライアントがHTTPで非同期メッセージを使用してチャネルのサブスクライブおよびメッセージのパブリッシュを行うためのメカニズムです。

標準のWebアプリケーションの単純なリクエスト/レスポンス機能では、クライアントがすべての通信を開始する必要がありますが、この場合、サーバーは明示的なリクエストを受け取った場合に、更新されたデータをクライアントへプッシュすることしかできません。このメカニズムは、クライアントがリクエストした場合にのみサーバーからのデータが必要となるショッピング・カートなどの従来のアプリケーションには適していますが、クライアントが明示的にリクエストしていない場合でもサーバーがデータを送信する必要のあるチャット・ルームやオークションの更新などの動的かつリアルタイムなアプリケーションには不適切です。クライアントは従来のHTTPプル手法を使用して最新データを定期的にチェックおよび取得することができますが、この手法にはスケーラビリティがなく、チェックの重複によりネットワーク・トラフィックの増加につながります。HTTPパブリッシュ/サブスクライブ・サーバーは、クライアントによるチャネル(JMSでのトピックに相当)のサブスクライブとメッセージ(利用可能な場合)の受信を可能にすることにより、この問題を解決しています。

pub-subサーバーはBayeuxプロトコルに基づきます(http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.htmlを参照)。Bayeuxプロトコルには、クライアントとサーバーがHTTPを介して非同期メッセージで通信するための規約が定義されています。これによって、クライアントは、イベントのソースまたは指定されている宛先であるチャネルに対して登録およびサブスクライブすることができます。次に、登録されたクライアントまたはpub-subサーバー自体がこれらのチャネルへメッセージをパブリッシュすると、サブスクライブしているすべてのクライアントがそのメッセージを受信します。

pub-subサーバーはBayeuxプロトコルを理解するすべてのクライアントと通信することができます。pub-subサーバーは、クライアントの識別、信頼のネゴシエーション、Bayeuxメッセージの交換、そして最も重要なことですが、サブスクライブ済みクライアントへのイベント・メッセージのパブリッシュを担当します。

次の図は、WebLogic Serverに含まれているpub-subサーバーの基本的なアーキテクチャについて説明しています。

図12-1 WebLogic ServerのHTTPパブリッシュ/サブスクライブ・サーバー

Pub-Subサーバーの仕組み

Webアプリケーションとpub-subサーバーは1対1の関係にあります。つまり、各Webアプリケーションは、1つの一意のpub-subサーバーへアクセスします。各pub-subサーバーには独自のチャネル・リストがあります。これは、同じエンタープライズ・アプリケーション内の異なるWebアプリケーションで同じ名前のチャネルが使用される場合があることを意味します。Webアプリケーションはコンテキスト・オブジェクトを使用して、関連付けられているpub-subサーバーへのハンドルを取得します。

pub-subサーバー自体はJava EEライブラリとして実装されます。このライブラリは、関連付けられているWebアプリケーションがweblogic.xmlデプロイメント記述子で参照します。

pub-subサーバーは独自のデプロイメント記述子weblogic-pubsub.xmlを持ちます。この記述子は、他のWebアプリケーション記述子と同じディレクトリ(WEB-INF)に格納されます。開発者はこの記述子を使用して、pub-subサーバーの初期チャネルの構成、トランスポートおよびメッセージ・ハンドラの指定、およびユーザーの認証と認可の設定を行います。

Webアプリケーション開発者は必要に応じて、サーバー側のpub-sub APIをサーブレットやJavaクラスで使用し、pub-subサーバーのコンテキストの取得、チャネルの管理、およびクライアントとの間で送受信されるメッセージの管理を行うことができます。しかし、サーバー側のpub-sub APIは使用する必要はありません。たとえば、開発者はpub-subサーバーを使用して、Webアプリケーションにチャット機能を実装することができます。通常のチャット・アプリケーションでは、サーバー側で別途コーディングしなくても、クライアント自体ですべてのサブスクライブ/パブリッシュ・タスクを実行することができます。しかし、クライアントから受信するメッセージのモニター、収集、解釈などの追加手順をpub-subサーバーで実行する必要がある場合、開発者はサーバー側のpub-subサーバーAPIを使用して、こうした機能をプログラミングする必要があります。

Web 2.0 Ajaxクライアントがpub-subサーバーと通信するには、BayeuxプロトコルをサポートするJavaScriptライブラリがクライアント側で必要となります。pub-subサーバーでは、配布キットのサンプルの一部としてDojo JavaScriptライブラリ実装が提供されます。このDojo JavaScriptライブラリでは4つの異なるトランスポート手段が提供され、そのうちのlong-pollingおよびcallback-pollingがWebLogic pub-subサーバーでサポートされています。

JMSを使用してpub-subサーバーをクラスタリング環境で実行すると、クラスタの複数のノード間でメッセージを共有することができます。この場合、pub-subサーバーは原則的にメッセージ処理をJMSプロバイダに委任します。

メッセージは、ファイル・システムまたはデータベースなどの物理ストレージに永続化されるよう指定することもできます。メッセージはデフォルトでは永続化されません。

次の項では、pub-subサーバーのその他の情報について説明します。

- チャネル

- メッセージ配信と配信順序の保証

チャネル

チャネルは、クライアントがサブスクライブおよびメッセージをパブリッシュする対象の、指定された宛先です。プログラマは、weblogic-pubsub.xmlデプロイメント記述子ファイルを作成し、そのファイルを標準のweb.xmlおよびweblogic.xmlファイルと一緒にWebアプリケーションのWEB-INFディレクトリ内にパッケージ化することによって、初期チャネル、チャネル・マッピング、およびセキュリティを定義します。プログラマは必要に応じてpub-subサーバーAPIをサーブレットで使用し、チャネルを動的に検出、作成、および破棄することもできます。

クライアント側でチャネルを作成および破棄できるようにするかどうかは、プログラマが決定します。つまり、クライアントの認可に基づいてcreateおよびdestroyメソッドの使用を制約するようプログラミングしなければならない場合があります。認可されていないクライアントがチャネルを作成または破棄しようとすると、エラー・メッセージが生成されます。

pub-subサーバーが既存のチャネルを破棄すると、そのチャネルをサブスクライブ済みのすべてのクライアントと、そのチャネルのすべてのサブチャネルが自動的にアンサブスクライブされます。クライアントは、pub-subサーバーによるチャネルの破棄によってアンサブスクライブされると、pub-subサーバーから切断レスポンス・メッセージを受け取るため、その他のチャネルへの再接続および再サブスクライブを試行することができます。

チャネルのネームスペースは階層的です。つまり、*および**などのワイルドカードを使用したチャネル取得パターンによって、複数のチャネルをまとめてサブスクリプション対象として指定できます。クライアントは、ワイルドカード・パターンによってサブスクライブした後に作成されたすべてのチャネルに自動的に登録されます。

メッセージ配信と配信順序の保証

クライアントとpub-subサーバー間では、メッセージの配信順序は保証されません。つまり、pub-subサーバーがmessage1、message2の順にパブリッシュした場合、クライアントはその順番でメッセージを受け取る場合もあれば、その逆の順序で受け取る場合もあります。

Web上では、クライアントは本質的に疎結合であるため、pub-subサーバーがメッセージをパブリッシュしたときにサブスクライバがアクティブでないか接続されていない可能性があります。この場合のメッセージの配信動作には、以下のルールが適用されます。

- クライアントにアクセスできない場合、pub-subサーバーがパブリッシュしたメッセージはそのクライアントに配信されません。

- クライアントは、再接続時に新たにパブリッシュされたメッセージを引き続き受信します。

- パブリッシュ済みメッセージを回復するには、pub-subサーバーを永続メッセージ用に構成し、チャネルを永続チャネルとして構成する必要があります。

HTTPパブリッシュ/サブスクライブ・サーバーの使用例

このトピックでは、簡単な例を使用してHTTP pub-subサーバーを使用する際の基本的な機能および必要となる作業について説明します。サンプルのWebアプリケーションに含まれる構成要素は以下のもののみです。

- pub-sub Java EEライブラリを構成するためのweb.xmlデプロイメント記述子。

- pub-subサーバー自体を構成するためのweblogic-pubsub.xmlデプロイメント記述子。

- ユーザーによるサブスクライブおよびメッセージのパブリッシュを可能にするHTMLファイル。このHTMLファイルでは、プログラミング・モデルとしてDOJOクライアントJavaScriptライブラリを使用します。

このサンプルでは、pub-sub APIによるサーバー側のプログラミング手法は使われていません。

WebLogic Server配布キットには、より複雑なサンプルが含まれています。このサンプルでは、株取引に基づく実際のシナリオが表され、サーバーとクライアントの両方の構成要素内でpub-sub APIが幅広く活用されています。このサンプルではクライアント側のプログラミング・フレームワークとしてDojoが使用され、各自のテスト用にDojo JavaScriptライブラリの一部が提供されます。また、pub-subサーバーおよびクライアントへセキュリティを追加する方法も示されています。このサンプルは次のディレクトリにあります。

WL_HOME/samples/server/examples/src/examples/webapp/pubsub/stock

WL_HOMEは、メインのWebLogic Serverのインストール・ディレクトリ(/oraclehome/wlserver_10.3など)です。

HTTPパブリッシュ/サブスクライブ・サーバーの使用: 標準の手順

次に、HTTPパブリッシュ/サブスクライブ・サーバーを使用する高度な手順について説明します。

注意:

この手順では、基本のWebアプリケーション、そのweb.xmlおよびweblogic.xmlデプロイメント記述子ファイル、JSP、サーブレットをすでに作成しているものとします。Webアプリケーションの作成方法の詳細は、第3章「Webアプリケーションの作成と構成」を参照してください。

1. WEB-INFディレクトリにあるWebアプリケーションのweblogic.xmlデプロイメント記述子で、pub-subサーバーがバンドルされる共有Java EEライブラリ(pubsub)への参照を追加します(コード内の太字を参照)。

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<library-ref>
<library-name>pubsub</library-name>
<specification-version>1.0</specification-version>
</library-ref>
</weblogic-web-app>

<library-refのその他の子要素および共有Java EEライブラリに関する詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

2. weblogic-pubsub.xmlファイルを作成し、初期チャネルの構成、トランスポートおよびメッセージ・ハンドラの指定、ユーザーの認証および認可の設定を行います。「weblogic-pubsub.xmlファイルの作成」を参照してください。

3. pub-subサーバーによるチャネルへのメッセージのパブリッシュ、クライアントからのメッセージのフィルタ処理、またはチャネルの動的な作成あるいは破棄が必要な場合、サーブレットなどのWebアプリケーション・コンポーネントにJavaコードを追加します。この手順は省略可能です。「サーバー側のPub-Sub APIによるプログラミング」を参照してください。

4. クライアントから受け取るメッセージを事前処理する必要がある場合、メッセージ・フィルタ・チェーンをプログラミングおよび構成します。「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。

5. HTMLファイル、JSPなど、ブラウザ・クライアントを更新し、ユーザーがチャネルをサブスクライブし、メッセージを送受信できるようにします。「Pub-Subサーバーと通信するためのブラウザ・クライアントの更新」を参照してください。

6. 更新済みの新しいデプロイメント記述子ファイルとブラウザ・クライアントを使用してWebアプリケーションを再アセンブルします。pub-subサーバー・コードを追加した場合は、サーブレットを再コンパイルします。
新しいweblogic-pubsub.xmlデプロイメント記述子を、web.xmlおよびweblogic.xmlファイルが格納されているWebアプリケーションの同じWEB-INFディレクトリに配置します。

Webアプリケーションのアセンブル方法に関する全般的な情報の詳細は、第3章「Webアプリケーションの作成と構成」を参照してください。

7. まだ実行していない場合、pub-subサーバーがバンドルされる共有Java EEライブラリWARファイルをデプロイします。この手順は、pub-subサーバーを使用するWebアプリケーションを再デプロイする前に実行しますが、実行するのはWebLogic Server全体に対して1回のみです。
pub-sub共有Java EEライブラリWARファイルpubsub-1.0.warは、次のディレクトリにあります。

WL_HOME/common/deployable-libraries

WL_HOMEは、メインのWebLogic Serverのインストール・ディレクトリ(/oraclehome/wlserver_10.3など)です。

管理コンソールまたはweblogic.Deployerコマンド・ライン・ツールのいずれかを使用することができます。管理コンソールの使用手順については「Java EEライブラリのインストール」を、weblogic.Deployerの使用方法の詳細は「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

8. 管理コンソールまたはweblogic.Deployerコマンド・ライン・ツールを使用して、更新したWebアプリケーションを再デプロイします。
管理コンソールの使用手順については「Webアプリケーションのインストール」を、weblogic.Deployerの使用方法の詳細は「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。

この時点で、ブラウザ・クライアントを使用してweblogic-pubsub.xmlファイルで構成されているチャネルをサブスクライブし、メッセージを送受信することができます。

pub-subアプリケーションのプログラミング後に、そのアプリケーションの実行時情報をモニタリングする必要がある場合があります。詳細は、「Pub-Subサーバーおよびチャネルの実行時情報の取得」を参照してください。

実装可能なpub-subサーバーのより高度な機能については、次の項を参照してください。

- セキュリティの有効化

- 高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

- 高度なトピック: 物理ストレージへのメッセージの永続化

weblogic-pubsub.xmlファイルの作成

weblogic-pubsub.xmlデプロイメント記述子は、pub-subサーバーの構成に使用するXMLファイルです。特に、初期チャネル、pub-subサーバーの構成プロパティ、およびチャネルをサブスクライブするクライアントのセキュリティ仕様を指定します。この情報の一部は、サーバー側のAPIを使用してpub-subサーバーによって実行時にリフレッシュできます。

デプロイメント記述子のルート要素は<wlps:weblogic-pubsub>であり、wlpsネームスペースはhttp://xmlns.oracle.com/weblogic/weblogic-pubsubです。

weblogic-pubsub.xmlファイルの要素の詳細については、このスキーマを参照してください。以下に、一般的に使用される要素の一部を示します。この節の最後に一般的なweblogic-pubsub.xmlファイルの例を示します。

- <wlps:server-config>: pub-subサーバーを構成します。この要素の子要素には以下の要素があります。

- <wlps:work-manager>: クライアントへメッセージを配信するワーク・マネージャの名前を指定します。

- <wlps:publish-without-connect-allowed>: pub-subサーバーに明示的に接続せずに、クライアントでメッセージをパブリッシュするかどうかを指定します。

- <wlps:supported-transport>: サポートされているトランスポート方法を指定します。現時点でサポートされているトランスポート方法はlong-pollingおよびcallback-pollingの2つです。

- <wlps:client-timeout-secs>: クライアントが接続/再接続メッセージを返信していない場合に、pub-subサーバーが接続を切断するまでの秒数を指定します。

- <wlps:channel>: 初期チャネルを定義および構成します。この要素の子要素には以下の要素があります。

- <wlps:channel-pattern>: サーブレットURLパターンの指定と同様の方法でチャネル・パターンを指定します(/foo/bar, /foo/bar/*、/foo/bar/**など)。

- <wlps:channel-persistence>: チャネルを永続化するかどうかを指定します。詳細は、「高度なトピック: 物理ストレージへのメッセージの永続化」を参照してください。

- <wlps:jms-handler-name>: チャネルで、デフォルトのハンドラではなく、JMSハンドラを使用するように指定します。詳細は、「高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート」を参照してください。

- <wlps:message-filter>: メッセージ・フィルタ・チェーンを構成します。詳細は、「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。

- <wlps:channel-constraints>: 特定のチャネルに対してどの操作をどのロールで実行できるかなど、チャネルのセキュリティを構成します。詳細は、「セキュリティの有効化」を参照してください。

- <wlps:jms-handler-mapping>: JMSハンドラを構成します。詳細は、「高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート」を参照してください。

次のサンプルweblogic-pubsub.xmlファイルでは、pub-subサーバーを使用するアプリケーションの簡単な構成を示します。詳細は、このサンプルの後の説明を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<wlps:weblogic-pubsub
xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub">
<wlps:server-config>
<wlps:publish-without-connect-allowed>true</wlps:publish-without-connect-allowed>
<wlps:supported-transport/>
<wlps:client-timeout-secs>100</wlps:client-timeout-secs>
<wlps:persistent-client-timeout-secs>400</wlps:persistent-client-timeout-secs>
<wlps:interval-millisecs>1000</wlps:interval-millisecs>
<wlps:multi-frame-interval-millisecs>2000</wlps:multi-frame-interval-millisecs>
</wlps:server-config>
<wlps:channel>
<wlps:channel-pattern>/chatrooms/**</wlps:channel-pattern>
</wlps:channel>
<wlps:channel-constraint>
<wlps:channel-resource-collection>
<wlps:channel-resource-name>all-permissions</wlps:channel-resource-name>
<wlps:description>Grant all permissions for everything by everyone</wlps:description>
<wlps:channel-pattern>/chatrooms/*</wlps:channel-pattern>
</wlps:channel-resource-collection>
</wlps:channel-constraint>
</wlps:weblogic-pubsub>

上記の例では:

- <wlps:server-config>要素で、pub-subサーバー自体を構成しています。特に、この要素では、クライアントがpub-subサーバーに明示的に接続せずにメッセージをパブリッシュできること、および、クライアントが再接続メッセージを送信していない期間が100秒を超えるとサーバーがクライアントの接続を切断することを指定しています。<wlps:persistent-client-timeout-secs>要素では、永続チャネルの場合に、クライアントの接続が切断されるまでの期間が最大400秒間であり、クライアントがこの間に再接続すると、それまでにパブリッシュされたメッセージを受信できることを指定しています。<wlps:interval-milliseconds>要素では、クライアントが/meta/connectチャネルへの以降のリクエストを最大で1000ミリ秒間遅延できることを指定しています。最後に、<wlps:multi-frame-interval-millisecs>要素では、マルチフレームの検出時に、クライアントが/meta/connectチャネルへの以降のリクエストを最大で2000ミリ秒間遅延できることを指定しています。

- <wlps:channel>要素で、ユーザーがサブスクライブ可能な1つの初期チャネルを構成しています。このチャネルはパターン/chatrooms/**によって識別されます。このパターンはチャネル階層の最上位を表しています。

- <wlps:channel-constraints>要素で、/chatrooms/**チャネルをどのように使用できるかに関するセキュリティ制約を指定しています。ここでは、すべてのチャネルに対するすべての操作に関して、すべてのユーザーにすべての許可が与えられています。

サーバー側のPub-Sub APIによるプログラミング

情報をモニターするため、またはサブスクライブ済みクライアントへパブリッシュされる前に受信データをインターセプトするために、pub-subサーバー自身がチャネルからメッセージを定期的に取得しなければならない場合があります。また、pub-subサーバーは、サブスクライブ済みのすべてのクライアントへ通知を行ったり、追加のサービスを提供するために、チャネルへ直接メッセージをパブリッシュしなければならない場合もあります。さらに、新しいチャネルを作成したり、既存のチャネルを破棄したりといった、チャネルのメンテナンスを行わなければならない場合もあります。

WebLogic Serverでは、これらのすべてのタスクを実行するために、com.bea.httppubsubパッケージでpub-sub APIを提供しています。pub-subプログラマは、pub-subアプリケーションを格納するWebアプリケーションのサーブレットまたはPOJO (プレーンな従来型Javaオブジェクト)でこのAPIを使用します。APIを使用したプログラミングは省略可能であり、pub-subサーバーがクライアント側で標準のパブリッシュ/サブスクライブ以外のタスクを実行しなければならない場合にのみ必要となります。

APIの主なクラスおよびインタフェースの概要

次に、pub-subサーバーAPIの主なインタフェースおよびクラスについて説明します。

- com.bea.httppubsub.PubSubServer —これはpub-subサーバーAPI.の最も重要なインタフェースです。これは、現在のWebアプリケーションに関連付けられているpub-subサーバーのインスタンスを表します。関連付けられているpub-subサーバーを取得するには、現在のサーブレットのコンテキスト・パスを利用します。プログラマはこのインタフェースを使用して、チャネルの管理、pub-subサーバーのコ構成、およびチャネルへのパブリッシュとサブスクライブに使用されるローカル・クライアントの作成を行うことができます。

- com.bea.httppubsub.LocalClient —プログラマはPubSubServerインタフェースを使用して現在のpub-subサーバーのインスタンスを作成したら、サーバー側のクライアント表現であるLocalClientを作成する必要があります。このクライアントは、pub-subサーバーに常に接続されます。プログラマはこのクライアントを使用して、チャネルへのパブリッシュおよびサブスクライブを実行できます。ブラウザ・ベースのクライアントなどのリモート・クライアントは、com.bea.httppubsub.Clientインタフェースによって表します。

- com.bea.httppubsub.ClientManager —新しいLocalClientを作成するためのインタフェースです。

- com.bea.httppubsub.Channel —チャネルとそのすべてのサブチャネルを表すインタフェースです。プログラマはこのインタフェースにより、チャネルおよびそのサブチャネルを現在サブスクライブしているクライアントの一覧の取得、チャネルへのメッセージのパブリッシュ、すべてのサブチャネルの一覧の取得、チャネルのサブスクライブまたはアンサブスクライブ、およびチャネルの破棄を実行することができます。

- com.bea.httppubsub.MessageFilter —クライアントがチャネルへパブリッシュするメッセージのインターセプトを行うメッセージ・フィルタを作成するためのインタフェースです。詳細は、「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。

- com.bea.httppubsub.DeliveredMessageListener —このインタフェースは、クライアント(リモート・クライアントまたはローカル・クライアント)がチャネルへメッセージをパブリッシュするたびに通知される、チャネルをリスニングするオブジェクトを作成するために使用します。

- com.bea.httppubsub.BayeuxMessage — pub-subサーバーとBayeuxクライアント間で交換されるメッセージを表すインタフェースです。

com.bea.httppubsubパッケージにはこの他にもサポート・クラス、インタフェース、列挙、例外があります。詳細は、JavadocのHTTP Pub-Sub APIを参照してください。

以降の節では、チャネルへのメッセージのパブリッシュやサブスクライブなど、最も一般的なサーバー側のタスクをpub-sub APIを使用して実行する方法について説明します。サンプル・コードは、WL_HOME/samples/server/examples/src/examples/webapp/pubsub/stock/src/stockWarにある配布キットのpub-subサーバー・サンプルのJavaソース・ファイルから抜粋しています。WL_HOMEは、メインのWebLogic Serverのインストール・ディレクトリ(/oraclehome/wlserver_10.3など)を示しています。

Pub-Subサーバー・インスタンスの取得とローカル・クライアントの作成

pub-subサーバーおよびそのチャネルでサーバー側のタスクを実行するには、pub-subサーバーを表すPubSubServerオブジェクトを最初にインスタンス化してから、pub-subに代わってチャネルを操作するために使用するローカル・クライアントを作成する必要があります。

例として次のサンプル・コードがあります。

import com.bea.httppubsub.FactoryFinder;
import com.bea.httppubsub.LocalClient;
import com.bea.httppubsub.PubSubSecurityException;
import com.bea.httppubsub.PubSubServer;
import com.bea.httppubsub.PubSubServerException;
import com.bea.httppubsub.PubSubServerFactory;
import org.json.JSONObject;
public class ApiBasedClient implements Client {
private PubSubServer pubSubServer;
private LocalClient localClient;
public ApiBasedClient(String serverName) throws PubSubServerException {
PubSubServerFactory pubSubServerFactory =
(PubSubServerFactory)FactoryFinder.getFactory(FactoryFinder.PUBSUBSERVER_FACTORY);
pubSubServer = pubSubServerFactory.lookupPubSubServer(serverName);
localClient = pubSubServer.getClientManager().createLocalClient();
}
...
}

FactoryFinderクラスはPubSubServerFactoryの実装を検索し、この実装がPubSubServerインスタンスの作成に使用されます。PubSubServerFactoryのlookupPubSubServer()メソッドは、メソッドが実行されるサーブレットのコンテキスト・パスに基づいて、PubSubServerインスタンスを返します。最後に、PubSubServerインスタンスのClientManagerのcreateLocalClient()メソッドがLocalClientオブジェクトを返します。このオブジェクトは、チャネルのサブスクライブおよびチャネルへのパブリッシュを行うためにpub-subサーバーが使用します。

チャネルへのメッセージのパブリッシュ

チャネルへメッセージをパブリッシュするには、次のサンプル・コードに示すように、PubSubServer.publishToChannel()メソッドを使用して、LocalClientオブジェクト、チャネル名、およびメッセージ・テキストを渡します。

public void publish(String channel, JSONObject data) throws IOException {
try {
pubSubServer.publishToChannel(localClient, channel, data.toString());
} catch (PubSubSecurityException e) {
throw new IOException(e);
}
}

この例のチャネル変数には、/my/channel/**などのチャネル名が含まれます。

publishToChannel()メソッドは非同期であり、すぐに戻り値を返します。つまり、サブスクライブ済みクライアントがメッセージを受信するまで待機しません。

チャネルのサブスクライブ

サーバー側からチャネルをサブスクライブするには2つの手順があります。

1. メッセージ・リスナーを作成し、LocalClientに登録します。

2. チャネルを明示的にサブスクライブします。

メッセージ・リスナーは、DeliveredMessageListenerインタフェースを実装するクラスです。このインタフェースでは単一のコールバック・メソッドonPublish()が定義されており、このメソッドは、ローカル・クライアントがメッセージを受信すると通知されます。このコールバック・メソッドは、ローカル・クライアントへの送信メッセージを表すDeliveredMessageEventインスタンスへ送信されます。

チャネルをサブスクライブするには、PubSubServer.subscribeToChannel()メソッドを使用して、LocalClientオブジェクトおよびチャネル名を渡します。

次のサンプル・コードでは、これらの両方の手順の例を示します。サンプル・コードの直後の説明を参照してください。

pubSubServer.subscribeToChannel(localClient, "/management/publisher");
localClient.registerMessageListener(new DeliveredMessageListener() {
private InWebPublisher publisher = new InWebPublisher(contextPath);
private boolean publishing = false;
public void onPublish(DeliveredMessageEvent event) {
Object payLoad = event.getMessage().getPayLoad();
if (payLoad instanceof String) {
String command = (String)payLoad;
if ("start".equals(command) && !publishing) {
publisher.startup();
publishing = true;
} else if ("halt".equals(command) && publishing) {
publisher.halt();
publishing = false;
}
}
}
});

上記の例では:

- pub-subサーバーは/management/publisherというチャネルをサブスクライブしています。

- メッセージ・リスナー・クラスは、LocalClient.registerMessageListener()メソッド呼出し内に直接実装されています。

メッセージ・フィルタ・チェーンの構成とプログラミング

pub-subサーバー・アプリケーション開発者は、1つまたは複数のメッセージ・フィルタをプログラミングし、チャネルに対してそれらのフィルタを構成して、クライアントから届くメッセージをインターセプトしたり、特定の方法でメッセージを変換または追加処理することができます。メッセージ・フィルタ・チェーンは、1つのチャネルに複数のフィルタがアタッチされることを意味します。つまり、最初のフィルタとして構成されているフィルタがメッセージを事前処理し、2番目のフィルタとして構成されているフィルタにそのメッセージを渡す、などのように処理されます。この機能は、サーブレット2.3仕様で導入されたフィルタに似ています。

メッセージ・フィルタは、さまざまな理由から役立ちます。まず、メッセージ・フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化できます。2つ目として、メッセージ・フィルタでは、クライアントからのメッセージをpub-subサーバーが取得してチャネルのサブスクライバに送信する前に事前処理するための容易かつ一貫性のある手段が提供されることです。メッセージを事前処理するのは、受信データの検証、モニター情報の収集、pub-subアプリケーション・ユーザーの追跡、キャッシングなどを行うためです。

メッセージ・フィルタ・チェーンを実装するには、主に次の2つの手順があります。

- メッセージ・フィルタ・クラスのプログラミング

- メッセージ・フィルタ・チェーンの構成

メッセージ・フィルタ・クラスのプログラミング

チェーンの各フィルタには、ユーザーがプログラミングした独自のフィルタ・クラスが含まれている必要があります。このフィルタ・クラスはcom.bea.httppubsub.MessageFilterインタフェースを実装する必要があります。MessageFilterインタフェースには単一のメソッドhandleMessage(EventMessage)があり、そのシグネチャは次のとおりです。

boolean handleMessage(EventMessage message);

com.bea.httppubsub.EventMessageインタフェースは、JSON (JavaScript Object Notation) (http://www.json.org/を参照)エンコード・オブジェクトであるBayeaxMessageを拡張します。JSONは、Bayeuxプロトコルで使用される軽量なデータ交換形式です。EventMessageインタフェースでは、getPayload()およびsetPayload()の2つのメソッドが定義されています。これらのメソッドは、受信メッセージへのアクセス、およびそのメッセージの処理を行うために使用します。

handleMessage()メッセージはboolean値を戻すため、プログラマは、チェーン内の任意のフィルタ・クラスでfalseを戻すことによって、メッセージ・フィルタ・チェーンにおける以降のすべてのプロセスに割込みをかけることができます。これによってフィルタ・プロセスが割り込まれるのみでなく、メッセージをチャネルのサブスクライバへ送信せずに、パブリッシュ元のクライアントへすばやく返信することができます。これは、プログラマにとって、受信メッセージに問題がないことを確認し、問題が検出された場合でも、そのメッセージがサブスクライバへパブリッシュされないようにすることができる優れた手段です。

以下に、MessageFilterインタフェースの簡単な実装例を示します。

package msgfilters;
public static class Filter1 implements MessageFilter {
public boolean handleMessage(EventMessage message) {
String msg = (String) message.getPayLoad();
message.setPayLoad("[" + msg.substring(1, msg.length()-1));
return true;
}
}

この例では、getPayload()メソッドが、入力されたmessageパラメータからStringメッセージを取得します。このmessageは、クライアントから直接届くか(Filter1がチェーン内で最初のフィルタとして構成されている場合)、別のフィルタ・クラスの結果です(Filter1がチェーン内で最初のフィルタではない場合)。setPayLoad()メソッドはメッセージをリセットしつつ、特定のデータ処理を実行しています。この例では、メッセージの最初の文字を[に置換しています。

メッセージ・フィルタ・チェーンの構成

メッセージ・フィルタは、pub-subサーバーのweblogic-pubsub.xmlデプロイメント記述子で構成します。

最初に、ルート<wlps:weblogic-pubsub>要素の<wlps:message-filter>子要素を使用してメッセージ・フィルタを宣言します。次に、チェーン内の各フィルタの<wlps:message-filter>要素を追加して特定のチャネルを構成します。<wlps:channel>要素でのフィルタの構成順が、各フィルタの実行順になります。

次に、weblogic-pubsub.xmlデプロイメント記述子でメッセージ・フィルタを構成する方法の例を示します(関連する情報のみ示しています)。サンプルの後の説明を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<wlps:weblogic-pubsub
xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub">
<wlps:server-config>
...
</wlps:server-config>
<wlps:message-filter>
<wlps:message-filter-name>filter1</wlps:message-filter-name>
<wlps:message-filter-class>msgfilters.Fiter1</wlps:message-filter-class>
</wlps:message-filter>
<wlps:message-filter>
<wlps:message-filter-name>filter2</wlps:message-filter-name>
<wlps:message-filter-class>msgfilters.Filter2</wlps:message-filter-class>
</wlps:message-filter>
<wlps:channel>
<wlps:channel-pattern>/firstchannel/*</wlps:channel-pattern>
<wlps:message-filter>filter1</wlps:message-filter>
</wlps:channel>
<wlps:channel>
<wlps:channel-pattern>/secondchannel/*</wlps:channel-pattern>
<wlps:message-filter>filter2</wlps:message-filter>
<wlps:message-filter>filter1</wlps:message-filter>
</wlps:channel>
</wlps:weblogic-pubsub>

この例では、<wlps:message-filter>要素を使用して2つのフィルタを宣言しています。filter1はmsgfilters.Filter1クラスで、filter2はmsgfilters.Filter2クラスで実装しています。

次に、/firstchannel/*のパターンのチャネルがfilter1で構成されています。これは、実行時に/firstchannelの直接のサブチャネルにパブリッシュされたすべてのメッセージがmsgfilters.Filter1クラスによって最初に処理されることを意味します。

/secondchannel/*のパターンのチャネルは、filter2およびfilter1の2つのフィルタで構成されています。これらの2つのフィルタの構成順が重要となります。実行時には、/secondchannelの直接のサブチャネルにパブリッシュされたすべてのメッセージがmsgfilters.Filter2クラスによってインターセプトおよび処理され、この処理結果はmsgfilters.Filter1に送信され、ここで独自の処理が行われた後、チャネルのサブスクライバに送信されます。

Pub-Subサーバーと通信するためのブラウザ・クライアントの更新

ブラウザまたはその他のWebベースのクライアントを更新してpub-subサーバーと通信するには、BayeuxプロトコルをサポートするJavaScriptライブラリを使用します。クライアント側のプログラミング・フレームワークには、Bayeuxプロトコルをサポートするものであれば任意のフレームワークを使用することができます。通常、このJavaScriptは、JSPやHTMLファイル、またはWebクライアントを実装するファイルに追加します。

この節では、クライアント側のプログラミング・フレームワークとしてDojoを使用してJSPを更新する例を示します。DojoはJavaScriptベースのツールキットであり、BayeuxプロトコルだけでなくAJAXもサポートします。WebLogic Serverでは、このツールキットを統合機能として提供していませんが、インストール済みのpub-subサンプルの一部としてライブラリのサブセットが含まれています。詳細については、「HTTPパブリッシュ/サブスクライブ・サーバーの使用例」を参照してください。

pub-subサーバーと通信するようにWebクライアントをプログラミングする際は、以下の主要な3つのタスクを実行する必要があります。

- Dojo cometd環境を初期化します。
次に、この手順を実行するための標準的な方法の例を示します。

dojo.io.cometd.init({}, "/context/cometd");

contextは、pub-subアプリケーションをホストするWebアプリケーションのコンテキスト・パスを指します。この初期化手順では、接続のトランスポート・タイプを決定するためにpub-subサーバーとのハンドシェークを作成します。クライアントは、このハンドシェークに成功すると、pub-subサーバーに接続します。

初期化文字列のcometd部分はpubsub Java EEライブラリのデフォルトのサーブレット・マッピングを明示的にオーバーライドしない限り必須です。このマッピングは、ライブラリ自身のweb.xmlファイルで定義されています。これを行う方法の詳細については、「pubsub Java EEライブラリのデフォルト・サーブレット・マッピングのオーバーライド」を参照してください。

- チャネルへメッセージをパブリッシュします。
メッセージは、単純な文字列メッセージやJSONメッセージの場合があります。次に、単純なメッセージのパブリッシュ方法の例を示します。

dojo.io.cometd.publish("/a/channel", "message content");

/a/channelは、メッセージのパブリッシュ先チャネルの名前を指し、2つ目のパラメータはメッセージのテキストです。次に、JSONメッセージのパブリッシュ方法の例を示します。

dojo.io.cometd.publish("/a/channel", {"data": "content"});

- この例の2つ目のパラメータには、任意のJSONオブジェクトを指定できます。

- チャネルをサブスクライブします。
チャネルを実際にサブスクライブするには、コールバックJavaScript関数を実装しておく必要があります。この関数には任意の名前を付けることができます。この関数は、チャネルをサブスクライブする際に後で参照します。次に、onUpdateというJavaScript関数を実装する方法の例を示します。

function onUpdate(message) {
if (!message.data) {
alert("bad message format "+message);
return;
}
// fetch the data published by other clients
var data = message.data;
}

チャネルを実際にサブスクライブするには、次のJavaScriptを使用します。

dojo.io.cometd.subscribe("/a/channel", null, "onUpdate");

/a/channelはサブスクライブ対象チャネルを指し、onUpdateは定義済みのコールバックJavaScript関数の名前です。

この項では、Dojoツールキットを使用してWebベースのクライアントを更新し、WebLogic pub-subサーバーと通信する方法に関する最小限の情報のみ提供しています。詳細は、http://www.dojotoolkit.org/documentationを参照してください。

pubsub Java EEライブラリのデフォルト・サーブレット・マッピングのオーバーライド

pubsub Java EEライブラリのweb.xmlでは、次に示すように、pub-subサーバーを実装する、PubSubServletと呼ばれる内部サーブレットが定義されています。

<web-app>
<servlet>
<servlet-name>PubSubServlet</servlet-name>
<servlet-class>com.bea.httppubsub.servlet.ControllerServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>PubSubServlet</servlet-name>
<url-pattern>/cometd/*</url-pattern>
</servlet-mapping>
</web-app>

太字のコードで示すように、PubSubServletのURLパターンは/cometd/*です。これが、pub-subサーバーと通信するWebクライアントを初期化する際に/mywebapp/cometdなどの文字列をデフォルトで使用しなければならない理由です。

このデフォルトURLパターンをオーバーライドするには、次のようなコードでWebアプリケーションのweb.xmlファイルを更新します。

<servlet-mapping>
<servlet-name>PubSubServlet</servlet-name>
<url-pattern>/web2/*</url-pattern>
</servlet-mapping>

これによって、Dojoを使用してWebクライアントを初期化する際に、cometdではなく、この新しいURLパターンを指定することができます。

dojo.io.cometd.init({}, "/context/web2");

Pub-Subサーバーおよびチャネルの実行時情報の取得

pub-subサーバーは、すべての実行時監視情報をJava Management Extensions (JMX) MBeanを使用して公開します。実行時に収集可能な情報の例として、登録済クライアントの詳細、チャネルのサブスクリプション数、メッセージ数などがあります。

pub-subサーバーでは、次の2種類の実行時MBeanを使用します。

- weblogic.management.runtime.WebPubSubRuntimeMBean — pub-subサーバー自体の実行時情報をカプセル化します。このMBeanを使用して取得可能なpub-subサーバーに関する情報の例として、関連付けられているWebアプリケーションのコンテキスト・ルートおよび構成済のチャネルのハンドルがあります。

- weblogic.management.runtime.ChannelRuntimeMBean — pub-subサーバーに対して構成されているチャネルに関する情報をカプセル化します。このMBeanを使用して取得可能なチャネルに関する情報の例として、このチャネルへパブリッシュされたメッセージの数、現在のサブスクライバ数、およびサブスクライバの一覧があります。

どちらのMBeanもWebLogic Server MBeanツリーに登録され、そのツリーを移動することによってアクセスできます。具体的には、WebPubSubRuntimeMBeanは現在のWebアプリケーションのWebAppComponentRuntimeMBeanの下に、すべてのChannelRuntimeMBeanはWebPubSubRuntimeMBeanの下に登録されます。

これらのMBeanの詳細は、WebLogic Server MBeanリファレンスの左側のペインにある「Runtime MBeans」ノードをオープンします。実行時MBeanがアルファベット順にリストされています。

JMX MBeanのプログラミングに関する全般的な情報については、『JMXによる管理の容易なアプリケーションの開発』を参照してください。

セキュリティの有効化

pub-subサーバーでは、以下のセキュリティ機能が提供されます。

- パブリッシュ/サブスクライブの制約の使用

- プリンシパルへのロールのマップ

- パブリッシュ/サブスクライブ通信でのSSLの構成

- セキュリティのその他の考慮事項

次の項では、これらの機能の使用方法について説明します。

パブリッシュ/サブスクライブの制約の使用

pub-subサーバーでは、チャネル制約と認可制約という2つのメカニズムを組み合わせてチャネルを保護する機能が提供されます。

チャネル制約は、概念的には、保護対象のリソースの集合と、必要に応じてその集合内の特定のリソースに関する認可制約を格納するコンテナです。認可制約は、WebLogic Serverのロールおよびポリシーを表し、「この集合内のこのリソースに対して特定の操作を実行できるのは誰か」といった問いに答えます。

pub-sub制約は、構成ファイルのweblogic-pub-sub.xmlで指定します。pub-subサーバーは、weblogic-pub-sub.xml構成ファイルのチャネル制約および認可制約を使用し、チャネルに対してロールおよびポリシーを設定します。

例として、例12-1に示すサンプルを考えます。重要な箇所は太字で示しています。

例12-1 Pub/Sub制約

<wlps:channel-constraint>
<wlps:channel-resource-collection>
<wlps:channel-resource-name>publish</wlps:channel-resource-name>
<wlps:description>publish channel constraint</wlps:description>
<wlps:channel-pattern>/stock/* *</wlps:channel-pattern>
<wlps:channel-pattern>/management/publisher</wlps:channel-pattern>
<wlps:channel-operation>publish</wlps:channel-operation>
</wlps:channel-resource-collection>

<wlps:auth-constraint>
<wlps:description>publisher</wlps:description>
<wlps:role-name>publisher</wlps:role-name>
</wlps:auth-constraint>

</wlps:channel-constraint>

この例では、/stock/* *チャネルと/management/publisherチャネルに対して操作publishを実行できるのが、WebLogic Serverロールpublisherを持つユーザーに限定されています。

チャネル操作へのアクセスの指定

チャネルに関しては、以下の4種類のアクション(操作)が許可されています。

- create

- delete

- subscribe

- publish

subscribe操作はデフォルトで(チャネル制約が定義されていない場合)、どのようなユーザーがどのチャネルに対しても実行することができます。

同様に、create、delete、およびpublish操作はデフォルトで、どのようなユーザーがどのチャネルに対しても実行することはできません。create、delete、およびpublish操作は、チャネル制約で明示的に構成されている場合にのみ許可されます。

特定のロールに対して任意のチャネル操作へのアクセスを指定するには、<wlps:channel-operation>と<wlps:auth-constraint>を組み合わせて使用します。

たとえば、例12-2では、publish操作が、publisherロールを持つ認証される対象に対しては許可され、その他のすべてのロールに対しては許可されていません。

例12-2 publisherロールの制約

<wlps:channel-constraint>

<wlps:channel-resource-collection>
<wlps:channel-resource-name>publish</wlps:channel-resource-name>
<wlps:description>publish channel constraint</wlps:description>
<wlps:channel-pattern>/stock/* *</wlps:channel-pattern>
<wlps:channel-pattern>/management/publisher</wlps:channel-pattern>
<wlps:channel-operation>publish</wlps:channel-operation>
</wlps:channel-resource-collection>

<wlps:auth-constraint>
<wlps:description>publisher</wlps:description>
<wlps:role-name>publisher</wlps:role-name>
</wlps:auth-constraint>

</wlps:channel-constraint>

すべてのチャネル操作へのアクセスの制限

空の認可制約(<wlps:auth-constraint> </wlps:auth-constraint>)を指定すると、指定したチャネル操作(<wlps:channel-operation>が指定されていない場合はすべてのチャネル操作)に対して、すべてのアクセスが禁止されます。

したがって、すべてのユーザーに対してチャネルに対するすべての操作を制限するには、次に示すように、weblogic-pub-sub.xml構成ファイルに空の<wlps:auth-constraint>要素を含めて設定します。

<wlps:channel-constraint>
<wlps:channel-resource-collection>
<wlps:description>Restrict All Acesss</wlps:description>
<wlps:channel-pattern>/**</wlps:channel-pattern>
</wlps:channel-resource-collection>
<wlps:auth-constraint> </wlps:auth-constraint>
</wlps:channel-constraint>

すべてのチャネル操作へのアクセスの許可

チャネル制約内に認可制約がない場合、指定したチャネル操作(<wlps:channel-operation>が指定されていない場合はすべてのチャネル操作)に対してアクセスが制限されません。

一方、空の認可制約(<wlps:auth-constraint> </wlps:auth-constraint>)を指定すると、指定したチャネル操作(<wlps:channel-operation>が指定されていない場合はすべてのチャネル操作)に対して、すべてのアクセスが禁止されます。

したがって、すべてのユーザーに対してチャネルに対するすべての操作を許可するには、次に示すように、weblogic-pub-sub.xml構成ファイルに<wlps:channel-operation>または<wlps:auth-constraint>要素を含めずに設定します。

<wlps:channel-constraint>
<wlps:channel-resource-collection>
<wlps:description>All Acesss</wlps:description>
<wlps:channel-pattern>/**</wlps:channel-pattern>
</wlps:channel-resource-collection>
<!-- Not defining an auth-constraint will open up access to everyone -->
</wlps:channel-constraint>

Webアプリケーションの再デプロイによる制約の更新

制約は動的に更新することができません。新しい設定を有効化するには、Webアプリケーションを再デプロイする必要があります。

プリンシパルへのロールのマップ

注意:

pub-subサーバーは認証を直接行いません。かわりに、pub-subサーバーはWebLogic Server (サーブレット・コンテナ)の最上位で動作し、WebLogic認証サービスを利用します。具体的には、pub-subサーバーは、特定のクライアントからのリクエストに対して、現在認証されているユーザー(匿名ユーザー)を利用します。

主要なpub-subセキュリティ・メカニズムは認可です。前述したように、pub-subサーバーは<wlps:channel-operation>要素と<wlps:auth-constraint>要素を組み合わせてチャネルに対するロールおよびポリシーの設定を行います。各bayeuxパケットは、1つのbayeuxリクエストに対応します。1つのHTTPリクエストは、1つまたは複数のbayeuxリクエストに変換されます。WebLogic Server (サーブレット・コンテナ)はHTTPリクエストに対して認可チェックを何度か実行し、pub-subサーバーは各bayeuxリクエストに対して認可チェックを1回実行します。

pub-sub認可を設定するにはロール名(weblogic-pub-sub.xmlファイルで<wlps:role-name>some-role-name</wlps:role-name>として指定)をプリンシパル名にマップする必要があります。これには、weblogic.xmlファイルで構成されたsecurity-role-assignment要素を使用します。

注意:

weblogic.xmlファイルにこのようなマッピングがない場合、そのロールは暗黙的に使用され、警告が生成されます。

「security-role-assignment」で説明しているように、security-role-assignment要素は、WebLogic Serverセキュリティ・レルム内の1つまたは複数のプリンシパルとセキュリティ・ロール間のマッピングを宣言します。

例12-3は、security-role-assignment要素を使用してプリンシパルをpublisherロールに割り当てる方法を示しています。

例12-3 security-role-assignment要素

<weblogic-web-app>
<security-role-assignment>
<role-name>publisher</role-name>
<principal-name>Tanya</principal-name>
<principal-name>Fred</principal-name>
<principal-name>system</principal-name>
</security-role-assignment>

</weblogic-web-app>

パブリッシュ/サブスクライブ通信でのSSLの構成

デフォルトでは、すべてのpub-sub通信はHTTPを介します。ただし、web.xmlファイルの変更により、pub-subサーバーがSSLを要請するように構成できます。SSLを要請すると、pub-subサーバーとWeb 2.0クライアント間のすべての通信がSSLを介して行われます。

WebLogic Serverは、INTEGRALまたはCONFIDENTIALトランスポート保証(web.xmlファイルで指定)を使用してユーザーが認証を受けた場合にSSL接続を確立します。例12-4では、トランスポート保証がINTEGRALに設定されています。

例12-4 web.xmlによるSSLの要請

<security-constraint>

<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/cometd/*</url-pattern>

<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>

<user-data-constraint>
<transport-guarantee>INTEGRAL</transport-guarantee>
</user-data-constraint>

</security-constraint>

セキュリティのその他の考慮事項

この項では、以下のpub-subセキュリティに関するその他の考慮事項について説明します。

- AuthCookieEnabledによるリソースへのアクセス

- Pub-Subサーバーのロック

AuthCookieEnabledによるリソースへのアクセス

WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を有効にするには、config.xmlのWebServer要素にAuthCookieEnabled="true"を追加します。

<WebServer Name="myserver" AuthCookieEnabled="true"/>

AuthCookieEnabledをtrue (デフォルト設定)に設定すると、新しいセキュアなCookie(_WL_AUTHCOOKIE_JSESSIONID)が、HTTPS接続を介した認証時にブラウザに送信されるようになります。一度セキュアなCookieが設定されると、セッションはそのCookieがブラウザから送信された場合しかセキュリティ制約のある他のHTTPSリソースにアクセスできません。

注意:

この機能はCookieが無効になっていても動作します。WebLogic Serverでは、URL中のauthCookieIDをJSESSIONIDとともにエンコードするために、セキュアな接続でのURL書換えを使用してセキュアなURLを書き換えるためです。

Pub-Subサーバーのロック

この項では、pub-subサーバーをロックして権限のないアクセスを防ぐ方法について説明します。ここで説明する手順では、アクセスの制限と引換えに追加のセキュリティを提供します。現在の環境に適したセキュリティ・レベルを決定してください。

pub-subサーバーをロックするには、次の手順に従います。

1. pub-sub通信に対してSSLを構成します。「パブリッシュ/サブスクライブ通信でのSSLの構成」を参照してください。

2. 認証(BASIC、FORMなど)を要求します。
WebLogic Serverでは、Webアプリケーションに要求される認証方式をweb.xmlファイルで設定します。

以下の例では、HTTP BASIC認証が要求されています。

<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>

3. auth-cookieがWebアプリケーションで有効化されていることを確認します。「AuthCookieEnabledによるリソースへのアクセス」を参照してください。

4. すべてのチャネルがweblogic-pubsub.xmlファイルで制約されていることを確認します。

5. デフォルトで許可されているsubscribe操作をロックします。

<wlps:channel-constraint>
<wlps:channel-resource-collection>
<wlps:channel-resource-name>publish</wlps:channel-resource-name>
<wlps:description>publish channel constraint</wlps:description>
<wlps:channel-pattern>/stock/*</wlps:channel-pattern>

<wlps:channel-pattern>/management/publisher</wlps:channel-pattern>
<wlps:channel-operation>publish</wlps:channel-operation>
</wlps:channel-resource-collection>

<wlps:auth-constraint>
<wlps:description>publisher</wlps:description>
<wlps:role-name>publisher</wlps:role-name>
</wlps:auth-constraint>
</wlps:channel-constraint>

<wlps:channel-constraint>
<wlps:channel-resource-collection>
<wlps:channel-resource-name>subscribe</wlps:channel-resource-name>
<wlps:description>subscribe channel constraint</wlps:description>
<wlps:channel-pattern>/stock/*</wlps:channel-pattern>
<wlps:channel-operation>subscribe</wlps:channel-operation>
</wlps:channel-resource-collection>

<wlps:auth-constraint>
<wlps:description>subscriber</wlps:description>
<wlps:role-name>subscriber</wlps:role-name>
</wlps:auth-constraint>

</wlps:channel-constraint>

高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

pub-subサーバー・アプリケーションは、スケーラビリティとサーバーのフェイルオーバー機能を提供できるように、WebLogic Serverのクラスタリング環境で動作できます。しかし、pub-subアプリケーションの動作は、パブリッシュされたメッセージを処理するメッセージ・ハンドラ(pub-subサーバー自体またはJMSプロバイダ)によって異なります。デフォルトの非JMSの場合、pub-subサーバーがすべてのメッセージを処理し、各クラスタ・ノード上のpub-subサーバーの各インスタンスは独立かつ孤立しています。これは、異なるサーバー・インスタンス間でイベント・メッセージを共有できないことを意味します。たとえば、クラスタのノードA上のチャネル/chatをサブスクライブしているクライアントは、同じクラスタのノードB上のチャネル/chatにパブリッシュされたメッセージを受信することができません。

クラスタのすべてのノードにパブリッシュされたすべてのメッセージを、特定のチャネルをサブスクライブしているすべてのクライアントが共有できるようにするには、そのチャネルをJMS用に構成する必要があります。これは、アプリケーションのweblogic-pubsub.xmlデプロイメント記述子内の適切な<wlps:channel>要素を更新して行います。

JMSが構成されたチャネルへクライアントがメッセージをパブリッシュすると、pub-subサーバーはそのメッセージをJMSトピックに再送します。JMSトピックからのメッセージは、クラスタの各ノードで実行されているJMSメッセージ・リスナーが取得した上で、ノード上のサブスクライブ済みクライアントへ配信します。

ハンドラとしてのJMSの構成

JMSをアプリケーションのメッセージ・ハンドラとして構成するには、pub-subサーバーのweblogic-pubsub.xmlデプロイメント記述子を使用します。

まず、ルート<wlps:weblogic-pubsub>要素の<wlps:jms-handler-mapping>子要素を使用して、JMSハンドラの構成を宣言します。ここに、JMSプロバイダのURL、接続ファクトリJNDI名、およびJMSトピックJNDI名を指定します。次に、<wlps:jms-handler-name>子要素を追加して、特定のチャネルがJMSチャネルになるよう構成します。

以下に、JMSハンドラとチャネルをweblogic-pubsub.xmlデプロイメント記述子で構成する方法の例を示します(関連箇所のみ太文字で示しています)。サンプルの後の説明を参照してください。

注意:

この項では、JMSプロバイダを構成済で、pub-sub JMSチャネルに使用される接続ファクトリおよびトピックを作成済であるものとします。WebLogic JMSの詳細は、『Oracle WebLogic Server JMSのプログラミング』または使用しているプロバイダのドキュメントを参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<wlps:weblogic-pubsub
xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub">
<wlps:server-config>
...
</wlps:server-config>
<wlps:jms-handler-mapping>
<wlps:jms-handler-name>DefaultJmsHandler</wlps:jms-handler-name>
<wlps:jms-handler>
<wlps:jms-provider-url>t3://localhost:7001</wlps:jms-provider-url>
<wlps:connection-factory-jndi-name>ConnectionFactoryJNDI</wlps:connection-factory-jndi-name>
<wlps:topic-jndi-name>TopicJNDI</wlps:topic-jndi-name>
</wlps:jms-handler>
</wlps:jms-handler-mapping>
<wlps:channel>
<wlps:channel-pattern>/chat/**</wlps:channel-pattern>
<wlps:jms-handler-name>DefaultJmsHandler</wlps:jms-handler-name>
</wlps:channel>
</wlps:weblogic-pubsub>

上記の例では:

- <wlps:jms-handler-mapping>要素で、DefaultJmsHandlerという名前のJMSハンドラを定義しています。<wlps:jms-handler>子要素では、pub-subサーバーがJMSトピックにメッセージを委託する際に使用するDefaultJmsHandlerの特定のプロパティを構成しています。具体的には、JMSプロバイダのJNDIツリーにアクセスするためにpub-subサーバーで使用されるJMSプロバイダURLがt3://localhost:7001であり、接続ファクトリJNDI名がConnectionFactoryJNDIであり、メッセージの委託先トピックのJNDI名がTopicJNDIです。

- <wlps:channel>の<wlps:jms-handler-name>子要素では、/chatのパターンのチャネルが実際には、DefaultJmsHandlerで指定されるJMS構成オプションを持つJMSチャネルであることが指定されています。

weblogic-pubsub.xmlデプロイメント記述子に指定できるJMSハンドラに関連するXML要素の一覧は、weblogic-pubsub.xsdスキーマ(http://xmlns.oracle.com/weblogic/weblogic-pubsub/1.0/weblogic-pubsub.xsd)を参照してください。

クライアント・セッション・フェイルオーバーの構成

サーバーのフェイルオーバーに加え、pub-subサーバーでは、クラスタリング環境におけるクライアント・セッションのフェイルオーバーもサポートします。クライアント・フェイルオーバーでは、チャネルのサブスクライブ時またはアンサブスクライブ時など、クライアントのステータスが変化すると、レプリケートされたHTTPセッション内にクライアントの最新ステータスが格納されます。クラスタ内の1つのノードがクラッシュすると、クラッシュしたノード上のクライアントは、レプリケートされたHTTPセッションを利用して別の利用可能なノードに移動され、回復が試行されます。

クライアント・セッション・フェイルオーバーを構成するには、次に示すように、pub-subアプリケーションをホストするWebアプリケーションのweblogic.xmlデプロイメント記述子ファイルで、ルート<weblogic-web-app>要素に<session-descriptor>子要素を追加し、永続ストアのタイプとしてreplicated_if_clusteredを指定します(関連箇所のみ太字で示しています)。

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>
</weblogic-web-app>

高度なトピック: 物理ストレージへのメッセージの永続化

特定のチャネルへパブリッシュされたメッセージを永続化するには、そのチャネルを永続チャネルとして構成する必要があります。この場合、このチャネルにパブリッシュされるすべてのメッセージは、データベースまたはファイル・システムなどの物理記憶域へ永続化されます。具体的には、この物理記憶域は、事前構成済WebLogic永続ストアである必要があります。WebLogicの永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能ストレージ・ソリューションを提供します。永続ストアは、ファイルベースのストアまたはJDBC対応データベースの永続性をサポートします。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用方法に関する項を参照してください。

Oracleでは、永続メッセージを格納するためのファイルまたはJDBCストアを独自に作成し、このストアを永続チャネル用に構成することをお薦めします。ただし、構成された名前のストアが検出されない場合は、メッセージの格納にはデフォルトのWebLogic永続ストアが使用され、警告メッセージがログ・ファイルに記録されます。

永続ストア内のメッセージは無期限には保存されず、構成された最大存続期間プロパティに基づき、その期間の経過後にストアから古いメッセージが定期的に削除されます。この最大期間のデフォルト値は3600秒ですが、永続チャネルごとに異なる値を構成することができます。

永続チャネルをサブスクライブするクライアントは、永続クライアントと呼ばれます。通常のクライアントとの主な違いは、pub-subサーバーによるタイムアウトの処理方法にあります。pub-subサーバーを構成する際は、2つの異なるタイムアウト構成オプションを使用できます; 以下の要素は、weblogic-pubsub.xmlファイルの<wlps:server-config>の子要素です:

- <wlps:client-timeout-secs> —通常の(非永続)クライアントが接続/再接続メッセージ送信しない場合に、削除(永続クライアントの場合は非アクティブ化)されるまでの秒数を指定します。非アクティブ化時には、そのクライアントがサブスクライブ済みの永続チャネルはすべて保持され、非永続チャネルはアンサブスクライブされます。デフォルト値は60秒です。

- <wlps:persistent-client-timeout-secs> —永続クライアントが接続/再接続メッセージ送信しない場合に、接続が切断および削除されるまでの秒数を指定します。この要素には、client-timeout-secsより大きな値を指定する必要があります。永続クライアントは、この永続タイムアウト値に達する前に再接続した場合はその期間内に永続チャネルにパブリッシュされたすべてのメッセージを受信できますが、このタイムアウト値より後に再接続した場合はそれらのメッセージを受信できません。デフォルト値は600秒です。

永続チャネルの構成

永続チャネルは、pub-subサーバーのweblogic-pubsub.xmlデプロイメント記述子ファイルで構成します。

まず、デフォルトの永続タイムアウト値の600秒を変更する場合は、<wlps:server-config>の<wlps:persistent-client-timeout-secs>子要素を追加してpub-subを構成します。次に、<wlps:channel>の<wlps:channel-persistence>子要素を追加して永続チャネルを構成し、そのチャネルのメッセージが保持される最大期間と、メッセージの格納先となる永続ストアの名前を指定します。次の例では、weblogic-pubsub.xmlファイルの関連箇所を示します。

<?xml version="1.0" encoding="UTF-8"?>
<wlps:weblogic-pubsub
xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub">
<wlps:server-config>
...
<wlps:persistent-client-timeout-secs>400</wlps:persistent-client-timeout-secs>
</wlps:server-config>
<wlps:channel>
<wlps:channel-pattern>/chat/**</wlps:channel-pattern>
<wlps:channel-persistence>
<wlps:max-persistent-message-duration-secs>3000</wlps:max-persistent-message-duration-secs>
<wlps:persistent-store>PubSubFileStore</wlps:persistent-store>
</wlps:channel-persistence>
</wlps:channel>
</wlps:weblogic-pubsub>

上記の例では:

- 永続クライアントのタイムアウト値が400秒です。この値は、このpub-subサーバーのすべての永続チャネルに適用されます。

- /chatのパターンのチャネルとそのすべてのサブチャネルが、永続チャネルとして構成されています。メッセージは、PubSubFileStoreという名前のWebLogic永続ストアに格納され、そのストア内で最大3000秒間存続します。
PubSubFileStoreは、WebLogic Server管理コンソールを使用してすでに作成し、構成しているものとします。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用方法に関する項を参照してください。

13 WebLogic JSPリファレンス

次の項では、JavaServer Pages (JSP)の作成に関するリファレンス情報を提供します。

- JSPタグ

- JSPバージョンの定義

- 暗黙的オブジェクト用の予約語

- WebLogic JSPのディレクティブ

- 宣言

- スクリプトレット

- 式

- HTMLと埋め込みJavaを使用したJSPの例

- アクション

- JSP式言語

- JSP式言語の暗黙的オブジェクト

- JSP式言語のリテラルと演算子

- JSP式言語の予約語

- JSP式言語の名前付き変数

- JSPでのユーザー入力データのセキュリティ

- JSPでのセッションの使用方法

- JSPからのアプレットのデプロイメント

- WebLogic JSPコンパイラの使用方法

JSPタグ

以下の表では、JSPページで使用できる基本的なタグについて説明します。短縮形のタグには、それぞれ対応するXMLタグがあります。

表13-1 JSPページの基本タグ

JSPタグ

構文

説明

Scriptlet

<% java_code %>

または対応する以下のXMLタグを使用する

<jsp:scriptlet>

java_code

</jsp:scriptlet>

Javaソース・コード・スクリプトレットを、HTMLページ内に埋め込みます。Javaコードが実行され、その出力が順に残りのHTMLとともにページへ挿入されます。詳細は、「スクリプトレット」を参照してください。

Directive

<%@ dir-type dir-attr %>

または対応する以下のXMLタグを使用する

<jsp:directive.dir_type dir_attr />

ディレクティブには、アプリケーション・サーバーへのメッセージが含まれます。

また、ディレクティブは、attr="value"という形式の名前/値ペア属性も含んでおり、これらはアプリケーション・サーバーへの付加的な命令を提供します。「WebLogic JSPのディレクティブ」を参照。

Declarations

<%! declaration %>

...または、等価なXMLタグを使用します...

<jsp:declaration>
declaration;
</jsp:declaration>

ページ内の他の宣言、スクリプトレット、または式から参照できる変数またはメソッドを宣言します。「宣言」を参照してください。

Expression

<%= expression %>

...または、等価なXMLタグを使用します...

<jsp:expression>
expression
</expression>

ページをリクエストするときに評価され、Stringに変換されてから、JSPレスポンスの出力ストリームにインライン化された状態で送信されるJava式を定義します。「式」を参照してください。

Actions

<jsp:useBean ... >

Beanをここでインスタンス化する場合は、ここにJSP本文を入れる

</jsp:useBean>
<jsp:setProperty ... >
<jsp:getProperty ... >
<jsp:include ... >
<jsp:forward ... >
<jsp:plugin ... >

JSPの高度な機能へのアクセスを提供し、XML構文のみを使用します。これらのアクションは、JSP 2.1仕様の定義のとおりにサポートされています。「アクション」を参照してください。

Comments

<%/* comment */%>

HTMLファイルの表示可能なソースからコメントを削除する場合は、JSPコメント・タグのみを使用してください。ブラウザでソースの表示を選択した場合、HTMLのコメントは表示されたままになります。

JSPバージョンの定義

JSP 2.1ではいくつかの新機能が導入され、同じ構文がJSP 2.1とJSP 2.0間で異なる意味を持つ場合があるため、想定する動作を実現するにはJSPバージョンを定義する必要があります。例:

- <%@ page deferredSyntaxAllowedAsLiteral="true" %>はJSP 2.0では使用できません。

- # {expr}はJSP 2.0のテンプレート・テキストでは有効ですが、JSP 2.1ではデフォルトで無効になっています。

JSPファイル・バージョンの定義ルール

JSPページのバージョンは、明示的な指定方法がないため、次のようにWebアプリケーションのバージョンによって決まります。

- JSPドキュメントのバージョンは、ドキュメント内に<jsp:root>がある場合はその属性のバージョン値によって決まり、ない場合はWebアプリケーションのバージョンによって決まります。

- WebアプリケーションのバージョンによってJSPバージョンが決まる場合、2.5はそのバージョンがJSP 2.1であることを、2.4はそのバージョンがJSP 2.0であることを示します。

- JSPドキュメントに<jsp:root>があり、Webアプリケーションのバージョンが2.4である場合、<jsp:root>のバージョンは2.0を超えてはなりません。ただし、Webアプリケーションのバージョンが2.5の場合は、<jsp:root>のバージョンは2.1未満にできます。

- 参照されるすべてのJSPタグ・バージョンは、現在のJSPファイルのバージョンを超えてはなりません。

タグ・ファイル・バージョンの定義ルール

すべてのJSPタグ・ファイルのバージョンは、そのタグ・ファイルが属するタグ・ライブラリのバージョンによって決まります。

- 暗黙的なタグ・ライブラリはディレクトリごとに作成されるため(タグ・ファイルを含む)、暗黙的なタグ・ライブラリのバージョンはデフォルトで2.0となります。ただし、このバージョンは、JSP 2.1の同じディレクトリにあるimplicit.tldファイルによって構成することができます。

- .tagxファイルの<jsp:root>属性のバージョン値は、タグ・ファイルのバージョンと同じである必要があります。

- 参照されるすべてのJSPタグ・バージョンは、現在のタグ・ファイルのバージョンを超えてはなりません。

暗黙的オブジェクト用の予約語

JSPでは、スクリプトレットや式に含まれる暗黙的オブジェクト用に予約語が用意されています。この暗黙的オブジェクトとは、JSPページに有用なメソッドや情報を提供するJavaオブジェクトです。WebLogic JSPは、JSP 2.1仕様に定義されている暗黙的オブジェクトをすべて実装しています。JSP APIについては、JSPホームページ(http://www.oracle.com/technetwork/java/javaee/jsp/index.html)にあるJavadocで説明されています。

注意:

この暗黙的オブジェクトはスクリプトレットや式の中でのみ使用するようにします。宣言で定義されるメソッドからこれらのキーワードを使用すると、未定義の変数を参照することになるため、変換時にコンパイル・エラーが発生します。

表13-2 暗黙的オブジェクト用の予約語

予約語

説明

request

HttpServletRequestオブジェクトを表します。ブラウザからのリクエストについての情報が含まれ、Cookie、ヘッダー、およびセッション・データを取得するために便利な一連のメソッドも用意されています。

response

HttpServletResponseオブジェクト、JSPページからブラウザに返送されるレスポンスの設定に便利な複数のメソッドを表します。このレスポンスの例には、Cookieやその他のヘッダー情報があります。

注意: JSPページ内からresponse.getWriter()メソッドを使用することはできません。使用した場合、実行時例外がスローされます。JSPレスポンスをブラウザに返送するには、可能であればスクリプトレット・コード内からoutキーワードを使用します。WebLogic Serverのjavax.servlet.jsp.JspWriterの実装では、javax.servlet.ServletOutputStreamを使用しています。これは、response.getServletOutputStream()を使用できることを暗黙的に示しています。しかし、この実装はWebLogic Serverに固有のものであることに注意が必要です。コードの保守容易性および移植性を保つには、outキーワードを使用します。

out

javax.jsp.JspWriterのインスタンスで、ブラウザへの出力の返送に使用できるメソッドがあります。

出力ストリームを必要とするメソッドを使用している場合、JspWriterは動作しません。この制限を回避するには、バッファされたストリームを提供して、このストリームをoutに記述します。次のコードに、例外スタック・トレースをoutに記述する方法を示します。

ByteArrayOutputStream ostr = new ByteArrayOutputStream();
exception.printStackTrace(new PrintWriter(ostr));
out.print(ostr);

pageContext

javax.servlet.jsp.PageContextオブジェクトを表します。様々なスコープのネームスペースやサーブレット関連オブジェクトへのアクセスに便利なAPIで、一般的なサーブレット関連機能のためのラッパー・メソッドを提供します。

session

リクエストに対するjavax.servlet.http.HttpSessionオブジェクトを表します。セッション・ディレクティブは、デフォルトではtrueに設定されています。したがって、sessionはデフォルトで有効です。JSP 2.1仕様では、セッション・ディレクティブがfalseに設定されている場合、sessionキーワードを使用すると変換時に致命的なエラーが発生することが説明されています。

application

javax.servlet.ServletContextオブジェクトを表します。サーブレット・エンジンやサーブレット環境に関する情報の検索に使用します。

リクエストを転送または取り込む場合は、ServletContextを使用してサーブレットのrequestDispatcherにアクセスできます。または、他のサーブレットへのリクエストの転送にJSPのforwardディレクティブ、他のサーブレットからの出力の取込みにJSPのincludeディレクティブを使用することもできます。

config

javax.servlet.ServletConfigオブジェクトを表し、サーブレット・インスタンスの初期化パラメータへのアクセスを提供します。

page

このJSPページから生成されたサーブレット・インスタンスを表します。スクリプトレット・コード内のJavaキーワードthisと同義です。

pageはjava.lang.Objectのインスタンスとして定義されるため、使用する際にはJSPページを実装しているサーブレットのクラス・タイプにキャストする必要があります。デフォルトでは、このサーブレット・クラスはJSPファイル名を取って名付けられます。便宜上、pageを使用するかわりに、Javaキーワードthisを使用してサーブレット・インスタンスを参照し、初期化パラメータへアクセスすることをお薦めします。

WebLogic JSPのディレクティブ

関数を実行したり、JSPページを特定の方法で解釈したりするようWebLogic JSPに指示するには、ディレクティブを使用します。ディレクティブは、JSPページのどこに挿入してもかまいません。通常、ディレクティブの位置は無関係で(includeディレクティブを除く)、複数のディレクティブ・タグを使用できます。ディレクティブは、ディレクティブ・タイプとその1つまたは複数の属性で構成されます。

構文は、次に示すように短縮形とXMLの2種類を使用できます。

- 短縮形: <%@ dir_type dir_attr %>

- XML: <jsp:directive.dir_type dir_attr />

dir_typeはディレクティブのタイプ、dir_attrはそのディレクティブ・タイプの1つまたは複数のディレクティブ属性のリストで置き換えます。

ディレクティブには、page、taglib、includeの3種類があります。

ページ・ディレクティブを使用した文字エンコーディングの設定

文字エンコーディング・セットを指定するには、そのページの先頭で次のディレクティブを使用します。

<%@ page contentType="text/html; charset=custom-encoding" %>

contentTypeディレクティブで指定した文字セットは、JSPおよびそのJSPに含まれるすべてのJSPで使用される文字セットを指定します。

WebアプリケーションのWebLogic固有のデプロイメント記述子に、デフォルトの文字エンコーディングを指定できます。

taglibディレクティブの使用方法

taglibディレクティブを使用して、JSPページが、タグ・ライブラリに定義されているカスタムJSPタグ拡張を使用することを宣言します。カスタムJSPタグの記述方法と使用方法の詳細は、『WebLogic JSPタグ拡張のプログラミング』を参照してください。

宣言

宣言を使用して、生成されたJSPサーブレット内のクラス・スコープ・レベルの変数とメソッドを定義します。JSPタグの間に記述された宣言は、JSPページの他の宣言やスクリプトレットからアクセスできます。例:

<%!
int i=0;
String foo= "Hello";
private void bar() {
// ...java code here...
}
%>

クラス・スコープのオブジェクトは、サーブレットの同一のインスタンス内で実行中の複数のスレッド間で共有されます。共有違反を防ぐには、クラス・スコープのオブジェクトを同期させます。スレッドセーフなコードの記述に自信がない場合は、次のディレクティブを使用して、サーブレットを非スレッドセーフとして宣言できます。

<%@ page isThreadSafe="false" %>

デフォルトでは、この属性はtrueに設定されています。isThreadSafeをfalseに設定すると、メモリー消費量が増えるのでパフォーマンスが低下することがあります。

スクリプトレット

JSPスクリプトレットは、JSPサーブレットのHTTPレスポンスのJava本文を構成します。次に示すように短縮形またはXMLのscriptletタグを使用して、JSPページ内にスクリプトレットを含めます。

短縮形:

<%
// Your Java code goes here
%>

XML:

<jsp:scriptlet>
// Your Java code goes here
</jsp:scriptlet>

スクリプトレットの特長は次のとおりです。

- JavaコードとプレーンなHTMLが混在する複数ブロックのスクリプトレットを作成できます。

- Javaコンストラクトやブロックの内部であっても、任意の場所でHTMLとJavaコードを切り替えられます。「HTMLと埋め込みJavaを使用したJSPの例」では、Javaループを宣言し、HTMLに切り替えてから、再びJavaコードに戻ってループを閉じています。ループ内部のHTMLは、ループが反復する回数分出力として生成されます。

- あらかじめ定義されている変数outを使用して、Javaコードからサーブレット出力ストリームに、HTMLテキストを直接出力できます。print()メソッドを呼び出して、HTTPページ・レスポンスに文字列を追加します。

- ユーザーが以前に入力したデータを出力する場合、HTML特殊文字が入力されていればすべて削除することをお薦めします。これらの文字を削除しない場合、クロス・サイト・スクリプティングによってWebサイトが損なわれるおそれがあります。詳細は、「JSP式言語」を参照してください。

- このJavaタグはインライン・タグであり、パラグラフが分けられることはありません。

式

JSPファイルの中に式を含めるには、次のタグを使用します。

<%= expr %>

exprをJava式で置き換えます。式が評価されるときに、そのstring表現がHTMLレスポンス・ページ内にインラインで配置されます。これは次の短縮形です

<% out.print( expr ); %>

このテクニックを使用すると、JSPページ内のHTMLを読みやすくできます。次の項のサンプルではexpressionタグの使用方法を示します。

式は、ユーザーが以前に入力したデータを戻すためによく使われます。ユーザーが入力したデータを出力する場合、HTML特殊文字が入力されていればすべて削除することをお薦めします。これらの文字を削除しない場合、クロス・サイト・スクリプティングによってWebサイトが損なわれるおそれがあります。詳細は、「JSP式言語」を参照してください。

HTMLと埋め込みJavaを使用したJSPの例

次に、HTMLと埋め込みJavaを使用したJSPの例を示します。

<html>
<head><title>Hello World Test</title></head>
<body bgcolor=#ffffff>
<center>
<h1> <font color=#DB1260> Hello World Test </font></h1>
<font color=navy>
<%
out.print("Java-generated Hello World");
%>
</font>
<p> This is not Java!
<p><i>Middle stuff on page</i>
<p>
<font color=navy>
<%
for (int i = 1; i<=3; i++) {
%>
<h2>This is HTML in a Java loop! <%= i %> </h2>
<%
}
%>
</font>
</center>
</body>
</html>

上記のコードがコンパイルされると、ブラウザには次のようなページが表示されます。

アクション

JSPアクションを使用して、JavaBeanで表されるオブジェクトの変更、使用、または作成を行います。アクションでは、XML構文のみが使用されます。

JSPでのJavaBeanの使用方法

<jsp:useBean>アクション・タグを使用すると、JavaBean仕様に準拠したJavaオブジェクトをインスタンス化し、それをJSPページから参照できます。

JavaBean仕様に準拠するには、オブジェクトに次のものが必要です。

- 引数をとらないパブリック・コンストラクタ

- 各variableフィールドに対するsetVariable()メソッド

- 各variableフィールドに対するgetVariable()メソッド

JavaBeanオブジェクトをインスタンス化する

<jsp:useBean>タグは、既存の名前付きJavaオブジェクトを特定のスコープから検索しようと試みます。既存のオブジェクトが見つからなければ、新しいオブジェクトをインスタンス化し、id属性で指定された名前にそのオブジェクトを関連付けようとします。オブジェクトは、オブジェクトの可用性を決定するscope属性で指定された位置に格納されます。たとえば、次のタグでは、examples.jsp.ShoppingCartというタイプのJavaオブジェクトを、cartという名前のHTTPセッションから検索しようとします。

<jsp:useBean id="cart"
class="examples.jsp.ShoppingCart" scope="session"/>

そのようなオブジェクトが存在しない場合、JSPでは新しいオブジェクトを作成し、cartという名前のHTTPセッション内に格納しようとします。クラスは、WebLogic Serverの起動に使用するCLASSPATH、またはJSPを含むWebアプリケーションのWEB-INF/classesディレクトリに入っている必要があります。

捕捉が必要な実行時例外があるので、<jsp:useBean>タグとともにerrorPageディレクティブを使用することをお薦めします。errorPageディレクティブを使用しない場合、JavaBeanで参照されるクラスを作成できず、InstantiationExceptionがスローされ、ブラウザにエラー・メッセージが返されます。

Java内で有効な型キャスト操作であれば、type属性を使用して、そのJavaBeanタイプを別のオブジェクトやインタフェースにキャストできます。class属性なしでこの属性を使用する場合、JavaBeanオブジェクトは、指定したスコープ内にすでに存在している必要があります。有効でない場合は、InstantiationExceptionがスローされます。

JavaBeanインスタンス化のセット・アップ作業を行う

<jsp:useBean>タグ構文には、別の形式もあります。これを使用すると、オブジェクトがインスタンス化されるときに実行するJSPコードの本文を定義できます。名前付きJavaBeanが指定したスコープ内にすでにある場合、本文は実行されません。この形式を使用すると、オブジェクトが最初に作成されるときのプロパティを設定できます。例:

<jsp:useBean id="cart" class="examples.jsp.ShoppingCart"
scope=session>
Creating the shopping cart now...
<jsp:setProperty name="cart"
property="cartName" value="music">
</jsp:useBean>

注意:

class属性なしでtype属性を使用すると、JavaBeanオブジェクトはインスタンス化されません。したがって、本文を含めるようなタグ形式は使用しないでください。代わりに、単一のタグ形式を使用します。この場合、JavaBeanが指定したスコープ内に存在している必要があります。存在していないとInstantiationExceptionがスローされます。errorPageディレクティブを使用して、潜在的な例外を捕捉します。

JavaBeanオブジェクトを使用する

JavaBeanオブジェクトをインスタンス化したら、Javaオブジェクトのように、JSPファイルでそのid名により参照できます。スクリプトレット・タグや式評価タグ内でそれを使用できます。<jsp:setProperty>タグを用いてそのsetXxx()メソッドを呼び出すこともでき、また<jsp:getProperty>タグを用いてgetXxx()メソッドを呼び出すこともできます。

JavaBeanオブジェクトのスコープを定義する

scope属性を使用して、JavaBeanオブジェクトの可用性とライフスパンを指定します。スコープは以下のいずれかです。

表13-3 JavaBeanオブジェクトのscope属性の定義

スコープ

説明

page

JavaBeanに対するデフォルトのスコープです。オブジェクトは現在のページのjavax.servlet.jsp.PageContextに格納されます。このJSPページの現在の呼出しからのみ使用できます。インクルードされたJSPページでは使用できません。このページ・リクエストの完了時には破棄されます。

request

requestスコープを使用すると、オブジェクトは現在のServletRequest内に格納されます。同じリクエスト・オブジェクトに渡された他のインクルード済みJSPページで使用可能です。このオブジェクトは現在のリクエストが完了したときに破棄されます。

session

複数のHTTPページにわたってJavaBeanオブジェクトを追跡できるよう、sessionスコープを使用してHTTPセッション内にJavaBeanオブジェクトを格納できます。JavaBeanへの参照は、このページのHttpSessionオブジェクトに格納されます。このスコープを使用するには、JSPページがセッションに参加できなければなりません。つまり、このpageディレクティブで、sessionをfalseに設定しないようにします。

application

application-scopeレベルでは、JavaBeanオブジェクトはWebアプリケーションに格納されます。このスコープを使用すると、同じWebアプリケーションの中で実行されている他のサーブレットやJSPページからもこのオブジェクトが使用可能になります。

JavaBeansの使用の詳細は、JSP 2.1仕様(http://www.oracle.com/technetwork/java/javaee/jsp/index.html)を参照してください。

リクエストの転送

どのような種類の認証を使用している場合でも、<jsp:forward>タグでリクエストが転送されるときには、ユーザーを再認証する必要はありません(デフォルト設定)。この動作を変更して、転送されたリクエストの認証を実行するには、<check-auth-on-forward/>要素をWebLogic固有のデプロイメント記述子(weblogic.xml)の<container-descriptor>要素に追加します。例:

<container-descriptor>
<check-auth-on-forward/>
</container-descriptor>

リクエストのインクルード

<jsp:include>タグを使用すると、JSPに別のリソースを含めることができます。このタグは、次の2種類の属性を取ります。

page - 含めるリソースを指定するためにページ属性を使用します。例:

<jsp:include page="somePage.jsp"/>

flush - このブール型属性をtrueに設定すると、ページ出力がバッファに格納され、リソースが含まれる前にそのバッファがフラッシュされます。<jsp:include>タグがJSPページの別のタグ内にあり、含めるリソースをそのタグで処理する場合は、flush="false"に設定すると便利です。

JSP式言語

新しいJSP式言語(JSP EL 2.1)は、ECMAScript式言語とXPath式言語の両方の影響を受けています。JSP ELは、標準アクションおよびカスタム・アクションの属性値と、テンプレート・テキスト内で使用可能です。どちらの場合も、JSP ELは一貫して構文#{expr}または${expr}で呼び出されます。

#{expr}構文は、JSP EL 2.1で導入された遅延式を示します。「#{}」で区切られた式は、その値がシステムで必要とされるまで評価されないため、「遅延評価」を使用します。これにより、式はライフサイクル内の適切な時点で基底のメカニズムによって処理されるようになります。一方、「${}」で区切られた式は、JSPページのコンパイル時にコンパイルされ、JSPページの実行時に実行されるため、「即時評価」を使用します。遅延式には、遅延ValueExpressionおよび遅延MethodExpressionが含まれます。${expr}構文は、JSP EL 2.1でサポートされています。

このJSP ELがJSP技術に追加されたことで、スクリプトレットJSPページをより簡単に記述できるようになりました。スクリプトレットJSPページではJSP EL式を使用できますが、Javaスクリプトレット、Java式、そしてJava宣言要素は使用できません。この使用パターンは、web.xmlデプロイメント記述子のscripting-invalid JSP構成要素を介して使用することができます。

JSP式言語の詳細は、http://java.sun.com/products/jsp/download/index.htmlを参照してください。

式および属性値

JSP EL式は、実行時の式を受け入れられる任意の属性で、標準アクションとカスタム・アクションのどちらの場合にも使用できます。以下に、属性値での式の使用方法として例を示します。

- 属性値に式の構文<some:tag value="${expr}"/>または<some:tag value="#{expr}"/>を1つ含めます。この場合、式が評価され、結果がその属性の想定される型に変換されます。この変換は、http://java.sun.com/products/jsp/download/index.htmlのセクション1.18 「Type Conversion」で説明されている型変換のルールに従います。

- 属性値に1つまたは複数の式をテキストを挟むかテキストで囲む形で含めます。たとえば<some:tag value="some${expr}${expr}text${expr}"/>または<some:tag value="some#{expr}#{expr}text#{expr}"/>のようにします。この場合、式が左から右へ評価され、(後述の型変換ルールに従って) String型に変換されてから、間に挟まれたテキストと連結されます。結果であるString型はhttp://java.sun.com/products/jsp/download/index.htmlのセクション1.18 「Type Conversion」で説明されている型変換のルールに従って、その属性の想定される型に変換されます。

- 属性値にテキストのみを含めます。たとえば<some:tag value="sometext"/>のようにします。この場合、属性のString値がその属性の想定される型に変換されます。この変換は、http://java.sun.com/products/jsp/download/index.htmlのセクション1.18 「Type Conversion」で説明されている型変換のルールに従います。

注意:

このルールはJSP 2.1の変換と同様ですが、空の文字列の扱いが異なります。

JSPXを使用する際は、以下の2つの条件を満たす必要があります。

- web.xml - web-appで、サーブレットのバージョン属性が2.4以上に定義されている必要があります。この条件が満たされない場合は、すべてのEL機能が無視されます。

- TLDファイル- jsp接頭辞に、次のようなネームスペース宣言が必要です。

<html xmlns:jsp="http://java.sun.com/JSP/Page";

以下に、JSP ELを使用してBeanのプロパティが3個未満かどうかを調べる条件付きのアクションを示します。

<c:if test="${bean1.a < 3}">
...
</c:if>

通常のJSPの制御メカニズムでも<mytags: if test="true" />を使用することは可能です。リテラル値に文字列${を含める場合、この値を含むリテラルの使用方法は次のようになります。この場合、その値を含むリテラルの使用方法は次のようになります。

<mytags:example code="an expression is ${'${'}expr}" />

結果として生じる属性値は、「an expression is ${expr}」という文字列になります。

式およびテンプレート・テキスト

テンプレート・テキスト内にはJSP ELを直接使用できます。カスタムまたは標準のアクションの本文内でもアクション外部のテンプレート・テキスト内でも構いません。ただし、タグの本体がタグ依存の場合や、(通常、互換性の問題から)ディレクティブによって明示的に、または暗黙的にJSP ELが無効化されている場合は除きます。

JSP EL式のセマンティクスはJava式と同じで、値が計算されて現在の出力に挿入されます。エスケープ処理が必要な場合(クロス・サイト・スクリプティング攻撃を予防するために行う場合など)は、JSTLのコア・タグ<c:out>を使用できます。例:

<c:out value="${anELexpression}" />

以下に示すカスタム・アクションでは、2つのJSP EL式を使用してBeanのプロパティにアクセスしています。

<c:wombat>
One value is ${bean1.a} and another is ${bean2.a.c}.
</c:wombat>

JSP式言語の暗黙的オブジェクト

JSPページ内で使用するJSP EL式で利用可能な暗黙的オブジェクトが、複数用意されています。これらのオブジェクトは以下の名前を使用して常に利用可能です。

- pageContext - pageContextオブジェクトを表します。

- pageScope - ページ・スコープの属性名とその値のマップを表します。

- requestScope - リクエスト・スコープの属性名とその値のマップを表します。

- sessionScope - セッション・スコープの属性名とその値のマップを表します。

- applicationScope - アプリケーション・スコープの属性名とその値のマップを表します。

- param - パラメータ名と単一のString型パラメータ値(ServletRequest.getParameter(String name)の呼出しで取得される)のマップを表します。

- paramValues - パラメータ名とそのパラメータのすべての値を含む単一のString[] (ServletRequest.getParameterValues(String name)の呼出しで取得される)のマップを表します。

- header - ヘッダー名と単一のString型ヘッダー値(ServletRequest.getHeader(string name)の呼出しで取得される)のマップを表します。

- headerValues - ヘッダー名とそのヘッダーのすべての値を含むString[] (ServletRequest.getHeaders(String name)の呼出しで取得される)のマップを表します。

- cookie - Cookie名と単一のCookieオブジェクトのマップを表します。Cookieは、HttpServletRequest.getCookies()のセマンティクスにしたがって取得されます。複数のCookieで同じ名前が共有されている場合、実装では必ずgetCookies()メソッドから返されたCookieオブジェクトの配列のうち最初のものが使用されます。ただし、暗黙的オブジェクトCookieを使用するユーザーは、Cookieの順序が現在のServlet仕様では指定されていないことを認識しておく必要があります。

- initParam - コンテキストの初期化パラメータ名とそのString型のパラメータ値(ServletRequest.getInitParameter(String name)の呼出しで取得される)のマップを表します。

表13-4に、上記の暗黙的オブジェクトの使用例をいくつか示します。

表13-4 暗黙的オブジェクトの使用例

式

説明

${pageContext.request.requestURI}

リクエストのURI (HttpServletRequestから取得)

${sessionScope.profile}

セッション・スコープの属性の名前付きプロファイル(見つからなかった場合null)

${param.productId}

productIdパラメータのString値(見つからなかった場合null)

${paramValues.productId}

productIdパラメータのすべての値を含むString[] (見つからなかった場合null)

JSP式言語のリテラルと演算子

以降の節では、JSP EL式のリテラルと演算子について説明します。JSP ELの構文はとても簡単です。変数には名前でアクセスできます。汎用の演算子[]を使用すると、マップ、リスト、オブジェクトの配列、およびJavaBeanオブジェクトのプロパティにアクセスできます。この演算子は自由にネスト可能です。.演算子は、JavaのID規約に従った名前を持つプロパティに対し、簡単にアクセスする手段として使用できます。一方、[]演算子では、より汎用的なアクセスが可能です。

標準のJava関係演算子を使用して、関係比較を行えます。他の値、ブール値(等価比較のみ)、String型、整数、または浮動小数点リテラルに対して比較を実行できます。算術演算子を使用すると、整数および浮動小数点の値を計算できます。論理演算子も利用可能です。

リテラル

ブール値、整数、浮動小数点、文字列、null用のリテラルが用意されています。

- ブール値 - trueおよびfalse

- 整数 - JSP 2.1 EL仕様の1.19項 「Collected Syntax」のIntegerLiteralコンストラクトで定義されています。

- 浮動小数点 - JSP 2.1 EL仕様の1.19項 「Collected Syntax」のFloatingPointLiteralコンストラクトで定義されています。

- 文字列 - 単一引用符および二重引用符。"引用符は、同じ種類の引用符で囲まれた文字列値でのみエスケープする必要があります。

- Null - null

エラー、警告、デフォルト値

ほとんどの場合、JSPページは表示用に使われます。表示に使用する場合は一般的に、ページに単純なエラーがあっても可能な限り良い状態で表示できるようにすることが、もっとも重要なポイントになります。JSP ELでは、この要件のための警告は用意されていませんが、デフォルト値とエラーを利用できます。デフォルト値は入力を修正する値で、問題がある場合に代わりに表示するものとして割り当てられます。エラーは例外であり、スローされた後には標準のJSP機構で処理されます。

演算子

JSP式言語で提供される演算子の一覧を以下に示します。

- .および[]

- 算術演算子: +、- (二項演算子)、*、/およびdiv、%およびmod、- (単項演算子)

- 論理演算子: and、&&、or、||、not、!

- 比較演算子: ==、eq、!=、ne、<、lt、>、gt、<=、ge、>=、le他の値、ブール値、文字列、整数、または浮動小数点リテラルに対して比較を実行できます。

- 空演算子: empty演算子は接頭辞操作で、値がnullまたは空のどちらなのかを判断するために使用できます。

- 条件演算子: A ?B : C。Aを評価した結果に応じてBまたはCの評価が実施されます。

演算子とその機能の詳細は、JSP 2.1仕様を参照してください。

演算子の優先順位

以下に、演算子の優先順位を高い方から低い方へ、左から右の順で示します。

- [] .

- ()

- - (単項演算子) not ! empty

- * / div % mod

- + - (二項演算子)

- < > <= >= lt gt le ge

- == != eq ne

- && and

- || or

- ? :

JSP式言語の予約語

以下の単語は予約語であり、識別子として使用することはできません。

- and

- eq

- gt

- true

- instanceof

- or

- ne

- le

- false

- empty

- not

- lt

- ge

- null

- div

- mod

注意:

現時点では、これらの単語の多くがこの言語に含まれていません。ただし、将来的に組み入れられる可能性があるので、使用は避けるようにしてください。

JSP式言語の名前付き変数

JSP ELの基本的な構想に、変数名を評価してオブジェクトに解決することがあります。JSP EL APIでは、名前をオブジェクトに解決する汎用メカニズムとしてVariableResolverが提供されています。このデフォルトの解決メカニズムが、テンプレートや属性内にあるJSP EL式の評価に使用されます。このデフォルト解決メカニズムでは、「JSP式言語の暗黙的オブジェクト」で説明した暗黙的オブジェクトが提供されています。

デフォルトの解決メカニズムでは、他の識別子をマップすることも可能です。これには、pageContextオブジェクトのPageContext.findAttribute(String)の動作により、識別子の値を属性としてルックアップします。たとえば${product}のようにします。

この式ではproductという名前の属性を検索し、ページ、リクエスト、セッション、およびアプリケーション・スコープを検索して、属性の値を返します。属性が見つからない場合、nullが返されます。JSP 2.1仕様の第14章「Expression Language API」を参照してください。VariableResolverの詳細と、評価APIとの対応関係について参照してください。

JSPでのユーザー入力データのセキュリティ

式やスクリプトレットを使用すると、JSPでユーザーからデータを受け取ったり、ユーザーが入力したデータを返したりできます。たとえば、例13-1のサンプルJSPでは、ユーザーに文字列の入力を求め、その文字列をuserInputという名前のパラメータに代入してから、<%= javax.servlet.ServletRequest.getParameter("userInput")%>という式を使ってそのデータをブラウザに返しています。

例13-1 ユーザーが入力した内容を戻すための式の使用

<html>
<body>
<h1>My Sample JSP</h1>
<form method="GET" action="mysample.jsp">
Enter string here:
<input type="text" name="userInput" size=50>
<input type=submit value="Submit">
</form>
<br>
<hr>
<br>
Output from last command:
<%= javax.servlet.ServletRequest.getParameter("userInput")%>
</body>
</html>

このようにユーザーが入力したデータを返す機能があると、クロス・サイト・スクリプティングと呼ばれるセキュリティの脆弱性がもたらされます。これは、ユーザーのセキュリティ認可を盗用するために利用されるおそれがあります。クロス・サイト・スクリプティングの詳細については、http://www.cert.org/tech_tips/malicious_code_mitigation.htmlの「Understanding Malicious Content Mitigation for Web Developers」(CERTのセキュリティ勧告)を参照してください。

セキュリティの脆弱性をなくすには、ユーザーが入力したデータを戻す前に、そのデータをスキャンして、表13-5に示すHTML特殊文字があるかどうかを調べます。特殊文字が見つかった場合、HTMLのエンティティ参照または文字参照と置き換えます。文字を置換することで、ブラウザでユーザー入力によるデータがHTMLとして実行されることを回避します。

表13-5 置換えの必要があるHTMLの特殊文字

置き換える必要のある特殊文字

置換え後のエンティティ/文字参照

<

&lt;

>

&gt;

(

&40;

)

&41;

#

&35;

&

&38;

WebLogic Serverユーティリティ・メソッドを使用する

WebLogic Serverには、ユーザーが入力したデータ内の特殊文字を置き換えるweblogic.servlet.security.Utils.encodeXSS()メソッドが用意されています。このメソッドを使用するには、ユーザー入力データを入力として提供します。例:

<%= weblogic.servlet.security.Utils.encodeXSS(
javax.servlet.ServletRequest.getParameter("userInput"))%>

アプリケーション全体を保護するため、ユーザーが入力したデータは、戻す際に毎回encodeXSS()メソッドを使用する必要があります。上記の例はencodeXSS()メソッドを明らかに使用すべき場所ですが、表13-5には、他にencodeXSS()メソッドの使用を検討すべき場所を示します。

表13-6 ユーザー入力データを戻すコード

ページのタイプ

ユーザー入力データ

例

エラー・ページ

誤りのある入力文字列、無効なURLやユーザー名

「ユーザー名はアクセスを許可されていません。」と表示するエラー・ページ

ステータス・ページ

ユーザー名、以前のページでの入力の要約

以前のページでの入力を確認するようユーザーに求める要約ページ

データベース表示

データベースから提示されたデータ

以前にユーザーによって入力されたデータベース・エントリのリストを表示するページ

JSPでのセッションの使用方法

WebLogic JSP内のセッションは、JSP 2.1仕様にしたがって動作します。次に、セッションの使用方法に関連した留意事項を示します。

- セッションには小さなオブジェクトを格納します。たとえば、セッションはEJBの格納ではなく、EJB主キーの格納に使用する方がよいでしょう。大量のデータは、データベースに格納します。セッションには、データの単純な文字列参照のみを保持するようにします。

- サーブレットまたはJSPの動的な再ロードとともにセッションを使用する場合、サーブレット・セッションに格納されるオブジェクトは、シリアライズ可能でなければなりません。シリアライゼーションが必要なのは、サーブレットが新しいクラス・ローダーで再ロードされるためです。再ロードにより、先に(サーブレットの古いバージョンから)ロードされたクラスと、新しいクラス・ローダーにロードされる(サーブレット・クラスの新しいバージョンに対応した)クラスとの間で互換性がなくなります。この互換性の欠如によって、サーブレットからClassCastExceptionエラーが返されます。

- セッション・データがユーザー定義型でなければならない場合、データ・クラスはシリアライズできるようにする必要があります。さらに、セッションはシリアライズされた形のデータ・オブジェクトを格納する必要があります。このとき、シリアライゼーションはデータ・クラスのバージョン間で互換性を保つ必要があります。

JSPからのアプレットのデプロイメント

JSPを使用すると、適切なクライアント・ブラウザ・タグを含むHTMLを生成することによって、WebページにJava Plug-inを簡単に組み込むことができます。Java Plug-inでは、クライアントのWebブラウザにより実装されたJVMのかわりに、Java Runtime Environment (JRE)を使用することができます。この機能により、アプレットと特定の種類のWebブラウザ間の非互換性による問題が回避できます。Java Plug-inは、http://www.oracle.com/technetwork/java/index-jsp-141438.htmlで入手可能です。

Internet ExplorerとNetscapeでは使用している構文が違うため、<jsp:plugin>アクションから生成されたサーブレット・コードでは、動的にブラウザ・クライアントの種類が調べられ、適切な<OBJECT>タグか、<EMBED>タグがそのHTMLページに送信されます。

<jsp:plugin>タグでは、<APPLET>タグの属性に似た多くの属性、および使用するJava Plug-inのバージョンを構成できる他の属性群が使用されます。アプレットがサーバーと通信する場合、アプレット・コードを実行するJVMはWebLogic Serverを実行するJVMと互換性がある必要があります。

次のサンプルでは、プラグイン・アクションを使用してアプレットをデプロイします。

<jsp:plugin type="applet" code="examples.applets.PhoneBook1"
codebase="/classes/" height="800" width="500"
jreversion="2.0"
nspluginurl=
"http://java.sun.com/products/plugin/1.1.3/plugin-install.html"
iepluginurl=
"http://java.sun.com/products/plugin/1.1.3/
jinstall-113-win32.cab#Version=1,1,3,0" >
<jsp:params>
<param name="weblogic_url" value="t3://localhost:7001">
<param name="poolname" value="demoPool">
</jsp:params>
<jsp:fallback>
<font color=#FF0000>Sorry, cannot run java applet!!</font>
</jsp:fallback>

</jsp:plugin>

上のサンプルのJSP構文は、ブラウザに対して、(まだダウンロードされていなければ) Java Plug-inバージョン1.3.1をダウンロードし、code属性で指定したアプレットを、codebaseで指定された位置から実行するように指示しています。

jreversion属性は、アプレットが要求しているJava Plug-inのバージョンを識別します。Webブラウザでは、このバージョンのJava Plug-inを使おうとします。プラグインがまだブラウザにインストールされていない場合、nspluginurl属性およびiepluginurl属性で、Java Plug-inのダウンロード元のURL(http://www.oracle.com/technetwork/java/index-jsp-141438.html)を指定します。一度プラグインがWebブラウザにインストールされれば、再度そのプラグインをダウンロードする必要はありません。

WebLogic ServerではJava 1.3.x VMを使用するため、<jsp:plugin>タグ内に、Java Plug-inバージョン1.3.xを指定する必要があります。上のサンプル・コードで1.3 JVMを指定するには、対応する属性値を次のように置き換えます。

jreversion="1.3"
nspluginurl=
"http://java.sun.com/products/plugin/1.3/plugin-install.html"
iepluginurl=
"http://java.sun.com/products/plugin/1.3/jinstall-131-win32.cab"

プラグイン・アクションのほかの属性は、<APPLET>タグの属性に相当します。アプレット・パラメータは、<params>タグのペアで指定し、<jsp:plugin>タグと</jsp:plugin>タグでネストします。

<jsp:fallback>タグでは、<jsp:plugin>アクションでサポートされていないブラウザ用にHTMLを置換できます。<fallback>タグと</jsp:fallback>タグでネストされたHTMLが、プラグイン構文のかわりに送られます。

WebLogic JSPコンパイラの使用方法

注意:

WebLogic JSPコンパイラは非推奨になっています。EARファイル、WARファイル、およびEJBをコンパイルするには、WebLogicのappcコンパイラであるweblogic.appcの使用をお薦めします。『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のappcリファレンスに関する項を参照してください。

WebLogic JSPコンパイラではコンパイルのパフォーマンスを向上させるため、ディスク上にまずjavaファイルを作成してからクラス・ファイルにコンパイルするのではなく、直接JSPをディスク上のクラス・ファイルに変換します。javaファイルはメモリー上にのみ置かれます。

生成されたjavaファイルを参照するには、メモリー内のjavaファイルをディスクにダンプする -keepgeneratedフラグをオンにします。

注意:

JSPのコンパイル中には、コマンド・ライン・フラグ(compilerclass)も記述子要素も呼び出されません。

JSPコンパイラの構文

JSPコンパイラは、他のWebLogicコンパイラ(RMIコンパイラやEJBコンパイラなど)とほとんど同じ方法で動作します。JSPコンパイラを起動するには、次のコマンドを入力します。

$ java weblogic.jspc -options fileName

fileNameを、コンパイルするJSPファイルの名前で置き換えます。ターゲットのfileNameの前か後にoptionsを指定することもできます。次の例では、-dオプションを使用してmyFile.jspをコンパイルし、出力先ディレクトリweblogic/classesに出力します。

$ java weblogic.jspc -d /weblogic/classes myFile.jsp

注意:

Webアプリケーションの一部で、Webアプリケーションのリソース(JSPタグ・ライブラリなど)を参照しているJSPをプリコンパイルする場合は、-webappフラグを使用してWebアプリケーションの場所を指定する必要があります。次のJSPコンパイラ・オプションのリストで、-webappフラグについて説明します。

JSPコンパイラ・オプション

次のオプションを任意で組み合わせて使用します。

表13-7 JSPコンパイラ・オプション

オプション

説明

-classpath

希望するCLASSPATHとなるディレクトリのリストを(Windows NT/2000プラットフォームではセミコロンで区切り、UNIXプラットフォームではコロンで区切って)追加します。JSPに必要なすべてのクラスを格納するディレクトリを含めます。次に例を示します(実際には1行で入力します)。

$ java weblogic.jspc -classpath  java/classes.zip;/weblogic/classes.zip myFile.JSP

-charsetMap

JSP contentTypeディレクティブで使用されるIANAまたは非公式の文字セット名からjava文字セット名へのマッピングを指定します。例:

-charsetMap x-sjis=Shift_JIS,x-big5=Big5

最も一般的なマッピングは、JSPコンパイラに組み込まれています。このオプションは、希望の文字セット・マッピングが認識されない場合にのみ使用します。

-commentary

JSPコンパイラにより、生成されたHTMLページにJSPからのコメントが含められます。このオプションを省略すると、コメントは生成されたHTMLページに表示されません。

-compileAll

カレント・ディレクトリ、または-webappオプションで指定したディレクトリ内のすべてのJSPを再帰的にコンパイルします-webappの説明を参照)。サブディレクトリ内のJSPもコンパイルされます。

-compileFlags

1つまたは複数のコマンド・ライン・フラグをコンパイラに渡します。複数のフラグはスペースで区切り、引用符で囲みます。例:

java weblogic.jspc -compileFlags "-g -v" myFile.jsp

-compiler

生成されたJavaソース・コードからクラス・ファイルをコンパイルする際に使用するJavaコンパイラを指定します。デフォルトでは、コンパイラとしてjavacが使われます。コンパイラのフルパスを明示的に指定する場合を除いて、Javaコンパイラ・プログラムはPATH内になければなりません。

-compilerclass

Javaコンパイラを、ネイティブ実行ファイルとしてではなく、Javaクラスとして実行します。

-compressHtmlTemplate

JSPテンプレート・ブロック内のHTMLを圧縮し、実行時のパフォーマンスを改善します。

JSPのHTMLテンプレート・ブロックに<pre>タグが含まれる場合は、このオプションを有効にしないでください。

-d <dir>

コンパイルされた出力(クラス・ファイル)の出力先ディレクトリを指定します。このオプションは、コンパイルされたクラスを、すでにCLASSPATHに入っているディレクトリに置くためのショートカットとして使用します。

-depend

JSPの以前に生成されたクラス・ファイルのタイム・スタンプが、JSPソース・ファイルよりも新しい場合、JSPは再コンパイルされません。

-debug

デバッグ・モードでコンパイルします。

-deprecation

生成されたJavaソース・ファイルをクラス・ファイルにコンパイルしているときに、ソース・ファイル中に非推奨のメソッドが使用されていると警告します。

-docroot directory

-webappを参照してください。

-encoding default|named character encoding

有効な引数は、(a) JDKのデフォルト文字エンコーディングの使用を指定するdefault、または(b) 8859_1などの名前付き文字エンコーディングです。-encodingフラグが指定されない場合、バイト配列が使用されます。

-g

クラス・ファイルにデバッグ情報も入れるよう、Javaコンパイラに指示します。

-help

JSPコンパイラで使用可能なオプションをすべて表示します。

-J

コンパイラに渡されるオプションのリストを取得します。

-k

1つのコマンドで複数のJSPをコンパイルする場合、1つまたは複数のJSPがコンパイルに失敗しても、コンパイルを続行します。

-keepgenerated

コンパイル処理の途中で作成されたJavaソース・コード・ファイルを削除せずに残します。通常、こうしたファイルはコンパイル後に削除されます。

-noTryBlocks

JSPファイルに、多数のまたは深くネストしたカスタムJSPタグが含まれていて、コンパイル時にjava.lang.VerifyError例外が発生する場合、JSPを正しくコンパイルするためにこのフラグを使用します。

-nowarn

Javaコンパイラからの警告メッセージが出力されないようにします。

-noPrintNulls

JSPの式の"null"が"" (空の文字列)として示されます。

-O

最適化を有効にして、生成されたJavaソース・ファイルをコンパイルします。このオプションは、-gオプションをオーバーライドします。

-optimizeJavaExpression

Java式を最適化し、実行時のパフォーマンスを改善します。

-package packageName

生成されたJava HTTPサーブレットのパッケージ名の前に追加するパッケージ名を設定します。デフォルトはjsp_servletです。

-superclass classname

生成されたサーブレットによって拡張されたスーパークラスのクラス名を設定します。スーパークラスの名前は、HttpServletまたはGenericServletから派生したものでなければなりません。

-verbose

compilerフラグで指定されたJavaコンパイラに、verboseフラグを渡します。詳細は、コンパイラのドキュメントを参照してください。デフォルトはoffです。

-verboseJavac

指定したJSPコンパイラによって生成されたメッセージを出力します。

-version

JSPコンパイラのバージョンを出力します。

-webapp directory

展開されたディレクトリ形式のWebアプリケーションが含まれるディレクトリの名前。JSPタグ・ライブラリやその他のJavaクラスなど、Webアプリケーション内のリソースへの参照がJSPに含まれる場合、JSPコンパイラはそのリソースをこのディレクトリで検索します。Webアプリケーションのリソースを要求するJSPをコンパイルする場合、このフラグを省略するとコンパイルに失敗します。

JSPのプリコンパイル

weblogic.xmlデプロイメント記述子の<jsp-descriptor>要素のprecompileパラメータをtrueに設定すると、Webアプリケーションをデプロイまたは再デプロイしたとき、またはWebLogic Serverを起動したときにJSPをプリコンパイルするようにWebLogic Serverを構成できます。サーバーを再起動するたびに、また追加でサーバーをターゲット指定したときに、JSPを再コンパイルしないようにするには、weblogic.jspcを使用してJSPをプリコンパイルし、プリコンパイルしたJSPをWEB-INF/classesフォルダにコピーして、.warファイルにアーカイブします。ソース・ファイルをアーカイブ.warファイルとは別のディレクトリに格納すると、クラス・ファイルのいずれかとJSPとの依存関係によってエラーが発生するおそれがなくなります。

JSPClassServletの使用

JSPの再コンパイルを回避する別の方法は、JSPServletのかわりにJSPClassServletを使用し、コンパイル済みのJSPをWEB-INF/classesディレクトリ内に格納することです。これによって、ソース・コードがサーバーから検出されなくなるため、JSPが再コンパイルされる可能性がなくなります。この方法を使用すると、JSPに対するいかなる変更も記録されず、JSPは再コンパイルされません。この方法により、プリコンパイル後にアプリケーションからJSPソース・コードを完全に削除することができます。

JSPClassServletをWebアプリケーションのweb.xmlファイルに追加する方法の例を次に示します。

<servlet>
<servlet-name>JSPClassServlet</servlet-name>
<servlet-class>weblogic.servlet.JSPClassServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>JSPClassServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>

仮想ホスティングを使用する場合は、作成するマッピングに対応する物理的なディレクトリを用意し、サーバーがファイルを検出できるようにする必要があります。

14 フィルタ

この章では、Webアプリケーションでのフィルタの使用に関する情報を提供します。

- フィルタの概要

- フィルタ・クラスの作成

- フィルタの構成

- サーブレット・レスポンス・オブジェクトでのフィルタ処理

- その他の情報源

フィルタの概要

フィルタは、Webアプリケーションのリソースに対するリクエストに応えて呼び出されるJavaクラスです。リソースには、Javaサーブレット、JavaServer Pages (JSP)、およびHTMLページや画像などの静的リソースがあります。フィルタを使用すると、リクエストをインターセプトして、レスポンス・オブジェクトおよびリクエスト・オブジェクトの検証や変更などを実行できます。

フィルタは、開発者が既存のリソースのコーディングを変更できず、そのリソースの動作を変更する必要がある状況を主に想定した、高度なJava EE機能です。一般に、フィルタを使ってリソースを変更するよりは、コードを変更してリソースの動作自体を変更した方が効率的です。状況によっては、フィルタを使用することによって、アプリケーションが不必要に複雑になり、パフォーマンスが低下することがあります。

フィルタの動作と仕組み

フィルタは、Webアプリケーションのコンテキストで定義します。フィルタは特定の名前のリソースまたはリソースのグループ(URLパターンに基づく)に対するリクエストをインターセプトして、フィルタ内でコードを実行します。それぞれのリソースまたはリソースのグループに対して、単一のフィルタ、またはチェーンと呼ばれる特定の順序で起動される複数のフィルタを指定できます。

フィルタは、リクエストをインターセプトするとき、HTTPリクエストとレスポンスへのアクセスを提供するjavax.servlet.ServletRequestオブジェクトとjavax.servlet.ServletResponseオブジェクト、およびjavax.servlet.FilterChainオブジェクトにアクセスできます。FilterChainオブジェクトには、順番に起動できるフィルタのリストが含まれています。フィルタは、作業を終了すると、チェーン内の次のフィルタを起動する、リクエストをブロックする、例外をスローする、本来リクエストされていたリソースを起動する、のうちのいずれかの処理を行うことができます。

本来のリソースが起動されると、制御は、チェーン内のリストの最後にあるフィルタに返されます。その後で、このフィルタは、レスポンス・ヘッダーとデータの検査および変更、リクエストのブロック、例外のスロー、チェーンの最後より1つ手前にあるフィルタの起動のいずれかを行うことができます。このプロセスはフィルタのチェーン内において逆順で続行されます。

注意:

フィルタでヘッダーを変更できるのは、レスポンスがまだコミットされていない場合のみです。

フィルタの用途

フィルタは次の機能を行うときに便利です。

- ロギング機能の実装

- ユーザーが作成したセキュリティ機能の実装

- デバッグ

- 暗号化

- データの圧縮

- クライアントに送信されるレスポンスの変更(ただし、レスポンスの後処理を行うと、アプリケーションのパフォーマンスが低下するおそれがあります)

フィルタ・クラスの作成

フィルタ・クラスを作成するには、javax.servlet.Filterインタフェース(http://download.oracle.com/javaee/1.3/api/javax/servlet/Filter.htmlを参照)を実装します。このインタフェースの次のメソッドを実装する必要があります。

- init()

- destroy()

- doFilter()

doFilter()メソッドは、リクエスト・オブジェクトとレスポンス・オブジェクトの検査と変更、ロギングなど他のタスクの実行、チェーン内の次のフィルタの起動、または、それ以上の処理のブロックのために使います。

フィルタの名前、ServletContext、およびフィルタの初期化属性にアクセスするために、FilterConfigオブジェクトに対して利用できるメソッドが他にいくつかあります。詳細は、Java EE Javadoc (http://download.oracle.com/javaee/1.3/api/index.html)でjavax.servlet.FilterConfigを参照してください。

チェーン内の次の項目(別のフィルタや元のリソースなどの場合があります)にアクセスするには、FilterChain.doFilter()メソッドを呼び出します。

フィルタの構成

Webアプリケーションのweb.xmlデプロイメント記述子を使って、フィルタをアプリケーションの一部として構成します。デプロイメント記述子では、フィルタを指定してから、そのフィルタをWebアプリケーションのURLパターンまたは特定のサーブレットにマップします。指定できるフィルタの数に制限はありません。

フィルタの構成

フィルタを構成するには:

1. テキスト・エディタでweb.xmlデプロイメント記述子をオープンするか、管理コンソールを使用します。詳細は、「Webアプリケーション開発者向けツール」を参照してください。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。

2. フィルタ宣言を追加します。filter要素では、フィルタの宣言、フィルタの名前の定義、およびフィルタを実行するJavaクラスの指定を行います。filter要素は、context-param要素のすぐ後で、listenerおよびservlet要素のすぐ前に指定します。例:

<context-param>Param</context-param>
<filter>
<icon>
<small-icon>MySmallIcon.gif</small-icon>
<large-icon>MyLargeIcon.gif</large-icon>
</icon>
<filter-name>myFilter</filter-name>
<display-name>My Filter</display-name>
<description>This is my filter</description>
<filter-class>examples.myFilterClass</filter-class>
</filter>
<listener>Listener</listener>
<servlet>Servlet</servlet>

icon、description、display-nameの各要素は省略可能です。

3. filter要素の内部に1つまたは複数の初期化属性を指定します。例:

<filter>
<icon>
<small-icon>MySmallIcon.gif</small-icon>
<large-icon>MyLargeIcon.gif</large-icon>
</icon>
<filter-name>myFilter</filter-name>
<display-name>My Filter</display-name>
<description>This is my filter</description>
<filter-class>examples.myFilterClass</filter-class>
<init-param>
<param-name>myInitParam</param-name>
<param-value>myInitParamValue</param-value>
</init-param>
</filter>

FilterクラスはFilterConfig.getInitParameter()メソッドまたはFilterConfig.getInitParameters()メソッドを使って初期化属性を読み取ることができます。

4. フィルタ・マッピングを追加します。filter-mapping要素は、URLパターンまたはサーブレット名を基にしてどのフィルタを実行するかを指定します。filter-mapping要素は、filter要素(群)のすぐ後ろに指定します。

- URLパターンを使ったフィルタ・マッピングを作成するには、フィルタの名前とURLパターンを指定します。URLパターン・マッチングは、Servlet 2.4仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specs)の11.1項に指定されているルールに従って実行されます。たとえば、次のfilter-mappingは/myPattern/を含むリクエストにmyFilterをマップします。

<filter-mapping>
<filter-name>myFilter</filter-name>
<url-pattern>/myPattern/*</url-pattern>
</filter-mapping>

- 特定のサーブレットに対するフィルタ・マッピングを作成するには、Webアプリケーションに登録されたサーブレットの名前にフィルタをマップします。たとえば、次のコードはmyServletというサーブレットにmyFilterフィルタをマップします。

<filter-mapping>
<filter-name>myFilter</filter-name>
<servlet-hame>myServlet</servlet-name>
</filter-mapping>

5. フィルタのチェーンを作成するには、複数のフィルタ・マッピングを指定します。詳細は、「フィルタのチェーンの構成」を参照してください。

フィルタのチェーンの構成

WebLogic Serverは、送られてくるHTTPリクエストに一致するすべてのフィルタ・マッピングのリストを作成することで、フィルタのチェーンを作成します。リストの順序は次の順番で決定します。

1. リクエストに一致するurl-patternを含むfilter-mapping要素のあるフィルタは、web.xmlデプロイメント記述子に記述された順序でチェーンに追加されます。

2. リクエストに一致するservlet-nameを含むfilter-mapping要素のあるフィルタは、URLパターンに一致するフィルタの後でチェーンに追加されます。

3. チェーン内の最後の項目は常に、最初にリクエストされたリソースです。

フィルタ・クラスでは、FilterChain.doFilter()メソッドを使ってチェーン内の次の項目を起動します。

サーブレット・レスポンス・オブジェクトでのフィルタ処理

サーブレットによって生成された出力にデータを追加することで、フィルタをサーブレットの出力の後処理に使用できます。ただし、サーブレットの出力を取り込むには、レスポンスにラッパーを作成する必要があります(サーブレットが実行を完了し、制御がチェーン内の最後のフィルタに戻される前に、サーブレットの出力バッファは自動的にフラッシュされ、クライアントに送信されるので、元のレスポンス・オブジェクトは使用できません。)そのようなラッパーを作成すると、WebLogic Serverはメモリーで出力の追加コピーを処理する必要が生じ、パフォーマンスが低下することがあります。

レスポンス・オブジェクトやリクエスト・オブジェクトのラッピングの詳細は、http://download.oracle.com/javaee/1.3/api/index.htmlのjavax.servlet.http.HttpServletResponseWrapperとjavax.servlet.http.HttpServletRequestWrapperを参照してください。

その他の情報源

- Servlet 2.5仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html)

- Java EE 5 APIリファレンス(Javadoc) (http://download.oracle.com/javaee/5/api/)

- Java EE 5チュートリアル(http://download.oracle.com/javaee/5/tutorial/doc/)

15 WebLogic JSPフォーム検証タグの使用方法

次の項では、WebLogic JSPフォーム検証タグの使用方法について説明します。

- WebLogic JSPフォーム検証タグの概要

- 検証タグ属性のリファレンス

- WebLogic JSPフォーム検証タグのJSP内での使用方法

- <wl:form>タグを使用したHTMLフォームの作成

- カスタム・バリデータ・クラスの使用方法

- 検証タグを使用したサンプルJSP

WebLogic JSPフォーム検証タグの概要

WebLogic JSPフォーム検証タグは、JSPページによって生成されるHTMLフォームのテキスト・フィールドにユーザーが入力するエントリを検証するための便利な方法です。WebLogic JSPフォーム検証タグを使用すると、よく使用される検証ロジックを繰返しコーディングする必要がなくなります。検証は、WebLogic Server配布キットに含まれている複数のカスタムJSPタグによって行われます。タグは次のことができます:

- 必須フィールドに値が入力されているかどうかを検証します(Required Field Validatorクラス)。

- フィールド内のテキストを正規表現と照らしあわせて検証します(Regular Expression Validatorクラス)。

- フォーム内の2つのフィールドを比較します(Compare Validatorクラス)。

- ユーザーが記述したJavaクラスによってカスタム検証を実行します(Custom Validatorクラス)。

- WebLogic JSPフォーム検証タグには、以下のものがあります。

- <wl:summary>

- <wl:form>

- <wl:validator>

検証タグによってフィールド内のデータが正しく入力されていないことが判明した場合、そのページが再表示され、再入力が必要なフィールドがテキストまたは画像で示され、エンド・ユーザーにアラートを通知します。フォームに正しく入力されると、エンド・ユーザーのブラウザには検証タグで指定された新しいページが表示されます。

検証タグ属性のリファレンス

この項では、WebLogicフォーム検証タグとその属性について説明します。タグを表すために使用される接頭辞は、JSPページのtaglibディレクティブで定義できます。このドキュメントでは、理解しやすいようにwlという接頭辞を使用してWebLogicフォーム検証タグを表します。

<wl:summary>

<wl:summary>は、検証用の親タグです。<wl:summary>の開始タグは、JSP内のすべての要素またはHTMLコードの前に置きます。終了タグの</wl:summary>は、終了タグ</wl:form>の後の任意の場所に置きます。

- name - (オプション) JSPページの<wl:validator>タグによって生成されるすべての検証エラー・メッセージを保持するベクトル変数の名前です。この属性を定義しない場合、デフォルト値のerrorVectorが使用されます。エラー・メッセージのテキストは、<wl:validator>タグのerrorMessage属性で定義されます。
このベクトル内の値を表示するには、<wl:errors/>タグを使用します。<wl:errors/>タグを使用するには、出力を表示するページ上の場所にこのタグを配置します。例:

<wl:errors color="red"/>

かわりに、スクリプトレットを使用することもできます。例:

<% if (errorVector.size() > 0) {
for (int i=0; i < errorVector.size(); i++) {
out.println((String)errorVector.elementAt(i));
out.println("<br>");
}
} %>

ここでerrorVectorは、<wl:summary>タグのname属性で割り当てられたベクトルの名前です。

name属性は、1つのページで複数のフォームを使用するときに必要になります。

- headerText - ページに表示されるテキストを格納する変数です。ページでエラーが発生したときにのみこのテキストを表示する場合、スクリプトレットを使用してこの条件をテストできます。例:

<% if(summary.size() >0 ) {
out.println(headerText);
}
%>

ここでsummaryは、<wl:summary>タグのname属性で割り当てられたベクトルの名前です。

- redirectPage - フォーム検証でエラーが返されない場合に表示されるページのURLです。この属性は、<wl:form>タグのaction属性にURLを指定する場合には必要ありません。
redirectPage属性を<wl:summary>タグが配置されているページに設定しないでください。無限ループとなってStackOverFlow例外が発生します。

<wl:form>

<wl:form>タグはHTML <form>タグとほぼ同じで、WebLogic JSPフォーム検証タグを使って検証できるHTMLフォームを定義します。name属性を使用して各フォームを一意に識別することによって、単一のJSPで複数のフォームを定義できます。

- method - GETまたはPOSTを入力します。この機能は、HTML <form>タグのmethod属性とまったく同じです。

- action - フォーム検証でエラーが返されない場合に表示されるページのURLです。この属性の値は、<wl:summary>タグのredirectPage属性の値に優先します。この属性は、単一のJSPページに複数のフォームを定義する場合に便利です。
action属性を<wl:form>タグが配置されているページに設定しないでください。無限ループとなってStackOverFlow例外が発生します。

- name - この機能は、HTML <form>タグのname属性とまったく同じです。同じページで複数のフォームが使用される場合にフォームを識別します。また、name属性はフォームへのJavaScript参照にも便利です。

<wl:validator>

フォーム・フィールドごとに、1つまたは複数の<wl:validator>タグを使用します。たとえば、正規表現と照らし合わせて入力を検証し、かつ、フィールドに何らかの入力が必要な場合、2つの<wl:validator>タグを使って、1つではRequiredFieldValidatorクラス、もう1つはRegExpValidatorクラスを使用します(空の値は正規表現フィールド・バリデータにより有効と評価されるので、これらのバリデータを両方とも使用する必要があります。)

- errorMessage - <wl:summary>タグのname属性によって定義されるベクトル変数に格納される文字列です。

- expression - RegExpValidatorクラスを使用すると、正規表現が評価されるようになります。RegExpValidatorを使用しない場合、この属性は省略できます。

- fieldToValidate - 検証するフォーム・フィールドの名前です。フィールド名は、HTML <input>タグのname属性で定義されます。

- validatorClass - 検証ロジックを実行するJavaクラスの名前です。3つのクラスを使用できます。また、独自のバリデータ・クラスを作成することもできます。詳細は、「カスタム・バリデータ・クラスの使用方法」を参照してください。
使用できる検証クラスは以下のとおりです。

- weblogicx.jsp.tags.validators.RequiredFieldValidator - テキストがフィールドに入力されているかどうかを検証します。

- weblogicx.jsp.tags.validators.RegExpValidator - 標準の正規表現を使用してフィールド内のテキストを検証します。注意: 空白の値も有効と評価されます。

- weblogicx.jsp.tags.validators.CompareValidator - 2つのフィールドに同じ文字列が入力されているかどうかをチェックします。このクラスを使用する場合、fieldToValidate属性をこれらの2つのフィールドに設定します。例:

fieldToValidate="field_1,field_2"

両方のフィールドが空白の場合でも、比較は有効と評価されます。

- myPackage.myValidatorClass - カスタム・バリデータ・クラスを指定します。

WebLogic JSPフォーム検証タグのJSP内での使用方法

検証タグをJSPで使用するには:

1. JSPを記述します。

1. taglibディレクティブを入力して、WebLogic JSPフォーム検証タグがあるタグ・ライブラリを参照します。例:

<%@ taglib uri="tagl" prefix="wl" %>

接頭辞属性では、JSPページのすべてのタグを参照するために使用される接頭辞を定義します。接頭辞は任意の値に設定できますが、このドキュメントではwlという接頭辞を使用してタグを参照します。

2. <wl:summary> ... </wl:summary>タグを入力します。
開始タグの<wl:summary ...>を、ページ上のすべてのHTMLコード、JSPタグ、スクリプトレット、式の前に配置します。

終了タグの</wl:summary>を、</wl:form>の後の任意の場所に置きます。

3. 付属のタグ・ライブラリに登録されている<wl:form> JSPタグを使用して、HTMLフォームを定義します。詳細は、「<wl:form>」および「<wl:form>タグを使用したHTMLフォームの作成」を参照してください。フォーム・ブロックは必ず</wl:form>タグを使用してクローズしてください。フォームごとに<wl:form>タグのname属性を一意に定義する場合、単一のページに複数のフォームを作成できます。

4. HTML <input>タグを使用して、HTMLフォームのフィールドを作成します。

2. <wl:validator>タグを追加します。このタグの構文については、「<wl:validator>」を参照してください。エラー・メッセージまたは画像を表示するページ上の場所に<wl:validator>タグを配置します。同じページで複数のフォームを使用する場合、<wl:validator>タグを、検証するフォーム・フィールドがある<wl:form>ブロックの中に配置します。
次の例は、必須フィールドの検証を示したものです。

<wl:form name="FirstForm" method="POST" action="thisJSP.jsp">

<wl:validator
errorMessage="Field_1 is required" expression=""
fieldToValidate="field_1"
validatorClass=
"weblogicx.jsp.tags.validators.RequiredFieldValidator"
>
<img src="images/warning.gif">
<font color=red>Field 1 is a required field</font>
</wl:validator>
<p> <input type="text" name = "field_1">  </p>
<p> <input type="text" name = "field_2">  </p>
<p> <input type="submit" value="Submit FirstForm">  </p>
</wl:form>

ユーザーがfield_1に値を入力しなかった場合は、ページが再度表示され、warning.gif画像と「Field 1 is a required field」というテキスト(赤色)が表示され、値を再入力するための空のフィールドが続いて表示されます。

3. WebLogic Serverインストールのextディレクトリのweblogic-vtags.jarファイルを、使用するWebアプリケーションのWEB-INF/libディレクトリにコピーします。このディレクトリは、作成が必要な場合もあります。

4. Webアプリケーションのweb.xmlデプロイメント記述子にtaglib要素を追加することによって、Webアプリケーションでタグ・ライブラリが使用されるよう構成します。例:

<taglib>
<taglib-uri>tagl</taglib-uri>
<taglib-location>
/WEB-INF/lib/weblogic-vtags.jar
</taglib-location>
</taglib>

<wl:form>タグを使用したHTMLフォームの作成

この項では、JSPページにHTMLフォームを作成する方法について説明します。ページに1つまたは複数のフォームを作成するには、<wl:form>タグを使用します。

単一のフォームの定義

weblogic-vtags.jarタグ・ライブラリに含まれている<wl: form>タグを以下のように使用します。

<wl:form method="POST" action="nextPage.jsp">
<p> <input type="text" name ="field_1">  </p>
<p> <input type="text" name ="field_2">  </p>
<p> <input type="submit" value="Submit Form">  </p>
</wl:form>

このタグの構文については、「<wl:form>」を参照してください。

複数のフォームの定義

ページで複数のフォームを使用する場合は、name属性を使用して各フォームを識別します。例:

<wl:form name="FirstForm" method="POST" action="thisJSP.jsp">
<p> <input type="text" name="field_1">  </p>
<p> <input type="text" name="field_2">  </p>
<p> <input type="submit" value="Submit FirstForm">  </p>
</wl:form>
<wl:form name="SecondForm" method="POST" action="thisJSP.jsp">
<p> <input type="text" name="field_1">  </p>
<p> <input type="text" name="field_2">  </p>
<p> <input type="submit" value="Submit SecondForm">  </p>
</wl:form>

検証によってエラーが返されたときのフィールド内の値の再表示

バリデータ・タグによってエラーが発見され、JSPページが再表示されたときに、ユーザーが入力した値を再表示して、フォーム全体を再び入力する必要がないようにしておくと便利です。この場合、HTML <input>タグのvalue属性を使用するか、Apache Jakartaプロジェクトから利用できるタグ・ライブラリを使用します。次に、この両方の手順について説明します。

<input>タグを使用して値を再表示する

javax.servlet.ServletRequest.getParameter()メソッドとHTML <input>タグのvalue属性を一緒に使用すると、検証の失敗によってページが再表示されるときにユーザーの入力を再表示できます。例:

<input type="text" name="field_1"
value="<%= request.getParameter("field_1") %>" >

クロス・サイト・スクリプティングによるセキュリティの脆弱性をなくすには、ユーザーが入力したデータ内のHTML特殊文字をすべてHTMLエンティティ参照に置き換えます。詳細は、「JSP式言語」を参照してください。

Apache Jakarta <input:text>タグを使用して値を再表示する

Apache Jakartaプロジェクトの無償で利用できるJSPタグ・ライブラリを使用することもできます。このタグ・ライブラリには、HTML <input>タグの代わりとして<input:text>タグが用意されています。たとえば、次のHTMLタグがあるとします。

<input type="text" name="field_1">

このタグは、Apacheタグ・ライブラリを使用すると次のように入力できます。

<input:text name="field_1">

詳細およびドキュメントについては、http://jakarta.apache.org/taglibs/doc/input-doc/intro.htmlの「Input Tag library」を参照してください。

Apacheタグ・ライブラリをJSPで使用するには:

1. 入力タグ・ライブラリ配布ファイルに含まれているinput.jarファイルをWebアプリケーションのWEB-INF/libディレクトリにコピーします。

2. 次のディレクティブをJSPに追加します。

<%@ taglib uri="input" prefix="input" %>

3. 次のエントリを、Webアプリケーションのweb.xmlデプロイメント記述子に追加します。

<taglib>
<taglib-uri>input</taglib-uri>
<taglib-location>/WEB-INF/lib/input.jar</taglib-location>
</taglib>

カスタム・バリデータ・クラスの使用方法

独自のバリデータ・クラスを使用するには:

1. weblogicx.jsp.tags.validators.CustomizableAdapter抽象クラスを拡張するJavaクラスを記述します。詳細は、「CustomizableAdapterクラスの拡張」を参照してください。

2. validate()メソッドを実装します。このメソッドでは、次のことを行います。

1. 検証するフィールドの値をServletRequestオブジェクトからルックアップします。例:

String val = req.getParameter("field_1");

2. フィールドが検証条件を満たしている場合、trueを返します。

3. バリデータ・クラスをコンパイルし、コンパイル結果の.classファイルをWebアプリケーションのWEB-INF/classesディレクトリに格納します。

4. バリデータ・クラス名をvalidatorClass属性に指定することによって、そのクラスを<wl:validator>タグで使用します。例:

<wl:validator errorMessage="This field is required" fieldToValidate="field_1" validatorClass="mypackage.myCustomValidator">

CustomizableAdapterクラスの拡張

CustomizableAdapterクラスは、Customizableインタフェースを実装し、以下のヘルパー・メソッドを提供する抽象クラスです。

- getFieldToValidate() - 検証するフィールド(<wl:validator>タグのfieldToValidate属性によって定義される)の名前を返します。

- getErrorMessage() - <wl:validator>タグのerrorMessage属性で定義されるエラー・メッセージのテキストを返します。

- getExpression() - <wl:validator>タグに定義されるexpression属性のテキストを返します。

CustomizableAdapterクラスを拡張するかわりに、Customizableインタフェースを実装できます。詳細は、Javadocでweblogicx.jsp.tags.validators.Customizableについて参照してください。

ユーザーの記述によるバリデータ・クラスのサンプル

例15-1 ユーザーの記述によるバリデータ・クラスのサンプル

import weblogicx.jsp.tags.validators.CustomizableAdapter;

public class myCustomValidator extends CustomizableAdapter{

public myCustomValidator(){
super();
}

public boolean validate(javax.servlet.ServletRequest req)
throws Exception {
String val = req.getParameter(getFieldToValidate());
// perform some validation logic
// if the validation is successful, return true,
// otherwise return false
if (true) {
return true;
}
return false;
}

}

検証タグを使用したサンプルJSP

このサンプル・コードには、WebLogic JSPフォーム検証タグを使用するJSPの基本的な構造が示されています。WebLogic Serverと一緒にサンプルをインストールした場合は、完全に機能するサンプル・コードも使用できます。サンプル・コードの実行手順については、インストールしたWebLogic Serverのsamples/examples/jsp/tagext/form_validation/package.htmlを参照してください。

例15-2 WebLogic JSPフォーム検証タグとJSP

<%@ taglib uri="tagl" prefix="wl" %>
<%@ taglib uri="input" prefix="input" %>

<wl:summary
name="summary"
headerText="<font color=red>Some fields have not been filled out correctly.</font>"
redirectPage="successPage.jsp"
>

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF">

<% if(summary.size() >0 )   {
out.println("<h3>" + headerText + "</h3>");
} %>

<% if (summary.size() > 0) {
out.println("<H2>Error Summary:</h2>");
for (int i=0; i < summary.size(); i++) {
out.println((String)summary.elementAt(i));
out.println("<br>");
}
} %>

<wl:form method="GET" action="successPage.jsp">

User Name: <input:text name="username"/>
<wl:validator
fieldToValidate="username"
validatorClass="weblogicx.jsp.tags.validators.RequiredFieldValidator"
errorMessage="User name is a required field!"
>
<img src=images/warning.gif> This is a required field!
</wl:validator>

<p>

Password: <input type="password" name="password">
<wl:validator
fieldToValidate="password"
validatorClass="weblogicx.jsp.tags.validators.RequiredFieldValidator"
errorMessage="Password is a required field!"
>
<img src=images/warning.gif> This is a required field!
</wl:validator>

<p>

Re-enter Password: <input type="password" name="password2">
<wl:validator
fieldToValidate="password,password2"
validatorClass="weblogicx.jsp.tags.validators.CompareValidator"
errorMessage="Passwords don't match"
>
<img src=images/warning.gif> Passwords don't match.
</wl:validator>

<p>

<input type="submit" value="Submit Form">  </p>

</wl:form>

</wl:summary>

</body>
</html>

16 カスタムWebLogic JSPタグ(cache、process、repeat)の使用方法

次の項では、WebLogic Server配布キットで提供される3つのカスタムJSPタグ(cacheタグ、repeatタグ、processタグ)の使用方法について説明します。

- WebLogicカスタムJSPタグの概要

- WebアプリケーションでのWebLogicカスタム・タグの使用方法

- cacheタグ

- processタグ

- repeatタグ

WebLogicカスタムJSPタグの概要

Oracleでは、JSPページで使用できる特殊なJSPタグとして、cache、repeat、およびprocessの3つを提供しています。これらのタグは、weblogic-tags.jarというタグ・ライブラリjarファイルにパッケージされています。このjarファイルには、タグのクラスとタグ・ライブラリ記述子(TLD)が含まれています。これらのタグを使用するには、JSPを格納するWebアプリケーションにこのjarファイルをコピーして、タグ・ライブラリをJSPで参照します。

WebアプリケーションでのWebLogicカスタム・タグの使用方法

WebLogicカスタム・タグを使用するには、タグをWebアプリケーションに入れる必要があります。

これらのタグをJSPで使用するには:

1. WebLogic Serverのextディレクトリのweblogic-tags.jarファイルを、WebLogicカスタム・タグを使用するJSPが格納されているWebアプリケーションのWEB-INF/libディレクトリにコピーします。

2. このタグ・ライブラリ記述子を、Java EE標準Webアプリケーション・デプロイメント記述子(web.xml)の<taglib>要素で参照します。例:

<taglib>
<taglib-uri>weblogic-tags.tld</taglib-uri>
<taglib-location>
/WEB-INF/lib/weblogic-tags.jar
</taglib-location>
</taglib>

3. taglibディレクティブを使用して、JSP内でタグ・ライブラリを参照します。例:

<%@ taglib uri="weblogic-tags.tld" prefix="wl" %>

cacheタグ

cacheタグは、タグの本体内で行われた処理のキャッシングを有効にします。このタグは、出力(変換)データと入力(計算済み)データの両方をサポートします。出力キャッシングとは、タグ内のコードによって生成されたコンテンツを指します。入力キャッシングとは、タグ内のコードによって設定される変数の値を指します。出力キャッシングは、コンテンツの最終的な形式をキャッシュする必要がある場合に便利です。入力キャッシングは、タグ内で計算されるデータと無関係にデータ表示が変化する場合に有用です。

あるクライアントがキャッシュのコンテンツを再計算しているときに、別のクライアントが同じコンテンツをリクエストした場合には、再計算の完了を待つことなく、すでにキャッシュ内にある情報が表示されます。これは、キャッシュの再計算が原因で、すべてのユーザーに対してWebサイトが停止することを回避するための仕組みです。さらに、async属性を使用して、すべてのユーザー(キャッシュの再計算を開始したユーザーも含む)に対して再計算の完了を待たないことを指定できます。

2つのバージョンのcacheタグを使用できます。バージョン2にはスコープが追加されています。

キャッシュのリフレッシュ

_cache_refreshオブジェクトをtrueに設定することで、対象とするスコープ内で強制的にキャッシュをリフレッシュできます。セッション・スコープでキャッシュをリフレッシュするには、次のように指定します。

<% request.setAttribute("_cache_refresh", "true"); %>

すべてのキャッシュをリフレッシュする場合は、キャッシュをapplicationスコープに設定します。ユーザー向けのすべてのキャッシュをリフレッシュする場合は、キャッシュをsessionスコープに設定します。現在のリクエスト内のすべてのキャッシュをリフレッシュする場合は、_cache_refreshオブジェクトをパラメータとして設定するか、リクエスト内に設定します。

<wl:cache>タグには、表示されるたびに更新する必要のあるコンテンツを指定します。<wl:cache>タグと</wl:cache>タグで囲まれた文は、キャッシュが期限切れになるか、key属性値(表「cacheタグの属性」を参照)が変更された場合にのみ実行されます。

キャッシュのフラッシュ

キャッシュをフラッシュするとキャッシュされた値が強制的に消去され、次にキャッシュがアクセスされたときに値が再計算されます。キャッシュをフラッシュするには、flush属性をtrueに設定します。キャッシュには、name属性を使用して名前を付ける必要があります。キャッシュにsize属性が設定されている場合は、すべての値がフラッシュされます。キャッシュにkey属性が設定されていてsize属性が設定されていない場合は、キャッシュを一意に識別するために必要なその他の属性(scopeやvarsなど)とともにそのkey属性を指定すると、特定のキャッシュをフラッシュできます。

例:

1. キャッシュを定義します。

<wl:cache name="dbtable" key="parameter.tablename"
scope="application">
// read the table and output it to the page
</wl:cache>

2. キャッシュされた表データを更新します。

3. 空タグ(/で終了し、終了タグを使用しない)でflush属性を使用して、キャッシュをフラッシュします。次に例を示します。

<wl:cache name="dbtable" key="parameter.tablename" scope="application" flush="true"/>

表16-1 cacheタグの属性

属性

必須

デフォルト値

説明

timeout

no

-1

キャッシュ・タイムアウト・プロパティ。cacheタグ内の文がリフレッシュされるまでの時間(秒単位)。この属性はプロアクティブではなく、この値はリクエスト時にのみリフレッシュされます。秒単位より時間単位の方がよい場合は、使用する単位を値の後に付けて指定できます。

- ms = ミリ秒

- s = 秒(デフォルト)

- m = 分

- h = 時間

- d = 日

scope

no

application

データをキャッシュするスコープを指定します。有効なスコープは次のとおりです。

- parameter、(バージョン1、2) HTTPサーブレット・リクエストのパラメータをリクエストします

- page、(バージョン1、2) JSPページ・コンテキストの属性をリクエストします(キャッシュ・フィルタにはこのスコープは存在しません。)

- request、(バージョン1、2)サーブレット・リクエストの属性をリクエストしますリクエスト属性は、転送またはインクルードされたページを含め、リクエスト全体に対して有効です。

- Cookie、(バージョン2)リクエスト内で見つかったCookieの値をリクエストします。同じ名前のCookieが複数ある場合、このリクエストは最初の値のみを戻します。

- requestHeader、(バージョン2)リクエストのヘッダーにある値をリクエスト。同じ名前のヘッダーが複数ある場合、最初のヘッダーの値のみを戻します。

scope

(続き)

- responseHeader、(バージョン2)レスポンスのヘッダーにある値をリクエストします。同じ名前のヘッダーが複数ある場合、最初のヘッダーの値のみを戻します。レスポンスのヘッダーを設定すると、すべてのレスポンスのヘッダーが設定した値で置き換えられます。このスコープをコンテンツの格納に使用しないでください。

- session、(バージョン1、2)現在のユーザーのセッション属性の値をリクエストします。セッションがない場合、このスコープにアクセスしてもセッションは作成されません。コンテンツをキャッシュしている場合はキャッシュが非常に大きくなることがあります。

- application、(バージョン1、2)サーブレットのコンテキスト属性に含まれる値をリクエストします。

- cluster、(バージョン1、2)アプリケーション・スコープの値をリクエスト。書込みがあった場合はクラスタ全体に情報をレプリケートします。

ほとんどのキャッシュは、sessionまたはapplicationスコープになります。

key

no

--

タグ内に格納されている値をキャッシュするかどうかを評価する際に使用する値を指定します。通常、ある特定のキャッシュは、web.xmlで構成したキャッシュ名によって識別されます。キャッシュ名が指定されていない場合、リクエストのURIがキャッシュ名として使用されます。キーを使用して、タグを識別するための追加の値を指定できます。たとえば、指定したエンド・ユーザーのキャッシュを切り分ける場合は、キャッシュ名に加えて、ユーザーID、リクエスト・パラメータのスコープ(問合せパラメータ/ポスト・パラメータ)から選択する値、およびクライアントのIPアドレスとしてキーを指定できます。したがって、キーの指定は「parameter.userid,parameter.clientip」となります。ここで、「parameter」はスコープ(リクエスト・パラメータのスコープ)、「userid」と「clientip」はパラメータまたは属性。つまり、キャッシュの主キーがキャッシュ名(この場合はリクエストのURI) + useridリクエスト・パラメータ+ clientipリクエスト・パラメータとなります。

キーのリストはカンマで区切ます。この属性の値はキーとしてキャッシュに入れる値を持つ変数の名前となります。スコープ名を名前の前に付加することで、さらにスコープを指定できます。例:

parameter.key | page.key | request.key | application.key | session.key

デフォルトでは、上のリストの順でスコープ内を検索します。名前を付けた各キーは、cacheタグ内でスクリプト変数として使用可能となります。キーのリストはカンマで区切ります。

async

no

false

asyncパラメータをtrueに設定すると、可能であれば、キャッシュは非同期で更新されます。キャッシュ・ヒットを開始するユーザーには古いデータが表示されます。

name

no

--

複数のJSPページ間でキャッシュを共有可能とする一意のキャッシュの名前。同じバッファが、名前を付けたキャッシュを使用するすべてのページのデータを格納するために使用されます。この属性は、キャッシュを共有する必要があり、本文をインクルードされるページで有用。この属性が設定されていない場合、一意の名前がキャッシュに割り当てられます。

keyの機能はどんな場合にも同じように使用できるので、タグの名前を手動で算出することは避けます。名前は、weblogic.jsp.tags.CacheTagにURIを加え、さらにキャッシュするページ内のタグを表すために生成された番号を加えて算出されます。別々のURIが同じJSPページに達する場合、キャッシュはデフォルトでは共有されません。名前付きのキャッシュはこうした場合に使用します。

システムで名前が指定されているキャッシュは、自動的にフラッシュしてリフレッシュすることはできません。

size

no

-1 (無制限)

キーを使用するキャッシュごとに許可されるエントリの数。デフォルトでは、キーのキャッシュを制限しません。キーの数を制限すると、タグはキャッシュに指示するために最小使用頻度方式(least-used system)を使用します。使用中のキャッシュのsize属性の値を変更しても、そのキャッシュのサイズは変わりません。

vars

no

--

変換されたキャッシュの出力をキャッシュするのみでなく、算出された値もブロック内にキャッシュできます。これらの変数はキャッシュ・キーと正確に同じように指定します。このタイプのキャッシュ処理を入力キャッシュ処理といいます。

入力キャッシングを実行するために変数が使用されます。キャッシュ取得時に変数は指定したスコープに復元されます。たとえば、データベースから結果を取得するために、リクエスト・パラメータのvar1およびセッションのvar2を使用したとします。キャッシュ作成時、これらの変数の値がキャッシュに格納されます。次回のキャッシュへのアクセス時、これらの値が復元されるため、個々の値のスコープからアクセスが可能です。たとえば、var1はリクエストから、var2はセッションから取得できます。

flush

いいえ

なし

trueに設定すると、キャッシュがフラッシュされます。この属性は、空タグ(/で終了)内で設定する必要があります。

バージョン2のキャッシュ・システムの追加プロパティ

- 各キャッシュには、キャッシュに関連付けられる任意の属性が追加されています。そうした属性はエンド・ユーザーによる操作が可能であり、キャッシュ取得時に指定できます。

- キャッシュ・システムの任意のスコープにあるjava.util.Listの「weblogicx.cache.CacheListener」キーに、weblogicx.cache.CacheListenerを実装するオブジェクトを配置して、キャッシュのリスナーを登録できます。スコープ内にListがある場合は、その末尾にリスナーを追加します。

次の例では、<wl:cache>タグの使用方法を示します。

例16-1 cacheタグの使用方法の例

<wl:cache>
<!--the content between these tags will only be
refreshed on server restart-->
</wl:cache>

<wl:cache key="request.ticker" timeout="1m">
<!--get stock quote for whatever is in the request parameter ticker
and display it, only update it every minute-->
</wl:cache>

<!--incoming parameter value isbn is the number used to lookup the
book in the database-->
<wl:cache key="parameter.isbn" timeout="1d" size="100">
<!--retrieve the book from the database and display
the information -- the tag will cache the top 100
most accessed book descriptions-->
</wl:cache>

<wl:cache timeout="15m" async="true">
<!--get the new headlines from the database every 15 minutes and
display them-->
<!--do not let anyone see the pause while they are retrieved-->
</wl:cache>

processタグ

<wl:process>タグは、問合せパラメータ・ベースのフロー制御用に使用します。このタグの4つの属性を組み合わせて使用することで、<wl:process>タグと</wl:process>タグに囲まれた文を選択的に実行できます。processタグは、フォームの送信結果を説明を付けて処理する場合にも使用できます。リクエスト・パラメータの値を基に条件を指定することで、JSP構文をページに含めるかどうかを指定できます。

表16-2 processタグの属性

タグ属性

必須

説明

name

いいえ

問合せパラメータの名前

notname

いいえ

問合せパラメータの名前

value

いいえ

問合せパラメータの値

notvalue

いいえ

問合せパラメータの値

次の例では、<wl:process>タグの使用方法を示します。

例16-2 processタグの使用方法の例

<wl:process notname="update">
<wl:process notname="delete">
<!--Only show this if there is no update or delete parameter-->
<form action="<%= request.getRequestURI() %>">
<input type="text" name="name"/>
<input type="submit" name="update" value="Update"/>
<input type="submit" name="delete" value="Delete"/>
</form>
</wl:process>
</wl:process>
<wl:process name="update">
<!-- do the update -->
</wl:process>

<wl:process name="delete">
<!--do the delete-->
</wl:process>
<wl:process name="lastBookRead" value="A Man in Full">
<!--this section of code will be executed if lastBookRead exists
and the value of lastBookRead is "A Man in Full"-->
</wl:process>

repeatタグ

<wl:repeat>タグは、列挙値、イテレータ、コレクション、オブジェクト配列、ベクトル、結果セット、結果セット・メタデータ、およびハッシュ表キーなど、様々なタイプの集合に対して処理を繰り戻す場合に使用します。また、count属性を使用して、一定回数のみループすることもできます。Javaオブジェクトのタイプを指定するには、set属性を使用します。

表16-3 repeatタグの属性

タグ属性

必須

タイプ

説明

set

いいえ

Object

以下を含むオブジェクトの集合。

- 列挙値

- イテレータ

- コレクション

- 配列

- ベクトル

- 結果セット

- 結果セット・メタデータ

- ハッシュ表キー

count

いいえ

Int

集合内で最初のcountエントリに対して処理を繰り戻します。

id

いいえ

String

反復処理の対象となる現在のオブジェクトを格納する変数。

type

いいえ

String

渡された集合に対して処理を繰り返して得られるオブジェクトの型。デフォルトはObjectです。この型は完全修飾である必要があります。

次の例では、<wl:repeat>タグの使用方法を示します。

例16-3 repeatタグの使用方法の例

<wl:repeat id="name" set="<%= new String[] { "sam", "fred", "ed" } %>">
<%= name %>
</wl:repeat>

<% Vector v = new Vector();%>
<!--add to the vector-->

<wl:repeat id="item" set="<%= v.elements() %>">
<!--print each element-->
</wl:repeat>

17 WebLogic EJB-to-JSP統合ツールの使用方法

次の項では、WebLogic EJB-to-JSP統合ツールを使用して、JavaServer Page (JSP)でEJBを呼び出すためのJSPタグ・ライブラリを作成する方法について説明します。ここでは、読者が少なくともEJBとJSPの両方についてある程度の知識を持っていることを前提としています。

- WebLogic EJB-to-JSP統合ツールの概要

- 基本的な処理

- インタフェース・ソース・ファイル

- 「Build Options」パネル

- トラブルシューティング

- JSPページでのEJBタグの使用方法

- EJBホーム・メソッド

- ステートフル・セッションBeanとエンティティBean

- デフォルト属性

WebLogic EJB-to-JSP統合ツールの概要

EJB jarファイルを使用する場合、WebLogic EJB-to-JSP統合ツールでJSPタグ拡張ライブラリを生成します。このライブラリのタグは、そのjarファイルのEJBを呼び出すようにカスタマイズされます。クライアントから見た場合、EJBはそのリモート・インタフェースによって表されます。例:

public interface Trader extends javax.ejb.EJBObject {
public TradeResult buy(String stockSymbol, int shares);
public TradeResult sell(String stockSymbol, int shares);
}

EJBを呼び出すWebアプリケーションの場合、JSPスクリプトレット(<% ... %>)内からJavaコードを使用してEJBを呼び出すのが一般的な方法です。EJB呼出しの結果はHTMLとしてフォーマット化され、Webクライアントに提供されます。このアプローチは面倒で、エラーを引き起こしやすくなります。EJBの呼出しに必要なJavaコードは最も単純なケースでも非常に長く、HTML表現を担当するほとんどの設計者のスキルを超えています。

EJB-to-JSPツールは、Javaコードの必要性を排除することによって、EJB呼出しプロセスを簡素化します。かわりに、EJB用にカスタム生成されるJSPタグ・ライブラリを使用して、EJBを呼び出します。たとえば、上のTrader Beanのメソッドは、次のようにJSPで呼び出されます。

<%@ taglib uri="/WEB-INF/trader-tags.tld" prefix="trade" %>
<b>invoking trade: </b><br>

<trade:buy stockSymbol="BEAS" shares="100"/>

<trade:sell stockSymbol="MSFT" shares="200"/>

この結果として生成されるJSPページは、より明確で直感的に理解できます。タグはEJBの各メソッドに対して(オプションで)生成されます。これらのタグは、対応するEJBメソッド呼出し用のパラメータに変換される属性を取ります。EJB呼出しの面倒な機構は隠され、生成されるタグ・ライブラリのハンドラ・コードの内部にカプセル化されます。生成されるタグ・ライブラリは、ステートレス・セッションBeanとステートフル・セッションBean、およびエンティティBeanをサポートします。これらのケースでは、タグの使用方法にそれぞれ若干の相違があります(後述の説明を参照)。

基本的な処理

WebLogic EJB-to-JSP統合ツールは、コマンド・ライン・モードで、次のコマンドを使用して実行できます。

java weblogic.servlet.ejb2jsp.Main

またはグラフィカル・モードで次のようにします。最も単純なEJB以外は、グラフィカル・ツールを使用する方法が適しています。

次のようにグラフィカル・ツールを呼び出します。

java weblogic.servlet.ejb2jsp.gui.Main

最初は、Webアプリケーションによってejb2jspプロジェクトがロードされません。新しいプロジェクトを作成するには、「ファイル」>「新規」メニューを選択し、ファイル選択欄を参照してEJB jarファイルを見つけ、そのファイルを選択します。初期化が済んだら、ejb2jspプロジェクトを修正、保存、および再ロードできます。

生成されるタグ・ライブラリの構成は単純です。jarファイル内のEJBのメソッドごとに、そのメソッドと同名のJSPタグが生成されます。各タグには、対応するメソッドのパラメータと同数の属性を指定できます。

インタフェース・ソース・ファイル

新しいEJB jarがロードされると、統合ツールはEJBのホーム・インタフェースとリモート・インタフェース用のJavaソース・ファイルを見つけようとします。これは、変換ツールはEJBクラスを参照するのみでタグを生成できますが、それらのタグ(対応するEJBメソッドがパラメータを取る)に意味のある属性名を割り当てることができないからです。「WebLogic EJB-to-JSP統合ツールの概要」のTraderの例では、EJB jarがロードされると、変換ツールはTrader.javaというソース・ファイルを探します。続いてこのファイルが解析され、buy()メソッドがstockSymbolおよびsharesパラメータを取ることが検出されます。これにより、対応するJSPタグは適切な名前が付けられた属性(buy()メソッドのパラメータに対応する)を持つようになります。

新しいEJB jarがロードされると、変換ツールは、EJB jarが存在するディレクトリとソース・ディレクトリが同じであるという前提で動作します。この前提に当てはまらない場合でも、エラーは致命的ではありません。新しいプロジェクトのロード後に、「プロジェクト・ビルド・オプション」パネルで、「EJBソース・パス」要素を調節して適切なディレクトリを指定できます。次に、「ファイル」>「属性の解決」メニューを選択して、解決プロセスを再実行します。

インタフェース・クラスに対応するjavaソース・ファイルを探すときに、統合ツールは指定されたディレクトリと、そのインタフェースのJavaパッケージによって示唆されるサブディレクトリの両方を検索します。たとえば、my.ejb.Traderの場合、指定されたディレクトリがC:/srcであれば、統合ツールはC:/src/Trader.javaとC:/src/my/ejb/Trader.javaの両方を検索します。

ソース・ファイルへのアクセスは必須ではありません。統合ツールを使用することにより、プロジェクトの各タグの属性名を常に変更できます。しかし、EJBのパブリック・インタフェースのソース・ファイルの解析は、意味のある属性名を割り当てるための最も迅速な方法として開発されました。

「ビルド・オプション」パネル

このパネルは、プロジェクトの構築に必要なローカル・ファイル・システムに関連するすべてのパラメータを設定するために使用します。Javaコンパイラ、生成されるJSPタグ・ハンドラのJavaパッケージ、およびプロジェクト構築後に生成されるJavaコードを保持するかどうか(デバッグに役立つ)を指定します。

また、このパネルでは、タグ・ライブラリ出力の種類を指定できます。Java EE Webアプリケーションで使用する場合、タグ・ライブラリは次の2通りの方法のいずれかでパッケージ化する必要があります。1つは別個のクラス・ファイルとタグ・ライブラリ記述子(.tld)ファイルで、もう1つは単一のtaglib jarファイルです。いずれかの出力タイプを「出力タイプ」プルダウン・メニューで選択します。開発およびテストのためには、DIRECTORY出力をお薦めします。jarファイルは、WebLogic ServerのWebアプリケーションを再デプロイしなければ上書きできないからです。

DIRECTORYまたはJARのいずれかについて、出力先を適切に選択して、タグ・ライブラリがWebアプリケーションによって検索されるようにします。たとえば、ディレクトリC:/mywebappをルートとするWebアプリケーションでタグ・ライブラリを使用する場合、「DIRECTORYクラス」フィールドには次のように指定する必要があります。

C:/mywebapp/WEB-INF/classes

また、「DIRECTORY .tldファイル」フィールドには次のように指定する必要があります。

C:/mywebapp/WEB-INF/trader-ejb.tld

前述のソース・パスも「ビルド・オプション」パネルで編集します。タグ・ライブラリがコアWebLogic ServerまたはJava EE APIに存在しない他のクラスに依存する場合は、「追加クラスパス」フィールドを使用できます。通常、このフィールドには何も追加する必要はありません。

トラブルシューティング

エラーや競合によって、プロジェクトの構築に失敗する場合があります。この項では、これらのエラーの理由と解決方法について説明します。

- 構築情報の欠落: 「ビルド・オプション」パネル内の必須フィールドの1つに、javaコンパイラ、コード・パッケージ名、出力の保存先ディレクトリなどの値が指定されていない場合です。未指定のフィールドに値を指定しないと、構築を正常に行うことができません。

- タグ名の重複: EJB jarがロードされると、統合ツールはEJBのメソッドごとにタグを記録します。このタグ名は、メソッド名と同じです。EJBがオーバーロード・メソッド(同名だがシグネチャが異なるメソッド)を持っている場合、タグ名が競合します。この競合を解決するには、これらのタグのいずれかの名前を変更するか、これらのタグの1つを無効にします。タグ名を変更するには、統合ツールの左ウィンドウのツリー階層を使用して問題のタグに移動します。右ウィンドウに表示されるタグ・パネルで、タグ名フィールドを変更します。タグを無効にするには、統合ツールの左ウィンドウのツリー階層を使用して問題のタグに移動します。右ウィンドウに表示されるタグ・パネルで、「タグの生成」ボックスの選択を解除します。EJB jarに複数のEJBが含まれている場合、Bean全体についてタグを無効にすることもできます。

- 意味のない属性名arg0、arg1...: このエラーは、タグの妥当な属性名がEJBのインタフェース・ソース・ファイルから推測できない場合に発生します。このエラーを修復するには、プロジェクトの階層ツリーで問題のタグに移動します。次に、そのタグの下にある各属性ツリー・リーフを選択します。各属性について、ツールの右側に表示されるパネルの属性名フィールドに適切な名前を入力します。

- 属性名の重複: これは、複数の属性を指定できる1つのタグに同名の属性が2つ存在する場合に発生します。問題の属性に移動して、そのタグでそれぞれ一意になるよう名前を変更します。

JSPページでのEJBタグの使用方法

生成されたEJBタグをJSPページで使用するには、そのページでタグ・ライブラリを宣言し、他のタグ拡張と同じようにそのタグを呼び出します。

<% taglib uri="/WEB-INF/trader-ejb.tld"
prefix="trade" %>
<trade:buy stockSymbol="XYZ" shares="100"/>

void以外の戻り値の型を持つEJBメソッドのために、「_return」という特別なオプションのタグ属性が組み込まれています。このタグが存在する場合、このメソッドから返される値は将来の処理のためにページ上で使用できます。

<% taglib uri="/WEB-INF/trader-ejb.tld"
prefix="trade" %>
<trade:buy stockSymbol="XYZ"
shares="100" _return="tr"/>
<% out.println("trade result: " + tr.getShares()); %>

プリミティブ数値型を戻すメソッドの場合、返される変数は、その型に対応するJavaオブジェクトです(「int」-> java.lang.Integer、など)。

EJBホーム・メソッド

EJB 2.0では、EJBホーム・インタフェースのメソッド(create()またはfind()以外)を使用できます。これらのホーム・インタフェース用のタグも生成されます。混乱を避けるため、新規プロジェクトがロードされるときに、EJBのホームの各メソッドに対応するタグの先頭に「home-」という文字列が付加されます。必要な場合は、これらのメソッドの名前を変更できます。

ステートフル・セッションBeanとエンティティBean

「ステートフル」なBeanの一般的な用途は、Beanのホーム・インタフェースからそのインスタンスを取得し、単一のBeanインスタンスの複数のメソッドを呼び出すことです。このプログラミング・モデルも、生成されるタグ・ライブラリに保存できます。ステートフルEJBメソッド用のメソッド・タグは、EJBホーム・インタフェースの(そのホームのfind()またはcreate()に対応する)タグの内部に配置する必要があります。find/createタグの内部に存在するすべてのEJBメソッド・タグは、終了タグによって検索または作成されるBeanインスタンスで処理されます。ステートフルBeanのメソッド・タグがそのホームのfind/createタグで閉じられていない場合、実行時例外が発生します。たとえば、次のEJBが存在するとします。

public interface AccountHome extends EJBHome {

public Account create(String accountId, double initialBalance);
public Account findByPrimaryKey(String accountID);
/* find all accounts with balance above some threshold */
public Collection findBigAccounts(double threshold);
}

public interface Account extends EJBObject {
public String getAccountID();
public double deposit(double amount);
public double withdraw(double amount);
public double balance();
}
Correct tag usage might be as follows:
<% taglib uri="/WEB-INF/account-ejb.tld" prefix="acct" %>
<acct:home-create accountId="103"
initialBalance="450.0" _return="newAcct">
<acct:deposit amount="20"/>
<acct:balance _return="bal"/>
Your new account balance is: <%= bal %>
</acct:home-create>

find/createタグで「_return」属性が指定されている場合、検索/作成されたEJBインスタンスを参照するページ変数が作成されます。エンティティBeanの検索メソッドも、EJBインスタンスのコレクションを戻す場合があります。Beanのコレクションを戻すメソッドを呼び出すホーム・タグは、そのコレクションのBeanごとにタグ本体で繰り返されます。「_return」が指定されている場合、それはその繰返しの内部の現在のBeanに設定されます。

<b>Accounts above $500:</b>
<ul>
<acct:home-findBigAccounts threshold="500" _return="acct">
<li>Account <%= acct.getAccountID() %>
has balance $<%= acct.balance() %>
</acct:home-findBigAccounts>
</ul>

上の例では、残高が$500を超えるすべての口座BeanのHTMLリストが表示されます。

デフォルト属性

デフォルトでは、各メソッドのタグでは、そのすべての属性(メソッド・パラメータ)が各タグ・インスタンスに設定される必要があります。しかし、統合ツールでは、JSPタグに属性が指定されていない場合に備えて、「デフォルト」のメソッド・パラメータを指定することもできます。デフォルトの属性/パラメータは、EJB-to-JSPツールの属性ウィンドウで指定できます。パラメータのデフォルトは、単純なEXPRESSIONから取得されるか、より複雑な処理が必要な場合、デフォルトMETHOD本文が記述されます。たとえば、「WebLogic EJB-to-JSP統合ツールの概要」のTraderの例で、何も指定されていない場合、銘柄記号"XYZ"に対して"buy"タグを動作させるとします。この場合、"buy"タグの"stockSymbol"属性の属性パネルで、デフォルト属性値フィールドをEXPRESSIONに設定し、デフォルト式フィールドに"XYZ" (引用符を含む)と入力します。その結果、他の値が指定されていなければ、buyタグはstockSymbol="XYZ"属性が存在するかのように動作します。

また、"buy"タグのshares属性を0 - 100のランダムな数値にしたい場合、デフォルト属性値をMETHODに設定し、デフォルト・メソッド本文の領域に、int型("buy"メソッドの"shares"属性に対応する型)を戻すJavaメソッドの本文を記述します。

long seed = System.currentTimeMillis();
java.util.Random rand = new java.util.Random(seed);
int ret = rand.nextInt();
/* ensure that it is positive...*/
ret = Math.abs(ret);
/* and < 100 */
return ret % 100;

デフォルトのメソッド本文はJSPタグ・ハンドラの内部に現れるため、作成するコードはpageContext変数にアクセスできます。JSP PageContextから、現在のHttpServletRequestまたはHttpSessionへのアクセスを取得し、セッション・データまたはリクエスト・パラメータを使用してデフォルト・メソッド・パラメータを生成できます。たとえば、ServletRequestパラメータから"buy"メソッドの"shares"パラメータを取得するには、次のコードを記述します。

HttpServletRequest req =
(HttpServletRequest)pageContext.getRequest();
String s = req.getParameter("shares");
if (s == null) {
/* webapp error handler will redirect to error page
* for this exception
*/
throw new BadTradeException("no #shares specified");
}
int ret = -1;
try {
ret = Integer.parseInt(s);
} catch (NumberFormatException e) {
throw new BadTradeException("bad #shares: " + s);
}
if (ret <= 0)
throw new BadTradeException("bad #shares: " + ret);
return ret;

生成されるデフォルト・メソッドは例外をスローするものと見なされます。処理中に発生した例外は、JSPのerrorPageによって処理されるか、Webアプリケーションの登録済例外処理ページによって処理されます。

A web.xmlデプロイメント記述子の要素

次の項では、web.xmlスキーマのルート要素<web-app>の下に定義するデプロイメント記述子の要素について説明します。

Java EEアノテーションの使用により、標準のweb.xmlデプロイメント記述子は省略可能になりました。Servlet 2.5仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html)では、サーブレット、フィルタ、リスナー、タグ・ハンドラなどの特定のWebコンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存関係を宣言できます。第8章「Webコンポーネント用のWebLogicアノテーション」を参照してください。

- web.xmlのネームスペース宣言とスキーマの場所

- icon

- display-name

- description

- distributable

- context-param

- filter

- filter-mapping

- listener

- servlet

- servlet-mapping

- session-config

- mime-mapping

- welcome-file-list

- error-page

- jsp-config

- resource-env-ref

- resource-ref

- security-constraint

- login-config

- security-role

- env-entry

- ejb-ref

- ejb-local-ref

- web-app

web.xmlのネームスペース宣言とスキーマの場所

web.xmlファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">

web.xmlのスキーマについては、http://java.sun.com/xml/ns/javaee/web-app_2_5.xsdを参照してください。

icon

icon要素では、GUIツールでWebアプリケーションを表示する場合に使用される画像(小さいアイコンと大きいアイコン)の、Webアプリケーション内での位置を指定します(servlet要素にもiconという要素があり、GUIツール内でサーブレットを表すアイコンを提供するために使用されます。)

次の表では、icon要素内で定義できる要素について説明します。

表A-1 icon要素

要素

必須/省略可能

説明

<small-icon>

省略可能

GUIツールでWebアプリケーションを表すために使用される、小さい(16x16ピクセル) .gif画像または.jpg画像の位置。この要素は現在、WebLogic Serverでは使用されていません。

<large-icon>

省略可能

GUIツールでWebアプリケーションを表すために使用される、、大きい(32x32ピクセル) .gif画像または.jpg画像の位置。この要素は現在、WebLogic Serverでは使用されていません。

display-name

省略可能なdisplay-name要素では、Webアプリケーションの表示名(GUIツールで表示できる短い名前)を指定します。

表A-2 display-name要素

要素

必須/省略可能

説明

<display-name>

省略可能

この要素は現在、WebLogic Serverでは使用されていません。

description

省略可能なdescription要素では、Webアプリケーションに関する説明文を示します。

表A-3 description要素

要素

必須/省略可能

説明

<description>

省略可能

この要素は現在、WebLogic Serverでは使用されていません。

distributable

distributable要素は、WebLogic Serverでは使用されていません。

表A-4 description要素

要素

必須/省略可能

説明

<distributable>

省略可能

この要素は現在、WebLogic Serverでは使用されていません。

context-param

context-param要素には、Webアプリケーションのサーブレット・コンテキストの初期化パラメータの宣言が含まれます。

表A-5 context-param要素

要素

必須/省略可能

説明

weblogic.httpd.
clientCertProxy

省略可能

この属性は、プロキシ・プラグインまたはHttpClusterServletによって送信される特別なWL-Proxy-Client-Certヘッダーに、Webアプリケーションのクライアントからの証明書を含めることを指定します。

この設定は、ユーザー認証がプロキシ・サーバーで実行される場合に役立ちます。clientCertProxyを設定すると、プロキシ・サーバーによりWL-Proxy-Client-Certという特別なヘッダーでクラスタに証明書が渡されます。

WL-Proxy-Client-Certヘッダーは、WebLogic Serverにアクセスする、どのクライアントでも指定できます。WebLogic Serverは、安全なソース(プラグイン)からのものであることを信用してヘッダーの証明書情報を受け取り、その情報を使用してユーザーを認証します。

このため、clientCertProxyを設定した場合は、接続フィルタを使用して、このプラグインが実行しているマシンからの接続のみをWebLogic Serverが受け入れるようにする必要があります。

この属性は、個々のWebアプリケーションに設定するのみでなく、次のように定義することもできます。

サーバー・インスタンスを利用するすべてのWebアプリケーションに対して、管理コンソールの「サーバー」>「構成」>「全般」ページで設定します。クラスタ内のサーバー・インスタンスを利用するすべてのWebアプリケーションに対して、「クラスタ」>「構成」>「全般」ページで設定します。

次の表では、Webアプリケーション・コンテナで使用される予約済みのコンテキスト・パラメータについて説明します。これらは非推奨となり、weblogic.xmlで置き換えられました。

表A-6 非推奨のcontext-param要素

非推奨のパラメータ

説明

weblogic.xmlでの代替要素

weblogic.httpd.inputCharset

Unicode以外の処理でコード・セット動作を定義します。

weblogic.xmlのinput-charset (charset-param内で定義)。「input-charset」を参照してください。

weblogic.httpd.servlet.reloadCheckSecs

サーブレットが変更されたかどうかをチェックする頻度と、変更されている場合はそれを再ロードするかどうかを定義します。値が -1の場合は再ロードせず、0の場合は常に再ロードします。デフォルトでは1秒に設定されます。

weblogic.xmlのservlet-reload-check-secs (container-descriptor内で定義)。「auth-filter」を参照してください。

weblogic.httpd.servlet.classpath

この値を設定すると、このパスがコンテナによってWebアプリケーションのクラスパスに追加されます。この方法は非推奨で、後方互換性のためのみにサポートされています。

なし。マニフェスト・クラスパス、WEB-INF/lib、WEB-INF/classes、仮想ディレクトリなどの方法を使用します。

weblogic.httpd.defaultServlet

Webアプリケーションのデフォルト・サーブレットを設定します。これは非推奨

方法で、後方互換性のためのみにサポートされています。

なし。web.xmlのservlet要素およびservlet-mapping要素を使用してデフォルト・サーブレットを定義します。default-servletのURLパターンは"/"。「servlet-mapping」を参照してください。サーブレット・マッピングのその他の例については、「サーブレット・マッピング」を参照してください。

filter

filter要素は、フィルタ・クラスとその初期化属性を定義します。フィルタの詳細は、「フィルタの構成」を参照してください。

次の表では、filter要素内で定義できる要素について説明します。

表A-7 filter要素

要素

必須/省略可能

説明

<icon>

省略可能

GUIツールでフィルタを表示する場合に使用される画像(小さいアイコンと大きいアイコン)の、Webアプリケーション内での位置を指定します。small-icon要素とlarge-icon要素があります。

この要素は現在、WebLogic Serverでは使用されていません。

<filter-name>

必須

フィルタの名前を定義します。この名前は、デプロイメント記述子内のほかの場所でそのフィルタ定義を参照する場合に使用されます。

<display-name>

省略可能

GUIツールによって表示されることを想定した短い名前。

<description>

省略可能

フィルタの説明文。

<filter-class>

必須

フィルタの完全修飾クラス名。

<init-param>

省略可能

フィルタの初期化属性の名前と値の組み合わせを指定します。

属性ごとに<init-param>タグの別個のセットを使用します。

filter-mapping

次の表では、filter-mapping要素内で定義できる要素について説明します。

表A-8 filter-mapping要素

要素

必須/省略可能

説明

<filter-name>

必須

URLパターンまたはサーブレットのマッピング先のフィルタの名前。この名前は、<filter-name>要素で<filter>要素に割り当てられている名前に対応します。

<url-pattern>

必須 - または<servlet>によってマップされる

URLを解決する場合に使用されるパターンを記述します。http://host:port (「host」はホスト名、「port」はポート番号) + ContextPathに続くURLの部分は、WebLogic Serverによって<url-pattern>と比較されます。パターンが一致すれば、この要素でマップされているフィルタが呼び出されます。

サンプル・パターンを次に示します。

/soda/grape/*
/foo/*
/contents
*.foo

URLは、Servlet仕様2.3で指定されているルールに準拠している必要があります。

<servlet>

必須 - または<url-pattern>によってマップされる

呼び出された場合に、このフィルタを実行するサーブレットの名前。

listener

listener要素を使用するアプリケーション・リスナーを定義します。

表A-9 listener要素

要素

必須/省略可能

説明

<listener-class>

省略可能

Webアプリケーション・イベントに応答するクラスの名前。

詳細は、「イベント・リスナー・クラスの構成」を参照してください。

servlet

servlet要素では、サーブレットの宣言的なデータを指定します。

jsp-file要素および<load-on-startup>要素が指定されている場合、そのJSPは、WebLogic Serverの起動時にあらかじめコンパイルされ、ロードされます。

次の表では、servlet要素内で定義できる要素について説明します。

表A-10 servlet要素

要素

必須/省略可能

説明

<icon>

省略可能

GUIツールでサーブレットを表示する場合に使用される画像(小さいアイコンと大きいアイコン)の、Webアプリケーション内での位置。small-icon要素とlarge-icon要素があります。

この要素は現在、WebLogic Serverでは使用されていません。

<servlet-name>

必須

サーブレットの標準名を定義します。この名前は、デプロイメント記述子内の他の場所でそのサーブレット定義を参照する場合に使用されます。

<display-name>

省略可能

GUIツールによって表示されることを想定した短い名前。

<description>

省略可能

サーブレットの説明文。

<servlet-class>

必須(または次を使用: <jsp-

file>)

サーブレットの完全修飾クラス名。

servletの本体では、<servlet-class>タグまたは<jsp-file>タグのいずれか一方のみを使用します。

<jsp-file>

必須(または次を使用: <servlet-

class>)

Webアプリケーションのルート・ディレクトリを基準にした、Webアプリケーション内のJSPファイルへのフルパス。

servletの本体では、<servlet-class>タグまたは<jsp-file>タグのいずれか一方のみを使用します。

<init-param>

省略可能

サーブレットの初期化属性の名前と値の組み合わせを指定します。

属性ごとに<init-param>タグの別個のセットを使用します。

<load-on-startup>

省略可能

この要素が指定されたサーブレットは、WebLogic Serverの起動時にWebLogic Serverによって初期化されます。この要素の省略可能なコンテンツは、サーブレットがロードされる順序を示す正の整数です。整数の小さい方から順にロードされます。値の指定がない、または値が正の整数でない場合は、WebLogic Serverによって、アプリケーションの起動時にある任意の順序でサーブレットがロードされます。

<run-as>

省略可能

Webアプリケーションの実行に使用するrun-as IDを指定します。この要素には、省略可能な説明とセキュリティ・ロールの名前が含まれます。

<security-role-
ref>

省略可能

<security-role>で定義されたセキュリティ・ロール名を、サーブレットのロジックでハード・コード化される代替ロール名にリンクする場合に使用されます。この特別な抽象化レイヤーによって、サーブレット・コードを変更しなくてもデプロイメント時にサーブレットを構成できるようになります。

icon

これは、servlet内の要素です。

icon要素では、GUIツールでWebアプリケーションを表示する場合に使用される画像(小さいアイコンと大きいアイコン)の、Webアプリケーション内での位置を指定します。

次の表では、icon要素内で定義できる要素について説明します。

表A-11 icon要素

要素

必須/省略可能

説明

<small-icon>

省略可能

GUIツールでサーブレットを表すために使用される、小さい(16x16ピクセル) .gif画像または.jpg画像のWebアプリケーション内での位置を指定します。

この要素は現在、WebLogic Serverでは使用されていません。

<large-icon>

省略可能

GUIツールでサーブレットを表すために使用される、大きい(32x32ピクセル) .gif画像または.jpg画像のWebアプリケーション内での位置を指定します。

この要素は現在、WebLogic Serverでは使用されていません。

init-param

これは、servlet内の要素です。

省略可能なinit-param要素では、サーブレットの初期化属性の名前と値の組み合わせを指定します。属性ごとにinit-paramタグの別個のセットを使用します。

javax.servlet.ServletConfig.getInitParameter()メソッドを使用して、これらの属性にアクセスできます。

次の表では、init-param要素内で定義できる要素について説明します。

表A-12 init-param要素

要素

必須/省略可能

説明

<param-name>

必須

この属性の名前を定義します。

<param-value>

必須

この属性のString値を定義します。

<description>

省略可能

初期化属性の説明文。

security-role-ref

これは、servlet内の要素です。

security-role-ref要素は、<security-role>で定義されたセキュリティ・ロール名を、サーブレットのロジックでハード・コード化される代替ロール名にリンクします。この特別な抽象化レイヤーによって、サーブレット・コードを変更しなくてもデプロイメント時にサーブレットを構成できるようになります。

次の表では、security-role-ref要素内で定義できる要素について説明します。

表A-13 security-role-ref要素

要素

必須/省略可能

説明

<description>

省略可能

ロールの説明文。

<role-name>

必須

サーブレット・コード内で使用されるセキュリティ・ロールまたはプリンシパルの名前を定義します。

<role-link>

必須

後にデプロイメント記述子内の<security-role>要素で定義されるセキュリティ・ロールの名前を定義します。

servlet-mapping

servlet-mapping要素では、サーブレットとURLパターンの間のマッピングを定義します。

次の表では、servlet-mapping要素内で定義できる要素について説明します。

表A-14 servlet-mapping要素

要素

必須/省略可能

説明

<servlet-name>

必須

URLパターンのマッピング先のサーブレットの名前。この名前は、<servlet>宣言タグでサーブレットに割り当てた名前に対応します。

<url-pattern>

必須

URLを解決する場合に使用されるパターンを記述します。http://host:port (「host」はホスト名、「port」はポート番号) + WebAppNameに続くURLの部分は、WebLogic Serverによって<url-pattern>と比較されます。パターンが一致すれば、この要素でマップされているサーブレットが呼び出されます。

サンプル・パターンを次に示します。

/soda/grape/*
/foo/*
/contents
*.foo

URLは、Servlet仕様2.3で指定されているルールに準拠している必要があります。

サーブレット・マッピングのその他の例については、「サーブレット・マッピング」を参照してください。

session-config

session-config要素では、Webアプリケーションのセッション属性を定義します。

次の表では、session-config要素内で定義できる要素について説明します。

表A-15 session-config要素

要素

必須/省略可能

説明

<session-timeout>

省略可能

このWebアプリケーション内のセッションが期限切れになるまでの分数。この要素で設定する値は、次に示す特殊な値のいずれか1つが入力されない限り、WebLogic固有のデプロイメント記述子であるweblogic.xmlの<session-descriptor>要素のTimeoutSecs属性に設定された値をオーバーライドします。

デフォルト値: 60

最大値: Integer.MAX_VALUE/60

特殊な値:

-1 = セッションはタイムアウトしません。weblogic.xmlの<session-descriptor>要素に設定された値は無視されます。

詳細は、「session-descriptor」を参照してください。

mime-mapping

mime-mapping要素では、拡張子とMIMEタイプの間のマッピングを定義します。

次の表では、mime-mapping要素内で定義できる要素について説明します。

表A-16 mime-mapping要素

要素

必須/省略可能

説明

<extension>

必須

拡張子を記述する文字列(例: txt)。

<mime-type>

必須

定義されているMIMEタイプを記述する文字列(例: text/plain)。

welcome-file-list

省略可能なwelcome-file-list要素では、welcome-file要素の順序付きリストを指定します。

URLリクエストがディレクトリ名の場合、WebLogic Serverは、この要素で指定された最初のファイルを処理します。そのファイルが見つからない場合、サーバーはリスト内の次のファイルを試します。

詳細は、「ウェルカム・ファイルの構成」を参照してください。

次の表では、welcome-file-list要素内で定義できる要素について説明します。

表A-17 welcome-file-list

要素

必須/省略可能

説明

<welcome-file>

省略可能

デフォルトのウェルカム・ファイルとして使用するファイル名(index.htmlなど)

error-page

省略可能なerror-page要素では、エラー・コードや例外のタイプとWebアプリケーションにあるリソースのパスの間のマッピングを指定します。

WebLogic ServerがHTTPリクエストに応答しているときにエラーが発生した場合や、Java例外の結果としてエラーが発生した場合は、WebLogic ServerによってHTTPエラー・コードまたはJavaエラー・メッセージのいずれかを表示するHTMLページが返されます。独自のHTMLページを定義して、これらのデフォルトのエラー・ページの代わりとして、またはJava例外のレスポンス・ページとして表示することができます。

詳細は、「HTTPエラー・レスポンスのカスタマイズ」を参照してください。

次の表では、error-page要素内で定義できる要素について説明します。

注意:

<error-code>と<exception-type>のどちらかを定義します。両方は定義しないでください。

表A-18 error-page要素

要素

必須/省略可能

説明

<error-code>

省略可能

有効なHTTPエラー・コード(例: 404)。

<exception-type>

省略可能

Java例外の完全修飾クラス名(例: java.lang.string)。

<location>

必須

エラーに応答して表示されるリソースの位置(例: /myErrorPg.html)。

jsp-config

jsp-config要素は、Webアプリケーション内のJSPファイルのグローバル構成情報を提供するために使用します。2つの下位要素taglibおよびjsp-property-groupがあります。

次の表では、jsp-config要素内で定義できる要素について説明します。

表A-19 jsp-config要素

要素

必須/省略可能

説明

<taglib>

省略可能

Webアプリケーション内のJSPページで使用するタグ・ライブラリに関する情報を提供します。

<jsp-property-group>

省略可能

複数のファイルをグループ化して、それらのファイルにグローバル・プロパティ情報を提供できるようにします。このように記述されたすべてのファイルはJSPファイルと見なされます。

taglib

これは、jsp-config内の要素です。

taglibは必須の要素で、Webアプリケーション内のJSPページで使用するタグ・ライブラリに関する情報を提供するために使用します。

JSPタグ・ライブラリ記述子(TLD)の位置をURIパターンに関連付けます。TLDは、WEB-INFディレクトリを基準にした相対位置にあるJSP内に指定できますが、Webアプリケーションをデプロイするときに、<taglib>タグを使用してTLDを構成することもできます。TLDごとに別個の要素を使用します。

次の表では、taglib要素内で定義できる要素について説明します。

表A-20 taglib要素

要素

必須/省略可能

説明

<taglib-location>

省略可能

Webアプリケーションのルートを基準にしたタグ・ライブラリ記述子の相対ファイル名を指定します。タグ・ライブラリ記述子ファイルをWEB-INFディレクトリの下に格納して、HTTPリクエストを通じて外部から入手できないようにするとよいでしょう。

<taglib-uri>

省略可能

web.xmlドキュメントの位置を基準にした相対位置にあるURIを指定します。このURIによって、Webアプリケーションで使用されるタグ・ライブラリが識別されます。

URIがJSPページのtaglibディレクティブで使用されているURI文字列と一致する場合、このタグ・ライブラリが使用されます。

jsp-property-group

これは、jsp-config内の要素です。

jsp-property-groupは必須の要素で、複数のファイルをグループ化して、それらのファイルにグローバル・プロパティ情報を提供できるようにするために使用します。このように記述されたすべてのファイルはJSPファイルと見なされます。

次の表で、jsp-property-group要素内に定義できる要素について説明します。

表A-21 jsp-property-group要素

要素

必須/省略可能

説明

<el-ignored>

省略可能

ELを無視するかどうかを制御します。ELの評価は、サーブレット2.4以降のweb.xmlを使用するWebアプリケーションではデフォルトで有効になっており、それ以外の場合は無効になっています。

<scripting-invalid>

省略可能

JSPページのグループで、スクリプト記述要素を無効にするかどうかを制御します。スクリプト記述は、デフォルトでは有効になっています。

<page-encoding>

省略可能

pageEncoding情報を示します。JSPページのページ・ディレクティブのpageEncoding属性と、そのページに一致するJSP構成要素との間で、エンコーディングが異なることを示す変換時エラー。XML構文内のドキュメントのプロログまたはテキスト宣言と、そのドキュメントに一致するJSP構成要素との間で、エンコーディングが異なることを示す場合もあります。複数のメカニズムに同じエンコーディングを指定しても構いません。

<is-xml>

省略可能

リソースがJSPドキュメント(XML)であることを示します。trueの場合は、URLパターンが一致するリソースのグループがJSPドキュメントで、XMLドキュメントとして解釈する必要があることを示します。falseの場合は、リソースがJSPドキュメントであることを示す他のプロパティ・グループがない限り、JSPドキュメントではないと見なされます。

<include-prelude>

省略可能

Webアプリケーション内の要素に対応している必要があるコンテキスト相対パス。この要素が存在する場合、指定されたパスが、このjsp-property-group内の各JSPページの最初に自動的に(includeディレクティブの場合のように)含まれます。

<include-coda>

省略可能

Webアプリケーション内の要素に対応している必要があるコンテキスト相対パス。この要素が存在する場合、指定されたパスが、このjsp-property-group内の各JSPページの最後に自動的に(includeディレクティブの場合のように)インクルードされます。

<deferred-syntax-allowed-as-literal>

省略可能

文字シーケンス#{を文字列リテラルとして使用できるどうかを制御します。

<trim-directive-whitespaces>

省略可能

ホワイト・スペースのみを含むテンプレート・テキストを、レスポンス出力から削除しなければならないかどうかを制御します。

<url-pattern>

必須

URLを解決する場合に使用されるパターンを記述します。http://host:port (「host」はホスト名、「port」はポート番号) + ContextPathに続くURLの部分は、WebLogic Serverによって<url-pattern>と比較されます。

サンプル・パターンを次に示します。

/soda/grape/*
/foo/*
/contents
*.foo

URLは、Servlet仕様2.4で指定されているルールに準拠している必要があります。

resource-env-ref

resource-env-ref要素には、Webアプリケーションの環境内のリソースに関連付けられた管理対象オブジェクトに対するWebアプリケーションの参照の宣言が含まれます。省略可能な説明、リソース環境参照名、Webアプリケーション・コードが予期するリソース環境参照のタイプで構成されます。

例:

<resource-env-ref>
<resource-env-ref-name>jms/StockQueue</resource-env-ref-name>
<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>

次の表では、resource-env-ref要素内で定義できる要素について説明します。

表A-22 resource-env-ref

要素

必須/省略可能

説明

<description>

省略可能

リソース環境参照の説明を指定します。

<resource-env-ref-name>

必須

リソース環境参照の名前を指定します; 値は、Webアプリケーションのコードで使用される環境エントリ名です。名前はjava:comp/envに対して相対的なJNDI名で、Webアプリケーション内で一意でなければなりません。

<resource-env-ref-type>

必須

リソース環境参照のタイプを指定します。Java言語のクラスまたはインタフェースの完全修飾名。

resource-ref

省略可能なresource-ref要素では、外部リソースへの参照ルックアップ名を定義します。この定義により、サーブレット・コードは、デプロイメント時に実際の位置にマップされる「仮想的な」名前でリソースをルックアップできるようになります。

各外部リソース名の定義には別々の<resource-ref>要素を使用します。外部リソース名は、デプロイメント時にWebLogic固有のデプロイメント記述子weblogic.xmlでリソースの実際の位置名にマップされます。

次の表では、resource-ref要素内で定義できる要素について説明します。

表A-23 resource-ref要素

要素

必須/省略可能

説明

<description>

省略可能

説明文。

<res-ref-name>

必須

JNDIツリー内で使用されるリソースの名前。Webアプリケーション内のサーブレットはこの名前を使用して、リソースへの参照をルックアップします。

<res-type>

必須

参照名に対応するリソースのJavaクラスのタイプ。Javaの完全パッケージ名を使用します。

<res-auth>

必須

セキュリティのためのリソース・サインオンの指定に使用されます。

APPLICATIONを指定した場合、アプリケーション・コンポーネント・コードによってプログラムでリソース・サインオンが行われます。Containerを指定した場合、WebLogic Serverでは、login-config要素で定義されたセキュリティ・コンテキストが使用されます。「login-config」を参照してください。

<res-sharing-scope>

省略可能

指定されたリソース・マネージャ接続ファクトリ参照を経由して取得された接続を共有するかどうかを指定します。

有効な値:

Shareable

Unshareable

security-constraint

security-constraint要素では、<web-resource-collection>要素で定義されたリソースの集合へのアクセス権限を定義します。

Webアプリケーションのセキュリティ構成の詳細な手順や例は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。また、WebLogicセキュリティの詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』を参照してください。

次の表では、security-constraint要素内で定義できる要素について説明します。

表A-24 security-constraint要素

要素

必須/省略可能

説明

<web-resource-
collection>

必須

このセキュリティ制約が適用されるWebアプリケーションのコンポーネントを定義します。

<auth-constraint>

省略可能

このセキュリティ制約で定義されるWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。「auth-constraint」を参照してください。

<user-data-
constraint>

省略可能

クライアントによるサーバーとの通信方法を定義します。

「user-data-constraint」を参照してください。

web-resource-collection

各<security-constraint>要素では、1つまたは複数の<web-resource-collection>要素が必要です。これらの要素では、このセキュリティ制約が適用されるWebアプリケーションの領域を定義します。

これは、security-constraint内の要素です。

次の表では、web-resource-collection要素内で定義できる要素について説明します。

表A-25 web-resource-collection要素

要素

必須/省略可能

説明

<web-resource-
name>

必須

Webリソースの集合の名前。

<description>

省略可能

このセキュリティ制約の説明文。

<url-pattern>

省略可能

<url-pattern>要素を1つまたは複数使用して、このセキュリティ制約の適用先となるURLパターンを宣言します。この要素を1つも使用しない場合、この<web-resource-collection>はWebLogic Serverから無視されます。

<http-method>

省略可能

<http-method>要素を1つまたは複数使用して、認可制約の対象になるHTTPメソッド(通常はGETまたはPOST)を宣言します。<http-method>要素を省略した場合には、デフォルトの動作として、セキュリティ制約がすべてのHTTPメソッドに適用されます。

auth-constraint

これは、security-constraint内の要素です。

省略可能なauth-constraint要素では、このセキュリティ制約で定義されたWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。

次の表では、auth-constraint要素内で定義できる要素について説明します。

表A-26 auth-constraint要素

要素

必須/省略可能

説明

<description>

省略可能

このセキュリティ制約の説明文。

<role-name>

省略可能

このsecurity-constraintで定義されたリソースにアクセスできるセキュリティ・ロールを定義します。セキュリティ・ロール名は、security-role-refを使用してプリンシパルにマップされます。

user-data-constraint

これは、security-constraint内の要素です。

user-data-constraint要素では、クライアントによるサーバーとの通信方法を定義します。

次の表では、user-data-constraint要素内で定義できる要素について説明します。

表A-27 user-data-constraint要素

要素

必須/省略可能

説明

<description>

省略可能

説明文。

<transport-
guarantee>

必須

クライアントとサーバーの間の通信方法を指定します。

INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSecure Sockets Layer (SSL)接続を確立します。

指定できる値:

NONE - トランスポートの保証が不要な場合に指定します。

INTEGRAL - クライアントとサーバーの間で、転送中にデータが変更されない方法でデータを転送する必要がある場合に指定します。

CONFIDENTIAL - 転送中にデータの中味を覗かれないようにデータを転送する必要がある場合に指定します。

login-config

省略可能なlogin-config要素を使って、ユーザーの認証方法、このアプリケーションで使用されるレルムの名前、およびフォームによるログイン機能で必要になる属性を構成します。

この要素が指定されている場合、ユーザーがWebアプリケーション内で定義されている<security-constraint>によって制約されたすべてのリソースにアクセスするには、認証を受ける必要があります。認証されると、ユーザーは、ほかのリソースにアクセスする権限が与えられる場合もあります。

次の表では、login-config要素内で定義できる要素について説明します。

表A-28 config

要素

必須/省略可能

説明

<auth-method>

省略可能

ユーザーの認証に使用する方法を指定します。指定できる値は次のとおりです。

BASIC - ブラウザ認証を使用します。これがデフォルト値です。

FORM - ユーザーが作成したHTMLフォームを使用します。

CLIENT-CERT

フォールバック・メカニズムを提供するために、複数の認証方法をカンマ区切りのリストとして定義できます。認証は、auth-methodリストで値が定義されている順序で試行されます。『Oracle WebLogic Serverセキュリティのプログラミング』の認証方法のフォールバック・メカニズムの提供に関する項を参照してください。

<realm-name>

省略可能

ユーザーの資格証明を認証する場合に参照されるレルムの名前。省略した場合、管理コンソールの「Webアプリケーション」>「構成」>「その他」タブにある「認証レルム名」フィールドで定義されたレルムがデフォルトで使用されます。

<realm-name>要素はWebLogic Server内のシステム・セキュリティ・レルムを参照しません。この要素ではHTTPベーシック認証で使用するレルム名を定義します。システム・セキュリティ・レルムは、サーバーでなんらかの操作が実行されるときにチェックされるセキュリティ情報の集合。サーブレット・セキュリティ・レルムは、ページがアクセスされてベーシック認証が使用されるときにチェックされる、セキュリティ情報の別の集合。

<form-login-
config>

省略可能

<auth-method>をFORMに構成する場合に、この要素を使用します。「form-login-config」を参照してください。

form-login-config

これは、login-config内の要素です。

<auth-method>をFORMに構成する場合に、<form-login-config>要素を使用します。

表A-29 form-login-config要素

要素

必須/省略可能

説明

<form-login-page>

必須

ユーザーを認証する場合に使用される、ドキュメント・ルートを基準にしたWebリソースの相対的なURI。これは、HTMLページ、JSP、またはHTTPサーブレットのいずれかになり、特定のネーミング・ルールに従うFORMベースの認証を表示するHTMLページを戻します。

<form-error-page>

必須

失敗した認証ログインに応答してユーザーに送信される、ドキュメント・ルートを基準にしたWebリソースの相対的なURI。

security-role

次の表では、security-role要素内で定義できる要素について説明します。

表A-30 security-role要素

要素

必須/省略可能

説明

<description>

省略可能

セキュリティ・ロールの説明文。

<role-name>

必須

ロール名。ここで使用する名前は、WebLogic固有のデプロイメント記述子weblogic.xmlで対応するエントリが必要になります。weblogic.xmlによって、ロールはセキュリティ・レルムにあるプリンシパルにマップされます。詳細については、「security-role-assignment」を参照。

env-entry

省略可能なenv-entry要素では、アプリケーションの環境エントリを宣言します。環境エントリごとに別個の要素を使用します。

次の表では、env-entry要素内で定義できる要素について説明します。

表A-31 env-entry要素

要素

必須/省略可能

説明

<description>

省略可能

説明文。

<env-entry-name>

必須

環境エントリの名前。

<env-entry-value>

必須

環境エントリの値。

<env-entry-type>

必須

環境エントリの型。

次のJavaクラスのタイプからいずれか1つを選択できます。

java.lang.Boolean
java.lang.String
java.lang.Integer
java.lang.Double
java.lang.Float

ejb-ref

省略可能なejb-ref要素では、EJBリソースへの参照を定義します。この参照は、WebLogic固有のデプロイメント記述子ファイルweblogic.xmlでマッピングを定義することにより、デプロイメント時にEJBの実際の位置にマップされます。各参照EJB名の定義には別々の<ejb-ref>要素を使用します。

次の表では、ejb-ref要素内で定義できる要素について説明します。

表A-32 ejb-ref要素

要素

必須/省略可能

説明

<description>

省略可能

参照の説明文。

<ejb-ref-name>

必須

Webアプリケーションで使用されるEJBの名前。この名前は、WebLogic固有のデプロイメント記述子weblogic.xmlでJNDIツリーにマップされます。詳細は、「ejb-reference-description」を参照してください。

<ejb-ref-type>

必須

参照EJBの期待されるJavaクラスのタイプ。

<home>

必須

EJBホーム・インタフェースの完全修飾クラス名。

<remote>

必須

EJBリモート・インタフェースの完全修飾クラス名。

<ejb-link>

省略可能

含まれているJava EEアプリケーション・パッケージでのEJBの<ejb-name>。

<run-as>

省略可能

参照されるEJBにセキュリティ・コンテキストが適用されるセキュリティ・ロール。<security-role>要素で定義されたセキュリティ・ロールである必要があります。

ejb-local-ref

ejb-local-ref要素は、エンタープライズBeanのローカル・ホームへの参照の宣言に使用されます。この宣言は以下のもので構成されます。

- 省略可能な説明

- エンタープライズBeanを参照するWebアプリケーションのコードで使用されるEJB参照名。参照されるエンタープライズBeanの予期されるタイプ

- 参照されるエンタープライズBeanの予期されるローカル・ホーム・インタフェースとローカル・インタフェース

- 参照されるエンタープライズBeanの指定に使用するejb-link情報(オプション)

次の表では、ejb-local-ref要素内で定義できる要素について説明します。

表A-33 ejb-local-ref要素

要素

必須/省略可能

説明

<description>

省略可能

参照の説明文。

<ejb-ref-name>

必須

EJB参照の名前を指定します。EJB参照はWebアプリケーションの環境内のエントリで、java:comp/envコンテキストに対して相対的。名前はWebアプリケーション内で一意である必要があります。名前の前にejb/を付けることを推奨します。

例:

<ejb-ref-name>ejb/Payroll</ejb-ref-name>

<ejb-ref-type>

必須

ejb-ref-type要素には、参照されるエンタープライズBeanの予期されるタイプが含まれます。ejb-ref-type要素は以下のいずれかである必要があります:

<ejb-ref-type>Entity</ejb-ref-type>

<ejb-ref-type>Session</ejb-ref-type>

<local-home>

必須

エンタープライズBeanのローカル・ホーム・インタフェースの完全修飾名。

<local>

必須

エンタープライズBeanのローカル・インタフェースの完全修飾名。

<ejb-link>

省略可能

ejb-link要素は、ejb-refまたはejb-local-ref要素内で、EJB参照がEJBにリンクされることを示すために使用されます。

ejb-link要素内の名前は、パス名で構成されます。このパス名には、参照先のEJBが含まれるejb-jar、#、対象Beanのejb-nameを順に指定します。

パス名は、EJBを参照するWebアプリケーションを含むWARファイルに対して相対的に指定します。このため、同じejb-nameを含む複数のEJBを一意に識別することが可能です。

使用される場所: ejb-local-refおよびejb-ref要素

例:

<ejb-link>EmployeeRecord</ejb-link>
<ejb-link>../products/product.jar#ProductEJB</ejb-link>

web-app

サーブレット2.4デプロイメント記述子のXMLスキーマです。WebLogic Serverは、http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specsで定義されているHTTPサーブレットを完全にサポートします。しかし、version属性は、2.4の動作を施行するために2.4に設定する必要があります。

次の表では、web-app要素内で定義できる要素について説明します。

表A-34 web-app要素

要素

必須/省略可能

説明

<version>

必須

サーブレット2.4の動作を施行するために、サーブレット・デプロイメント記述子はすべて、スキーマの2.4バージョンを指定する必要があります。

B weblogic.xmlデプロイメント記述子の要素

このドキュメントでは、WebLogic Server固有のデプロイメント記述子weblogic.xmlの要素に関する詳細なリファレンスを提供します。お使いのWebアプリケーションにweblogic.xmlデプロイメント記述子が含まれていない場合、WebLogic Serverによってこのデプロイメント記述子の要素にデフォルトの値が自動的に選択されます。

次の項では、weblogic.xmlデプロイメント記述子のルート要素<weblogic-web-app>の下に定義できる複合的なデプロイメント記述子要素について説明します。

- weblogic.xmlのネームスペース宣言とスキーマの場所

- description

- weblogic-version

- security-role-assignment

- run-as-role-assignment

- resource-description

- resource-env-description

- ejb-reference-description

- service-reference-description

- session-descriptor

- jsp-descriptor

- auth-filter

- container-descriptor

- charset-params

- virtual-directory-mapping

- url-match-map

- security-permission

- context-root

- wl-dispatch-policy

- servlet-descriptor

- work-manager

- logging

- library-ref

- fast-swap

- 後方互換性フラグ

- Webコンテナのグローバル構成

weblogic.xmlのネームスペース宣言とスキーマの場所

WebLogic Serverのweblogic.xmlファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。

<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">

weblogic.xmlのスキーマについては、http://xmlns.oracle.com/weblogic/weblogic-web-app/1.3/weblogic-web-app.xsdを参照してください。

description

description要素は、Webアプリケーションの説明文です。

weblogic-version

weblogic-version要素は、当該Webアプリケーション(ルート要素<weblogic-web-app>に定義)のデプロイ先とするWebLogic Serverのバージョンを示します。この要素は参照用で、現在WebLogic Serverでは使用されていません。

security-role-assignment

security-role-assignment要素は、Webアプリケーションのセキュリティ・ロールとWebLogic Serverの1つまたは複数のプリンシパルとのマッピングを宣言します。次に例を示します。

<security-role-assignment>
<role-name>PayrollAdmin</role-name>
<principal-name>Tanya</principal-name>
<principal-name>Fred</principal-name>
<principal-name>system</principal-name>
</security-role-assignment>

この要素を使用すると、次の例のように、特定のロールを外部定義されたロールとしてマークすることもできます。

<security-role-assignment>
<role-name>roleadmin</role-name>
<externally-defined/>
</security-role-assignment>

注意:

<security-role-assignment>要素には、<principal-name>または<externally-defined>のどちらかが定義されている必要があります。この両方を省略することはできません。

次の表では、security-role-assignment要素内で定義できる要素について説明します。

表B-1 security-role-assignment要素

要素

必須/省略可能

説明

<role-name>

必須

セキュリティ・ロール名を指定します。

<principal-name>

<externally-defined>が定義されていない場合、必須

セキュリティ・レルムで定義されるプリンシパルの名前を指定します。複数の<principal-name要素を使用してプリンシパルをロールにマップできます。セキュリティ・レルムの詳細は、『Oracle WebLogic Serverの保護』を参照してください。

<externally-defined>

<principal-name>が定義されていない場合、必須

特定のセキュリティ・ロールがセキュリティ・レルムでグローバルに定義されていることを指定します。WebLogic Serverでは、このセキュリティ・ロールをグローバル・レルム内でルックアップするのではなくプリンシパル名として使用します。セキュリティ・ロールとprincipal-nameのマッピングが別の場所で定義されている場合、これは暗示的なプレースホルダーとして使用されます。

security-role-assignment要素およびその下位要素を定義していない場合は、Webアプリケーション・コンテナによってロール名がプリンシパル名として暗黙的にマップされ、ログに警告メッセージが出力されます。マッピングが定義されていないと、EJBコンテナはモジュールをデプロイしません。

以下に、ロール名が「role_xyz」の場合の使用例を示します。

- weblogic.xmlで「role_xyz」をユーザー「joe」にマップすると、role_xyzがローカル・ロールになります。

- role_xyzを外部定義されたロールとして指定すると、これがグローバルになります(レルム・レベルで定義されたロールを参照します)。

- security-role-assignment要素を定義しないと、role_xyzがローカル・ロールになります。この場合、Webアプリケーション・コンテナによって暗黙的なマッピングが作成され、ログに警告メッセージが出力されます。

run-as-role-assignment

run-as-role-assignment要素は、web.xmlのrun-asロール名(servlet要素の下位要素)をシステムの有効なユーザー名にマップします。この値は、servlet-descriptorのrun-as-principal-name要素によって任意のサーブレットについてオーバーライドできます。ロール名のrun-as-role-assignmentがない場合は、Webアプリケーション・コンテナによりsecurity-role-assignmentに定義されている最初のprincipal-nameが使用されます。次の例に、run-as-role-assignment要素の使用方法を示します。

<run-as-role-assignment>
<role-name>RunAsRoleName</role-name>
<run-as-principal-name>joe</run-as-principal-name>
</run-as-role-assignment>

次の表では、run-as-role-assignment要素内で定義できる要素について説明します。

表B-2 run-as-role-assignment要素

要素

必須/省略可能

説明

<role-name>

必須

セキュリティ・ロール名を指定します。

<run-as-principal-name>

必須

プリンシパルの名前を指定します。

resource-description

resource-description要素は、サーバー・リソースのJNDI名を、WebLogic ServerのEJBリソースの参照にマップするために使用されます。

次の表では、resource-description要素内で定義できる要素について説明します。

表B-3 resource-description要素

要素

必須/省略可能

説明

<res-ref-name>

必須

リソース参照名を指定します。

<jndi-name>

必須

リソースのJNDI名を指定します。

resource-env-description

resource-env-description要素は、ejb-jar.xmlデプロイメント記述子で宣言されたresource-env-refを、それが表しているサーバー・リソースのJNDI名にマップします。

次の表では、resource-env-description要素内で定義できる要素について説明します。

表B-4 resource-env-description要素

要素

必須/省略可能

説明

<res-env-ref-name>

必須

リソース環境参照名を指定します。

<jndi-name>

必須

リソース環境参照のJNDI名を指定します。

ejb-reference-description

次の表では、ejb-reference-description要素内で定義できる要素について説明します。

表B-5 ejb-reference-description要素

要素

必須/省略可能

説明

<ejb-ref-name>

必須

Webアプリケーションで使用するEJB参照の名前を指定します。

<jndi-name>

必須

参照のJNDI名を指定します。

service-reference-description

次の表では、service-reference-description要素内で定義できる要素について説明します。

表B-6 service-reference-description要素

要素

必須/省略可能

説明

<service-ref-name>

<wsdl-url>

<call-property>

<call-property>要素には次の下位要素があります。

<name>

<value>

<port-info>

<port-info>要素には次の下位要素があります。

<port-name>

<stub-property>

<call-property>

session-descriptor

session-descriptor要素には、サーブレット・セッションのパラメータを定義します。

表B-7 session-descriptor

要素名

デフォルト値

値

timeout-secs

3600

WebLogic Serverでセッションをタイムアウトするまでに待機する時間を秒単位で指定します。デフォルト値は3600秒です。

トラフィックの多いサイトでは、セッションのタイムアウトを調整すると、アプリケーションの動作を最適化できます。ブラウザ・クライアントでいつでもセッションを終了できるようにする必要がある場合でも、ユーザーがサイトを離れるか、ユーザーのセッションがタイムアウトになれば、サーバーに接続する必要はなくなります。

この属性は、web.xmlのsession-timeout要素(分単位で定義)によってオーバーライドされる可能性があります。

invalidation-interval-secs

60

WebLogic Serverが、タイムアウトの無効なセッションに対してハウス・クリーニング・チェックを実行してから古いセッションを削除してメモリーを解放するまでの待機時間を秒単位で設定します。この要素を使用して、トラフィックの多いサイトでWebLogic Serverのパフォーマンスが最適化されるようにチューニングします。

デフォルト値は60秒です。

sharing-enabled

false

アプリケーション・レベルでこの値をtrueに設定した場合、複数のWebアプリケーションでHTTPセッションを共有できます。

Webアプリケーション・レベルで有効になっている場合、この要素は無視されます。

debug-enabled

false

HTTPセッションのデバッグ機能を有効にします。

デフォルト値はfalseです。

id-length

52

セッションIDのサイズを設定します。

最小値は8バイト、最大値はInteger.MAX_VALUEで指定した値。

WAPアプリケーションを作成する場合、WAPプロトコルはCookieをサポートしていないため、URLを書き換える必要があります。また、一部のWAPデバイスでは、URLの長さに128文字(属性も含む)の制限があり、URL書換えで転送できるデータ・サイズが限られます。属性用の領域を確保するには、WebLogic Serverでランダムに生成されるセッションIDのサイズをこの属性で制限します。

WAPEnabled属性を設定して、長さを52文字までに制限し、特殊文字の使用を禁止することもできます。詳細は、「URL書換えとWireless Access Protocol (WAP)」を参照してください。

tracking-enabled

true

HTTPリクエスト間のセッション・トラッキングを有効にします。

cache-size

1028

JDBCとファイル永続セッションのキャッシュ・サイズを設定します。

max-in-memory-sessions

-1

メモリー/レプリケートされたセッションの最大セッション数を設定します。

メモリー内で使用できるサーブレット・セッションの上限数を構成する機能がない場合、新しいセッションが作成され続けると、最終的にはサーバーでメモリー不足となります。これを回避するため、WebLogic Serverでは作成されるセッション数に対して、構成可能な制限を設けています。この数を超えると、新しいセッションの作成が試行されるたびに、weblogic.servlet.SessionCreationExceptionが発生します。この機能は、レプリケートされたインメモリー・セッションと、レプリケートされないインメモリー・セッションの双方に適用されます。

メモリー内で使用できるサーブレット・セッションの上限を構成するには、このmax-in-memory-sessions要素に上限値を設定します。

デフォルトは-1 (無制限)。負の値を指定しても-1と同じ無制限になります。

cookies-enabled

true

セッションCookieの使用はデフォルトで有効になっているが(推奨)、このプロパティをfalseに設定して無効にすることも可能です。テストのためにこのオプションをオフにする場合もあります。

cookie-name

JSESSIONID

セッション・トラッキングCookieの名前を定義します。設定しない場合、デフォルトはJSESSIONID。アプリケーションに対して、より詳細な名前を指定できます。

cookie-path

null

セッション・トラッキングCookieのパスを定義します。

この属性を設定しない場合、デフォルトは/ (スラッシュ)。デフォルト値では、ブラウザは、WebLogic Serverで指定されているすべてのURLにCookieを送信します。マップ対象を絞り込んだパスを設定し、リクエストURLを、ブラウザがCookieを送信するものに限定できます。

cookie-domain

null

Cookieが有効になるドメインを指定します。たとえば、cookie-domainを.mydomain.comに設定すると、*.mydomain.comドメイン内のすべてのサーバーにCookieが返されます。

ドメイン名には少なくとも2つのコンポーネントが必要です。名前を*.comまたは*.netに設定すると無効になります。

この属性を設定しない場合、デフォルトは、Cookieを発行したサーバーのドメイン。

詳細は、Servlet仕様のCookie.setDomain()を参照してください。

cookie-comment

null

Cookieファイル内のセッション・トラッキングを行うCookieを識別するコメントを指定します。

cookie-secure

false

CookieをHTTPS接続でのみ返信するようブラウザに指示します。これにより、Cookie IDが保護され、HTTPSを使用するWebサイトでのみ使用されるようになります。この機能を有効にすると、HTTPでのセッションCookieは機能しなくなります。

この機能を使用する場合、url-rewriting-enabled要素は無効にする必要があります。

cookie-max-age-secs

-1

セッションCookieの存続期間を秒単位で設定します。時間が経過すると、Cookieはクライアントで期限切れになります。

任意の整数を設定可能です。デフォルト値は -1 (無制限)。

Cookieの詳細は、第10章「セッションとセッション永続性の使用」を参照してください。

persistent-store-type

memory

永続ストレージの方法を次のいずれかに設定します。

- memory - 永続セッション・ストレージを無効にします。

- replicated - memoryと同じですが、セッション・データはクラスタリングされたサーバー間でレプリケートされます。

- replicated_if_clustered - Webアプリケーションがクラスタリングされているサーバーにデプロイされている場合は、有効なpersistent-store-typeがレプリケートされます。それ以外の場合は、memoryがデフォルトです。

- async-replicated - アプリケーションまたはWeb Applicationで非同期セッションのレプリケーションができます。『Oracle WebLogic Serverパフォーマンスおよびチューニング』の非同期HTTPセッションのレプリケーションに関する項を参照してください。

- async-replicated-if-clustered - クラスタ環境にデプロイされる場合、アプリケーションまたはWebアプリケーションで非同期セッション・レプリケーションを有効にします。単一のサーバー環境にデプロイされる場合、セッションの永続性/レプリケーションはデフォルトでインメモリーになります。これにより、デプロイメント・エラーなしで単一サーバーでのテストが可能になります。

- file - ファイル・ベースの永続性を使用します(「session-descriptor」も参照)。

- async-jdbc - アプリケーションまたはWebアプリケーションでHTTPセッションの非同期JDBC永続性を有効にします。「セッションの永続性の構成」を参照してください。

- jdbc - データベースを使用して永続セッションを格納します(「session-descriptor」も参照)。

- cookie - すべてのセッション・データはユーザーのブラウザ内のCookieに格納されます。

persistent-store-cookie-name

WLCOOKIE

Cookieベースの永続性に使用するCookieの名前を設定します。WLCOOKIE Cookieはセッション状態を保持します - これは、Webアプリケーション間で共有されないことが必要です。

詳細は、「Cookieベースのセッション永続性の使用」を参照してください。

persistent-store-dir

session_db

ファイル・ベースの永続性に直接使用されるストレージ・ディレクトリを指定します

各セッションのサイズに有効なセッション数をかけたサイズを保存できるのみのディスク・スペースを確保する必要があります。セッションのサイズはpersistent-store-dirに作成されているファイルで確認できます。各セッションのサイズは、シリアライズされたセッション・データの変更のサイズによって異なります。

各サーバー・インスタンスには、構成不要なデフォルトの永続ファイル・ストアがあります。したがって、ディレクトリが指定されていない場合は、デフォルトのストアが<server-name>\data\store\defaultディレクトリに自動的に作成されます。ただし、デフォルトのストアをクラスタリングされたサーバーの間で共有することはできません。

複数サーバー間で共有しているディレクトリにカスタム永続ストアを作成すると、ファイル永続セッションをクラスタリング可能にできます。ただし、その場合はこのディレクトリを手動で作成する必要があります。

persistent-store-pool

None

永続ストレージに使用されるJDBC接続プールの名前を指定します。

persistent-store-table

wl_servlet_sessions

JDBCベースの永続セッションの保存に使用するデータベース表名を指定します。これはpersistent-store-typeがjdbcに設定されている場合にのみ適用されます。

persistent-store-table要素は、デフォルト以外のデータベース表名を選択した場合にのみ使用されます。

jdbc-column-name-max-inactive-interval

wl_max_inactive_interval列名の代替名として使用されます。このjdbc-column-name-max-inactive-interval要素はJDBCベースの永続性にのみ適用されます。長い列名をサポートしていないデータベースでは必須です。

jdbc-connection-timeout-secs

120

注意: この要素はこのリリースでは非推奨です。

WebLogic ServerがJDBC接続をタイムアウトするまでの待機時間を秒単位で設定します(秒数)。

url-rewriting-enabled

true

URL書換えを有効にします。これによって、セッションIDがURLにエンコーディングされ、Cookieがブラウザで無効の場合にセッション・トラッキングが実行されます。

http-proxy-caching-of-cookies

true

falseに設定されている場合、レスポンスにはヘッダーが以下のように追加されます。

"Cache-control: no-cache=set-cookie"

これは、プロキシ・キャッシュでCookieがキャッシュされないことを示します。

encode-session-id-in-query-params

false

最新のサーブレットの仕様では、パス・パラメータでセッションIDをエンコードするためにコンテナが必要です。特定のWebサーバーは、パス・パラメータを使用して機能しません。このような場合、encode-session-id-in-query-params要素をtrueに設定する(デフォルトはfalseです。)

runtime-main-attribute

ServletSessionRuntimeMBeanで使用されます。ServletSessionRuntimeMBeanのgetMainAttribute()で返されるセッション属性の値で、この要素の文字列がキーとして使われます。

例: user-name

この要素は、様々なセッションのセッション実行時情報をタグ付けする場合に役立ちます。

cookie-http-only

true

HttpOnlyのCookieが有効になっているかを指定します。この要素は、trueに設定されている場合、すべてのCookieがブラウザ・スクリプトに対して、無効になります。デフォルト値はtrueです。デフォルトでは、HttpOnlyのCookieが有効になっています。

jsp-descriptor

jsp-descriptor要素には、JSPコンパイラの構成パラメータのリストを指定します。次の表で、jsp-descriptor要素内に定義できる要素について説明します。

表B-8 jsp-descriptor要素

要素

デフォルト値

説明

page-check-seconds

1

JSPファイルが変更されたために再コンパイルする必要があるかどうかをチェックする間隔を秒単位で設定します。変更されている場合は、依存関係もチェックされ、再帰的に再ロードされます。

- 値-1の場合、ページのチェックは行われません。これは、本番環境でのデフォルト値です。

- 値0の場合、ページは常にチェックされます。

- 値1の場合、ページは毎秒チェックされます。この値は、開発環境でのデフォルト値です。

JSPを変更することが稀な本番環境では、チューニング要件に応じて、pageCheckSecondsの値を60以上に設定することを検討してください。

strict-stale-check

true

展開されたWARにのみ適用されます。

更新されたJSPファイルがチェックされます。つまり、ファイルのタイムスタンプがビルド時のタイムスタンプよりも後(新しい)かどうかがチェックされます。新しいファイルが古いファイルを置換できるのみです。

falseに設定した場合は、タイムスタンプが変更されたかどうかのみがチェックされます。変更されていれば、ファイルが置換されます。

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://
xmlns.oracle.com/weblogic/weblogic-web-app">
<jsp-descriptor>
<strict-stale-check>false
</strict-stale-check>
</jsp-descriptor>
</weblogic-web-app>

precompile

false

trueに設定すると、Webアプリケーションのデプロイ(再デプロイ)時またはWebLogic Serverの起動時に、変更されたすべてのJSPが自動的にあらかじめコンパイルされます。

precompile-continue

false

trueに設定すると、いずれかのJSPのコンパイルに失敗しても、変更されたすべてのJSPがプリコンパイルされます。precompileがtrueに設定されている場合にのみ有効です。

keepgenerated

false

JSPコンパイル・プロセスの間に生成されるJavaファイルを保存します。このパラメータをtrueに設定しない限り、中間生成されたJavaファイルはコンパイル後に削除されます。

verbose

true

trueに設定すると、デバッグ情報がブラウザ、コマンド・プロンプト、およびWebLogic Serverログ・ファイルに出力されます。

working-dir

internally generated directory

WebLogic Serverが、JSP用に生成されたJavaとコンパイル済みのクラス・ファイルを保存するディレクトリの名前。

注意: weblogic.xmlでworking-dirが定義されている場合、Webアプリケーションがアンデプロイされても、WebLogic Serverはこのディレクトリを削除しません。

print-nulls

null

falseに設定すると、"null"を含む式は" "として出力されます。

backward-compatible

true

trueに設定すると、後方互換性が有効になります。

詳細は、「後方互換性フラグ」を参照してください。

encoding

Default encoding of your platform

JSPページで使用されるデフォルトの文字セットを指定します。標準のJava文字セット名を使用します(http://download.oracle.com/javase/6/docs/technotes/guides/intl/を参照)。

この属性を設定しない場合、デフォルトはユーザーのプラットフォームのエンコーディング。

JSPコードに含まれるJSPページ・ディレクティブはこの設定をオーバーライドします。例:

<%@ page contentType="text/html; charset=custom-encoding"%>

package-prefix

jsp_servlet

すべてのJSPページのコンパイル先となるパッケージの接頭辞を指定します。

exact-mapping

true

trueの場合、JSPの最初のリクエスト時に新しく作成されるJspStubが正確なリクエストにマップされます。exactMappingがfalseに設定されている場合、Webアプリケーション・コンテナはJSP用に正確ではないurlマッピングを生成します。exactMappingはJSPページのパス情報を提供します。

default-file-name

true

JSP用の生成済みJavaおよびコンパイル済みクラス・ファイルを保存するファイルのデフォルト名。

rtexprvalue-jsp-param-name

false

jsp:paramタグのname属性に実行時の式の値を指定できるようにします。デフォルトではfalseに設定されます。

optimize-java-expression

false

trueの場合、JSPコンパイラによりJava式が最適化され実行時のパフォーマンスが改善されます。

compress-html-template

false

trueの場合、JSPテンプレート・ブロック内のHTMLが圧縮され実行時のパフォーマンスが改善されます。

JSPのHTMLテンプレート・ブロックに<pre> HTMLタグが含まれる場合は、この機能を有効にしないでください。

auth-filter

auth-filter要素は、認証フィルタのHttpServletクラスを指定します。

注意:

この要素は現在のリリースでは非推奨とされています。かわりにサーブレット認証フィルタを使用してください。

container-descriptor

<container-descriptor>要素には、Webアプリケーションの動作に影響するパラメータのリストを指定します。

check-auth-on-forward

<check-auth-on-forward/>要素は、サーブレットまたはJSPから転送されたリクエストの認証を必要とするときに追加します。再認証を必要としない場合、このタグは省略します。例:

<container-descriptor>
<check-auth-on-forward/>
</container-descriptor>

注意:

ベスト・プラクティスとしては、check-auth-on-forwardプロパティを有効にしないことをお薦めします。

filter-dispatched-requests-enabled

<filter-dispatched-requests-enabled>要素は、ディスパッチされたリクエストにフィルタを適用するかどうかを制御します。デフォルト値はfalseです。

注意:

2.4サーブレットは、(2.4仕様にしたがって) 2.3サーブレットと後方互換性があるため、2.3の記述子要素がWebLogic Serverで検出された場合、<filter-dispatched-requests-enabled>要素のデフォルトはtrueになります。

redirect-with-absolute-url

<redirect-with-absolute-url>要素は、javax.servlet.http.HttpServletResponse.SendRedirect()メソッドでのリダイレクトに相対URLと絶対URLのどちらを使用するかを制御します。プロキシHTTPサーバーを使用しており、URLを非相対リンクに変換したくない場合は、この要素をfalseに設定します。

デフォルトの動作では、URLが非相対リンクに変換されます。

注意:

リダイレクトで使用されるユーザーが読めるデータ。

index-directory-enabled

<index-directory-enabled>要素は、適切な索引ファイルが見つからない場合にHTMLディレクトリのリストを自動的に生成するかどうかを制御します。

デフォルト値はfalseです(ディレクトリは生成されません)。値はtrueまたはfalseです。

index-directory-sort-by

<index-directory-sort-by>要素は、weblogic.servlet.FileServletで生成されるディレクトリ・リストのソート順序を定義します。有効なsort-by値は、NAME、LAST_MODIFIED、およびSIZEです。デフォルトのsort-by値はNAMEです。

servlet-reload-check-secs

<servlet-reload-check-secs>要素は、サーブレットが変更されたかどうかをWebLogic Serverがチェックして、変更されていた場合に再ロードするかどうかを定義します。

- 値-1の場合、サーブレットのチェックは行われません。これは、本番環境でのデフォルト値です。

- 値0の場合、サーブレットは常にチェックされます。

- 値1の場合、サーブレットは毎秒チェックされます。この値は、開発環境でのデフォルト値です。

管理コンソールで指定する値は、手動で設定する値よりも常に優先されます。

resource-reload-check-secs

<resource-reload-check-secs>要素は、Webアプリケーション・スコープのリソース・パスで検出されるキャッシュされたリソースのメタデータ・キャッシングに使用されます。このパラメータでは、リソースが変更されているかどうかをチェックして変更されていた場合に再ロードを行う頻度を特定します。

- 値-1の場合、再ロードは行われません。これは、本番環境でのデフォルト値です。

- 値0の場合、常に再ロードが行われます。

- 値1の場合、毎秒再ロードが行われます。この値は、開発環境でのデフォルト値です。

このパラメータの値としては管理コンソールを使用して指定したものに優先権が与えられます。

注意:

jsp-descriptor要素では、<page-check-seconds>が指定されている場合、<page-check-seconds>は<resource-reload-check-secs>の値をオーバーライドします。

single-threaded-servlet-pool-size

<single-threaded-servlet-pool-size>要素は、SingleThreadModeインスタンス・プールで使用するプールのサイズを定義します。デフォルト値は5です。

注意:

SingleThreadModeインスタンス・プールはこのリリースでは非推奨とされています。

session-monitoring-enabled

<session-monitoring-enabled>要素は、「true」に設定すると、セッションのためにランタイムMBeanが作成できます。デフォルト値の「false」に設定すると、ランタイムMBeansが作成されません。管理コンソールで指定した値は、手動で設定する値よりも優先されます。

save-sessions-enabled

<save-sessions-enabled>要素は、再デプロイまたはアンデプロイ時にセッション・データをクリーン・アップするかどうかを制御します。これはメモリーとレプリケート・セッションに影響します。値をtrueに設定すると、セッション・データは保存されます。falseに設定すると、Webアプリケーションが再デプロイまたはアンデプロイされるときにセッション・データは破棄されます。デフォルトはfalseです。

prefer-web-inf-classes

<prefer-web-inf-classes>要素をtrueに設定すると、WebアプリケーションのWEB-INFディレクトリにあるクラスが、アプリケーションまたはシステム・クラスローダー内にロードされたクラスに優先してロードされます。デフォルト値は、falseです。管理コンソールに指定した値は、手動で設定する値よりも優先されます。

注意:

weblogic.xml内でprefer-web-inf-classesが有効になっている場合、prefer-application-packagesもprefer-application-resourcesも指定できません。

prefer-application-packages

<prefer-application-packages要素では、アプリケーションからロードするクラスのパッケージ・リストを指定します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のprefer-application-packagesに関する項を参照してください。

<?xml version="1.0" encoding="UTF-8"?>

<wls:weblogic-web-app
xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
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/ejb-jar_3_0.xsd
http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd">

<wls:weblogic-version>10.3.5</wls:weblogic-version>
<wls:context-root>FilterWeb</wls:context-root>
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>com.oracle.foo</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
</wls:weblogic-web-app>

prefer-application-packagesまたはprefer-application-resourcesを使用するには、prefer-web-inf-classesがfalseに設定されている必要があることに注意してください。

prefer-application-resources

<prefer-application-resources要素では、リソースがシステム・クラスローダーにある場合でも必ずアプリケーションからロードする必要があるリソースのリストを指定します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のprefer-application-resourcesに関する項を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>javax.faces.*</package-name>
<package-name>com.sun.faces.*</package-name>
<package-name>com.bea.faces.*</package-name>
</prefer-application-packages>

<prefer-application-resources>
<resource-name>javax.faces.*</resource-name>
<resource-name>com.sun.faces.*</resource-name>
<resource-name>com.bea.faces.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
</prefer-application-resources>
</container-descriptor>
</weblogic-web-app>

prefer-application-packagesまたはprefer-application-resourcesを使用するには、prefer-web-inf-classesがfalseに設定されている必要があることに注意してください。

default-mime-type

<default-mime-type>要素のデフォルト値はnullです。この要素を使用すると、拡張がマップされていないcontent-typeのデフォルトのMIMEタイプを指定できます。

client-cert-proxy-enabled

<client-cert-proxy-enabled>要素のデフォルト値はtrueです。trueの場合、WebLogic ServerによってクライアントからのID証明書がバックエンドのサーバーに渡されます。また、受信したWL-Proxy-Client-Certヘッダーを受け入れるのか、破棄するのかがWebLogic Serverに通知されます。

WL-Proxy-Client-Certヘッダーの各ID証明書はプロキシ・サーバー・プラグインによってエンコードされ、バックエンドのWebLogic Serverインスタンスに渡されます。各WebLogic Serverインスタンスでは、このヘッダーから証明書情報を受け取り、安全なソースに由来するものであると確認してから、その証明書情報でユーザーを認証します。バックグラウンドのWebLogic Serverインスタンスでは、このパラメータが(クラスタ、サーバーまたはWebアプリケーションのレベルで) trueに設定されている必要があります。

この要素をtrueに設定する場合、weblogic.security.net.ConnectionFilterを使用して、各WebLogic Serverインスタンスで確実に、プロキシ・サーバー・プラグインが実行されているマシンからの接続のみを受け付けるようにします。trueを指定した場合に接続フィルタを使用しないとWL-Proxy-Client-Certヘッダーのなりすましが可能になるため、セキュリティに脆弱性が生じるおそれがあります。

relogin-enabled

<relogin-enabled>要素は後方互換性のためのパラメータです。すでにログインしているユーザーが権限を持たないリソースにアクセスしようとすると、FORBIDDEN (403)レスポンスが発生します。

allow-all-roles

Webアプリケーションのweb.xml記述子に定義されているsecurity-constraints要素の中では、auth-constraint要素が、当該リソースの集合へのアクセスを許可する必要があるユーザー・ロールを示します。role-name = "*"とすると、Webアプリケーション内のすべてのロールを示す構文を簡単に記述できます。なお、role-name = "*"は以前のリリースでは、レルム内に定義されているすべてのユーザーおよびロールを示すものとして扱われていました。

このallow-all-roles要素は、以前の動作に戻すための後方互換性スイッチです。デフォルトの動作では、Webアプリケーションに定義されているすべてのロールが許可されます。weblogic.xmlに指定されている値が、WebAppContainerMBeanに定義されている値よりも優先されます。

native-io-enabled

weblogic.servlet.FileServlet(暗黙的に登録されているデフォルトのサーブレット)で静的ファイルを提供しているときにネイティブI/Oを使用するには、native-io-enabledをtrueに設定します。(デフォルト値はfalseです。) native-io-enabled要素はWindows上でのみ適用されます。

minimum-native-file-size

minimum-native-file-size要素はnative-io-enabledがtrueに設定されている場合にのみ適用されます。この要素には、ネイティブI/Oを使用する際の最小ファイル・サイズをバイト単位で指定します。提供するファイルのサイズがこの値よりも大きいと、ネイティブI/Oが使用されます。この値を設定しない場合、デフォルト値として4000が使用されます。

disable-implicit-servlet-mappings

disable-implicit-servlet-mappingsフラグがtrueに設定されている場合、Webアプリケーション・コンテナでは内部サーブレット(*.jsp、*.classなど)の暗黙的なマッピングが作成されず、デフォルト・サーブレットのマッピングのみが作成されます。通常、暗黙的なサーブレット・マッピングを無効にするのは、HttpClusterServletやHttpProxyServletを構成している場合です。

デフォルト値はfalseです。

temp-dir

temp-dir要素は、"javax.servlet.context.tempDir"属性で戻されるように、Webアプリケーション用の一時ディレクトリの場所を指定します。

optimistic-serialization

optimistic-serializationが有効になっている場合、リクエストがサーブレット・コンテキストを超えてディスパッチされるときにgetAttribute(name)のコンテキストとリクエスト属性はシリアライズおよびデシリアライズされません。

つまり、複数のWebアプリケーションに共通する属性は、共通の親クラスローダーにスコープ指定するか(アプリケーション・スコープ指定)、2つのWebアプリケーションが同じアプリケーションに属していない場合はシステムのクラスパスに配置する必要があります。

optimistic-serializationがオフ(デフォルト値)になっている場合、WebLogic ServerはClassCastExceptionの発生を回避するためにgetAttribute(name)のコンテキストおよびリクエストの属性をシリアライズおよびデシリアライズします。

optimistic-serialization値は、WebAppContainerMBeanでドメイン・レベルで指定することもでき、その場合すべてのWebアプリケーションに適用されます。weblogic.xmlに値を指定した場合、その値によってドメイン・レベルの値がオーバーライドされます。

デフォルト値はfalseです。

show-archived-real-path-enabled

show-archived-real-path-enabled要素は、アーカイブされたWebアプリケーションのgetRealPath()の動作を指定します。

trueに設定されている場合、getRealPath()はリソース・ファイルの標準のパスを戻します。

show-archived-real-path-enabled要素がfalseに設定されている場合、サーブレット・コンテナは、アーカイブされたWebアプリケーションのファイルのフルパスをnullとして戻します。

デフォルト値はfalseです。

require-admin-traffic

require-admin-trafffic要素は、トラフィックが管理チャネルを通過する必要があるかどうかを定義します。trueに設定すると、トラフィックが管理チャネルを通過できます。それ以外の場合、トラフィックが管理チャネルを通過できるのは、Webアプリケーションが管理モードにある場合のみです。例:

<container-descriptor>
<require-admin-traffic>true</require-admin-traffic>
</container-descriptor>

access-logging-disabled

access-logging-disabled要素は、基底のWebアプリケーションのアクセス・ロギングを無効にするかどうかを定義します。このプロパティをtrueに設定すると、ロギングのオーバーヘッドが小さくなり、サーバーのスループットが改善されます。このプロパティを指定しないかfalseに設定すると、アプリケーションのアクセスがロギングされます。

prefer-forward-query-string

転送リクエストでHttpServletRequest.getQueryString()が呼び出されたとき、WebLogic Serverは、RequestDispatcher経由で転送サーブレットによって送信されたqueryStringとクライアントによって送信されたオリジナルなqueryStringを戻します。

prefer-forward-query-stringフラグをtrueに設定した場合、WebLogic Serverは、転送された問合せ文字列が指定されている場合、それのみを戻します。デフォルト値はfalseです。

charset-params

<charset-params>要素は、Unicode以外の処理でコード・セット動作を定義するために使います。例:

<charset-params>
<input-charset>
<resource-path>/*</resource-path>
<java-charset-name>UTF-8</java-charset-name>
</input-charset>
</charset-params>

input-charset

<input-charset>要素を使って、GETデータとPOSTデータの読取りにどの文字セットを使用するのかを定義します。例:

<input-charset>
<resource-path>/foo</resource-path>
<java-charset-name>SJIS</java-charset-name>
</input-charset>

詳細は、「HTTPリクエストのエンコーディングの識別」を参照してください。

次の表では、<input-charset>要素内で定義できる要素について説明します。

表B-9 input-charset要素

要素

必須/省略可能

説明

<resource-path>

必須

リクエストのURLに含まれている場合、<java-charset-name>で指定されているJava文字セットを使用するようにWebLogic Serverに知らせるパス。

<java-charset-name>

必須

使用するJava文字セットを指定します。

charset-mapping

<charset-mapping>要素を使って、IANA文字セット名をJava文字セット名にマップします。例:

<charset-mapping>
<iana-charset-name>Shift-JIS</iana-charset-name>
<java-charset-name>SJIS</java-charset-name>
</charset-mapping>

詳細は、「IANA文字セットのJava文字セットへのマッピング」を参照してください。

次の表では、<charset-mapping>要素内で定義できる要素について説明します。

表B-10 charset-mapping要素

要素

必須/省略可能

説明

<iana-charset-name>

必須

<java-charset-name>要素で指定されたJava文字セットにマップされるIANA文字セット名を指定します。

<java-charset-name>

必須

使用するJava文字セットを指定します。

virtual-directory-mapping

virtual-directory-mappingリクエストは、特定の種類のリクエスト(画像のリクエストなど)用に、Webアプリケーションのデフォルト・ドキュメント・ルート以外のドキュメント・ルートを指定するために使用します。Webアプリケーション・セット用のすべての画像は単一の場所に格納でき、それらを使用する各Webアプリケーションのドキュメント・ルートにコピーする必要がありません。リクエストを受信した場合、仮想ディレクトリが指定されていれば、サーブレット・コンテナは要求されたリソースをまず仮想ディレクトリで検索し、次にWebアプリケーションのデフォルト・ドキュメント・ルートで検索します。これにより、同じドキュメントが両方の場所に存在する場合の優先順位が決まります。

例:

<virtual-directory-mapping>
<local-path>c:/usr/gifs</local-path>
<url-pattern>/images/*</url-pattern>
<url-pattern>*.jpg</url-pattern>
</virtual-directory-mapping>
<virtual-directory-mapping>
<local-path>c:/usr/common_jsps.jar</local-path>
<url-pattern>*.jsp</url-pattern>
</virtual-directory-mapping>

次の表では、virtual-directory-mapping要素内で定義できる要素について説明します。

表B-11 virtual-directory-mapping要素

要素

必須/省略可能

説明

<local-path>

必須

ディスク上の物理位置を指定します。

<url-pattern>

必須

マッピングのURLパターンを含みます。Servlet API仕様の11.2項で指定されているルールに準拠している必要があります。

仮想ディレクトリ・マッピングのWebLogic Server実装では、マッピングのurl-patternに一致するディレクトリが必要です。上記の画像の例であれば、c:/usr/gifs/imagesにimagesというディレクトリを作成する必要があります。これにより、サーブレット・コンテナがimagesディレクトリにある複数のWebアプリケーションの画像を見つけることが可能になります。

url-match-map

この要素は、URLパターン・マッチング用のクラスを指定するために使用します。WebLogic ServerのデフォルトURLマッチ・マッピング・クラスは、Java EE仕様に基づいたweblogic.servlet.utils.URLMatchMapです。また、WebLogic ServerにはSimpleApacheURLMatchMapも実装されています。これは、url-match-map要素を使用してプラグインできます。

SimpleApacheURLMatchMapのルールを示します。

*.jwsをJWSServletにマップする場合、

http://foo.com/bar.jws/bazはpathInfo = bazを使用してJWSServletに解決されます。

次の例に示すように、使用するURLMatchMapをweblogic.xmlで構成します。

<url-match-map>
weblogic.servlet.utils.SimpleApacheURLMatchMap
</url-match-map>

security-permission

security-permission要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。セキュリティ許可仕様の実装については、次のURLを参照してください。

http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

オプションのcodebaseおよびsignedBy句は無視してください。

例:

<security-permission-spec>
grant { permission java.net.SocketPermission "*", "resolve" };
</security-permission-spec>

説明:

- permission java.net.SocketPermissionは許可・クラス名。

- "*"はターゲット名。

- resolveはアクション。

context-root

context-root要素は、このスタンドアロンWebアプリケーションのコンテキスト・ルートを定義します。WebアプリケーションがスタンドアロンではなくEARの一部の場合、EARのMETA-INF/application.xmlファイルにコンテキスト・ルートを指定します。application.xmlのcontext-root設定は、weblogic.xmlのcontext-root設定より優先します。

このweblogic.xml要素は、2フェーズ・デプロイメント・モデルを使用するデプロイメントに対してのみ有効に機能します。

Webアプリケーションのコンテキスト・ルートの優先順位は次のとおりです。

- application.xmlのコンテキスト・ルートがチェックされ、見つかった場合はこれがWebアプリケーションのコンテキスト・ルートとして使用されます。

- コンテキスト・ルートの設定がapplication.xmlになく、WebアプリケーションがEARの一部としてデプロイされる場合、コンテキスト・ルートがweblogic.xmlに定義されているかどうかがチェックされます。見つかった場合、これがWebアプリケーションのコンテキスト・ルートとして使用されます。Webアプリケーションがスタンドアロンとしてデプロイされる場合、application.xmlは使用されず、コンテキスト・ルートのチェックはweblogic.xmlで開始されます。このファイルに定義されていない場合、デフォルトによってURIが使用されます。

- コンテキスト・ルートがweblogic.xmlとapplication.xmlのどちらにも定義されていない場合、コンテキスト・パスはURIから推定され、URIに定義されている値からWAR接尾辞を取り除いた名前が付けられます。たとえば、URIがMyWebApp.warの場合は、MyWebAppという名前が付けられます。

注意:

context-root要素をEARライブラリ内の個々のWebアプリケーションに対して設定することはできません。Webアプリケーション・ライブラリに対してのみ設定できます。

wl-dispatch-policy

wl-dispatch-policy要素を使用して、ワーク・マネージャ名を指定し、Webアプリケーションを構成されたワーク・マネージャに割り当てます。このWebアプリケーション・レベルのパラメータは、個々のサーブレットやjspレベルでper-servlet-dispatch-policy要素を使ってオーバーライドできます。

servlet-descriptor

servlet-descriptor要素を使用して、サーブレット固有の要素を集約します。

次の表では、servlet-descriptor要素内で定義できる要素について説明します。

表B-12 servlet-descriptor要素

要素

必須/省略可能

説明

<servlet-name>

必須

web.xmlデプロイメント記述子ファイルのサーブレット要素に定義されたサーブレット名を指定します。

<run-as-principal-name>

省略可能

web.xmlデプロイメント記述子に定義されたrun-as-role-nameに対するプリンシパル名を含みます。

<init-as-principal-name>

省略可能

サーブレットのinitメソッドのrun-as-principal-nameと同じ。ここに指定するIDはシステムの有効なユーザー名である必要があります。init-as-principal-nameを指定しない場合、コンテナはrun-as-principal-name要素を使用します。

<destroy-as-principal-name>

省略可能

サーブレットのdestroyメソッドのrun-as-principal-nameと同じ。ここに指定するIDはシステムの有効なユーザー名である必要があります。destroy-as-principal-nameを指定しない場合、コンテナはrun-as-principal-name要素を使用します。

<dispatch-policy>

省略可能

この要素は非推奨です。実行キュー名を指定して、ある特定のサーブレットを割り当てるために構成されたexecute-queueに使用します。この設定は、wl-dispatch-policyで定義したWebアプリケーション・レベルのディスパッチ・ポリシーをオーバーライドします。

work-manager

work-manager要素は<weblogic-web-app>要素の下位要素です。work-manager要素の内部には以下の要素を定義できます。

表B-13 work-manager要素

要素

必須/省略可能

説明

name

必須

ワーク・マネージャの名前を指定します。

response-time-request-class / fair-share-request-class / context-request-class / request-class-name

省略可能

以下の4つの要素から選択できます。

- response-time-request-class - アプリケーションのレスポンス時間リクエスト・クラスを定義します。レスポンス時間はgoal-ms属性にミリ秒単位で定義します。増分は((目標値 - T) Cr)/Rです - Tは平均スレッド使用時間、Rは到着率、Crはフェア・シェアよりもレスポンス時間目標値を優先するための係数です。

- fair-share-request-class - フェア・シェア・リクエスト・クラスを定義します。フェア・シェアは、デフォルト・シェアに対する属性値の割合で定義されます。したがって、デフォルトは100です。増分はCf/(P R T)です - Pは割合、Rは到着率、Tは平均スレッド使用時間、Cfはフェア・シェアの優先順位をレスポンス時間目標値よりも低くするための係数です。

- context-request-class - コンテキスト・クラスを定義します。コンテキスト情報(現在のユーザーまたはそのロール、Cookie、作業領域などのフィールド)をサービス・クラス名にマッピングした複数のケースを指定して、コンテキストを定義します。

- request-class-name - リクエスト・クラス名を定義します。

min-threads-constraint、min-threads-constraint-name

省略可能

以下の2つの要素から選択できます。

- min-threads-constraint - 制約対象の作業セットのリクエストに割り当てられるスレッドの数を確保して、デッドロックを回避するために使用します。デフォルトはゼロ。min-threadsの値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に役立ちます。

- min-threads-constraint-name - min-threads-constraint要素の名前を定義します。

max-threads-constraint、max-threads-constraint-name

省略可能

以下の2つの要素から選択できます。

- max-threads-constraint - 制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、統合された3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。

- max-threads-constraint-name - max-threads-constraint要素の名前を定義します。

capacity、capacity-name

省略可能

以下の2つの要素から選択できます。

- capacity - 制約を定義して、「制約対象の作業セット」と呼ばれるエントリ・ポイントのセットに適用できます。この容量に達した場合にのみ、サーバーはリクエストの拒否を開始します。デフォルトはゼロ。容量には、制約対象の作業セットからのすべてのリクエスト(キューにあるリクエストと実行中のリクエスト)が含まれます。この制約は、独自にフロー制御を行うJMSのようなサブシステムを主な対象としています。この制約は、グローバル・キューのしきい値とは無関係。

- capacity-name - capacity要素の名前を定義します。

logging

logging要素は<weblogic-web-app>要素の下位要素です。logging要素の内部には以下の要素を定義できます。

表B-14 logging要素

要素

必須/省略可能

説明

log-filename

必須

ログ・ファイルの名前を指定します。ファイル名は絶対アドレスで指定する必要があります。

logging-enabled

省略可能

ManagedConnectionFactoryまたはManagedConnectionに対してログ・ライターが設定されているかどうかを示します。この要素をtrueに設定すると、ManagedConnectionFactoryまたはManagedConnectionから生成された出力は、log-filename要素で指定したファイルに送られます。

この値を指定しないと、WebLogic Serverでは定義されているデフォルト値が使用されます。

値の範囲: trueまたはfalse

デフォルト値: false

rotation-type

省略可能

ファイルのローテーション・タイプを設定します。

値は、bySize、byTIme、noneです。

- bySize - ログ・ファイルがfile-size-limitに指定したサイズに達すると、ファイル名がFileName.nに変更されます。

- byTIme - file-time-spanに指定した間隔で、ファイル名がFileName.nに変更されます。ファイル名が変更されると、以後のメッセージはlog-filenameに指定した名前の新しいファイルに蓄積されます。

- none - メッセージは1つのファイルに蓄積されます。サイズが大きくなった場合、ファイルの内容を消去する必要があります。

デフォルト値: bySize

number-of-files-limited

省略可能

当該サーバー・インスタンスで、古いメッセージの保存用に作成するファイルの数を制限するかどうかを指定します。(rotation-typeでbySizeを指定する必要があります。)この制限に達すると、最も古いファイルが上書きされます。このオプションを有効にしない場合、新しいファイルが無限に作成されていくため、必要に応じてこれらのファイルを削除する必要があります。

number-of-files-limitedをtrueに設定して有効にした場合、サーバーはrotationType変数を参照してログ・ファイルのローテーション方法を判断します。ローテーションでは、新しいファイルを作成するのではなく、既存のファイルがオーバーライドされます。number-of-files-limitedをfalseに設定すると、サーバーは同じログ・ファイルをオーバーライドしないで、多数のログ・ファイルを作成します。

値の範囲: trueまたはfalse

デフォルト値: false

file-count

省略可能

サーバーがログをローテーションする際に作成するログ・ファイルの最大数。この数には、現在のメッセージを格納するためにサーバーで使用されているファイルは含まれません。(number-of-files-limitedを有効にする必要があります。)

デフォルト値: 7

file-size-limit

省略可能

サーバーがログ・メッセージを別のファイルに移動するきっかけとなるサイズ(rotation-typeでbySizeを指定する必要があります。)ログ・ファイルが指定の最小サイズに到達すると、以後サーバーは、ファイル・サイズをチェックする際に、現在のログ・ファイルの名前をFileName.nに変更し、それ以降のメッセージを保存するための新規ログ・ファイルを作成します。

デフォルト値: 500

rotate-log-on-startup

省略可能

起動サイクル中にサーバーがログ・ファイルをローテーションするかどうかを指定します。

値の範囲: trueまたはfalse

デフォルト値: true

log-file-rotation-dir

省略可能

ローテーションされたログ・ファイルが格納されるディレクトリ・パスを指定します。

rotation-time

省略可能

ログ・ファイルの時間ベースのローテーション・シーケンスの開始時間で、フォーマットはk:mm(ここでkは1 - 24)です。(rotation-typeでbyTimeを指定する必要があります。)指定された時間に、現在のログ・ファイル名が変更されます。以後、file-time-spanで指定した間隔でログ・ファイル名が変更されます。

指定した時間がすでに過ぎている場合、サーバーはただちにファイルのローテーションを開始します。

デフォルトでは、ローテーション・サイクルはただちに開始されます。

file-time-span

省略可能

古いログ・メッセージが別のファイルに移される間隔(単位は時間)。(rotation-typeでbyTimeを指定する必要があります。)

デフォルト値: 24

library-ref

library-ref要素では、現在のWebアプリケーションのWebアプリケーション・ライブラリとして使用されるライブラリ・モジュールを参照します。

例:

<library-ref>
<library-name>WebAppLibraryFoo</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1beta</implementation-version>
<exact-match>false</exact-match>
</library-ref>

Webアプリケーションに関連する下位要素はlibrary-name、specification-version、implementation-version、およびexact-matchのみです。

library-ref要素の内部には以下の要素を定義できます。

表B-15 library-ref要素

要素

必須/省略可能

説明

library-name

必須

ライブラリ・モジュールの参照用にライブラリの名前を提供します。デフォルト値はnullです。

specification-version

省略可能

ライブラリ・モジュールの参照用に仕様のバージョンを提供します。デフォルト値は0です。(これはfloatです。)

implementation-version

省略可能

ライブラリ・モジュールの参照用に実装のバージョンを提供します。デフォルト値はnullです。

exact-match

省略可能

デフォルト値はfalseです。

fast-swap

次の表では、fast-swap要素内で定義できる要素について説明します。

FastSwapデプロイメントの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

表B-16 fast-swap要素

要素

必須/省略可能

説明

<enabled>

省略可能

trueに設定すると、現在のアプリケーションでFastSwapデプロイメントが有効化されます。

<refresh-interval>

省略可能

FastSwapによって、HTTPリクエストの受信時に、アプリケーション・クラスでの変更がチェックされます。refresh-interval秒以内に以降のHTTPリクエストを受信しても、変更はチェックされません。refresh-interval秒が経過して最初のHTTPリクエストの受信時に、クラスの変更チェックが再度実行されます。

<redefinition-task-limit>

省略可能

FastSwapのクラスの再定義は、再定義タスクによって非同期に行われます。再定義タスクは、JMXインタフェースを使用して制御および検査できます。

この要素では、FastSwapシステムで保持される再定義タスクの数を指定します。この制限をタスク数が超えると、古いタスクが自動的に削除されます。

後方互換性フラグ

WebLogic Serverでは、WebLogic Server 9.2以前のリリースに対する後方互換性はjsp-descriptor要素のbackward-compatible要素を介してサポートされます。

JSP 2.0 Webアプリケーションとの互換性

JSP 2.1はWebLogic Server 10.0からサポートされています。Webアプリケーションのバージョン(バージョン2.4または2.5)とweblogic.xml記述子ファイルのbackward-compatible要素の設定によっては、JSP 2.0もWeblogic Serverでサポートされます。

JSPの動作とバッファ接尾辞

- Webアプリケーションのバージョンが2.5であり(たとえば、web.xmlに2.5のバージョン属性があり)、かつ、backward-compatibilityフラグがfalseに設定されている場合は:

- バージョン2.1のすべてのJSP/TAGファイルは新しいJSP動作に従います。

- バージョン2.0以前のすべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。

- Webアプリケーションのバージョンが2.5であり、かつ、backward-compatibilityフラグがtrueに設定されている場合、すべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。

- Webアプリケーションのバージョンが2.4以前である場合は、backward-compatibilityフラグの設定に関係なく、すべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。

Servlet 2.5パッケージの暗黙的なインポート

Servlet 2.5仕様では、java.lang.*、javax.servlet.*、javax.servlet.jsp.*、およびjavax.servlet.http.*パッケージのみが暗黙的にインポートされると規定されています。Servlet 2.5仕様に準拠して、WebLogic Serverではこれらの規定されているパッケージのみがインポートされます。一方、WebLogic Serverの以前のリリースでは、java.io.*、java.util.*、およびjavax.servlet.jsp.tagext.*パッケージもインポートされていました。

以下のいずれかの状態である場合、WebLogic Serverは2.4以前の動作に従い、上記の規定されていないパッケージもインポートします。

- weblogic.xml記述子ファイルのbackward-compatibleフラグがtrueに設定されています。

- Webアプリケーションのバージョンが2.4以前です。

- バージョン2.5のWebアプリケーションにある個々のJSP/TAGファイルがバージョン2.0以前です。

Webコンテナのグローバル構成

Webコンテナをグローバル・レベルで構成するには、WebAppContainerMBeanを使用します。WebAppContainerMBean属性の詳細と、この属性を使用してすべてのWebアプリケーションに対しドメイン全体のデフォルトを指定する方法については、「WebAppContainerMBean」を参照してください。

C GlassFishデプロイメント記述子のサポート

WebLogic Serverでは、GlassFishデプロイメント記述子のサブセットをサポートしています。このため、GlassFish Server上にデプロイされて動作する基本的なWebアプリケーションをWebLogic Serverにデプロイできます。

Webアプリケーションにweblogic.xmlとglassfish-web.xmlまたはsun-web.xmlの両方が存在する場合、WebLogic Serverではweblogic.xmlが使用され、GlassFishデプロイメント記述子は無視されます。Webアプリケーションにglassfish-web.xmlとsun-web.xmlの両方が存在する場合、WebLogic Serverではglassfish-web.xmlが使用され、sun-web.xmlは無視されます。

GlassFish要素が、表C-1に示されているサポート対象のデプロイメント記述子のリストにある場合、WebLogic Serverではweblogic.xml内の対応する要素の設定が使用されます。この要素がサポート対象のデプロイメント記述子のリストにない場合、WebLogic Serverではこの要素が無視されます。

glassfish-web.xmlまたはsun-web.xmlが使用されている場合、WebLogic Serverでは、情報レベルのログ・メッセージ(個々の設定が使用されるか、無視されるかなど)が発行されます。WebLogic Serverでは、対応するweblogic.xml記述子要素の生成も永続化も行われません。

表C-1 サポートされているGlassFishデプロイメント記述子

glassfish-web.xml要素名

対応するweblogic.xml要素名

context-root

context-root

security-role-mapping

- role-name

- principal-name

- group-name

security-role-assignment

- role-name

- principal-name

- principal-name

session-config

- session-manager:manager-properties:reapIntervalSeconds

- session-manager:manager-properties:maxSessions

- session-manager:store-properties:directory

- session-properties:timeoutSeconds

session-descriptor

- invalidation-interval-seconds

- max-in-memory-sessions

- persistent-store-dir

- timeout-secs

ejb-ref

- ejb-ref-name

- jndi-name

ejb-reference-description

- ejb-ref-name

- jndi-name

resource-ref

- res-ref-name

- jndi-name

resource-description

- res-ref-name

- jndi-name

resource-env-ref

- resource-env-ref-name

- jndi-name

resource-env-description

- resource-env-ref-name

- jndi-name

class-loader

- delegate

container-descriptor

- prefer-web-inf-classes

jsp-config

- checkInterval

- keepgenerated

- scratchdir

jsp-descriptor

- page-check-seconds

- keepgenerated

- working-dir

D Webアプリケーションのベスト・プラクティス

次の項では、WebLogic Webアプリケーションとアプリケーション・リソースの設計、開発、およびデプロイにおけるベスト・プラクティスを紹介します。

- CGIのベスト・プラクティス

- サーブレットのベスト・プラクティス

- JSPのベスト・プラクティス

- ServletResponseWrapperをサブクラス化する際のベスト・プラクティス

CGIのベスト・プラクティス

サブスクリプトの呼出しに関するCGIのベスト・プラクティスを次に示します。

- sh subscript.shは、展開(非アーカイブ) WebアプリケーションおよびアーカイブWebアプリケーション(WARファイル)の両方に使用できます。

- sh $PWD/subscript.shは、展開(非アーカイブ) WebアプリケーションおよびアーカイブWebアプリケーション(WARファイル)の両方に使用できます。

- sh $DOCUMENT_ROOT/$PATH/subscript.shは、展開(非アーカイブ) Webアプリケーションに使用できます。アーカイブWebアプリケーション(WARファイル)には使用できません。これは、ドキュメント・ルートがお使いのWARファイルのルートを指している場合があり、スクリプト言語でそのWARファイルを開いて実行に必要なsubscript.shを検出できないことがあるためです。これはshのみでなく、すべてのスクリプト言語に当てはまります。

サーブレットのベスト・プラクティス

HTTPサーブレットを作成する際は、次のベスト・プラクティスについて検討します。

- サーブレット・クラスは、WebアプリケーションのWEB-INF/classesディレクトリにコンパイルします。

- サーブレットは、必ずJava EE標準のWebアプリケーション・デプロイメント記述子(web.xml)に登録します。

- サーブレットのリクエストへの応答時には、サーブレットに関連するフィルタを適用する前にサーブレット・クラス・ファイルのタイム・スタンプがチェックされ、メモリー内にある既存のサーブレット・インスタンスと比較されます。バージョンの新しいサーブレット・クラスがある場合、すべてのサーブレット・クラスが再ロードされてからフィルタ処理が行われます。サーブレットが再ロードされると、そのサーブレットのinit()メソッドが呼び出されます。変更後のサーブレット・クラスが検出された場合、サーブレット・クラス間に依存関係が存在する可能性があるため、すべてのサーブレットが再ロードされます。
サーブレット・リロード属性のタイム・スタンプがWebLogic Serverによってチェックされる間隔(秒単位)を設定できます。この属性は、管理コンソールのWebアプリケーションの「ファイル」タブで設定します。この属性をゼロに設定すると、WebLogic Serverによって、リクエストごとにタイム・スタンプがチェックされます。これはサーブレットの開発中やテスト中には便利ですが、本番環境では必要以上に時間が消費されます。この属性を-1に設定すると、変更されたサーブレットについてのチェックがWebLogic Serverで行われません。

JSPのベスト・プラクティス

JSPの再コンパイルを回避する方法の詳細は、「Avoiding Unnecessary JSP Compilation」(http://www.oracle.com/technology/index.html)の、特に「Scenarios that Cause Recompilation of JSPs」の項を参照してください。

ServletResponseWrapperをサブクラス化する際のベスト・プラクティス

Java EEでは、javax.servlet.ServletResponseWrapperクラスが用意されています。このクラスはサーブレットでサブクラス化して、そのレスポンスに適合させることができます。

ServletResponseWrapperクラスをサブクラス化して独自のレスポンス・ラッパーを作成する場合、flushBuffer()メソッドとresetBuffer()メソッドを常にオーバーライドすることをお薦めします。そうしない場合、レスポンスが早まって行われる可能性があります。

Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved.