Oracle® Fusion Middleware

Oracle WebLogic Serverアプリケーションの開発

12c (12.2.1.1.0)

E77261-01(原本部品番号:E72115-01)

2016年6月

このドキュメントは、Java Platform, Enterprise Edition 6を使用してWebLogic Server E-コマース・アプリケーションのビルドについて説明します。

Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発, 12c (12.2.1.1.0)

E77261-01

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

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

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

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

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

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

目次

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

はじめに

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

- 表記規則

1 WebLogic Serverアプリケーション開発の概要

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

- WebLogic ServerとJava EEプラットフォーム

- Java EEアプリケーションとモジュールの概要

- Webアプリケーション・モジュール

- サーブレット

- JavaServer Pages

- Webアプリケーション・モジュールの詳細

- Enterprise JavaBeanモジュール

- WebLogic ServerでのEJBドキュメント

- EJBに関する追加情報

- コネクタ・モジュール

- エンタープライズ・アプリケーション

- Java EEプログラミング・モデル

- パッケージ化とデプロイメントの概要

- WebLogic Webサービス

- JMSおよびJDBCモジュール

- WebLogic診断フレームワーク・モジュール

- 外部診断記述子の使用

- 外部診断記述子を定義する

- Coherence Grid Archive (GAR)モジュール

- Beanの検証

- XMLデプロイメント記述子

- デプロイメント記述子の自動生成

- EJBGen

- Javaベースのコマンド・ライン・ユーティリティ

- 以前のリリースのJava EEおよびWebLogic Serverのデプロイメント記述子のアップグレード

- デプロイメント・プラン

- 開発ツール

- Java APIリファレンスおよびwls-api.jarファイル

- wls-api.jarファイルの使用

- weblogic.jarファイルの使用

- Apache Ant

- サード・パーティ・バージョンのAntの使用方法

- Antのヒープ・サイズの変更

- ソース・コード・エディタまたはIDE

- データベース・システムとJDBCドライバ

- Webブラウザ

- サード・パーティ・ソフトウェア

- このリリースでの新機能と変更された機能

2 Antタスクを使用したWebLogic Serverドメインの構成と使用

- Antタスクを使用したドメインの構成と起動についての概要

- wlserver Antタスクを使用したサーバーの起動とドメインの作成

- wlserverを使用する基本的な手順

- wlserver用build.xmlファイルのサンプル

- wlserver Antタスク・リファレンス

- wlconfig Antタスクを使用したWebLogic Serverドメインの構成

- wlconfig Antタスクの機能

- wlconfigを使用する基本的な手順

- wlconfig Antタスク・リファレンス

- 主な属性

- ネストされる要素

- create

- delete

- set

- get

- query

- invoke

- wlconfig Antタスクを使用したセキュリティ・レルムの作成の例

- libclasspath Antタスクの使用

- libclasspathタスクの定義

- libclasspath Antタスク・リファレンス

- libclasspathの主な属性

- ネストされるlibclasspathの要素

- librarydir

- library

- libclasspath Antタスクの例

3 WebLogic Mavenプラグインの使用方法

- Mavenのインストール

- WebLogic Mavenプラグインの構成

- WebLogic Mavenプラグインの使用方法

- 基本構成POMファイル

- Mavenプラグインのゴール

- appc

- create-domain

- deploy

- distribute-app

- install

- list-apps

- purge-tasks

- redeploy

- remove-domain

- start-app

- start-server

- stop-app

- stop-server

- undeploy

- uninstall

- update-app

- wlst

- wlst-client

- ws-clientgen

- wsgen

- wsimport

- ws-wsdlc

- ws-jwsc

4 分割開発ディレクトリ環境の作成

- 分割開発ディレクトリ環境の概要

- ソース・ディレクトリとビルド・ディレクトリ

- 分割開発ディレクトリからのデプロイメント

- 分割開発ディレクトリにおけるAntタスク

- 分割開発ディレクトリ構造の使用: 主な手順

- 分割開発ディレクトリでのJava EEコンポーネントの配置

- ソース・ディレクトリの概要

- エンタープライズ・アプリケーションの構成

- Webアプリケーション

- EJB

- EJBの記述子に関する重要な注意事項

- 分割開発ディレクトリでの共有クラスの配置

- 共有ユーティリティ・クラス

- サード・パーティ・ライブラリ

- 共有クラスのクラス・ローディング

- weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成

- weblogic.BuildXMLGen構文

- 分割開発ディレクトリを使用した複数EARプロジェクトの開発

- 複数のEARで共有されるライブラリとクラスの配置

- 複数のbuild.xmlファイルのリンク

- WebLogic Serverアプリケーション開発のベスト・プラクティス

5 分割開発ディレクトリでのアプリケーションのビルド

- wlcompileを使用したアプリケーションのコンパイル

- includesおよびexcludesプロパティの使い方

- wlcompile Antタスクの属性

- ネストされたjavacオプション

- コード・コンパイル用のクラスパスの設定

- wlcompileとwlappcのライブラリ要素

- wlappcを使用したモジュールおよびアプリケーションのビルド

- wlappc Antタスクの属性

- wlappc Antタスクの構文

- appcおよびwlappcにおける構文の違い

- weblogic.appcリファレンス

- weblogic.appcの構文

- weblogic.appcのオプション

6 分割開発ディレクトリからのデプロイメントとパッケージ化

- wldeployを使用したアプリケーションのデプロイメント

- wlpackageを使用したアプリケーションのパッケージ化

- アーカイブと展開されたアーカイブ・ディレクトリ

- wlpackage Antタスクの例

- wlpackage Antタスクの属性のリファレンス

7 本番再デプロイメント用アプリケーションの開発

- 本番再デプロイメントとは

- サポートされているアプリケーションとサポートされていないアプリケーションの種類

- 追加アプリケーション・サポート

- プログラミングの要件と規約

- アプリケーションが自己完結型であることが必要

- バージョン管理されているアプリケーションが現在のバージョンのJNDIツリーにデフォルトでアクセスすることが必要

- セキュリティ・プロバイダに互換性があることが必要

- アプリケーションがバージョン識別子を指定することが必要

- アプリケーションが名前と識別子にアクセスできることが必要

- クライアント・アプリケーションが可能な限り同じバージョンを使用することが必要

- アプリケーションのバージョンの割当て

- アプリケーションのバージョンの規約

- アプリケーションのアップグレードによる本番再デプロイメントの使用

- バージョン情報へのアクセス

8 Java EE注釈と依存関係インジェクションの使用

- アノテーションの処理

- アノテーションの解析

- アノテーション構成のデプロイメント表示

- アノテーション付きクラスのコンパイル

- アノテーションの動的な更新

- リソースの依存関係インジェクション

- アプリケーション・ライフ・サイクル・アノテーション・メソッド

- 標準のJDKアノテーション

- javax.annotation.PostConstruct

- javax.annotation.PreDestroy

- javax.annotation.Resource

- javax.annotation.Resources

- 標準のセキュリティ関連JDKアノテーション

- javax.annotation.security.DeclareRoles

- javax.annotation.security.DenyAll

- javax.annotation.security.PermitAll

- javax.annotation.security.RolesAllowed

- javax.annotation.security.RunAs

9 Contexts and Dependency Injection for the Java EE Platformの使用方法

- CDI for the Java EE Platformについて

- マネージドBeanの定義

- Beanの注入

- Beanのスコープの定義

- 注入ポイントでのBeanのスコープのオーバーライド

- 修飾子の使用方法

- Beanタイプの実装に対する修飾子の定義

- Beanへの修飾子の適用

- 修飾Beanの注入

- Beanタイプの代替の実装の提供

- Beanタイプの代替の実装の定義

- アプリケーションに対するBeanタイプの代替の実装の選択

- セッションBeanへのスコープと修飾子の適用

- セッションBeanへのスコープの適用

- セッションBeanへの修飾子の適用

- プロデューサ・メソッド、ディスポーザ・メソッド、およびプロデューサ・フィールドの使用方法

- プロデューサ・メソッドの定義

- ディスポーザ・メソッドの定義

- プロデューサ・フィールドの定義

- マネージドBeanの初期化と破棄の準備

- マネージドBeanの初期化

- マネージドBeanの破棄の準備

- Beanクラスのメソッド呼出しおよびライフ・サイクル・イベントのインターセプト

- インターセプタ・バインディング・タイプの定義

- インターセプタ・クラスの定義

- インターセプトのためのメソッドの特定

- インターセプタの有効化

- マネージドBeanクラスの装飾

- デコレータ・クラスの定義

- デコレータ・クラスの有効化

- CDI BeanクラスへのEL名の割当て

- ステレオタイプの定義と適用

- ステレオタイプの定義

- Beanへのステレオタイプの適用

- Bean間の通信のためのイベントの使用方法

- イベント・タイプの定義

- イベントの送信

- イベントの処理

- 事前定義済Beanの注入

- リソースの注入と修飾

- JCAテクノロジでのCDIの使用方法

- CDIアプリケーションの構成

- サード・パーティのポータブルな拡張のサポート

- 暗黙的Beanの検出の有効化と無効化

10 Java API for JSON Processing

- JavaScript Object Notation (JSON)について

- オブジェクト・モデルAPI

- JSONデータからのオブジェクト・モデルの作成

- アプリケーション・コードからのオブジェクト・モデルの作成

- オブジェクト・モデルの参照

- ストリームへのオブジェクト・モデルの書込み

- ストリーミングAPI

- パーサーを使用したJSONデータの読取り

- ジェネレータを使用したJSONデータの書込み

11 WebLogic Serverアプリケーションのクラスローディングの理解

- Javaのクラスローディング

- Javaクラスローダーの階層

- クラスのロード

- prefer-web-inf-classes要素

- 実行中プログラムのクラス変更

- ポリシー・クラスローダーを使用したクラス・キャッシング

- WebLogic Serverアプリケーションのクラスローディング

- WebLogic Serverアプリケーションのクラスローディングの概要

- アプリケーション・クラスローダーの階層

- カスタム・モジュール・クラスローダーの階層

- クラスローダーの階層の宣言

- ユーザー定義のクラスローダーの制約

- サーブレット再ロードの無効化

- ネスティングの深さ

- モジュール・タイプ

- 重複エントリ

- インタフェース

- call-by-valueセマンティクス

- 処理中の作業

- 開発用途のみ

- 実装クラスのための個々のEJBクラスローダー

- アプリケーション・クラスローディングと、値渡しまたは参照渡し

- フィルタリング・クラスローダーの使用

- フィルタリング・クラスローダーとは

- フィルタリング・クラスローダーの構成

- リソースのロード順序

- モジュールおよびアプリケーション間のクラス参照の解決

- リソース・アダプタ・クラス

- 共有ユーティリティ・クラスのパッケージ化

- マニフェスト・クラスパス

- クラスローダー分析ツール(CAT)の使用

- CATインタフェースの開始

- CATによるクラス分析の方法

- マニフェスト階層を介したクラス参照の確認

- Java EEライブラリを使用したアプリケーションとモジュールの共有

- ドメイン/libディレクトリへのJARの追加

12 共有Java EEライブラリおよびオプション・パッケージの作成

- 共有Java EEライブラリおよびオプション・パッケージの概要

- オプション・パッケージ

- ライブラリ・ディレクトリ

- ライブラリのバージョニングのサポート

- 共有Java EEライブラリとオプション・パッケージの比較

- 補足情報

- 共有Java EEライブラリの作成

- 共有Java EEライブラリ・ファイルの作成

- オプション・パッケージ・クラス・ファイルの作成

- 共有Java EEライブラリのマニフェスト属性の編集

- 配布およびデプロイメント用共有Java EEライブラリのパッケージ化

- エンタープライズ・アプリケーションでの共有Java EEライブラリの参照

- 参照されたエンタープライズ・ライブラリ内のcontext-rootのオーバーライド

- スタンドアロン・モジュールとしてデプロイされた共有Java EEライブラリのURI

- Java EEアプリケーションまたはモジュールからのオプション・パッケージの参照

- weblogic.appmergeを使用したライブラリの結合

- CLIからのweblogic.appmergeの使用

- Antタスクとしてのweblogic.appmergeの使用

- 分割開発ディレクトリ環境への共有Java EEライブラリの統合

- 共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ

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

- WebアプリケーションにおけるWebアプリケーション・ライブラリの使用

- LibraryRuntimeMBeanに登録された共有Java EEライブラリ情報へのアクセス

- 共有Java EEライブラリの参照時のモジュールの優先順位

- 共有Java EEライブラリを使用する場合のベスト・プラクティス

13 アプリケーション・ライフ・サイクル・イベントのプログラミング

- アプリケーション・ライフサイクル・イベントの理解

- weblogic-application.xmlへのイベントの登録

- 基本的なライフサイクル・リスナー機能のプログラミング

- ロール・ベースのアプリケーション・ライフ・サイクル・リスナーの構成

- URIパラメータを指定した場合と指定しない場合のライフサイクル・イベントの構成例

- 再デプロイメント時のアプリケーション・ライフサイクル・イベントの動作の理解

- アプリケーション・バージョン・ライフサイクル・イベントのプログラミング

- アプリケーション・バージョン・ライフサイクル・イベントの動作の理解

- アプリケーション・バージョン・ライフサイクル・イベントの種類

- アプリケーション・バージョン・ライフサイクル・イベントを使用する場合の本番デプロイメント・シーケンスの例

14 コンテキスト伝播のプログラミング

- コンテキストの伝播の理解

- コンテキスト伝播のプログラミング: 主な手順

- クライアントのコンテキスト伝播のプログラミング

- アプリケーションのコンテキスト伝播のプログラミング

15 WebLogic ServerでのJavaMailのプログラミング

- WebLogic ServerアプリケーションでのJavaMailの使用の概要

- JavaMail構成ファイルの理解

- WebLogic Server用のJavaMailの構成

- JavaMailを使用したメッセージの送信

- JavaMailを使用したメッセージの読込み

16 トピックのスレッド化とクラスタリング

- WebLogic Serverでのスレッドの使用

- ワーク・マネージャAPIを使用した低レベルなスレッド化

- WebLogic Serverクラスタのアプリケーションのプログラミング

17 WebLogic Serverアプリケーション用のOSGiバンドルの開発

- OSGiの理解

- WebLogic Server OSGiの実装に提供されている機能

- OSGiフレームワークの構成

- OSGiフレームワーク・インスタンスの構成

- 管理コンソールからのOSGiフレームワーク・インスタンスの構成

- config.xmlからのOSGiフレームワーク・インスタンスの構成

- WLSTからのOSGiフレームワーク・インスタンスの構成

- JavaプログラムからのOSGiフレームワーク・インスタンスの構成

- フレームワークにバンドルをインストールする際に必要なパラメータ

- OSGiフレームワーク永続性の構成

- OSGiサービスの使用

- OSGiバンドルの作成

- OSGiバンドルのデプロイ

- ターゲット・システムにOSGiバンドルをデプロイする準備

- エンタープライズ・アプリケーションとしてバンドルをデプロイする準備

- Webアプリケーションとしてバンドルをデプロイする準備

- グローバル・ワーク・マネージャ

- グローバル・データ・ソース

- osgi-libディレクトリへのOSGiバンドルのデプロイ

- バンドルに対する起動レベルと実行レベルの設定

- JNDIからのデプロイされたバンドル・オブジェクトへのアクセス

- WebLogic Serverを経由したOSGiロギングの使用

- OSGiバンドル用のフィルタリング・クラスローダーの構成

- OSGIのサンプル

18 WebLogic ServerでのWebSocketプロトコルの使用方法

- WebSocketプロトコルの理解

- HTTPリクエスト/レスポンス・モデルの限界

- WebSocketエンドポイント

- WebSocketプロトコルのハンドシェイク・リクエスト

- WebSocketプロトコルのメッセージングとデータ転送

- WebLogic ServerのWebSocketの実装の理解

- WebSocketプロトコルの実装

- WebLogic WebSocket Java API

- WebSocketメッセージングのプロトコル・フォールバック

- WebSocketサンプル・アプリケーション

- WebSocketアプリケーションの作成の概要

- エンドポイントの作成

- アノテーション付きエンドポイントの作成

- プログラム的なエンドポイントの作成

- アプリケーション内でのプログラム的なエンドポイントへのパスの指定

- WebSocket接続のライフサイクル・イベントの処理

- アノテーション付きWebSocketエンドポイントでのライフサイクル・イベントの処理

- Connection openedイベントの処理

- Message receivedイベントの処理

- Errorイベントの処理

- Connection closedイベントの処理

- プログラム的なWebSocketエンドポイントでのライフサイクル・イベントの処理

- WebSocketエンドポイントでのリソースの定義、注入およびアクセス

- メッセージの送信

- エンドポイントの単一ピアへのメッセージ送信

- エンドポイントのすべてのピアへのメッセージ送信

- WebSocketエンドポイントのスレッド・セーフティの確保

- WebSocketメッセージのエンコーディングとデコーディング

- WebSocketメッセージとしてのJavaオブジェクトのエンコーディング

- JavaオブジェクトとしてのWebSocketメッセージのデコーディング

- エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する方法

- クライアントの状態の管理

- サーバー・エンドポイントのプログラムによる構成

- Java API for WebSocketを使用するアプリケーションの構築

- WebSocketアプリケーションのデプロイ

- WebSocketアプリケーションの監視

- プロキシ・サーバーでのWebSocketの使用

- WebSocketクライアントの記述

- ブラウザ・ベースのWebSocketクライアントの記述

- Java WebSocketクライアントの記述

- WebSocketクライアント・エンドポイントのプログラムによる構成

- Java WebSocketクライアントのサーバー・エンドポイントへの接続

- WebSocketクライアントからメッセージをディスパッチするための最大スレッド数の設定

- WebSocketアプリケーションの保護

- 検証済の生成元ポリシーの適用

- WebSocketクライアントの認証と認可

- WebSocketクライアントの認証

- セキュアなWebSocket接続の確立

- 複合コンテンツの回避

- WebSocket接続に対する制限の指定

- WebSocketメッセージングのプロトコル・フォールバックの有効化

- クライアント・アプリケーションでJavaScript API for WebSocketフォールバックを使用する方法

- WebSocketフォールバックの構成

- WebSocketオブジェクトの作成

- JavaScript WebSocketクライアントのライフサイクル・イベントの処理

- JavaScript WebSocketクライアントからのメッセージの送信

- WebSocketフォールバックのクライアント・ライブラリのパッケージ化と場所の指定

- WebSocketフォールバックの有効化

- 非推奨のAPIからJSR 356 Java API for WebSocketへのアプリケーションの移行

- JSR 356 APIと固有のWebLogic Server WebSocket APIとの比較

- 固有のWebSocketサーバー・エンドポイントで使用するAPIをJSR 356 APIに変換する方法

- パスのパターン文字列の/*接尾辞の置換え

- エンドポイントURIの変数パス・パラメータを表す/*接尾辞の置換え

- エンドポイントの追加データを表す/*接尾辞の置換え

- 固有のWebSocketサーバー・エンドポイントで使用するAPIをJSR 356 APIに変換する例

- WebLogic ServerでのJava API for WebSocketの使用例

A エンタープライズ・アプリケーションのデプロイメント記述子の要素

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

- weblogic-application

- ejb

- entity-cache

- max-cache-size

- xml

- parser-factory

- entity-mapping

- jdbc-connection-pool

- connection-factory

- pool-params

- driver-params

- security

- application-param

- classloader-structure

- listener

- singleton-service

- startup

- shutdown

- work-manager

- session-descriptor

- library-ref

- library-context-root-override

- fast-swap

- weblogic-application.xmlスキーマ

- application.xmlスキーマ

B wldeploy Antタスクのリファレンス

- wldeploy Antタスクの概要

- wldeployを使用する基本手順

- wldeploy用build.xmlファイルのサンプル

- wldeploy Antタスクの属性のリファレンス

- 主な属性

- ネストされた<files>子要素

はじめに

ここでは、このガイド『Oracle WebLogic Serverアプリケーションの開発』で使用されるドキュメントのアクセシビリティ機能と表記規則について説明します。

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

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 WebLogic Serverアプリケーション開発の概要

この章ではWebLogic Server アプリケーションと基本概念について概説します。

この章の内容は次のとおりです。

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

- WebLogic ServerとJava EEプラットフォーム

- Java EEアプリケーションとモジュールの概要

- Webアプリケーション・モジュール

- Enterprise JavaBeanモジュール

- コネクタ・モジュール

- エンタープライズ・アプリケーション

- WebLogic Webサービス

- JMSおよびJDBCモジュール

- WebLogic診断フレームワーク・モジュール

- Coherence Grid Archive (GAR)モジュール

- Beanの検証

- XMLデプロイメント記述子

- デプロイメント・プラン

- 開発ツール

- このリリースでの新機能と変更された機能

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

このドキュメントは、Java Platform, Enterprise Edition (Java EE)を使用してWebLogic Serverアプリケーションをビルドするアプリケーション開発者を対象としています。Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。

WebLogic Serverアプリケーションは、Javaプログラマ、Webデザイナ、アプリケーション・アセンブラによって作成されます。プログラマとデザイナは、アプリケーションのビジネス・ロジックとプレゼンテーション・ロジックを実装するモジュールを作成します。アプリケーション・アセンブラは、WebLogic Serverにデプロイ準備完了のアプリケーションにモジュールをアセンブルします。

WebLogic ServerとJava EEプラットフォーム

WebLogic Serverは、Java Platform, Enterprise Edition (Java EE)バージョン7.0技術を実装しています(http://www.oracle.com/technetwork/java/javaee/overview/index.htmlを参照)。Java EEは、Javaプログラミング言語に基づいた多層エンタープライズ・アプリケーションを開発するための標準プラットフォームです。Java EEを構成する技術は、いくつかのソフトウェア・ベンダーによって共同開発されました。

Java EE 7プログラミング・モデル: 生産性の向上

Java EEプログラミング・モデルの重要な点は、メタデータ・アノテーションの継続される進化です。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョンで必要だったデプロイメント記述子にかわるものです。

Java EE 7では、開発の容易さに焦点を当て続けています。記述する必要があるコードが少なくなりました。定型コードの多くは削除され、可能なかぎりデフォルト値が使用され、アノテーションを広範に使用することによって、デプロイメント記述子の必要性が低減されています。また、開発ツールの改善およびオープン・ソースのサポートにより、開発者の選択肢が広がり、開発環境の作成が容易になりました。WebLogic Serverでサポートされているすべての新しいJava EE 7アップデートの詳細は、『Oracle WebLogic Serverの新機能 12.2.1』の「Java EE 7サポート」を参照してください。

WebLogic ServerおよびJava EEアプリケーション

WebLogic Server Java EEアプリケーションは、標準化され、モジュール化されたコンポーネントに基づいています。WebLogic Serverでは、これらのモジュール用にあらゆるサービスが用意され、細かなアプリケーションの動作を、プログラミングを必要とせずに自動的に処理します。Java EEでは、モジュールの動作とパッケージ化が汎用的で移植性の高い方法で定義されています。このため、実行時構成はモジュールを実際にアプリケーション・サーバーにデプロイするときに行います。

Java EEには、Webアプリケーション、EJBモジュール、Webサービス、エンタープライズ・アプリケーション、クライアント・アプリケーション、およびコネクタのデプロイメント仕様が含まれています。Java EEでは、どのようにアプリケーションをターゲット・サーバーにデプロイするかは指定されておらず、標準のモジュールまたはアプリケーションをパッケージ化する方法のみが指定されています。この仕様では、モジュールのタイプごとに必要なファイルとそれらのディレクトリ構造上の格納場所が定義されています。

Javaはプラットフォームに依存しないので、任意のプラットフォームでコードの編集とコンパイルを行い、別のプラットフォームで稼働する開発用WebLogic Serverでアプリケーションをテストできます。たとえば、WebLogic ServerアプリケーションをWindowsまたはLinuxが動作しているPCで開発する場合、そのアプリケーションが最終的にどこにデプロイされるかを考慮する必要はありません。

詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.htmlのJava EE仕様を参照してください。

Java EEアプリケーションとモジュールの概要

WebLogic Server Java EEアプリケーションは、WebLogic Server上で動作する以下のモジュールまたはアプリケーションのいずれかを含みます。

- Webアプリケーション・モジュール - HTMLページ、サーブレット、JavaServer Pages、および関連ファイル。「Webアプリケーション・モジュール」を参照してください。

- Enterprise JavaBeans (EJB)モジュール - エンティティBean、セッションBean、およびメッセージドリブンBean。「Enterprise JavaBeanモジュール」を参照してください。

- コネクタ・モジュール - リソース・アダプタ。「コネクタ・モジュール」を参照してください。

- エンタープライズ・アプリケーション - アプリケーションにパッケージ化されたWebアプリケーション・モジュール、EJBモジュール、リソース・アダプタ、およびWebサービス。「エンタープライズ・アプリケーション」を参照してください。

- Webサービス - 「WebLogic Webサービス」を参照してください。

WebLogicアプリケーションには、以下のWebLogic固有のモジュールを含めることもできます。

- JDBCおよびJMSモジュール - 「JMSおよびJDBCモジュール」を参照してください。

- Weblogic診断フレームワーク(WLDF)モジュール - 「WebLogic診断フレームワーク・モジュール」を参照してください。

- Coherence Grid Archive (GAR) モジュール - 「Coherence Grid Archive (GAR)モジュール」を参照してください

Webアプリケーション・モジュール

WebLogic ServerのWebアプリケーションには、以下のファイルが含まれています。

- 少なくとも1つのサーブレットまたはJSP、およびヘルパー・クラス。

- 必要に応じて、web.xmlデプロイメント記述子(WARファイルの内容を記述するJava EE標準のXMLドキュメント)。

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

- Webアプリケーションには、HTMLページおよびXMLページ、およびそれらに付属する画像やマルチメディア・ファイルなどのサポート・ファイルが含まれている場合もあります。

サーブレット

サーブレットはWebLogic Serverで実行されるJavaクラスであり、クライアントからリクエストを受け取り、そのリクエストを処理して、必要に応じてクライアントにレスポンスを返します。HttpServletは主に、Webブラウザのリクエストに応えて動的なWebページを生成するために使用します。

JavaServer Pages

JavaServer Pages (JSP)は、JavaコードをWebページに埋め込むことができる拡張HTMLで記述されたWebページです。JSPでは、HTMLに似たタグを使用して、タグ・ライブラリと呼ばれるカスタムJavaクラスを呼び出すことができます。appcコンパイラは、JSPをコンパイルし、サーブレットに変換します。WebLogic Serverでは、サーブレット・クラス・ファイルが存在しないか、またはJSPソース・ファイルよりもタイムスタンプが古い場合にJSPが自動的にコンパイルされます。「wlappcを使用したモジュールおよびアプリケーションのビルド」を参照してください。

サーバーでのコンパイルを避けるために、あらかじめJSPをコンパイルし、サーブレット・クラスをWebアプリケーション(WAR)ファイルにパッケージ化することもできます。サーブレットおよびJSPでは、Webアプリケーションと共にデプロイするヘルパー・クラスがさらに必要な場合があります。

Webアプリケーション・モジュールの詳細

以下のドキュメントを参照してください。

- 分割開発ディレクトリでのJava EEコンポーネントの配置

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

- Oracle WebLogic Server用のJSPタグ拡張の開発

Enterprise JavaBeanモジュール

Enterprise JavaBeans (EJB) テクノロジは、コンポーネントベースのビジネス・アプリケーションを開発およびデプロイするためのサーバー側コンポーネント・アーキテクチャです。EJBテクノロジを使用することで、Java EE 8テクノロジに基づいて、安全でポータブルな分散トランザクション・アプリケーションを迅速かつ容易に開発できます。

EJB 3.3仕様では、プログラミングおよびパッケージ化モデルの変更が簡素化されています。前のバージョンのJavaインタフェースを使用する必要がなくなり、プレーンな従来型Javaオブジェクトに注釈付けし、EJBコンポーネントとして使用できるようになりました。EJBモジュールをWebアプリケーションの内部に直接配置できるようになり、簡素化はさらに進みました。これにより、WebコンポーネントおよびEJBコンポーネントを格納するアーカイブを作成して、それらをEARファイルに結合する必要はなくなりました。

WebLogic ServerでのEJBドキュメント

WebLogic ServerでEJBを使用する方法については、次を参照してください。

- EJBのすべての新機能については、『Oracle WebLogic Server Enterprise JavaBeansの開発』の「EJBでの新しい機能と変更」を参照してください。

- 基本的なEJBの概念とコンポーネントの詳細は、『Oracle WebLogic Serverの理解』の「Enterprise Java Beans (EJB)」を参照してください。

- WebLogic Serverでの3.1 EJBのプログラミング、パッケージ化およびデプロイについては、『Oracle WebLogic Server Enterprise JavaBeansの開発』を参照してください。

- 分割されたディレクトリ環境でWebLogic Server EJBを編成およびビルドする手順については、分割開発ディレクトリ環境の作成を参照してください。

- 2.x EJBのプログラム作成およびパッケージ化の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』を参照してください。

EJBに関する追加情報

エンタープライズBeanの利点、エンタープライズBeanの種類、ライフサイクルなどのEJBの概念を学習するには、次のWebサイトを参照してください。

- EJB 3.2仕様(JSR-345)(http://jcp.org/en/jsr/summary?id=345)

- Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/partentbeans.htm#BNBLR)の「エンタープライズBeans」の章

- Java EE 7プラットフォームの概要: パート3 (EJB Technology, Even Easier to Use)(http://www.oracle.com/technetwork/articles/javaee/javaee7overview-part3-139660.html#ejbeasy)

コネクタ・モジュール

コネクタ(別称リソース・アダプタ)にはJava、および必要に応じてエンタープライズ情報システム(EIS)と対話するために必要なネイティブ・モジュールが含まれています。WebLogic Server環境にデプロイされたリソース・アダプタを使用すると、Java EEアプリケーションでリモートEISにアクセスできるようになります。WebLogic Serverアプリケーションの開発者は、HTTPサーブレット、JavaServer Pages (JSP)、Enterprise JavaBeans (EJB)、およびその他のAPIにより、EISのデータとビジネス・ロジックを使用する統合アプリケーションを開発できます。

WebLogic Serverにリソース・アダプタをデプロイするには、まずWebLogic Server固有のデプロイメント記述子であるweblogic-ra.xmlファイルを作成して構成し、これをデプロイメント・ディレクトリに追加する必要があります。WebLogic Serverへのリソース・アダプタのデプロイは、スタンドアロン・モジュールまたはエンタープライズ・アプリケーションの一部として行えます。「エンタープライズ・アプリケーション」を参照してください。

コネクタの詳細は、『Oracle WebLogic Serverリソース・アダプタの開発』を参照してください。

エンタープライズ・アプリケーション

エンタープライズ・アプリケーションは、1つまたは複数のWebアプリケーション・モジュール、EJBモジュール、およびリソース・アダプタで構成されています。また、クライアント・アプリケーションが含まれていることもあります。エンタープライズ・アプリケーションは必要に応じて、エンタープライズ・アプリケーションの標準Java EEデプロイメント記述子であるapplication.xmlファイルによって定義できます。

Java EEプログラミング・モデル

Java EEプログラミング・モデルの重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーションの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(1.4以前)で必要だったデプロイメント記述子にかわるものです。

Java EEアノテーションの使用により、標準のapplication.xmlおよびweb.xmlデプロイメント記述子は省略可能になりました。このJava EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナ用のJDK アノテーション機能を使用します(http://docs.oracle.com/javaee/7/api/を参照)。Java EEアノテーションと依存関係インジェクションの使用を参照してください。

WebLogic Server固有の拡張機能が含まれているアプリケーションの場合は、さらにweblogic-application.xmlファイルでも定義されます。クライアント・モジュールを含むエンタープライズ・アプリケーションには、client-application.xmlデプロイメント記述子とWebLogic実行時クライアント・アプリケーション・デプロイメント記述子も備わっています。エンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。

パッケージ化とデプロイメントの概要

本番用と開発用の両方の場合において、エンタープライズ・アプリケーションの一部として、スタンドアロンのWebアプリケーション、EJBおよびリソース・アダプタもパッケージ化およびデプロイすることをお薦めします。それにより、アプリケーション開発を大幅に容易にするOracleの分割開発ディレクトリ構造を使用できるようになります。分割開発ディレクトリ環境の作成を参照してください。

エンタープライズ・アプリケーションは、Webアプリケーション・モジュール、EJBモジュール、およびリソース・アダプタで構成されています。これは次のようにパッケージ化できます。

- 開発が目的の場合は、WebLogic分割開発ディレクトリ構造をお薦めします。単一のアーカイブEARファイルまたは展開されたEARディレクトリ構造ではなく、分割開発ディレクトリではソース・ファイルと出力ファイルを分離する2つの並列ディレクトリが存在します。このディレクトリ構造は、単一のWebLogic Serverインスタンスでの開発用に最適化されています。分割開発ディレクトリ環境の作成を参照してください。Oracleでは、JARユーティリティを使用しなくてもEARを作成できるwlpackage Antタスクを提供しています。これは、分割開発ディレクトリ構造でのみ使用できます。「wlpackageを使用したアプリケーションのパッケージ化」を参照してください。

- 開発目的の場合は、さらに分割開発ディレクトリ構造を活用できるようスタンドアロンのWebアプリケーションおよびEnterprise JavaBeans (EJB)をエンタープライズ・アプリケーションの一部としてパッケージ化することをお薦めします。「分割開発ディレクトリでのJava EEコンポーネントの配置」を参照してください。

- 本番用の場合は、展開(非アーカイブ)ディレクトリ形式をお薦めします。この形式を使うと、アプリケーションを再デプロイすることなくファイルを更新できます。アーカイブ・ファイルを更新するには、ファイルのアーカイブを展開および更新し、その後再アーカイブして再デプロイする必要があります。

- 拡張子.earの付いたjarユーティリティを使用してアプリケーションをJARアーカイブ・ファイルとしてパッケージ化することを選択できます。アーカイブ・ファイルは配布がしやすく、占める領域が少なくてすみます。EARファイルには、アプリケーションのすべてのJAR、WAR、およびRARモジュール・アーカイブ・ファイル、およびバンドルされたモジュールを記述するXML記述子が格納されます。「wlpackageを使用したアプリケーションのパッケージ化」を参照してください。

省略可能なMETA-INF/application.xmlデプロイメント記述子には、各Webアプリケーション、EJB、およびコネクタ・モジュールの要素のほか、セキュリティ・ロールやアプリケーション・リソース(データベースなど)を記述するための追加の要素があります。この記述子が存在する場合、WebLogicデプロイヤは、この記述子からモジュールのリストを選択します。ただし、この記述子が存在しない場合、コンテナはPOJO (プレーンな従来型Javaオブジェクト)クラスで定義されるアノテーションから、モジュールを推測します。エンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。

WebLogic Webサービス

Webサービスは、分散型Webベース・アプリケーションのモジュールとして共有され、使用されます。これらのサービスは一般的に、カスタマ・リレーションシップ・マネージメント・システム、注文処理システムなどの既存のバックエンド・アプリケーションと連携します。Webサービスは別々のコンピュータ上に常駐でき、多様なテクノロジを使用して実装できますが、HTTPなどの標準のWebプロトコルを使用してパッケージ化されトランスポートされます。そのため、Web上のどのようなユーザーでも簡単にアクセスできます。

Webサービスは、最低限、次のモジュールから構成されています。

- Web上のサーバーによってホストされるWebサービス実装。WebLogic Webサービスは、WebLogic Serverによってホストされます。Webサービス・モジュールはJavaクラス、あるいはWebサービスを実装するEJBのどちらかを含む場合があります。Webサービスは、実装に応じて、Webアプリケーション・アーカイブ(WAR)またはEJBモジュール(JAR)のどちらかとしてパッケージ化されます。

- Webサービスとそのユーザー間のデータ転送とWebサービス呼出しの標準。WebLogic Webサービスでは、Simple Object Access Protocol (SOAP) 1.1をメッセージ・フォーマットとして使用し、HTTPを接続プロトコルとして使用します。

- Webサービスを起動できるようにクライアントに記述するための標準。WebLogic Webサービスは、XMLベースの仕様であるWeb Services Description Language (WSDL) 1.1を使用して記述しています。

- Webサービスを呼び出すためのクライアント用の標準 - JAX-WSまたはJAX-RPC。それぞれ、『Oracle WebLogic Server JAX-WS Webサービスの開発』または『Oracle WebLogic Server JAX-RPC Webサービスの開発』を参照してください。

- Webサービスを検索して登録するための規格(UDDI)。

WebLogic Webサービスおよびサポートされている標準の詳細は、『Oracle WebLogic Server WebLogic Webサービスの理解』を参照してください。

JMSおよびJDBCモジュール

JMSおよびJDBCの構成は、それぞれweblogic-jms.xsdおよびjdbc-data-source.xsdスキーマに準拠するXMLファイルによって定義されたモジュールとして格納されます。これらのモジュールは、標準のJava EEモジュールに類似しています。管理者はグローバルなシステム・リソースとして、Java EEアプリケーションと共にパッケージ化されるモジュール(パッケージ化されたリソース)として、またはグローバルに使用可能なスタンドアロンのモジュールとして、JMSおよびJDBCモジュールを作成したり管理したりできます。

JMSおよびJDBCリソースのモジュール形式のデプロイメントを利用すると、エンタープライズ・アプリケーション・ファイル(EARファイルなど)やJMSまたはJDBCのスタンドアロン・モジュールを開いたり、JMSやJDBCの手動による膨大な再構成を行わずに、アプリケーションと必要なJMSまたはJDBC構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。

アプリケーション開発者は、エンタープライズ・レベルのIDEまたはXMLファイルの編集に対応した開発ツールでアプリケーション・モジュールを作成し、そのJMSまたはJDBCモジュールをアプリケーションの一部としてパッケージ化して、そのアプリケーションをデプロイするためにWebLogic管理者に渡します。

詳細は、次を参照してください:

- JMSアプリケーション・モジュールのデプロイメントの構成

- JDBCアプリケーション・モジュールのデプロイメントの構成

WebLogic診断フレームワーク・モジュール

WebLogic診断フレームワーク(WLDF)では、WebLogic Serverインスタンスおよびサーバー・インスタンスにデプロイされたアプリケーションから診断データを生成、収集、解析、永続化できます。サーバー・スコープの診断では、一部のWLDF機能は、ドメインの構成の一部として構成されます。その他の機能は、サーバー(またはクラスタ)をターゲット指定できるシステム・リソース記述子として構成されます。アプリケーション・スコープの診断では、診断機能は、アプリケーションのリソース記述子として構成されます。

アプリケーション・スコープのインストゥルメンテーションは、診断システム・モジュールに類似した診断モジュールとして構成およびデプロイされます。ただし、アプリケーション・モジュールは、アプリケーション・アーカイブでパッケージ化されたweblogic-diagnostics.xmlというXML構成ファイルに構成されます。

アプリケーション用にインストゥルメンテーションを構成する詳細な手順については、「アプリケーション・スコープのインストゥルメンテーションの構成」を参照してください。

外部診断記述子の使用

WebLogic Serverでは、外部診断記述子を使用できるため、診断記述子をインポートしていないアプリケーションに診断機能を統合することも可能です。この機能では、デプロイメント・ビュー、およびアプリケーションまたはモジュールのデプロイメントがサポートされ、デプロイメント・プラン(plan.xml)内に外部診断記述子が宣言されている場合に、その記述子の存在が検出されます。

外部診断記述子を定義する

まず、診断記述子を外部ファイルとして定義し、そのURIをplan.xmlファイル内で構成します。例:

<module-override>
<module-name>reviewService.ear</module-name>
<module-type>ear</module-type>
</module-descriptor>
<module-descriptor external="true">
<root-element>wldf-resource</root-element>
<uri>META-INF/weblogic-diagnostics.xml</uri>
...
...
</module-override>
<config-root>D:\plan</config-root>

次に、外部診断記述子ファイルをそのURIに配置します。上のサンプルであれば、記述子ファイルをd:\plan\ META-INFに配置します。

Coherence Grid Archive (GAR)モジュール

Coherence GARモジュールは、アプリケーションの可用性、スケーラビリティおよびパフォーマンスを向上させることができる、分散されたメモリー内キャッシングおよびデータ・グリッド・コンピューティングを提供します。GARモジュールは、スタンドアロン・モジュールとして、およびJava EEアプリケーションとともにパッケージ化されるモジュール(パッケージ化されたリソース)としてデプロイされます。GARモジュールは、グローバルに使用可能にすることもできます。

GARモジュールはcoherence-application.xmlデプロイメント記述子によって定義され、coherence-application.xsd XMLスキーマに準拠する必要があります。GARには、Coherenceアプリケーションを構成するアーティファクト(Coherence構成ファイル、アプリケーション・クラス(エントリ・プロセッサ、アグリゲータ、フィルタなど)、必要な依存関係)が含まれています。

Beanの検証

Bean Validation 仕様(JSR 349)では、JavaBeansコンポーネントでデータを検証するためのメタデータ・モデルとAPIを定義しています。サーバーとJava EE 7クライアントの両方でサポートされるため、ブラウザやサーバー・サイドなど複数のレイヤーにデータ検証を配布するかわりに、1箇所で検証制約を定義して、それを様々なレイヤーで共有することができます。また、Bean検証の目的は、Beanを検証することだけではありません。実際には任意のJavaオブジェクトの検証にも使用できます。

Bean検証とJNDI

Java EE 仕様で規定されている場合、JNDIを使用して、java:comp/Validatorおよびjava:comp/ValidatorFactoryという名前でデフォルトのValidatorとValidatorFactoryが配置されます。これら2つのアーティファクトは、スコープ内の検証ディスクリプタを反映しています。

Bean検証構成

Bean検証は、XMLディスクリプタまたはアノテーションを使用して構成できます。

- ディスクリプタ:

- ディスクリプタ要素は、対応するアノテーションをオーバーライドします。

- Weblogic Serverでは、モジュールごとに1つのディスクリプタを使用できます。このため、1つのアプリケーションで複数の検証ディスクリプタを使用することはできますが、各モジュール・スコープでは1つしか使用できません。

- 検証ディスクリプタは、validation.xmlという名前でMETA-INFディレクトリにパッケージされます。ただし、WebモジュールではディスクリプタはWEB-INFディレクトリにパッケージされます。

- アノテーション:

- デフォルトのValidatorおよびValidatorFactoryは、@Resourceアノテーションを使用してリクエストされます。ただし、このアノテーションですべてのソース・ファイルがスキャンされるわけではありません。

- WebLogic Connectorは、Bean検証を内部的に使用してコネクタ・ディスクリプタを検証します。

Bean検証を構成すると、特定のコンテナ用の標準的な一連のコンテナ管理クラスがスキャンされます。たとえば、EJBの場合、Beanおよびインターセプタ・クラスがスキャンされます。Webアプリケーション・クラスおよびマネージドBeanでも、ValidatorおよびValidatorFactoriesの挿入がサポートされます。

Bean検証をサポートするクラスの詳細は、関連するコンポーネントの仕様に記載されている、依存性の挿入をサポートするクラスのリストを参照してください。

XMLデプロイメント記述子

デプロイメント構成は、特定のWebLogic Serverドメインにエンタープライズ・アプリケーションをデプロイするために必要となるデプロイメント記述子の値を定義するプロセスです。アプリケーションまたはモジュールに関するデプロイメント構成は、Java EEデプロイメント記述子、WebLogic Server記述子およびWebLogic Serverデプロイメント・プランの3種類のXMLドキュメントに格納されます。この項では、Java EEおよびWebLogic固有のデプロイメント記述子について説明します。デプロイメント・プランについては、「デプロイメント・プラン」を参照してください。

Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDKアノテーション機能を採用しています。アノテーションを使用すると、コンテナ内でのコンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、以前のバージョンのWebアプリケーション(2.4以前)、エンタープライズ・アプリケーション(1.4以前)、およびEnterprise JavaBeans (2.x以前)で必要だったデプロイメント記述子にかわるものです。Java EEアノテーションと依存関係インジェクションの使用を参照してください。

しかしながら、デプロイメント記述子は、エンタープライズ・アプリケーションで完全にサポートされます。ただし、Java EE標準のデプロイメント記述子は必須ではありません。たとえば、従来のEJB 2.xプログラミング・モデルを使用したい場合や、後々の開発やデプロイメントの段階でより細かくカスタマイズできるようにしたい場合、メタデータ・アノテーションに加えて(またはメタデータ・アノテーションの代わりに)標準のデプロイメント記述子を作成できます。

モジュールとアプリケーションには、ディレクトリまたはJARファイルの内容を記述したデプロイメント記述子というXMLドキュメントが組み込まれています。デプロイメント記述子は、XMLタグでフォーマットされたテキスト・ドキュメントです。Java EE仕様では、Java EEモジュールおよびアプリケーション用の標準的で移植性の高いデプロイメント記述子が定義されています。Oracleでは、モジュールまたはアプリケーションをWebLogic Server環境にデプロイするときに使用するWebLogic固有のデプロイメント記述子をさらに定義しています。

表1-1に、モジュールとアプリケーションのタイプと、それらのJava EE標準およびWebLogic固有のデプロイメント記述子を示します。

注意:

次の表にリストされているWebLogicデプロイメント記述子のXMLスキーマには、WebLogic固有のすべてのデプロイメント記述子で共有される要素を記述するhttp://xmlns.oracle.com/weblogic/weblogic-javaee/1.7/weblogic-javaee.xsdスキーマの要素も含まれています。

最新のスキーマ情報は、次を参照してください。http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html。

表1-1 Java EEとWebLogicのデプロイメント記述子

モジュールまたはアプリケーション

スコープ

デプロイメント記述子

Webアプリケーション

Java EE

web.xml

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-app_3_1.xsdでServlet 3.0 Schemaを参照してください。

WEB-INF/beans.xml (WARファイルのクラスがContexts and Dependency Injection (CDI)に参加する場合にのみ必要)

スキーマ: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/beans_1_1.xsd

Contexts and Dependency Injection for the Java EE Platformの使用方法を参照してください。

Webアプリケーション

WebLogic

weblogic.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-web-app/1.8/weblogic-web-app.xsd

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。

エンタープライズBean 3.0

Java EE

ejb-jar.xml

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/ejb-jar_3_1.xsdでEJB 3.2 Schemaを参照してください。

META-INF/beans.xml (EJB JARファイルのクラスがCDIに参加する場合にのみ必要)

スキーマ: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/beans_1_1.xsd

Contexts and Dependency Injection for the Java EE Platformの使用方法を参照してください。

エンタープライズBean 3.0

WebLogic

weblogic-ejb-jar.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.6/weblogic-ejb-jar.xsd

weblogic-rdbms-jar.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-rdbms-jar/1.2/weblogic-rdbms-jar.xsd

persistence-configuration.xml

スキーマ: http://xmlns.oracle.com/weblogic/persistence-configuration/1.0/persistence-configuration.xsd

『Oracle WebLogic Server Enterprise JavaBeansの開発』を参照してください。

エンタープライズBean 2.1

Java EE

ejb-jar.xml

http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsdでEJB 2.1 Schemaを参照してください。

エンタープライズBean 2.1

WebLogic

weblogic-ejb-jar.xml

スキーマ:: http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.6/weblogic-ejb-jar.xsd

『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のweblogic-ejb-jar.xmlデプロイメント記述子に関する項を参照してください。

weblogic-cmp-rdbms-jar.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-rdbms-jar/1.2/weblogic-rdbms-jar.xsd

『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のweblogic-cmp-rdbms-jar.xmlデプロイメント記述子に関する項を参照してください。

Webサービス

Java EE

webservices.xml

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/javaee_web_services_1_4.xsdでWeb services 1.4 Schemaを参照してください。

Webサービス

WebLogic

weblogic-webservices.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-webservices/1.1/weblogic-webservices.xsd

weblogic-wsee-clientHandlerChain.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-wsee-clientHandlerChain/1.0/weblogic-wsee-clientHandlerChain.xsd

weblogic-webservices-policy.xml

スキーマ: http://xmlns.oracle.com/weblogic/webservice-policy-ref/1.1/webservice-policy-ref.xsd

weblogic-wsee-standaloneclient.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-wsee-standaloneclient/1.0/weblogic-wsee-standaloneclient.xsd

『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebLogic Webサービス・デプロイメント記述子要素リファレンスに関する項を参照してください。

リソース・アダプタ

Java EE

ra.xml

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/connector_1_7.xsdでConnector 1.6 Schemaを参照してください。

META-INF/beans.xml (RARファイルのクラスがCDIに参加する場合にのみ必要)

スキーマ: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/beans_1_1.xsd

Contexts and Dependency Injection for the Java EE Platformの使用方法を参照してください。

リソース・アダプタ

WebLogic

weblogic-ra.xml

Schema: http://xmlns.oracle.com/weblogic/weblogic-connector/1.5/weblogic-connector.xsd

『Oracle WebLogic Serverリソース・アダプタの開発』のweblogic-ra.xmlスキーマに関する項を参照してください。

エンタープライズ・アプリケーション

Java EE

application.xml

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_7.xsdでApplication 7Schemaを参照してください。

エンタープライズ・アプリケーション

WebLogic

weblogic-application.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-application/1.7/weblogic-application.xsd

「weblogic-application.xmlデプロイメント記述子の要素」を参照してください。

クライアント・アプリケーション

Java EE

application-client.xml

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application-client_7.xsdでApplication Client 7Schemaを参照してください。

META-INF/beans.xml (アプリケーション・クライアントJARファイルのクラスがCDIに参加する場合にのみ必要)

スキーマ: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/beans_1_1.xsd

Contexts and Dependency Injection for the Java EE Platformの使用方法を参照してください。

クライアント・アプリケーション

WebLogic

application-client.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-application-client/1.4/weblogic-application-client.xsd

『Oracle WebLogic Serverスタンドアロン・クライアントの開発』のJava EEアプリケーション・クライアント(シン・クライアント)の開発に関する項を参照してください。

HTTP Pub/Subアプリケーション

WebLogic

weblogic-pubsub.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-pubsub/1.0/weblogic-pubsub.xsd

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のHTTPパブリッシュ/サブスクライブ・サーバーの使用方法に関する項を参照してください。

JMSモジュール

WebLogic

FileName-jms.xml。FileNameには任意の名前を指定します。

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsd

『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールのデプロイメントの構成に関する項を参照してください。

JDBCモジュール

WebLogic

FileName-jdbc.xml。FileNameには任意の名前を指定します。

スキーマ: http://xmlns.oracle.com/weblogic/jdbc-data-source/1.5/jdbc-data-source.xsd

『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCアプリケーション・モジュールのデプロイメントの構成に関する項を参照してください。

デプロイメント・プラン

WebLogic

plan.xml

スキーマ: http://www.oracle.com/webfolder/technetwork/weblogic/deployment-plan/index.html

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverデプロイメントの理解に関する項を参照してください。

リソース・デプロイメント・プラン

WebLogic

resource-deployment-plan.xml

スキーマ: http://xmlns.oracle.com/weblogic/resource-deployment-plan/1.0/resource-deployment-plan.xsd

『WebLogic Server Multitenantの使用』のリソース・デプロイメント・プランに関する項を参照してください。

WLDFモジュール

WebLogic

weblogic-diagnostics.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd

『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDFアプリケーション・モジュールのデプロイメントに関する項を参照してください。

Coherenceモジュール

WebLogic

coherence-application.xml

スキーマ: http://xmlns.oracle.com/coherence/coherence-application/1.0/coherence-application.xsd

『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。

モジュールまたはアプリケーションをパッケージ化する場合は、デプロイメント記述子を格納するディレクトリ(WEB-INFまたはMETA-INF)を作成し、次にそのディレクトリ内にXMLデプロイメント記述子を作成します。

デプロイメント記述子の自動生成

WebLogic Serverでは、デプロイメント記述子を自動生成するための様々なツールを用意しています。これらについては、これ以降の項で説明します。

EJBGen

EJBGenは、Javadocマークアップを使用してEJBデプロイメント記述子ファイルを生成するEnterprise JavaBeans 2.xのコード・ジェネレータまたはコマンド・ライン・ツールです。Beanクラス・ファイルにJavadocタグでアノテーションを付け、EJBGenを使用してリモート・クラスとホーム・クラスおよびEJBアプリケーション用のデプロイメント記述子ファイルを生成し、EJB.javaおよび記述子ファイルの編集および管理が必要なファイルを1つに減らせます。『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBGenリファレンスに関する項を参照してください。

Javaベースのコマンド・ライン・ユーティリティ

WebLogic Serverには、Webアプリケーションやエンタープライズ・アプリケーションの標準Java EEデプロイメント記述子とWebLogic固有のデプロイメント記述子の両方を自動的に生成するJavaベースのコマンド・ライン・ユーティリティがあります。

これらのコマンド・ライン・ユーティリティは、ステージング・ディレクトリにアセンブルしたクラスを検証し、サーブレット・クラスなどを基に適切なデプロイメント記述子を構築します。以下のようなユーティリティがあります。

- java weblogic.marathon.ddinit.EarInit - エンタープライズ・アプリケーションのデプロイメント記述子を自動生成します。

- java weblogic.marathon.ddinit.WebInit - Webアプリケーションのデプロイメント記述子を自動生成します。

たとえば、DDInitでは、Webアプリケーションを構成するJSPファイルやその他のオブジェクトを含むc:\stageというディレクトリを作成したものの、web.xmlおよびweblogic.xmlデプロイメント記述子を作成していない場合があります。それらを自動的に生成するには、次のコマンドを実行します。

prompt> java weblogic.marathon.ddinit.WebInit c:\stage

ユーティリティによってweb.xmlおよびweblogic.xmlデプロイメント記述子が生成され、WEB-INFディレクトリに配置されます(WEB-INFディレクトリがない場合はDDInitによって作成されます)。

以前のリリースのJava EEおよびWebLogic Serverのデプロイメント記述子のアップグレード

WebLogic Serverの新しいリリースにアプリケーションを移行する場合は、現行のJava EE仕様とWebLogic Serverのリリースの機能をアプリケーションで利用できるように、必ずデプロイメント記述子をアップグレードしておくことをお薦めします。

Java EEアプリケーションとモジュールのデプロイメント記述子をアップグレードするには、まずweblogic.DDConverterツールを使用して、アップグレードした記述子を一時ディレクトリに生成します。アップグレードしたデプロイメント記述子を調べて、その記述子が正しいことを確認したら、新しいデプロイメント記述子ファイルを持つJava EEモジュール・アーカイブまたは展開されたディレクトリを再パッケージ化します。

次のコマンドでweblogic.DDConverterを呼び出します。

prompt> java weblogic.DDConverter [options] archive_file_or_directory

archive_file_or_directoryは、エンタープライズ・アプリケーション、Webアプリケーション、EJB、リソース・アダプタのアーカイブ・ファイル(EAR、WAR、JAR、RAR)または展開されたディレクトリです。

次の表では、weblogic.DDConverterコマンド・オプションを説明します。

オプション

説明

-d <dir>

記述子が作成されるディレクトリを指定します。

-help

標準の使用方法メッセージを出力します。

-quiet

エラー・メッセージを除く出力メッセージをオフにします。

-verbose

デバッグで使用する追加出力をオンにします。

次の例では、weblogic.DDConverterコマンドを使用して、my.earエンタープライズ・アプリケーションのアップグレードされたデプロイメント記述子をカレント・ディレクトリのサブディレクトリtempdirに生成する方法を示します。

prompt> java weblogic.DDConverter -d tempdir my.ear

デプロイメント・プラン

デプロイメント・プランは、特定のWebLogic Server環境のためのアプリケーションのWebLogic Serverデプロイメント構成を定義する、XMLドキュメントです。デプロイメント・プランは、アプリケーションのアーカイブ・ファイルの外部にあり、アプリケーションの既存のWebLogic Serverデプロイメント記述子に格納されているデプロイメント・プロパティに対して変更を適用することができます。デプロイメント・プランを使用すると、Java EEやWebLogic固有の既存のデプロイメント記述子を修正することなく、特定の環境についてのアプリケーションのWebLogic Server構成を簡単に変更できます。複数のデプロイメント・プランを使用すると、単一のアプリケーションを、複数の様々なWebLogic Server環境にデプロイされるように再構成できます。

プログラマは、アプリケーションのプログラミングを完了したら、デプロイメント構成をエクスポートして、アプリケーションを新しいWebLogic Server環境にデプロイするために管理者が使用するカスタム・デプロイメント・プランを作成します。そして、アプリケーションを環境に合わせて構成するための青写真としてデプロイメント・プランを使用するデプロイヤ(たとえば、テスト管理者、ステージング管理者または本番管理者)に、アプリケーション・デプロイメント・ファイルとカスタム・デプロイメント・プランの両方を配布します。

WebLogic Serverには、アプリケーションのデプロイメント構成のエクスポートを支援するため、以下のツールが用意されています。

- weblogic.PlanGenerator。WebLogic Serverデプロイメント記述子の選択されたカテゴリについて、null変数を備えるテンプレート・デプロイメント・プランを作成します。エクスポート・プロセスを開始しているところであり、デプロイメント記述子のクラス全体に対してnull変数を備えるテンプレート・デプロイメント・プランを作成する必要がある場合は、このツールの使用をお薦めします。

- WebLogic Server管理コンソールは、インストールされているアプリケーションの構成プロパティが変更されると、必要に応じてデプロイメント・プランを更新または新規作成します。WebLogic Server管理コンソールを使用して、新しいデプロイメント・プランを生成したり、既存のプラン内の変数を追加またはオーバーライドできます。記述子プロパティのカテゴリ全体をエクスポートするのではなく、プラン内の個々のデプロイメント記述子プロパティを対話形式で追加または編集できるため、WebLogic Server管理コンソールにはweblogic.PlanGeneratorよりも高い柔軟性があります。

デプロイメント・プランの作成と使用方法の詳細は、次を参照してください。

- WebLogic Serverデプロイメントの理解

- 新しい環境にデプロイするためのアプリケーションのエクスポート

- WebLogic Serverデプロイメント・プランの理解

開発ツール

この項では、WebLogic Serverアプリケーションを開発するための必須ツールや省略可能なツールについて説明します。

Java APIリファレンスおよびwls-api.jarファイル

Oracleには、『Oracle Fusion Middleware Oracle WebLogic Server Java APIリファレンス』が用意されています。このリファレンスには、WebLogic Server用のJava EEアプリケーションを開発する際に使用可能な、サポートされているすべてのJavaクラスが定義されています。『Oracle WebLogic Server Java APIリファレンス』を参照してください。

『Oracle WebLogic Server Java APIリファレンス』とともに、wls-api.jarファイルを使用して、WebLogic Server環境に合わせてJava EEアプリケーションを開発およびコンパイルすることをお薦めします。wls-api.jarファイルは、WebLogic Server配布のwlserver/server/libディレクトリに配置されており、次の利点を提供します。

- テストされたベスト・プラクティスに基づく、よりパフォーマンスの高いコードの開発

- 非推奨またはサポート対象外となったコード・パスの回避

wls-api.jarファイルの使用

wls-api.jarファイルとapi.jarファイルを使用すると、Oracle JDeveloperなどの統合開発環境(IDE)でJava EEアプリケーションを開発およびコンパイルすることができます。IDEには、Javaベースのアプリケーションの開発を簡略化するための一連のツールが用意されています。wls-api.jarファイルは、WebLogic環境に合わせてJava EEアプリケーションを開発および実行するための、クリーンで簡潔なAPI jarを提供します。

注意:

wls-api.jarファイルはJava EEクラスを参照しません。Oracleではapi.jarファイルに、Java EE JARへのアクセスを含むマニフェスト・クラスパスを用意しています。

WLST、weblogic.Deployerユーティリティ、weblogic.appcなどのツールにアクセスするために、開発環境のクラスパスにweblogic.jarファイルを含める必要がある場合があります。

weblogic.jarファイルの使用

クライアントとして、またはレガシー・アプリケーションを開発およびコンパイルするために、実行時環境に対してweblogic.jarファイルを引き続き使用する必要があります。ただし、WebLogic Server環境に合わせてJava EEアプリケーションを開発およびコンパイルするには、wls-api.jarファイルを使用します。

Apache Ant

WebLogic Serverによるアプリケーションのビルド方法としては、Apache Antが最適です。Antは、Javaベースのビルド・ツールです。Antの利点の1つは、これがシェル・ベースのコマンドではなく、Javaクラスで拡張されていることです。WebLogic Server分割開発ディレクトリ環境を使用してアプリケーションをコンパイル、ビルド、デプロイ、パッケージ化するための様々なAnt拡張クラスを利用できます。

もう1つの利点は、Antがクロス・プラットフォーム・ツールであるということです。開発者は、eXtensible Markup Language (XML)で、Antによるスクリプトを作成します。XMLタグは、ビルドするターゲット、ターゲット間の依存関係、およびターゲットを構築するための実行タスクを定義します。AntライブラリはWebLogic Serverに付属していて、製品パッケージからJavaアプリケーションを簡単に構築できるようになっています。

Antを使用するには、まずWL_SERVER\samples\domains\wl_serverディレクトリ(WL_SERVERはWebLogic Serverインストール・ディレクトリ)にあるsetExamplesEnv.cmd (Windows)またはsetExamplesEnv.sh (UNIX)コマンドを実行して、環境を設定する必要があります。

Antの機能の包括的な説明については、http://jakarta.apache.org/ant/manual/index.htmlを参照してください。

注意:

Apache JakartaのWebサイトでは、Antの最新バージョンに関するオンライン・ドキュメントのみを公開しています。このAntは、WebLogic Serverに同梱されているものとはバージョンが異なる可能性があります。WebLogic Serverに同梱されているAntのバージョンを調べるには、WebLogic環境の設定後、次のコマンドを実行します。

prompt> ant -version

特定のバージョン(たとえば、WebLogic Serverに含まれるバージョン)のAntのドキュメントを参照するには、http://archive.apache.org/dist/ant/binaries/からAntのzipファイルをダウンロードして、ドキュメントを展開します。

クロス・プラットフォーム・スクリプトをコンパイルするAntの使用、またはAntによって処理可能なXMLスクリプトを作成するクロス・プラットフォーム・スクリプトの使用については、ORACLE_HOME/wlserver/samples/server/examples/src/examples/ejb20/basic/beanManaged/build.xmlなどの任意のWebLogic Serverサンプルを参照してください。ここで、ORACLE_HOMEは、WebLogic Serverをインストールしたディレクトリを表します。WebLogic Serverのコード・サンプルの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

また、Antを使ってサンプルを構築する方法を説明したWebLogic Serverドキュメント(ORACLE_HOME/wlserver/samples/server/examples/src/examples/examples.html)も参照してください。

サード・パーティ・バージョンのAntの使用方法

WebLogic Serverに同梱されているAntが不十分な場合は、独自のバージョンのAntを使用できます。WebLogic Serverに同梱されているAntのバージョンを判断するには、WebLogic環境の設定後、次のコマンドを実行します。

prompt> ant -version

別のバージョンのAntを使用する予定がある場合は、WL_HOME\server\lib\antディレクトリの適切なJARファイルを更新されたバージョンのファイルで置き換えるか、新しいファイルをCLASSPATHの前に追加します。なお、WL_HOMEは、WebLogicのメイン・インストール・ディレクトリ(c:\Oracle\Middleware\Oracle_Home\wlserverなど)です。

Antのヒープ・サイズの変更

デフォルトでは、環境スクリプトは128 MBのヒープ・サイズをAntに割り当てます。ローカル環境変数ANT_OPTSに-Xオプションを設定すると、この値を独自のプロジェクトに合わせて増減できます。例:

prompt> setenv ANT_OPTS=-Xmx128m

ヒープ・サイズを永続的に設定する場合は、環境を設定するスクリプトのMEM_ARGS変数を追加または更新し、WebLogic Serverを起動するなどの操作を行います。次の、WebLogic Serverインスタンスを起動するWindowsコマンド・スクリプトの抜粋を参照してください。

set MEM_ARGS=-Xms32m -Xmx200m

MEM_ARGS変数の使用例については、WL_HOME/server/binのスクリプトとコマンドを参照してください。

ソース・コード・エディタまたはIDE

Javaソース・ファイル、構成ファイル、HTMLまたはXMLページ、およびJavaServer Pagesの編集には、テキスト・エディタが必要です。WindowsとUNIXの行末コードの違いを適切に処理するエディタが望ましいですが、それ以外には特別な要件は何もありません。HTML/XMLページおよびJavaServer Pagesは、通常のテキスト・エディタか、またはDreamWeaverなどのWebページ・エディタで編集できます。XMLページの場合、DTD検証機能を備えたエンタープライズ・レベルのIDE、またはXMLファイルの編集をサポートするその他の開発ツールを使用できます。

データベース・システムとJDBCドライバ

データベース・システムは、ほぼすべてのWebLogic Serverアプリケーションで必要となります。標準JDBCドライバを介してアクセスできる任意のDBMSを使用できますが、WebLogic Java Message Service (JMS)などのサービスでは、Oracle、Sybase、Informix、Microsoft SQL ServerまたはIBM DB2をサポートするJDBCドライバが必要です。サポート対象のデータベース・システムとJDBCドライバについては、Oracle Technology Networkの「Oracle Fusion Middleware Supported System Configurations」ページを参照してください。

Webブラウザ

ほとんどのJava EEアプリケーションは、Webブラウザ・クライアントによって実行されるように設計されています。WebLogic ServerはHTTP 1.1仕様をサポートしており、FirefoxおよびMicrosoft Internet Explorerブラウザの現行バージョンでテストされています。

作成するアプリケーションの条件を書き出す場合、どのWebブラウザ・バージョンをサポートするかに留意してください。テスト・プランには、サポートされるバージョンごとのテスト計画を含めます。バージョン番号とブラウザ構成は明確に指定します。作成するアプリケーションはセキュア・ソケット・レイヤー(SSL)プロトコルをサポートしますか。ブラウザの代替セキュリティ設定をテストして、サポートしているセキュリティをユーザーに通知できるようにします。

アプリケーションがアプレットを使用する場合、様々なブラウザに埋め込まれているJVMには違いがあるため、サポートするブラウザの構成をテストすることが特に重要です。解決策の1つは、Javaプラグインをインストールするようユーザーに指示して、すべてのユーザーが同じJavaランタイム・バージョンを持つようにすることです。

サード・パーティ・ソフトウェア

サード・パーティのソフトウェア製品を使用して、WebLogic Server開発環境を強化することができます。「WebLogic開発者向けツール・リソース」では、アプリケーション・サーバーをサポートする製品の開発者向けツールの情報が提供されます。

注意:

ソフトウェア・ベンダーに問い合わせて、使用しているプラットフォームとWebLogic Serverのバージョンにソフトウェアが対応しているかどうかを確認してください。

このリリースでの新機能と変更された機能

このリリースのWebLogic Serverでは、アプリケーション開発用に次の新機能が導入されています。

- WebSocketの監視サポート—管理コンソールを使用して、WebSocketアプリケーションおよびエンドポイントのメッセージ統計およびランタイム・プロパティを監視できます。詳細は「WebSocketアプリケーションの監視」を参照してください。
WebLogic Serverは、WebSocketのJava APIのバージョン1.1をサポートするようになりました。

- 次を含むMavenサポートの更新:

- WebLogic Serverでは、Mavenバージョン3.2.5をサポートするようになりました。

- installゴールはクイックスタート・インストーラをサポートするようになりました。

- バージョン12.2.1以降、ORACLE_HOMEのすべての製品からWLST環境を自動的に取り込むWLSTの単一の統合されたバージョンがあります。wlst-clientゴールを使用してFusion Middleware依存関係を含むWLSTスクリプトを実行する場合、それらのスクリプトで必要なライブラリを引き込むために、まずFMWSHARE依存関係をインクルードする必要があります。

- deploy、redeployおよびdistribute-appのゴールのsourceパラメータは、デプロイするアプリケーションを指定するためにMaven座標、HTTP URLまたはローカル・ファイル/ディレクトリをサポートするようになりました

更新されたMavenサポートの詳細は、「WebLogic Mavenプラグインの使用方法」を参照してください。

- ポリシー・クラスローダーでのクラス・キャッシング—ポリシー・クラスローダーは、startWebLogicスクリプトを使用してWebLogicサーバーを起動する際のデフォルトのシステム・クラスローダーです。ポリシー・クラスローダーは、クラス・キャッシングおよび索引付けを通じてクラスローダーのパフォーマンスおよびサーバー起動時間を向上し、あらゆるWebLogicモード(開発または本番)でサポートされています。詳細は、「ポリシー・クラスローダーを使用したクラス・キャッシング」を参照してください。

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

2 Antタスクを使用したWebLogic Serverドメインの構成と使用

この章では、開発ビルド・スクリプトでWebLogic Antタスクを使用して、WebLogic Server インスタンスの起動と停止、およびWebLogic Serverドメインの構成を行う方法について説明します。

この章の内容は次のとおりです。

- Antタスクを使用したドメインの構成と起動についての概要

- wlserver Antタスクを使用したサーバーの起動とドメインの作成

- wlconfig Antタスクを使用したWebLogic Serverドメインの構成

- libclasspath Antタスクの使用

Antタスクを使用したドメインの構成と起動についての概要

WebLogic Serverには、開発環境で一般的な構成タスクを実行するのに役立つ2つのAntタスクがあります。構成タスクでは、WebLogic Serverインスタンスの起動と停止、WebLogic Serverドメインの作成と構成を行うことができます。

他のWebLogic Antタスクと組み合わせると、カスタム・ドメインでアプリケーションの実証やテストを行うための強力なビルド・スクリプトを作成できます。たとえば、単一のAntビルド・スクリプトでは、以下のことを実行できます。

- wlcompile、wlappc、およびWebサービスAntタスクを使用して、アプリケーションをコンパイルします。

- wlserver Antタスクを使用して、新しい単一サーバー・ドメインを作成し、管理サーバーを起動します。

- wlconfig Antタスクを使用して、必要なアプリケーション・リソースを備えた新しいドメインを構成します。

- wldeploy Antタスクを使用して、アプリケーションをデプロイします。

- コンパイル済みのクライアント・アプリケーションを自動的に起動して、製品の機能を実証またはテストします。

次の項では、構成用Antタスクのwlserverおよびwlconfigの使用について説明します。

wlserver Antタスクを使用したサーバーの起動とドメインの作成

wlserver Antタスクを使用すると、WebLogic Serverインスタンスを起動、再起動、および停止したり、WebLogic Serverインスタンスへ接続したりできます。サーバー・インスタンスは、構成済みのWebLogic Serverドメインにすでに存在している場合もあります。または、generateconfig=true属性を使用して、開発用の新しい単一サーバー・ドメインを作成することができます。

Antスクリプトでwlserverタスクを使用する場合、指定したサーバーが使用可能になり接続をリスニングするまでタスクは制御を戻しません。wlserverを使用してサーバー・インスタンスを起動すると、サーバー・プロセスはAnt VMの終了後に自動的に終了します。wlserverタスクを使用して、現在動作中のサーバーにのみ接続する場合、サーバー・プロセスはAntの完了後も実行し続けます。

wlserver WebLogic Server Antタスクは、標準java Antタスク(org.apache.tools.ant.taskdefs.Java)を拡張します。つまり、java Antタスクのすべての属性がwlserver Antタスクにも適用されます。たとえば、output属性とerror属性を使用してwlserver Antタスクの出力と標準エラーがそれぞれ書き込まれるファイルの名前を指定できます。標準Java Antタスクの属性の完全なドキュメント資料については、Apache AntサイトのJavaに関する項を参照してください(http://ant.apache.org/manual/Tasks/java.html)。

wlserverを使用する基本的な手順

wlserver Antタスクを使用する手順は、次のとおりです。

1. 環境を設定します。

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

Unixでは、WL_HOME/server/binディレクトリにあるsetWLSEnv.shコマンドを実行します。WL_HOMEは、インストールされているWebLogic Serverの最上位ディレクトリです。

注意:

wlserverタスクは、WebLogic Serverに付属しているバージョンのAntであらかじめ定義されています。独自にインストールしたAntでこのタスクを使用する場合は、ビルド・ファイルに次のタスク定義を追加します。

<taskdef name="wlserver" classname="weblogic.ant.taskdefs.management.WLServer"/>

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

2. サーバーの起動、停止、再起動、または接続を行うためのビルド・スクリプトに、wlserverタスクの呼出しを追加します。wlserverの属性とデフォルトの動作については、「wlserver Antタスク・リファレンス」を参照してください。

3. ステージング・ディレクトリでantと入力し、必要であればこのコマンドにターゲットの引数を渡して、build.xmlファイルで指定されたAntタスク(1つまたは複数)を実行します。

prompt> ant

wlserverタスクからより詳細なメッセージを取得するには、ant -verboseを使用します。

wlserver用build.xmlファイルのサンプル

すべてのデフォルト値を使用してカレント・ディレクトリ内のサーバーを起動する、最小限のwlserverターゲットを次に示します。

<target name="wlserver-default">
<wlserver/>
</target>

次のターゲットは、指定された接続パラメータ、およびユーザー名とパスワードの組合せを使用して、既存の動作中サーバーに接続します。

<target name="connect-server">
<wlserver host="127.0.0.1" port="7001" username="weblogic" password="weblogic" action="connect"/>
</target>

次のターゲットは、configサブディレクトリに構成されたWebLogic Serverインスタンスを起動します。

<target name="start-server">
<wlserver dir="./config" host="127.0.0.1" port="7001" action="start"/>
</target>

次のターゲットは、空のディレクトリに新しい単一サーバー・ドメインを作成し、ドメインのサーバー・インスタンスを起動します。

<target name="new-server">
<delete dir="./tmp"/>
<mkdir dir="./tmp"/>
<wlserver dir="./tmp" host="127.0.0.1" port="7001"
generateConfig="true" username="weblogic" password="weblogic" action="start"/>
</target>

wlserver Antタスク・リファレンス

次の表では、wlserver Antタスクの属性について説明します。

表2-1 Wlserver antタスクの属性

属性

説明

データ型

必須?

policy

WebLogic Serverドメインのセキュリティ・ポリシー・ファイルのパス。この属性は、サーバー・インスタンスを起動する場合にのみ使用します。

ファイル

いいえ

dir

ドメイン構成を保持するパス(c:\Oracle\Middleware\user_projects\domains\mydomainなど)。デフォルトでは、wlserverはカレント・ディレクトリを使用します。

ファイル

いいえ

beahome

Middlewareホーム・ディレクトリのパス(c:\Oracle\Middlewareなど)。

ファイル

いいえ

weblogichome

WebLogic Serverのインストール・ディレクトリのパス(たとえば、c:\Oracle\Middleware\wlserver_12.1)。

ファイル

いいえ

servername

起動、終了、再起動、または接続するサーバーの名前。

WebLogic Serverインスタンスは、そのプロトコル、ホスト、ポートの値によって一意に識別されるので、一連の属性を使用して起動、終了、再起動するサーバーを指定する場合、servername属性で実際の名前を指定する必要はありません。ただし、管理サーバーを終了する場合に限り、この属性を指定する必要があります。

この属性のデフォルト値はmyserverです。

サーバーの命名規則の詳細は、『Oracle WebLogic Serverドメイン構成の理解』のサーバー名の制限に関する項を参照してください。

文字列

管理サーバーを終了する場合にのみ必須

domainname

サーバーが構成されるWebLogic Serverドメインの名前。

文字列

いいえ

adminserverurl

ドメインの管理サーバーにアクセスするためのURL。この属性は、ドメインの管理ターゲット・サーバーを起動する場合に必須です。

文字列

管理ターゲット・サーバーを起動する場合は必須

username

管理者アカウントのユーザー名。username属性とpassword属性の両方を省略すると、wlserverはboot.propertiesファイルから暗号化されたユーザー名およびパスワードの値を取得しようとします。boot.propertiesの詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』の起動IDファイルに関する項を参照してください。

文字列

いいえ

password

管理者アカウントのパスワード。username属性とpassword属性の両方を省略すると、wlserverはboot.propertiesファイルから暗号化されたユーザー名およびパスワードの値を取得しようとします。boot.propertiesの詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』の起動IDファイルに関する項を参照してください。

文字列

いいえ

pkpassword

SSL秘密鍵ファイルを復号化するための秘密鍵パスワード。

文字列

いいえ

timeout

wlserverがサーバーの起動を待機する最大時間(ミリ秒単位)。動作中のサーバーに接続するときの最大待機時間も指定します。

この属性のデフォルト値は0で、これはサーバーがRUNNING状態に遷移するまでAntタスクが無限に待つことを意味します。

long

いいえ

timeoutSeconds

wlserverがサーバーの起動を待機する最大時間(秒単位)。動作中のサーバーに接続するときの最大待機時間も指定します。

この属性のデフォルト値は0で、これはサーバーがRUNNING状態に遷移するまでAntタスクが無限に待つことを意味します。

long

いいえ

productionmodeenabled

サーバー・インスタンスを開発モードと本番モードのどちらで起動するかを指定します。

開発モードでは、WebLogic Serverインスタンスはdomain_name/autodeployディレクトリ(domain_nameはWebLogic Serverドメインの名前)にあるアプリケーションを自動的にデプロイおよび更新できます。つまり、開発モードでは自動デプロイを使用します。本番モードでは、自動デプロイメント機能は無効になります。詳細は、「アプリケーションおよびモジュールのデプロイ」を参照してください。

この属性の有効な値は、TrueおよびFalseです。デフォルト値はFalseです(つまり、デフォルトでは、サーバー・インスタンスは開発モードで起動します。)

注意: この属性をTrueに設定して本番モードでサーバーを起動する場合は、サーバーを再起動して開発モードに戻す必要があります。つまり、WebLogic Scripting Tool (WLST)など他の管理ツールを使用して、実行中のサーバーでモードをリセットすることはできません。

ブール

いいえ

host

サーバー・インスタンスがリスニングするDNS名またはIPアドレス。

この属性のデフォルト値はlocalhostです。

文字列

いいえ

port

サーバー・インスタンスがリスニングするTCPポート番号。

この属性のデフォルト値は7001です。

int

いいえ

generateconfig

wlserverが、指定されたサーバーの新しいドメインを作成するかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

いいえ

action

wlserverが実行するアクションを指定します。 start、shutdown、reboot、またはconnect。

shutdownアクションは、強制停止を実行するforceshutdown属性(オプション)と組み合わせて使用することもできます。

この属性のデフォルト値はstartです。

文字列

いいえ

failonerror

WebLogic Server Antタスクで使用されるグローバル属性。ビルド中にエラーが発生した場合、タスクを失敗させるかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

いいえ

forceshutdown

この省略可能な属性は、強制停止を実行するためにaction="shutdown"属性と組み合わせて使用されます。例:

<wlserver
host="${wls.host}"
port="${port}"
username="${wls.username}"
password="${wls.password}"
action="shutdown"
forceshutdown="true"/>

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

いいえ

noExit

(オプション) Antが終了した後もサーバー・プロセスを実行したままにします。有効な値は、trueまたはfalseです。デフォルト値はFalseで、Antが終了するとサーバー・プロセスも停止することを意味します。

ブール

いいえ

protocol

wlserver AntタスクがWebLogic Serverインスタンスとの通信に使用するプロトコルを指定します。

有効な値は、t3、t3s、http、https、およびiiopです。デフォルト値はt3です。

文字列

いいえ

forceImplicitUpgrade

8.1以前のドメインで実行されているwlserver Antタスクがドメインを暗黙的にアップグレードするかどうかを指定します。

有効な値は、trueまたはfalseです。デフォルト値はfalse。つまり、Antタスクは暗黙的にドメインをアップグレードせず、ドメインをアップグレードする必要があるというエラーを表示して失敗します。

ドメインのアップグレードの詳細は、『Oracle WebLogic Serverのアップグレード』を参照してください。

ブール

いいえ

configFile

ドメインの構成ファイルを指定します。

この属性の値は、http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsdのWebLogic Server Domain Configuration Schemaで定義したXMLスキーマに準拠する有効なXMLファイルである必要があります。

XMLファイルは、ドメインの管理サーバーのルート・ディレクトリ(カレント・ディレクトリか、またはdir属性で指定したディレクトリ)に存在する必要があります。

この属性を指定しない場合のデフォルトは、dir属性で指定したディレクトリのconfig.xmlになります。dir属性を指定していない場合、デフォルト・ドメインのディレクトリはカレント・ディレクトリです。

文字列

いいえ

useBootProperties

WebLogic Serverインスタンスの起動時にboot.propertiesファイルを使用するかどうかを指定します。この属性がtrueに設定されている場合、WebLogic Serverは、boot.propertiesファイルに格納されているユーザー名と暗号化されているパスワードを使用して、username属性とpassword属性で設定された値以外から起動します。

注意: WebLogic Serverインスタンスの終了時と再起動時にもusernameとpassword属性の値が使用されます。useBootProperties属性は、サーバーの起動時にのみ適用されます。この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

いいえ

verbose

Antタスクが、アクションの実行中に追加情報を出力するかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

いいえ

wlconfig Antタスクを使用したWebLogic Serverドメインの構成

次の項では、wlconfig Antタスクを使用してWebLogic Serverドメインを構成する方法について説明します。

注意:

同等の機能を実現するには、WebLogic Scripting Tool (WLST)を使用する必要があります。『WebLogic Scripting Toolの理解』を参照してください。

wlconfig Antタスクの機能

wlconfig Antタスクを使用すると、動作中の管理サーバー・インスタンス上でMBeanの作成、問合せ、変更を行うことで、WebLogic Serverドメインを構成できます。特に、wlconfigでは次のことを実行できます。

- 新しいMBeanを作成し、必要に応じて新しいMBeanオブジェクト名をAntプロパティに格納します。

- 管理サーバー上で使用可能な、指定したMBeanに属性値を設定します。

- MBeanを作成するコマンドの内部に属性を設定するコマンドをネストすることで、MBeanの作成と属性の設定を1回の手順で行います。

- MBeanの問合せを実行し、必要に応じて問合せの結果をAntプロパティ参照内に格納します。

- MBeanの問合せを実行し、一致するすべての結果に対して属性を設定します。

- 作成コマンドを他の作成コマンドの内部にネストすることで、MBean間の親子関係を確立します。

wlconfigを使用する基本的な手順

1. コマンド・シェルで環境を設定します。詳細は、「wlserverを使用する基本的な手順」を参照してください。

注意:

wlconfigタスクは、WebLogic Serverに付属しているバージョンのAntであらかじめ定義されています。独自にインストールしたAntでこのタスクを使用する場合は、ビルド・ファイルに次のタスク定義を追加します。

<taskdef name="wlconfig" classname="weblogic.ant.taskdefs.management.WLConfig"/>

2. Antタスクのコンテキストで作成された新しいWebLogic Serverドメインを構成するには、通常wlconfigをwlserverと組み合わせて使用します。wlconfigを使用してそのようなドメインを構成する場合は、最初にwlserver属性を使用して新しいドメインを作成し、WebLogic Serverインスタンスを起動します。

3. wlconfigタスクの最初の呼出しを追加して、ドメインの管理サーバーに接続します。例:

<target name="doconfig">
<wlconfig url="t3://localhost:7001" username="weblogic"
password=password>
</target>

4. ネストされたcreate、delete、get、setおよびquery要素を追加して、ドメインを構成します。

5. ステージング・ディレクトリでantと入力し、必要であればこのコマンドにターゲットの引数を渡して、build.xmlファイルで指定されたAntタスク(1つまたは複数)を実行します。

prompt> ant doconfig

wlconfigタスクからより詳細なメッセージを取得するには、ant -verboseを使用します。

注意:

ドメイン作成スクリプトとしてはWLSTをお薦めします。ソフトウェアとともにインストールされているオフラインのWLSTサンプル・スクリプトを参照してください。これらのスクリプトを参照すると、ドメイン・テンプレートを使用してドメインを作成する方法が理解できます。オフライン・スクリプトは、WL_HOME\common\templates\scripts\wlstディレクトリにあります。WL_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリを表します。たとえば、basicWLSDomain.pyスクリプトを実行すると、単純なWebLogicドメインが作成されます。一方、sampleMedRecDomain.pyを実行すると、Avitek MedRecサンプルで使用するようなリソースを定義したドメインが作成されます。『WebLogic Scripting Toolの理解』を参照してください。

wlconfig Antタスク・リファレンス

次の項では、wlconfigで使用可能な属性と要素について説明します。

主な属性

次の表では、wlconfig Antタスクの主な属性について説明します。

表2-2 wlconfig Antタスクの主な属性

属性

説明

データ型

必須?

url

ドメインの管理サーバーのURL。

文字列

はい

username

管理者アカウントのユーザー名。

文字列

いいえ

password

管理者アカウントのパスワード。

ビルド・ファイルまたはpsなどのプロセス・ユーティリティでパスワードがプレーン・テキストで表示されないようにするには、まずWebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用して有効なユーザー名と暗号化されたパスワードを構成ファイルに格納します。次に、Antビルド・ファイルでusernameとpasswordの両属性を省略します。これらの属性を省略すると、wlconfigはデフォルト構成ファイルの値を使用してログインを試みます。

デフォルト以外の構成ファイルとキー・ファイルからユーザー名およびパスワードを取得する場合は、wlconfigでuserconfigfile属性およびuserkeyfile属性を使用します。

パスワードの格納と暗号化の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstoreUserConfigのコマンド・リファレンスに関する項を参照してください。

文字列

いいえ

failonerror

WebLogic Server Antタスクで使用されるグローバル属性。ビルド中にエラーが発生した場合、タスクを失敗させるかどうかを指定します。この属性は、デフォルトでtrueに設定されます。

ブール

いいえ

userconfigfile

管理ユーザー名および管理パスワードを取得するために使用するユーザー構成ファイルの場所を指定します。このオプションは、プレーン・テキストのパスワードをインラインに表示したくない場合はビルド・ファイルで、またはpsなどのプロセス・レベルのユーティリティでusernameおよびpassword属性のかわりに使用します。

userconfigfile属性を指定する前に、『WebLogic Server WLSTコマンド・リファレンス』の説明に従い、WebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用して、まずファイルを生成する必要があります。

ファイル

いいえ

userkeyfile

ユーザー構成ファイル(userconfigfile属性)に格納されたユーザー名とパスワードの情報を暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

userkeyfile属性を指定する前に、『WebLogic Server WLSTコマンド・リファレンス』の説明に従い、WebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用して、まずキー・ファイルを生成する必要があります。

ファイル

いいえ

ネストされる要素

wlconfigには、構成オプションを指定するためにネストできる要素もあります。

- create

- delete

- set

- get

- query

- invoke

create

create要素は、WebLogic Serverドメインで新しいMBeanを作成します。wlconfigタスクにはcreate要素をいくつでも指定できます。

create要素には、ネストされたset要素をいくつでも指定できます。この要素では、新しく作成されるMBeanの属性を設定します。create要素にはネストされたcreate要素を追加することもできます。この要素は子MBeanを作成します。

create要素には次の属性があります。

表2-3 create要素の属性

属性

説明

データ型

必須?

name

作成する新しいMBeanオブジェクトの名前。

文字列

いいえ(何も指定しない場合、wlconfigがデフォルト名を供給します。)

type

MBeanタイプ。

文字列

はい

property

新しく作成されるMBeanのオブジェクト名を保持するオプションのAntプロパティの名前。

注意: create要素を別のcreate 要素の中にネストした場合、ネストしたcreate要素にはproperty属性を指定できません。

文字列

いいえ

delete

delete要素は、WebLogic Serverドメインから既存のMBeanを削除します。delete要素には属性が1つあります。

表2-4 delete要素の属性

属性

説明

データ型

必須?

mbean

削除するMBeanのオブジェクト名。

文字列

delete要素がwlconfigタスクの直接の子である場合は必須です。query要素内にネストされている場合は省略可能です。

set

set要素は、指定されたMBean、新しく作成されたMBean、または問合せの一部として取得されたMBeanに対して、MBean属性を設定します。set要素は、wlconfigタスクの直接の子として、またはcreate要素やquery要素の内部にネストして指定することができます。

set要素には次の属性があります。

表2-5 set要素の属性

属性

説明

データ型

必須?

attribute

設定するMBean属性の名前。

文字列

はい

value

指定されたMBean属性に設定する値。

値のリスト全体を引用符で囲み、オブジェクト名をセミコロンで区切ることによって、(Antプロパティに格納されている)複数のオブジェクト名を1つの値として指定できます。

文字列

はい

mbean

値を設定するMBeanのオブジェクト名。この属性は、set要素がメインのwlconfigタスクの直接の子として指定される場合にのみ必須ですが、set要素がcreateまたはquery要素のコンテキスト内にネストされる場合は省略可能です。

文字列

set要素がwlconfigタスクの直接の子である場合にのみ必須

domain

この属性は、セキュリティMBeanまたはサード・パーティSPI MBeanのJMXドメイン名を指定します。ドメインはWebLogic Serverドメインに相当するため、管理MBeanの場合は省略可能です。

注意: set要素をcreate要素の中にネストした場合、この属性は使用できません。

文字列

いいえ

get

get要素は、WebLogic ServerドメインのMBeanから属性値を取得します。wlconfigタスクにはget要素をいくつでも指定できます。

get要素には次の属性があります。

表2-6 get要素の属性

属性

説明

データ型

必須?

attribute

値を取得するMBean属性の名前。

文字列

はい

property

取得したMBean属性値を保持するAntプロパティの名前。

文字列

はい

mbean

属性値を取得するMBeanのオブジェクト名。

文字列

はい

query

query要素は検索パターンに一致するMBeanを見つけます。

query要素は、以下のネストされた子要素をサポートします。

- set - 結果セット内のすべてのMBeanに対してset操作を実行します。

- get - 結果セット内のすべてのMBeanに対してget操作を実行します。

- create - 結果セット内の各MBeanが、新しいMBeanの親として使用されます。

- delete - 結果セット内のすべてのMBeanに対してdelete操作を実行します。

- invoke - 結果セット内で一致するMBeanをすべて呼び出します。

wlconfigタスクには、ネストされたquery要素をいくつでも指定できます。

queryには次の属性があります。

表2-7 query要素の属性

属性

説明

データ型

必須?

domain

MBeanを検索するWebLogic Serverドメインの名前。

文字列

いいえ

type

問合せを実行するMBeanのタイプ。

文字列

いいえ

name

問合せを実行するMBeanの名前。

文字列

いいえ

pattern

JMX問合せパターン。

文字列

いいえ

property

問合せ結果を格納するオプションのAntプロパティの名前。

文字列

いいえ

domain

この属性は、セキュリティMBeanまたはサード・パーティSPI MBeanのJMXドメイン名を指定します。ドメインはWebLogic Serverドメインに相当するため、管理MBeanの場合は省略可能です。

文字列

いいえ

invoke

invoke要素は、1つまたは複数のMBeanの管理操作を呼び出します。WebLogic Server Mbeanの場合、通常このコマンドを使用して、ほとんどのWebLogic Server MBeanが備えているgetAttributeとsetAttribute以外の操作を呼び出します。

invoke要素には次の属性があります。

表2-8 invoke要素の属性

属性

説明

データ型

必須?

mbean

呼び出すMBeanのオブジェクト名。

文字列

invoke要素のmbean属性またはtype属性の指定が必須です。

type

呼出しを実行するMBeanのタイプ。

文字列

invoke要素のmbean属性またはtype属性の指定が必須です。

methodName

呼出しを実行するMBeanのメソッド。

文字列

はい

arguments

methodName属性で指定したメソッドに渡される引数のリスト(スペース区切り)。

文字列

いいえ

wlconfig Antタスクを使用したセキュリティ・レルムの作成の例

次の例に、wlconfig Antタスクを使用してセキュリティ・レルムを作成する方法を示します。

例2-1 wlconfigを使用したセキュリティ・レルムの作成

<wlconfig url="t3://myhost:7001"
username="weblogic"
password="password">
<create type="weblogic.management.security.Realm" name="MyRealm" property="new.provider">
<set attribute="DefaultRealm" value="false"/>
<create name="MyAuthenticator" type="weblogic.security.providers.authentication.DefaultAuthenticator" realm="MyRealm"/>
<create name="MyAuthorizer" type="weblogic.security.providers.authorization.DefaultAuthorizer" realm="MyRealm"/>
<create name="MyRoleMapper" type="weblogic.security.providers.authorization.DefaultRoleMapper" realm="MyRealm"/>
<create name="MyCredentialMapper" type="weblogic.security.providers.credentials.DefaultCredentialMapper" realm="MyRealm"/>
<create name="MyCertPathProvider" type=""weblogic.security.providers.pk.WebLogicCertPathProvider" realm="MyRealm"/>
</create>
<set mbean="Security:Name=MyRealm" attribute="CertPathBuilder" value="Security:Name=MyRealmMyCertPathProvider"/>
</wlconfig>

libclasspath Antタスクの使用

libclasspath Antタスクは、アプリケーション・ライブラリやWebライブラリなどのライブラリを使用するアプリケーションをビルドするために使用します。

- libclasspathタスクの定義

- wlserver Antタスク・リファレンス

- libclasspath Antタスクの例

libclasspathタスクの定義

独自にインストールしたAntでこのタスクを使用するには、ビルド・ファイルに次のタスク定義を追加します。

<taskdef name="libclasspath" classname="weblogic.ant.taskdefs.build.LibClasspathTask"/>

libclasspath Antタスク・リファレンス

次の項では、libclasspath Antタスクで使用できる属性と要素について説明します。

- libclasspathの主な属性

- ネストされるlibclasspathの要素

libclasspathの主な属性

次の表では、libclasspath Antタスクの主な属性について説明します。

表2-9 libclasspath Antタスクの属性

属性

説明

必須

basedir

抽出元の.earまたは.warファイルのルート。

basedirまたはbasewarが必須。

basewar

抽出元の.warファイルの名前。

basewarを指定した場合、basedirは無視されて、basewarで参照されているライブラリが、クラスパスまたはリソース・パースの情報の抽出元となる.warファイルとして使用されます。

tmpdir

ライブラリの抽出に使用されるディレクトリの完全修飾名。

はい。

classpathproperty

参照されるライブラリのクラスパスを指定します。

たとえば、basedirがweblogic.xmlファイル内のWebアプリケーション・ライブラリを参照する.warファイルを指している場合、classpathpropertyにはWebアプリケーション・ライブラリのWEB-INF/classesおよびWEB-INF/libディレクトリを指定します。

また、basedirがWEB-INF/bea-ext以下に.warのファイル群を格納した.warファイルを指している場合、classpathpropertyには、このOracle拡張機能のWEB-INF/classesおよびWEB-INF/libディレクトリを指定します。

2つの属性のうち少なくとも1つが必須。

resourcepathproperty

クラスではないライブラリ・リソースを指定します。

たとえば、basedirがWEB-INF/bea-ext以下に.warのファイル群を格納した.warファイルを指している場合、resourcepathpropertyには展開された拡張機能のルートを指定します。

ネストされるlibclasspathの要素

libclasspathには、構成オプションを指定するためにネストできる2つの要素があります。libclasspath Antタスクを使用する場合は、少なくともこのうちの1つの要素が必要です。

librarydir

この要素を使用する場合は次の属性が必須です。

dir - このディレクトリのすべてのファイルが使用可能なライブラリとして登録されることを指定します。

library

この要素を使用する場合は次の属性が必須です。

file-このファイルが使用可能なライブラリとして登録されます。

libclasspath Antタスクの例

この項では、libclasspath Antタスクのサンプル・コードを示します。

例2-2 libclasspath Antタスクのサンプル・コード

.
.
.
<taskdef name="libclasspath" classname="weblogic.ant.taskdefs.build.LibClasspathTask"/>

<!-- Builds classpath based on libraries defined in weblogic-application.xml. -->
<target name="init.app.libs">
<libclasspath basedir="${src.dir}" tmpdir="${tmp.dir}" classpathproperty="app.lib.classpath">
<librarydir dir="${weblogic.home}/common/deployable-libraries/"/>
</libclasspath>
<echo message="app.lib.claspath is ${app.lib.classpath}" level="info"/>
</target>
.
.
.

window.name='maven' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
3 WebLogic Mavenプラグインの使用方法

Apache Mavenは、Javaベース・プロジェクトの構築および管理を行うためのソフトウェア・ツールです。WebLogic Server は、Maven環境内からWebLogic Server上で様々な処理を実行できるようにするプラグインのプロビジョニングによってMavenのサポートを提供しています。

weblogic-maven-pluginは、インストール、サーバーの起動と停止、ドメインの作成、WLSTスクリプトの実行、およびアプリケーションのコンパイルとデプロイのための拡張機能を提供します。weblogic-maven-pluginを使用すると、必要に応じて、ご使用のMaven環境内からWebLogic Serverをインストールし、ローカルWebLogic Server要件を満たすことができます。

次の項では、weblogic-maven-pluginの使用方法について説明します。

- Mavenのインストール

- WebLogic Mavenプラグインの構成

- Mavenプラグインのゴール

追加のMavenのドキュメントについては、『継続的インテグレーションによるアプリケーションの開発』を参照してください。特に、Mavenを使用したWebLogic Server用のJava EEプロジェクトの構築に関する項を参照してください。

Mavenのインストール

weblogic-maven-pluginプラグインを使用するには、その前にまず、機能するMavenインストールとMavenリポジトリを設定する必要があります。WebLogic Serverは、Maven 3.0.4以降をサポートしています。

Maven 3.2.5の配布はWebLogic Serverに付属しており、次の場所にあります。ORACLE_HOME\oracle_common\modules\org.apache.maven_3.2.5これは、変更を含まない、標準のMaven 3.2.5リリースのコピーです。

ORACLE_HOME\wlserver\server\bin\setWLSEnvスクリプトを実行して、Mavenを構成します。

別の方法として、Maven Webサイト(http://maven.apache.org)からMavenの独自のコピーをダウンロードしてインストールすることもできます。該当するドキュメントの詳細に従って、必要な変数(M2_HOMEやJAVA_HOMEなど)を設定するようにしてください。

注意:

weblogic-maven-pluginは、Javaプロトコル・ハンドラをweblogic.netに設定します。デフォルトのJDKプロトコル・ハンドラを使用するには、Mavenを実行するJVMのシステム・プロパティ-DUseSunHttpHandler=trueを指定します。これを実行するには、mvn.batまたはmvn.shファイル内の環境変数MAVEN_OPTSをオーバーライドして、適切な値を設定します。次に例を示します。set MAVEN_OPTS="-DUseSunHttpHandler=true"

アプリケーションとプロジェクトを構築するためのMavenのインストールと使用方法の詳細は、http://maven.apache.org/users/index.htmlのMavenユーザー・センターに関する項を参照してください。

WebLogic Mavenプラグインの構成

weblogic-maven-pluginプラグインは、組込み済JARファイルとそれに付随するpomファイルとして提供されます。

weblogic-maven-pluginをインストールおよび構成する手順は、次のとおりです。

1. Oracle Maven同期プラグインをインストールして、pushゴールを実行します。

a. ディレクトリを、ORACLE_HOME\oracle_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.2.1に変更します。

b. mvn install:install-file -DpomFile=oracle-maven-sync-12.2.1.pom -Dfile=oracle-maven-sync-12.2.1.jar。

c. mvn com.oracle.maven:oracle-maven-sync:push -DoracleHome=c:\oracle\middleware\oracle_home\。

2. Maven help:describeゴールを使用して、プラグインのインストールが成功したかどうかを検証できます。詳細は、Apacheヘルプ・プラグインdescribeゴールのドキュメントを参照してください。

mvn help:describe -DgroupId=com.oracle.weblogic
-DartifactId=weblogic-maven-plugin -Dversion=12.2.1-0-0

WebLogic Mavenプラグインの使用方法

WebLogic Mavenプラグインのゴールを呼び出すには、次の2つの方法があります。

- MavenプロジェクトPOMから

- コマンド・ラインから

appc、wsgen、wsimport、ws-jwsc、ws-wsdlcおよびws-clientgenゴールは、POMを必要とします。

他のゴールはいずれの方法でも正常に呼び出せます。たとえば、install、wlst、wlst-client、start-serverまたはstop-serverは、POMからでも、コマンド・ラインからでも呼び出せます。

望ましいお薦めの方法は、Maven POMファイルを使用することです。

POMファイルからWebLogic Mavenプラグイン・ゴールを呼び出すには、次の操作を実行します。

1. buildセクションが未設定の場合は、POMにbuildセクションを追加します。

2. WebLogic Mavenプラグインのbuildセクションにplug-inセクションを追加します。

3. 実行するゴールごとに、WebLogic Mavenプラグインのpluginセクションにexecutionセクションを追加します。このセクションではゴールに必要なパラメータを提供し、Mavenライフサイクルのフェーズにゴールをマップする必要があります。

次は、数個のゴールを含む、必要な追加の例を示しています。このセクションの後半にある各ゴールの詳細な説明は、各ゴールのパラメータと例の詳細を示しています。

同じライフサイクル・フェーズに複数のゴールをマップした場合は、通常、POMでリストした順序で実行されます。

例3-1 POMファイルの変更

<build>
<plugins>
<plugin>
<!-- This is the configuration for the
weblogic-maven-plugin
-->
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<configuration>
<middlewareHome>/fmwhome/wls12210</middlewareHome>
</configuration>
<executions>
<!-- Execute the appc goal during the package phase -->
<execution>
<id>wls-appc</id>
<phase>package</phase>
<goals>
<goal>appc</goal>
</goals>
<configuration>
<source>${project.build.directory}/${project.name}.${project.packaging}</source>
</configuration>
</execution>
<!-- Deploy the application to the WebLogic Server in the
pre-integration-test phase
-->
<execution>
<id>wls-deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<!--The admin URL where the app is deployed.
Here use the plugin's default value t3://localhost:7001-->
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<!--The location of the file or directory to be deployed-->
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source>
<!--The target servers where the application is deployed.
Here use the plugin's default value AdminServer-->
<targets>AdminServer</targets>
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>
<!-- Stop the application in the pre-integration-test phase -->
<execution>
<id>wls-stop-app</id>
<phase>pre-integration-test</phase>
<goals>
<goal>stop-app</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<name>${project.build.finalName}</name>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

表3-1には、デフォルトのMavenライフサイクルのフェーズがリストされています。

表3-1 Mavenライフサイクルのフェーズ

フェーズ

説明

validate

プロジェクトが正しく、必要なすべての情報が利用可能であることを検証します。

compile

プロジェクトのソース・コードをコンパイルします。

test

フレームワークをテストする適切なユニットを使用して、コンパイルされたソース・コードをテストします。これらのテストで、コードをパッケージ化したりデプロイすることは要求されません。

package

コンパイルされたコードを取得して、JARなどの配布可能なフォーマットでパッケージ化します。

integration-test

パッケージを処理して、必要に応じて統合テストを実行できる環境にデプロイします。

verify

チェックを実行して、パッケージが有効であり、品質基準を満たしていることを確認します。

install

ローカルで他のプロジェクトにおける依存関係として使用するために、パッケージをローカル・リポジトリにインストールします。

deploy

統合またはリリース環境で、他の開発者やプロジェクトと共有するために、最終パッケージをリモート・リポジトリにコピーします。

表3-2は、フェーズに対するゴールの最も一般的なマッピングを示しています。

表3-2 フェーズに対するゴールの一般的なマッピング

フェーズ

ゴール

validate

ws-clientgen、ws-wsdlc

compile

ws-jwsc

test

NA

package

appc

pre-integration-test脚注 1

install、create-domain、start-server、distribute-app、deploy、purge-tasks、redeploy、update-app、start-app、stop-app、wlst、wlst-clientおよびlist-apps

post-integration-test脚注 2

remove-domain、undeploy、stop-server、uninstall

verify

NA

install

NA

deploy

NA

脚注 1

integration-testフェーズには、統合テストの実際の実行の前にそれぞれ実行される、事前サブフェーズがあります。

脚注 2

integration-testフェーズには、統合テストの実際の実行の後にそれぞれ実行される、事後サブフェーズがあります。

基本構成POMファイル

例3-2は、weblogic-maven-plugin appcゴールの使用をデモする基本的なJava EE Webアプリケーションのpom.xmlファイルを示しています。

例3-2 基本構成pom.xmlファイル

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>demo.sab</groupId>
<artifactId>maven-demo</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>

<name>maven-demo</name>

<properties>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<dependencies>
<dependency>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-server-pom</artifactId>
<version>12.2.1-0-0</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
</dependencies>

<build>
<plugins>
...
...

<!-- WebLogic Server 12c Maven Plugin -->
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
</plugin>
<configuration>
</configuration>
<executions>
<execution>
<id>wls-appc</id>
<phase>package</phase>
<goals>
<goal>appc</goal>
</goals>
<configuration>
<source>${project.build.directory}/${project.name}.
${project.packaging}</source>
</configuration>
</execution>
</executions>
</plugins>
</build>

</project>

Mavenプラグインのゴール

表3-3では、すべてのweblogic-maven-pluginゴールを一覧表示しています。各ゴールの詳細は、後の項で説明します。

表3-3 Mavenプラグインのゴール

ゴール名

説明

appc

EJBおよびJSPをWebLogic Serverにデプロイするために必要なクラスを生成およびコンパイルします。また、個別のモジュール・レベルおよびアプリケーション・レベルの両方で現在の仕様に準拠しているかどうか、デプロイメント記述子を検証します。

create-domain

ドメイン・テンプレートを使用してWebLogic Serverドメインを作成します。このゴールは、ドメイン・ディレクトリ(最後のディレクトリでドメイン名を決定)および管理ユーザー名とパスワードの指定をサポートしています。より複雑なドメインを作成する場合は、wlstゴールを使用します。

deploy

実行中のサーバーにWebLogic Serverアプリケーションおよびモジュールをデプロイします。WAR、JAR、RARなどのすべてのデプロイメント・フォーマットをサポートします。

distribute-app

デプロイメント・ファイルをターゲット・サーバーにコピーして検証することで、デプロイメント用に準備します。

install

WebLogic Serverをインストールします。

list-apps

ドメインにデプロイ、配布、またはインストールされているアプリケーションおよびスタンドアロン・モジュールのデプロイメント名をリストします。

purge-tasks

リタイアしたデプロイメント・タスクをフラッシュします。

redeploy

実行中のアプリケーションまたは実行中のアプリケーションの一部を再デプロイします。

remove-domain

ドメイン・ディレクトリを削除します。

start-app

WebLogic Server上にデプロイされたアプリケーションを起動します。

start-server

WebLogic Serverを起動します。このゴールは、ローカル起動スクリプトを実行して、WLSを起動します。ノード・マネージャを使用してリモート・サーバーを起動する場合は、かわりにwlstゴールを使用します。

stop-app

アプリケーションを停止します。

stop-server

WebLogic Serverを停止します。このゴールは、ローカル起動スクリプトを実行して、WLSを停止します。ノード・マネージャを使用してリモート・サーバーを停止する場合は、かわりにwlstゴールを使用します。

undeploy

WebLogic Serverからアプリケーションをアンデプロイします。デプロイメント・ユニットを停止して、ステージングされているファイルをターゲット・サーバーから削除します。

uninstall

WebLogic Serverをアンインストールします。

update-app

プラン・ファイルを再分散して、新しいプランの内容に基づいてアプリケーションを再構成することで、アプリケーションのデプロイメント・プランを更新します。

wlst

Maven用のWLSTラッパー。

wlst-client

ローカル・サーバーのインストールを必要とせずにWLSTオンライン・コマンドを実行するためのWLSTラッパー。

ws-clientgen

WSDLからクライアントWebサービス・アーティファクトを生成します。

wsgen

JAX-WSサービスのエンドポイント実装クラスで、JAX-WS Webサービスで使用されるすべてのポータブル・アーティファクトを生成します。

wsimport

WSDLファイルとバインディング・ファイルを解析し、そのアクセスに必要なJavaコードを生成するMavenゴール。

ws-jwsc

JAX-WS Webサービスを構築します。

ws-wsdlc

WSDLから一連のアーティファクトと、Webサービスの部分的なJava実装を生成します。

appc

完全名

com.oracle.weblogic:weblogic-maven-plugin:appc

説明

EJBおよびJSPをWebLogic Serverにデプロイするために必要なクラスを生成およびコンパイルします。また、個別のモジュール・レベルおよびアプリケーション・レベルの両方で現在の仕様に準拠しているかどうか、デプロイメント記述子を検証します。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-4 appcのパラメータ

名前

タイプ

必須

説明

altappdd

java.lang.String

いいえ

代替ディスクリプタを指定します。.earデプロイメント用に代替application.xml、またはスタンドアロン・モジュール・デプロイメント用に代替web.xmlか代替ejb.xmlを指定するために使用することができます。

altwlsappdd

java.lang.String

いいえ

代替WebLogic Serverアプリケーション・デプロイメント記述子のパスを指定します。

basicClientJar

boolean

いいえ

trueの場合、EJB用に生成されたクライアントJARのデプロイメント記述子を含みません。デフォルト値: false

classpath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。かわりに標準のMaven依存関係モデルを使用して、ビルド時に有効なCLASSPATHを操作します。

clientJarOutputDir

java.lang.String

いいえ

生成されたクライアントJARが書き込まれるディレクトリを指定します。

commentary

boolean

いいえ

このパラメータはこのリリースでは非推奨となっています。

compiler

java.lang.String

いいえ

生成されたJavaソース・コードからクラス・ファイルをコンパイルするためのJavaコンパイラを指定します。コンパイラの絶対パスを明示的に指定する場合を除いて、Javaコンパイラ・プログラムはPATH内になければなりません。デフォルト値: javac

compilerClass

java.lang.String

いいえ

このクラスはコンパイラを呼び出します。デフォルト値: com.sun.tools.javac.Main

continueCompilation

boolean

いいえ

trueの場合、JSPファイルにエラーがある場合でもコンパイルを続行します。デフォルト値: false

debug

boolean

いいえ

trueの場合、デバッグ情報をクラス・ファイルにコンパイルします。デフォルト値: false

deprecation

boolean

いいえ

trueの場合、生成されたJavaソース・ファイルをクラス・ファイルにコンパイルしているときに、ソース・ファイル中に非推奨のメソッドが使用されていると警告します。デフォルト値: false

destdir

java.io.File

いいえ

コンパイルされたクラス・ファイルが書き込まれるディレクトリを指定します。このパラメータは、コンパイルされたクラスを、すでにCLASSPATHに入っているディレクトリに置くために使用します。

enableHotCodeGen

boolean

いいえ

このパラメータはこのリリースでは非推奨となっています。

forceGeneration

boolean

いいえ

trueの場合、EJBおよびJSPクラスを強制的に生成します。それ以外の場合、必要ないと判断されると、クラスは再生成されません。デフォルト値: false

idl

boolean

いいえ

trueの場合、EJBリモート・インタフェース用のIDLを生成します。デフォルト値: false

idlDirectory

java.lang.String

いいえ

IDLファイルが書き込まれるディレクトリを指定します。デフォルト: ターゲット・ディレクトリまたはJAR

idlFactories

boolean

いいえ

trueの場合、値タイプ用にファクトリ・メソッドを生成します。デフォルト値: false

idlMethodSignatures

java.lang.String

いいえ

IDLコードを生成するトリガーとして使用されるメソッド・シグネチャを指定します。

idlNoAbstractInterfaces

boolean

いいえ

trueの場合、抽象インタフェース、およびそれらを含むメソッドまたは属性を生成しません。デフォルト値: false

idlNoValueTypes

boolean

いいえ

値タイプ、またはそれらを含むメソッドと属性を生成しません。デフォルト値: false

idlOrbix

boolean

いいえ

trueの場合、Orbix 2000 2.0 C++と多少の互換性を持つIDLを生成します。デフォルト値: false

idlOverwrite

boolean

いいえ

trueの場合、既存のIDLファイルを上書きします。デフォルト値: false

idlVerbose

boolean

いいえ

trueの場合、IDL生成に関する追加のステータス情報を表示します。デフォルト値: false

idlVisibroker

boolean

いいえ

trueの場合、Visibroker 4.5 C++と多少の互換性を持つIDLを生成します。デフォルト値: false

ignorePlanValidation

boolean

いいえ

trueの場合、プラン・ファイルが存在しなければそれを無視します。

iiop

boolean

いいえ

trueの場合、EJB用にCORBAのスタブを生成します。デフォルト値: false

iiopDirectory

java.lang.String

いいえ

IIOPスタブ・ファイルが書き込まれるディレクトリを指定します。デフォルト: ターゲット・ディレクトリまたはJAR

keepgenerated

boolean

いいえ

trueの場合、生成された.javaファイルを保持します。デフォルト値: false

libraries

java.lang.String

いいえ

ライブラリのカンマ区切りのリスト。

librarydir

java.io.File

いいえ

指定したディレクトリ内のすべてのファイルをライブラリとして登録します。

lineNumbers

boolean

いいえ

trueの場合、生成されたクラス・ファイルにJSPの行番号を追加し、デバッグを支援します。デフォルト値: false

manifest

java.io.File

いいえ

このパラメータはこのリリースでは非推奨となっています。標準のMavenメカニズムを使用して、パッケージ化時にマニフェストを指定します。

maxfiles

java.lang.Integer

いいえ

生成されたJavaファイルを一度にコンパイルする最大数を指定します。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

noexit

boolean

いいえ

trueの場合、JSPコンパイル・エラーが発生したときにappcゴールの実行を終了しません。デフォルト値: true

normi

boolean

いいえ

このパラメータはこのリリースでは非推奨となっています。

nowarn

boolean

いいえ

trueの場合、コンパイラに関する警告を表示しません。デフォルト値: false

nowrite

boolean

いいえ

このパラメータはこのリリースでは非推奨となっています。

optimize

boolean

いいえ

trueの場合、最適化を有効にしてコンパイルします。デフォルト値: false

output

java.io.File

いいえ

代替的な出力アーカイブまたはディレクトリを指定します。設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。

plan

java.io.File

いいえ

デプロイメント・プラン(オプション)のパスを指定します。

quiet

boolean

いいえ

trueの場合、エラー以外は出力をオフにします。

runtimeFlags

java.lang.String

いいえ

コンパイラにオプションのリストを渡します。

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。かわりに標準のMaven依存関係モデルを使用して、有効なCLASSPATHを操作します。

source

java.io.File

いいえ

ソース・ファイルのパスを指定します。デフォルト値: ${project.build.directory}/${project.artifactId}.${project.packaging}

sourceVersion

java.lang.String

いいえ

Javaファイルの互換性を、指定されたJDK以前のバージョンに制限します。例: "1.5"デフォルト値は、使用するJavaコンパイラのJDKのバージョンです。

supressCompiler

boolean

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。かわりに標準のMaven依存関係モデルを使用して、ビルド時に有効なCLASSPATHにターゲット・クラスを追加します。

targetVersion

java.lang.String

いいえ

コンパイルされたクラス・ファイルの実行に最低限必要なレベルのJVMを指定します。例: "1.5"デフォルト値は、使用するJavaコンパイラのJDKのバージョンです。

verbose

boolean

いいえ

trueの場合、コンパイル処理中のステータスに関する追加情報を表示します。デフォルト値: false

verboseJavac

boolean

いいえ

trueの場合、Javaコンパイラからの詳細出力を有効にします。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

writeInferredDescriptors

boolean

いいえ

trueの場合、アノテーションを含む推測情報とともに記述子を出力します。

使用例

appcゴールは、WebLogic Serverアプリケーション・コンパイラ・ユーティリティを実行し、デプロイメント用のアプリケーションを準備します。

<execution>
<id>wls-appc</id>
<phase>package</phase>
<goals>
<goal>appc</goal>
</goals>
<configuration>
<source>${project.build.directory}/${project.name}.${project.packaging}</source>
</configuration>
</execution>

例3-3では、典型的なappcゴールの出力を示します。

例3-3 appc

$ mvn com.oracle.weblogic:weblogic-maven-plugin:appc
-Dsource=target/basicWebapp.war -DforceGeneration=true
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building basicWebapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:appc (default-cli) @ main-test ---
[INFO] Running weblogic.appc on
/home/oracle/src/tests/main-test/target/basicWebapp.war
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.901s
[INFO] Finished at: Wed Aug 19 10:52:46 EST 2015
[INFO] Final Memory: 26M/692M
[INFO]

create-domain

完全名

com.oracle.weblogic:weblogic-maven-plugin:create-domain

説明

ドメイン・テンプレートを使用してWebLogic Serverドメインを作成します。このゴールは、ドメイン・ディレクトリ(最後のディレクトリでドメイン名を決定)および管理ユーザー名とパスワードの指定をサポートしています。より複雑なドメインを作成する場合は、wlstゴールを使用します。

注意:
バージョン12.2.1以降、ORACLE_HOMEのすべての製品からWLST環境を自動的に取り込むWLSTの単一の統合されたバージョンがあります。

パラメータ

表3-5 create-domainのパラメータ

名前

タイプ

必須

説明

domainHome

java.lang.String

true

ドメインの作成に使用するディレクトリを指定します。このゴールは、ドメイン名として指定された最後のサブディレクトリの名前を取得して、新しいドメインの名前をその値に設定します。たとえば、domainHome=/weblogic/domains/MyNewDomainと指定すると、ドメイン名が'MyNewDomain'に設定されます。

domainTemplate

java.lang.String

いいえ

ドメインを作成するために使用するドメイン・テンプレート・ファイルを指定します。このパラメータを指定しない場合、WebLogic Serverに組み込まれているデフォルトのドメイン・テンプレートが使用されます。

failOnDomainExists

boolean

いいえ

trueの場合、作成するドメインがすでに存在すると、ビルドが失敗して例外がスローされます。falseの場合、作成するドメインがすでに存在しても、ビルドは成功し、既存のドメインは上書きされません。ドメインが存在しない場合、このパラメータによる影響はありません。デフォルト値: false

middlewareHome

java.lang.String

true

Oracle Middlewareインストール・ディレクトリへのパス。

password

java.lang.String

true

管理パスワードを指定します。

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

user

java.lang.String

true

管理ユーザー名を指定します。

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

wlstVersion

java.lang.String

いいえ

非推奨。バージョン12.2.1以降、WLSTの単一の統合されたバージョンがあります。このパラメータは非推奨であり、無視されます。

workingDir

java.lang.String

いいえ

create-domainゴールを実行する現在の作業ディレクトリ。デフォルト値: ${project.build.directory}/weblogic-maven-plugin

使用例

create-domainゴールを使用して、指定されたWebLogic ServerインストールからWebLogic Serverドメインを作成します。domainHome構成パラメータを使用して、ドメインの場所を指定します。

ドメインを作成する場合は、ユーザー名とパスワードが必要です。それらは、POMファイルでuserおよびpassword構成パラメータを使用して指定するか、コマンドラインで指定できます。

ドメイン名は、domainHomeで指定された最後のサブディレクトリから取得されます。

<execution>
<id>wls-create-domain</id>
<phase>pre-integration-test</phase>
<goals>
<goal>create-domain</goal>
</goals>
<configuration>
<middlewareHome>c:/dev/wls12210</middlewareHome>
<domainHome>${project.build.directory}/base_domain</domainHome>
<user>weblogic</user>
<password>password</password>
</configuration>
</execution>

例3-4では、create-domainゴールの実行からの一般的なコマンド出力を示します。

例3-4 create-domain

mvn com.oracle.weblogic:weblogic-maven-plugin:create-domain
-DdomainHome=c:\oracle\middleware\oracle_home\user_projects\domains\maven-domain
-DmiddlewareHome=c:\oracle\middleware\oracle_home -Duser=weblogic -Dpassword=password
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1-0-0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:create-domain (default-cli) @
weblogic-maven-plugin ---
[INFO] [create-domain]Domain creation script:
readTemplate(r'C:/oracle/middleware/oracle_home/wlserver/common/templates/wls/wls.jar')
set('Name', 'maven-domain')
cd('/Security/maven-domain/User/weblogic')
set('Name', 'weblogoc')
set('Password', '***')
writeDomain(r'c:/oracle/middleware/oracle_home/user_
projects/domains/maven-domain')
[INFO] [wlst]script temp file = C:/Users/user/AppData/Local/Temp/test6066166061714573929.py
[INFO] [wlst]Executing: [cmd:[C://windows\\system32\\cmd.exe, /c,
C:\oracle\middleware\oracle_home\wlserver\common\bin\wlst.cmd
C:\Users\user\AppData\Local\Temp\test6066166061714573929.py ]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec]
[INFO] [exec] Initializing WebLogic Scripting Tool (WLST) ...
[INFO] [exec]
[INFO] [exec] Welcome to WebLogic Server Administration Scripting Shell
[INFO] [exec]
[INFO] [exec] Type help() for help on available commands
[INFO] [exec]
[INFO] [wlst][cmd:[C:\\windows\\system32\\cmd.exe, /c, C:\oracle\middleware\oracle_home\wlserver\common\bin\wlst.cmd
C:\Users\user\AppData\Local\Temp\test6066166061714573929.py ]] exit code=0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 18.276s
[INFO] Finished at: Wed Aug 19 13:13:25 EDT 2015
[INFO] Final Memory: 9M/23M
[INFO] ------------------------------------------------------------------------

deploy

完全名

com.oracle.weblogic:weblogic-maven-plugin:deploy

説明

実行中のサーバーにWebLogic Serverアプリケーションおよびモジュールをデプロイします。WAR、JAR、RARなどのすべてのデプロイメント・フォーマットをサポートします。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-6 deployのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

altappdd

java.lang.String

いいえ

代替ディスクリプタを指定します。.earデプロイメント用に代替application.xml、またはスタンドアロン・モジュール・デプロイメント用に代替web.xmlか代替ejb.xmlを指定するために使用することができます。

appversion

java.lang.String

いいえ

起動するアプリケーションのバージョン。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

enableSecurityValidation

boolean

いいえ

trueの場合、セキュリティ・データの検証を有効にします。デフォルト値: false

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

external_stage

boolean

いいえ

trueの場合、ユーザーが、サーバーのステージング領域のアプリケーションを外部から、またはサード・パーティ・ツールを使用してコピーすることを示します。指定した場合、WebLogic Serverは、StagingDirectoryName(of target server)/ applicationNameの下でアプリケーションを探します。デフォルト値: false

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

libimplver

java.lang.String

いいえ

Java EEライブラリまたはオプション・パッケージの実装のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに実装のバージョンが含まれていない場合にのみ使用できます。

library

boolean

いいえ

共有Java EEライブラリまたはオプション・パッケージとしてデプロイします。

libspecver

java.lang.String

いいえ

Java EEライブラリまたはオプション・パッケージの仕様のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに仕様バージョンが含まれていない場合にのみ使用できます。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

nostage

boolean

いいえ

trueの場合、デプロイメント・ファイルをターゲット・サーバーにコピーせず、sourceパラメータで指定された特定の場所に保持します。デフォルトでは、管理サーバーの場合はnostageがtrue、管理対象サーバー・ターゲットの場合はstageがtrueになります。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。デフォルト値: false

partition

java.lang.String

いいえ

アプリケーションまたはライブラリをデプロイするリソース・グループに関連付けられているパーティションの名前を指定します。

deploy操作およびdistribute操作には、resourceGroup属性を設定してアプリケーションまたはライブラリをデプロイまたは配布するパーティション・リソース・グループの名前を指定する必要があります。指定したパーティションに存在するリソース・グループが1つのみの場合、resourceGroup属性は省略可能です。partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

plan

java.lang.String

いいえ

デプロイメント・プランのパスを指定します。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。デフォルト値: false

resourceGroup

java.lang.String

いいえ

アプリケーションまたはライブラリをデプロイするパーティションまたはドメイン・レベルのリソース・グループの名前を指定します。

deploy操作およびdistribute操作には、resourceGroup属性を設定してアプリケーションまたはライブラリをデプロイまたは配布するリソース・グループの名前を指定する必要があります。パーティションの場合、指定したパーティションに存在するリソース・グループが1つのみの場合、resourceGroup属性は省略可能です。

サポートされているその他のデプロイメント処理の場合、WebLogicサーバーは一意のアプリケーション名からリソース・グループを導出するため、resourceGroup属性は指定しません。

resourceGroupTemplate

java.lang.String

いいえ

アプリケーションまたはライブラリをデプロイするリソース・グループ・テンプレートに名前を指定します。

retiretimeout

java.lang.Integer

いいえ

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。指定しない場合、正常なリタイア・ポリシーと見なされます。デフォルト値: -1

securityModel

java.lang.String

いいえ

このデプロイメントで使用するセキュリティ・モデルを指定し、それをセキュリティ・レルムのデフォルトのセキュリティ・モデルよりも優先的に使用します。可能な値: DDOnly、CustomRoles、CustomRolesAndPoliciesおよびAdvanced

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

source

java.lang.String

いいえ

デプロイするアーティファクトのアドレスを指定します。アドレスには次のいずれかを指定できます。

- コロン(:)で区切られたMavenのリストが形式を調整します: groupId:artifactId:packaging:classifier:version。

- ローカル・システムのアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリ。たとえば、/home/myhome/myapps/helloworld.war。

- リモートHTTP URL (http://foo/a/b.ear)。

stage

boolean

いいえ

trueの場合、デプロイメントの前に、アプリケーションをターゲット・サーバー・ステージング領域にコピーする必要があることを示します。デフォルトでは、管理サーバーの場合はnostageがtrue、管理対象サーバー・ターゲットの場合はstageがtrueになります。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

現在の処理のターゲットのカンマ区切りリストを指定します。デフォルト値はAdminServerです。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

upload

boolean

いいえ

trueの場合、デプロイメント前に、ソース・ファイルを管理サーバーのアップロード・ディレクトリにコピーします。この設定は、プラグインをリモートで(remoteパラメータを使用して)実行する場合、およびユーザーに管理サーバーのファイル・システムに対する通常アクセス権が付与されていない場合に使用します。デフォルト値: false

usenonexclusivelock

boolean

いいえ

trueのときは、同じユーザーがドメインですでに取得している既存のロックを、デプロイメント処理で使用することを指定します。複数のデプロイメント・ツールを同時に使用していて、いずれかのツールでドメイン構成のロックをすでに取得している場合に便利。

デフォルト値: false

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、追加のステータス情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

使用例

このゴールを使用してアプリケーションをデプロイします。

<execution>
<id>wls-deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<source>${project.build.directory}/${project.build.finalName}
.${project.packaging}</source>
<targets>AdminServer</targets>
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>

例3-5では、典型的なdeployゴールの出力を示します。

例3-5 deploy

mvn com.oracle.weblogic:weblogic-maven-plugin:deploy
-Dsource=C:\webservices\MySimpleEjb.jar
-Dpassword=password -Duser=weblogic
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1-0-0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:deploy (default-cli) @ weblogic-mave
n-plugin ---
weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -
deploy -user weblogic -source C:\webservices\MySimpleEjb.jar -targets AdminServe
r
<Aug 19, 2015> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiati
ng deploy operation for application, MySimpleEjb [archive: C:\webservices\MySimp
leEjb.jar], to AdminServer .>
Task 0 initiated: [Deployer:149026]deploy application MySimpleEjb on AdminServer
.
Task 0 completed: [Deployer:149026]deploy application MySimpleEjb on AdminServer
.
Target state: deploy completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.042s
[INFO] Finished at: Wed Aug 19 13:41:11 EDT 2015
[INFO] Final Memory: 10M/25M

distribute-app

完全名

com.oracle.weblogic:weblogic-maven-plugin:distribute-app

説明

デプロイメント・ファイルをターゲット・サーバーにコピーして検証することで、デプロイメント用に準備します。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-7 distribute-appのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

enableSecurityValidation

boolean

いいえ

trueの場合、セキュリティ・データの検証を有効にします。デフォルト値: false

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

external_stage

boolean

いいえ

trueの場合、ユーザーが、サーバーのステージング領域のアプリケーションを外部から、またはサード・パーティ・ツールを使用してコピーすることを示します。指定した場合、WebLogic Serverは、StagingDirectoryName(of target server)/ applicationNameの下でアプリケーションを探します。デフォルト値: false

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

nostage

boolean

いいえ

trueの場合、デプロイメント・ファイルをターゲット・サーバーにコピーせず、sourceパラメータで指定された特定の場所に保持します。デフォルトでは、管理サーバーの場合はnostageがtrue、管理対象サーバー・ターゲットの場合はstageがtrueになります。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。デフォルト値: false

partition

java.lang.String

いいえ

アプリケーションまたはライブラリを配布するリソース・グループに関連付けられているパーティションの名前を指定します。

deploy操作およびdistribute操作には、resourceGroup属性を設定してアプリケーションまたはライブラリをデプロイまたは配布するパーティション・リソース・グループの名前を指定する必要があります。指定したパーティションに存在するリソース・グループが1つのみの場合、resourceGroup属性は省略可能です。partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

plan

java.lang.String

いいえ

デプロイメント・プランのパスを指定します。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。デフォルト値: false

resourceGroup

java.lang.String

いいえ

アプリケーションまたはライブラリを配布するパーティションまたはドメイン・レベルのリソース・グループの名前を指定します。

deploy操作およびdistribute操作には、resourceGroup属性を設定してアプリケーションまたはライブラリをデプロイまたは配布するリソース・グループの名前を指定する必要があります。パーティションの場合、指定したパーティションに存在するリソース・グループが1つのみの場合、resourceGroup属性は省略可能です。

サポートされているその他のデプロイメント処理の場合、WebLogicサーバーは一意のアプリケーション名からリソース・グループを導出するため、resourceGroup属性は指定しません。

resourceGroupTemplate

java.lang.String

いいえ

アプリケーションまたはライブラリを配布するリソース・グループ・テンプレートに名前を指定します。

retiretimeout

java.lang.Integer

いいえ

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。指定しない場合、正常なリタイア・ポリシーと見なされます。デフォルト値: -1

securityModel

java.lang.String

いいえ

このデプロイメントで使用するセキュリティ・モデルを指定し、それをセキュリティ・レルムのデフォルトのセキュリティ・モデルよりも優先的に使用します。可能な値: DDOnly、CustomRoles、CustomRolesAndPoliciesおよびAdvanced

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

source

java.lang.String

いいえ

配布するアーティファクトのアドレスを指定します。アドレスには次のいずれかを指定できます。

- コロン(:)で区切られたMavenのリストが形式を調整します: groupId:artifactId:packaging:classifier:version。

- ローカル・システムのアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリ。たとえば、/home/myhome/myapps/helloworld.war。

- リモートHTTP URL (http://foo/a/b.ear)。

stage

boolean

いいえ

trueの場合、デプロイメントの前に、アプリケーションをターゲット・サーバー・ステージング領域にコピーする必要があることを示します。デフォルトでは、管理サーバーの場合はnostageがtrue、管理対象サーバー・ターゲットの場合はstageがtrueになります。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

現在の処理のターゲットのカンマ区切りリストを指定します。指定しない場合、構成されているすべてのターゲットが使用されます。新しいアプリケーションの場合、デフォルトのターゲットは管理サーバーです。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

upload

boolean

いいえ

trueの場合、デプロイメント前に、ソース・ファイルを管理サーバーのアップロード・ディレクトリにコピーします。この設定は、プラグインをリモートで(remoteパラメータを使用して)実行する場合、およびユーザーに管理サーバーのファイル・システムに対する通常アクセス権が付与されていない場合に使用します。デフォルト値: false

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、追加のステータス情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

このゴールを使用して、デプロイメント・ファイルをデプロイする準備をします。

<execution>
<id>wls-distribute-app</id>
<phase>pre-integration-test</phase>
<goals>
<goal>distribute-app</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<source>${project.build.directory}/${project.build.finalName}
.${project.packaging}</source>
<targets>cluster1</targets>
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>

例3-6では、典型的なdistribute-appゴールの出力を示します。

例3-6 distribute-app

$ mvn com.oracle.weblogic:weblogic-maven-plugin:distribute-app
-Dadminurl=t3://localhost:7001 -Dstage=true -DmiddlewareHome=/maven/wls12210
-Dname=cluster-test -Duser=weblogic -Dpassword=welcome1 -Dtargets=cluster1
-Dsource=target/cluster-test-1.0-SNAPSHOT.war
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building cluster-test 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:distribute-app (default-cli) @
cluster-test ---
weblogic.Deployer invoked with options: -noexit -adminurl t3://localhost:7001
-distribute -user weblogic -name cluster-test -source
/home/oracle/src/tests/uber-test/cluster-test/
target/cluster-test-1.0-SNAPSHOT.war -targets cluster1 -stage
<Aug 19, 2015> <Info> <J2EE Deployment SPI> <BEA-260121>
<Initiating distribute operation for application, cluster-test [archive:
/home/oracle/src/tests/uber-test/cluster-test/
target/cluster-test-1.0-SNAPSHOT.war], to cluster1 .>
Task 0 initiated: [Deployer:149026]distribute application cluster-test on
cluster1.
Task 0 completed: [Deployer:149026]distribute application cluster-test on
cluster1.
Target state: distribute completed on Cluster cluster1

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.953s
[INFO] Finished at: Wed Aug 19 14:10:00 EST 2015
[INFO] Final Memory: 15M/429M
[INFO] ------------------------------------------------------------------------

install

完全名

com.oracle.weblogic:weblogic-maven-plugin:install

説明

JARファイルからWebLogic Serverをインストールします。

パラメータ

表3-8 installのパラメータ

名前

タイプ

必須

説明

artifactLocation

java.lang.String

true

インストールのアドレスを指定します。アドレスには次のいずれかを指定できます。

- コロン(:)で区切られたMavenのリストが形式を調整します: groupId:artifactId:packaging:classifier:version。

- ローカル・システムのファイル(/home/myhome/myapps/wls_generic.jar)。

- リモートHTTP URL (http://myarchive/installers/wls_generic.jar)。

installCommand

java.lang.String

いいえ

バイナリまたはJARインストーラで製品をインストールします(クイックスタート・インストーラを含む)。次のマクロがサポートされています。

- @INSTALLER_FILE@ - インストーラ・ファイルへのパス。

- @INSTALL_TO_LOCATION@ - ターゲット・ディレクトリ(クイックスタート・インストーラにのみ適しています)。

- @JAVA_HOME@ - Javaホームへのパス。

- @JAVA_TMPDIR@ - Java一時ディレクトリへのパス。

- @RESPONSE_FILE@ - OUIサイレント・インストーラのレスポンス・ファイルへのパス。

- @INV_PTR_LOC_FILE@ - OUI invPtrLocファイルへのパス。

JARインストーラの例:

@JAVA_HOME@/bin/java -Xms512m -Xmx1024m -Djava.io.tmpdir=@JAVA_TMPDIR@ -jar @INSTALLER_FILE@ -silent -responseFile @RESPONSE_FILE@ -invPtrLoc @INV_PTR_LOC_FILE@

クイックスタートJARインストーラの例:

@JAVA_HOME@/bin/java -Xms512m -Xmx1024m -Djava.io.tmpdir=@JAVA_TMPDIR@ -jar @INSTALLER_FILE@ ORACLE_HOME=@INSTALL_TO_LOCATION@

このパラメータは省略可能です。

supplementalQuickStartLocationパラメータが指定されているときにクイックスタート・インストーラに指定された場合、@INSTALLER_FILE@マクロをsupplementalQuickStartLocationパラメータから導出されたファイル・ロケーションで置き換えることで、同じコマンドが予備のクイックスタート・インストーラで使用されます。

@INSTALLER_FILE@マクロが使用されていない場合、インストール・ゴールは引数に続いてinstallCommand文字列の'-jar'引数を予備のクイックスタート・インストーラJARファイル名で置き換えます。

installDir

java.lang.String

true

非推奨。かわりにmiddlewareHomeパラメータを使用してください。

invPtrLoc

java.lang.String

いいえ

サイレント・インストーラのインベントリの場所のファイル。これは、バイナリまたはJARインストーラを使用する場合に、UNIXベースのプラットフォームで必要です。

middlewareHome

java.lang.String

いいえ

クイックスタート・インストーラを使用するときにインストールするORACLE_HOMEディレクトリ。

quickStartInstaller

boolean

いいえ

これがクイックスタート・インストーラであることを示します。クイックスタート・インストーラでは、artifactLocationパラメータおよびinstallDirパラメータを指定する必要があります。このパラメータがtrueに設定されると、その他すべてのパラメータは無視されます。デフォルト値はfalseです。

response

java.lang.String

いいえ

非推奨。かわりにresponseFileパラメータを使用してください。

responseFile

java.lang.String

いいえ

サイレント・インストーラのレスポンス・ファイル。これは、バイナリまたはJARインストーラを使用する場合に必要です。

supplementalQuickStartLocation

java.lang.String

いいえ

クイックスタートの予備インストーラ。

使用例

このゴールを使用して、WebLogic Serverをローカル・ディレクトリにインストールし、それを使用して、他のゴールを実行したり、Mavenプロジェクトとして表されるアプリケーションのデプロイおよびテストのためのWebLogic Serverドメインを作成できます。

注意:

installゴールは、myserverと呼ばれる単一の管理対象サーバーを作成し、ドメインを作成しません。create-domainを含む他のほとんどのゴールは、AdminServerというデフォルトのサーバー名を使用します。したがって、POMでこのAdminServerというデフォルトのサーバー名をオーバーライドする必要があります。

このゴールは、指定されたインストールの配布を使用してWebLogic Serverをインストールします。artifactLocation構成パラメータを使用して配布場所を指定します。このパラメータは、ファイル・システム上のファイル、アクセス可能なHTTP URL、またはMavenリポジトリにインストールされた配布のMavenコーディネートとして配布場所を指定できます。pom.xmlファイルのweblogic-maven-pluginセクションで、またはMavenの起動時に-DartifactLocationプロパティを使用して、artifactLocation構成要素を指定します。

例3-7では、JARファイルを使用してWindowsベースのシステムにWebLogic Serverをインストールする例を示します。

例3-7 JARファイルからのインストール

mvn com.oracle.weblogic:weblogic-maven-plugin:install
-DartifactLocation=c:\wls-temp\wls_jrf_generic.jar
-DinstallDir=C:\test-maven -DresponseFile=c:\wls-temp\response.txt
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:install (default-cli) @ standalone-p
om ---
[INFO] [install]ORACLE_HOME = C:\test-maven\Oracle\Middleware\Oracle_Home
[INFO] Executing:  [cmd:[C:\\Windows\\System32\\cmd.exe, /c, C:\weblogic\dev\AUT
O_D~1\x86_64\JDK180~3\JDK18~1.0_4\jre\bin\java.exe -Xms1024m -Xmx1024m -Djava.io
.tmpdir=C:\Users\user\AppData\Local\Temp\ -jar c:\wls-temp\wls_jrf_g
eneric.jar -silent -responseFile c:\wls-temp\response.txt ]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] Launcher log file is C:\Users\user\AppData\Local\Temp\OraInsta
ll2015-04-23_09-45-13AM\launcher2015-04-23_09-45-13AM.log.
[INFO] [exec] Extracting files..................................................
................................................................................
...................................
[INFO] [exec] Starting Oracle Universal Installer
[INFO] [exec]
[INFO] [exec] Checking if CPU speed is above 300 MHz.   Actual 2491    Passed
[INFO] [exec] Checking swap space: must be greater than 512 MB    Passed
[INFO] [exec] Checking if this platform requires a 64-bit JVM.   Actual 64 Pa
ssed (64-bit not required)
[INFO] [exec]
[INFO] [exec]
[INFO] [exec] Preparing to launch the Oracle Universal Installer from C:\Users\
user\AppData\Local\Temp\OraInstall2015-04-23_09-45-13AM
[INFO] [exec] Log: C:\Users\user\AppData\Local\Temp\OraInstall2015-04-23_09-
45-13AM\install2015-04-23_09-45-13AM.log
[INFO] [exec] Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights
reserved.
[INFO] [exec] Reading response file..
[INFO] [exec] -nocheckForUpdates / SKIP_SOFTWARE_UPDATES flag is passed and henc
e skipping software update
[INFO] [exec] Skipping Software Updates...
[INFO] [exec] Starting check : CertifiedVersions
[INFO] [exec] Expected result: One of 6.1,6.2,6.3
[INFO] [exec] Actual Result: 6.1
[INFO] [exec] Check complete. The overall result of this check is: Passed
[INFO] [exec] CertifiedVersions Check: Success.
[INFO] [exec] Starting check : CheckJDKVersion
[INFO] [exec] Expected result: 1.8.0_40
[INFO] [exec] Actual Result: 1.8.0_40-ea
[INFO] [exec] Check complete. The overall result of this check is: Passed
[INFO] [exec] CheckJDKVersion Check: Success.
[INFO] [exec] Validations are enabled for this session.
[INFO] [exec] Verifying data......
[INFO] [exec] Copying Files...
[INFO] [exec] -----------20%----------40%----------60%----------80%-----Visit ht
tp://www.oracle.com/support/policies.html for Oracle Technical Support policies.

[INFO] [exec] ---100%
[INFO] [exec]
[INFO] [exec] The installation of Oracle Fusion Middleware 12c Infrastructure 12
.2.1.0.0 completed successfully.
[INFO] [exec] Logs successfully copied to C:\weblogic\src
\inventory\logs.
[INFO] Installer exited with code: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

例3-8では、JARファイルとinstallCommandパラメータを使用してWindowsベースのシステムにWebLogic Serverをインストールする例を示します。

例3-8 installCommandを使用したJARファイルからのインストール

mvn com.oracle.weblogic:weblogic-maven-plugin:install
-DinstallCommand="@JAVA_HOME@/bin/java -Xms512m -Xmx1024m
-jar  @INSTALLER_FILE@ -silent -responseFile c:\wls-temp\response.txt"
-DartifactLocation=c:\wls-temp\wls_jrf_generic.jar
-DresponseFile=c:\wls-temp\response.txt
INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:install (default-cli) @ standalone-p
om ---
[INFO] [install]ORACLE_HOME = C:\test-maven\Oracle\Middleware\Oracle_Home
[INFO] Executing:  [cmd:[C:\\Windows\\System32\\cmd.exe, /c, C:\weblogic\dev\AUT
O_D~1\x86_64\JDK180~3\JDK18~1.0_4\jre/bin/java -Xms512m -Xmx1024m -jar  c:\wls-t
emp\wls_jrf_generic.jar -silent -responseFile c:\wls-temp\response.txt]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] Launcher log file is C:\Users\user\AppData\Local\Temp\OraInsta
ll2015-04-23_10-58-13AM\launcher2015-04-23_10-58-13AM.log.
[INFO] [exec] Extracting files..................................................
................................................................................
.................
[INFO] [exec] Starting Oracle Universal Installer
[INFO] [exec]
[INFO] [exec] Checking if CPU speed is above 300 MHz.   Actual 2491    Passed
[INFO] [exec] Checking swap space: must be greater than 512 MB    Passed
[INFO] [exec] Checking if this platform requires a 64-bit JVM.   Actual 64    Pa
ssed (64-bit not required)
[INFO] [exec]
[INFO] [exec]
[INFO] [exec] Preparing to launch the Oracle Universal Installer from C:\Users\
user\AppData\Local\Temp\OraInstall2015-04-23_10-58-13AM
[INFO] [exec] Log: C:\Users\user\AppData\Local\Temp\OraInstall2015-04-23_10-
58-13AM\install2015-04-23_10-58-13AM.log
[INFO] [exec] Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights
reserved.
[INFO] [exec] Reading response file..
[INFO] [exec] -nocheckForUpdates / SKIP_SOFTWARE_UPDATES flag is passed and henc
e skipping software update
[INFO] [exec] Skipping Software Updates...
[INFO] [exec] Starting check : CertifiedVersions
[INFO] [exec] Expected result: One of 6.1,6.2,6.3
[INFO] [exec] Actual Result: 6.1
[INFO] [exec] Check complete. The overall result of this check is: Passed
[INFO] [exec] CertifiedVersions Check: Success.
[INFO] [exec] Starting check : CheckJDKVersion
[INFO] [exec] Expected result: 1.8.0_40
[INFO] [exec] Actual Result: 1.8.0_40-ea
[INFO] [exec] Check complete. The overall result of this check is: Passed
[INFO] [exec] CheckJDKVersion Check: Success.
[INFO] [exec] Validations are enabled for this session.
[INFO] [exec] Verifying data......
[INFO] [exec] Copying Files...
[INFO] [exec] -----------20%----------40%----------60%----------80%-----Visit ht
tp://www.oracle.com/support/policies.html for Oracle Technical Support policies.

[INFO] [exec] ---100%
[INFO] [exec]
[INFO] [exec] The installation of Oracle Fusion Middleware 12c Infrastructure 12
.2.1.0.0 completed successfully.
[INFO] [exec] Logs are located here: C:\Users\user\AppData\Local\Temp\OraIns
tall2015-04-23_10-58-13AM.
[INFO] Installer exited with code: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

list-apps

完全名

com.oracle.weblogic:weblogic-maven-plugin:list-apps

説明

ドメインにデプロイ、配布、またはインストールされているアプリケーションおよびスタンドアロン・モジュールのデプロイメント名をリストします。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-9 list-appsのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。

password

java.lang.String

いいえ

管理パスワードを指定します。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、追加のステータス情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

list-appsゴールを使用して、デプロイメント名をリストします。

<execution>
<id>wls-list-apps</id>
<phase>pre-integration-test</phase>
<goals>
<goal>list-apps</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
</configuration>
</execution>

例3-9では、典型的なlist-appsゴールの出力を示します。

例3-9 list-apps

mvn com.oracle.weblogic:weblogic-maven-plugin:list-apps
-Duser=weblogic -Dpassword=password
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:list-apps (default-cli) @ weblogic-m
aven-plugin ---
weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -
listapps -user weblogic
SamplesSearchWebApp
stockBackEnd
ajaxJSF
asyncServlet30
singletonBean
webFragment
examplesWebApp
mainWebApp
annotation
MySimpleEjb
stockFrontEnd
jsfBeanValidation
programmaticSecurity
entityBeanValidation
faceletsJSF
bookmarkingJSF
stockAdapter
noInterfaceViewInWAR
jdbcDataSource.war
asyncMethodOfEJB
calendarStyledTimer
cdi
jaxrs
criteriaQuery
portableGlobalJNDIName
multipartFileHandling
elementCollection
Number of Applications Found : 27
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.656s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 11M/28M
[INFO] ------------------------------------------------------------------------
C:\Oracle\Middleware\Oracle_Home\wlserver\server\lib>

purge-tasks

完全名

com.oracle.weblogic:weblogic-maven-plugin:purge-tasks

説明

リタイアしたデプロイメント・タスクをフラッシュします。

パラメータ

表3-10 purge-tasksのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

debug

boolean

いいえ

trueの場合、デバッグ情報をクラス・ファイルにコンパイルします。デフォルト値: false

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

password

java.lang.String

いいえ

管理パスワードを指定します。

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、デプロイメント処理中のステータスに関する追加情報を表示します。デフォルト値: false

purge-tasksゴールを使用して、リタイアしたデプロイメント・タスクをフラッシュします。

<execution>
<id>wls-purge</id>
<phase>pre-integration-test</phase>
<goals>
<goal>purge-tasks</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
</configuration>
</execution>

例3-11では、典型的なpurge-tasksゴールの出力を示します。

例3-10 purge-tasks

mvn  com.oracle.weblogic:weblogic-maven-plugin:purge-task
s -Duser=weblogic -Dpassword=password
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:purge-tasks (default-cli) @ standalo
ne-pom ---
weblogic.Deployer invoked with options:  -noexit -purgetasks -user weblogic -adm
inurl t3://localhost:7001
Currently there are no retired tasks.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.139s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 8M/24M
[INFO] ------------------------------------------------------------------------

redeploy

完全名

com.oracle.weblogic:weblogic-maven-plugin:redeploy

説明

実行中のアプリケーションまたは実行中のアプリケーションの一部を再デプロイします。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-11 redeployのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

appversion

java.lang.String

いいえ

起動するアプリケーションのバージョン。

deleteFiles

java.lang.String

いいえ

このパラメータで指定されているファイルを削除し、アプリケーションをアクティブのままにします。このパラメータは、アーカイブ解除されたデプロイメントにのみ有効です。

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

libimplver

java.lang.String

いいえ

Java EEライブラリまたはオプション・パッケージの実装のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに実装のバージョンが含まれていない場合にのみ使用できます。

library

boolean

いいえ

共有Java EEライブラリまたはオプション・パッケージとしてデプロイします。

libspecver

java.lang.String

いいえ

Java EEライブラリまたはオプション・パッケージの仕様のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに仕様バージョンが含まれていない場合にのみ使用できます。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

partition

java.lang.String

いいえ

アプリケーションまたはライブラリを再デプロイするリソース・グループに関連付けられているパーティションの名前を指定します。

partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

plan

java.lang.String

いいえ

デプロイメント・プランのパスを指定します。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。

removePlanOverride

boolean

いいえ

redeployまたはupdateデプロイメント処理中にオーバーライドされたデプロイメント・プランを削除します。

リソース・グループにデプロイされたアプリケーションまたはライブラリでは、リソース・グループが参照するリソース・グループ・テンプレートで定義されたアプリケーション構成をオーバーライドできます。アプリケーション・オーバーライドを削除するには、removePlanOverride属性を指定します。

resourceGroupTemplate

java.lang.String

いいえ

アプリケーションまたはライブラリを再デプロイするリソース・グループ・テンプレートに名前を指定します。

retiretimeout

java.lang.Integer

いいえ

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。指定しない場合、正常なリタイア・ポリシーと見なされます。デフォルト値: -1

rmiGracePeriod

java.lang.Integer

いいえ

正常な停止中のRMIリクエストに対する猶予期間の秒数を指定します。gracefulパラメータがtrueの場合のみ使用できます。デフォルト値の-1は、猶予期間がないことを意味します。デフォルト値: -1

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

source

java.lang.String

いいえ

再デプロイするアーティファクトのアドレスを指定します。アドレスには次のいずれかを指定できます。

- コロン(:)で区切られたMavenのリストが形式を調整します: groupId:artifactId:packaging:classifier:version。

- ローカル・システムのアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリ。たとえば、/home/myhome/myapps/helloworld.war。

- リモートHTTP URL (http://foo/a/b.ear)。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

現在の処理のターゲットのカンマ区切りリストを指定します。デフォルト・ターゲットはAdminServerです。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

upload

boolean

いいえ

trueの場合、再デプロイメント前に、指定されたソース・ファイルを管理サーバーのuploadディレクトリにコピーします。この設定は、プラグインをリモートで(remoteパラメータを使用して)実行する場合、およびユーザーに管理サーバーのファイル・システムに対する通常アクセス権が付与されていない場合に使用します。デフォルト値: false

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、デプロイメント処理中のステータスに関する追加情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

redeployゴールを使用して、アプリケーションまたはそのアプリケーションの一部を再デプロイします。

<execution>
<id>wls-redeploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>redeploy</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</sour
ce>
<name>${project.build.finalName}</name>
</configuration>
</execution>

例3-11では、典型的なredeployゴールの出力を示します。

例3-11 redeploy

mvn com.oracle.weblogic:weblogic-maven-plugin:redeploy -Dsou
rce=C:\Oracle\Middleware\Oracle_Home\wlserver\server\lib\MySimpleEjb.jar  -Duser
=weblogic -Dpassword=password -Dname=ExampleEJB
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:redeploy (default-cli) @ weblogic-ma
ven-plugin ---
weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -
redeploy -user weblogic -name ExampleEJB -source C:\Oracle\Middleware\Oracle_Hom
e\wlserver\server\lib\MySimpleEjb.jar -targets AdminServer
<Aug 19, 2015> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat
ing redeploy operation for application, ExampleEJB [archive: C:\Oracle\Middlewar
e\Oracle_Home\wlserver\server\lib\MySimpleEjb.jar], to AdminServer .>
Task 3 initiated: [Deployer:149026]deploy application ExampleEJB on AdminServer.

Task 3 completed: [Deployer:149026]deploy application ExampleEJB on AdminServer.

Target state: redeploy completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.322s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015

remove-domain

完全名

com.oracle.weblogic:weblogic-maven-plugin:remove-domain

説明

ドメイン・ディレクトリを削除します。このゴールが成功するには、ドメインが実行中でない必要があります。これは単純なユースケースの便利なゴールです。ドメインがすでに削除されている場合、STDOUTにはステータス・メッセージが表示されますが、ゴールは失敗しません。

パラメータ

表3-12 remove-domainのパラメータ

名前

タイプ

必須

説明

domainHome

java.lang.String

true

ドメイン・ディレクトリへのパス。

workingDir

java.lang.String

いいえ

現在の作業ディレクトリを指定します。

デフォルト値: ${project.build.directory}/weblogic-maven-plugin)

remove-domainゴールを使用して、ドメイン・ディレクトリを削除します。

<execution>
<id>wls-remove-domain</id>
<phase>pre-integration-test</phase>
<goals>
<goal>remove-domain</goal>
</goals>
<configuration>
<domainHome>${project.build.directory}/base_domain</domainHome>
</configuration>
</execution>

例3-13では、典型的なremove-domainゴールの出力を示します。

例3-12 remove-domain

mvn com.oracle.weblogic:weblogic-maven-plugin:remove-domain
-DdomainHome=C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain
:
[INFO] [remove-domain]Executing: [cmd:[C:\\Windows\\System32\\cmd.exe, /c, rmdir
/Q /S C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain]]
[INFO] Process being executed, waiting for completion.
[INFO] [remove-domain][cmd:[C:\\Windows\\System32\\cmd.exe, /c, rmdir /Q /S C:\O
racle\Middleware\Oracle_Home\user_projects\domains\base_domain]] exit code=0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4:01.074s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 8M/20M
[INFO] ------------------------------------------------------------------------

start-app

完全名

com.oracle.weblogic:weblogic-maven-plugin:start-app

説明

WebLogic Server上にデプロイされたアプリケーションを起動します。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-13 start-appのパラメータ

名前

タイプ

必須

説明

adminmode

boolean

いいえ

trueの場合、アプリケーションを管理モードに切り替えて、構成済の管理チャネル経由で管理リクエストのみを受け付けます。falseの場合、本番モードと見なされます。デフォルト値: false

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

appversion

java.lang.String

いいえ

アプリケーションのバージョン識別子を指定します。指定しない場合、アプリケーションの現在アクティブになっているバージョンと見なされます。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

domainHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。

partition

java.lang.String

いいえ

アプリケーションまたはライブラリを起動するリソース・グループに関連付けられているパーティションの名前を指定します。

partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

planversion

java.lang.String

いいえ

デプロイメント・プランのバージョンを指定します。指定しない場合、アプリケーションのデプロイメント・プランの現在アクティブになっているバージョンと見なされます。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。デフォルト値: false

retiretimeout

java.lang.Integer

いいえ

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。指定しない場合、正常なリタイア・ポリシーと見なされます。デフォルト値: -1

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

現在の処理のターゲットのカンマ区切りリストを指定します。指定しない場合、構成されているすべてのターゲットが使用されます。新しいアプリケーションの場合、デフォルトのターゲットはアプリケーションがデプロイされるすべてのターゲットです。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、デプロイメント処理中のステータスに関する追加情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

start-appゴールを使用して、アプリケーションを起動します。

<execution>
<id>wls-start-app</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start-app</goal>
</goals>
<configuration>
<adminurl>t3://localhost:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<name>${project.build.finalName}</name>
</configuration>
</execution>

例3-13では、典型的なstart-appゴールの出力を示します。

例3-13 start-app

mvn com.oracle.weblogic:weblogic-maven-plugin:start-app
-Duser=weblogic -Dpassword=password -Dname=ExampleEJB
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:start-app (default-cli) @ weblogic-m
aven-plugin ---
weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -
start -user weblogic -name ExampleEJB -retiretimeout -1
<Aug 19, 2015> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat
ing start operation for application, ExampleEJB [archive: null], to configured t
argets.>
Task 5 initiated: [Deployer:149026]start application ExampleEJB on AdminServer.
Task 5 completed: [Deployer:149026]start application ExampleEJB on AdminServer.
Target state: start completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.053s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 10M/26M
[INFO] ------------------------------------------------------------------------

start-server

完全名

com.oracle.weblogic:weblogic-maven-plugin:start-server

説明

現在の作業ディレクトリのスクリプトからWebLogic Serverを起動します。これは単純なユースケースの便利なゴールです。サーバーがすでに起動されている場合、STDOUTにはステータス・メッセージが表示されますが、ゴールは失敗しません。

パラメータ

表3-14 start-serverのパラメータ

名前

タイプ

必須

説明

command

java.lang.String[]

いいえ

WebLogic Serverを起動するためのスクリプトを指定します。このパラメータが指定されていない場合、デフォルトでは、プラットフォームに基づいてstartWebLogic.shまたはstartWebLogic.cmdが使用されます。

domainHome

java.lang.String

いいえ

WebLogic Serverドメインのパスを指定します。デフォルト値: ${basedir}/Oracle/Domains/mydomain

httpPingUrl

java.lang.String

いいえ

pingの実行時にサーバーが実行中であるかどうかを検証するURLを指定します。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

timeoutSecs

java.lang.Integer

いいえ

スクリプトのタイムアウトを秒単位で指定します。waitForExitパラメータがtrueの場合に有効です。ゼロ(0)または負の値はスクリプトがタイムアウトしないことを示します。デフォルト値: -1

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

使用例

start-serverゴールは、指定されたドメインでstartWebLogicコマンドを実行し、WebLogic Serverインスタンスを起動します。

<execution>
<id>wls-wlst-start-server</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start-server</goal>
</goals>
<configuration>
<domainHome>${project.build.directory}/base_domain</domainHome>
</configuration>
</execution>

例3-14では、典型的なstart-serverゴールの出力を示します。

例3-14 start-server

mvn com.oracle.weblogic:weblogic-maven-plugin:start-server
-DdomainHome=c:\oracle\middleware\oracle_home\user_projects\domains\wl_server
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1-0-0
[INFO] ------------------------------------------------------------------------[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:start-server (default-cli)
@ weblogic-maven-plugin ---
.[INFO] Starting server in domain:
c:\oracle\middleware\oracle_home\user_projects\domains\wl_server
[INFO] Check stdout file for details:
c:\oracle\middleware\oracle_home\user_projects\domains\wl_server\server-2183114106972126386.out
[INFO] Process being executed, waiting for completion.
.............
[INFO] Server started successful
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 37.725s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 8M/23M

stop-app

完全名

com.oracle.weblogic:weblogic-maven-plugin:stop-app

説明

アプリケーションを停止します。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-15 stop-appのパラメータ

名前

タイプ

必須

説明

adminmode

boolean

いいえ

trueの場合、アプリケーションを管理モードに切り替えて、構成済の管理チャネル経由で管理リクエストのみを受け付けます。falseの場合、本番モードと見なされます。デフォルト値: false

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

appversion

java.lang.String

いいえ

アプリケーションのバージョン識別子を指定します。指定しない場合、アプリケーションの現在アクティブになっているバージョンと見なされます。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

domainHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

graceful

boolean

いいえ

trueの場合、既存のHTTPクライアントが作業を完了した後でアプリケーションを停止します。指定しない場合、強制停止と見なされます。

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

ignoresessions

boolean

いいえ

trueの場合、正常な停止時に、保留中のHTTPセッションを無視します。gracefulパラメータがtrueの場合のみ使用できます。デフォルト値: false

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。

partition

java.lang.String

いいえ

アプリケーションまたはライブラリを停止するリソース・グループに関連付けられているパーティションの名前を指定します。

partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

planversion

java.lang.String

いいえ

デプロイメント・プランのバージョンを指定します。指定しない場合、アプリケーションのデプロイメント・プランの現在アクティブになっているバージョンと見なされます。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。デフォルト値: false

rmiGracePeriod

java.lang.Integer

いいえ

正常な停止中のRMIリクエストに対する猶予期間の秒数を指定します。gracefulパラメータがtrueの場合のみ使用できます。デフォルト値の-1は、猶予期間がないことを意味します。デフォルト値: -1

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

現在の処理のターゲットのカンマ区切りリストを指定します。指定しない場合、構成されているすべてのターゲットが使用されます。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、追加のステータス情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

stop-appを使用して、アプリケーションを停止します。

<execution>
<id>wls-start-app</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start-app</goal>
</goals>
<configuration>
<adminurl>t3://localhost:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<name>${project.build.finalName}</name>
</configuration>
</execution>

例3-15では、典型的なstop-appゴールの出力を示します。

例3-15 stop-app

mvn com.oracle.weblogic:weblogic-maven-plugin:stop-app  -Dus
er=weblogic -Dpassword=password -Dname=ExampleEJB
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:stop-app (default-cli)
@ weblogic-ma
ven-plugin ---
weblogic.Deployer invoked with options:  -noexit
-adminurl t3://localhost:7001 -
stop -user weblogic -name ExampleEJB
<Aug 19, 2015> <Info>
<J2EE Deployment SPI> <BEA-260121> <Initiat
ing stop operation for application, ExampleEJB [archive: null],
to configured ta
rgets.>
Task 6 initiated: [Deployer:149026]stop application ExampleEJB on
AdminServer.
Task 6 completed: [Deployer:149026]stop application ExampleEJB on
AdminServer.
Target state: stop completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.028s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 10M/29M
[INFO] ------------------------------------------------------------------------
C:\Oracle\Middleware\Oracle_Home\wlserver\server\lib>

stop-server

完全名

com.oracle.weblogic:weblogic-maven-plugin:stop-server

説明

現在の作業ディレクトリのスクリプトからWebLogic Serverを停止します。これは単純なユースケースの便利なゴールです。サーバーがすでに停止されている場合、STDOUTにはステータス・メッセージが表示されますが、ゴールは失敗しません。

パラメータ

表3-16 stop-serverのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

command

java.lang.String[]

いいえ

WebLogic Serverを停止するためのスクリプトを指定します。プラットフォームに基づいてデフォルトのstopWebLogic.shまたはstopWebLogic.cmdになります。

domainHome

java.lang.String

いいえ

WebLogic Serverドメインのパスを指定します。デフォルト値: ${basedir}/Oracle/Domains/mydomain

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

outputLog

java.lang.String

いいえ

スクリプト出力のリダイレクト先のログ・ファイルを指定します。指定しない場合、デフォルトでstdoutが使用されます。

password

java.lang.String

true

管理パスワードを指定します。

timeoutSecs

java.lang.Integer

いいえ

スクリプトのタイムアウトを秒単位で指定します。waitForExitパラメータがtrueの場合に有効です。ゼロ(0)または負の値はスクリプトがタイムアウトしないことを示します。デフォルト値: -1

user

java.lang.String

true

管理ユーザー名を指定します。

waitForExit

boolean

いいえ

trueの場合、プラグインはスクリプトが完了するまで待機する必要があります。デフォルト値: true

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

workingDir

java.lang.String

いいえ

スクリプトの作業ディレクトリを指定します。この属性を指定しない場合、デフォルトの現在の作業ディレクトリになります。デフォルト値: ${project.base.directory}

使用例

stop-serverゴールは、指定したドメインでstopWebLogicスクリプトを使用してサーバー・インスタンスを停止します。

<execution>
<id>wls-wlst-stop-server</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop-server</goal>
</goals>
<configuration>
<domainHome>${project.build.directory}/base_domain</domainHome>
<user>weblogic</user>
<password>password</password>
<adminurl>t3://localhost:7001</adminurl>
</configuration>
</execution>

例3-16では、典型的なstop-serverゴールの出力を示します。

例3-16 stop-server

mvn com.oracle.weblogic:weblogic-maven-plugin:stop-server
-DdomainHome=c:\oracle\middleware\oracle_home\userprojects\domains\wl_server
-DworkingDir=c:\oracle\middleware\oracle_home\user_projects\domains\wl_server
-Duser=weblogic -Dpassword=password
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1-0-0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:stop-server (default-cli)
@ weblogic
-maven-plugin ---
[INFO] Stop server in domain:
c:\oracle\middleware\oracle_home\user_projects\dom
ains\wl_server
[INFO] Process being executed, waiting for completion.
[INFO] [exec] Stopping Weblogic Server...
[INFO] [exec]
[INFO] [exec] Initializing WebLogic Scripting Tool (WLST) ...
[INFO] [exec]
[INFO] [exec] Welcome to WebLogic Server Administration Scripting Shell
[INFO] [exec]
[INFO] [exec] Type help() for help on available commands
[INFO] [exec]
[INFO] [exec] Connecting to t3://localhost:7001 with userid weblogic ...
[INFO] [exec] Successfully connected to Admin Server "AdminServer" that belongs
to domain "wl_server".
[INFO] [exec]
[INFO] [exec] Warning: An insecure protocol was used to connect to the
[INFO] [exec] server. To ensure on-the-wire security, the SSL port or
[INFO] [exec] Admin port should be used instead.
[INFO] [exec]
[INFO] [exec] Shutting down the server AdminServer with force=false while connec
ted to AdminServer ...
[INFO] [exec] WLST lost connection to the WebLogic Server that you were
[INFO] [exec] connected to, this may happen if the server was shutdown or
[INFO] [exec] partitioned. You will have to re-connect to the server once the
[INFO] [exec] server is available.
[INFO] [exec] Disconnected from weblogic server: AdminServer
[INFO] [exec] Disconnected from weblogic server:
[INFO] [exec]
[INFO] [exec]
[INFO] [exec] Exiting WebLogic Scripting Tool.
[INFO] [exec]
[INFO] [exec] Done
[INFO] [exec] Stopping Derby Server...
[INFO] [exec] Derby server stopped.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23.270s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 9M/23M
[INFO] ------------------------------------------------------------------------

undeploy

完全名

com.oracle.weblogic:weblogic-maven-plugin:undeploy

説明

WebLogic Serverからアプリケーションをアンデプロイします。デプロイメント・ユニットを停止して、ステージングされているファイルをターゲット・サーバーから削除します。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-17 undeployのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

appversion

java.lang.String

いいえ

アプリケーションのバージョン識別子を指定します。指定しない場合、アプリケーションの現在アクティブになっているバージョンと見なされます。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

graceful

boolean

いいえ

trueの場合、既存のHTTPクライアントが作業を完了した後でアプリケーションを停止します。指定しない場合、強制停止と見なされます。

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

ignoresessions

boolean

いいえ

trueの場合、正常な停止時に、保留中のHTTPセッションを無視します。gracefulパラメータがtrueの場合のみ使用できます。デフォルト値: false

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。

partition

java.lang.String

いいえ

アプリケーションまたはライブラリを更新するリソース・グループに関連付けられているパーティションの名前を指定します。

partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

planversion

java.lang.String

いいえ

デプロイメント・プランのバージョンを指定します。指定しない場合、アプリケーションのデプロイメント・プランの現在アクティブになっているバージョンと見なされます。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。デフォルト値: false

resourceGroupTemplate

java.lang.String

いいえ

アプリケーションまたはライブラリをアンデプロイするリソース・グループ・テンプレートに名前を指定します。

rmiGracePeriod

java.lang.Integer

いいえ

正常な停止中のRMIリクエストに対する猶予期間の秒数を指定します。gracefulパラメータがtrueの場合のみ使用できます。デフォルト値の-1は、猶予期間がないことを意味します。デフォルト値: -1

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

現在の処理のターゲットのカンマ区切りリストを指定します。指定しない場合、構成されているすべてのターゲットが使用されます。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、デプロイメント処理中のステータスに関する追加情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

undeployゴールを使用して、WebLogic Serverからアプリケーションを再デプロイします。

<execution>
<id>wls-undeploy</id>
<phase>post-integration-test</phase>
<goals>
<goal>undeploy</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<name>${project.build.finalName}</name>
</configuration>
</execution>

例3-17では、典型的なundeployゴールの出力を示します。

例3-17 undeploy

mvn com.oracle.weblogic:weblogic-maven-plugin:undeploy
-Duser=weblogic -Dpassword=password -Dname=ExampleEJB
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebLogic Server Maven Plugin 12.2.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:undeploy (default-cli)
@ weblogic-ma
ven-plugin ---
weblogic.Deployer invoked with options:  -noexit
-adminurl t3://localhost:7001 -
undeploy -user weblogic -name ExampleEJB -targets AdminServer
<Aug 19, 2015> <Info> <J2EE Deployment SPI>
<BEA-260121> <Initiat
ing undeploy operation for application, ExampleEJB [archive: null],
to AdminServ
er .>
Task 7 initiated: [Deployer:149026]remove application ExampleEJB
on AdminServer.

Task 7 completed: [Deployer:149026]remove application ExampleEJB
on AdminServer.

Target state: undeploy completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.114s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 9M/26M
[INFO] ------------------------------------------------------------------------

uninstall

完全名

com.oracle.weblogic:weblogic-maven-plugin:uninstall

説明

WebLogic Serverをアンインストールします。

パラメータ

表3-18 uninstallのパラメータ

名前

タイプ

必須

説明

invPtrLoc

java.io.File

true

このパラメータは非推奨であり、無視されます。

middlewareHome

java.lang.String

true

Oracle Middlewareインストール・ディレクトリ。このパラメータは、クイックスタート・インストーラを使用してインストールされたサーバーをアンインストールする場合に必要です。それ以外の場合は無視され、responseFileの場所が使用されます。

response

java.io.File

true

非推奨。responseFileパラメータを使用します。

responseFile

java.io.File

true

サイレント・インストーラのレスポンス・ファイル。これは、バイナリまたはJARインストーラを使用する場合に必要です。

例3-18では、JARファイル・インストールでのWebLogic Serverをアンインストールする例を示しています。

例3-18 JARインストールでのアンインストール

mvn com.oracle.weblogic:weblogic-maven-plugin:uninstall -DresponseFile=c:\wls-temp\response.txt
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:uninstall (default-cli) @ standalone
-pom ---
[INFO] [uninstall]ORACLE_HOME = C:\test-maven\Oracle\Middleware\Oracle_Home
[INFO] [uninstall]ORACLE_HOME = C:\test-maven\Oracle\Middleware\Oracle_Home
[INFO] Executing:  [cmd:[C:\\Windows\\System32\\cmd.exe, /c, C:\test-maven\Oracl
e\Middleware\Oracle_Home\oui\bin\deinstall.cmd -noconsole -deinstall -silent -re
sponseFile c:\wls-temp\response.txt]]
[INFO] Process being executed, waiting for completion.
[INFO] Installer exited with code: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

update-app

完全名

com.oracle.weblogic:weblogic-maven-plugin:update-app

説明

プラン・ファイルを再配布して、新しいプランのコンテキストに基づいてアプリケーションを再構成することで、アプリケーションのデプロイメント・プランを更新します。ローカル・サーバー・インストールを必要としません。

パラメータ

表3-19 update-appのパラメータ

名前

タイプ

必須

説明

adminurl

java.lang.String

いいえ

管理サーバーのリスニング・アドレスとリスニング・ポートを指定します。デフォルト値: t3://localhost:7001

advanced

boolean

いいえ

trueの場合、高度な使用オプションを出力します。

appversion

java.lang.String

いいえ

アプリケーションのバージョン識別子を指定します。指定しない場合、アプリケーションの現在アクティブになっているバージョンと見なされます。

debug

boolean

いいえ

trueの場合、デバッグレベル・メッセージを標準出力に表示します。デフォルト値: false

domainHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

examples

boolean

いいえ

trueの場合、このプラグインの使用方法の例を表示します。

failOnError

boolean

いいえ

trueの場合、エラーが発生すると、そのエラーが記録される前に、Mojoによって強制的にビルドが失敗します。デフォルト値: true

id

java.lang.String

いいえ

ユーザーが指定する一意のデプロイメント・タスク識別子(オプション)を指定します。

middlewareHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

name

java.lang.String

いいえ

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。

noversion

boolean

いいえ

trueの場合、管理サーバー上のバージョン関連のすべてのコード・パスを無視します。デフォルト値: false

nowait

boolean

いいえ

trueの場合、複数のタスクを開始し、その後は-listアクションを使用してモニターします。

partition

java.lang.String

いいえ

アプリケーションまたはライブラリを更新するリソース・グループに関連付けられているパーティションの名前を指定します。

partitionパラメータはパーティション管理者にとっては省略可能です。

password

java.lang.String

いいえ

管理パスワードを指定します。

plan

java.lang.String

いいえ

デプロイメント・プランの場所を指定します。

planversion

java.lang.String

いいえ

デプロイメント・プランのバージョンを指定します。指定しない場合、アプリケーションのデプロイメント・プランの現在アクティブになっているバージョンと見なされます。

remote

boolean

いいえ

trueの場合、管理サーバーと同じマシンでプラグインが実行されていないことを指定します。この場合、sourceパラメータは、uploadパラメータが同時に使用されていない限り、サーバー上のパスを指定します。デフォルト値: false

removePlanOverride

boolean

いいえ

redeployまたはupdateデプロイメント処理中にオーバーライドされたデプロイメント・プランを削除します。

リソース・グループにデプロイされたアプリケーションまたはライブラリでは、リソース・グループが参照するリソース・グループ・テンプレートで定義されたアプリケーション構成をオーバーライドできます。アプリケーション・オーバーライドを削除するには、removePlanOverride属性を指定します。

rmiGracePeriod

java.lang.Integer

いいえ

正常な停止中のRMIリクエストに対する猶予期間の秒数を指定します。gracefulパラメータがtrueの場合のみ使用できます。デフォルト値の-1は、猶予期間がないことを意味します。デフォルト値: -1

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

submoduletargets

java.lang.String

いいえ

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。可能な値の形式: submod@mod-jms.xml@targetまたはsubmoduleName@target

targets

java.lang.String

いいえ

アプリケーションまたはモジュールを更新するターゲット。この属性では、カンマ区切りリストを使用できます。ターゲットが指定されていない場合は、すべてのターゲットが更新されます。

timeout

java.lang.Integer

いいえ

デプロイメント・タスクの完了までのWebLogic Serverの最長待機秒数を指定します。デフォルト値の-1は、永久に待機することを意味します。デフォルト値: -1

upload

boolean

いいえ

trueの場合、デプロイメント前に、ソース・ファイルを管理サーバーのアップロード・ディレクトリにコピーします。この設定は、プラグインをリモートで(remoteパラメータを使用して)実行する場合、およびユーザーに管理サーバーのファイル・システムに対する通常アクセス権が付与されていない場合に使用します。デフォルト値: false

user

java.lang.String

いいえ

管理ユーザー名を指定します。

userConfigFile

java.lang.String

いいえ

プレーン・テキストでユーザー名とパスワードを直接指定するかわりに、管理ユーザー名とパスワードを取得するために使用するユーザー構成ファイルの場所を指定します。

userKeyFile

java.lang.String

いいえ

ユーザー構成ファイルに格納されたユーザー名とパスワードを暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

verbose

boolean

いいえ

trueの場合、追加のステータス情報を表示します。デフォルト値: false

version

boolean

いいえ

trueの場合、バージョン情報を出力します。デフォルト値: false

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

update-appゴールを使用して、アプリケーションのデプロイメント・プランを更新します。

<execution>
<id>wls-update-app</id>
<phase>pre-integration-test</phase>
<goals>
<goal>update-app</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>password</password>
<name>${project.build.finalName}</name>
<plan>${basedir}/misc/myplan.xml</plan>
</configuration>
</execution>

例3-19では、典型的なwlstゴールの出力を示します。

例3-19 update-app

$ mvn com.oracle.weblogic:weblogic-maven-plugin:update-app -Duser=weblogic
-Dpassword=password -Dadminurl=t3://localhost:7001 -Dplan=misc/myplan.xml
-Dname=basicWebapp
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building basicWebapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:update-app (default-cli)
@ main-test ---
weblogic.Deployer invoked with options: -noexit -adminurl
t3://localhost:7001 -update -user weblogic -plan
/home/oracle/src/tests/main-test/misc/myplan.xml -name basicWebapp -targets AdminServer
<Aug 19, 2015> <Info> <J2EE Deployment SPI> <BEA-260121>
<Initiating update operation for application, basicWebapp [archive: null],
to AdminServer .>
Task 10 initiated: [Deployer:149026]update application basicWebapp on
AdminServer.
Task 10 completed: [Deployer:149026]update application basicWebapp on
AdminServer.
Target state: update completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.651s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 18M/435M
[INFO] ------------------------------------------------------------------------

wlst

完全名

com.oracle.weblogic:weblogic-maven-plugin:wlst

説明

このゴールは、WLSTスクリプティング・ツールのラッパーです。WLSTオンライン・コマンドを実行するためにはサーバーのインストールが必要です。

パラメータ

表3-20 wlstのパラメータ

名前

タイプ

必須

説明

args

java.lang.String

いいえ

非推奨。scriptArgsパラメータを使用して、scriptArg要素のリストとして引数を指定します。

WLST Pythonインタプリタに渡されるコマンドライン引数を含む文字列値を指定します。引数は空白で区切ります。空白を含む引数は、一重引用符またはエスケープされた二重引用符で囲む必要があります。たとえば、2つのパラメータを含む、次のような引数の文字列があります。

"'Thomas Paine' \"Now is the time that tries men's souls.\""

debug

boolean

いいえ

trueの場合、追加のステータス情報を表示します。

デフォルト値: false

executeScriptBeforeFile

boolean

いいえ

trueの場合、スクリプトとファイルが提供されているときに、そのスクリプトをファイルの前と後のどちらで実行するのかを指定します。ファイルまたはスクリプトのいずれかが必要であり、両方使用することもできます。filenameおよびscriptパラメータを参照してください。。

デフォルト値: true

failOnError

boolean

いいえ

trueの場合、wlstゴールが失敗したときに、Mavenのビルドが失敗します。デフォルト値はtrueであり、その結果、どのようなエラー状態でもビルドは失敗します。場合によっては、failOnErrorをfalseに設定すると、wlstゴールでエラーを無視できます。

デフォルト値: true

fileName

java.lang.String

いいえ

実行するWLST Pythonスクリプトのファイル・パスを指定します。fileNameとscriptのいずれかのパラメータを指定する必要があり、両方指定することもできます。

middlewareHome

java.lang.String

true

Oracle Middlewareインストール・ディレクトリへのパス。

propertiesFile

java.lang.String

いいえ

Javaプロパティ・ファイルのパスを指定します。プロパティ名が、WLST Pythonインタプリタの定義済変数になり、指定した値に初期化されます。たとえば、プロパティ・ファイルに"foobar: Very important stuff"という行が含まれている場合、変数foobarをPython文で"print('foobar has the value: ' + foobar)"という形式で使用できます。

script

java.lang.String

いいえ

インラインWLST Pythonスクリプト、たとえば "print('Hello, world!')"を指定します。

Pythonではネストされたコード・ブロックをインデントで区切るため、複数行からなるスクリプトをPOMで指定する場合は、pom.xml内でインデントを使用せずに行う必要があります(ただし、コード・ブロックの区切りとして必要な場合を除く)。

scriptArgs

java.lang.String

いいえ

文字列値のリストとしてWLST Jythonインタプリタに渡されるコマンドライン引数を指定します。引数に埋め込まれた空白が含まれている場合、呼出し側はscriptArg要素の値に、囲むための一重引用符かエスケープされた二重引用符を含める必要があります。scriptArgsが指定されている場合、argsパラメータ(非推奨)は無視されます。

serverClasspath

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

weblogicHome

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

wlstVersion

java.lang.String

いいえ

このパラメータはこのリリースでは非推奨となっており、無視されます。

workingDir

java.lang.String

いいえ

wlst-scriptおよびcreate-domainゴールを実行する現在の作業ディレクトリ。デフォルト値: ${project.build.directory}/weblogic-maven-plugin

使用例

wlstゴールによってWebLogic Scripting Tool (WLST)を使用して、WebLogic Serverドメインでリソースを構成したり他の操作を実行するスクリプトを実行できます。wlst Mavenゴールは、WebLogic Server WLST標準環境を使用して、それをすべての既存のWLSTスクリプトとともに使用できるようにします。

wlstゴールを使用して、fileName構成パラメータとともに指定した外部WLSTスクリプトを実行できます。または、script構成要素を使用してpom.xmlファイル内で一連のWLSTコマンドを指定できます。

<execution>
<id>wls-wlst-server</id>
<phase>post-integration-test</phase>
<goals>
<goal>wlst</goal>
</goals>
<configuration>
<middlewareHome>c:/dev/wls12210</middlewareHome>
<fileName>${project.basedir}/misc/configure_resources.py</fileName>
<args>t3://localhost:7001 weblogic password AdminServer</args>
<script>
print('This is a WLST inline script\n')
print('Next, we run a WLST script to create JMS resources on the server\n')
</script>
<executeScriptBeforeFile>true</executeScriptBeforeFile>
</configuration>
</execution>

例3-20では、典型的なwlstゴールの出力を示します。

例3-20 wlst

mvn com.oracle.weblogic:weblogic-maven-plugin:wlst
-DfileName=create-datasource.py

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:wlst (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++  weblogic-maven-plugin: wlst                                            ++
[INFO] ++====================================================================++

*** Creating DataSource ***

Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'mydomain'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

Location changed to edit tree. This is a writable tree with
DomainMBean as the root. To make changes you will need to start
an edit session via startEdit().

For more help, use help(edit)

Starting an edit session ...
Started edit session, please be sure to save and activate your
changes once you are done.
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released
once the activation is completed.
Activation completed
Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.
For more help, use help(serverRuntime)

**** DataSource Details ****

Name:            cp
Driver Name:     Oracle JDBC driver
DataSource:      oracle.jdbc.xa.client.OracleXADataSource
Properties:      {user=demo}
State:           Running

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

デフォルトでは、wlstゴールはpre-integration-testフェーズにバインドされています。ゴールに対するデフォルトのフェーズのバインドをオーバーライドするために、プラグインのゴールを特定のライフサイクル・フェーズに明示的にバインドすることができます。たとえば、次に示すように、post-integration-testフェーズにバインドします。pom.xmlファイルは、wlstゴールをpre-integration-testフェーズとpost-integration-testフェーズの両方にバインドします(デュアル・フェーズ・ターゲット)。例に示すように、デフォルトの設定をオーバーライドして、異なるフェーズで異なるスクリプトを実行し、ニーズに応じて変更を行うことができます。

pom.xmlファイルの例

<project>
....
<executions>
<execution>
<id>WLS_SETUP_RESOURCES</id>
<phase>pre-integration-test</phase>
<goals>
<goal>wlst</goal>
</goals>
<configuration>
<fileName>src/main/wlst/create-datasource.py</fileName>
</configuration>
</execution>

<execution>
<id>WLS_TEARDOWN_RESOURCES</id>
<phase>post-integration-test</phase>
<goals>
<goal>wlst</goal>
</goals>
<configuration>
<fileName>src/main/wlst/remove-datasource.py</fileName>
</configuration>
</execution>
</executions>
....
</project>

wlst-client

完全名

com.oracle.weblogic:weblogic-maven-plugin:wlst-client

説明

このゴールは、ローカル・サーバーのインストールを必要とせずにWLSTオンライン・コマンドを実行するためのWLSTラッパーです。ローカル・サーバーがインストールされていない場合、このゴールではWLSTオンライン・コマンドのみがサポートされます。

パラメータ

表3-21 wlst-clientのパラメータ

名前

タイプ

必須

説明

args

java.lang.String

いいえ

非推奨。scriptArgsパラメータを使用して、scriptArg要素のリストとして引数を指定します。

debug

boolean

いいえ

trueの場合、追加のステータス情報を表示します。

デフォルト値: false

executeScriptBeforeFile

boolean

いいえ

trueの場合、スクリプトとファイルが提供されているときに、そのスクリプトをファイルの前と後のどちらで実行するのかを指定します。ファイルまたはスクリプトのいずれかが必要であり、両方使用することもできます。filenameおよびscriptパラメータを参照してください。。

デフォルト値: true

failOnError

boolean

いいえ

trueの場合、wlstゴールが失敗したときに、Mavenのビルドが失敗します。デフォルト値はtrueであり、その結果、どのようなエラー状態でもビルドは失敗します。場合によっては、failOnErrorをfalseに設定すると、wlstゴールでエラーを無視できます。

デフォルト値: true

fileName

java.lang.String

いいえ

実行するWLST Pythonスクリプトのファイル・パスを指定します。fileNameとscriptのいずれかのパラメータを指定する必要があり、両方指定することもできます。

middlewareHome

java.lang.String

いいえ

Oracle Middlewareインストール・ディレクトリへのパス。

このパラメータは、すべてのWLSTオフライン・コマンドに必要です。WLSTスクリプトで、有効なミドルウェア・ホームを指定せずにオフライン・コマンドが使用されている場合、このwlst-clientゴールは失敗します。

propertiesFile

java.lang.String

いいえ

Javaプロパティ・ファイルのパスを指定します。プロパティ名が、WLST Pythonインタプリタの定義済変数になり、指定した値に初期化されます。たとえば、プロパティ・ファイルに"foobar: Very important stuff"という行が含まれている場合、変数foobarをPython文で"print('foobar has the value: ' + foobar)"という形式で使用できます。

script

java.lang.String

いいえ

インラインWLST Pythonスクリプト、たとえば "print('Hello, world!')"を指定します。

Pythonではネストされたコード・ブロックをインデントで区切るため、複数行からなるスクリプトをPOMで指定する場合は、pom.xml内でインデントを使用せずに行う必要があります(ただし、コード・ブロックの区切りとして必要な場合を除く)。

scriptArgs

java.lang.String

いいえ

文字列値のリストとしてWLST Jythonインタプリタに渡されるコマンドライン引数を指定します。引数に埋め込まれた空白が含まれている場合、呼出し側はscriptArg要素の値に、囲むための一重引用符かエスケープされた二重引用符を含める必要があります。scriptArgsが指定されている場合、argsパラメータ(非推奨)は無視されます。

Fusion Middleware依存関係を使用したスクリプトの実行

wlst-clientゴールを使用してFusion Middleware依存関係を含むWLSTスクリプトを実行する場合、それらのスクリプトで必要なライブラリを引き込むために、まずcom.oracle.fmwshare依存関係をインクルードする必要があります。

com.oracle.fmwshare依存関係は、すべてのFusion Middleware依存関係より前に記載する必要があります。

たとえば、SOAのWLSTスクリプトを実行する場合、com.oracle.fmwshareおよびSOAに次のような依存関係を追加します。

<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>soa-wlst-client</id>
<goals>
<goal>wlst-client</goal>
</goals>
<configuration>
<fileName>${project.basedir}/misc/doSoaStuff.py</fileName>
<scriptArgs>
<scriptArg>${adminUserName}</scriptArg>
<scriptArg>${adminPassword}</scriptArg>
<scriptArg>${adminUrl}</scriptArg>
</scriptArgs>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.oracle.fmwshare</groupId>
<artifactId>fmwshare-wlst-dependencies</artifactId>
<version>12.2.1-0-0</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.oracle.soa</groupId>
<artifactId>soa-wlst-dependencies</artifactId>
<version>12.2.1-0-0</version>
<type>pom</type>
</dependency>
</dependencies>
</plugin>

使用例

wlst-clientゴールによってWebLogic Scripting Tool (WLST)を使用して、WebLogic Serverドメインでリソースを構成したり他の操作を実行するスクリプトを実行できます。wlst-clientゴールでは、WLSTオンライン・コマンドの実行にローカル・サーバーのインストールを必要としません。

wlst-client Mavenゴールは、WebLogic Server WLST標準環境を使用して、それをすべての既存のWLSTスクリプトとともに使用できるようにします。

wlst-clientゴールを使用して、fileName構成パラメータとともに指定した外部WLSTスクリプトを実行するか、script構成要素を使用してpom.xmlファイル内で一連のWLSTコマンドを指定するか、あるいはその両方の方法を使用することができます。

例:

<execution>
<id>wls-wlst-server</id>
<phase>post-integration-test</phase>
<goals>
<goal>wlst-client</goal>
</goals>
<configuration>
<fileName>${project.basedir}/misc/configure_resources.py</fileName>
<args>t3://some-host:7001 weblogic password AdminServer</args>
<script>
print('This is a WLST inline script\n')
print('Next, we run a WLST script to create JMS resources on the server\n')
</script>
<executeScriptBeforeFile>true</executeScriptBeforeFile>
</configuration>
</execution>

例3-20では、典型的なwlst-clientゴールの出力を示します。

例3-21 wlst-client

mvn com.oracle.weblogic:weblogic-maven-plugin:wlst-client
-DfileName=create-datasource.py

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven-demo 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:wlst (default-cli) @ maven-demo ---
[INFO] ++====================================================================++
[INFO] ++  weblogic-maven-plugin: wlst                                            ++
[INFO] ++====================================================================++

*** Creating DataSource ***

Connecting to t3://some-host:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'mydomain'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

Location changed to edit tree. This is a writable tree with
DomainMBean as the root. To make changes you will need to start
an edit session via startEdit().

For more help, use help(edit)

Starting an edit session ...
Started edit session, please be sure to save and activate your
changes once you are done.
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released
once the activation is completed.
Activation completed
Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.
For more help, use help(serverRuntime)

**** DataSource Details ****

Name:            cp
Driver Name:     Oracle JDBC driver
DataSource:      oracle.jdbc.xa.client.OracleXADataSource
Properties:      {user=demo}
State:           Running

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

別の例として、次の簡単なWLSTスクリプトがあるとします。

try:
connect('weblogic','password','t3://10.151.69.120:7001')
listApplications()
print('TEST PASS')
except:
print('TEST FAIL')

このWLSTスクリプトではfileName構成パラメータを指定できます(例3-22を参照)。

例3-22 wlst-clientスクリプトの例

C:\Oracle\Middleware\Oracle_Home\oracle_common\plugins\maven\com\oracle\maven\or
acle-maven-sync\12.2.1>mvn com.oracle.weblogic:weblogic-maven-plugin:wlst-client
-DfileName=test.py
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:wlst-client (default-cli) @ standalo
ne-pom ---
[INFO] [wlst-client]No middlewareHome specified.
Connecting to t3://10.151.69.120:7001 with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "bas
e_domain".

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

jaxwsejb30ws
TEST PASS
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 29.197s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 18M/45M

デフォルトでは、wlstゴールはpre-integration-testフェーズにバインドされています。ゴールに対するデフォルトのフェーズのバインドをオーバーライドするために、プラグインのゴールを特定のライフサイクル・フェーズに明示的にバインドすることができます。たとえば、次に示すように、post-integration-testフェーズにバインドします。pom.xmlファイルは、wlstゴールをpre-integration-testフェーズとpost-integration-testフェーズの両方にバインドします(デュアル・フェーズ・ターゲット)。例に示すように、デフォルトの設定をオーバーライドして、異なるフェーズで異なるスクリプトを実行し、ニーズに応じて変更を行うことができます。

pom.xmlファイルの例

<project>
....
<executions>
<execution>
<id>WLS_SETUP_RESOURCES</id>
<phase>pre-integration-test</phase>
<goals>
<goal>wlst</goal>
</goals>
<configuration>
<fileName>src/main/wlst/create-datasource.py</fileName>
</configuration>
</execution>

<execution>
<id>WLS_TEARDOWN_RESOURCES</id>
<phase>post-integration-test</phase>
<goals>
<goal>wlst</goal>
</goals>
<configuration>
<fileName>src/main/wlst/remove-datasource.py</fileName>
</configuration>
</execution>
</executions>
....
</project>

exit()のトラップ

exit()は、WLSTをユーザー・セッションから終了させて、スクリプト・シェルを閉じます。デフォルトでは、WLSTを終了するときに、現在のWLST JVMのSystem.exit(0)が呼び出されます。wlst-clientは、Mavenビルド・プロセスと同じJVM内で実行されるため、Mavenビルド・プロセス全体が終了することになります。これに備えて、Maven実装ではWLST exit()のコールをトラップして、例外をスローします。

WLSTスクリプトからexit()を明示的にコールしないことをお薦めします。

たとえば、前述のWLSTスクリプトの例を変更し、次のようにexit()を追加したとします。

try:
connect('weblogic','password','t3://10.151.69.120:7001')
listApplications()
exit()
print('TEST PASS')
except:
print('TEST FAIL')

Maven実装がexit()をトラップすると、例外がスローされます。

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

jaxwsejb30ws

Exiting WebLogic Scripting Tool.

TEST FAIL
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 29.250s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 19M/45M
[INFO] ------------------------------------------------------------------------

ws-clientgen

非推奨

このゴールはこのリリースでは非推奨となっています。

完全名

com.oracle.weblogic:weblogic-maven-plugin:ws-clientgen

説明

パラメータ

表3-22に、ws-clientgenのパラメータについて簡単にまとめます。これらのパラメータは、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』の表2-3 「clientgen AntタスクのWebLogic固有の属性」で詳しく説明されています。

表3-22 ws-clientgenのパラメータ

名前

タイプ

必須

説明

binding

bindings

java.lang.String

いいえ

JAX-WSおよびJAXBカスタム・バインディング宣言またはSOAPハンドラ・ファイルを指定する1つ以上のカスタマイズ・ファイルを指定します。バインディング要素が1つしかない場合、<binding>./filename</binding>および<bindings><binding>./filename</binding></bindings>の両方が許可されます。

bindingsパラメータの説明は、表3-23を参照してください。

catalog

java.lang.String

いいえ

外部XMLカタログ・ファイルを指定して、外部エンティティの参照を解決します。

XMLカタログ・ファイルの作成の詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のXMLカタログの使用に関する項を参照してください。

copyWsdl

boolean

いいえ

WSDLをws-clientgenゴールの宛先ディレクトリ内のどこにコピーするかを制御します。

debug

boolean

いいえ

追加のデバッグ出力をオンにします。

debugLevel

boolean

いいえ

Antデバッグレベルを使用します。

destDir

java.io.File

true

ws-clientgenゴールがクライアント・ソース・コード、WSDLファイル、クライアント・デプロイメント記述子ファイルを生成するディレクトリを指定します。

destFileまたはdestDirのいずれかの属性を指定する必要があります(両方は指定できません)。

failOnError

boolean

いいえ

ws-clientgenゴールが、エラー発生時にも実行し続けるかどうかを指定します。デフォルト値はTrueです。

fork

boolean

いいえ

外部でJDKコンパイラを使用してjavacを実行するかどうかを指定します。デフォルト値はfalseです。

genRuntimeCatalog

boolean

いいえ

ws-clientgenゴールがクライアント実行時環境にXMLカタログ・アーティファクトを生成するかどうかを指定します。この値のデフォルトはtrueです。

includeAntRuntime

boolean

いいえ

Antランタイム・ライブラリをクラスパスに含めるかどうかを指定します。

includeJavaRuntime

boolean

いいえ

実行するVMのデフォルトのランタイム・ライブラリをクラスパスに含めるかどうかを指定します。

jmstransportclient

JMSTransportClient

いいえ

JMSトランスポートを使用したWebLogic Webサービスの呼出し

表3-25に、jmstransportclientパラメータのパラメータを示します。

packageName

java.lang.String

いいえ

生成されたクライアント・インタフェースとスタブ・ファイルをパッケージ化するパッケージ名を指定します。

produce

produces

FileSet

List<FileSet>

いいえ

FileSetが1つのみあります。

FileSetが複数あります。

verbose

boolean

いいえ

冗長出力をオンにします

wsdl

java.lang.String

true

クライアント・コンポーネント・ファイルの生成が必要な(WebLogicまたは非WebLogic) Webサービスを記述するWSDLの絶対パス名またはURLを指定します。

wsdlLocation

java.lang.String

いいえ

WebServiceまたはWebServiceProviderアノテーションで生成されるwsdlLocation属性の値を制御します。

xauthfile

java.lang.String

いいえ

認可ファイルを指定します。

xmlCatalog

java.lang.String

いいえ

未使用

表3-23に、bindingsパラメータのパラメータを示します。

表3-23 Bindingのパラメータ

名前

タイプ

必須

説明

file

java.lang.String

いいえ

JAX-WSおよびJAXBカスタム・バインディング宣言またはSOAPハンドラ・ファイルを含むカスタマイズ・ファイルを指定します。

表3-24に、xmlCatalogパラメータのパラメータを示します。

表3-24 xmlCatalogのパラメータ

名前

タイプ

必須

説明

refid

java.lang.String

いいえ

ws-jwscゴールが、コンパイルするJWSファイルを検索するディレクトリ(セミコロン区切り)を指定します。

表3-25に、jmstransportclientパラメータのパラメータを示します。

表3-25 jmstransportclientのパラメータ

名前

タイプ

必須

説明

destinationName

java.lang.String

いいえ

宛先キューまたはトピックのJNDI名。デフォルト値はcom.oracle.webservices.jms.RequestQueueです。

destinationType

java.lang.String

いいえ

有効な値は次のとおりです: QUEUEまたはTOPIC。デフォルト値はQUEUEです。

replyToName

java.lang.String

いいえ

レスポンス・メッセージを送信するJMS宛先のJNDI名。

targetService

java.lang.String

いいえ

Webサービスのポート・コンポーネント名。

jndiInitialContextFactory

java.lang.String

いいえ

JNDIルックアップに使用される初期コンテキスト・ファクトリ・クラスの名前。デフォルト値はweblogic.jndi.WLInitialContextFactoryです。

jndiConnectionFactoryName

java.lang.String

JMS接続を確立するために使用される接続ファクトリのJNDI名。デフォルト値はcom.oracle.webservices.jms.ConnectionFactoryです。

jndiUrl

java.lang.String

JNDIプロバイダのURL。デフォルト値はt3://localhost:7001です。

deliveryMode

java.lang.String

リクエスト・メッセージが永続であるかどうかを示す配信モード。有効な値は、PERSISTENTおよびNON_PERSISTENTです。デフォルト値はPERSISTENTです。

timeToLive

long

いいえ

リクエスト・メッセージの存続期間(ミリ秒単位)。デフォルト値は180000Lです。

priority

int

いいえ

リクエストおよびレスポンス・メッセージに関連付けられたJMSの優先度。デフォルト値は0です。

jndiContextParameter

java.lang.String

いいえ

次のようなフォーマットのJNDIのプロパティ: someParameterName1=someValue1 , someParameterName2=someValue2

bindingVersion

java.lang.String

いいえ

SOAP JMSバインディングのバージョン。デフォルト値は1.0です。

runAsPrincipal

java.lang.String

いいえ

リスニングMDBを実行するために使用されるプリンシパル。

runAsRole

java.lang.String

いいえ

リスニングMDBを実行するために使用されるロール。

messageType

java.lang.String

いいえ

リクエスト・メッセージで使用するメッセージの種類。有効な値は com.oracle.webservices.api.jms.JMSMessageType.BYTESおよびcom.oracle.webservices.api.jms.JMSMessageType.TEXTです。デフォルト値はBYTESです。

enableHttpWsdlAccess

boolean

いいえ

HTTPを介してWSDLをパブリッシュするかどうかを指定するブール・フラグ。デフォルト値はtrueです。

mdbPerDestination

boolean

いいえ

リクエストされた宛先ごとに1つのリスニング・メッセージドリブンBean (MDB)を作成するかどうかを指定するブール・フラグ。デフォルト値はtrueです。

activationConfig

java.lang.String

いいえ

JMSプロバイダに渡されたアクティブ化構成プロパティ。

contextPath

java.lang.String

いいえ

webサービスのデプロイされたコンテキスト。

serviceUri

java.lang.String

いいえ

URLのWebサービスURI部分。

portName

java.lang.String

いいえ

生成されたWSDLのポートの名前。

使用例

ws-clientgenゴールは、WSDLからクライアントWebサービス・アーティファクトを生成します。

このゴールは、構成より規則優先のアプローチのメリットを受けており、プロジェクトのデフォルトを使用して実行できます。

ws-clientgenゴールを実行するには、次の2つの方法があります。

- コマンド・ラインからたとえば、別名を定義した後に次のように指定します。

mvn –DvariableName1=value1  –DvariableName2=value2 com.oracle.weblogic:weblogic-maven-plugin:ws-clientgen

- Maven generate-resourcesライフサイクル・フェーズを指定することにより。この場合、pom.xmlの同じディレクトリでmvn generate-resourcesを実行します。
これを実行するには、pom.xmlファイルを変更して、generate-resourcesライフサイクル・フェーズ、ws-clientgenゴールを指定し、設定する必要があるパラメータを含めます。次のケースについて検討します。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven_plugin.simple</groupId>
<artifactId>maven_plugin_simple</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>clientgen</id>
<phase>generate-resources</phase>
<goals>
<goal>ws-clientgen</goal>
</goals>
<configuration>
<wsdl>${basedir}/AddNumbers.wsdl</wsdl>
<dest${project.build.outputDirectory}</destDir>
<packageName>maven_plugin.simple.client</packageName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

例3-23では、典型的なws-clientgenゴールの出力を示します。

例3-23 ws-clientgen

mvn -f C:\maven-doc\jwsc-test-2\clientgen_pom.xml generate-resources
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven_plugin_simple 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:ws-clientgen (clientgen) @ maven_plugin_sim
ple ---
[INFO] Executing standalone...

[INFO] Executing Maven goal 'clientgen'...
calling method public static void weblogic.wsee.tools.clientgen.MavenClientGen.e
xecute(org.apache.maven.plugin.logging.Log,java.util.Map) throws java.lang.Throw
able
[INFO] Consider using <depends>/<produces> so that wsimport won't do unnecessary
compilation
[WARNING] parsing WSDL...
[WARNING]
[WARNING]
[WARNING]
[WARNING] Generating code...
[WARNING]
[WARNING]
[WARNING] Compiling code...
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

wsgen

完全名

com.oracle.weblogic:weblogic-maven-plugin:wsgen

説明

JAX-WSサービスのエンドポイント実装クラスを読み取り、JAX-WS Webサービスで使用されるすべてのポータブル・アーティファクトを生成するMavenゴール。Javaクラスから起動する場合にwsgenゴールを使用します。

サービス・エンドポイント・インタフェースと実装クラス、値タイプおよび生成されたクラス(存在する場合)をWARファイルにパッケージ化し、そのWARをWebコンテナにデプロイできます。

wsgenゴールは、 JAX-WS Maven wsgenプラグインのゴールにラッパーを提供します。

パラメータ

表3-26に、wsgenの各パラメータを示します。

表3-26 wsgenのパラメータ

名前

タイプ

必須

説明

args

java.lang.String

いいえ

コマンドライン・オプション(省略可能)を指定します。複数の要素を指定でき、各トークンは各自のリストに指定されている必要があります。

destDir

java.io.File

いいえ

生成された出力クラスの格納場所のフルパス名を指定します。これを無効にするには、xnocompileを使用します。デフォルトは${project.build.outputDirectory})です。

encoding

java.lang.String

いいえ

デプロイメント記述子またはXMLファイルなどの出力ファイルの文字エンコーディングを指定します。文字エンコーディングの例としては、SHIFT-JISやUTF-8などがあります。デフォルト値はプラットフォームに依存します。

extension

boolean

いいえ

extensionは常にtrueに設定されるので、ユーザーが設定する必要はありません。拡張機能はOracle JAX-WSベンダー拡張に限定されません。

executable

java.lang.String

いいえ

実行可能ファイルの名前。通常はwsgen。

genWsdl

boolean

いいえ

WSDLファイルを${resourceDestDir}に生成すべきかどうかを指定します。デフォルトでは、WSDLは生成されません。

inlineSchemas

boolean

いいえ

生成されたWSDLにインライン・スキーマを生成します。デフォルトはfalseです。

genWsdlパラメータはtrueに設定する必要があります。

jmstransportservice

boolean

いいえ

WebサービスにJMSトランスポートを使用します。省略できます。jmstransportserviceパラメータの説明は、表3-34を参照してください。

keep

boolean

いいえ

生成されたファイルを保持するかどうかを指定します。デフォルトはtrueです。

metadata

java.io.File

いいえ

wsgenタスクのメタデータ・ファイル(『JAX-WS Release Documentation』の「External Web Service Metadata」を参照)。一致しないファイルは無視されます。

portName

java.lang.String

いいえ

生成されたWSDLで使用するポート名を指定します。genWsdlパラメータはtrueに設定する必要があります。

protocol

java.lang.String

いいえ

genWsdlと組み合せて使用し、wsdl:bindingで使用するプロトコルを指定します。genWsdlパラメータはtrueに設定する必要があります。

有効な値は、soap1.1およびXsoap1.2です。

デフォルトはsoapのsoap1.1です。Xsoap1.2は標準ではないため、extensionオプションと組み合せないと使用できません。

resourceDestDir

java.io.File

いいえ

生成されたWSDLファイルの格納先ディレクトリを指定します。デフォルトは${project.build.directory}/generated-sources/wsdlです。genWsdlパラメータはtrueに設定する必要があります。

sei

java.lang.String

いいえ

サービス・エンドポイント実装クラスの名前を指定します。

servicename

java.lang.String

いいえ

生成されたWSDLで使用するサービス名(wsdl:servicename)を指定します。genWsdlパラメータはtrueに設定する必要があります。

sourceDestDir

java.io.File

いいえ

生成されるソース・ファイルを格納する場所を指定します。このパラメータを使用すると、keepもtrueに設定されます。デフォルトは${project.build.directory}/generated-sources/wsgenです。

verbose

boolean

いいえ

ツールが実行している処理に関するメッセージを出力します。デフォルト値: false

vmArgs

java.util.List

いいえ

JVMオプション(省略可能)を指定します。複数の要素を指定でき、各トークンは各自のリストに指定されている必要があります。

xdonotoverwrite

boolean

いいえ

説明なし

xnocompile

boolean

いいえ

コード生成後のコンパイルを無効にし、生成されたソースがコンパイル・フェーズ中にMavenによってコンパイルされるようにします。デフォルトはfalseです。

このパラメータを使用すると、keepもtrueに設定されます。

使用例

wsgenゴールは、JAX-WSサービスのエンドポイント実装クラスを読み取り、JAX-WS Webサービスで使用されるすべてのポータブル・アーティファクトを生成します。

Mavenのprocess-classesライフサイクル・フェーズを指定します。その後で、POMファイルと同じディレクトリ内でmvn process-classesを実行します。

これを実行するには、pom.xmlファイルを変更して、process-classesライフサイクル・フェーズ、wsgenゴールを指定し、設定する必要があるパラメータを含めます。次のケースについて検討します。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven_plugin.simple</groupId>
<artifactId>maven_plugin_simple</artifactId>
<version>1.0</version>
<build>
<sourceDirectory>.</sourceDirectory>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>wsgen</id>
<phase>process-classes</phase>
<goals>
<goal>wsgen</goal>
</goals>
<configuration>
<destDir>${project.build.directory}/wsgenOutput/</destDir>
<sei>myexample.IPInfo</sei>
<verbose>true</verbose>
<genWsdl>true</genWsdl>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

例3-24では、典型的なwsgenゴールの出力を示します。

例3-24 wsgen

mvn -Dfile=pom.xml process-classes
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven_plugin_simple 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ maven_plug
in_simple ---
[debug] execute contextualize
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Oracle\Middleware\Oracle_Home\orac
le_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.1.3\src\main\resou
rces
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ maven_plugin_
simple ---
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. b
uild is platform dependent!
[INFO] Compiling 1 source file to C:\Oracle\Middleware\Oracle_Home\oracle_common
\plugins\maven\com\oracle\maven\oracle-maven-sync\12.1.3\target\classes
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:wsgen (wsgen) @ maven_plugin_simple
---
[INFO] Processing: myexample.IPInfo
[WARNING] Using platform encoding (Cp1252), build is platform dependent!
[INFO] jaxws:wsgen args: [-keep, -s, 'C:\Oracle\Middleware\Oracle_Home\oracle_co
mmon\plugins\maven\com\oracle\maven\oracle-maven-sync\12.2.1\target\generated-so
urces\wsgen', -d, 'C:\Oracle\Middleware\Oracle_Home\oracle_common\plugins\maven\
com\oracle\maven\oracle-maven-sync\12.2.1\target\wsgenOutput', -verbose, -extens
ion, -wsdl, -r, 'C:\Oracle\Middleware\Oracle_Home\oracle_common\plugins\maven\co
m\oracle\maven\oracle-maven-sync\12.2.1\target\generated-sources\wsdl', myexampl
e.IPInfo]
myexample\jaxws\GetIpAddress.java
myexample\jaxws\GetIpAddressResponse.java
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.309s
[INFO] Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 8M/32M
[INFO] ------------------------------------------------------------------------

この例では、wsgenゴールによって次のファイルが作成されます。

target
classes
META-INF
wsdl
IPInfoService.wsdl
IPInfoService_schema1.xsd
myexample
IPInfo.class
generated-sources
wsdl
IPInfoService.wsdl
IPInfoService_schema1.xsd
wsgen
myexample
jaxws
GetIpAddress.java
GetIpAddressResponse.java
wsgenoutput
myexample
jaxws
GetIpAddress.class
GetIpAddressResponse.class

wsimport

完全名

com.oracle.weblogic:weblogic-maven-plugin:wsimport

説明

WSDLファイルとバインディング・ファイルを解析し、そのアクセスに必要なJavaコードを生成するMavenゴール。WSDLから起動する場合にwsimportゴールを使用します。

wsimportゴールは、JAX-WS Maven wsimportゴールにラッパーを提供します。

パラメータ

表3-27に、wsimportの各パラメータを示します。

表3-27 wsimportのパラメータ

名前

タイプ

必須

説明

args

java.lang.String

いいえ

コマンドライン・オプション(省略可能)を指定します。複数の要素を指定でき、各トークンは各自のリストに指定されている必要があります。

bindingDirectory

java.io.File

いいえ

バインディング・ファイルが格納されているディレクトリ。

bindingFiles

java.util.List

いいえ

バインディングで使用するファイルのリスト。指定されていない場合、bindingDirectory内のすべての.xmlファイルが使用されます。

catalog

java.io.File

いいえ

外部エンティティ参照を解決するためのカタログ・ファイルで、TR9401、XCatalog、OASIS XML Catalogの各形式がサポートされています。

destDir

java.io.File

いいえ

生成された出力クラスの格納場所のフルパス名を指定します。これを無効にするには、xnocompileを使用します。デフォルトは${project.build.outputDirectory})です。

encoding

java.lang.String

いいえ

デプロイメント記述子またはXMLファイルなどの出力ファイルの文字エンコーディングを指定します。文字エンコーディングの例としては、SHIFT-JISやUTF-8などがあります。デフォルトはプラットフォームに依存します。

executable

java.lang.String

いいえ

実行可能ファイルの名前。通常はwsimport。

extension

boolean

いいえ

extensionは常にtrueに設定されるので、ユーザーが設定する必要はありません。拡張機能はOracle JAX-WSベンダー拡張に限定されません。

genJWS

boolean

いいえ

スタブ化されたJWS実装ファイルを生成します。デフォルトはfalseです。

httpproxy

java.lang.String

いいえ

HTTP/HTTPSプロキシを設定します。形式は[user[:password]@]proxyHost[:proxyPort]です。

implDestDir

java.io.File

いいえ

JWS実装ファイルの生成場所を指定します。

implPortName

java.lang.String

いいえ

生成されたJWS実装のポート名のローカル部分。genJWS=trueを意味します。注意: これはQNameのString表現(形式: "{" + Namespace URI + "}" + ローカル部分)です。

implServiceName

java.lang.String

いいえ

生成されたJWS実装のサービス名のローカル部分。genJWS=trueを意味します。注意: これはQNameのString表現(形式: "{" + Namespace URI + "}" + ローカル部分)です。

jmstransportclient

JMSTransportClient

いいえ

JMSトランスポートを使用したWebLogic Webサービスの呼出し

表3-25に、jmstransportclientパラメータのパラメータを示します。

jmsUri

jmsUri

いいえ

WSDLファイルで定義されているjmsUriをオーバーライドします。extension=trueが必須です。

keep

boolean

いいえ

生成されたファイルを保持するかどうかを指定します。デフォルトはtrueです。

packageName

java.lang.String

いいえ

ソース・ファイルの生成先のパッケージ。

quiet

boolean

いいえ

wsimport出力を抑制します。デフォルトはfalseです。

sourceDestDir

java.io.File

いいえ

生成されるソース・ファイルを格納する場所を指定します。このパラメータを使用すると、keepもtrueに設定されます。デフォルトは${project.build.directory}/generated-sources/wsimportです。

staleFile

java.io.File

いいえ

出力が無効かどうかの判断に使用するフラグ・ファイルが格納されているフォルダ。

フォルダを指定しない場合、デフォルトは${project.build.directory}/jaxws/staleです。

target

java.lang.String

いいえ

指定のJAXWS仕様バージョンに従ってコードを生成します。"2.0"を設定すると、JAX-WSはJAX-WS 2.0ランタイムで実行するアーティファクトを生成します。

verbose

boolean

いいえ

ツールが実行している処理に関するメッセージを出力します。デフォルト値: false

vmArgs

java.lang.String

いいえ

JVMオプション(省略可能)を指定します。複数の要素を指定でき、各トークンは各自のリストに指定されている必要があります。

wsdlDirectory

java.io.File

いいえ

WSDLファイルが格納されているディレクトリ。

wsdlFiles

java.util.List

いいえ

WSDLで使用するファイルのリスト。指定されていない場合、wsdlDirectory内のすべての.wsdlファイルが使用されます。

wsdlLocation

java.lang.String

いいえ

@WebService.wsdlLocationおよび@WebServiceClient.wsdlLocation値です。

指定したwsdlLocationにWSDLの相対パスが追加される場合は、アスタリスクで終わることができます。

例:

...
<configuration>
<wsdlDirectory>src/mywsdls</wsdlDirectory>
<wsdlFiles>
<wsdlFile>a.wsdl</wsdlFile>
<wsdlFile>b/b.wsdl</wsdlFile>
<wsdlFile>${basedir}/src/mywsdls/c.wsdl</wsdlFile>
</wsdlFiles>
<wsdlLocation>http://example.com/mywebservices/*</wsdlLocation>
</configuration>
...

a.wsdlのwsdlLocation: http://example.com/mywebservices/a.wsdl

b/b.wsdlのwsdlLocation: http://example.com/mywebservices/b/b.wsdl

${basedir}/src/mywsdls/c.wsdlのwsdlLocation: file://absolute/path/to/c.wsdl

注意: アスタリスク表記が使用されている場合、外部バインディング・ファイルは使用できません。

wsdlUrls

java.util.List

いいえ

コンパイルされる外部WSDLのURLのリスト。

xadditionalHeaders

boolean

いいえ

リクエストまたはレスポンス・メッセージにバインドされていないヘッダーをJavaメソッド・パラメータにマップします。

xauthFile

java.io.File

いいえ

認証ファイルの場所を指定します。

xdebug

boolean

いいえ

デバッグ・メッセージを有効にします。デフォルトはfalseです。

xdisableAuthenticator

boolean

いいえ

JAX-WS RIが使用するオーセンティケータを無効化します(これを設定すると、xauthfileは無視されます)。

xdisableSSLHostnameVerification

boolean

いいえ

WSDLのフェッチ中のSSLホスト名検証を無効化します。

xjcArgs

java.util.List

いいえ

WsImportコマンドの-Bオプションを使用してxjcに単に渡される、XJC固有のオプション・パラメータを指定します。

複数の要素を指定でき、各トークンは各自のリストに指定されている必要があります。

xnoAddressingDataBinding

boolean

いいえ

W3C EndpointReferenceTypeをJavaにバインドします。デフォルトでは、WsImportは仕様に従ってEndpointReferenceTypeをJavaにバインドせずに、仕様で提供されているW3CEndpointReferenceを使用します。

xnocompile

boolean

いいえ

コード生成後のコンパイルを無効にし、生成されたソースがコンパイル・フェーズ中にMavenによってコンパイルされるようにします。デフォルトはtrueです。

このパラメータを使用すると、keepもtrueに設定されます。

xuseBaseResourceAndURLToLoadWSDL

boolean

いいえ

JAX-WS Maven wsimportによる説明はありません。

使用例

wsimportゴールは、WSDLファイルとバインディング・ファイルを解析し、Webサービスのアクセスに必要なJavaコードを生成します。

wsimportゴールを使用するには、2つの方法があります。

- クライアント側アーティファクトを生成する方法。この場合は、Webサービスを呼び出すクライアントを実装します。

- Webサービスの実装を独自に作成する方法。wsimportゴールをgenJWSパラメータとともに使用して、ポータブル・アーティファクトとスタブ化された実装ファイルを生成します。その後で、サービス・エンドポイントを実装します。

Mavenのgenerate-sourcesライフサイクル・フェーズを指定します。その後で、POMファイルと同じディレクトリ内でmvn generate-sourcesを実行します。

たとえば、例3-25で示したWSDLをインポートする必要があるとします。

例3-25 インポートするWSDL

<?xml version='1.0' encoding='UTF-8'?><!-- Published by JAX-WS RI at
http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.9-b14041
svn-revision#14041. --><!-- Generated by JAX-WS RI at
http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.9-b14041
svn-revision#14041. --><definitions
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-uti
lity-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_
2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://ws.web.wls.my.org/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://ws.web.wls.my.org/" name="SampleWs">
<types>
<xsd:schema>
<xsd:import namespace="http://ws.web.wls.my.org/" schemaLocation="x.xsd"/>
</xsd:schema>
</types>
<message name="hello">
<part name="parameters" element="tns:hello"/>
</message>
<message name="helloResponse">
<part name="parameters" element="tns:helloResponse"/>
</message>
<portType name="SampleWs">
<operation name="hello">
<input wsam:Action="http://ws.web.wls.my.org/SampleWs/helloRequest" message="tns:hello"/>
<output wsam:Action="http://ws.web.wls.my.org/SampleWs/helloResponse" message="tns:helloResponse"/>
</operation>
</portType>
<binding xmlns:soapjms="http://www.w3.org/2010/soapjms/" name="SampleWsPortBinding" type="tns:SampleWs">
<soapjms:jndiInitialContextFactory>weblogic.jndi.WLInitialContextFactory</soapjms:jndiInitialContextFactory>
<soapjms:jndiConnectionFactoryName>com.oracle.webservices.api.jms.ConnectionFactory</soapjms:jndiConnectionFactoryName>
<soapjms:jndiUrl>t3://localhost:7001</soapjms:jndiUrl>
<soapjms:bindingVersion>SOAP_JMS_1_0</soapjms:bindingVersion>
<soapjms:destinationName>com.oracle.webservices.api.jms.RequestQueue</soapjms:destinationName>
<soapjms:targetService>SampleWs</soapjms:targetService>
<soapjms:timeToLive>180000</soapjms:timeToLive>
<soapjms:deliveryMode>PERSISTENT</soapjms:deliveryMode>
<soapjms:priority>0</soapjms:priority>
<soapjms:messageType>BYTES</soapjms:messageType>
<soapjms:destinationType>QUEUE</soapjms:destinationType>
<soap:binding transport="http://www.w3.org/2010/soapjms/" style="document"/>
<operation name="hello">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="SampleWs">
<port name="SampleWsPort" binding="tns:SampleWsPortBinding">
<soap:address location="jms:jndi:com.oracle.webservices.api.jms.RequestQueue?targetService=Sampl
eWs&amp;jndiURL=t3://localhost:7001&amp;messageType=BYTES&amp;deliveryMode=PERSISTENT"/>
</port>
</service>
</definitions>

このWSDLをインポートするには、pom.xmlファイルを変更して、generate-sourcesライフサイクル・フェーズ、wsimportゴール、WSDLの場所を指定し、設定する必要があるパラメータを含めます。この例では、説明上、ローカルのWSDLファイルを使用します。

次のケースについて検討します。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven_plugin.simple</groupId>
<artifactId>maven_plugin_simple</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>wsimport-jmssample</id>
<goals>
<goal>wsimport</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<wsdlFiles>
<wsdlFile>${basedir}/import-example/SampleWs.wsdl</wsdlFile>
</wsdlFiles>
<genJWS>true</genJWS>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

例3-26では、典型的なwsimportゴールの出力を示します。

例3-26 wsimport

mvn -Dfile=pom.xml generate-sources
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven_plugin_simple 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:wsimport (wsimport-jmssample) @ mave
n_plugin_simple ---
[INFO] Processing: file:/C:/Oracle/Middleware..../import-example/SampleWs.wsdl
[WARNING] Using platform encoding (Cp1252), build is platform dependent!
[INFO] jaxws:wsimport args: [-keep, -s,
'C:\Oracle\Middleware\...\import-example\target\generated-sources\wsimport', -d,
'C:\Oracle\Middleware...\import-example\target\classes', -extension,
-Xnocompile, -jms, -jmsuri, jms:jndi:null?targetServi
ce=null, -httpproxy:some-proxy-name, -generateJWS, -implDestDir,
'C:\Oracle\Middleware...\import-example',
"file:/C:/Oracle/Middleware...import-example/SampleWs.wsdl"]
parsing WSDL...

Generating code...

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.888s
[INFO] Finished at: Finished at: Wed Aug 19 11:33:51 EDT 2015
[INFO] Final Memory: 7M/23M
[INFO] ------------------------------------------------------------------------

この例では、wsimportゴールによって次のファイルが作成されます。

org
my
wls
web
ws
SampleWs_SampleWsPortImpl.java
target
classes
generated-sources
wsimport
org
my
wls
web
ws
Hello.java
HelloResponse.java
ObjectFactory.java
package-info.java
SampleWs.java
SampleWs_Service.java
jaxws
stale
.2b48c6ef28bc8a45aa2da4246c0c4ac90cf82c57

ws-wsdlc

非推奨

このゴールはこのリリースでは非推奨となっています。

完全名

com.oracle.weblogic:weblogic-maven-plugin:ws-wsdlc

説明

WSDLから一連のアーティファクトと、Webサービスの部分的なJava実装を生成するMavenゴール。

ws-wsdlcゴールは、"wsdlc" Antタスク用のMavenラッパーを提供します。これは、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』に説明されています。

パラメータ

表3-28に、ws-wsdlcのパラメータについて簡単にまとめます。これらのパラメータは、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』の表2-3 「clientgen AntタスクのWebLogic固有の属性」で詳しく説明されています。

表3-28 ws-wsdlcのパラメータ

名前

タイプ

必須

説明

bindings

java.lang.String

いいえ

JAX-WSおよびJAXBカスタム・バインディング宣言またはSOAPハンドラ・ファイルを指定するカスタマイズ・ファイル。

catalog

java.lang.String

いいえ

外部XMLカタログ・ファイルを指定します。

XMLカタログ・ファイルの作成の詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のXMLカタログの使用に関する項を参照してください。

debug

boolean

いいえ

プロセスをデバッグするときに設定するフラグを指定します。デフォルト値はfalseです。

debugLevel

java.lang.String

いいえ

Antデバッグレベルを使用します。

destImplDir

java.lang.String

いいえ

途中まで作成済のJWS実装ファイルの生成先となるディレクトリを指定します。

destJavadocDir

java.lang.String

いいえ

JWSインタフェースを記述するJavadocの生成先となるディレクトリを指定します。

destJwsDir

java.lang.String

true

JWSインタフェース・ファイルおよびデータ・バインディング・アーティファクトを格納するJARファイルの生成先となるディレクトリを指定します。。

explode

boolean

いいえ

展開された出力を必要とする場合に設定するフラグを指定します。デフォルトはtrueです。

failOnError

boolean

いいえ

ws-clientgenゴールが、エラー発生時にも実行し続けるかどうかを指定します。デフォルト値はtrueです。

fork

boolean

いいえ

外部でJDKコンパイラを使用してjavacを実行するかどうかを指定します。デフォルト値はfalseです。

includeAntRuntime

boolean

いいえ

Antランタイム・ライブラリをクラスパスに含めるかどうかを指定します。デフォルト値はtrueです。

includeJavaRuntime

boolean

いいえ

実行するVMのデフォルトのランタイム・ライブラリをクラスパスに含めるかどうかを指定します。デフォルト値はfalseです。

optimize

boolean

いいえ

最適化を必要とする場合に設定するフラグを指定します。デフォルトはtrueです。

packageName

java.lang.String

いいえ

生成されたJWSインタフェースおよび実装ファイルの生成先となるパッケージを指定します。

srcPortName

java.lang.String

いいえ

JWSインタフェース・ファイルの生成元になるWSDLポートの名前を指定します。このパラメータの値は、JWSインタフェース・ファイルの生成対象のWebサービス・ポートに対応するportパラメータのnameパラメータの値に設定します。

portパラメータは、WSDLファイル内のserviceパラメータの子です。この属性を指定しない場合、ws-wsdlcは、srcServiceNameによって指定されるサービスからJWSインタフェース・ファイルを生成します。

srcServiceName

java.lang.String

いいえ

JWSインタフェース・ファイルの生成元になるWebサービスの名前を指定します。

srcWsdl

java.lang.String

true

JWSインタフェースとデータ・バインディング・アーティファクトを格納するJARファイルの生成に使用するWSDLファイルの名前を指定します。

verbose

boolean

いいえ

冗長出力を必要とする場合に設定するフラグを指定します。デフォルト値はfalseです。

使用例

ws-wsdlcゴールは、WSDLから一連のアーティファクトと、Webサービスの部分的なJava実装を生成します。

このゴールは、構成より規則優先のアプローチのメリットを受けており、プロジェクトのデフォルトを使用して実行できます。

ws-wsdlcゴールを実行するには、次の2つの方法があります。

- コマンド・ラインからたとえば、別名を定義した後に次のように指定します。

mvn –DvariableName1=value1  –DvariableName2=value2  com.oracle.weblogic:weblogic-maven-plugin:ws-wsdlc

- Maven generate-resourcesライフサイクル・フェーズを指定することにより。
これを実行するには、pom.xmlファイルを変更して、generate-resourcesライフサイクル・フェーズ、ws-wsdlcゴールを指定し、設定する必要があるパラメータを含めます。この場合、pom.xmlの同じディレクトリでmvn generate-resourcesを実行します。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven_plugin.simple</groupId>
<artifactId>maven_plugin_simple</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>wsdlc</id>
<phase>generate-resources</phase>
<goals>
<goal>ws-wsdlc</goal>
</goals>
<configuration>
<srcWsdl>${basedir}/AddNumbers.wsdl</srcWsdl>
<destJwsDir>${project.build.directory}/jwsImpl</destJwsDir>
<destImplDir>${project.build.directory}/output</destImplDir>
<packageName>maven_plugin.simple</packageName>
<verbose>true</verbose>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

例3-27では、典型的なws-wsdlcゴールの出力を示します。

例3-27 ws-wsdlc

mvn -f wsdlc_pom.xml generate-resources
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven_plugin_simple 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:ws-wsdlc (wsdlc) @ maven_plugin_simple ---
[INFO] Executing standalone...

[INFO] Executing Maven goal 'wsdlc'...
calling method public static void weblogic.wsee.tools.wsdlc.MavenWsdlc.execute(o
rg.apache.maven.plugin.logging.Log,java.util.Map) throws java.lang.Throwable
Catalog dir = C:\Users\maven\AppData\Local\Temp\_ckr59b
Download file [AddNumbers.wsdl] to C:\Users\maven\AppData\Local\Temp\_ckr59b
srcWsdl is redefined as [ C:\Users\maven\AppData\Local\Temp\_ckr59b\AddNumber
s.wsdl ]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

ws-jwsc

非推奨

このゴールはこのリリースでは非推奨となっています。

完全名

com.oracle.weblogic:weblogic-maven-plugin:ws-jwsc

説明

JAX-WS webサービスを構築するMavenゴール。

ws-jwscゴールは、jwsc Antタスク用のMavenラッパーを提供します。これは、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』に説明されています。

注意:

ws-jwscゴールは、WebLogic固有のアノテーションに関する項に説明されているJAX-RPC-のみのJWSアノテーションとは連携しません。

module要素のネストされた設定

ws-jwscゴールは、例3-28の太字で示されているように、ネストされた設定の要素をサポートしています。複数のmoduleを含むMavenプロジェクトの詳細は、POMの概要に関する項を参照してください。

例3-28 ネストされた設定の要素

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.ws</groupId>
<artifactId>test-ws-jwsc1</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>first-jwsc</id>
<phase>generate-resources</phase>
<goals>
<goal>ws-jwsc</goal>
</goals>
<configuration>
<srcDir>${basedir}/src/main/java</srcDir>
<destDir>${project.build.directory}/jwscOutput
/${project.build.finalName}</destDir>
<listfiles>true</listfiles>
<debug>true</debug>

<module>
<name>pocreate</name>
<contextPath>mypub</contextPath>
<compiledWsdl>D:\maven-test\order_wsdl.jar</compiledWsdl >

<jws>
<file>examples/wsee/jwsc/POCreateImpl.java</file>
<transportType>
<type>WLHttpTransport</type>
<serviceUri>POCreate</serviceUri>
<portName>POCreatePort</portName>
</transportType>
</jws>
<jws>
…
</jws>
<descriptors>
<descriptor>"resources/web.xml"<descriptor/>
<descriptor>"resources/weblogic.xml"<descriptor />
</descriptors>
</module>
<module>
…
</module>
</modules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

ws-jwscに対するこれらのネストされた設定の要素には、次の条件があります。

- 次の要素のうちの少なくとも1つを使用する必要があります: jws、jwses、module、またはmodules。

- jwsesやmodules要素などのcollection要素は省略できます。

- collection要素内に子要素が1つのみある場合、そのcollection要素も削除できます。
たとえば、jws要素が1つのみある場合、jwsを使用します。複数のjws要素がある場合は、jwses要素の下にすべてのjws要素を追加します。

- JWSCやタスクと同様に、moduleにjwsの子要素が1つのみある場合、moduleのその他のサブ要素は、jwscとjwsc/transportTypeにネストされます。

例3-29は、jwsパラメータがws-jwscの子となっているmodule要素がない例を示しています。

例3-29 ws-jwscゴールの子としてのjws要素

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.ws</groupId>
<artifactId>test-ws-jwsc</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>first-jwsc</id>
<phase>compile</phase>
<goals>
<goal>ws-jwsc</goal>
</goals>
<configuration>
<srcDir>${basedir}/src/main/java</srcDir>
<destDir>${project.build.directory}/jwscOutput/
${project.build.finalName}</destDir>
<jws>            <!-- no parent <module> -->
<file>examples/wsee/jwsc/POCreateImpl.java</file>
<compiledWsdl>${project.build.directory}/purchaseorder_wsdl.jar>
<transportType>
<type>WLHttpTransport</type>
</transportType>
</jws>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

ws-jwscのパラメータ

表3-29に、ws-jwscのパラメータについて簡単にまとめます。これらのパラメータは、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』の表2-3 「clientgen AntタスクのWebLogic固有の属性」で詳しく説明されています。

表3-29 ws-jwscのパラメータ

名前

タイプ

必須

説明

applicationXml

java.lang.String

いいえ

エンタープライズ・アプリケーションのapplication.xmlデプロイメント記述子の完全修飾名およびフルパスを指定します。既存のファイルを指定した場合、ws-jwscゴールは、Webサービス情報を含めるようにそのファイルを更新します。ただし、jwscは、変更されたapplication.xmlファイルをdestDirに自動的にコピーしません。このファイルをdestDIRに手動でコピーする必要があります。ファイルが存在しない場合、jwscはファイルを作成します。

ws-jwscゴールは、対応するweblogic-application.xmlファイルも同じディレクトリで作成または更新します。この属性を指定しなかった場合、jwscは、destDir/META-INF/application.xml (destDirはjwsc属性)ファイルを作成または更新します。

debug

boolean

いいえ

追加のデバッグ出力をオンにします。

destDir

java.lang.String

true

コンパイルしたJWSファイル、XMLスキーマ、WSDL、生成されたデプロイメント記述子ファイルを含む、JARファイルまたはWARファイルにパッケージ化された全ファイルを格納するディレクトリの絶対パス名を指定します。

destEncoding

java.lang.String

いいえ

デプロイメント記述子またはXMLファイルなどの出力ファイルの文字エンコーディングを指定します。文字エンコーディングの例としては、SHIFT-JISやUTF-8などがあります。この属性のデフォルト値はUTF-8です。

jws

Jws

いいえ

<jws>要素が1つのみあります。

jwsパラメータの説明は、表3-30を参照してください。

jwses

Jws

いいえ

< jws>要素が複数含まれます。

keepGenerated

boolean

いいえ

このゴールで生成されたJavaソース・ファイルおよびアーティファクトがすでに存在する場合、それを再生成するかどうかを指定します。

falseを指定すると、新しいJavaソース・ファイルとアーティファクトが常に生成され、既存のアーティファクトがすべて上書きされます。trueを指定すると、ゴールによって、既存のアーティファクトのタイムスタンプに基づき、変更のあったアーティファクトのみが再生成されます。

listfiles

boolean

いいえ

すべてのファイルをリストするかどうかを指定します。

module

Module

いいえ

1つの<module>要素が含まれます。

moduleパラメータの説明は、表3-31を参照してください。

modules

Module

いいえ

<module>要素が複数含まれます。

optimize

boolean

いいえ

最適化が必要な場合に設定するフラグを指定します。デフォルトはtrueです。

sourcepath

java.lang.String

true

パラメータとして使用されるJavaBeanやユーザー定義の例外など、JWSファイルで参照されるJavaファイルを格納する最上位ディレクトリのフルパス名。

srcDir

java.lang.String

true

コンパイルするJWSファイルを含む最上位ディレクトリの絶対パス名を指定します。

srcEncoding

java.lang.String

いいえ

JWSファイルまたは構成XMLファイルなどの入力ファイルの文字エンコーディングを指定します。

文字エンコーディングの例としては、SHIFT-JISやUTF-8などがあります。この属性のデフォルト値は、JVMに対する文字エンコーディング・セットです。

verbose

boolean

いいえ

冗長出力を指定します

jwsのパラメータ

「jws」で説明されているように、jwsパラメータでは、特定のWebサービスを実装するJWSファイルの名前を指定します。ws-jwscゴールは、このWebサービス向けにJavaコードとサポート・アーティファクトを生成し、エンタープライズ・アプリケーション内でデプロイ可能なWARファイルにパッケージ化します。

次の2つの方法でjwsパラメータを指定できます。

- ws-jwscゴールの直接の子要素。この場合、ws-jwscは各JWSファイルに個別のWARファイルを生成します。一般的に、ws-jwscゴールに対してJWSファイルを1つのみ指定している場合にこの方法を使用します。

- moduleパラメータの子要素。同様に、ws-jwscゴールの子でもあります。この場合、ws-jwscは、moduleパラメータ内でグループ化されているすべてのJWSファイルの生成されたコードおよびアーティファクトをすべて含むWARファイルを1つ生成します。
この方法は、共通のJavaデータ型など、サポート・ファイルをすべてのJWSファイルで共有する場合に有効です。

表3-30に、jwsパラメータの子パラメータを示します。この表では、jwsがws-jwscの子である場合、moduleの子である場合、またはその両方の場合にパラメータが適用されるかどうかを説明しています。

表3-30 jwsのパラメータ

名前

タイプ

必須

説明

ws-jwsc、module、または両方の子

compiledWsdl

java.lang.String

いいえ

既存のWSDLファイルに基いてws-wsdlcゴールによって生成されるJARファイルの絶対パス名を指定します。

「WSDLから開始する」ケースでのみ必須

両方

contextPath

java.lang.String

いいえ

webサービスのデプロイされたコンテキストを指定します。

ws-jwsc

explode

boolean

いいえ

展開された出力を必要とする場合に設定するフラグを指定します。デフォルトはtrueです。

ws-jwsc

file

java.lang.String

true

コンパイルするJWSファイルの名前。ws-jwscゴールは、srcdirディレクトリにあるファイルを検索します。

両方

generateWsdl

boolean

true

生成されたWARファイルにWEB-INFディレクトリのWSDLファイルを含めるかどうかを指定します。デフォルト値はfalseです。

両方

jmstransportservice

boolean

いいえ

WebサービスにJMSトランスポートを使用します。省略できます。jmstransportserviceパラメータの説明は、表3-34を参照してください。

ws-jwsc

name

java.lang.String

いいえ

生成されたWARファイル(explode属性がtrueに設定されている場合は展開ディレクトリ)で、デプロイ可能なWebサービスを格納しているファイルの名前を指定します。

ws-jwsc

transportType

transportType

いいえ

トランスポート・タイプ要素が1つのみ含まれる場合に使用されます。省略できます。

transportTypeパラメータの説明は、表3-33を参照してください。

両方

transportTypes

transportType

いいえ

トランスポート・タイプ要素が複数含まれる場合に使用されます。省略できます。

transportTypeパラメータの説明は、表3-33を参照してください。

両方

wsdlOnly

boolean

いいえ

このJWSファイルに対してWSDLファイルのみが生成されるように指定します。デフォルト値はfalseです。

ws-jwsc

moduleのパラメータ

「module」で説明されているように、moduleパラメータは1つ以上のjwsパラメータをまとめてグループ化し、それらの生成されたコードまたはアーティファクトを単一のWebアプリケーション(WAR)ファイルにパッケージ化します。moduleパラメータは、ws-jwscゴールの子です。

表3-31に、moduleパラメータのパラメータを示します。

表3-31 moduleのパラメータ

名前

タイプ

必須

説明

clientgen

java.lang.String

いいえ

<clientgen>要素が1つのみあります。省略できます。

clientgens

java.lang.String

いいえ

<clientgen>要素が複数あります。省略できます。

contextPath

java.lang.String

いいえ

Webサービスのデプロイされたコンテキストを指定します。

descriptor

java.lang.String

いいえ

新しいweb.xml記述子を生成しない場合に使用するweb.xml記述子を指定します。パスは完全修飾する必要があります。複数のファイルは", "で区切る必要があります。

ejbWsInWar

boolean

いいえ

EJBベースのWebサービスを、JARファイルではなくWARファイルにパッケージ化するかどうかを指定します。

explode

boolean

いいえ

展開された出力を必要とする場合に設定するフラグを指定します。デフォルトはtrueです。

FileSet

FileSet

いいえ

1つのFileSet要素が含まれる場合に使用されます。省略できます。

FileSets

FileSet

いいえ

FileSet要素が複数含まれる場合に使用されます。省略できます。

generateWsdl

boolean

true

生成されたWARファイルにWEB-INFディレクトリのWSDLファイルを含めるかどうかを指定します。デフォルト値はfalseです。

jws

Jws

いいえ

1つのjws要素が含まれる場合に使用されます。省略できます。

jwses

Jws

いいえ

jws要素が複数含まれる場合に使用されます。省略できます。

name

java.lang.String

いいえ

earファイルを評価するときに使用するWARの名前を指定します。

wsdlOnly

boolean

いいえ

このJWSファイルに対してWSDLファイルのみが生成されるように指定します。デフォルト値はfalseです。

zipfileset

java.lang.String

いいえ

<zipfileset>要素が1つのみあります。

FileSetのパラメータ

「jwsfileset」で説明されているように、FileSetパラメータは、ws-jwscゴールが、コンパイルするJWSファイルを検索する1つ以上のディレクトリを指定します。この場合、ws-jwscが検索するJWSファイルのリストは、各ファイルがmoduleのjwsパラメータで個別に指定されているように扱われます。

FileSetパラメータは、ws-jwscゴールの子です。

表3-32に、FileSetパラメータのパラメータを示します。

表3-32 FileSetのパラメータ

名前

タイプ

必須

説明

srcDir

java.lang.String

true

ws-jwscゴールが、コンパイルするJWSファイルを検索するディレクトリ(セミコロン区切り)を指定します。

prefix

java.lang.String

いいえ

使用する接頭辞。

sourceIncludes

java.lang.String

いいえ

ファイル・セットに対する明示的なincludes-listを指定します。

sourceExcludes

java.lang.String

いいえ

ファイル・セットに対する明示的なexcludes-listを指定します。

TransportTypeのパラメータ

「WLHttpTransport」、「WLHttpsTransport」および「WLJMSTransport」で説明されているように、トランスポート・パラメータを使用して、生成されたWSDLのポート名に加え、Webサービスを呼び出すために使用するトランスポート・タイプ、コンテキスト・パスおよびURLのサービスURIセクションを指定します。

ws-jwscゴールは、これらのトランスポート・パラメータを1つのTransportTypeに結合します。

表3-32に、transportTypeパラメータのパラメータを示します。

表3-33 transportTypeのパラメータ

名前

タイプ

必須

説明

transportTypeName

java.lang.String

true

値がWLHttpTransport、WLHttpsTransport、またはWLJMSTransportであることを指定します。

デフォルト値はWLHttpTransportです。

serviceUri

java.lang.String

いいえ

URLのWebサービスURI部分を指定します。

contextPath

java.lang.String

いいえ

Webサービスのデプロイされたコンテキストを指定します。

portName

java.lang.String

いいえ

生成されたWSDLのポートの名前を指定します。

表3-34に、jmstransportserviceパラメータのパラメータを示します。

表3-34 jmstransportserviceのパラメータ

名前

タイプ

必須

説明

destinationName

java.lang.String

いいえ

宛先キューまたはトピックのJNDI名。デフォルト値はcom.oracle.webservices.jms.RequestQueueです。

destinationType

java.lang.String

いいえ

有効な値は次のとおりです: QUEUEまたはTOPIC。デフォルト値はQUEUEです。

replyToName

java.lang.String

いいえ

レスポンス・メッセージを送信するJMS宛先のJNDI名。

targetService

java.lang.String

いいえ

Webサービスのポート・コンポーネント名。

jndiInitialContextFactory

java.lang.String

いいえ

JNDIルックアップに使用される初期コンテキスト・ファクトリ・クラスの名前。デフォルト値はweblogic.jndi.WLInitialContextFactoryです。

jndiConnectionFactoryName

java.lang.String

JMS接続を確立するために使用される接続ファクトリのJNDI名。デフォルト値はcom.oracle.webservices.jms.ConnectionFactoryです。

jndiUrl

java.lang.String

JNDIプロバイダのURL。デフォルト値はt3://localhost:7001です。

deliveryMode

java.lang.String

リクエスト・メッセージが永続であるかどうかを示す配信モード。有効な値は、PERSISTENTおよびNON_PERSISTENTです。デフォルト値はPERSISTENTです。

timeToLive

long

いいえ

リクエスト・メッセージの存続期間(ミリ秒単位)。デフォルト値は180000Lです。

priority

int

いいえ

リクエストおよびレスポンス・メッセージに関連付けられたJMSの優先度。デフォルト値は0です。

jndiContextParameter

java.lang.String

いいえ

次のようなフォーマットのJNDIのプロパティ: someParameterName1=someValue1 , someParameterName2=someValue2

bindingVersion

java.lang.String

いいえ

SOAP JMSバインディングのバージョン。デフォルト値は1.0です。

runAsPrincipal

java.lang.String

いいえ

リスニングMDBを実行するために使用されるプリンシパル。

runAsRole

java.lang.String

いいえ

リスニングMDBを実行するために使用されるロール。

messageType

java.lang.String

いいえ

リクエスト・メッセージで使用するメッセージの種類。有効な値は com.oracle.webservices.api.jms.JMSMessageType.BYTESおよびcom.oracle.webservices.api.jms.JMSMessageType.TEXTです。デフォルト値はBYTESです。

enableHttpWsdlAccess

boolean

いいえ

HTTPを介してWSDLをパブリッシュするかどうかを指定するブール・フラグ。デフォルト値はtrueです。

mdbPerDestination

boolean

いいえ

リクエストされた宛先ごとに1つのリスニング・メッセージドリブンBean (MDB)を作成するかどうかを指定するブール・フラグ。デフォルト値はtrueです。

activationConfig

java.lang.String

いいえ

JMSプロバイダに渡されたアクティブ化構成プロパティ。

contextPath

java.lang.String

いいえ

webサービスのデプロイされたコンテキスト。

serviceUri

java.lang.String

いいえ

URLのWebサービスURI部分。

portName

java.lang.String

いいえ

生成されたWSDLのポートの名前。

使用例

ws-jwscゴールは、JAX-WS webサービスを構築します。

このゴールは、構成より規則優先のアプローチのメリットを受けており、プロジェクトのデフォルトを使用して実行できます。

ws-jwscゴールを実行するには、Maven generate-resourcesフェーズを指定します。

これを実行するには、pom.xmlファイルを変更して、generate-resourcesフェーズ、ws-jwscゴールを指定し、設定する必要があるpaパラメータを含めます。この場合、pom.xmlの同じディレクトリでmvn generate-resourcesを実行します。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>maven_plugin.simple</groupId>
<artifactId>maven_plugin_simple</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.2.1-0-0</version>
<executions>
<execution>
<id>jwsc</id>
<phase>generate-resources</phase>
<goals>
<goal>ws-jwsc</goal>
</goals>
<configuration>
<destDir>${project.build.directory}/jwscOutput/
<listfiles>true</listfiles>
<debug>true</debug>
<jws>            <!-- no parent <module> -->
<file>examples/wsee/jwsc/POCreateImpl.java</file>
<compiledWsdl>${project.build.directory}/purchaseorder_wsdl.jar>
<transportType>
<type>WLHttpTransport</type>
</transportType>
</jws>
<verbose>true</verbose>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

例3-30では、典型的なws-jwscゴールの出力を示します。

例3-30 ws-jwsc

mvn -f jwsc_pom.xml generate-resources
INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building maven_plugin_simple 1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.2.1-0-0:ws-jwsc (jwsc) @ maven_plugin_simple ---
[INFO] Executing standalone...

INFO] Executing Maven goal 'jwsc'...
calling method public static void weblogic.wsee.tools.jws.MavenJwsc.execute(org.apache.maven.plugin.logging.Log,
java.util.Map) throws java.lang.Throwable
[EarFile] Application File : C:\maven-doc\jwsc-test-2\output\META-INF\application.xml
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

4 分割開発ディレクトリ環境の作成

この章では、Java EEアプリケーションまたはモジュールの開発に使用できるWebLogic Server 分割開発ディレクトリを作成する方法を説明します。

この章の内容は次のとおりです。

- 分割開発ディレクトリ環境の概要

- 分割開発ディレクトリ構造の使用: 主な手順

- 分割開発ディレクトリでのJava EEコンポーネントの配置

- 分割開発ディレクトリでの共有クラスの配置

- weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成

- 分割開発ディレクトリを使用した複数EARプロジェクトの開発

- WebLogic Serverアプリケーション開発のベスト・プラクティス

分割開発ディレクトリ環境の概要

WebLogic分割開発ディレクトリ環境は、ディレクトリ・レイアウトと、Java EEアプリケーションの反復的なビルド、変更、およびデプロイメントを支援する関連Antタスクで構成されます。他の開発フレームワークと比較して、WebLogic分割開発ディレクトリには、これらのメリットがあります。

- 迅速な開発とデプロイメント。不必要なファイルのコピーを最小限に抑えることにより、分割開発ディレクトリのAntタスクはデプロイ可能なアーカイブ・ファイルまたは展開アーカイブ・ディレクトリを最初に生成しないで迅速なアプリケーションの再コンパイルと再デプロイを支援します。

- シンプルな構築スクリプト。Oracle提供のAntタスクは、作成するJava EEモジュールおよびクラスを自動的に判別し、一般的なクラスパスの依存関係をサポートする適切な順序でコンポーネントをビルドします。多くの場合、プロジェクトの構築スクリプトはただ単にソース・ディレクトリとビルド・ディレクトリを識別し、Antタスクがそのデフォルト動作を実行できるようにするだけです。

- ソース制御システムとの簡単な統合。分割開発ディレクトリは、ソース・ファイルと生成ファイルを完全に分離します。このため、編集可能なファイルのみをソース制御システムに維持することができます。また、ビルド・ディレクトリ全体を削除することでビルドをクリーン・アップすることもできます(ビルド・ファイルはプロジェクトの再ビルドで簡単に置換されます)。

ソース・ディレクトリとビルド・ディレクトリ

ソース・ディレクトリとビルド・ディレクトリは、分割開発ディレクトリ環境の基盤です。ソース・ディレクトリには、プロジェクトのすべての編集可能なファイル(Javaソース・ファイル、編集可能な記述子ファイル、JSP、静的コンテンツなど)が格納されます。アプリケーションのソース・ディレクトリは、「分割開発ディレクトリでのJava EEコンポーネントの配置」で説明されているディレクトリ構造のガイドラインに従って作成します。

ソース・ディレクトリの最上位レベルは、1つのJava EEモジュールのみを開発している場合であっても、常にエンタープライズ・アプリケーション(.earファイル)を表します。最上位ソース・ディレクトリの下のサブディレクトリには、次が含まれます。

- エンタープライズ・アプリケーションのモジュール(EJBやWebアプリケーション)

注意:

分割開発ディレクトリ構造は、新しいリソース・アダプタ・コンポーネントの開発をサポートしていません。

- エンタープライズ・アプリケーションの記述子ファイル(application.xmlおよびweblogic-application.xml)

- アプリケーションの複数のモジュールで共有されるユーティリティ・クラス(例外、定数など)

- アプリケーションのモジュールで使用されるライブラリ(コンパイル済み.jarファイル - サード・パーティのライブラリを含みます)

ビルド・ディレクトリの内容は、有効なソース・ディレクトリに対してwlcompile antタスクを実行すると自動的に生成されます。wlcompileタスクはソース・ディレクトリ内のEJB、Webアプリケーション、および共有のライブラリ・ディレクトリとクラス・ディレクトリを認識し、一般的なクラス・パスの要件をサポートする順序でそれらのコンポーネントをビルドします。補足的なAntタスクを使用すると、Webサービスをビルドするか、アノテーション付きのEJBコードからデプロイメント記述子ファイルを生成できます。

図4-1 ソース・ディレクトリとビルド・ディレクトリ

ビルド・ディレクトリには、ビルド・プロセスで生成されたファイルのみが格納されます。ソース・ディレクトリとビルド・ディレクトリのファイルを組み合わせることにより、デプロイ可能なJava EEアプリケーションになります。

ビルド・ディレクトリとソース・ディレクトリの内容は、任意に選択したディレクトリに配置できます。ただし、使いやすいように、それらのディレクトリは1つのプロジェクト・ディレクトリの中のsourceおよびbuildというディレクトリに配置されます(たとえば、\myproject\buildおよび\myproject\source)。

分割開発ディレクトリからのデプロイメント

すべてのWebLogic Serverデプロイメント・ツール(weblogic.Deployer、wldeployおよびWebLogic Server管理コンソール)は、分割開発ディレクトリからの直接のデプロイメントをサポートしています。WebLogic Serverにアプリケーションをデプロイする場合は、ビルド・ディレクトリのみ指定します。

WebLogic Serverは、アプリケーションのデプロイメントでソース・ディレクトリ内のすべてのクラスとリソースを使用しようとします。必要なリソースがソース・ディレクトリにない場合、WebLogic Serverはアプリケーションのビルド・ディレクトリでそのリソースを探します。たとえば、編集可能なファイルとしてソース・コードと一緒に格納されているのではなく、ビルド・プロセスの過程でデプロイメント記述子が生成された場合、WebLogic Serverはその生成ファイルをビルド・ディレクトリから取得します。

WebLogic Serverは、アプリケーションのビルド・ディレクトリの最上位の位置にある.beabuild.txtファイルを調べてソース・ディレクトリの位置を確認します。ソース・ディレクトリを移動した場合は、.beabuild.txtファイルを編集して新しいソース・ディレクトリ名を指定してください。

「wldeployを使用したアプリケーションのデプロイメント」では、分割ディレクトリ環境からのデプロイメントを自動化するために使用できるwldeploy Antタスクが説明されています。

図4-2では、一般的なデプロイメント・プロセスを示します。このプロセスは、WebLogic Serverのツールでビルド・ディレクトリを指定することから始まります。この図で、コンパイルされたクラスと生成されたデプロイメント記述子はすべてビルド・ディレクトリにありますが、他のアプリケーション・リソース(静的ファイルや編集可能なデプロイメント記述子など)はどこにあるかわかりません。WebLogic Serverは隠された.beabuild.txtファイルを使用して、必要なリソースのあるアプリケーションのソース・ディレクトリを見つけます。

図4-2 分割ディレクトリのデプロイメント

分割開発ディレクトリにおけるAntタスク

Oracleでは、分割開発ディレクトリ環境を使用したアプリケーションの開発を支援するAntタスクのコレクションを用意しています。各Antタスクは、ソース・ディレクトリ、ビルド・ディレクトリ、またはその両方を使用して一般的な開発タスクを実行します。

- wlcompile - このAntタスクは、ソース・ディレクトリの内容をビルド・ディレクトリのサブディレクトリにコンパイルします。wlcompileはJavaクラスをコンパイルするだけでなく、アノテーション付きの.ejbファイルを処理してデプロイメント記述子を作成します(「wlcompileを使用したアプリケーションのコンパイル」を参照)。

- wlappc - このAntタスクは、appcコンパイラを呼び出し、appcコンパイラはJSPおよびコンテナ固有のEJBクラスを生成してデプロイメントします。「wlappcを使用したモジュールおよびアプリケーションのビルド」を参照してください。

- wldeploy - このAntタスクは、任意形式のJava EEアプリケーション(展開されたものでもアーカイブされたものでも)をWebLogic Serverにデプロイします。分割開発ディレクトリ環境から直接デプロイするには、アプリケーションのビルド・ディレクトリを指定します。「wldeploy Antタスクのリファレンス」を参照してください。

- wlpackage - このAntタスクはソース・ディレクトリとビルド・ディレクトリ両方の内容を使用して、デプロイメント用に受け渡すことができるEARファイルまたは展開EARディレクトリを生成します。

分割開発ディレクトリ構造の使用: 主な手順

次の手順では、分割開発ディレクトリ構造を使用してWebLogic Serverアプリケーションをビルドおよびデプロイする方法を示します。

1. プロジェクトのメインのEARソース・ディレクトリを作成します。分割開発ディレクトリ環境を使用する場合は、複数のJava EEモジュールを開発しない場合でも、WebアプリケーションとEJBをエンタープライズ・アプリケーションの一部として開発する必要があります。「分割開発ディレクトリでのJava EEコンポーネントの配置」を参照してください。

2. Webアプリケーション、EJBコンポーネントまたは共有ユーティリティ・クラスのソースを格納するための、1つまたは複数のサブディレクトリをEARディレクトリに追加します。「分割開発ディレクトリでのJava EEコンポーネントの配置」および「分割開発ディレクトリでの共有クラスの配置」を参照してください。

3. モジュールのすべての編集可能なファイル(ソース・コード、静的コンテンツ、編集可能なデプロイメント記述子)をEARディレクトリのサブディレクトリに格納します。必要に応じて、ソース・ディレクトリの全内容をソース制御システムに追加します。

4. setWLSEnv.cmd (Windows)またはsetwlsenv.sh (UNIX)スクリプトを実行してWebLogic Server環境を設定します。それらのスクリプトは、WL_HOME\server\bin\ディレクトリにあります。WL_HOMEは、WebLogic Serverのインストール先の最上位ディレクトリです。

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

5. weblogic.BuildXMLGenユーティリティを使用して、プロジェクトで使用するデフォルトのbuild.xmlファイルを生成します。環境の必要に応じて、デフォルトのプロパティ値を編集します。「weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成」を参照してください。

6. build.xmlファイル内のデフォルト・ターゲットを使用して、アプリケーションをビルド、デプロイ、およびパッケージ化します。デフォルト・ターゲットのリストについては、「weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成」を参照してください。

分割開発ディレクトリでのJava EEコンポーネントの配置

分割開発ディレクトリ構造では、各プロジェクトをJava EEエンタープライズ・アプリケーションとしてステージングする必要があります。したがって、分割ディレクトリのAntタスクを有効活用するには、スタンドアロンのWebアプリケーションやEJBでもエンタープライズ・アプリケーションのモジュールとしてステージングすることをお薦めします。このプラクティスを行うことで、後日モジュールを簡単に追加または削除することもできます(アプリケーションがすでにEARとして構成されているため)。

注意:

プロジェクトで複数のEARが必要な場合は、「分割開発ディレクトリを使用した複数EARプロジェクトの開発」も参照してください。

次の項では、分割開発ディレクトリ構造で次のモジュール・タイプをステージングするための基本規約を説明します。

- エンタープライズ・アプリケーションの構成

- Webアプリケーション

- EJB

- 共有ユーティリティ・クラス

- サード・パーティ・ライブラリ

ディレクトリの例は、ORACLE_HOME\wlserver\samples\src\examples\splitdirにインストールされたsplitdirサンプル・アプリケーションから利用します。ORACLE_HOMEはWebLogic Serverのコード・サンプルを構成するディレクトリです。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

ソース・ディレクトリの概要

次の図は、Webアプリケーション、EJB、共有ユーティリティ・クラスおよびサード・パーティ・ライブラリを持つエンタープライズ・アプリケーションのソース・ディレクトリの内容をまとめたものです。以降の項では、エンタープライズ・ソース・ディレクトリの個々の要素がどのように配置されるのかを詳しく説明します。

図4-3 エンタープライズ・アプリケーションのソース・ディレクトリの概要

エンタープライズ・アプリケーションの構成

分割開発ディレクトリ・プロジェクトの最上位ソース・ディレクトリは、エンタープライズ・アプリケーションを表します。次の図は、このディレクトリに必要な最小限のファイルとディレクトリを示しています。

図4-4 エンタープライズ・アプリケーションのソース・ディレクトリ

次の項で説明するように、エンタープライズ・アプリケーション・ディレクトリには、Webアプリケーション、EJB、ユーティリティ・クラス、サード・パーティJARファイルなどを保持する1つまたは複数のサブディレクトリもあります。

Webアプリケーション

Webアプリケーションは、次の図に示されている基本的なソース・ディレクトリ・レイアウトを使用します。

図4-5 Webアプリケーションのソース・ディレクトリとビルド・ディレクトリ

Webアプリケーションの主要なディレクトリとファイルは、次のとおりです。

- helloWebApp\ - Webアプリケーション・モジュールの最上位には、JSPファイルや、アプリケーションで使用されるHTMLファイルやグラフィックなどの静的コンテンツを格納できます。静的ファイルは、Webアプリケーションの任意指定のサブディレクトリに格納することもできます(helloWebApp\graphicsやhelloWebApp\staticなど。)

- helloWebApp\WEB-INF\ - Webアプリケーションの編集可能なデプロイメント記述子のファイル(web.xmlおよびweblogic.xml)をWEB-INFサブディレクトリに格納します。

- helloWebApp\WEB-INF\src - サーブレットのJavaソース・ファイルはWEB-INF\srcの下のパッケージ・サブディレクトリに格納します。

Webアプリケーションをビルドする際に、appc AntタスクとjspcコンパイラはJSPをビルド・ディレクトリのhelloWebApp\WEB-INF\classes\jsp_servletの下のパッケージ・サブディレクトリにコンパイルします。そのビルド・プロセスで、編集可能なデプロイメント記述子はコピーされません。

EJB

EJBは、次の図に示されているソース・ディレクトリ・レイアウトを使用します。

図4-6 EJBのソース・ディレクトリとビルド・ディレクトリ

EJBの主要なディレクトリとファイルは、以下のとおりです。

- helloEJB\ - EJBのソース・ファイルはすべて、EJBモジュール・ディレクトリのパッケージ・ディレクトリに格納します。ソース・ファイルは、.javaソース・ファイルかアノテーション付きの.ejbファイルのいずれかです。

- helloEJB\META-INF\ - 編集可能なEJBデプロイメント記述子(ejb-jar.xmlおよびweblogic-ejb-jar.xml)はEJBモジュール・ディレクトリのMETA-INFサブディレクトリに格納します。helloWorldEarサンプルにはhelloEJB\META-INFサブディレクトリが含まれていません。その理由は、デプロイメント記述子ファイルが.ejbソース・ファイルのアノテーションから生成されているためです。「EJBの記述子に関する重要な注意事項」を参照してください。

ビルド・プロセスの過程で、EJBクラスはビルド・ディレクトリのhelloEJBモジュールのパッケージ・サブディレクトリにコンパイルされます。また、アノテーション付きの.ejbソース・ファイルを使用する場合は、ビルド・プロセスでEJBデプロイメント記述子が生成されて、ビルド・ディレクトリのhelloEJB\META-INFサブディレクトリに格納されます。

EJBの記述子に関する重要な注意事項

EJBデプロイメント記述子はソースMETA-INFディレクトリに含まれ、それらの記述子ファイルがゼロから作成されるか手動で編集される場合のみソース・コードとして取り扱われる必要があります。アノテーション付きの.ejbファイルから生成された記述子ファイルはビルド・ディレクトリにのみ配置され、それらのファイルはアプリケーションをビルドすることで削除および再生成できます。

ある特定のEJBコンポーネントについて、EJBのソース・ディレクトリは次のいずれかを含む必要があります:

- META-INFに、.javaソース・ファイルのEJBソース・コードと編集可能なデプロイメント記述子

または:

- META-INF.に、記述子のアノテーションが.ejbソース・ファイルにあるEJBソース・コードと編集できない記述子。

つまり、アノテーション付きの.ejbソース・ファイルと編集可能な記述子ファイルを同じEJBコンポーネントで提供してはならないということです。

分割開発ディレクトリでの共有クラスの配置

WebLogic分割開発ディレクトリは、エンタープライズ・アプリケーションのモジュールで必要とされる共有ユーティリティ・クラスとライブラリの格納にも役立ちます。次の項では、共有ユーティリティ・クラスとサード・パーティJARファイルのディレクトリ・レイアウトとクラスローディング動作について説明します。

共有ユーティリティ・クラス

エンタープライズ・アプリケーションは、アプリケーション・モジュール間で共有されるJavaユーティリティ・クラスを頻繁に使用します。Javaユーティリティ・クラスがサード・パーティのJARと異なる点は、ソース・ファイルがアプリケーションの一部であり、コンパイルを必要とすることです。Javaユーティリティ・クラスは一般的に、EJBまたはWebアプリケーションなどのアプリケーション・モジュールで使用されるライブラリです。

図4-7 Javaユーティリティ・クラスのディレクトリ

Javaユーティリティ・クラスのソースは、エンタープライズ・アプリケーションの最上位ディレクトリの指定したサブディレクトリに配置します。その指定のサブディレクトリの下では、標準のパッケージ・サブディレクトリ規約を使用します。

ビルド・プロセスの過程で、wlcompile Antタスクはjavacコンパイラを呼び出し、Javaクラスをビルド・ディレクトリの下のAPP-INF/classes/ディレクトリにコンパイルします。その結果、デプロイされているアプリケーションの他のモジュールからそれらのクラスが利用可能になります。

サード・パーティ・ライブラリ

エンタープライズ・アプリケーションを拡張してサード・パーティの.jarファイルを使用するには、それらのファイルを次のようにAPP-INF\lib\ディレクトリに配置します。

図4-8 サード・パーティ・ライブラリのディレクトリ

サード・パーティJARは通常はコンパイルされませんが、アプリケーション・コードのソース制御システムを使用してバージョニングできます。たとえば、XMLパーサー、ロギング実装、およびWebアプリケーション・フレームワークのJARファイルは一般的にアプリケーションで使用され、編集可能なソース・コードと一緒に保持されます。

ビルド・プロセスの過程で、サード・パーティJARファイルはビルド・ディレクトリにコピーされませんが、デプロイメントのソース・ディレクトリに残ります。

共有クラスのクラス・ローディング

APP-INF/classesとAPP-INF/libに格納されたクラスとライブラリは、エンタープライズ・アプリケーションのすべてのモジュールからアクセスできます。アプリケーションのクラスローダーは常に、まず初めにAPP-INF/classes、次にAPP-INF/libを調べることでクラスのリクエストの解決を試みます。

weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成

ソース・ディレクトリ構造をセット・アップした後は、weblogic.BuildXMLGenユーティリティを使用して基本のbuild.xmlファイルを作成します。weblogic.BuildXMLGenは、分割開発ディレクトリ構造に配置されたエンタープライズ・アプリケーションのためのAnt build.xmlファイルを生成する便利なユーティリティです。このユーティリティは、ソース・ディレクトリを解析して、エンタープライズ・アプリケーションならびに個々のモジュールのビルドおよびデプロイ・ターゲットを作成します。また、ビルドをクリーン・アップして新しいデプロイメント記述子を生成するためのターゲットを生成します。

また、オプション・パッケージは、weblogic.BuildXMLGenでJava EE共有ライブラリとしてサポートされます。そのため、オプション・パッケージ参照の検索では、アプリケーションおよびそのモジュールのすべてのマニフェストがスキャンされます。オプション・パッケージ参照が見つかると、生成されたbuild.xmlファイル内のcompileおよびappcタスクに追加されます。

たとえば、lib\echolib.jarに配置されているライブラリをオプション・パッケージとして参照する場合、weblogic.BuildXMLGenによって生成されるタスクには次のようなappcタスクが含まれます。

<target name="appc" description="Runs weblogic.appc on your application">
<wlappc source="${dest.dir}" verbose="${verbose}">
<library file="lib\echolib\echolib.jar" />
</wlappc>
</target>

モジュールのcompileおよびappcタスクでも、lib\echolib\echolib.jarライブラリが使用されます。

weblogic.BuildXMLGen構文

weblogic.BuildXMLGenの構文は次のとおりです。

java weblogic.BuildXMLGen [options] <source directory>

オプションには以下があります。

- -help: 標準の使用方法メッセージを出力します。

- -version: バージョン情報を出力します。

- -projectName <project name>: Antプロジェクトの名前。

- -d <directory>: build.xmlが作成されるディレクトリ。デフォルトはカレント・ディレクトリ。

- -file <build.xml>: 生成されたビルド・ファイル名。

- -librarydir <directories>: ディレクトリのカンマ区切りのリストで、共有Java EEライブラリのビルド・ターゲットを作成します。共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

- -username <username>: デプロイ・コマンドのためのユーザー名。

- -password <password>: ユーザー・パスワード。

weblogic.BuildXMLGenを実行した後は、生成されたbuild.xmlファイルを編集して開発環境のプロパティを指定します。編集する必要のあるプロパティについては、次の例を参照してください。

例4-1 build.xmlの編集可能なプロパティ

<!-- BUILD PROPERTIES ADJUST THESE FOR YOUR ENVIRONMENT -->
<property name="tmp.dir" value="/tmp" />
<property name="dist.dir" value="${tmp.dir}/dist"/>
<property name="app.name" value="helloWorldEar" />
<property name="ear" value="${dist.dir}/${app.name}.ear"/>
<property name="ear.exploded" value="${dist.dir}/${app.name}_exploded"/>
<property name="verbose" value="true" />
<property name="user" value="USERNAME" />
<property name="password" value="PASSWORD" />
<property name="servername" value="myserver" />
<property name="adminurl" value="iiop://localhost:7001" />

特に、必ずtmp.dirプロパティを編集して使用するビルド・ディレクトリを示します。デフォルトでは、このbuild.xmlファイルは、アプリケーションの名前にちなんで名付けられたサブディレクトリtmp.dir (上の例では/tmp/helloWorldEar)にプロジェクトをビルドします。

次の例は、build.xmlファイルに作成されたデフォルトの主要なターゲットを示しています。これらのターゲットは、EARソース・ディレクトリでant -projecthelpコマンドを入力することでコマンド・プロンプトで表示できます。

例4-2 デフォルトのbuild.xmlのターゲット

appc                 Runs weblogic.appc on your application
build                Compiles helloWorldEar application and runs appc
clean                Deletes the build and distribution directories
compile              Only compiles helloWorldEar application, no appc
compile.appStartup   Compiles just the appStartup module of the application
compile.appUtils     Compiles just the appUtils module of the application
compile.build.orig   Compiles just the build.orig module of the application
compile.helloEJB     Compiles just the helloEJB module of the application
compile.helloWebApp  Compiles just the helloWebApp module of the application
compile.javadoc      Compiles just the javadoc module of the application
deploy                 Deploys (and redeploys) the entire helloWorldEar application
descriptors          Generates application and module descriptors
ear                  Package a standard J2EE EAR for distribution
ear.exploded         Package a standard exploded J2EE EAR
redeploy.appStartup  Redeploys just the appStartup module of the application
redeploy.appUtils    Redeploys just the appUtils module of the application
redeploy.build.orig  Redeploys just the build.orig module of the application
redeploy.helloEJB    Redeploys just the helloEJB module of the application
redeploy.helloWebApp Redeploys just the helloWebApp module of application
redeploy.javadoc     Redeploys just the javadoc module of the application
undeploy               Undeploys the entire helloWorldEar application

分割開発ディレクトリを使用した複数EARプロジェクトの開発

これまでに説明した分割開発ディレクトリの例と手順は、1つのエンタープライズ・アプリケーションで構成されたプロジェクトを対象としています。複数のエンタープライズ・アプリケーションを同時にビルドする必要があるプロジェクトでは、以降の項で説明するように規約と手順が少し異なります。

注意:

次の項では、MedRecサンプル・アプリケーションを参照します。このサンプル・アプリケーションは、共有ユーティリティ・クラス、サード・パーティJARファイル、および専用クライアント・アプリケーションの3つの異なるエンタープライズ・アプリケーションで構成されています。MedRecソースおよびビルド・ディレクトリは、ORACLE_HOME/user_projects/domain/medrecの下にインストールされています。ORACLE_HOMEは、Oracle WebLogic ServerをインストールしたときにOracleホームとして指定したディレクトリです。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項 を参照してください。

複数のEARで共有されるライブラリとクラスの配置

EARが1つのプロジェクトでは、分割開発ディレクトリの規約はサード・パーティJARファイルをEARソース・ディレクトリのAPP-INF/libディレクトリに維持するよう促します。ただし、EARが複数のプロジェクトでは、同じサード・パーティJARファイルのコピーを各EARソース・ディレクトリのAPP-INF/libディレクトリに保持する必要があります。この場合、ソースJARファイルの複数のコピーが導入され、一部のJARファイルが異なるバージョンである可能性が大きくなり、ソース制御システムに追加のスペースが必要となります。

これらの問題を解決するには、構築スクリプトを編集して、ライブラリを必要とする各EARのビルド・ディレクトリのAPP-INF/libディレクトリにサード・パーティJARファイルをコピーするようにしてみてください。こうすれば、ソース制御システムでJARファイルの1つのコピーとバージョンを維持できるだけでなく、プロジェクトの各EARでJARファイルを使用することができます。

WebLogic Serverと一緒にインストールされるMedRecサンプル・アプリケーションでは、次の図に示されているようにこの戦略を使用します。

図4-9 MedRecの共有JARファイル

MedRecは、プロジェクトの複数のEARで共有されるユーティリティ・クラスでも同様のアプローチをとります。ユーティリティ・クラスのソースをそれらを必要とする各earのスコープの中に置くのではなく、MedRecはユーティリティ・クラスのソースをすべてのEARから独立して維持します。ユーティリティ・クラスをコンパイルした後、構築スクリプトはそれらをアーカイブし、ビルド・ディレクトリのそれらのクラスを使用する各EARのAPP-INF/LIBサブディレクトリにJARをコピーします(図4-9を参照)。

複数のbuild.xmlファイルのリンク

分割開発ディレクトリを使用して複数のEARを開発する場合、各EARプロジェクトは通常それ専用のbuild.xmlファイル(おそらくweblogic.BuildXMLGenの複数回の実行で生成される)を使用します。MedRecのようなアプリケーションでは、アプリケーション・スイートの各EARの下級のbuild.xmlファイルを呼び出すマスターbuild.xmlファイルも使用します。

Antは、マスターbuild.xmlファイル内の他のプロジェクト・ビルド・ファイルを実行できるようにするコア・タスク(antという名前)を提供します。MedRecのマスター・ビルド・ファイルから抜粋した次の行は、その使用方法を示しています。

<ant inheritAll="false" dir="${root}/startupEar" antfile="build.xml"/>

上のタスクは、/startupEarサブディレクトリのbuild.xmlというファイルを実行するようにAntに指示しています。inheritAllパラメータは、マスター・ビルド・ファイルのユーザー・プロパティのみを/startupEarのbuild.xmlファイルに渡すようにAntに指示しています。

MedRecでは、共通のユーティリティ・クラスやクライアント・アプリケーションをビルドするだけでなく、上のタスクに似た複数のタスクを使用してstartupEar、medrecEar、およびphysicianEarアプリケーションをビルドします。

WebLogic Serverアプリケーション開発のベスト・プラクティス

アプリケーション開発には、以下の「ベスト・プラクティス」をお薦めします。

- エンタープライズ・アプリケーションの一部としてアプリケーションをパッケージ化します。「wlpackageを使用したアプリケーションのパッケージ化」を参照してください。

- 分割開発ディレクトリ構造を使用します。「分割開発ディレクトリでのJava EEコンポーネントの配置」を参照してください。

- 配布する場合は、アーカイブ形式でパッケージ化とデプロイを行います。「wlpackageを使用したアプリケーションのパッケージ化」を参照してください。

- 他のほとんどの場合は、展開形式でデプロイするほうが便利です。「アーカイブと展開されたアーカイブ・ディレクトリ」を参照してください。

- テストされていないコードを、製品アプリケーションのサーバーとなるWebLogic Serverインスタンスにデプロイしないでください。未テスト・コードに対しては、編集およびコンパイルに使用しているのと同じコンピュータに開発用WebLogic Serverインスタンスを設定するか、ネットワーク上の別の場所にWebLogic Serverの開発場所を指定してください。

- 開発用コンピュータで開発用WebLogic Serverインスタンスを実行しない場合でも、プログラムをコンパイルするにはWebLogic Server配布キットへのアクセスが必要です。WebLogicまたはJava EE APIを使用してコードをコンパイルするには、Javaコンパイラが配布ディレクトリ内のweblogic.jarファイルとその他のJARファイルにアクセスする必要があります。WebLogic配布キットのファイルをローカルで使用するには、WebLogic Serverを開発用コンピュータにインストールします。

5 分割開発ディレクトリでのアプリケーションのビルド

この章では、WebLogic分割開発ディレクトリ環境を使用してWebLogic Server Java EEアプリケーションをビルドする方法を説明します。

この章の内容は次のとおりです。

- wlcompileを使用したアプリケーションのコンパイル

- wlappcを使用したモジュールおよびアプリケーションのビルド

wlcompileを使用したアプリケーションのコンパイル

wlcompile Antタスクは、javacコンパイラを起動して、アプリケーションのJavaコンポーネントを分割開発ディレクトリ構造にコンパイルするために使用します。wlcompileの基本的な構文では、helloWorldEarサンプルからの次のコマンドのようにソース・ディレクトリとビルド・ディレクトリを識別します。

<wlcompile srcdir="${src.dir}" destdir="${dest.dir}"/>

注意:

デプロイメント記述子は、Java EE 5の時点で必須ではなくなりました。そのため、展開形式のモジュール・ディレクトリにデプロイメント記述子がない場合は、.warまたは.jar接尾辞を使用してモジュール・タイプを指定する必要があります。wlcompileでモジュールを認識できるようにするため、接尾辞は必須でとなっています。.war接尾辞は、そのモジュールがWebアプリケーション・モジュールであることを示します。.jar接尾辞は、そのモジュールがEJBモジュールであることを示します。

このタスクを使用すると発生するイベントの順序を次に示します。

1. wlcompileは、Javaコンポーネントを出力ディレクトリにコンパイルします。

ORACLE_HOMEwlserver\samples\server\examples\build\helloWorldEar\APP-INF\classes\

ここでORACLE_HOMEは、WebLogic Serverのコード・サンプルを構成するディレクトリです。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

2. wlcompileはEJBを構築し、以前に構築されたJavaモジュールを、コンパイラのクラスパスに自動的に含めます。これにより、EJBは手動でクラスパスを編集する必要なしにJavaモジュールを呼び出せます。

3. 最後に、wlcompileはWebアプリケーション内のJavaコンポーネントを、コンパイラのクラスパスにあるEJBおよびJavaモジュールと一緒にコンパイルします。これにより、Webアプリケーションは手動でクラスパスを編集する必要なしに、EJBおよびアプリケーションJavaクラスを参照できるようになります。

includesおよびexcludesプロパティの使用

より複雑なエンタープライズ・アプリケーションでは、wlcompileタスクで自動的に処理できないコンパイルの依存関係がある場合があります。ただし、wlcompileでincludeおよびexcludeオプションを使用して独自の依存関係を実行できます。includesおよびexcludesプロパティはエンタープライズ・アプリケーション・モジュール名(エンタープライズ・アプリケーションのソース・ディレクトリ内のサブディレクトリ名)を受けて、これらをコンパイル処理に含めたり除外したりします。

helloWorldEarサンプルからの次の行は、appStartupモジュールがコンパイルから除外されることを示しています。

<wlcompile srcdir="${src.dir}" destdir="${dest.dir}"
excludes="appStartup"/>

wlcompile Antタスクの属性

表5-1では、wlcompile固有のAntタスクの属性を示します。

表5-1 wlcompile Antタスクの属性

属性

説明

srcdir

ソース・ディレクトリ。

destdir

ビルド/出力ディレクトリ。

classpath

wlcompileで使用されるクラスパスを変更できます。

includes

ビルドから特定のディレクトリを含めることができます。

excludes

ビルドから特定のディレクトリを除外できます。

librarydir

クラスパスに追加するための共有Java EEライブラリのディレクトリを指定します。共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

ネストされたjavacオプション

wlcompile Antタスクは、コンパイル時の動作を変更するネストされたjavacオプションを受け入れます。たとえば、次のwlcompileコマンドは非推奨の警告を無視し、デバッグを有効にします。

<wlcompile srcdir="${mysrcdir}" destdir="${mybuilddir}">
<javac deprecation="false" debug="true"
debuglevel="lines,vars,source"/>
</wlcompile>

コード・コンパイル用のクラスパスの設定

ほとんどのWebLogicサービスはJava EE仕様に基づいており、標準Java EEパッケージを通じてアクセスします。WebLogicサービスを使用するプログラムのコンパイルに必要なWebLogicおよびその他のJavaクラスは、インストールしたWebLogic Serverのlibディレクトリのwls-api.jarファイルにパッケージ化されます。wls-api.jarファイル以外にも、コンパイラのCLASSPATHに以下を組み込みます。

- JDKディレクトリ内のlib\tools.jarファイル、または使用するJava Development Kitに必要なその他の標準Javaクラス。

- Apache Antのexamples.propertyファイル(サンプル環境用)。このファイルについては、samples\server\examples\src\examples\examples.htmlにあるAntを使用してのサンプルの構築に関するWebLogic Serverドキュメントで説明されています。

- サード・パーティJavaツールまたはプログラムがインポートするサービスのクラス。

- コンパイルするプログラムによって参照されるその他のアプリケーション・クラス。

wlcompileとwlappcのライブラリ要素

library要素は、Java EEライブラリおよびオプション・パッケージの作成で説明されているように、アプリケーションのビルドに必要な共有Java EEライブラリを表すモジュールの名前および必要に応じてバージョン情報を定義する要素(オプション)です。「wlappcを使用したモジュールおよびアプリケーションのビルド」で説明されているwlcompileとwlappcの両方で、library要素を使用できます。

名前とバージョン情報は、ライブラリ要素の属性(「表5-2」を参照)として指定されます。

表5-2 ライブラリの属性

属性

説明

file

Java EEライブラリのファイル名(必須)。

name

必須のJava EEライブラリの名前(オプション)。

specificationversion

ライブラリで必要な仕様のバージョン(オプション)。

implementationversion

ライブラリで必要な実装のバージョン(オプション)。

specificationversionとimplementationversionの両方のフォーマットの選択肢については、「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」で説明します。次の出力では、サンプルlibrary参照を示します。

<library file="c:\mylibs\lib.jar" name="ReqLib" specificationversion="920" implementationversion="1.1" />

wlappcを使用したモジュールおよびアプリケーションのビルド

デプロイメント時間を短縮するには、weblogic.appc Javaクラス(またはそれと同等のAntタスクwlappc)を使用して、デプロイ可能なアーカイブ・ファイル(WAR、JARまたはEAR)をプリコンパイルします。weblogic.appcを使用してプリコンパイルを実行すると、特定のヘルパー・クラスが生成され、アプリケーションが現在のJava EE仕様に準拠していることを確認するための検証チェックが実行されます。アプリケーション・レベルのチェックでは、個別のモジュールに対するアプリケーション・レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。

また、オプション・パッケージは、appcでJava EE共有ライブラリとしてサポートされます。そのため、オプション・パッケージ参照の検索では、アプリケーションおよびそのモジュールのすべてのマニフェストがスキャンされます。

wlappcは、weblogic.appcコンパイラに対するAntタスク・インタフェースです。次の項では、wlappcのオプションと使用方法について説明します。weblogic.appcとwlappc Antタスクは、エンタープライズ・アプリケーションを記述するapplication.xmlデプロイメント記述子ファイルに表示されている順番でモジュールをコンパイルします。

wlappc Antタスクの属性

表5-3では、wlappc固有のAntタスクのオプションを示します。これらのオプションは、weblogic.appcコマンド・ライン・オプションと似ていますが、いくつかの点で違いがあります。

注意:

weblogic.appcオプションのリストについては、「weblogic.appcリファレンス」を参照してください。

「wlcompileとwlappcのライブラリ要素」を参照してください。

表5-3 wlappc Antタスクの属性

オプション

説明

print

標準の使用方法メッセージを出力します。

version

appcのバージョン情報を出力します。

output <file>

代替的な出力アーカイブまたはディレクトリを指定します。これが設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。

forceGeneration

EJBおよびJSPクラスを強制的に生成します。このフラグを使用しない場合、クラスが再生成されないことがあります(必要ないと判断された場合)。

lineNumbers

生成されたクラス・ファイルに行番号を追加し、デバッグを支援します。

writeInferredDescriptors

アプリケーションまたはモジュールに、デプロイメント記述子がアノテーション情報と共に格納されることを指定します。

basicClientJar

EJB用に生成されたクライアントJARのデプロイメント記述子を含みません。

idl

EJBリモート・インタフェース用のIDLを生成します。

idlOverwrite

常に既存のIDLファイルを上書きします。

idlVerbose

IDL生成についての詳細な情報を表示します。

idlNoValueTypes

値タイプ、およびそれを含むメソッドと属性を生成しません。

idlNoAbstractInterfaces

抽象インタフェース、およびそれを含むメソッドと属性を生成しません。

idlFactories

値タイプ用にファクトリ・メソッドを生成します。

idlVisibroker

Visibroker 4.5 C++と多少の互換性を持つIDLを生成します。

idlOrbix

Orbix 2000 2.0 C++と多少の互換性を持つIDLを生成します。

idlDirectory <dir>

IDLファイルを作成するディレクトリを指定します(デフォルトでは、ターゲット・ディレクトリまたはJAR)。

idlMethodSignatures <>

IDLコードを生成するトリガーとして使用されるメソッド・シグネチャを指定します。

iiop

EJB用にCORBAのスタブを生成します。

iiopDirectory <dir>

IIOPのスタブ・ファイルを記述するディレクトリを指定します(デフォルトでは、ターゲット・ディレクトリまたはJAR)。

keepgenerated

生成された.javaファイルを保持します。

librarydir

クラスパスに追加するための共有Java EEライブラリのディレクトリを指定します。共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

compiler <java.jdt>

使用するJavaコンパイラを選択します。デフォルトはJDTです。

debug

デバッグ情報をクラス・ファイルにコンパイルします。

optimize

最適化を有効にしてコンパイルします。

nowarn

警告なしでコンパイルします。

verbose

冗長情報を出力してコンパイルします。

deprecation

非推奨となった呼出しについて警告します。

normi

Symantecのsjにフラグを渡します。

runtimeflags

Java実行時にフラグを渡します。

classpath <path>

コンパイル中に使用するクラスパスを選択します。

clientJarOutputDir <dir>

生成されたクライアントjarファイルを配置するディレクトリを指定します。これが設定されていないと、生成されたjarファイルはJVMが実行しているディレクトリと同じ場所に配置されます。

advanced

高度な使用オプションを出力します。

wlappc Antタスクの構文

wlappc Antタスクを使用するための基本的な構文では、宛先ソース・ディレクトリの場所を決定します。このディレクトリには、wlappcでコンパイルするファイルが格納されます。

<wlappc source="${dest.dir}" />

表5-3の2つのオプション(idlおよびidlOrverWrite)を呼び出すwlappc Antタスク・コマンドの例を次に示します。

<wlappc source="${dest.dir}"idl="true" idlOrverWrite="true" />

appcおよびwlappcにおける構文の違い

appcとwlappcでは、構文にいくつかの違いがあります。appcの場合、コマンド内に存在するフラグはBooleanです。wlappcの場合、コマンド内にフラグが存在するということは、引数が必要であることを意味します。

以下はそれを説明するための、同一コマンドの例です。1つ目がappcコマンド、2つ目がwlappcコマンドです。

java weblogic.appc -idl foo.ear
<wlappc source="${dest.dir} idl="true"/>

weblogic.appcリファレンス

次の項では、appcコンパイラのコマンド・ライン・バージョンを使用する方法について説明します。weblogic.appcコマンド・ライン・コンパイラは、記述子で見つかった警告やエラーをすべて報告し、関連のモジュールをすべてEARファイルにコンパイルします。このファイルは、WebLogic Serverにデプロイできます。

weblogic.appcの構文

appcの実行には、次の構文を使用します。

prompt>java weblogic.appc [options] <ear, jar, or war file or directory>

weblogic.appcのオプション

appcの使用可能なオプションは次のとおりです。

オプション

説明

-print

標準の使用方法メッセージを出力します。

-version

appcのバージョン情報を出力します。

-output <file>

代替的な出力アーカイブまたはディレクトリを指定します。これが設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。

-forceGeneration

EJBおよびJSPクラスを強制的に生成します。このフラグを使用しない場合、クラスが再生成されないことがあります(必要ないと判断された場合)。

-library <file[[@name=<string>][@libspecver=<version>][@libimplver=<version|string>]]>

共有Java EEライブラリのカンマ区切りのリスト。省略可能な名前とバージョン文字列情報は、「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」で説明されている形式で指定する必要があります。

-writeInferredDescriptors

アプリケーションまたはモジュールに、デプロイメント記述子がアノテーション情報と共に格納されることを指定します。

-lineNumbers

生成されたクラス・ファイルに行番号を追加し、デバッグを支援します。

-basicClientJar

EJB用に生成されたクライアントJARのデプロイメント記述子を含みません。

-idl

EJBリモート・インタフェース用のIDLを生成します。

-idlOverwrite

常に既存のIDLファイルを上書きします。

-idlVerbose

IDL生成についての詳細な情報を表示します。

-idlNoValueTypes

値タイプ、およびそれを含むメソッドと属性を生成しません。

-idlNoAbstractInterfaces

抽象インタフェース、およびそれを含むメソッドと属性を生成しません。

-idlFactories

値タイプ用にファクトリ・メソッドを生成します。

-idlVisibroker

Visibroker 4.5 C++と多少の互換性を持つIDLを生成します。

-idlOrbix

Orbix 2000 2.0 C++と多少の互換性を持つIDLを生成します。

-idlDirectory <dir>

IDLファイルを作成するディレクトリを指定します(デフォルトでは、ターゲット・ディレクトリまたはJAR)。

-idlMethodSignatures <>

IDLコードを生成するトリガーとして使用されるメソッド・シグネチャを指定します。

-iiop

EJB用にCORBAのスタブを生成します。

-iiopDirectory <dir>

IIOPのスタブ・ファイルを記述するディレクトリを指定します(デフォルトでは、ターゲット・ディレクトリまたはJAR)。

-keepgenerated

生成された.javaファイルを保持します。

-compiler <javac>

使用するJavaコンパイラを選択します。

-g

デバッグ情報をクラス・ファイルにコンパイルします。

-O

最適化を有効にしてコンパイルします。

-nowarn

警告なしでコンパイルします。

-verbose

冗長情報を出力してコンパイルします。

-deprecation

非推奨となった呼出しについて警告します。

-normi

Symantecのsjにフラグを渡します。

-J<option>

Java実行時にフラグを渡します。

-classpath <path>

コンパイル中に使用するクラスパスを選択します。

-clientJarOutputDir <dir>

生成されたクライアントjarファイルを配置するディレクトリを指定します。これが設定されていないと、生成されたjarファイルはJVMが実行しているディレクトリと同じ場所に配置されます。

-advanced

高度な使用オプションを出力します。

6 分割開発ディレクトリからのデプロイメントとパッケージ化

この章では、WebLogic分割開発ディレクトリ環境を使用してWebLogic Server Java EEアプリケーションをデプロイする方法を説明します。

この章の内容は次のとおりです。

- wldeployを使用したアプリケーションのデプロイメント

- wlpackageを使用したアプリケーションのパッケージ化

wldeployを使用したアプリケーションのデプロイメント

wldeployタスクは、分割開発ディレクトリから直接デプロイする簡単な手段を提供します。wlcompileは、weblogic.Deployerディレクトリとほとんど同じ引数を提供します。分割開発ディレクトリからデプロイするには、次のように、ビルド・ディレクトリの位置をデプロイ可能なファイルとして指定するだけです。

<wldeploy user="${user}" password="${password}"
action="deploy" source="${dest.dir}"
name="helloWorldEar" />

上のタスクは、weblogic.BuildXMLGenを使用してbuild.xmlファイルを作成すると自動的に作成されます。

詳細なコマンドのリファレンスについては、wldeploy Antタスクのリファレンスを参照してください。

wlpackageを使用したアプリケーションのパッケージ化

wlpackage Antタスクは、ソース・ディレクトリとビルド・ディレクトリの両方の内容を使用して、デプロイ可能なアーカイブ・ファイル(.EARファイル)、またはエンタープライズ・アプリケーションを表す展開アーカイブ・ディレクトリ(展開.EARディレクトリ)を作成します。wlpackageは、評価、テスト、パフォーマンスのプロファイリング、または本番デプロイメントを目的として別のグループまたは個人にアプリケーションを配布する際に使用します。

アーカイブと展開されたアーカイブ・ディレクトリ

本番用の場合は、展開された(アーカイブされていない)ディレクトリ形式でエンタープライズ・アプリケーションをデプロイすると便利です。これは、エンタープライズ・アプリケーションの一部としてパッケージ化されたスタンドアロンのWebアプリケーション、EJB、およびコネクタにも当てはまります。この形式を使用すると、アプリケーション全体のアーカイブを展開してから、編集および再アーカイブするのではなく、展開ディレクトリの中でファイルを直接更新できます。『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメントするファイルのパッケージ化に関する項で説明されているように、展開されたアーカイブ・ディレクトリを使用すると、他にも利点があります。

アプリケーションを1つのアーカイブ・ファイルにパッケージ化することもできます。その方法は、モジュールとアプリケーションを配布用にパッケージ化する際に便利です。アーカイブ・ファイルは簡単にコピーでき、展開されたディレクトリよりも処理するファイル数が少なく、ファイル圧縮によってディスク・スペースも節約できます。

Javaクラスローダーは、クラスパス内のディレクトリを検索するのと同じように、JARファイル内のJavaクラス・ファイル(および他のファイル・タイプ)を検索できます。クラスローダーはディレクトリまたはJARファイルを検索できるので、JAR (アーカイブ)ファイルまたは展開された(アーカイブされていない)ディレクトリのどちらとしてでも、Java EEモジュールをWebLogic Serverにデプロイできます。

wlpackage Antタスクの例

本番環境において、wlpackage Antタスクは、分割開発ディレクトリ・アプリケーションをWebLogic Serverにデプロイ可能な従来のEARファイルとしてパッケージ化するのに使用します。MedRecサンプルの続きで、アプリケーションのパッケージ化は次のように行えます。

<wlpackage tofile="\physicianEAR\physicianEAR.ear"
srcdir="\physicianEAR"
destdir="\build\physicianEAR"/>
<wlpackage todir="\physicianEAR\explodedphysicianEar"
srcdir="\src\physicianEAR"
destdir="\build\physicianEAR" />

wlpackage Antタスクの属性のリファレンス

次の表では、wlpackage Antタスクの属性について説明します。

表6-1 wlpackage Antタスクの属性

属性

説明

データ型

必須?

tofile

wlpackage Antタスクによってパッケージ化された分割開発ディレクトリ・アプリケーションのEARアーカイブ・ファイルの名前。

文字列

tofileまたはtodirのどちらかの属性を指定する必要があります。

todir

wlpackage Antタスクによってパッケージ化された分割開発ディレクトリ・アプリケーションの展開ディレクトリの名前。

文字列

tofileまたはtodirのどちらかの属性を指定する必要があります。

srcdir

分割開発ディレクトリ・アプリケーションのソース・ディレクトリを指定します。

ソース・ディレクトリには、プロジェクトのすべての編集可能なファイル(Javaソース・ファイル、編集可能な記述子ファイル、JSP、静的コンテンツなど)が格納されます。

文字列

はい。

destdir

分割開発ディレクトリ・アプリケーションのビルド・ディレクトリを指定します。

既に、ソース・ディレクトリに対してwlcompile Antタスクを実行し、必要なコンポーネントがビルド・ディレクトリに生成されていることが前提となります。必要なコンポーネントとしては、コンパイル済みのJavaクラス、生成されたデプロイメント記述子などがあります。

文字列

はい。

7 本番再デプロイメント用アプリケーションの開発

この章では、WebLogic Server で本番再デプロイメント戦略を使用してアプリケーションをプログラミングおよび管理する方法について説明します。

この章の内容は次のとおりです。

- 本番再デプロイメントとは

- サポートされているアプリケーションとサポートされていないアプリケーションの種類

- プログラミングの要件と規約

- アプリケーションのバージョンの割当て

- アプリケーションのアップグレードによる本番再デプロイメントの使用

- バージョン情報へのアクセス

本番再デプロイメントとは

本番再デプロイメントを使用すると、デプロイされたアプリケーションを停止せずに(アプリケーションのクライアントへの可用性を中断することなく)、本番環境でアプリケーションの新しいバージョンを再デプロイできます。本番再デプロイメントのしくみは、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイすることです。WebLogic Serverは、新しいクライアント・リクエストのみが新しいバージョンに転送されるように、自動的にクライアント接続を管理します。再デプロイメント時にアプリケーションにすでに接続していたクライアントは、作業が完了するまで、より古いリタイア中のバージョンのアプリケーションを使用し続けます。

詳細は、「本番再デプロイメントを使用したアプリケーションのアップグレード」を参照してください。

サポートされているアプリケーションとサポートされていないアプリケーションの種類

本番再デプロイメントでサポートされるのはHTTPクライアントとRMIクライアントのみです。開発および設計段階において、サポートされないクライアントが、本番再デプロイメントを使用しているアプリケーションにアクセスしないようにしておく必要があります。WebLogic Serverはサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、本番再デプロイメント時にはサポートされないクライアント接続を保護しません。

エンタープライズ・アプリケーションには、サポートされているJava EEモジュールであれば、どのタイプでも格納できます。エンタープライズ・アプリケーションには、アプリケーション・スコープのJMSモジュールやJDBCモジュールも格納できます。

エンタープライズ・アプリケーションにJCAリソース・アダプタ・モジュールが含まれる場合、モジュールは次の条件を満たす必要があります。

- JCA 1.5に準拠している必要があります

- weblogic.connector.extensions.Suspendableインタフェースを実装する必要があります

- enable-access-outside-appがfalse(デフォルト値)に設定された状態で、アプリケーション・スコープ方式で使用される必要があります

新しいバージョンのEARのリソース・アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース・アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンのEAR全体がリタイアされます。

リソース・アダプタの本番再デプロイメント要件の一覧については、『Oracle WebLogic Serverリソース・アダプタの開発』の本番再デプロイメントに関する項を参照してください。

追加アプリケーション・サポート

本番再デプロイメントでは、グローバルなJMS宛先からのインバウンドJMSメッセージによってアクセスされるエンタープライズ・アプリケーションおよび1つまたは複数のメッセージドリブンBeanをコンシューマとして使用するエンタープライズ・アプリケーションもサポートされます。この種類のアプリケーションの場合、WebLogic Serverは、リタイアされた旧バージョンのアプリケーションのメッセージドリブンBeanを保留してから、新しいバージョンのメッセージドリブンBeanをデプロイします。グローバルJMS宛先に対してJMS APIを使用するJMSコンシューマの場合、本番再デプロイメントはサポートされません。メッセージドリブンBeanが、保留中にパブリッシュされたメッセージなど、トピックからパブリッシュされたメッセージをすべて受信する必要がある場合は、恒久サブスクライバを使用します。

プログラミングの要件と規約

WebLogic Serverは、本番再デプロイメントを実行する際に、アプリケーションの2つのインスタンスを同時にデプロイします。アプリケーションの複数のインスタンスがWebLogic Serverドメインに共存できるようにするには、一定のプログラミング規約に従う必要があります。次の項では、本番再デプロイメントで必須のプログラミング規約について説明します。

アプリケーションが自己完結型であることが必要

インプレース再デプロイメント戦略を使用するアプリケーションは、リソースの使用に際して自己完結型となるのが最善の方法です。つまり、バージョン管理されたアプリケーションの場合は通常、グローバル・リソースではなく、アプリケーション・スコープのJMSおよびJDBCリソースを可能な限り使用します。

アプリケーションがグローバル・リソースを使用する必要がある場合、アプリケーションが複数のインスタンスによる安全な同時アクセスをサポートするようにプログラミングする必要があります。これは、アプリケーションが外部(別にデプロイされた)アプリケーションまたは外部プロパティ・ファイルを使用する場合にも当てはまります。WebLogic Serverでは、バージョン管理されたアプリケーションでグローバル・リソースを使用できない仕様にはなっていないので、リソースへのアクセスが安全な方法で行われるようにする必要があります。

バージョン管理されたアプリケーション内からグローバルJNDIリソースをルックアップすると、警告メッセージが表示されます。このチェックを無効にするには、JNDIルックアップ時にJNDI環境プロパティweblogic.jndi.WLContext.ALLOW_GLOBAL_RESOURCE_LOOKUPをtrueに設定します。

同様に、外部アプリケーションをルックアップしたときに警告が表示されないようにするには、JNDI環境プロパティweblogic.jndi.WLContext.ALLOW_EXTERNAL_APP_LOOKUPをtrueに設定します。

バージョン管理されているアプリケーションが現在のバージョンのJNDIツリーにデフォルトでアクセスすること

WebLogic Serverは、JMSおよびJDBCアプリケーション・モジュールなどのアプリケーション・スコープのリソースを、アプリケーションで使用可能なローカルJNDIツリーにバインドします。バージョン管理されていないアプリケーションと同様に、バージョン管理されているアプリケーションは、このローカル・ツリーからアプリケーション・スコープのリソースを直接ルックアップできます。アプリケーション・スコープJMSモジュールには、JMS APIまたはメッセージドリブンBeanなどのサポートされているJMSインタフェースを介してアクセスできます。

グローバルJNDIツリーにバインドされているアプリケーション・モジュールには、同じアプリケーション・バージョン内からのみアクセスする必要があります。WebLogic Serverは、バージョン管理されているアプリケーションでデプロイされたグローバル・リソースに対してバージョン対応JNDIルックアップとバインドを実行します。デフォルトでは、グローバル・リソースに対する内部JNDIルックアップは、同じバージョンのアプリケーションに対するバインドを返します。

現在のバージョンのアプリケーションが見つからない場合は、JNDI環境プロパティweblogic.jndi.WLContext.RELAX_VERSION_LOOKUPを使用して、同じバージョンではなく、現在アクティブなバージョンのアプリケーションからバインドを返します。

注意:

ルックアップしている新旧バージョンのリソースが互換可能であることが明らかな場合にのみ、weblogic.jndi.WLContext.RELAX_VERSION_LOOKUPをtrueに設定します。

セキュリティ・プロバイダに互換性があることが必要

アプリケーションで使用するセキュリティ・プロバイダは、WebLogic ServerアプリケーションのバージョニングSSPIをサポートする必要があります。デフォルトのWebLogic Serverセキュリティ・プロバイダ(許可、ロール・マッピング、および資格証明マッピング・プロバイダ)は、アプリケーション・バージョニングSSPIをサポートしています。

アプリケーションがバージョン識別子を指定することが必要

本番再デプロイメントを使用するには、アプリケーションの現在のデプロイされているバージョンと更新されたバージョンの双方が一意のバージョン識別子を指定する必要があります。「アプリケーションのバージョンの割当て」を参照してください。

アプリケーションが名前と識別子にアクセスできることが必要

バージョン管理されたアプリケーションは、各バージョンで共通しているアプリケーション名とアプリケーションのバージョンごとに変わるアプリケーション識別子の両方をプログラムで取得できます。デプロイされたバージョンに関係なく、アプリケーション名を参照するエラー・メッセージまたは基本表示には、アプリケーション名を使用します。アプリケーションのデプロイされたバージョンに対してアプリケーションが一意の識別子を提供する必要がある場合は、アプリケーションIDを使用します。名前と識別子を提供するMBean属性の詳細は、「バージョン情報へのアクセス」を参照してください。

クライアント・アプリケーションが可能な限り同じバージョンを使用することが必要

「本番再デプロイメントとは」の説明にあるとおり、WebLogic Serverは、進行中のクライアントの全作業が完了するまで、クライアント・アプリケーションのリクエストを同じバージョンのアプリケーションにルーティングします。ただし、アプリケーションのバージョンがタイムアウト期間によってリタイアされるか、デプロイされていない場合、クライアントのリクエストは、アクティブなバージョンのアプリケーションにルーティングされます。つまり、指定したアプリケーション・バージョンに対するクライアントの関連付けは、best-effortに基づいて維持されます。

リクエストの処理時に別のアプリケーションに再帰的にアクセスするクライアント・アプリケーションの場合、この性質は問題となる場合があります。WebLogic Serverは、再帰的にアクセスされたアプリケーションの同じバージョンにリクエストをディスパッチしようとしますが、中間のアプリケーション・バージョンが手動でデプロイされていないこと、およびタイムアウト期間後であることを保証しません。厳密なバージョン要件を持つ関連アプリケーションのグループがある場合は、本番再デプロイメント時のバージョンの一貫性を維持するために、全アプリケーションをまとめてパッケージ化することをお薦めします。

アプリケーションのバージョンの割当て

アプリケーションのMANIFEST.MFのバージョン識別子を指定し、新しいアプリケーションがデプロイメント用にリリースされるたびにバージョンを自動的にインクリメントするように指定することをお薦めします。これにより、管理者またはデプロイヤがアプリケーションを再デプロイするたびに、本番再デプロイメントが実行されるようになります。

テスト目的で、デプロイヤが、デプロイメントおよび再デプロイメント時にバージョン識別子をアプリケーションに割り当てることもできます。『Oracle WebLogic Serverへのアプリケーションへのデプロイ』のデプロイメントおよび再デプロイメント中のバージョン識別子の割当てに関する項を参照してください。

アプリケーションのバージョンの規約

WebLogic Serverは、MANIFEST.MFファイルのWeblogic-Application-Versionプロパティの値からアプリケーション・バージョンを取得します。バージョン文字列には最大で215文字まで指定できます。表7-1に示す有効な文字以外は使用できません。

表7-1 有効な文字と無効な文字

有効なASCII文字

無効なバージョン構成

a-z

..

A-Z

.

0-9

他の文字と組み合わせたピリオド(「.」)、アンダースコア(「_」)、ハイフン(「-」)

たとえば、次のマニフェスト・ファイルの内容は、バージョン「v920.beta」のアプリケーションを示します。

Manifest-Version: 1.0
Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.)
Weblogic-Application-Version: v920.beta

アプリケーションのアップグレードによる本番再デプロイメントの使用

WebLogic Server 9.2以降へのデプロイメント用にアプリケーションをアップグレードする場合、AppDeploymentMBeanから取得されたName属性は、デプロイされたアプリケーション名およびアプリケーションのバージョン文字列で構成された一意のアプリケーション識別子を戻します。デプロイされたアプリケーション名が必要なアプリケーションは、Name属性ではなく、新しいApplicationName属性を使用する必要があります。一意の識別子が必要なアプリケーションは、Name属性とApplicationIdentifier属性のどちらでも使用できます(「バージョン情報へのアクセス」を参照)。

バージョン情報へのアクセス

アプリケーション・コードは、新しいMBean属性を使用して、表示やロギングなどに使用するバージョン情報を取得できます。次の表では、ApplicationMBeanで利用できる読取り専用属性を示します。

表7-2 ApplicationMBeanの読取り専用のバージョン属性

属性名

説明

ApplicationName

アプリケーションのデプロイメント名を表す文字列

VersionIdentifier

同じアプリケーションのすべてのバージョンの中から、現在のアプリケーションのバージョンを一意に識別する文字列

ApplicationIdentifier

デプロイされたすべてのアプリケーションおよびバージョンの中から、現在のアプリケーションのバージョンを一意に識別する文字列

ApplicationRuntimeMBeanでも、新しい読取り専用属性のバージョン情報を利用できます。次の表を参照してください。

表7-3 ApplicationRuntimeMBeanの読取り専用のバージョン属性

属性名

説明

ApplicationName

アプリケーションのデプロイメント名を表す文字列

ApplicationVersion

アプリケーションのバージョンを表す文字列

ActiveVersionState

アクティブなアプリケーション・バージョンの現在の状態を示す整数。アクティブなバージョンの有効な状態は次のとおりです。

- ACTIVATED - アプリケーションの1つまたは複数のモジュールがアクティブで、新しいクライアント・リクエストで使用可能になっていることを示します。

- PREPARED - WebLogic Serverが、アプリケーションの1つまたは複数のモジュールを準備しているものの、まだアクティブになっていないことを示します。

- UNPREPARED - アプリケーションのどのモジュールも準備されておらず、アクティブになっていないことを示します。

詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください。

管理者が本番再デプロイメント・プロセスを逆転させる場合もあるため、現在アクティブなバージョンが、最後にデプロイされたバージョンに対応しているとは限りません。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番再デプロイメント・プロセスのロールバックに関する項を参照してください。

8 Java EEアノテーションと依存関係インジェクションの使用

この章では、Java EEメタデータ・アノテーションおよび依存関係インジェクション(DI)について説明します。

この章の内容は次のとおりです。

- アノテーションの処理

- リソースの依存関係インジェクション

- 標準のJDKアノテーション

- 標準のセキュリティ関連JDKアノテーション

アノテーションの処理

Java EEアノテーションの使用により、標準のapplication.xmlおよびweb.xmlデプロイメント記述子は省略可能になりました。このJava EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナ用のJDKアノテーション機能を使用します(http://docs.oracle.com/javaee/6/api/を参照)。

アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子にかわるものです。

アノテーションの解析

アプリケーション・コンポーネントでは、必要なものの定義にアノテーションを使用できます。アノテーションを使用すると、デプロイメント記述子を扱う必要がなくなります。アノテーションにより、アプリケーション・コンポーネントの開発は簡略化されます。引続きデプロイメント記述子により、アノテーションで定義した値をオーバーライドすることもできます。アノテーション使用の一例としては、依存関係インジェクション(DI)を必要とするフィールドまたはメソッドの定義が挙げられます。アノテーションは、EJBやサーブレットのような、POJO (プレーンな従来型Javaオブジェクト)コンポーネント・クラスに対して定義されます。

フィールドまたはメソッド上のアノテーションでは、「リソースの依存関係インジェクション」に記載のとおり、フィールドやメソッドが注入を必要とすることを宣言できます。また、クラス自体にアノテーションを適用することもできます。クラス・レベルのアノテーションは、アプリケーション・コンポーネントの環境内でエントリを宣言しますが、リソースの注入にはつながりません。むしろ、アプリケーション・コンポーネントでは、JNDIまたはコンポーネント・コンテキスト・ルックアップ・メソッドを使用してエントリをルックアップすることが前提となっています。アノテーションをクラスに適用する際には、JNDI名および環境エントリ・タイプを明示的に指定する必要があります。

アノテーション構成のデプロイメント表示

Java EE開発API [JSR88]を使用すると、開発者はデプロイメント記述子を調べることができます。たとえば、デプロイメント記述子のないEJBモジュールの場合を考えます。このモジュールには、アノテーションを使用するEJBとして宣言されたクラスがあることが前提です。Session Helperのユーザーは、引き続きモジュールをデプロイメント記述子がある場合と同様に扱えます。したがって、開発者は構成情報を修正でき、その情報はデプロイメント・プランに書き出されます。デプロイメント中はこれらのプランが尊重され、アノテーションからの情報をオーバーライドします。

アノテーション付きクラスのコンパイル

WebLogic Serverユーティリティappc (およびそれに対応するAnt wlappcとAppmerge)では、メタデータ・アノテーションをサポートしています。appmergeおよびappcユーティリティは、アプリケーションまたはモジュールを入力として取り、それらを処理して、それぞれ出力アプリケーションまたはモジュールとして生成します。-writeInferredDescriptorsフラグと一緒に使用すると、出力アプリケーションまたはモジュールには、アノテーション情報と共にデプロイメント記述子が含まれます。また記述子では、出力アプリケーションまたはモジュールが直接デプロイされるのであれば、実行の必要なアノテーション処理はないため、metadata-complete属性がtrueに設定されます。ただし、以前に処理されたアプリケーションまたはモジュールでこれらのツールが呼び出された場合、metadata-complete属性がtrueに設定されていると、appmergeおよびappcがアノテーションの処理について制限を受けます。

そのような場合、.orig接尾辞によって、本来の記述子を保持する必要があります。出力アプリケーションに対してアノテーションの処理を再適用する場合、開発者は記述子を復元して、もう一度-writeInferredDescriptorsフラグを使用する必要があります。appmergeまたはappcが、標準のデプロイメント記述子の存在しないエンタープライズ・アプリケーションで、-writeInferredDescriptorsとともに使用されると、記述子が生成され、Java EE仕様の推論ルールに基づき、書き出されます。

appcの使用の詳細は、「weblogic.appcリファレンス」を参照してください。appmergeの使用の詳細は、「weblogic.appmergeを使用したライブラリの結合」を参照してください。

アノテーションの動的な更新

デプロイされたモジュールは、updateデプロイメント操作を使用して更新できます。そのような更新において、デプロイメント記述子または更新されたクラスに変更があった場合、コンテナでは新しいデプロイメント記述子を処理する一方で、アノテーション情報を再度検討する必要があります。

コンテナでは、記述子フレームワークの2フェーズの更新メカニズムを使用して、現在の記述子と提案されている記述子の相違点を確認します。このメカニズムはまた、動的でないプロパティに変更があった場合も、コンテナにそれを通知します。その後、コンテナはそのような動的でない変更を、独自の特定的な方法によって処理します。コンテナでは、正しい参照との相違点を確実に発見するため、提案された記述子に対しアノテーション処理を実行する必要があります。

同様に、モジュールのクラスの一部は、更新処理中に更新可能です。これらのクラスがアノテーションを通じて構成情報に影響を与えることがあり得るとわかった場合、コンテナは変更が加えられることを回避します。

リソースの依存関係インジェクション

依存関係インジェクション(DI)を使用することで、アプリケーション・コンポーネントで外部リソースおよび構成パラメータに対する依存関係をアノテーションを介して宣言できます。コンテナはこれらのアノテーションを読み込み、リソースまたは環境エントリをアプリケーション・コンポーネントに注入します。依存関係インジェクションは、リソースのルックアップをjavaxインタフェースまたはJNDI APIを使用して行うことにかわる、非常に簡単なプログラミング方法です。

アプリケーション・コンポーネントのフィールドまたはメソッドには、@Resourceアノテーションを付けることができます。コンテナは、必要に応じて環境エントリを解放し、インジェクション・フィールドまたはメソッドに使用されるプリミティブ型に一致させます。例8-1は、アプリケーション・コンポーネントで@Resourceアノテーションを使用して環境エントリを宣言する方法を示しています。

例8-1 環境エントリの依存関係インジェクション

// fields

// The maximum number of tax exemptions, configured by the Deployer.
@Resource int maxExemptions;
// The minimum number of tax exemptions, configured by the Deployer.
@Resource int minExemptions;

…..
}

上記のコードでは、@resourceアノテーションは名前を指定していません。したがって、コンテナは<class-name>/maxExemptionsというenv-entry名を探し、そのエントリの値をmaxExemptions変数に注入します。フィールドまたはメソッドには、任意のアクセス修飾子(public、privateなど)を指定できます。アプリケーション・クライアントのメイン・クラス以外のすべてのクラスについて、フィールドまたはメソッドは、静的なものとする必要があります。アプリケーション・クライアントは、Java EEアプリケーションと同じライフサイクルを使用するため、アプリケーション・クライアントのメイン・クラスのインスタンスが、アプリケーション・クライアントのコンテナによって作成されることはありません。その代わり、静的なmainメソッドが呼び出されます。アプリケーション・クライアントのメイン・クラスに対する注入をサポートするため、注入用にアノテーションを付けられるフィールドまたはメソッドは静的であることが必要です。

アプリケーション・ライフサイクル・アノテーション・メソッド

アプリケーション・コンポーネントでは、すべてのリソースが注入された後で、独自に初期化を実行する必要がある場合があります。このケースをサポートするため、クラスのメソッドの1つに、@PostConstructアノテーションを付けることができます。このメソッドは、すべての注入が行われた後、クラスのサービスが開始される前に呼び出されます。このメソッドは、クラスが注入されるリソースをリクエストしていなくても呼び出されます。同様に、コンテナによってライフサイクルを管理されているクラスでは、クラスのサービスが終了し、これ以上はコンテナによって使用されなくなったときに呼び出される、1つのメソッドに@PreDestroyアノテーションを適用できます。クラス階層構造内の各クラスに、@PostConstructメソッドと@PreDestroyメソッドを指定できます。

メソッドの呼出し順は、クラス階層構造における順序に一致しており、スーパークラスに対するメソッドが、サブクラスに対するメソッドよりも前に呼び出されます。Java EE側からは、これらのJava EEクライアントのライフサイクル・メソッドの呼び出しに関与しているのは、アプリケーション・クライアント・コンテナのみです。Java EEクライアントのライフサイクル・メソッドは静的であることが必要です。Java EEクライアントは、@PostConstructコールバックをサポートするのみです。

標準のJDKアノテーション

この項では、以下のアノテーションのリファレンス情報を提供します。

- javax.annotation.PostConstruct

- javax.annotation.PreDestroy

- javax.annotation.Resource

- javax.annotation.Resources

WebLogic Server Enterprise JavaBeansに対するEJB固有のアノテーションの詳細は、『Oracle WebLogic Server Enterprise JavaBeansの開発』を参照してください。

WebLogic Serverアプリケーションに対するWebコンポーネント固有のアノテーションの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のWebコンポーネント用のWebLogicアノテーションに関する項を参照してください。

javax.annotation.PostConstruct

ターゲット: メソッド

初期化を実行するために、依存関係インジェクションが完了した後、1番目のビジネス・メソッドを呼び出す前にアプリケーション・コンポーネントから呼び出す必要のあるライフサイクル・コールバック・メソッドを指定します。このメソッドは、すべての注入が行われた後、クラスのサービスが開始される前に呼び出されます。このメソッドは、クラスが注入されるリソースをリクエストしていなくても呼び出されます。

依存関係インジェクションを含むすべてのコンポーネントには、@PostConstructメソッドを指定する必要があります。

このアノテーションは、コンポーネント内の1つのメソッドにのみ付けることができます。

@PostConstructアノテーションを付けるメソッドは、以下の要件を満たす必要があります。

- メソッドにパラメータを指定してはいけません - ただし、EJBインターセプタの場合にかぎり、EJB仕様で定義されているとおりjavax.interceptor.InvocationContextオブジェクトを取ります。

- メソッドの戻り値の型がvoidでなければなりません。

- 検査済みの例外をスローしてはいけません。

- public、protected、package private、またはprivateにすることは可能です。

- アプリケーション・クライアントの場合を除いて、メソッドはstaticであってはいけません。

- メソッドはfinalでもnon-finalでもかまいませんが、EJBの場合はnon-finalとする必要があります。

- メソッドが未検査の例外をスローした場合、クラスはサービスを開始してはいけません。EJBの場合、PostConstructアノテーションの付いたメソッドは、beanインスタンスが破棄される前に例外およびクリーン・アップを処理できます。

このアノテーションには、属性はありません。

javax.annotation.PreDestroy

ターゲット: メソッド

アプリケーション・コンポーネントがコンテナによって破棄されようとしていることを通知するライフサイクル・コールバック・メソッドを指定します。通常、このアノテーションは、クラスが保持しているリソースを解放するメソッドに適用します。

このアノテーションは、Beanクラス内の1つのメソッドにのみ付けることができます。

@PreDestroyアノテーションを付けるメソッドは、以下の要件を満たす必要があります。

- メソッドにパラメータを指定してはいけません - ただし、EJBインターセプタの場合にかぎり、EJB仕様で定義されているとおりjavax.interceptor.InvocationContextオブジェクトを取ります。

- メソッドの戻り値の型がvoidでなければなりません。

- 検査済みの例外をスローしてはいけません。

- public、protected、package private、またはprivateにすることは可能です。

- アプリケーション・クライアントの場合を除いて、メソッドはstaticであってはいけません。

- メソッドはfinalでもnon-finalでもかまいませんが、EJBの場合はnon-finalとする必要があります。

- メソッドが未検査の例外をスローした場合、クラスはサービスを開始してはいけません。EJBの場合、PreDestroyアノテーションの付いたメソッドは、beanインスタンスが破棄される前に例外およびクリーン・アップを処理できます。

このアノテーションには、属性はありません。

javax.annotation.Resource

ターゲット: クラス、メソッド、フィールド

外部リソース(JDBCデータ・ソース、JMS宛先、接続ファクトリなど)への依存関係を指定します。

このアノテーションをフィールドまたはメソッドに指定すると、Beanの初期化時に、リクエストされたリソースのインスタンスがBeanに注入されます。このアノテーションをクラスに適用すると、コンポーネントが実行時にルックアップするリソースが宣言されます。

属性

表8-1 javax.annotation.Resourceアノテーションの属性

名前

説明

データ型

必須?

name

リソースのJNDI名を指定します。

@Resourceアノテーションをフィールドに適用した場合は、クラス名で修飾されたフィールド名がname属性のデフォルト値になります。メソッドに適用した場合は、そのメソッドに対応するコンポーネント・プロパティ名をクラス名で修飾した名前がデフォルト値になります。このアノテーションをクラスに適用した場合はデフォルト値がないため、この属性を指定する必要があります。

文字列

いいえ

type

リソースのJavaデータ型を指定します。

@Resourceアノテーションをフィールドに適用した場合は、そのフィールドの型がtype属性のデフォルト値になります。メソッドに適用した場合は、コンポーネント・プロパティの型がデフォルトになります。クラスに適用した場合はデフォルト値がないため、この属性を指定する必要があります。

Class

いいえ

authenticationType

このリソースに使用する認証タイプを指定します。

この属性の有効な値は以下のとおりです。

- AuthenticationType.CONTAINER

- AuthenticationType.APPLICATION

デフォルト値はAuthenticationType.CONTAINERです

AuthenticationType

いいえ

shareable

リソースを、このコンポーネントと他のコンポーネントとの間で共有できるかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はtrueです。

ブール

いいえ

mappedName

コンポーネント参照をマップするWebLogic Server固有の名前を指定します。

ただし、WebLogicデプロイメント記述子ファイル内でJNDI名を指定しない場合、ルックアップされるJNDI名としてmappedNameの値が常に使用されます。例:

@Resource(mappedName = "http://www.bea.com";)

URL url;

@Resource(mappedName="customerDB")

DataSource db;

@Resource(mappedName = "jms/ConnectionFactory")

ConnectionFactory connectionFactory;

@Resource(mappedName = "jms/Queue")

Queue queue;

つまり、MappedNameは他(通常はWebLogicデプロイメント記述子ファイル)で指定されているJNDI名がない場合のみ、JNDI名として扱われます。

文字列

いいえ

description

リソースの説明を指定します。

文字列

いいえ

javax.annotation.Resources

ターゲット: クラス

@Resourceアノテーションの配列を指定します。アノテーションの繰返しは許可されていないため、Resourcesアノテーションは、複数のリソース宣言のコンテナとして機能します。

属性

表8-2 javax.annotation.Resourcesアノテーションの属性

名前

説明

データ型

必須?

value

@Resourceアノテーションの配列を指定します。

Resource[]

はい

標準のセキュリティ関連JDKアノテーション

この項では、以下のアノテーションのリファレンス情報を提供します。

- javax.annotation.security.DeclareRoles

- javax.annotation.security.DenyAll

- javax.annotation.security.PermitAll

- javax.annotation.security.RolesAllowed

- javax.annotation.security.RunAs

javax.annotation.security.DeclareRoles

ターゲット: クラス

Java EEコンテナで使用されるセキュリティ・ロールを定義します。

通常、このアノテーションは、アノテーションを付けたクラスのメソッド内から(たとえばisUserInRoleメソッドを使用して)テストできるロールを定義するために使用します。また、クラスまたはクラスのメソッドで@RolesAllowedアノテーションを使用している場合はロールが暗黙的に宣言されますが、このアノテーションを使用することでそれらのロールを明示的に宣言できます。

セキュリティ・ロールは、WebLogic ServerでWebLogic Server管理コンソールを使用して作成できます。詳細は、「セキュリティ・ロールの管理」を参照してください。

属性

表8-3 javax.annotation.security.DeclareRolesアノテーションの属性

名前

説明

データ型

必須?

value

Java EEコンテナ内で使用するセキュリティ・ロールの配列を指定します。

String[]

はい

javax.annotation.security.DenyAll

ターゲット: メソッド

このアノテーションを付けたメソッドへのアクセスを、どのセキュリティ・ロールにも許可しないことを指定します。つまり、このメソッドは、Java EEコンテナでの実行から除外されます。

このアノテーションには、属性はありません。

javax.annotation.security.PermitAll

ターゲット: メソッド

このアノテーションを付けたメソッドへのアクセスを、WebLogic Serverに定義されているすべてのセキュリティ・ロールに許可することを指定します。

このアノテーションには、属性はありません。

javax.annotation.security.RolesAllowed

ターゲット: クラス、メソッド

Java EEコンテナ内のメソッドにアクセスできるセキュリティ・ロールのリストを指定します。

クラス・レベルで指定した場合は、アプリケーション・コンポーネント内のすべてのメソッドに適用されます。メソッド・レベルで指定した場合は、そのメソッドにのみ適用されます。このアノテーションをクラス・レベルとメソッド・レベルの両方で指定した場合は、クラス・レベルの値がメソッド・レベルの値によってオーバーライドされます。

セキュリティ・ロールは、WebLogic ServerでWebLogic Server管理コンソールを使用して作成できます。詳細は、「セキュリティ・ロールの管理」を参照してください。

属性

表8-4 javax.annotation.security.RolesAllowedアノテーションの属性

名前

説明

データ型

必須?

value

Java EEコンテナのメソッドにアクセスできるセキュリティ・ロールのリストを指定します。

String[]

はい

javax.annotation.security.RunAs

ターゲット: クラス

Java EEコンテナを実際に実行するセキュリティ・ロールを指定します。

指定するセキュリティ・ロールは、WebLogic Serverのセキュリティ・レルム内に存在し、ユーザーまたはグループにマッピングされている必要があります。詳細は、「セキュリティ・ロールの管理」を参照してください。

属性

表8-5 javax.annotation.security.RunAsアノテーションの属性

名前

説明

データ型

必須?

value

Java EEコンテナが実行されるセキュリティ・ロールを指定します。

文字列

はい

9 Contexts and Dependency Injection for the Java EE Platformの使用方法

WebLogic Server は、Contexts and Dependency Injection (CDI)仕様の実装を提供します。CDI仕様には、注入を使用してアプリケーション内の依存関係を指定するための一連のサービスが定義されています。CDIは、Beanのコンテキストに基づいたライフ・サイクル管理、型保証注入ポイント、疎結合イベント・フレームワーク、疎結合インターセプタおよびデコレータ、Beanのかわりの実装、Unified Expression Language (EL)によるBeanのナビゲーション、CDI拡張がサード・パーティのフレームワークまたは将来のJava EEコンポーネントをサポートできるようにするサービス・プロバイダ・インタフェース(SPI)を提供します。

次の項では、アプリケーション内でのCDI for the Java EE platformの使用方法について説明します。

- CDI for the Java EE Platformについて

- マネージドBeanの定義

- Beanの注入

- Beanのスコープの定義

- 注入ポイントでのBeanのスコープのオーバーライド

- 修飾子の使用方法

- Beanタイプの代替の実装の提供

- セッションBeanへのスコープと修飾子の適用

- プロデューサ・メソッド、ディスポーザ・メソッド、およびプロデューサ・フィールドの使用方法

- マネージドBeanの初期化と破棄の準備

- Beanクラスのメソッド呼出しおよびライフ・サイクル・イベントのインターセプト

- マネージドBeanクラスの装飾

- CDI BeanクラスへのEL名の割当て

- ステレオタイプの定義と適用

- Bean間の通信のためのイベントの使用方法

- 事前定義済Beanの注入

- リソースの注入と修飾

- JCAテクノロジでのCDIの使用方法

- CDIアプリケーションの構成

- サード・パーティのポータブルな拡張のサポート

- 暗黙的Beanの検出の有効化と無効化

CDI for the Java EE Platformについて

CDIは、Java Specification Request (JSR) 299: Contexts and Dependency Injection for the Java EE 1.1によって指定されています。この仕様は、以前はWeb Beansと呼ばれていました。CDIは、次の関連する仕様を使用します。

- JSR 330: Dependency Injection for Java

- Java EE 7のマネージドBeanの仕様。これは、『JSR 342: Java Platform, Enterprise Edition 7 (Java EE 7) Specification』の一部です。

- インターセプタの仕様。これは、『JSR 345: Enterprise JavaBeans 3.2』の一部です。

CDIは、次の機能を提供します。

- コンテキスト。この機能により、ステートフル・コンポーネントのライフ・サイクルおよび相互作用を、明確に定義されているが拡張可能なライフ・サイクル・コンテキストにバインドできるようになります。

- 依存関係インジェクション。この機能により、型保証された方法でコンポーネントをアプリケーションに注入でき、デプロイメント時に特定のインタフェースのどの実装を注入するのかを選択できます。

CDIは、次のようなJava EEの主なコンポーネント・テクノロジと統合されます。

- サーブレット

- JavaServer Pages (JSP)

- JavaServer Faces (JSF)

- Enterprise JavaBeans (EJB)

- Java EE Connector Architecture (JCA)

- Webサービス

このような統合により、サーブレットやEJBコンポーネントなど標準Java EEオブジェクトが、依存関係のCDI注入を使用できるようになります。CDI注入により、たとえば、WebアプリケーションでJSFテクノロジとともにマネージドBeanを簡単に使用できるようになります。

詳細は、Java EE 7チュートリアルのContexts and Dependency Injection for the Java EE Platformの概要を参照してください。

CDI 1.1の例

次のようなJava EE 7のサンプル(CDI 1.1の新機能のデモ)が用意されています。

- CDIイベントのCDIサンプル・アプリケーション – 対話Bean間でコンパイル時の依存がない分離された方法でBeanが対話する方法を示します。

- CDI Transactionalアノテーション – @Transactionalアノテーションでアノテーションが付けられたBeanを呼び出す方法を示します。これにより、CDIマネージドBeanのトランザクションの境界で宣言的に制御する機能を持つアプリケーションを提供します。

- CDIトランザクション・スコープAPI – ライフサイクルが現在有効なJTAトランザクションに対してスコープされたBeanインスタンスを定義するために標準CDIスコープを指定する機能を、@TransactionScopedアノテーションが提供する方法を示します。

詳細は、WebLogic Server配布キットのCDI 1.1の例ORACLE_HOME/samples/server/src/examples/javaee7/cdiを参照してください。ORACLE_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードを参照してください。

CDI 1.0の例

CDIの使用方法を示すJava EE 6の例は、ORACLE_HOME/samples/server/src/examples/javaee7/cdiにインストールされたcdiサンプル・アプリケーションで提供されています。ORACLE_HOMEはWebLogic Serverのコード・サンプルを構成するディレクトリです。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードを参照してください。

マネージドBeanの定義

Beanは、CDIによって作成および管理できるオブジェクトのソースです。詳細は、Java EE 7チュートリアルのBeanに関する項を参照してください。

マネージドBeanは、CDIアプリケーションの基本コンポーネントであり、CDIによって作成および管理できるBeanを定義します。マネージドBeanを定義するには、次の条件のいずれかを満たす最上位レベルのプレーンな従来型Javaオブジェクト(POJO)クラスを定義します。

- このクラスは、他のJava EE仕様によってマネージドBeanとなるように定義されています。

- このクラスは、Java EE 7チュートリアルのマネージドBeansに関する項にリストされているJSR 346で必要とされる条件をすべて満たします。

注意:

マネージドBeanを定義するために、アノテーションなど特別な宣言は必要ありません。アプリケーションのマネージドBeanを注入に使用できるようにするには、「CDIアプリケーションの構成」の説明に従ってアプリケーションを構成する必要があります

Beanの注入

自身で定義するBeanを使用するには、それらを、JavaServer Facesアプリケーションなどのアプリケーションが使用できる別のBeanに注入します。詳細は、Java EE 7チュートリアルのBeanの注入に関する項を参照してください。

CDIでは、Bean名ではなく、注入ポイントで指定されているJavaの型に基づいてBeanクラスを選択することで、型を保証してBeanを注入できます。CDIでは、注入ポイントのJavaの型からBeanを注入する場所も判別されます。

この点において、CDI BeanインジェクションはJava EE 5仕様で導入されたリソース・インジェクションとは異なり、リソースの文字列名から呼び出すためにリソースを選択します。たとえば、javax.annotation.Resourceアノテーションで注入されるデータ・ソースは、その文字列名によって識別されます。

Beanを注入するには、注入するBeanを使用するクラス内に注入ポイントを作成することで、Beanのインスタンスを取得します。javax.inject.Injectアノテーションで、次のプログラム要素の1つに注釈付けすることで注入ポイントを作成します。

- インスタンス・クラス・フィールド

- イニシャライザ・メソッド・パラメータ

- Beanコンストラクタ・パラメータ

例9-1は、@Injectアノテーションを使用してBeanを別のBeanに注入する方法を示します。

例9-1 別のBeanへのBeanの注入

この例では、インスタンス・クラス・フィールドに注釈付けして、BeanクラスGreetingのインスタンスをクラスPrinterに注入します。

import javax.inject.Inject;
...
public class Printer {
@Inject Greeting greeting;
...
}

Beanのスコープの定義

Beanのスコープは、そのBeanを使用するアプリケーションとユーザーの対話の期間を定義します。Webアプリケーションが、別のBeanクラスを注入するBeanを使用できるようにするには、そのBeanがアプリケーションとユーザーの対話の期間にわたって状態を保持できるようにする必要があります。

Beanのスコープを定義するには、Beanのクラス宣言にそのスコープのアノテーションを付けます。javax.enterprise.contextパッケージは、次のスコープを宣言します。

- @RequestScoped

- @SessionScoped

- @ApplicationScoped

- @ConversationScoped

- @Dependent

これらのスコープの詳細は、Java EE 7チュートリアルのスコープの使用方法に関する項を参照してください。

Beanのスコープを定義しない場合、Beanのスコープはデフォルトの@Dependentになります。@Dependentのスコープは、そのBeanのライフ・サイクルを、そのBeanの注入先のオブジェクトのライフ・サイクルにすることを指定します。

@Dependent以外の事前定義済スコープは、コンテキスト・スコープです。CDIは、コンテキスト・スコープのBeanを、Java EE仕様によって定義されるライフ・サイクルを持つコンテキストに配置します。たとえば、セッション・コンテキストとそのBeanは、HTTPセッションのライフタイムの間のみ存在します。注入されるBeanへの参照は、コンテキストを認識しています。参照は常に、参照するスレッドのコンテキストに関連付けられたBeanに適用されます。CDIコンテナによって、オブジェクトは、それらのオブジェクトに対して指定されているスコープによって決定される適切な時点で作成され、注入されます。

例9-2は、Beanのスコープを定義する方法を示します。

例9-2 Beanのスコープの定義

この例では、Accountant Beanクラスのスコープを@RequestScopedと定義します。

この例のAccountantクラスは、@BeanCounter修飾子によって修飾されています。詳細は、「修飾子の使用方法」を参照してください

package com.example.managers;

import javax.enterprise.context.RequestScoped;

@RequestScoped
@BeanCounter
public class Accountant implements Manager
{
...
}

注入ポイントでのBeanのスコープのオーバーライド

注入ポイントでのBeanのスコープのオーバーライドにより、アプリケーションは、デフォルト・スコープ@Dependentを持つBeanの新しいインスタンスをリクエストできます。@Dependentのスコープは、そのBeanのライフ・サイクルを、そのBeanの注入先のオブジェクトのライフ・サイクルにすることを指定します。CDIコンテナは、インスタンスにその他のライフ・サイクル管理を提供しません。スコープの詳細は、「Beanのスコープの定義」を参照してください

注意:

Beanのスコープのオーバーライドによる影響は、特にオーバーライドされるスコープが@Requestや@Sessionの場合に、予期できない望ましくないものになることがあります。

注入ポイントでBeanのスコープをオーバーライドするには、@Injectアノテーションのかわりにjavax.enterprise.inject.Newアノテーションを使用することでBeanを注入します。@Injectアノテーションの詳細は、「Beanの注入」を参照してください

修飾子の使用方法

修飾子によって、特定のBeanタイプの実装を複数提供できます。修飾子を使用する場合、開発時に複数の実装の中から選択します。詳細は、Java EE 7チュートリアルの修飾子の使用方法に関する項を参照してください。

注意:

デプロイメント時に複数の代替の実装の中から選択するには、「Beanタイプの代替の実装の提供」の説明に従って代替を使用します

修飾子の使用方法には、次の項で説明するタスクが含まれます。

- Beanタイプの実装に対する修飾子の定義

- Beanへの修飾子の適用

- 修飾Beanの注入

Beanタイプの実装に対する修飾子の定義

修飾子は、アプリケーションによって定義されるアノテーションであり、Beanタイプの実装の識別を可能にします。提供するBeanタイプの実装ごとに修飾子を1つ定義します。

修飾子は、Beanタイプの複数の実装を提供し、かつ代替を使用していない場合にのみ定義します。Beanタイプに対して修飾子が定義されていない場合、そのタイプのBeanが注入されるときにCDIによって事前定義済修飾子@Defaultが適用されます。

注意:

CDIでは、修飾子が特定のBeanに一意である必要はありません。1つの修飾子を複数のBeanタイプに定義できます。

修飾子を定義する手順は、次のとおりです。

1. その修飾子を表すJavaアノテーション・タイプを定義します。

2. javax.inject.Qualifierアノテーションでアノテーション・タイプの宣言に注釈付けします。

3. 実行時に仮想マシンによってその修飾子が保持されることを指定します。

このためには、java.lang.annotation.Retention(RUNTIME)メタアノテーションを使用します。

4. その修飾子をプログラム要素METHOD、FIELD、PARAMETERおよびTYPEに適用できることを指定します。

このためには、java.lang.annotation.Target({METHOD, FIELD, PARAMETER, TYPE})メタアノテーションを使用します。

次の例では、修飾子@BeanCounterおよび@PeopleManagerを、同じBeanタイプの別々の実装に対して定義する方法を示します。

例9-3 @BeanCounter修飾子の定義

この例では、@BeanCounter修飾子を定義します。

package com.example.managers;

import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import javax.inject.Qualifier;

@Qualifier
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface BeanCounter {}

例9-4 @PeopleManager修飾子の定義

この例では、@PeopleManager修飾子を定義します。

package com.example.managers;

import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import javax.inject.Qualifier;

@Qualifier
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface PeopleManager {}

Beanへの修飾子の適用

Beanに修飾子を適用すると、Beanタイプの実装が特定されます。1つのBeanに、任意の数の修飾子を適用することも、修飾子を適用しないこともできます。Beanに修飾子が適用されていない場合、CDIによって暗黙的に事前定義済修飾子@DefaultがそのBeanに適用されます。

注意:

CDIでは、修飾子が特定のBeanに一意である必要はありません。1つのアプリケーション内で使用可能な一連のBeanで異なるタイプのBeanに同じ修飾子を適用できます。

修飾子をBeanに適用するには、そのBeanのクラス宣言に、適用する各修飾子で注釈付けします。Beanに適用する修飾子は、「Beanタイプの実装に対する修飾子の定義」の説明に従って定義する必要があります

次の例では、修飾子@BeanCounterおよび@PeopleManagerをManager Beanタイプの別々の実装に対して適用する方法を示します。

例9-5 Beanへの@BeanCounter修飾子の適用

この例では、@BeanCounter修飾子をAccountantクラスに適用します。Accountantクラスは、Manager Beanタイプの実装です。@BeanCounter修飾子は、例9-3で定義されています。

package com.example.managers;
...
@BeanCounter
public class Accountant implements Manager
{...}

例9-6 Beanへの@PeopleManager修飾子の適用

この例では、@PeopleManager修飾子をBossクラスに適用します。Bossクラスは、Manager Beanタイプの実装です。@PeopleManager修飾子は、例9-4で定義されています。

package com.example.managers;
...
@PeopleManager
public class Boss implements Manager
{...}

修飾Beanの注入

修飾Beanを注入するには、注入ポイントを作成し、その注入ポイントにBeanの修飾子で注釈付けします。注入ポイントの修飾子は、注入ターゲットの全体的な要件を定義します。CDIアプリケーションには、注入ポイントのタイプと、注入ポイントに注釈付けされている修飾子に一致するCDIマネージドBeanが含まれている必要があります。それ以外の場合は、デプロイメント・エラーが発生します。注入ポイントの作成方法の詳細は、「Beanの注入」を参照してください

注入ポイントに注釈付けしない場合、デフォルトで事前定義済修飾子@Defaultがその注入ポイントに適用されます。

CDIでは、注入ポイントは、最初にBeanタイプを一致させ、次にそのタイプの実装を注入ポイントの修飾子と一致させることで解決されます。

アクティブなBeanクラスのうちの1つのみを、注入ポイントのBeanタイプおよび修飾子と一致させることができます。それ以外の場合は、エラーが発生します。

Beanクラスは、次の状況のいずれかでアクティブです。

- Beanクラスが、有効化されている代替です。

- Beanクラスが、代替でなく、そのBeanタイプに対して有効化されている代替がありません。

代替の詳細は、「Beanタイプの代替の実装の提供」を参照してください

例9-7は、修飾Beanの注入方法を示します。

例9-7 修飾Beanの注入

この例では、Manager Beanタイプの@BeanCounter実装を注入します。Manager Beanタイプは、次のクラスによって実装されています。

- Accountant。例9-5に示しています。

- Boss。例9-6に示しています。

この例では、Accountantクラスが注入されます。それは、このクラスのBeanタイプと修飾子が、注入ポイントのBeanタイプと修飾子に一致するためです。

package com.example.managers;
...
import javax.inject.Inject;
...
public class PennyPincher {
@Inject @BeanCounter Manager accountant;
...
}

Beanタイプの代替の実装の提供

エンタープライズ・アプリケーションの開発、テスト、および本番デプロイメントの各環境は、大きく異なる場合があります。構成、リソースの可用性、およびパフォーマンスの要件の相違により、1つの環境に適したBeanクラスが、別の環境には合わないことがあります。

同じアプリケーションでも、デプロイメント・シナリオの相違によって、異なるビジネス・ロジックが必要とされる場合もあります。たとえば、注文処理アプリケーションでは、国固有の消費税法によって国固有の消費税のビジネス・ロジックが必要な場合もあります。

Beanタイプの代替の実装を提供することにより、そのような異なる要件を満たすためにデプロイメント時にアプリケーションを変更できます。CDIでは、対応するプライマリの実装のかわりに、任意の数の代替のBeanタイプの実装から注入するものを選択できます。詳細は、Java EE 7チュートリアルの代替の使用方法に関する項を参照してください。

注意:

開発時に複数の代替の実装から選択するには、「修飾子の使用方法」の説明に従って修飾子を使用します

Beanタイプの代替の実装の提供には、次の項で説明するタスクが含まれます。

- Beanタイプの代替の実装の定義

- アプリケーションに対するBeanタイプの代替の実装の選択

Beanタイプの代替の実装の定義

Beanタイプの代替の実装を定義する手順は、次のとおりです。

1. Beanタイプのプライマリの実装と同じBeanタイプのBeanクラスを作成します。

どの代替もアプリケーションに注入できるようにするには、すべての代替とプライマリの実装が、すべて同じBeanタイプであることが必要です。Beanの注入方法の詳細は、「Beanの注入」を参照してください

2. avax.enterprise.inject.Alternativeアノテーションで実装のクラス宣言に注釈付けします。

注意:

デフォルトで必ずプライマリの実装が選択されるようにするには、プライマリの実装のクラス宣言に@Alternativeで注釈付けしないでください。

次の例では、1つのBeanタイプのプライマリの実装と代替の実装の宣言を示します。代替の実装は、テストで使用するための模擬の実装です。

例9-8 Beanタイプのプライマリの実装の宣言

この例では、BeanタイプOrderのプライマリの実装OrderImplを宣言します。

package com.example.orderprocessor;
...
public class OrderImpl implements Order {
...
}

例9-9 Beanタイプの代替の実装の宣言

この例では、BeanタイプOrderの代替の実装MockOrderImplを宣言します。このBeanタイプのプライマリの実装の宣言を例9-8に示します。

package com.example.orderprocessor;
...
import javax.enterprise.inject.Alternative;

@Alternative
public class MockOrderImpl implements Order {
...
}

アプリケーションに対するBeanタイプの代替の実装の選択

デフォルトでは、CDIはアプリケーションへの注入にBeanタイプのプライマリの実装を選択します。代替の実装を注入する必要がある場合は、明示的にその代替を選択する必要があります。

アプリケーションに対して代替の実装を選択する手順は、次のとおりです。

1. beans.xmlファイルのalternatives要素に、代替のclass要素を追加します。

2. class要素に、代替の完全修飾クラス名を指定します。

beans.xmlファイルの詳細は、「CDIアプリケーションの構成」を参照してください

例9-16は、Beanタイプの代替の実装を選択するためのbeans.xmlファイルのclass要素を示しています。

例9-10 Beanタイプの代替の実装の選択

この例では、代替の実装com.example.orderprocessor.MockOrderImplを選択します。

...
<alternatives>
<class>com.example.orderprocessor.MockOrderImpl</class>
</alternatives>
...

セッションBeanへのスコープと修飾子の適用

CDIでは、スコープおよび修飾子をセッションBeanに適用できます。セッションBeanは、次の要件のいずれかを満たすEJBコンポーネントです。

- Beanを実装するクラスには、次のいずれかのアノテーションが付いています。

- javax.ejb.Singleton。シングルトン・セッションBeanを指定します。

- javax.ejb.Stateful。ステートフル・セッションBeanを指定します。

- javax.ejb.Stateless。ステートレス・セッションBeanを指定します。

- そのBeanが、ejb-jar.xmlデプロイメント記述子ファイルにリストされています。

セッションBeanの詳細は、次のドキュメントを参照してください。

- Oracle WebLogic Server Enterprise JavaBeansの開発

- Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発

セッションBeanへのスコープの適用

CDIによりセッションBeanに適用できるスコープは、表9-1に示すようにセッションBeanのタイプに応じて異なります。

表9-1 セッションBeanに適用できるCDIスコープ

セッションBeanタイプ

適用できるスコープ

シングルトン

次のスコープのいずれかです。

- Dependent

- Application

ステートフル

任意

ステートレス

Dependent

CDIにおけるスコープの詳細は、「Beanのスコープの定義」を参照してください

CDIで、ステートフル・セッションBeanへの参照が注入されるときは、CDIによってBeanが作成され、Beanのフィールドが注入され、そのスコープに応じてステートフル・セッションBeanが管理されます。コンテキストを破棄するときは、CDIによってステートフル・セッションBeanの削除メソッドがコールされ、そのBeanが削除されます。

セッションBeanへの修飾子の適用

CDIでは、任意の修飾子をセッションBeanに適用できます。CDIでは、セッションBeanに適用できる修飾子のタイプに制限はありません。CDIにおける修飾子の詳細は、「修飾子の使用方法」を参照してください

プロデューサ・メソッド、ディスポーザ・メソッド、およびプロデューサ・フィールドの使用方法

プロデューサ・メソッドは、注入可能なオブジェクトを生成するメソッドです。

ディスポーザ・メソッドは、アプリケーションが、プロデューサ・メソッドから返されたオブジェクトに、カスタマイズされたクリーンアップを実行できるようにします。

プロデューサ・フィールドは、オブジェクトを生成するBeanのフィールドです。プロデューサ・フィールドは、プロデューサ・メソッドの単純な代替です。

詳細は、Java EE 7チュートリアルのCDIアプリケーションでのプロデューサ・メソッド、プロデューサ・フィールドおよびディスポーザ・メソッドの使用に関する項を参照してください。

プロデューサ・メソッドの定義

プロデューサ・メソッドにより、アプリケーションはCDIマネージドBeanの作成方法をカスタマイズできます。このカスタマイズには、CDIがBeanを解決するために通常使用するプロセスのオーバーライドも含まれます。プロデューサ・メソッドにより、CDI Beanクラスのインスタンスではないオブジェクトを注入できるようになります。

プロデューサ・メソッドは、CDI BeanクラスまたはセッションBeanクラスのメソッドであることが必要です。ただし、プロデューサ・メソッドは、CDI Beanクラスのインスタンスではないオブジェクトを返すことができます。この状況では、プロデューサ・メソッドはBeanタイプが一致するオブジェクトを返す必要があります。

プロデューサ・メソッドには、任意の数のパラメータを指定できます。必要に応じて、これらのパラメータに修飾子を適用できます。プロデューサ・メソッドのすべてのパラメータは、注入ポイントです。したがって、プロデューサ・メソッドのパラメータには、@Injectアノテーションは必要ありません。

プロデューサ・メソッドを定義するには、javax.enterprise.inject.Producesアノテーションでメソッドの宣言に注釈付けします。

プロデューサ・メソッドがnullを返すことがある場合は、メソッドのスコープをDependentに設定します。

注意:

アプリケーション・コードでプロデューサ・メソッドを直接コールしてもCDIは起動されません。

プロデューサ・メソッドの定義の例は、例9-11を参照してください。

ディスポーザ・メソッドの定義

プロデューサ・メソッドから返されるオブジェクトのカスタマイズ・クリーンアップが必要な場合は、プロデューサ・メソッドを宣言するクラスでディスポーザ・メソッドを定義します。

ディスポーザ・メソッドを定義するには、javax.enterprise.inject.Disposesアノテーションで、メソッドの宣言の破棄されるパラメータに注釈付けします。破棄されるパラメータのタイプは、プロデューサ・メソッドの戻りタイプと同じであることが必要です。

ディスポーザ・メソッドは、破棄されるオブジェクトの注入ポイントが、プロデューサ・メソッドのタイプと修飾子の両方に一致する場合に、プロデューサ・メソッドと一致します。1つのディスポーザ・メソッドをクラス内の複数のプロデューサ・メソッドに一致するように定義できます。

例9-11は、@Producesアノテーションを使用してプロデューサ・メソッドを定義する方法と、@Disposesアノテーションを使用してディスポーザ・メソッドを定義する方法を示しています。

例9-11 プロデューサ・メソッドとディスポーザ・メソッドの定義

この例では、プロデューサ・メソッドconnectとディスポーザ・メソッドcloseを定義します。

プロデューサ・メソッドconnectは、タイプConnectionのオブジェクトを返します。ディスポーザ・メソッドcloseでは、パラメータconnectionが、破棄されるパラメータです。このパラメータのタイプは、プロデューサ・メソッドの戻りタイプに一致するタイプConnectionです。

実行時に、CDIフレームワークによってSomeClassのインスタンスが作成され、プロデューサ・メソッドがコールされます。したがって、CDIフレームワークが、プロデューサ・メソッドに渡されるパラメータの注入を担当します。

プロデューサ・メソッドのスコープは@RequestScopedです。リクエスト・コンテキストが破棄されるときに、Connectionオブジェクトがそのリクエスト・コンテキストにある場合、CDIによってこのオブジェクトに対してディスポーザ・メソッドがコールされます。そのディスポーザ・メソッドへのコールでは、CDIによってConnectionオブジェクトがパラメータとして渡されます。

import javax.enterprise.inject.Produces;
import javax.enterprise.inject.Disposes;

import javax.enterprise.context.RequestScoped;

public class SomeClass {
@Produces @RequestScoped
public Connection connect(User user) {
return createConnection(user.getId(),
user.getPassword());
}

private Connection createConnection(
String id, String password) {...}

public void close(@Disposes Connection connection) {
connection.close();
}
}

プロデューサ・フィールドの定義

プロデューサ・フィールドは、プロデューサ・メソッドの単純な代替です。プロデューサ・フィールドは、マネージドBeanクラスまたはセッションBeanクラスのフィールドにする必要があります。プロデューサ・フィールドは、次の制約に従って、静的である場合も静的でない場合もあります。

- セッションBeanクラスでは、プロデューサ・フィールドは静的フィールドであることが必要です。

- マネージドBeanクラスでは、プロデューサ・フィールドは、静的でも静的でなくても構いません。

プロデューサ・フィールドを定義するには、javax.enterprise.inject.Producesアノテーションでフィールドの宣言に注釈付けします。

プロデューサ・フィールドにアクセスしたときにnullが含まれている可能性がある場合は、フィールドのスコープをDependentに設定します。

注意:

アプリケーション・コード内でプロデューサ・フィールドを直接使用すると、CDIは起動しません。

プロデューサ・フィールドには、ディスポーザはありません。

マネージドBeanの初期化と破棄の準備

CDIマネージドBeanクラスおよびそれらのスーパークラスでは、マネージドBeanの初期化と破棄の準備のためのアノテーションがサポートされています。これらのアノテーションは、『JSR 250: Common Annotations for the Java Platform』で定義されています。詳細は、Java EEアノテーションと依存関係インジェクションの使用を参照してください。

マネージドBeanの初期化

マネージドBeanの初期化では、依存関係インジェクションの後、クラスがサービスを開始する前にCDIフレームワークがコールする必要があるライフ・サイクル・コールバック・メソッドを指定します。

マネージドBeanを初期化する手順は、次のとおりです。

1. マネージドBeanクラスまたはそのスーパークラスのいずれかで、必要な初期化を実行するメソッドを定義します。

2. javax.annotation.PostConstructアノテーションで、メソッドの宣言に注釈付けします。

マネージドBeanがコンポーネントに注入されると、すべての注入が実行され、すべてのイニシャライザがコールされた後にCDIによってそのメソッドがコールされます。

注意:

JSR 250で規定されているように、注釈付けされたメソッドがスーパークラスで宣言される場合、宣言するクラスのサブクラスがそのメソッドをオーバーライドしないかぎり、そのメソッドがコールされます。

マネージドBeanの破棄の準備

マネージドBeanの破棄の準備では、アプリケーション・コンポーネントがコンテナによって破棄されようとしていることを通知するライフ・サイクル・コールバック・メソッドを指定します。

マネージドBeanの破棄を準備する手順は、次のとおりです。

1. マネージドBeanクラスまたはそのスーパークラスのいずれかで、マネージドBeanの破棄を準備するメソッドを定義します。

このメソッドでは、Beanが保持していたリソースの解放など、Beanを破棄する前に必要なクリーンアップを実行します。

2. javax.annotation.PreDestroyアノテーションで、メソッドの宣言に注釈付けします。

Beanを破棄するためのロジックを開始する前にCDIによってそのメソッドがコールされます。

注意:

JSR 250で規定されているように、注釈付けされたメソッドがスーパークラスで宣言される場合、宣言するクラスのサブクラスがそのメソッドをオーバーライドしないかぎり、そのメソッドがコールされます。

Beanクラスのメソッド呼出しおよびライフ・サイクル・イベントのインターセプト

Beanクラスのメソッド呼出しまたはライフ・サイクル・イベントのインターセプトでは、呼出しまたはイベントにインターセプタ・クラスを割り込みます。インターセプタ・クラスを割り込むと、そのインターセプタ・クラスで定義されている追加のアクションが実行されます。インターセプタ・クラスによって、頻繁に実行されるが、アプリケーションのビジネス・ロジックからは分離されているタスクのコードのメンテナンスが簡素化されます。そのようなタスクの例としては、ロギングと監査があります。

注意:

インターセプタ・クラスのプログラミング・モデルは、アプリケーションのビジネス・ロジックから分離されている操作に対して最適化されています。ビジネス・セマンティクスを持つ操作を実行するメソッドをインターセプトするには、「マネージドBeanクラスの装飾」の説明に従ってデコレータ・クラスを使用します

Java EE 5仕様で導入されたインターセプタは、EJBコンポーネント固有です。Java EE 5インターセプタの詳細は、『Oracle WebLogic Server Enterprise JavaBeansの開発』のビジネス・メソッドまたはライフ・サイクル・コールバック・イベントのインターセプタの指定に関する項を参照してください。

CDIでは、次のタイプのJava EE管理対象オブジェクトでインターセプタを使用できます。

- CDIマネージドBean

- EJBセッションBean

- EJBメッセージドリブンBean

注意:

CDIではEJBエンティティBeanがサポートされていないため、EJBエンティティBeanでは、インターセプタを使用できません。

詳細は、Java EE 7チュートリアルのインターセプタの使用方法に関する項を参照してください。

Beanクラスのメソッド呼出しおよびライフ・サイクル・イベントのインターセプトには、次の項で説明するタスクが含まれます。

- インターセプタ・バインディング・タイプの定義

- インターセプタ・クラスの定義

- インターセプトのためのメソッドの特定

- インターセプタの有効化

インターセプタ・バインディング・タイプの定義

インターセプタ・バインディング・タイプは、インターセプタ・クラスとインターセプトされるBeanを関連付けるアプリケーション定義のアノテーションです。必要なインターセプタのタイプごとにインターセプタ・バインディング・タイプを定義します。

注意:

CDIでは、インターセプタ・バインディング・タイプが特定のインターセプタ・クラスに固有でなくても構いません。1つのインターセプタ・バインディング・タイプを複数のインターセプタ・クラスで使用するように定義できます。

インターセプタ・バインディング・タイプを定義する手順は、次のとおりです。

1. インターセプタ・バインディング・タイプを表すJavaアノテーション・タイプを定義します。

2. javax.interceptor.InterceptorBindingアノテーションで、アノテーション・タイプの宣言に注釈付けします。

3. インターセプタ・バインディング・タイプが、実行時に仮想マシンによって保持されることを指定します。

このためには、java.lang.annotation.Retention(RUNTIME)メタアノテーションを使用します。

4. インターセプタ・バインディング・タイプを、プログラム要素METHODおよびTYPEに適用できることを指定します。

このためには、java.lang.annotation.Target({METHOD, TYPE})メタアノテーションを使用します。

例9-12 インターセプタ・バインディング・タイプの定義

この例では、@Transactionalインターセプタ・バインディング・タイプを定義します。

package com.example.billpayment.interceptor;

import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import javax.interceptor.InterceptorBinding;

@InterceptorBinding
@Target({METHOD, TYPE})
@Retention(RUNTIME)
public @interface Transactional {}

インターセプタ・クラスの定義

インターセプタ・クラスは、関連付けられたターゲットBeanクラスで発生するメソッド呼出しまたはライフ・サイクル・イベントへの割込みに使用されます。インターセプタ・クラスでは、ロギングや監査など、頻繁に実行されるが、アプリケーションのビジネス・ロジックからは分離されているタスクのコードを提供します。

インターセプタ・クラスを定義する手順は、次のとおりです。

1. インターセプタを表すJavaクラスを定義します。

2. 次のアノテーションでクラス宣言に注釈付けします。

- javax.interceptor.Interceptor

- クラスに対して定義されているインターセプタ・バインディング・タイプ
1つのインターセプタ・クラスに、任意の数のインターセプタ・バインディング・タイプを適用できます。

注意:

CDIでは、インターセプタ・バインディング・タイプが特定のインターセプタ・クラスに固有でなくても構いません。同じインターセプタ・バインディング・タイプを複数のインターセプタ・クラスに適用できます。

3. そのクラス内にインターセプタ・メソッドを実装します。

CDIでは、インターセプタ・メソッドのシグネチャがインターセプトされるメソッドのシグネチャに一致する必要はありません。

4. クラス内のインターセプタ・メソッドを特定します。

インターセプタ・メソッドは、Beanクラスのメソッド呼出しまたはライフ・サイクル・イベントをインターセプトするときに呼び出されるメソッドです。

インターセプタ・メソッドを特定するには、インターセプタ・メソッドのタイプに適したアノテーションで、メソッドの宣言に注釈付けします。

インターセプタ・メソッドのタイプ

アノテーション

メソッドの呼出し

javax.interceptor.AroundInvoke

EJBタイムアウト

javax.interceptor.AroundTimeout

マネージドBeanまたはEJBコンポーネントの初期化

javax.annotation.PostConstruct

マネージドBeanまたはEJBコンポーネントの破棄

javax.annotation.PreDestroy

ステートフル・セッションBeanのアクティブ化

javax.ejb.PostActivate

ステートフル・セッションBeanの非アクティブ化

javax.ejb.PrePassivate

注意:

1つのインターセプタ・クラスに、複数のインターセプタ・クラスを含めることができます。ただし、1つのインターセプタ・クラスに含めることができる特定のタイプのインターセプタ・メソッドは1つのみです。

例9-13は、インターセプタ・クラスを定義する方法を示します。

例9-13 インターセプタ・クラスの定義

この例では、@Transactionalインターセプタ・バインディング・タイプが定義されるインターセプタ・クラスを定義します。このクラスのmanageTransactionメソッドは、インターセプタ・メソッドです。@Transactionalインターセプタ・バインディングは、例9-12で定義されています。

package com.example.billpayment.interceptor;

import javax.annotation.Resource;
import javax.interceptor.*;
...
@Transactional @Interceptor
public class TransactionInterceptor {
@Resource UserTransaction transaction;
@AroundInvoke
public Object manageTransaction(InvocationContext ctx)
throws Exception {
...
}
}

インターセプトのためのメソッドの特定

インターセプトのためのメソッドの特定により、メソッドと、そのメソッドが呼び出されるときに呼び出されるインターセプタが関連付けられます。CDIでは、インターセプトのためにBeanクラスのすべてのメソッドを特定するか、Beanクラスの個別のメソッドのみを特定できます。

- インターセプトのためにBeanクラスのすべてのメソッドを特定するには、適切なインターセプタ・バインディング・タイプでBeanクラスの宣言に注釈付けします。

- インターセプトのためにBeanクラスの個別のメソッドを特定するには、適切なインターセプタ・バインディング・タイプでそのメソッドの宣言に注釈付けします。

CDIでは、インターセプトされるメソッドのシグネチャがインターセプタ・メソッドのシグネチャに一致する必要はありません。インターセプトされるメソッドの引数と戻りタイプを判別するには、インターセプタがインターセプタ・コンテキストを問い合せる必要があります。したがって、Beanクラスのインタフェースのコンパイル時に何も知識がなくても、Beanクラスの任意のメソッドまたはライフ・サイクル・イベントをインターセプトできます。

注意:

Java EE 5インターセプタの実装は、インターセプトされるメソッドのアノテーションで宣言する必要があります。CDIインターセプタは、インターセプタ・バインディングを使用して、インターセプタ・メソッドを特定し、インターセプトされるメソッドをそのインターセプタ・メソッドに関連付けます。インターセプトされるメソッドとインターセプタ・メソッドの両方に、バインディングで注釈付けする必要があります。このようにして、インターセプトされるメソッドとインターセプタ・メソッドは、インターセプタ・バインディングを介してのみ相互に関連付けされます。

例9-14 インターセプトのためのBeanクラスのすべてのメソッドの特定

この例では、@Transactionalインターセプタによって、インターセプトのためのShoppingCartクラスのすべてのメソッドが特定されます。

package com.example.billpayment.interceptor;

@Transactional
public class ShoppingCart {
...
}

例9-15 インターセプトのためのクラスの個別のメソッドの特定

この例では、@Transactionalインターセプタによって、インターセプトのためのShoppingCartクラスのcheckoutメソッドのみが特定されます。

package com.example.billpayment.interceptor;

public class ShoppingCart {
...
@Transactional public void checkout() {
...
}
}

インターセプタの有効化

デフォルトでは、インターセプタは無効です。インターセプタを、メソッドの呼出しおよびイベントに割り込む必要がある場合は、インターセプタを明示的に有効化する必要があります。

インターセプタを有効化する手順は、次のとおりです。

1. beans.xmlファイルのinterceptors要素にインターセプタのclass要素を追加します。

2. class要素に、そのインターセプタの完全修飾クラス名を指定します。

beans.xmlファイル内のclass要素の順序が、インターセプタの呼出し順序と一致するようにします。

CDIインターセプタは、beans.xmlファイルで宣言されている順序で呼び出されます。ejb-jar.xmlファイル内またはjavax.interceptor.Interceptorsアノテーションによって定義されているインターセプタは、CDIインターセプタの前にコールされます。インターセプタは、CDIデコレータの前にコールされます。

注意:

Java EE 5インターセプタは、インターセプトされるメソッドで注釈付けされている順序で呼び出されます。

beans.xmlファイルの詳細は、「CDIアプリケーションの構成」を参照してください

例9-16は、インターセプタ・クラスを有効化するためのbeans.xmlファイルのclass要素を示します。

例9-16 インターセプタ・クラスの有効化

この例では、インターセプタ・クラスcom.example.billpayment.interceptor.TransactionInterceptorを有効化します。インターセプタ・クラスは、例9-13で定義されています。

...
<interceptors>
<class>com.example.billpayment.interceptor.TransactionInterceptor</class>
</interceptors>
...

マネージドBeanクラスの装飾

マネージドBeanクラスの装飾により、ビジネス・セマンティクスを持つ操作を実行する装飾されるクラスのメソッドの呼出しをインターセプトできます。どのマネージドBeanクラスも装飾できます。

注意:

デコレータ・クラスのプログラミング・モデルは、アプリケーションのビジネス・ロジックを実行する操作に対して最適化されています。アプリケーションのビジネス・ロジックから分離されているメソッドをインターセプトするには、「Beanクラスのメソッド呼出しおよびライフ・サイクル・イベントのインターセプト」の説明に従ってインターセプタ・クラスを使用します

詳細は、Java EE 7チュートリアルのデコレータの使用方法に関する項を参照してください。

マネージドBeanクラスの装飾には、次の項で説明するタスクが含まれます。

- デコレータ・クラスの定義

- デコレータ・クラスの有効化

デコレータ・クラスの定義

デコレータ・クラスは、ビジネス・セマンティクスを持つ操作を実行する装飾されるクラスのメソッドの呼出しをインターセプトします。デコレータ・クラスおよびインターセプタ・クラスは類似しており、どちらもメソッド周辺のインターセプトを提供します。ただし、デコレータ・クラスのメソッドは、装飾されるBeanクラスのインターセプトされるメソッドと同じシグネチャを持ちます。

デコレータ・クラスを定義する手順は、次のとおりです。

1. 装飾対象のBeanクラスと同じインタフェースを実装するJavaクラスを作成します。
装飾されるクラスのいくつかのメソッドのみをインターセプトする場合は、デコレータ・クラスを抽象クラスとして宣言します。クラスを抽象として宣言する場合、装飾対象のBeanクラスのすべてのメソッドを実装する必要はありません。

2. javax.decorator.Decoratorアノテーションでデコレータ・クラスのクラス宣言に注釈付けします。

3. インターセプトする装飾されるBeanクラスのメソッドを実装します。
デコレータ・クラスが具体クラスである場合、装飾するBeanクラスのすべてのメソッドを実装する必要があります。

デコレータ・クラスのインターセプトするメソッドが、装飾されるBeanクラスのインターセプトされるメソッドと同じシグネチャを持つようにしてください。

4. デコレータ・クラスに委任注入ポイントを追加します。
デコレータ・クラスには、委任注入ポイントが1つのみ含まれている必要があります。委任注入ポイントは、装飾されるクラスのインスタンスである委任オブジェクトを、デコレータ・オブジェクトに注入します。

デコレータ・オブジェクトのメソッドが、装飾されるメソッドの実装を処理する方法をカスタマイズできます。CDIでは、デコレータ・オブジェクトが、対応する委任オブジェクトを呼び出すことができますが、これは必須ではありません。したがって、デコレータ・オブジェクトに、対応する委任オブジェクトを呼び出させるかどうかは自由に選択できます。

a. デコレータ・クラスで、装飾するBeanクラスのインスタンスを注入します。

b. javax.decorator.Delegateアノテーションで、注入ポイントに注釈付けします。

c. 注入ポイントに修飾子を適用する必要がある場合は、適用します。
注入ポイントに修飾子を適用すると、デコレータは、注入ポイントの修飾子に一致するBeanクラスのBeanにのみ適用されます。

注意:

装飾されるBeanクラスを定義するために、アノテーションなどの特別な宣言は必要ありません。有効化されたデコレータ・クラスは、委任注入ポイントのBeanタイプと修飾子に一致するBeanクラスまたはセッションBeanに適用されます。

例9-17は、デコレータ・クラスの定義を示します。

例9-17 デコレータ・クラスの定義

この例では、デコレータ・クラスDataAccessAuthDecoratorを定義します。このクラスは、タイプDataAccessのBeanを装飾します。

装飾されるクラスのいくつかのメソッドのみがインターセプトされるため、このクラスは抽象クラスとして宣言します。このクラスは、DataAcess Beanタイプの装飾される実装の委任インスタンスdelegateを注入します。

import javax.decorator.*;
import javax.inject.Inject;
import java.lang.Override;
...
@Decorator
public abstract class DataAccessAuthDecorator
implements DataAccess {

@Inject @Delegate DataAccess delegate;

@Override
public void delete(Object object) {
authorize(SecureAction.DELETE, object);
delegate.delete(object);
}

private void authorize(SecureAction action, Object object) {
...
}
}

デコレータ・クラスの有効化

デフォルトでは、デコレータ・クラスは無効です。CDIアプリケーションで、デコレータ・クラスを呼び出す必要がある場合は、デコレータ・クラスを明示的に有効化する必要があります。

デコレータ・クラスを有効化する手順は、次のとおりです。

1. beans.xmlファイルのdecorators要素に、デコレータ・クラスのclass要素を追加します。

2. class要素に、そのデコレータ・クラスの完全修飾クラス名を指定します。

beans.xmlファイル内のclass要素の順序が、デコレータ・クラスの呼出し順序と一致するようにします。

注意:

アプリケーションに対して定義されているインターセプタ・クラスは、そのアプリケーションのデコレータ・クラスの前に呼び出されます。

beans.xmlファイルの詳細は、「CDIアプリケーションの構成」を参照してください

例9-18は、デコレータ・クラスを有効化するためのbeans.xmlファイルのclass要素を示します。

例9-18 デコレータ・クラスの有効化

この例では、デコレータ・クラスcom.example.billpayment.decorator.DataAccessAuthDecoratorを有効化します。

...
<decorators>
<class>com.example.billpayment.decorator.DataAccessAuthDecorator</class>
</decorators>
...

CDI BeanクラスへのEL名の割当て

ELにより、プレゼンテーション・レイヤーのコンポーネントが、アプリケーション・ロジックを実装するマネージドBeanと通信できます。プレゼンテーション・レイヤーのコンポーネントは、通常、JavaServer Faces (JSF)ページおよびJavaServer Pages (JSP)ページです。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のJSP式言語に関する項を参照してください。

JSPページおよびJSFページのスクリプト言語では、注入される変数の構文は、これらの言語の組込み変数の構文と同一です。JSPページまたはJSFページに注入されるCDI Beanは、EL名を介してアクセス可能であることが必要です。詳細は、Java EE 7チュートリアルのBeanのEL名の指定に関する項を参照してください。

EL名をCDI Beanクラスに割り当てるには、javax.inject.NamedアノテーションでBeanクラスのクラス宣言に注釈付けします。

名前を指定しない場合、EL名は、最初の文字を小文字にした非修飾クラス名です。たとえば、非修飾クラス名がShoppingCartである場合、EL名はshoppingCartです。

名前を指定するには、@Namedアノテーションのvalue要素を、目的の名前に設定します。

注意:

EL名をCDI Beanクラスに割り当てるには、@NamedアノテーションでBeanクラス宣言に注釈付けする必要があります。クラスに@Namedで注釈付けされていない場合、CDI BeanクラスにEL名は付きません。

次の例は、@Namedアノテーションを使用してEL名をCDI Beanクラスに割り当てる方法を示します。この例では、EL名cartをShoppingCartクラスに割り当てます。

import javax.enterprise.context.SessionScoped;

@SessionScoped
@Named("cart")
public class ShoppingCart {
public String getTotal() {
...
}

...
}

JSPページまたはJSFページがアクセスするBeanは、JavaBeans標準に準拠している必要があります。BeanのEL名を介してJSPページまたはJSFページからCDIマネージドBeanにアクセスするには、JavaBeansコンポーネントの構文に類似した構文を使用します。

次の例は、JSFページで、ShoppingCartクラスのインスタンスに、そのクラスに割り当てられたEL名を介してアクセスする方法を示しています。

例9-19 EL名を介したBeanへのアクセス

この例では、ShoppingCartクラスのインスタンスにアクセスし、JSFページにそのtotalプロパティの値を表示します。

このプロパティは、ShoppingCartクラスのgetTotal getterメソッドによって返されます。

...
<h:outputText value="#{cart.total}"/>
...

ステレオタイプの定義と適用

いくつかのBeanが類似した関数を実行する大規模なアプリケーションでは、場合によっては、同じアノテーションのセットをいくつかのBeanクラスに適用する必要があります。ステレオタイプを定義すると、アノテーションのセットの定義を一度行うのみで済みます。その後、そのステレオタイプを使用して、同じアノテーションのセットを、それらのアノテーションを必要とするすべてのBeanクラスに適用できるようになります。詳細は、Java EE 7チュートリアルのステレオタイプの使用方法に関する項を参照してください。

ステレオタイプの定義と適用には、次の項で説明するタスクが含まれます。

- ステレオタイプの定義

- Beanへのステレオタイプの適用

ステレオタイプの定義

ステレオタイプは、アプリケーション定義のアノテーション・タイプであり、他のアノテーション・タイプが組み込まれています。

ステレオタイプを定義する手順は、次のとおりです。

1. ステレオタイプを表すJavaアノテーション・タイプを定義します。

2. 次のアノテーションでアノテーション・タイプの宣言に注釈付けします。

- javax.enterprise.inject.Stereotype

- ステレオタイプに組み込むその他のアノテーション・タイプ
ステレオタイプには次のアノテーション・タイプを指定できます。

- デフォルトのスコープ(「Beanのスコープの定義」を参照)

- @Alternative(「Beanタイプの代替の実装の提供」を参照)

- 1つ以上のインターセプタ・バインディング(「Beanクラスのメソッド呼出しおよびライフ・サイクル・イベントのインターセプト」を参照)

- @Named(「CDI BeanクラスへのEL名の割当て」を参照)

3. ステレオタイプが、実行時に仮想マシンによって保持されることを指定します。

このためには、java.lang.annotation.Retention(RUNTIME)メタアノテーションを使用します。

4. ステレオタイプをプログラム要素TYPEに適用できることを指定します。

このためには、java.lang.annotation.Target(TYPE)メタアノテーションを使用します。

次の例では、ステレオタイプの定義を示します。

例9-20 ステレオタイプの定義

この例では、ステレオタイプ@Actionを定義します。これは、ステレオタイプが注釈付けする各Beanに対して次のことを指定します。

- デフォルトのスコープは、そのスコープがスコープ・アノテーションでオーバーライドされていないかぎり、Requestスコープです。

- その名前が@Namedアノテーションでオーバーライドされていないかぎり、デフォルトEL名がBeanに割り当てられます。

- インターセプタ・バインディング@Secureおよび@TransactionalがBeanに適用されます。これらのインターセプタ・バインディングの定義は、この例の範囲外です。

import javax.enterprise.inject.Stereotype;
import javax.inject.Named;
import javax.enterprise.context.RequestScoped;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;

@RequestScoped
@Secure
@Transactional
@Named
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

Beanへのステレオタイプの適用

Beanにステレオタイプを適用するには、適用する各ステレオタイプで、そのBeanのクラス宣言に注釈付けします。Beanには任意の数のステレオタイプを適用できます。Beanに適用するステレオタイプは、「ステレオタイプの定義」の説明に従って定義する必要があります

例9-21は、Beanにステレオタイプを適用する方法を示します。

例9-21 Beanへのステレオタイプの適用

この例では、ステレオタイプ@Actionおよび@MockをBeanクラスMockLoginActionに適用します。@Actionステレオタイプの定義を、例9-20に示します。@Mockステレオタイプの定義は、この例の範囲外です。

@Action
@Mock
public class MockLoginAction extends LoginAction {
...
}

Bean間の通信のためのイベントの使用方法

実行時に、アプリケーションで、情報を生成する処理が実行されたり、状態の変更が発生し、Bean間の通信が必要となる場合があります。たとえば、アプリケーションで、アプリケーションのアーキテクチャの1つの層のステートフルBeanがそれらの内部状態を、別の層で発生する状態の変更と同期することが必要な場合があります。

イベントを使用すると、Beanはコンパイル時の依存関係なしにこの情報を通信できます。1つのBeanでイベントを定義し、別のBeanでイベントを送信し、さらに別のBeanでそのイベントを処理できます。これらのBeanは、それぞれ別のパッケージに含めることができ、アプリケーションの別の層に含めることもできます。詳細は、Java EE 7チュートリアルのイベントの使用方法に関する項を参照してください。

Bean間の通信のためのイベントの使用には、次の項で説明するタスクが含まれます。

- イベント・タイプの定義

- イベントの送信

- イベントの処理

イベント・タイプの定義

イベント・タイプは、Bean間で通信する情報を表すJavaクラスです。たとえば、イベント・タイプは、ステートフルBeanがアプリケーションの別の層における状態の変更と同期する必要がある状態情報を表す場合があります。

Bean間で通信する変更のセットごとにイベントのタイプを定義します。

イベント・タイプを定義する手順は、次のとおりです。

1. そのイベント・タイプを表すJavaクラスを定義します。

そのクラスが、次の要件を満たすようにします。

- クラスが具体Javaクラスとして宣言されています。

- クラスにタイプ変数がありません。
イベントのイベント・タイプには、イベント・オブジェクトのランタイム・クラスのすべてのスーパークラスとインタフェースが含まれます。イベント・タイプには、タイプ変数を含めないでください。どのJavaタイプも監視対象のイベント・タイプにできます。

2. 必要であれば、このタイプのイベントをさらに区別するための修飾子を定義します。詳細は、「Beanタイプの実装に対する修飾子の定義」を参照してください

3. クラスにコードを指定して、クラスからインスタンス化されるイベント・オブジェクトのイベント・ペイロードを移入します。

イベント・ペイロードとは、そのイベントに含める情報です。getterおよびsetterメソッドとともにJavaBeansプロパティを使用して、イベント・ペイロード内の情報のアイテムを表すことができます。

イベントの送信

処理に応じて発生した変更を通信するには、アプリケーションが、処理を実行するときに正しいタイプのイベントを送信する必要があります。CDIは、実行時にアプリケーション・コードがイベントを送信し、関連付けられた修飾子を選択できるようにする事前定義済イベント・ディスパッチャ・オブジェクトを提供しています。

イベントを送信する手順は、次のとおりです。

1. 送信するイベント・タイプのインスタンスを取得します。

2. 送信するイベント・オブジェクトのイベント・ペイロードを移入するためのイベント・インスタンスのメソッドをコールします。

3. パラメータ化javax.enterprise.event.Eventインタフェースのインスタンスを注入します。

修飾イベントを送信する場合、イベント修飾子で注入ポイントに注釈付けします。

4. 注入されるEventインスタンスのfireメソッドをコールします。

fireメソッドへのコールで、送信するイベント・インスタンスをパラメータとして渡します。

例9-22は、イベントを送信する方法を示します。

例9-22 イベントの送信

この例では、修飾子@LoggedInで、タイプUserのイベントのインスタンスを注入します。fireメソッドは、@LoggedIn修飾子が適用されるUserイベントのみを送信します。

import javax.enterprise.event.Event;
import javax.enterprise.context.SessionScoped;
import javax.inject.Inject;
import java.io.Serializable;

@SessionScoped
public class Login implements Serializable {

@Inject @LoggedIn Event<User> userLoggedInEvent;
private User user;

public void login(Credentials credentials) {

//... use credentials to find user

if (user != null) {
userLoggedInEvent.fire(user);
}
}
...
}

イベントの処理

どのCDIマネージドBeanクラスもイベントを処理できます。

イベントを処理する手順は、次のとおりです。

1. Beanクラスでは、イベントを処理するメソッドを定義します。

注意:

修飾子をイベント・タイプに適用する場合、修飾されるタイプごとに1つのメソッドを定義します。

2. メソッドのシグネチャで、メソッドにイベントを渡すためのパラメータを定義します。

パラメータのタイプは、必ずイベントのJavaタイプと同一になるようにします。

3. javax.enterprise.event.Observesアノテーションで、メソッド・シグネチャのパラメータに注釈付けします。

必要であれば、メソッドが条件付であるかトランザクションであるかを指定する@Observesアノテーションの要素を設定します。詳細は、Java EE 7チュートリアルのオブザーバ・メソッドを使用したイベントの処理に関する項を参照してください。

4. イベント・タイプが修飾されている場合は、注釈付けされるパラメータに修飾子を適用します。

5. メソッド本体に、イベント・オブジェクトのイベント・ペイロードを処理するためのコードを指定します。

例9-23は、特定のタイプの修飾されたイベントを受信するためのオブザーバ・メソッドを宣言する方法を示します。例9-24は、特定のタイプのすべてのイベントを受信するためのオブザーバ・メソッドを宣言する方法を示します。

例9-23 特定のタイプの修飾されたイベントの処理

この例では、@Observesアノテーションと@LoggedIn修飾子でパラメータuserが注釈付けされているafterLoginメソッドを宣言します。このメソッドは、修飾子@LoggedInが付いたタイプUserのイベントが送信されるときにコールされます。

import javax.enterprise.event.Observes;

public void afterLogin(@Observes @LoggedIn User user) {
...
}

例9-24 特定のタイプのイベントの処理

この例では、@Observesアノテーションでパラメータuserが注釈付けされているafterLoginメソッドを宣言します。このメソッドは、タイプUserのイベントが送信されるときにコールされます。

import javax.enterprise.event.Observes;

public void afterLogin(@Observes User user) {
...
}

事前定義済Beanの注入

CDIは、次のインタフェースを実装する事前定義済Beanを提供しています。

javax.transaction.UserTransaction

Java Transaction API (JTA)ユーザー・トランザクション。

java.security.Principal

個人、企業、ログインIDなどのエンティティを表すプリンシパルの抽象的な観念。

プリンシパルは、現在のコール元のIDを表します。注入されたプリンシパルにアクセスする場合はいつでも、それは常に現在のコール元のIDを表します。

たとえば、プリンシパルは、初期化の際にフィールドに注入されます。後で、プリンシパルが注入されたオブジェクトに対して、注入されたプリンシパルを使用するメソッドがコールされます。この状況では、注入されたプリンシパルは、メソッドが実行されるときの現在のコール元のIDを表します。

javax.validation.Validator

Beanインスタンスのバリデータ。

このインタフェースを実装するBeanによって、デフォルトのBean検証ValidatorFactoryオブジェクトのValidatorオブジェクトを注入できます。

javax.validation.ValidatorFactory

初期化されたValidatorインスタンスを返すファクトリ・クラス。

このインタフェースを実装するBeanによって、デフォルトのBean検証ValidatorFactoryオブジェクトを注入できます。

事前定義済Beanを注入するには、javax.annotation.Resourceアノテーションを使用して、Beanのインスタンスを取得することで、注入ポイントを作成します。Beanタイプについては、Beanによって実装されるインタフェースのクラス名を指定します。

事前定義済Beanは、Dependentスコープおよび事前定義済のデフォルト修飾子@Defaultが指定されて注入されます。

リソースの注入の詳細は、Java EE 7チュートリアルのリソースの注入に関する項を参照してください。

例9-25は、@Resourceアノテーションを使用して事前定義済Beanを注入する方法を示します。

例9-25 事前定義済Beanの注入

この例では、サーブレット・クラスTransactionServletにユーザー・トランザクションを注入します。ユーザー・トランザクションは、javax.transaction.UserTransactionインタフェースを実装する事前定義済Beanのインスタンスです。

import javax.annotation.Resource;
import javax.servlet.http.*;
...
public class TransactionServlet extends HttpServlet {
@Resource UserTransaction transaction;
...
}

リソースの注入と修飾

Java EE 5のリソース注入は、構成の文字列に依存しています。通常、これらの文字列は、オブジェクトが作成されるときに解決されるJNDI名です。CDIでは、注入ポイントで指定されているJavaタイプに基づいてBeanクラスを選択することで、Beanの型保証注入が保証されます。

CDI Beanクラスでも、データ・ソース、Java Message Service (JMS)リソース、Webサービス参照など実際のリソースにアクセスするには、Java EE 5のリソース注入が必要です。CDI Beanクラスは、Java EE 5のリソース注入を使用できるため、プロデューサ・フィールドを使用して、Java EE 5のリソース注入への依存を最小限にできます。このようにすることで、CDIでは、適切なリソースにアクセスするために必要な構成をカプセル化する方法が簡素化されます。

Java EE 5のリソース注入への依存を最小限にする手順は、次のとおりです。

1. アプリケーション内の1箇所のみで、Java EE 5のリソース注入を使用します。

2. プロデューサ・フィールドを使用して、注入されるリソース・タイプをCDI Beanに変換します。
このCDI Beanは、他のCDI Beanと同様にアプリケーションに注入できます。

プロデューサ・フィールドの詳細は、「プロデューサ・フィールドの定義」を参照してください

次の例は、Java EE 5アノテーションを使用してリソースを注入する方法を示します。

import javax.annotation.Resource;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceUnit;
import javax.ejb.EJB;
import javax.xml.ws.WebServiceRef;
...
public class SomeClass {

@WebServiceRef(lookup="java:app/service/PaymentService")
PaymentService paymentService;

@EJB(ejbLink="../payment.jar#PaymentService")
PaymentService paymentService;

@Resource(lookup="java:global/env/jdbc/CustomerDatasource")
Datasource customerDatabase;

@PersistenceContext(unitName="CustomerDatabase")
EntityManager customerDatabasePersistenceContext;

@PersistenceUnit(unitName="CustomerDatabase")
EntityManagerFactory customerDatabasePersistenceUnit;

...
}

次の例は、CDIプロデューサ・フィールドとJava EE 5のリソース注入を結合することで、同じリソースのセットを注入する方法を示します。

SomeClassクラスの宣言は、このBeanのスコープをApplicationに設定する@ApplicationScopedで注釈付けされています。@Dependentスコープは、プロデューサ・フィールドに暗黙的に適用されます。

import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.inject.Produces;
import javax.annotation.Resource;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceUnit;
import javax.ejb.EJB;
javax.xml.ws.WebServiceRef;
...
@ApplicationScoped
public class SomeClass {

@Produces
@WebServiceRef(lookup="java:app/service/PaymentService")
PaymentService paymentService;

@Produces
@EJB(ejbLink="../their.jar#PaymentService")
PaymentService paymentService;

@Produces @CustomerDatabase
@Resource(lookup="java:global/env/jdbc/CustomerDatasource")
Datasource customerDatabase;

@Produces @CustomerDatabase
@PersistenceContext(unitName="CustomerDatabase")
EntityManager customerDatabasePersistenceContext;

@Produces @CustomerDatabase
@PersistenceUnit(unitName="CustomerDatabase")
EntityManagerFactory customerDatabasePersistenceUnit;
...
}

CDIでは、CDIとの一貫性を保つようにCDIアプリケーションでJava EEリソースを使用できます。このようにJava EEリソースを使用するには、そのリソースをCDI Beanとして他のBeanに注入します。

次の例は、Java EEリソースをCDI Beanとして別のBeanに注入する方法を示します。

この例では、永続性ユニット・リソースをRequestスコープを持つBeanに注入します。

import javax.enterprise.context.RequestScoped;
import javax.enterprise.inject.Inject;

@RequestScoped
public class SomeOtherClass {
...
@Inject @CustomerDatabase
private EntityManagerFactory emf;
...
}

別のクラス、たとえばYetAnotherClassは、タイプSomeOtherClassのフィールドを注入できます。SomeOtherClassのインスタンスが、現在のリクエスト・コンテキストに存在していない場合は、CDIによって次の一連の処理が実行されます。

1. SomeOtherClassのインスタンスの作成

2. プロデューサ・フィールドを使用することによるエンティティ・マネージャ・ファクトリへの参照の注入

3. 現在のリクエスト・コンテキストでのSomeOtherClassの新しいインスタンスの保存

どの場合も、CDIによって、SomeOtherClassのこのインスタンスへの参照が、YetAnotherClassのフィールドに注入されます。リクエスト・コンテキストが破棄されるときに、SomeOtherClassのインスタンスおよびエンティティ・マネージャ・ファクトリへのその参照が破棄されます。

JCAテクノロジでのCDIの使用方法

WebLogic Serverでは、埋込みリソース・アダプタおよびグローバル・リソース・アダプタでのCDIがサポートされています。CDIに対してリソース・アダプタを有効化するには、リソース・アダプタのパッケージ化されたアーカイブのMETA-INFディレクトリにbeans.xmlファイルを配置します。beans.xmlファイルの詳細は、「CDIアプリケーションの構成」を参照してください

リソース・アダプタのすべてのクラスを、注入に使用できます。次のクラスを除いて、リソース・アダプタのすべてのクラスをCDIマネージドBeanにできます。

- リソース・アダプタBean。これらのBeanは、javax.resource.spi.Connectorアノテーションで注釈付けされているか、リソース・アダプタ・デプロイメント記述子ra.xmlで対応する要素として宣言されているクラスです。

- マネージド接続ファクトリBean。これらのBeanは、javax.resource.spi.ConnectionDefinitionアノテーションまたはjavax.resource.spi.ConnectionDefinitionsアノテーションで注釈付けされているか、ra.xmlで対応する要素として宣言されているクラスです。

- アクティブ化仕様Bean。これらのBeanは、javax.resource.spi.Activationアノテーションで注釈付けされているか、ra.xmlで対応する要素として宣言されてるクラスです。

- 管理対象オブジェクトBean。これらのBeanは、javax.resource.spi.AdministeredObjectアノテーションで注釈付けされているか、ra.xmlで対応する要素として宣言されているクラスです。

CDIアプリケーションの構成

CDIアプリケーションを構成すると、そのアプリケーションに対してCDIサービスが有効化されます。CDIアプリケーションは、そのアプリケーションがCDIアプリケーションとして識別されるように構成する必要があります。CDIマネージドBeanを定義するために、アノテーションなどの特別な宣言は必要ありません。CDIアプリケーションのパッケージ化のために特に定義されているモジュール・タイプはありません。

CDIアプリケーションを構成するには、beans.xmlという名前のファイルを、アプリケーションのパッケージ化されたアーカイブに含めます。beans.xmlファイルは、eXtensible Markup Language (XML)スキーマbeans_1_0.xsdのインスタンスである必要があります。

アプリケーションで代替、インターセプタ、デコレータのいずれも使用しない場合は、beans.xmlファイルを空にできます。ただし、beans.xmlファイルは空であっても提供する必要があります。

CDIアプリケーションで代替、インターセプタまたはデコレータを使用する場合は、それらのアイテムをbeans.xmlファイルで宣言することでそれらを有効化する必要があります。詳細は、次を参照してください:

- アプリケーションに対するBeanタイプの代替の実装の選択

- インターセプタの有効化

- デコレータ・クラスの有効化

beans.xmlファイルの必須の場所は、アプリケーションのタイプに応じて異なります。

- Webアプリケーションの場合は、beans.xmlファイルは、WEB-INFディレクトリ内に配置してください。

- EJBモジュール、リソース・アーカイブ(RAR)ファイル、アプリケーション・クライアントJARファイル、またはライブラリJARファイルの場合は、beans.xmlファイルはMETA-INFディレクトリ内に配置してください。

CDI Beanアーカイブは、EJBモジュールのlibディレクトリに含めることができます。EJBモジュールのlibディレクトリの各CDI BeanアーカイブのMETA-INFディレクトリにbeans.xmlファイルを含める必要があります。

例9-26は、CDIアプリケーションを構成するためのbeans.xmlファイルを示します。

例9-26 CDIアプリケーションを構成するためのbeans.xmlファイル

この例では、次のクラスを有効化することで、CDIアプリケーションを構成します。

- 代替の実装com.example.orderprocessor.MockOrderImpl

- インターセプタ・クラスcom.example.billpayment.interceptor.TransactionInterceptor

- デコレータ・クラスcom.example.billpayment.decorator.DataAccessAuthDecorator

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_1.xsd">
<alternatives>
<class>com.example.orderprocessor.MockOrderImpl</class>
</alternatives>
<interceptors>
<class>com.example.billpayment.interceptor.TransactionInterceptor</class>
</interceptors>
<decorators>
<class>com.example.billpayment.decorator.DataAccessAuthDecorator</class>
</decorators>
</beans>

サード・パーティのポータブルな拡張のサポート

CDIは、フレームワーク、拡張、および他のテクノロジとの統合の基盤となることを目的としています。したがって、CDIは、次のようなCDIへのポータブルな拡張の開発を可能にするSPIを公開しています。

- ビジネス・プロセス管理エンジンとの統合

- Spring、Seam、GWT、Wicketなどサード・パーティのフレームワークとの統合

- CDIプログラミング・モデルに基づいた新しいテクノロジ

CDIへのポータブルな拡張の開発を可能にするSPIは、javax.enterprise.inject.spiパッケージで提供されています。

CDIの拡張のコードは、CDIフレームワークによって送信されるイベントを処理できます。

詳細は、JSR 346: Contexts and Dependency Injection for the Java EE platformのPortable extensionsを参照してください。

暗黙的Beanの検出の有効化と無効化

CDI 1.1およびJava EE 7では、暗黙的Beanアーカイブの概念を導入しました。暗黙的Beanアーカイブは、beans.xmlファイルを持たないアーカイブ(JARファイル、WARファイルなど)です。CDIによって管理できるBeanを持ちます。これは、アプリケーションをデプロイするのにかかる時間を大幅に増やす可能性があります。この時間の増加は、Java EE 7より前のリリース用に作成され、Java EE 7アプリケーション・サーバーにデプロイされたアプリケーションで特に顕著です。

暗黙的なBeanの検出はデフォルトで有効になっています。WebLogic Serverには、WLSTコマンドを使用してこの機能を有効化または無効化する機能があります。

次の例は、オンライン・モードおよびオフライン・モードでWLSTコマンドを使用して暗黙的なBeanの検出を有効化または無効化する方法を示します。

例9-27 オンライン・モードでWLSTを使用する暗黙的Beanの検出の有効化または無効化

次の例では、WLSが稼働している必要があります。'user'と'password'は管理者のユーザーとパスワードにする必要があり、'url'は管理サーバーが稼働しているマシンのURL(たとえば、localhost:7001)にする必要があります。また、'mydomain'はドメイン名と一致する必要があります。

connect('user','password','url')
domainConfig()
edit()
cd('CdiContainer/mydomain')
startEdit()
set('ImplicitBeanDiscoveryEnabled',1)  // 1 to enable 0 to disable
validate()
save()
activate(block="true")

オフライン・モードでWLSTを使用する暗黙的Beanの検出の有効化または無効化

次の例では、'domain'はドメインのパス(たとえば、/oracle/wls/mydomain)にする必要があります。また、'mydomain'はドメイン名と一致する必要があります。

readDomain(domain)
create('mydomain','CdiContainer')
cd('CdiContainer/mydomain')
set('ImplicitBeanDiscoveryEnabled',1)
// 1 to enable 0 to disable
updateDomain()
closeDomain()

10 Java API for JSON Processing

WebLogic Serverでは、JSR-353リファレンス実装を含めることにより、Java API for JSON Processing 1.0 (JSR 353)の仕様をサポートし、これをWebLogic Serverインスタンスにデプロイされるアプリケーションで使用できるようにしています。

この章の内容は次のとおりです。

- JavaScript Object Notation (JSON)について

- オブジェクト・モデルAPI

- ストリーミングAPI

JSONの概念の詳細は、Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/jsonp.htm)の「JSON Processing」の章を参照してください。

JavaScript Object Notation (JSON)について

JSONは軽量なデータ交換形式で、インターネット経由で相互通信するアプリケーションのデータのシリアライズおよびデシリアライズ用の一般的な形式として、広く使用されています。このようなアプリケーションは、異なるプログラミング言語で作成され、まったく異なる環境で実行されることがよくあります。JSONはオープンな標準であり、読取りと書込みが簡単で、他の表現よりコンパクトなため、このような使用例に適しています。RESTful Webサービスでは通常、リクエストとレスポンス内のデータの形式としてJSONが広く利用されており、JSONには終了タグがないため、JSON表現は対応するXML表現よりも通常はコンパクトです。

Java API for JSON Processingは、JSONテキストの処理(解析、生成、変換、問合せ)に便利です。JSONデータの生成および解析用に、XMLドキュメントで使用されるものと同じような2つのプログラミング・モデルが用意されています。

- オブジェクト・モデルでは、メモリー内のJSONデータを示すツリーが作成されます。このツリーは参照と分析が可能です。メモリー内で生成されたJSONデータは不変であり、変更できませんが、オブジェクト・モデルは非常に柔軟で、ツリーのすべてのコンテンツにアクセスする必要がある処理に使用できます。ただし、通常はストリーミング・モデルより低速で、より多くのメモリーが必要です。このオブジェクト・モデルでは、ツリー全体を瞬時に参照して、JSON出力が生成されます。
オブジェクト・モデルの使用方法の詳細は、「オブジェクト・モデルAPI」を参照してください。

- ストリーミング・モデルでは、JSONデータの要素を一度に1つずつ読み取るイベント・ベースのパーサーを使用します。パーサーによってイベントが生成され、オブジェクトや配列の開始または終了時、キーや値の検出時には処理が停止されます。各要素はアプリケーション・コードごとに処理または破棄することができ、パーサーは次のイベントに進みます。このアプローチは、要素の処理に残りのデータからの情報が不要なローカル処理に適しています。ストリーミング・モデルでは、一度に1つの要素を使う関数コールにより、所定のストリームにJSON出力が生成されます。
ストリーミング・モデルの使用方法の詳細は、「ストリーミングAPI」を参照してください。

オブジェクト・モデルAPI

オブジェクト・モデルAPIは、JSONオブジェクトおよび配列構造の不変のオブジェクト・モデルを提供する高レベルなAPIです。これらのJSON構造は、JavaのJsonObject型およびJsonArray型を使用するオブジェクト・モデルとして表現されます。インタフェースjavax.json.JsonObjectにはマップ・ビューがあり、ゼロ(0)個以上の名前/値ペアの、順不同のコレクションにモデルからアクセスできます。同様に、javax.json.JsonArrayインタフェースにはリスト・ビューがあり、ゼロ(0)個以上の連続した値にモデルからアクセスできます。

オブジェクト・モデルAPIでは、ビルダー・パターンを使用してこれらのオブジェクト・モデルを作成します。javax.json.JsonObjectBuilderおよびjavax.json.JsonArrayBuilderインタフェースには、それぞれJsonObject型およびJsonArray型のモデルを作成するメソッドがあります。

これらのオブジェクト・モデルは、javax.json.JsonReaderインタフェースを使用して入力ソースから作成することもできます。同様に、これらのオブジェクト・モデルは、javax.jsonJsonWriterインタフェースを使用して出力ソースに書き込むことができます。

次の各項では、オブジェクト・モデルAPIの使用例を示します。

- JSONデータからのオブジェクト・モデルの作成

- アプリケーション・コードからのオブジェクト・モデルの作成

- オブジェクト・モデルの参照

- ストリームへのオブジェクト・モデルの書込み

JSONデータからのオブジェクト・モデルの作成

次の例では、テキスト・ファイル内のJSONデータからオブジェクト・モデルを作成する方法を示します。

import java.io.FileReader;
import javax.json.Json;
import javax.json.JsonReader;
import javax.json.JsonStructure;
...
JsonReader reader = Json.createReader(new FileReader("jsondata.txt"));
JsonStructure jsonst = reader.read();

オブジェクト参照jsonstは、ファイルの内容に応じてJsonObject型またはJsonArray型のいずれかになります。JsonObjectおよびJsonArrayはJsonStructureのサブタイプです。この参照はツリーの最上位を表したもので、ツリーの参照に使用したり、ストリームにJSONデータとして書き込むことができます。

アプリケーション・コードからのオブジェクト・モデルの作成

次の例では、アプリケーション・コードからオブジェクト・モデルを作成する方法を示します。

import javax.json.Json;
import javax.json.JsonObject;
...
JsonObject model = Json.createObjectBuilder()
.add("firstName", "Duke")
.add("lastName", "Java")
.add("age", 18)
.add("streetAddress", "100 Internet Dr")
.add("city", "JavaTown")
.add("state", "JA")
.add("postalCode", "12345")
.add("phoneNumbers", Json.createArrayBuilder()
.add(Json.createObjectBuilder()
.add("type", "mobile")
.add("number", "111-111-1111"))
.add(Json.createObjectBuilder()
.add("type", "home")
.add("number", "222-222-2222")))
.build();

オブジェクト参照モデルはツリーの最上位を表したもので、addメソッドの呼出しをネストして作成し、buildメソッドを呼び出してビルドします。javax.json.JsonObjectBuilderインタフェースには、次のaddメソッドが含まれています。

JsonObjectBuilder add(String name, BigDecimal value)
JsonObjectBuilder add(String name, BigInteger value)
JsonObjectBuilder add(String name, boolean value)
JsonObjectBuilder add(String name, double value)
JsonObjectBuilder add(String name, int value)
JsonObjectBuilder add(String name, JsonArrayBuilder builder)
JsonObjectBuilder add(String name, JsonObjectBuilder builder)
JsonObjectBuilder add(String name, JsonValue value)
JsonObjectBuilder add(String name, long value)
JsonObjectBuilder add(String name, String value)
JsonObjectBuilder addNull(String name)

javax.json.JsonArrayBuilderインタフェースにも同様のaddメソッドが含まれていますが、name (key)パラメータは使用できません。配列およびオブジェクトをネストするには、この例で示したように、JsonArrayBuilderの新規オブジェクトまたはJsonObjectBuilderの新規オブジェクトを対応するaddメソッドに渡します。

生成されるツリーは、JSON構文で表したJSONデータです。

オブジェクト・モデルの参照

次の例では、オブジェクト・モデルを参照する簡単な方法を示します。

import javax.json.JsonValue;
import javax.json.JsonObject;
import javax.json.JsonArray;
import javax.json.JsonNumber;
import javax.json.JsonString;
...
public static void navigateTree(JsonValue tree, String key) {
if (key != null)
System.out.print("Key " + key + ": ");
switch(tree.getValueType()) {
case OBJECT:
System.out.println("OBJECT");
JsonObject object = (JsonObject) tree;
for (String name : object.keySet())
navigateTree(object.get(name), name);
break;
case ARRAY:
System.out.println("ARRAY");
JsonArray array = (JsonArray) tree;
for (JsonValue val : array)
navigateTree(val, null);
break;
case STRING:
JsonString st = (JsonString) tree;
System.out.println("STRING " + st.getString());
break;
case NUMBER:
JsonNumber num = (JsonNumber) tree;
System.out.println("NUMBER " + num.toString());
break;
case TRUE:
case FALSE:
case NULL:
System.out.println(tree.getValueType().toString());
break;
}
}

navigateTreeメソッドは、「JSONデータからのオブジェクト・モデルの作成」および「アプリケーション・コードからのオブジェクト・モデルの作成」で示したモデルで使用できます。

navigateTree(model, null);

navigateTreeメソッドは2つの引数(JSON要素とキー)を取ります。キーは、オブジェクト内のキー/値のペアを出力する場合にのみ使用します。ツリー内の要素は、JsonValue型で表します。要素がオブジェクトまたは配列の場合、オブジェクトまたは配列に格納されている各要素に対して、このメソッドの新規呼出しが行われます。要素が値の場合は、標準出力に表示されます。

JsonValue.getValueTypeメソッドは、要素がオブジェクト、配列または値のいずれであるかを識別します。オブジェクトの場合、JsonObject.keySetメソッドはオブジェクトのキーが含まれる文字列セットを返し、JsonObject.get(String name)メソッドはキーがnameである要素の値を返します。配列の場合は、JsonArrayにList<JsonValue>インタフェースが実装されます。この例で示したように、JsonObject.keySetによって返されたSet<String>インスタンス、およびJsonArrayのインスタンスには拡張forループを使用できます。

「アプリケーション・コードからのオブジェクト・モデルの作成」で示したモデルでnavigateTreeメソッドを実行すると、次の出力が生成されます。

OBJECT
Key firstName: STRING Duke
Key lastName: STRING Java
Key age: NUMBER 18
Key streetAddress: STRING 100 Internet Dr
Key city: STRING JavaTown
Key state: STRING JA
Key postalCode: STRING 12345
Key phoneNumbers: ARRAY
OBJECT
Key type: STRING mobile
Key number: STRING 111-111-1111
OBJECT
Key type: STRING home
Key number: STRING 222-222-2222

ストリームへのオブジェクト・モデルの書込み

「JSONデータからのオブジェクト・モデルの作成」および「アプリケーション・コードからのオブジェクト・モデルの作成」で作成したオブジェクト・モデルは、次に示すように、javax.json.JsonWriterインタフェースを使用してストリームに書き込むことができます。

import java.io.StringWriter;
import javax.json.JsonWriter;
...
StringWriter stWriter = new StringWriter();
JsonWriter jsonWriter = Json.createWriter(stWriter);
jsonWriter.writeObject(model);
jsonWriter.close();

String jsonData = stWriter.toString();
System.out.println(jsonData);

The Json.createWriter method takes an output stream as a parameter. The JsonWriter.writeObject method writes the object to the stream. The JsonWriter.close method closes the underlying output stream.

The following example uses try-with-resources to close the JSON writer automatically:

StringWriter stWriter = new StringWriter();
try (JsonWriter jsonWriter = Json.createWriter(stWriter)) {
jsonWriter.writeObject(model);
}

String jsonData = stWriter.toString();
System.out.println(jsonData);

ストリーミングAPI

ストリーミングAPIは、大量のJSONデータを効率的に処理できるように設計された、低レベルのAPIです。このAPIは次のインタフェースで構成されます。

インタフェース

説明

javax.json.stream.JsonParser

JSONをストリーミングで解析するメソッドが含まれます。

このインタフェースでは、プル解析プログラミング・モデルを使用して、JSONデータに対し前方/読取り専用アクセスを行うことができます。このモデルでは、アプリケーション・コードを使用して、パーサー・インタフェースでスレッドの制御やメソッドのコールを行い、パーサーを前方に移動したり、現在のパーサーの状態からJSONデータを取得したりできます。

javax.json.stream.JsonGenerator

JSONをストリーミングで出力ソースに書き込むメソッドが含まれます。

このインタフェースには、JSONを出力ソースに書き込むメソッドがあります。ジェネレータによって、名前/値ペアがJSONオブジェクトに、値がJSON配列に書き込まれます。

次の各項では、ストリーミングAPIの使用例を示します。

- パーサーを使用したJSONデータの読取り

- ジェネレータを使用したJSONデータの書込み

パーサーを使用したJSONデータの読取り

ストリーミングAPIは、JSONテキストを解析する上で、最も効率的な方法です。次の例では、JsonParserオブジェクトの作成方法およびイベントを使用してJSONデータを解析する方法を示します。

import javax.json.Json;
import javax.json.stream.JsonParser;
...
JsonParser parser = Json.createParser(new StringReader(jsonData));
while (parser.hasNext()) {
JsonParser.Event event = parser.next();
switch(event) {
case START_ARRAY:
case END_ARRAY:
case START_OBJECT:
case END_OBJECT:
case VALUE_FALSE:
case VALUE_NULL:
case VALUE_TRUE:
System.out.println(event.toString());
break;
case KEY_NAME:
System.out.print(event.toString() + " " +
parser.getString() + " - ");
break;
case VALUE_STRING:
case VALUE_NUMBER:
System.out.println(event.toString() + " " +
parser.getString());
break;
}
}

この例は、次の3つのステップで構成されます。

1. Json.createParser静的メソッドを呼び出して、パーサー・インスタンスを取得します。

2. JsonParser.hasNextメソッドおよびJsonParser.nextメソッドを使用して、パーサー・イベントを繰り返します。

3. 要素ごとにローカル処理を実行します。

この例は、パーサーから生成される可能性のある10個のイベント・タイプを示しています。パーサーのnextメソッドで次のイベントに進みます。

KEY_NAME、VALUE_STRINGおよびVALUE_NUMBERの各イベント・タイプでは、JsonParser.getStringメソッドを呼び出して、要素の内容を取得できます。

VALUE_NUMBERイベントでは、次のメソッドを使用することもできます。

START_OBJECT
KEY_NAME firstName - VALUE_STRING Duke
KEY_NAME lastName - VALUE_STRING Java
KEY_NAME age - VALUE_NUMBER 18
KEY_NAME streetAddress - VALUE_STRING 100 Internet Dr
KEY_NAME city - VALUE_STRING JavaTown
KEY_NAME state - VALUE_STRING JA
KEY_NAME postalCode - VALUE_STRING 12345
KEY_NAME phoneNumbers - START_ARRAY
START_OBJECT
KEY_NAME type - VALUE_STRING mobile
KEY_NAME number - VALUE_STRING 111-111-1111
END_OBJECT
START_OBJECT
KEY_NAME type - VALUE_STRING home
KEY_NAME number - VALUE_STRING 222-222-2222
END_OBJECT
END_ARRAY
END_OBJECT

ジェネレータを使用したJSONデータの書込み

次の例では、ストリーミングAPIを使用してJSONデータをファイルに書き込む方法を示します。

FileWriter writer = new FileWriter("test.txt");
JsonGenerator gen = Json.createGenerator(writer);
gen.writeStartObject()
.write("firstName", "Duke")
.write("lastName", "Java")
.write("age", 18)
.write("streetAddress", "100 Internet Dr")
.write("city", "JavaTown")
.write("state", "JA")
.write("postalCode", "12345")
.writeStartArray("phoneNumbers")
.writeStartObject()
.write("type", "mobile")
.write("number", "111-111-1111")
.writeEnd()
.writeStartObject()
.write("type", "home")
.write("number", "222-222-2222")
.writeEnd()
.writeEnd()
.writeEnd();
gen.close();

この例では、ライター・ストリームまたは出力ストリームをパラメータとして取るJson.createGenerator静的メソッドを呼び出して、JSONジェネレータを取得します。例では、write、writeStartArray、writeStartObjectおよびwriteEndの各メソッドの呼出しをネストして、JSONデータをtest.txtファイルに書き込みます。JsonGenerator.closeメソッドで、内部のライター・ストリームまたは出力ストリームを閉じます。

11 WebLogic Serverアプリケーションのクラスローディングの理解

この章では、JavaクラスローダーおよびWebLogic Server Java EEアプリケーションのクラスローディングについて説明します。

この章の内容は次のとおりです。

- Javaのクラスローディング

- WebLogic Serverアプリケーションのクラスローディング

- モジュールおよびアプリケーション間のクラス参照の解決

- クラスローダー分析ツール(CAT)の使用

- Java EEライブラリを使用したアプリケーションとモジュールの共有

- ドメイン/libディレクトリへのJARの追加

Javaのクラスローディング

クラスローダーは、Java言語の基本的モジュールです。クラスローダーは、Java仮想マシン(JVM)の構成要素で、クラスをメモリーにロードし、実行時にクラス・ファイルを検索してロードする役割があります。Javaプログラミングを適切に行うためには、クラスローダーとその機能をよく理解する必要があります。この項では、Javaクラスローダーの概要を説明します。

Javaクラスローダーの階層

クラスローダーには、親クラスローダーおよび子クラスローダーからなる階層が含まれます。親クラスローダーと子クラスローダーの関係は、オブジェクトのスーパークラスとサブクラスの関係に似ています。ブート・ストラップ・クラスローダーはJavaクラスローダー階層のルートです。Java仮想マシン(JVM)では、ブート・ストラップ・クラスローダーを作成し、このクラスローダーによって、Java Development Kit (JDK)の内部クラスおよびJVMに組み込まれているjava.*パッケージがロードされます。(java.lang.Stringなどがロードされます。)

拡張クラスローダーは、ブート・ストラップ・クラスローダーの子です。拡張クラスローダーは、JDKの拡張ディレクトリにあるすべてのJARファイルをロードします。この機能は、クラスパスにエントリを追加することなくJDKを拡張できるので便利です。ただし、拡張ディレクトリ内にあるものは、すべて完全に独立している必要があり、拡張ディレクトリに含まれているクラスまたはJDKクラスしか参照できません。

システム・クラスパス・クラスローダーは、JDK拡張クラスローダーを拡張します。システム・クラスパス・クラスローダーは、JVMのクラスパスからクラスをロードします。アプリケーション固有のクラスローダー(WebLogic Serverのクラスローダーなど)は、システム・クラスパス・クラスローダーの子です。

注意:

Oracleで「システム・クラスパス・クラスローダー」と呼んでいるクラスローダーは、多くの場合、WebLogic Server以外の文脈上では、「アプリケーション・クラスローダー」と呼ばれています。WebLogic Serverにおけるクラスローダーについて説明する際には、Java EEアプリケーションまたはライブラリ関連のクラスローダー(「アプリケーション・クラスローダー」と呼ぶ)と区別するために「システム」という用語を使用します。

クラスのロード

クラスローダーでは、クラスのロード時に委任モデルを使用します。クラスローダーの実装では、まずキャッシュをチェックして、リクエストされたクラスがすでにロードされていないか確認します。クラスを確認することで、ディスクからクラスを繰返しロードする代わりに、キャッシュ・メモリーのコピーが使用されるのでパフォーマンスが向上します。キャッシュにクラスがなければ、現在のクラスローダーが親にクラスを要求します。親クラスローダーがクラスをロードできない場合のみクラスローダーはクラスのロードを試行します。親と子両方のクラスローダーにクラスがあると、親のクラスがロードされます。この委任モデルに従うのは、複数の同じ形式のコピーがロードされることを防ぐためです。同じクラスのコピーが複数あると、ClassCastExceptionが発生する可能性があります。

クラスローダーは、親クラスローダーにクラスのロードを要求してから、クラスを実際にロードします。Webアプリケーションと関連するWebLogic Serverのクラスローダーは、クラスを親に要求する前にまずローカルをチェックするように構成できます。これにより、Webアプリケーションは独自のサード・パーティ・クラスを使用できるようになります。このサード・パーティ・クラスは、WebLogic Server製品の一部として使用することも可能な場合があります。「prefer-web-inf-classes要素」節では、これについてより詳細に説明しています。

prefer-web-inf-classes要素

weblogic.xml Webアプリケーションのデプロイメント記述子には、<prefer-web-inf-classes要素(<container-descriptor要素のサブ要素)が含まれています。デフォルトでは、この要素はFalseに設定されています。この要素をTrueに設定すると、クラスローダーの委任モデルが無効になり、Webアプリケーションからのクラス定義のほうが、より高度なクラスローダーのクラス定義よりも優先的にロードされるようになります。このため、Webアプリケーションは独自バージョンのサード・パーティ・クラスを使用できるようになります。このクラスは、WebLogic Serverの一部としても使用できる場合があります。「weblogic.xmlデプロイメント記述子の要素」を参照してください。

この機能を使用する場合は、Webアプリケーションのクラス定義から作成されたインスタンスと、サーバーの定義から作成されたインスタンスを混在させないように注意してください。これらのインスタンスが混在していると、ClassCastExceptionが発生します。

例11-1はprefer-web-inf-classes要素とその定義およびデフォルト値を示します。

例11-1 prefer-web-inf-classes要素

/**
* If true, classes located in the WEB-INF directory of a web-app will be
* loaded in preference to classes loaded in the application or system
* classloader.
* @default false
*/
boolean isPreferWebInfClasses();
void setPreferWebInfClasses(boolean b);

実行中プログラムのクラス変更

WebLogic Serverでは、サーバーが稼働中にEJBなどのアプリケーション・モジュールの新しいバージョンをデプロイできます。このプロセスは、ホット・デプロイ、またはホット再デプロイと呼ばれ、クラスのロードと密接な関係があります。

Javaクラスローダーには、クラスをアンデプロイしたり、アンロードしたりする標準メカニズムはありません。また、新しいバージョンのクラスをロードすることもできません。実行中の仮想マシンでクラスを更新するには、変更されるクラスをロードしたクラスローダーを、新しいクラスローダーに置き換える必要があります。クラスローダーが置き換えられると、そのクラスローダー(または、そのクラスローダーの子に当たるクラスローダー)からロードされたすべてのクラスを、再ロードする必要があります。また、これらのクラスのインスタンスはすべて、再インスタンス化する必要があります。

WebLogic Serverでは、各アプリケーションに、システム・クラスローダーの子に当たるクラスローダーからなる階層があります。これらの階層により、アプリケーションまたはアプリケーションの一部が、システムの他の部分に影響を与えることなく個別に再ロード可能です。「WebLogic Serverアプリケーションのクラスローディング」で、このトピックについて説明しています。

ポリシー・クラスローダーを使用したクラス・キャッシング

ポリシー・クラスローダーは、startWebLogicスクリプトを使用してWebLogicサーバーを起動する際のデフォルトのシステム・クラスローダーです。ポリシー・クラスローダーは、クラス・キャッシングおよび索引付けを通じてクラスローダーのパフォーマンスおよびサーバー起動時間を向上し、あらゆるWebLogicモード(開発または本番)でサポートされています。

ポリシー・クラスローダーはロードされたクラスをキャッシュ・ファイルにキャッシュします。それ以降の起動時に、キャッシュされたクラスはバルクに事前ロードされ、サーバー起動など、システム・クラスローダーから多数のクラスをロードするケースでパフォーマンスを向上します。ポリシー・クラスローダーには即時索引も含まれ、これによりソース・コードを含むパッケージ名とJARファイルをマップします。この索引はクラスの参照時間を改善し、欠落しているクラスまたはリソースを探す時間を削減します。キャッシュされたファイルはDOMAIN_HOME/servers/weblogic_name/cache/classloaderディレクトリで生成されます。

WebLogic Server 12.1.3では、startWebLogicスクリプトでCLASS_CACHEの環境変数を設定すると、開発モードでクラス・キャッシングを有効にできます。既存の12.1.3起動スクリプトでは、CLASS_CACHE変数を引き続き使用してクラス・キャッシングを有効にします。『Oracle WebLogic Serverアプリケーションの開発 12c (12.1.3)』のクラス・キャッシングの構成に関する項を参照してください。

WebLogic Server 12.2.1では、新しいドメインがデフォルトでクラス・キャッシングにポリシー・クラスローダーを使用します。12.2.1にアップグレードする12.1.3ドメインではすべて自動的にポリシー・クラスローダーも使用します。

WebLogic Serverアプリケーションのクラスローディング

次の項では、WebLogic Serverアプリケーション・クラスローダーの概要を説明します。

- WebLogic Serverアプリケーションのクラスローディングの概要

- アプリケーション・クラスローダーの階層

- カスタム・モジュール・クラスローダーの階層

- 実装クラスのための個々のEJBクラスローダー

- アプリケーション・クラスローディングと、値渡しまたは参照渡し

- フィルタリング・クラスローダーの使用

WebLogic Serverアプリケーションのクラスローディングの概要

WebLogic Serverのクラスローディングは、アプリケーションの概念に基づいています。アプリケーションは、通常、アプリケーション・クラスを含むエンタープライズ・アーカイブ(EAR)ファイルにパッケージ化されています。EARファイル内にあるものは、すべて同じアプリケーションの一部と見なされます。次のファイルは、EARの一部になることもでき、またスタンドアロンのアプリケーションとしてロードすることも可能です。

- Enterprise JavaBean (EJB) JARファイル

- WebアプリケーションWARファイル

- リソース・アダプタRARファイル

注意:

詳細については、次の各項を参照してください。

- リソース・アダプタとクラスローディングについては、「リソース・アダプタ・クラス」を参照してください。

- クラスローディング時の一般的なアプリケーション・ファイルのオーバーライド方法の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の汎用ファイル・ロード・オーバーライドに関する項を参照してください。

EJBとWebアプリケーションを別々にデプロイすると、これらは2つのアプリケーションと見なされます。2つのファイルをまとめてEARファイル内にデプロイすれば、1つのアプリケーションとなります。したがって、複数のモジュールが同一アプリケーションの一部と見なされるためには、複数のモジュールをまとめてEARファイルにデプロイします。

すべてのアプリケーションは、独自のクラスローダー階層を受け取ります。この階層の親はシステム・クラスパス・クラスローダーです。したがって、アプリケーションどうしが分離されているため、アプリケーションAからアプリケーションBのクラスローダーおよびクラスを見ることはできません。階層クラスローダーには、兄弟概念またはフレンド概念はありません。アプリケーション・コードは、アプリケーション(またはモジュール)と関連するクラスローダーでロードされたクラス、およびアプリケーション(またはモジュール)クラスローダーの祖先に当たるクラスローダーでロードされたクラスからしか見えません。したがって、WebLogic Serverは同一のJVM内の複数の分離したアプリケーションのホストになります。

アプリケーション・クラスローダーの階層

WebLogic Serverでは、アプリケーションのデプロイ時にクラスローダーの階層が自動的に作成されます。この階層のルート・クラスローダーは、アプリケーション内のすべてのEJB JARファイルをロードします。また、WebアプリケーションWARファイルごとに子クラスローダーが作成されます。

WebアプリケーションによるEJBの呼出しがよくあるため、WebLogic Serverアプリケーション・クラスローダー・アーキテクチャではJavaServer Page (JSP)ファイルおよびサーブレットからその親クラスローダー内のEJBインタフェースを見ることができるようになっています。また、このアーキテクチャではEJB層を再デプロイすることなくWebアプリケーションを再デプロイできます。実際には、EJB層ではなくJSPファイルおよびサーブレットを変更するほうが一般的です。

次の図は、WebLogic Serverアプリケーションのクラスローディング概念を示しています。

図11-1 WebLogic Serverのクラスローディング

アプリケーションにEJBを使用するサーブレットとJSPが含まれる場合:

- サーブレットとJSPをWARファイルにパッケージ化します。

- Enterprise JavaBeansをEJB JARファイルにパッケージ化します。

- このWARファイルとJARファイルをEARファイルにパッケージ化します。

- パッケージ化したEARファイルをデプロイします。

WARファイルとJARファイルは別々にデプロイできますが、まとめて1つのEARファイルにしてデプロイすることにより、サーブレットとJSPからEJBクラスを検索できるようにクラスローダーが配置されます。WARファイルとJARファイルを別々にデプロイすると、WebLogic Serverではそれらのファイルごとに兄弟クラスローダーを作成します。したがって、そのWARファイルにはEJBホームおよびリモート・インタフェースを含める必要があり、WebLogic Serverでは、EJBクライアントと実装クラスが異なるJVMにある場合と同様に、EJB呼出しにRMIのスタブ・クラスとスケルトン・クラスを使用する必要があります。この概念については、次の「アプリケーション・クラスローディングと、値渡しまたは参照渡し」の項で詳しく説明しています。

注意:

Webアプリケーション・クラスローダーには、JSPクラスを除く、Webアプリケーションのすべてのクラスが含まれます。JSPクラスは、独自のクラスローダーを取得します。これは、Webアプリケーション・クラスローダーの子に当たります。これにより、JSPを個別に再ロードできます。

カスタム・モジュール・クラスローダーの階層

アプリケーション用のカスタム・クラスローダーの階層を作成して、クラスの可視性や再ロードを制御しやすくすることができます。この機能を実現するには、weblogic-application.xmlデプロイメント記述子ファイルでclassloader-structure要素を定義します。

次の図は、WebLogicアプリケーションにおいてクラスローダーがデフォルトではどのように構成されているかを示します。アプリケーション・レベルのクラスローダーは、すべてのEJBクラスがロードされている場所にあります。各Webモジュールについて、そのモジュールのクラス用の子クラスローダーが個別に存在します。

簡素化のため、次の図ではJSPクラスローダーを示していません。

図11-2 標準的なクラスローダーの階層

この階層は、EJB呼出し時にcall-by-referenceセマンティクスを使用できるようになるため、大半のアプリケーションにとって最適です。また、これにより他のモジュールに影響を与えることなくWebモジュールを個別に再ロードできるようになります。さらに、Webモジュールの1つで実行されているコードが、任意のEJBモジュールからのクラスをロードできるようになります。これは、使用しているEJBのインタフェースがWebモジュールに含まれることを防げるため便利です。これらの利点のいくつかは、厳密にはJava EEに準拠していないことに注意してください。

カスタム・モジュール・クラスローダーを作成できると、以下のことが可能になる代替的なクラスローダー構成を宣言するメカニズムが得られます。

- 個々のEJBモジュールを単独で再ロード

- モジュールのグループを、一緒に再ロード

- 特定のWebモジュールとEJBモジュールの親子関係を逆転

- EJBモジュール間でネームスペースを分離

クラスローダーの階層の宣言

Weblogic固有のアプリケーション・デプロイメント記述子weblogic-application.xml内でクラスローダーの階層を宣言できます。

この宣言のDTDは次のとおりです。

<!ELEMENT classloader-structure (module-ref*, classloader-structure*)>
<!ELEMENT module-ref (module-uri)>
<!ELEMENT module-uri (#PCDATA)>

weblogic-application.xmlの最上位要素には、オプションclassloader-structure要素が含まれます。この要素を指定しない場合は、標準のクラスローダーが使用されます。また、定義の中に特定のモジュールを含めなかった場合、標準的な階層と同様にクラスローダーが割り当てられます。つまり、EJBモジュールはアプリケーションのルート・クラスローダーと関連付けられ、Webアプリケーション・モジュールは独自のクラスローダーを持ちます。

classloader-structure要素により、classloader-structureスタンザのネスティングが可能になって、クラスローダーの任意階層を記述できるようになります。現在は、3レベルに制限されています。最も外側のエントリは、アプリケーション・クラスローダーを示します。リストされていないモジュールについては、標準的な階層であると仮定されます。

注意:

JSPクラスローダーは、この定義スキームには含まれません。JSPは常に、所属するWebモジュールと関連のクラスローダーの子クラスローダーにロードされます。

DTD要素の詳細は、エンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。

以下は、クラスローダーの宣言例です(weblogic-application.xmlのclassloader-structure要素で定義)。

<classloader-structure>
<module-ref>
<module-uri>ejb1.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web3.war</module-uri>
</module-ref>

<classloader-structure>
<module-ref>
<module-uri>web1.war</module-uri>
</module-ref>
</classloader-structure>

<classloader-structure>
<module-ref>
<module-uri>ejb3.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web2.war</module-uri>
</module-ref>

<classloader-structure>
<module-ref>
<module-uri>web4.war</module-uri>
</module-ref>
</classloader-structure>
<classloader-structure>
<module-ref>
<module-uri>ejb2.jar</module-uri>
</module-ref>
</classloader-structure>
</classloader-structure>
</classloader-structure>

ネスティングの構成は、クラスローダーの階層を示します。上記のスタンザにより、次の図に示す階層がもたらされます。

図11-3 クラスローダーの階層の例

ユーザー定義のクラスローダーの制約

ユーザー定義のクラスローダーの制約により、再ロードできるものが制御しやすくなり、モジュール間でのクラスの可視性が提供されます。この特徴は主に開発者のためのものです。繰返し開発が行われる場合には有用ですが、本番環境で使用する目的の場合には再ロード機能の使用はお薦めしません。更新時に無効な要素が含まれると、実行中のアプリケーションが破損するおそれがあるためです。ネームスペースの分離とクラス可視性のためのカスタム・クラスローダーの配置は、本番環境で使用する場合においても容認できるものです。ただし、Java EE仕様にはアプリケーションがいかなるクラスローダー構成にも依存してはならないと書いてあることに、プログラマは注意する必要があります。

一部のクラスローダー階層は、アプリケーション内のモジュールが2つの別個のアプリケーションのモジュールのように動作する原因となる可能性があります。たとえば、EJBを独自のクラスローダーに配置して個別に再ロードできるようにすると、Oracleが標準的なクラスローダー階層に提供しているcall-by-referenceによる最適化ではなく、call-by-valueセマンティクスを受け取ります。また、カスタム階層を使用すると、参照が古いものになる可能性があります。したがって、EJBモジュールを再ロードする場合は、呼出し側モジュールも再ロードしてください。

ユーザー定義によるモジュール・クラスローダー階層の作成には、いくつかの制約があります。これらについてはこれ次の項で説明します。

サーブレット再ロードの無効化

カスタム・クラスローダー階層を使用する場合は、その特定のアプリケーションにおけるWebアプリケーションについては、サーブレットの再ロードは無効化されます。

ネスティングの深さ

ネスティングは、3つのレベルまでに制限されています(アプリケーション・クラスローダーを含む)。ネスティングが深くなると、デプロイメント例外が発生します。

モジュール・タイプ

カスタム・クラスローダー階層は、現在はWebおよびEJBモジュールに限定されています。

重複エントリ

エントリが重複すると、デプロイメント例外が発生します。

インタフェース

標準のWebLogic Serverクラスローダー階層により、EJBインタフェースがアプリケーション内のすべてのモジュールで利用可能になります。したがって、それ自体のモジュールにインタフェースが含まれていなくても、他のモジュールがEJBを呼び出せます。これが可能なのは、EJBは常にルート・クラスローダーにロードされ、その他のモジュールはすべてそのクラスローダーを共有するか、そのクラスローダーの子に相当するクラスローダーを持つことになるためです。

カスタム・クラスローダー機能があれば、呼び出される側のクラスが呼出し側から見えないようにクラスローダー階層を構成することが可能です。この場合、呼出し側モジュールにインタフェース・クラスを含める必要があります。これは、別個のアプリケーションのモジュールに対して呼出しを行っている場合の要件と同じです。

call-by-valueセマンティクス

WebLogic Serverに設けられた標準クラスローダー階層により、アプリケーション内のモジュール間での呼出しでcall-by-referenceセマンティクスを使用することが可能となります。これは、呼出し側が常に同じクラスローダーまたは呼び出される側の子クラスローダーを使用しているためです。この機能により、2つのモジュールがクラスローダー・ツリーにおける別々のブランチに存在するように、クラスローダー階層を構成することが可能になります。この場合、call-by-valueセマンティクスが使用されます。

処理中の作業

再ロードに必要となるクラスローダーの切替えは、複数モジュールに渡って原子性を保たないことに留意してください。実際、アプリケーションの更新は、一般に原子性を保ちません。この理由により、タイミングによっては、異なった処理中の操作(変更が行われているときに発生している操作)が、異なったバージョンのクラスにアクセスすることになる可能性があります。

開発用途のみ

development-use-only機能は、開発に使用することが意図されています。更新は原子性を保たないので、この機能は本番に使用するには適していません。

実装クラスのための個々のEJBクラスローダー

WebLogic Serverを使うと、他のモジュールを同時に再ロードして、EJBモジュール全体を再デプロイする必要なしに、個々のEJBモジュールを再ロードできます。この機能は、現在JSPがWebLogic Serverサーブレットのコンテナに再ロードされている方法に類似しています。

EJBクラスはインタフェースを通じて呼び出されるため、個々のEJB実装クラスをそれ自身のクラスローダーにロードすることが可能です。このようにして、これらのクラスはEJBモジュール全体を再デプロイすることなく個別に再ロードできます。次の図は、単一のEJBモジュールのクラスローダー階層の一例です。2つのEJB (FooおよびBar)が含まれています。これは、前の項で説明した一般的なアプリケーション階層におけるサブツリーと考えられます。

図11-4 単一のEJBモジュールのクラスローダー階層の例

展開されたアプリケーションのルートを基準とした相対的な場所にあるファイルの部分的な更新を実行するには、次のコマンド・ラインを使用します。

例11-2 部分的ファイル更新の実行

java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy myejb/foo.class

-redeployコマンドの後で、更新したい展開アプリケーションのルートを基準として相対的にファイルのリストを指定します。これは、(上記のような)特定の要素へのパスであっても、モジュール(または任意の要素およびモジュールのセット)へのパスであってもかまいません。例:

例11-3 更新のための相対ファイル・リストの指定

java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy mywar myejb/foo.class anotherejb

更新するファイル群を指定されると、システムは再デプロイの最小要件を計算しようとします。EJB implクラスのみを再デプロイすると、そのクラスのみが再デプロイされることになります。EJB全体(上の例ではanotherejb)を指定するか、またはEJBホーム・インタフェースを変更して更新する場合、EJBモジュール全体の再デプロイが必要です。

クラスローダーの階層によっては、この再デプロイメントで他のモジュールが再デプロイされることになる可能性があります。具体的には、他のモジュールがEJBクラスローダーを共有する場合や、(WebLogic Serverの標準クラスローダー・モジュールのように) EJBクラスローダーの子クラスローダーにロードされる場合は、これらのモジュールも再ロードされます。

アプリケーション・クラスローディングと、値渡しまたは参照渡し

最近のプログラミング言語では、パラメータを渡すときのモデルとして、値渡しと参照渡しがよく使用されます。値渡しの場合、パラメータおよび戻り値はメソッドの呼出しごとにコピーされます。参照渡しの場合は、実際のオブジェクトを示すポインタ(または参照)がメソッドに渡されます。参照渡しでは、オブジェクトをコピーしなくてもよく、渡されたパラメータの状態を変更するメソッドも使用できるため、パフォーマンスが向上します。

WebLogic Serverでは、サーバー内のリモート・メソッド・インタフェース(RMI)呼出しのパフォーマンス向上のための最適化機能もあります。値渡しおよびRMIサブシステムのマーシャリングやアンマーシャリング機能を使用するのではなく、参照渡しを使用することによって、サーバーがダイレクトJavaメソッド呼出しを行います。この方式により、パフォーマンスが大幅に改善され、EJB 2.0ローカル・インタフェースにもこの方式が採用されています。

RMI呼出しの最適化および参照呼出しが使用されるのは、呼出し側と呼び出された側が共に同じアプリケーションにある場合に限られます。通常、クラスローダーが関係します。アプリケーションにはそれぞれ独自のクラスローダー階層があるため、どのアプリケーション・クラスも両方のクラスローダーに定義があり、複数のアプリケーション間で割当てを行おうとするとClassCastExceptionエラーを受け取ります。この問題を回避するため、WebLogic Serverでは複数のアプリケーション間での呼出しには、同じJVM内であっても値呼出しを使用しています。

注意:

複数アプリケーション間の呼出しは、同一アプリケーション内の呼出しに比べて遅くなります。したがって、モジュールは1つのEARファイルにまとめてデプロイし、高速のRMI呼出しおよびEJB 2.0ローカル・インタフェースを使用できるようにしてください。

フィルタリング・クラスローダーの使用

WebLogic Serverでは、システム・クラスパスにあるJARファイルはWebLogic Serverのシステム・クラスローダーによってロードされます。サーバー・インスタンスの内部で実行されるすべてのアプリケーションは、システム・クラスローダーの子であるアプリケーション・クラスローダー内にロードされます。このシステム・クラスローダーの実装では、アプリケーションは、システム・クラスローダー内にすでに存在する異なるバージョンのサードパーティ製JARを使用できません。すべての子クラスローダーは親(システム・クラスローダー)に対して特定のクラスを要求します。親から見えるクラスをロードすることはできません。

たとえば、com.foo.Bazというクラスが$CLASSPATHとアプリケーションEARの両方に存在する場合は、$CLASSPATHにあるクラスがロードされて、EARのクラスはロードされません。weblogic.jarは$CLASSPATHにあるため、アプリケーションはWebLogic Serverクラスをオーバーライドすることはできません。

次の項では、フィルタリング・クラスローダーの定義と使用方法について説明します。

- フィルタリング・クラスローダーとは

- フィルタリング・クラスローダーの構成

- リソースのロード順序

フィルタリング・クラスローダーとは

FilteringClassLoaderは、デプロイメント記述子を構成することで、特定のパッケージがシステム・クラスローダーによってロードされるのではなく、常にアプリケーションからロードされるように明示的に指定するメカニズムです。これによって、XercesやAntなどの代替バージョンのアプリケーションを使用できるようになります。FilteringClassLoaderを使用することにより、サード・パーティJARをバンドルしてアプリケーションに使用できますが、javaxパッケージまたはweblogicパッケージ内のクラスのようなAPIクラスに対してフィルタ処理を行うことはお薦めしません。

FilteringClassLoaderはアプリケーション・クラスローダーとシステム・クラスローダーの間に位置します。システム・クラスローダーの子であり、アプリケーション・クラスローダーの親となります。FilteringClassLoaderはloadClass(String className)メソッドをインターセプトして、weblogic-application.xmlファイルに指定されているパッケージのリストとclassNameを比較します。パッケージとclassNameが一致する場合、FilteringClassLoaderはClassNotFoundExceptionをスローします。この例外は、このクラスをアプリケーションからロードするようにアプリケーション・クラスローダーに通知します。

フィルタリング・クラスローダーの構成

FilteringClassLoaderを構成して、特定のパッケージがアプリケーションからロードされることを指定するには、アプリケーションからロードされるパッケージのリストを記述しているweblogic-application.xmlに、prefer-application-packages記述子要素を追加します。次の例は、org.apache.log4j.*パッケージとantlr.*パッケージがシステム・クラスローダーではなくアプリケーションからロードされることを示します。

<prefer-application-packages>
<package-name>org.apache.log4j.*</package-name>
<package-name>antlr.*</package-name>
</prefer-application-packages>

prefer-application-packages記述子要素は、weblogic.xmlでも定義できます。詳細は、「prefer-application-packages」を参照してください。

EARファイル内に含まれているWARファイルに対して特定のパッケージをロードすることを指定するには、WARファイルのweblogic.xmlファイルでFilteringClassLoaderを構成します。

たとえば、A.earにB.warが含まれるとします。A.earはweblogic-application.xmlでFilteringClassLoaderを定義し、B.warはweblogic.xmlで別のFilteringClassLoaderを定義します。A.earをデプロイすると、B.warはweblogic.xmlのFilteringClassLoaderに定義されているパッケージをロードします。WARレベルのFilteringClassLoaderは、このWARファイルに対するEARレベルのFilteringClassLoaderより優先されます。

フィルタリング・クラスローダーの構成のヘルプは、「クラスローダー分析ツール(CAT)の使用」を参照してください。

リソースのロード順序

リソースのロード順序は、java.lang.ClassLoaderのgetResource()およびgetResources()メソッドがリソースを戻す順序です。フィルタが有効になっている場合、この順序はフィルタ処理が無効な場合とは若干異なります。フィルタが有効になっているということは、FilteringClassLoaderに1つまたは複数のパッケージ・パターンがあることを意味しています。フィルタがない場合(デフォルト)、リソースはクラスローダー・ツリーの上から下へという順序で収集されます。たとえば、Web(1)がリソースをリクエストすると、リソースはシステム(3)、アプリケーション(2)、Web(1)の順序でグループ化されます。例11-4を参照してください。

注意:

FilteringClassLoaderの下で、リソースはデフォルトのJava EE委任モデルに従って返されます。FilteringClassLoaderの親に存在するリソースのみが、返される列挙の最後に追加されます。

図11-4 システム・クラスローダーの使用

System (3)
|
App (2)
|
Web (1)

具体的にいうと、すべてのクラスローダーに存在するリソース/META-INF/foo.xmlの場合は、以下のURLのリストが返されます。

META-INF/foo.xml - from the System ClassLoader (3)
META-INF/foo.xml - from the App ClassLoader (2)
META-INF/foo.xml - from the Web ClassLoader (1)

フィルタリングが有効になっている場合は、システム・クラスローダーのリソースよりも前に、FilteringClassLoaderの子(アプリケーション・クラスローダー)から呼出し側のクラスローダーまでのリソースが戻されます。図11-5では、(D)、(B)、および(A)のすべてのクラスローダーに同じリソースが存在する場合、Webクラスローダーがリソースを要求すると、リソースは次のような順序で取得されます。

META-INF/foo.xml - from the App ClassLoader (B)
META-INF/foo.xml - from the Web ClassLoader (A)
META-INF/foo.xml - from the System ClassLoader (D)

図11-5 フィルタリング・クラスローダー実装の使用

System (D)
|
FilteringClassLoader (filterList := x.y.*) (C)
|
App (B)
|
Web (A)

アプリケーション・クラスローダーが同じリソースをリクエストした場合は、次のような順序になります。

META-INF/foo.xml - from the App ClassLoader (B)
META-INF/foo.xml - from the System ClassLoader (D)

getResource()の場合は、最初の記述子のみが返されて、getResourceAsStream()は最初のリソースのinputStreamを返します。

モジュールおよびアプリケーション間のクラス参照の解決

アプリケーションでは、エンタープライズBean、サーブレットとJavaServer Pages、ユーティリティ・クラス、およびサード・パーティ製パッケージなど、様々なJavaクラスを使用します。WebLogic Serverでは、個別のクラスローダーにアプリケーションをデプロイして、独立を維持し、動的な再デプロイメントとアンデプロイメントを容易にします。このため、各モジュールが各クラスに個別にアクセスできるようにアプリケーションのクラスをパッケージ化する必要があります。場合によっては、一連のクラスを複数のアプリケーションまたはモジュールに格納する必要があります。この項では、アプリケーションを正常にステージングするために、WebLogic Serverで複数のクラスローダーを使用する方法について説明します。

クラスローディング問題の分析および解決の詳細は、「クラスローダー分析ツール(CAT)の使用」を参照してください。

リソース・アダプタ・クラス

各リソース・アダプタは、固有のクラスローダーを使用してクラスをロードするようになりました(Webアプリケーションの場合に類似)。その結果、アプリケーション・アーカイブ(EARファイル)でリソース・アダプタと一緒にパッケージ化されているWebアプリケーションやEJBなどのモジュールは、リソース・アダプタのクラスへの可視性を持ちません。そのような可視性が必要な場合は、リソース・アダプタのクラスをAPP-INF/classesに置く必要があります。また、これらのクラスを(JARユーティリティを使用して)アーカイブし、それらをアプリケーション・アーカイブのAPP-INF/libに置くこともできます。

リソース・アダプタ固有のクラスがWebLogic Serverのシステム・クラスパスにないことを確認してください。リソース・アダプタ固有のクラスをWebモジュール(EJB、Webアプリケーションなど)と共に使用する必要がある場合、それらのクラスを該当するモジュールのアーカイブ・ファイル(EJBに使用するJARファイルまたはWebアプリケーションに使用するWARファイルなど)にまとめます。

共有ユーティリティ・クラスのパッケージ化

WebLogic Serverは、EARファイル内で共有ユーティリティ・クラスを格納できる場所を提供します。ユーティリティJARファイルはAPP-INF/libディレクトリに、個々のクラスはAPP-INF/classesディレクトリに置きます。(Jarファイルを/classesディレクトリに置いたり、クラスを/libディレクトリに置いたりしないでください。)これらのクラスは、アプリケーションのルート・クラスローダーにロードされます。

この機能により、(どちらに置くかは標準のWebLogic Serverクラスローダーの階層によって変わりますが)システム・クラスパス内にユーティリティ・クラスを置く必要や、EJB JARファイル内にクラスを置く必要はなくなります。この機能を使用する場合は、次の節で説明するマニフェストClass-Pathを使う場合とは少し異なることに注意してください。この機能を使うと、クラス定義はアプリケーション全体で共有されます。マニフェストClass-Pathでは、参照しているモジュールのクラスパスが単純に拡張されます。つまり、クラスのコピーが別々に各モジュールについて存在するということです。

マニフェスト・クラスパス

Java EE仕様では、クラスの補助的なJARファイルを必要とすることをモジュールで指定する手段としてマニフェストClass-Pathエントリが用意されています。このマニフェストClass-Pathエントリを使用するのは、EJB JARファイルまたはWARファイルの一部として追加の補助的なJARファイルがある場合に限られます。その場合、JARファイルまたはWARファイルの作成時に、必要なJARファイルを参照するClass-Path要素と共にマニフェスト・ファイルを含める必要があります。

utility.jarファイルを参照する簡単なマニフェスト・ファイルを以下に示します。

Manifest-Version: 1.0 [CRLF]
Class-Path: utility.jar [CRLF]

このマニフェスト・ファイルの先頭行には、常にManifest-Version属性を指定する必要があり、次に改行(CR | LF |CRLF)、そしてClass-Path属性が続きます。マニフェスト・フォーマットの詳細は、http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.htmlを参照してください。

マニフェストClass-Pathエントリは、エントリが定義されている現在のアーカイブを基準として他のアーカイブを参照します。この構造により、複数のWARファイルおよびEJB JARファイルで、共通のライブラリJARを共有できます。たとえば、WARファイルにy.jarというマニフェスト・エントリが含まれる場合、このエントリは、以下のように、(WARファイル内ではなく)WARファイルの次に指定する必要があります。

/<directory>/x.war
/<directory>/y.jars

マニフェスト・ファイル自体は、META-INF/MANIFEST.MFのアーカイブに配置します。

詳細は、http://docs.oracle.com/javase/tutorial/deployment/jar/manifestindex.htmlを参照してください。

クラスローダー分析ツール(CAT)の使用

CATとはWebベースのクラス分析ツールで、クラスローダー構成のフィルタリングを簡素化し、競合状態の検出、アプリケーションのクラスパスやクラス競合のデバッグといったクラスローディング問題の分析をサポートし、問題解決に役立つソリューションを提案します。

CATはスタンドアロンWebアプリケーションです。wls-cat.warという1つのWARファイルとして配布され、その機能はWebベース・フロントエンドを使用して公開されます。CATは、開発モードでのみ内部オンデマンド・アプリケーションとしてデプロイされます。デプロイメントは初回のアクセス時に実行されます。サーバーが本番モードで稼働中の場合、自動的にデプロイされません。本番モードでデプロイする際には、その使用に制限はありませんが、他のWebアプリケーションと同様に手動でデプロイする必要があります。CAT Webアプリケーションは、WL_HOME/server/lib/wls-cat.warに格納されます。WebLogic Serverバージョン10.3.x以降を対象にデプロイできます。

注意:

CATは、Java用のIBM SDKではサポートされていません。これは、CATアプリケーションの一部の機能がHotSpot実装に依存するためです。

CATインタフェースの開始

CATには、現在実行中のアプリケーションとモジュールをすべて表示する単一のWeb GUIが実装されています。

CATの使用を開始するには:

- WebLogic Server管理コンソールで、「デプロイメント」 > 「app_name」 > 「テスト」を選択し、「クラスローダー分析ツール」リンクを選択します。コンソールのログイン資格証明情報を入力します。
または

- ブラウザを開いてhttp://wls-host:port/wls-cat/へ移動し、コンソールのログイン資格証明情報を入力します。

ナビゲーション・ペインでは、分析するアプリケーションやモジュールを選択し、右側のペインには選択したアイテムの簡単な説明が表示されます。右側のペインを使用して、選択したアプリケーションやモジュールに関する次のようなアクションと分析を実行できます。

- クラスローディング競合の分析

- システムおよびアプリケーションのクラスローダーの表示

- レポートの生成

CATによるクラス分析の方法

CATは、システム・クラスパス・クラスローダーやWebLogic Serverのメイン・アプリケーションのクラスローダーによってロードされ、フィルタリング、アプリケーション、およびモジュールのクラスローダーとして定義されたクラスを分析します。クラス、パッケージ、またはJARのレベルで分析を実行できます。選択する各アクションの結果は、基本ビューまたは詳細ビューで表示されます。

CATを使用して実行できるタスクの例を紹介します。

- アプリケーションおよびモジュールに関する基本情報の表示

- クラスローディング競合の分析

- 提案されたソリューションの確認

- フィルタリング・クラスローダーの構成に関する提案の取得

- クラスローダー階層および各クラスローダーのクラスパス全体の表示

- クラスローダーにおけるクラス(またはリソース)の検索

マニフェスト階層を介したクラス参照の確認

アプリケーションには、アプリケーションのクラスパス内に直接存在しないクラスへのマニフェスト参照が複数含まれている場合がありますが、これらのクラスはマニフェスト参照によってクラスパスに連鎖されています。アプリケーション開発者は、知らないうちに別のJARから追加のクラスがアプリケーションのクラスパスに取り込まれ、さらに他のJARへのマニフェスト参照が含まれるようになったことに気付かない場合があります。

CATは、アプリケーションまたはモジュールのクラスパスを検索して、潜在する連鎖したマニフェスト参照を検出および表示する機能を備えています(次のマニフェスト階層を持つEARの例を参照)。

cat4mf.ear
+- ejb.jar
+- web-mf-in-root.war
+- lib
+- applib.jar
+- apputil_1.jar
+- apputil_1_1.jar
+- apputil_1_1_1.jar
+- apputil_1_2.jar
+- apputil_1_2_1.jar
+- ejbutil_1.jar
+- ejbutil_1_1.jar
+- ejbutil_1_2.jar
+- ejbutil_1_2_1.jar
+- webutil_1.jar
+- webutil_1_1.jar
+- webutil_1_1_1.jar
+- webutil_2.jar
+- webutil_2_1.jar

次に示すように、ejb.jarにはejbutil_1.jarへのマニフェスト参照が含まれ、これによってejbutil_1_1.jarおよびejbutil_1_2.jarへの参照、さらにejbutil_1_2_1.jarへの参照が含まれるようになります。

ejb.jar
-> ejbutil_1.jar
-> ejbutil_1_1.jar
-> ejbutil_1_2.jar
-> ejbutil_1_2_1.jar

CATを使用したマニフェスト参照の表示

1. 「CATインタフェースの開始」の説明に従って、CATツールを開きます

2. ナビゲーション・ペインを使用して、分析する実行中のアプリケーションまたはモジュールを選択します。

注意: マニフェスト参照は、アプリケーション・レベルではなくモジュール・レベルで分析することをお薦めします。

3. アプリケーションのサマリーペインでクラスローダー・ツリービューをクリックし、選択したアプリケーションまたはモジュールのクラスローダーをすべて表示します。

- メニューから詳細ビューをクリックすると、各クラスローダーのクラスパスが表示されます。

- 各クラスローダーのハッシュ・コードはアクティブなURLです。

4. 分析するクラスローダーのハッシュ・コードのURLをクリックします。

5. クラスローダーページはデフォルトの基本ビューで表示されるため、クラスパスおよびクラスローダーによってロードされたクラスを表示するには、詳細ビューを選択します。

6. 分析するリソースフィールドに、ロードされたクラス名のいずれかを入力し(pckgname.classnameの形式を使用)、リソースの分析をクリックします。

7. 詳細な出力のマニフェスト参照セクションに、選択したクラス名の連鎖したマニフェスト参照が一覧で表示されます。

先ほどのマニフェスト階層を持つEARの例では、出力は次のようになります。

path/to/user_projects/applications/cat4mf/y79s0z/ejb.jar
path/to/user_projects/applications/cat4mf/y79s0z/ejbutil_1.jar
path/to/user_projects/applications/cat4mf/y79s0z/ejbutil_1_2.jar
path/to/user_projects/applications/cat4mf/y79s0z/ejbutil_1_2_1.jar

Java EEライブラリを使用したアプリケーションとモジュールの共有

Java EEライブラリ機能により、複数のエンタープライズ・アプリケーション間で、種類が異なる1つまたは複数のJava EEモジュールを簡単に共有できます。Java EEライブラリは、デプロイメントに際してJava EEアプリケーション・コンテナに登録される1つまたは複数のモジュールです。詳細は、共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

ドメイン/libディレクトリへのJARの追加

WebLogic Serverでは、ドメイン・ディレクトリ内にlibサブディレクトリがあります。ドメイン内のWebLogic Serverインスタンスで実行しているすべてのJava EEアプリケーションで(別のシステム・レベル・クラスローダー内)JARファイル・クラスが使用可能になるように、このサブディレクトリを使用して1つまたは複数のJARファイルを追加できます。ドメイン/libディレクトリ内のJARは、システム・クラスパスに追加されません。作成されるクラスローダーは、システム・クラスローダーの子です。ドメイン/libディレクトリのJAR内のすべてのクラスがEARファイルなどのJava EEアプリケーションからのみ参照可能です。システム・クラスパスのクラスはドメイン/libディレクトリ内のクラスにアクセスできません。

libサブディレクトリは、サーバーにデプロイされているすべてまたは大部分のアプリケーションで必要とされ、ほとんど変更されないJARファイルを格納するためのディレクトリです。たとえば、libディレクトリを使用して、ドメイン内のすべてのJava EEデプロイメントで必要とされるサード・パーティ・ユーティリティ・クラスを格納できます。ドメイン/libクラスローダーはすべてのJava EEアプリケーションの親であるため、サード・パーティ・ユーティリティ・クラスが使用可能になります。

libディレクトリは、ドメインにデプロイされている1つまたは2つのアプリケーションでJARを共有したり、定期的に更新する必要があるJARを共有したりする際の一般的な方法としては推奨できません。libディレクトリ内のJARを更新する場合は、アプリケーションが変更を認識できるように、ドメイン内の全サーバーを再起動する必要があります。複数のアプリケーション間でJARファイルまたはJava EEモジュールを共有する必要がある場合は、共有Java EEライブラリおよびオプション・パッケージの作成で説明されているJava EEライブラリ機能を使用します。

libディレクトリでJARを共有するには:

1. ドメイン内のすべてのサーバーを停止します。

2. 共有するJARファイルをドメイン・ディレクトリのlibサブディレクトリにコピーします。例:

mkdir DOMAIN_HOME\wl_server\lib
cp c:\3rdpartyjars\utility.jar
DOMAIN_HOME\wl_server\lib

注意:

WebLogic Serverは、起動時にlibディレクトリに読込みアクセスできるようにする必要があります。

管理サーバーは、libディレクトリ内のファイルを、リモート・マシン上の管理ターゲット・サーバーに自動的にコピーしません。管理ターゲット・サーバーが、管理サーバーと同じ物理ドメイン・ディレクトリを共有していない場合、管理ターゲット・サーバー・マシン上のdomain_name/libディレクトリに手動でJARファイルをコピーする必要があります。

3. ドメイン内の管理サーバーとすべての管理対象サーバーを起動します。

12 共有Java EEライブラリおよびオプション・パッケージの作成

この章では、WebLogic Serverでサポートされている共有Java EEライブラリとオプション・パッケージを使用してアプリケーション間でコンポーネントとクラスを共有する方法について説明します。

この章の内容は次のとおりです。

- 共有Java EEライブラリおよびオプション・パッケージの概要

- 共有Java EEライブラリの作成

- エンタープライズ・アプリケーションでの共有Java EEライブラリの参照

- Java EEアプリケーションまたはモジュールからのオプション・パッケージの参照

- weblogic.appmergeを使用したライブラリの結合

- 分割開発ディレクトリ環境への共有Java EEライブラリの統合

- 共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ

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

- WebアプリケーションにおけるWebアプリケーション・ライブラリの使用

- LibraryRuntimeMBeanに登録された共有Java EEライブラリ情報へのアクセス

- 共有Java EEライブラリの参照時のモジュールの優先順位

- 共有Java EEライブラリを使用する場合のベスト・プラクティス

共有Java EEライブラリおよびオプション・パッケージの概要

WebLogic Serverの共有Java EEライブラリ機能では、複数のエンタープライズ・アプリケーション間で、1つまたは複数の種類のJava EEモジュールを簡単に共有できます。共有Java EEライブラリは、デプロイメントに際してJava EEアプリケーション・コンテナに登録される1つまたは複数のモジュールです。共有Java EEライブラリは次のいずれかです。

- スタンドアロンEJBモジュール

- スタンドアロンWebアプリケーション・モジュール

- エンタープライズ・アプリケーションにパッケージ化された複数のEJBモジュール

- エンタープライズ・アプリケーションにパッケージ化された複数のWebアプリケーション・モジュール

- 単独のプレーンJARファイル

共有Java EEライブラリを適切なアーカイブ・ファイル(EAR、JAR、またはWAR)にパッケージ化することをお薦めします。ただし、開発目的の場合、展開されたアーカイブ・ディレクトリとして共有Java EEライブラリをデプロイすれば、更新と再デプロイメントの繰返しを簡単にすることができます。

共有Java EEライブラリを登録後、そのライブラリを参照するエンタープライズ・アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に必要なライブラリへの参照を受け取り、参照側アプリケーション自体の一部としてパッケージ化されているかのように、ライブラリを構成するモジュールを使用できます。参照側アプリケーションのクラスパスにライブラリ・クラスが追加され、参照側アプリケーションまたはモジュールのプライマリ・デプロイメント記述子は、共有Java EEライブラリを構成するモジュールのデプロイメント記述子と(メモリー内で)結合されます。

このトピックでは、大部分において、エンタープライズ・アプリケーションでのみ参照可能な共有Java EEライブラリについて説明しています。ただし、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション・ライブラリと非常に似ていますが、参照方法が多少異なります。詳細は、「Webアプリケーション共有Java EEライブラリの情報」を参照してください。

注意:

WebLogic Serverでは、ドメイン・ディレクトリのlibサブディレクトリを使用して、WebLogic Serverシステム・クラスパスに1つまたは複数のJARファイルを追加するという簡単な方法も利用できます。「ドメイン/libディレクトリへのJARの追加」を参照してください。

オプション・パッケージ

WebLogic Serverは、http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/extensions.htmlに記載(バージョニングについては、オプション・パッケージのバージョニング(http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/versioning.htmlを参照)で説明しています)のとおり、オプション・パッケージをサポートしています。オプション・パッケージは、Java EEライブラリと似た機能を提供しており、これを使用すると複数のアプリケーション間で単一のJARファイルを簡単に共有できます。Java EEライブラリの場合、最初に、関連するJARファイルをオプション・パッケージとしてデプロイし、WebLogic Serverにオプション・パッケージを登録する必要があります。パッケージを登録したら、そのマニフェスト・ファイルでパッケージを参照するJava EEモジュールをデプロイできます。

オプション・パッケージは、weblogic.BuildXMLGenでJava EE共有ライブラリとしてもサポートされます。そのため、オプション・パッケージ参照の検索では、アプリケーションおよびそのモジュールのすべてのマニフェストがスキャンされます。オプション・パッケージ参照が見つかると、生成されたbuild.xmlファイル内のwlcompileおよびappcタスクに追加されます。

オプション・パッケージは、すべてのJava EEモジュール(EAR、JAR、WARまたはRARアーカイブ)または展開されたアーカイブ・ディレクトリから参照できる点がJava EEライブラリとは異なります。Java EEライブラリは、有効なエンタープライズ・アプリケーションからのみ参照できます。

たとえば、複数のWebアプリケーションで必要とされるサード・パーティのWebアプリケーション・フレームワーク・クラスを、単一のJARファイル内にパッケージ化およびデプロイし、ドメイン内の複数のWebアプリケーション・モジュールから参照することが可能です。この場合、個々のWebアプリケーション・モジュールは共有JARファイルを参照する必要があるため、Java EEライブラリではなくオプション・パッケージを使用します(Java EEライブラリの場合、完全なエンタープライズ・アプリケーションのみがライブラリを参照できます)。

注意:

OracleのドキュメントとWebLogic Serverユーティリティでは、ライブラリという語をJava EEライブラリとオプション・パッケージの両方の意味で使用します。必要な場合にのみオプション・パッケージと呼びます。

ライブラリ・ディレクトリ

Java EEプラットフォームには、アプリケーションでオプション・パッケージや共有ライブラリを使用するためのいくつかのメカニズムが用意されています。ライブラリはアプリケーションにバンドルすることもできますし、アプリケーションで使用するために個別にインストールすることもできます。EARファイルには、JARファイルにパッケージ化されたライブラリを格納するディレクトリを含めることができます。このディレクトリの名前は、EARファイルのデプロイメント記述子のlibrary-directory要素内に指定されます。library-directory要素が指定されていない場合、またはEARファイルにデプロイメント記述子が含まれていない場合は、libというディレクトリが使用されます。ライブラリ・ディレクトリが存在しないことを指定するには、空のlibrary-directory要素を使用します。このディレクトリ(サブディレクトリは除く)内にある、拡張子.jarが付いたファイルはすべて、アプリケーション・クライアントを含むEARファイル内にパッケージ化されているすべてのコンポーネントで利用可能とする必要があります。これらのライブラリは、アプリケーションにバンドルされている他のライブラリ、または別個にインストールされている他のライブラリを参照できます。

この機能は、WebLogic ServerでサポートされているAPP-INF/lib機能に似ています。APP-INF/libとlibrary-directoryが両方とも存在する場合は、library-directory内のjarが優先されます。つまり、これらのファイルが、クラスパス内のAPP-INF/lib jarファイルよりも前に置かれます。APP-INF/libの詳細は、「モジュールおよびアプリケーション間のクラス参照の解決」および「分割開発ディレクトリでの共有クラスの配置」を参照してください。

ライブラリのバージョニングのサポート

WebLogic Serverでは、共有Java EEライブラリのバージョニングによって、参照側のアプリケーションは、使用するライブラリの最低限のバージョンを指定したり、必要なバージョンを完全一致の形で指定したりできます。WebLogic Serverでは、共有Java EEライブラリのバージョニングを、http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/versioning.htmlのオプション・パッケージのバージョニングのドキュメントで説明されている2種類のレベルでサポートしています。

- 仕様バージョン - 共有Java EEライブラリまたはオプション・パッケージが従う仕様のバージョン番号(Java EE仕様バージョンなど)を指定します。

- 実装バージョン - ライブラリまたはパッケージの実際のコード実装のバージョン番号を指定します。たとえば、コードの実際の改訂番号またはリリース番号が実装バージョンに当たります。実装バージョンを指定するには、仕様バージョンを指定する必要があります。

ベスト・プラクティスとして、共有Java EEライブラリを作成する際には、バージョン情報(仕様バージョンまたは実装バージョンと仕様バージョンの両方)を必ず含めることをお薦めします。共有コンポーネントの開発時にバージョン情報を作成および更新すると、テスト目的でコンポーネントの複数のバージョンを同時にデプロイできます。バージョン情報を指定しない場合、またはバージョン文字列のインクリメントに失敗した場合は、新しいライブラリをデプロイする前に既存のライブラリをアンデプロイする必要があります。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

参照側アプリケーションのバージョニング情報によって、そのアプリケーションで必要なライブラリとパッケージのバージョンが決まります。各アプリケーションに応じて、必要となるライブラリまたはパッケージのバージョンが異なる場合があります。たとえば、本番アプリケーションがある特定のバージョンのライブラリを要求することがあります。これはそのライブラリのみが本番用に完全に適しているためです。同じライブラリの最低限のバージョンを常に使用するように内部アプリケーションを構成できます。特定のバージョンを必要としないアプリケーションで、最新バージョンのライブラリを使用するように構成することもできます。「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」を参照してください。

共有Java EEライブラリとオプション・パッケージの比較

オプション・パッケージと共有Java EEライブラリでは、以下の機能が共通しています。

- 両方とも、デプロイメント時にWebLogic Serverインスタンスに登録されます。

- 両方とも、省略可能な実装バージョン文字列と仕様バージョン文字列をサポートしています。

- 共有Java EEライブラリとオプション・パッケージを参照するアプリケーションは、共有ファイルの必須バージョンを指定できます。

- オプション・パッケージは他のオプション・パッケージを、共有Java EEライブラリは他の共有Java EEライブラリを参照できます。

オプション・パッケージは、共有Java EEライブラリと以下の点が異なっています。

- オプション・パッケージはプレーンJARファイルであるのに対し、共有Java EEライブラリは、プレーンJARファイル、Java EEエンタープライズ・アプリケーション、スタンドアロンJava EEモジュール(EJBまたはWebアプリケーション)のいずれでも可能です。つまり、ライブラリは有効なJava EEおよびWebLogic Serverデプロイメント記述子を持つことができます。オプション・パッケージのJARファイルのデプロイメント記述子は無視されます。

- すべてのJava EEアプリケーションまたはモジュールがオプション・パッケージを参照できる(META-INF/MANIFEST.MFを使用)のに対し、共有Java EEライブラリを参照できるのはエンタープライズ・アプリケーションとWebアプリケーションのみです(weblogic-application.xmlまたはweblogic.xmlを使用)。

通常、1つまたは複数のEJB、Webアプリケーションまたはエンタープライズ・アプリケーション・モジュールを複数の異なるエンタープライズ・アプリケーション間で共有する場合は、共有Java EEライブラリを使用します。1つまたは複数の(JARファイルにパッケージ化された)クラスを複数のJava EEモジュール間で共有する場合は、オプション・パッケージを使用します。

プレーンJARファイルは、ライブラリとしてもオプション・パッケージとしても共有できます。次を行う場合は、オプション・パッケージを使用します。

- 複数のJava EEモジュール間でプレーンJARファイルを共有

- 共有JARから別の共有JARファイルを参照

- Java EE 5.0仕様の説明に従ってプレーンJARを共有

1つまたは複数のエンタープライズ・アプリケーションからJARファイルを参照するだけで、Java EE仕様に厳密に準拠する必要がない場合は、共有Java EEライブラリを使用してプレーンJARファイルを共有します。

注意:

OracleのドキュメントとWebLogic Serverユーティリティでは、共有Java EEライブラリという語をライブラリとオプション・パッケージの両方の意味で使用します。必要な場合にのみオプション・パッケージと呼びます。

補足情報

管理者側から見た共有Java EEライブラリ、オプション・パッケージおよび参照側アプリケーションのデプロイおよび管理の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイに関する項を参照してください。

共有Java EEライブラリの作成

複数のアプリケーションで共有可能な新しい共有Java EEライブラリを作成するには:

1. 有効かつデプロイ可能なJava EEモジュールまたはエンタープライズ・アプリケーションに共有Java EEライブラリを作成します。ライブラリは、Java EEモジュールまたはエンタープライズ・アプリケーションで必要なJava EEデプロイメント記述子を持つ必要があります。

「共有Java EEライブラリ・ファイルの作成」を参照してください。

2. オプション・パッケージ・クラスを作業ディレクトリに作成します。

「オプション・パッケージ・クラス・ファイルの作成」を参照してください。

3. 共有Java EEライブラリのMANIFEST.MFファイルを作成および編集して、名前およびバージョン文字列情報を指定します。

「共有Java EEライブラリのマニフェスト属性の編集」を参照してください。

4. 配布およびデプロイメント用共有Java EEライブラリをパッケージ化します。

「配布およびデプロイメント用共有Java EEライブラリのパッケージ化」を参照してください。

共有Java EEライブラリ・ファイルの作成

以下の種類のJava EEモジュールを共有Java EEライブラリとしてデプロイできます。

- 展開されたディレクトリの形式またはJARファイルでパッケージ化された形式のEJBモジュール

- 展開されたディレクトリの形式またはWARファイルでパッケージ化された形式のWebアプリケーション・モジュール

- 展開されたディレクトリの形式またはEARファイルでパッケージ化された形式のエンタープライズ・アプリケーション

- JARファイルでパッケージ化された形式のプレーンJavaクラス(複数可)

- 別のライブラリから参照される共有Java EEライブラリ(「Webアプリケーション共有Java EEライブラリの情報」を参照)

共有Java EEライブラリには以下の制限があります。

- 共有Java EEライブラリのWebアプリケーション・モジュールのコンテキスト・ルートは、参照側のエンタープライズ・アプリケーションのコンテキスト・ルートとは競合しないようにする必要があります。必要に応じて、ライブラリのコンテキスト・ルートをオーバーライドするように参照側アプリケーションを構成できます。「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」を参照してください。

- 共有Java EEライブラリをネストすることはできません。たとえば、共有Java EEライブラリとしてEARをデプロイする場合は、EAR全体をライブラリとして指定する必要があります。EAR内の個々のJava EEモジュールを名前が付けられた個別のライブラリとして指定することはできません。

- 他のJava EEモジュールまたはエンタープライズ・アプリケーションの場合と同様、ドメイン内のターゲット・サーバーまたはクラスタにデプロイするために共有Java EEライブラリを構成する必要があります。つまり、ライブラリには、WebLogic Server固有のデプロイメント記述子およびオプション・デプロイメント・プランとともに、有効なJava EEデプロイメント記述子が必要です。『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

共有Java EEライブラリを、スタンドアロンJava EEモジュールではなく、エンタープライズ・アプリケーションとしてパッケージ化することをお薦めします。これは、スタンドアロン・モジュールのURIはデプロイメント名から派生しており、モジュールがどのようにデプロイされたかによって変わる可能性があるためです。デフォルトでは、WebLogic Serverはデプロイメント・アーカイブ・ファイル名または展開されたアーカイブ・ディレクトリ名をデプロイメント名として使用します。別のファイルまたは場所からスタンドアロン共有Java EEライブラリを再デプロイする場合、デプロイメント名とURIが変わり、誤ったURIを使用している参照側アプリケーションは、デプロイされたライブラリにアクセスできません。

スタンドアロンJava EEモジュールとして共有Java EEライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前をURIとして使用します。

オプション・パッケージ・クラス・ファイルの作成

任意のクラスのセットをオプション・パッケージ・ファイルにまとめることができます。共有クラスのコレクションは、最終的に標準JARアーカイブにパッケージ化されます。ただし、JARのマニフェスト・ファイルを編集する必要があるので、最初にすべてのクラス・ファイルを作業ディレクトリに作成します。

1. 新しいオプション・パッケージ用の作業ディレクトリを作成します。例:

mkdir /apps/myOptPkg

2. 必要に応じて適切なパッケージ・サブディレクトリを作成して、コンパイルしたクラス・ファイルを作業ディレクトリにコピーします。例:

mkdir -p /apps/myOptPkg/org/myorg/myProduct
cp /build/classes/myOptPkg/org/myOrg/myProduct/*.class /apps/myOptPkg/org/myOrg/myProduct

3. オプション・パッケージとして使用するJARファイルがすでにある場合、その内容を作業ディレクトリに展開して、マニフェスト・ファイルを編集できるようにします。

cd /apps/myOptPkg
jar xvf /build/libraries/myLib.jar

共有Java EEライブラリのマニフェスト属性の編集

共有Java EEライブラリの名前とバージョン情報は、META-INF/MANIFEST.MFファイルで指定します。表12-1で、有効な共有Java EEライブラリ・マニフェストの属性を示します。

表12-1 Java EEライブラリのマニフェスト属性

属性

説明

Extension-Name

共有Java EEライブラリの名前を識別する文字列値(オプション)。参照するアプリケーションでは、ライブラリを使用するには、完全に一致するExtension-Name値を使用する必要があります。

ベスト・プラクティスとしては、ライブラリごとにExtension-Name値を必ず指定します。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ・デプロイメントと展開されたアーカイブ・デプロイメントでは異なっており、デプロイメント・コマンドで任意の値に設定できます。

Specification-Version

共有Java EEライブラリの仕様バージョンを定義する文字列値(オプション)。参照するアプリケーションでは、ライブラリで要求されているSpecification-Versionを必要に応じて指定できます。正確な仕様バージョンを使用できない場合、参照側アプリケーションのデプロイメントは失敗します。

Specification-Versionは、次のフォーマットを使用します。

バージョン番号および改訂番号をピリオドで区切ったメジャー/マイナー・バージョン・フォーマット(「9.0.1.1」など)

特定の共有Java EEライブラリを完全一致の形で示すバージョン、最低限のバージョン、使用可能な最新バージョンのいずれかを要求するようにアプリケーションの参照を構成できます。

共有Java EEライブラリの仕様バージョンは、一部制約があるものの、ライブラリのデプロイ時にコマンド・ラインでも設定できます。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

Implementation-Version

共有Java EEライブラリのコード実装バージョンを定義する文字列値(オプション)。Implementation-Versionは、Specification-Versionが定義済みの場合にのみ指定できます。

Implementation-Versionは、次のフォーマットを使用します。

- バージョン番号および改訂番号をピリオドで区切ったメジャー/マイナー・バージョン・フォーマット(「9.0.1.1」など)

- テキストによる名前付きバージョンのフォーマット(「9011Beta」または「9.0.1.1.B」など)

メジャー/マイナー・バージョン・フォーマットを使用する場合、特定の共有Java EEライブラリを完全一致の形で示すバージョン、最低限のバージョン、使用可能な最新バージョンのいずれかを要求するようにアプリケーションの参照を構成できます。テキスト・フォーマットを使用する場合、アプリケーションの参照では、ライブラリのバージョンを完全一致の形で指定する必要があります。

共有Java EEライブラリの実装バージョンは、一部制約があるものの、ライブラリのデプロイ時にコマンド・ラインでも設定できます。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

マニフェスト・ファイルの属性を指定するには:

1. テキスト・エディタでマニフェスト・ファイルを開くか作成します。サンプルの共有Java EEライブラリの場合、次のコマンドを使用します。

cd /apps/myLibrary
mkdir META-INF
emacs META-INF/MANIFEST.MF

次に、オプション・パッケージのサンプルの場合、次を使用します。

cd /apps/myOptPkg
mkdir META-INF
emacs META-INF/MANIFEST.MF

2. テキスト・エディタで、共有Java EEライブラリの名前を指定する文字列値を追加します。例:

Extension-Name: myExtension

ライブラリを参照するアプリケーションは、Extension-Name値に完全一致した共有ファイルを指定する必要があります。

3. ベスト・プラクティスとしては、共有Java EEライブラリのバージョン情報(オプション)を入力します。例:

Extension-Name: myExtension
Specification-Version: 2.0
Implementation-Version: 9.0.0

バージョン識別子に対してメジャー/マイナー・フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です(表12-2を参照)

注意:

デプロイメント時に必要に応じてコマンド・ラインでSpecification-VersionおよびImplementation-Versionを指定できますが、これらの文字列をMANIFEST.MFファイルで指定することをお薦めします。マニフェストにバージョン文字列を指定すると、旧バージョンと並行して新しいバージョンのライブラリをデプロイできるようになります。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

配布およびデプロイメント用共有Java EEライブラリのパッケージ化

管理者によるデプロイメント用に共有Java EEライブラリまたはオプション・パッケージを配布する場合、デプロイメント・ファイルをアーカイブ・ファイル(共有Java EEライブラリの場合は.EARファイルまたはスタンドアロン・モジュール・アーカイブ・ファイル、オプション・パッケージの場合は単純な.JARファイル)にパッケージ化して配布します。「wldeployを使用したアプリケーションのデプロイメント」を参照してください。

共有Java EEライブラリは標準Java EEアプリケーションまたはスタンドアロン・モジュールとしてパッケージ化されるため、『Oracle WebLogic Serverへのアプリケーションのデプロイ』で説明されているように、ライブラリのデプロイメント構成をデプロイメント・プランにエクスポートすることもできます。オプション・パッケージ.JARファイルにはデプロイメント記述子が含まれていないため、エクスポートすることはできません。

開発目的で、展開されたアーカイブ・ディレクトリとしてライブラリをデプロイすると、更新と再デプロイメントの繰返しが簡単になります。

エンタープライズ・アプリケーションでの共有Java EEライブラリの参照

Java EEアプリケーションは、アプリケーションのweblogic-application.xmlデプロイメント記述子のエントリを基に、登録された共有Java EEライブラリを参照できます。表12-2では、ライブラリ参照を定義するXML要素を示します。

表12-2 weblogic-application.xmlの共有Java EEライブラリ参照用の要素

要素

説明

library-ref

library-refは、共有Java EEライブラリへの参照を定義する親要素です。他のすべての要素はlibrary-ref内に格納されます。

library-name

使用する共有Java EEライブラリの名前を指定する文字列値(必須)。library-nameは、ライブラリのマニフェスト・ファイルのExtension-Name属性の値に完全に一致する必要があります。(表12-2を参照。)

specification-version

共有Java EEライブラリの必要な仕様バージョンを定義する文字列値(オプション)。この要素を設定しなかった場合、アプリケーションは最新の仕様バージョンに一致するライブラリを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アプリケーションは、構成した値を下回らない最新の仕様バージョンに一致するライブラリを使用します。使用可能なすべてのライブラリが、構成されたspecification-versionよりも古い場合、アプリケーションをデプロイすることはできません。次のexact-match要素を使用すると、必要なバージョンをさらに絞り込むことができます。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アプリケーションでは、ライブラリのマニフェスト・ファイルのSpecification-Version属性に完全一致する文字列値を持つ共有Java EEライブラリが必要になります。(表12-2を参照。)

implementation-version

共有Java EEライブラリの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アプリケーションは最新の実装バージョンに一致するライブラリを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アプリケーションは、構成した値を下回らない最新の実装バージョンに一致するライブラリを使用します。使用可能なすべてのライブラリが、構成されたimplementation-versionよりも古い場合、アプリケーションをデプロイすることはできません。次のexact-match要素を使用すると、必要な実装バージョンをさらに絞り込むことができます。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アプリケーションでは、ライブラリのマニフェスト・ファイルのImplementation-Version属性に完全一致する文字列値を持つ共有Java EEライブラリが必要になります。(表12-2を参照。)

exact-match

構成された値よりも新しい仕様または実装バージョンを持つ共有Java EEライブラリがある場合、それをアプリケーションで使用するかどうかを指定するブール値(オプション)。デフォルトでは、この要素はfalseです - つまり、WebLogic Serverは、最新バージョンのライブラリがある場合は、それを使用します。この要素をtrueに設定すると、specification-version要素とimplementation-version要素に完全一致するバージョンが必要になります。

context-root

Webアプリケーション共有Java EEライブラリで使用する代替コンテキスト・ルートを指定する文字列値(オプション)。この要素は、ライブラリのコンテキスト・ルートが、参照側Java EEアプリケーションのWebアプリケーションのコンテキスト・ルートと競合する場合に指定します。

Webアプリケーション共有Java EEライブラリは特殊なライブラリの呼称であり、別のWebアプリケーションによって参照されるWebアプリケーションです。「Webアプリケーション共有Java EEライブラリの情報」を参照してください。

たとえば、次のweblogic-application.xml記述子の単純なエントリでは、共有Java EEライブラリmyLibraryを参照します。

<library-ref>
<library-name>myLibrary</library-name>
</library-ref>

上記の例では、WebLogic Serverは、依存関係にあるアプリケーションをデプロイする際にmyLibraryというライブラリを探します。myLibraryのコピーが複数登録されている場合、WebLogic Serverは、最新の仕様バージョンのライブラリを選択します。選択した仕様バージョンを複数のライブラリのコピーが使用している場合、WebLogic Serverは、最新の実装バージョンのコピーを選択します。

この例では、仕様バージョンの要件を指定して共有Java EEライブラリを参照します。

<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
</library-ref>

上記の例では、WebLogic Serverは、仕様バージョン2.0以降のライブラリを探します。バージョン2.0以降のライブラリが複数ある場合、WebLogic Serverは、実装バージョンにFloat値を使用しているライブラリを調べ、最新バージョンを選び出します。WebLogic Serverは、実装バージョンにFloat以外の値を使用している選択ライブラリを無視します。

この例では、仕様バージョンと非Float値の実装バージョンの両方を指定して共有Java EEライブラリを参照します。

<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>81Beta</implementation-version>
</library-ref>

上記の例では、WebLogic Serverは、仕様バージョンが2.0以降で、実装バージョンが81Betaに完全一致するライブラリを探します。

次の例では、仕様バージョンと実装バージョンの両方が完全一致しなければならないケースを示します。

<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1</implementation-version>
<exact-match>true</exact-match>
</library-ref>

次の例は、ライブラリ参照を使用してcontext-rootを指定します。WARライブラリ参照がweblogic-application.xmlから作成された場合、context-rootは次の参照を使用して指定できます。

<library-ref>
<library-name>myLibrary</library-name>
<context-root>mywebapp</context-root>
</library-ref>

参照されたエンタープライズ・ライブラリ内のcontext-rootのオーバーライド

Java EEアプリケーションは、weblogic-application.xmlデプロイメント記述子内のエントリを使用して、参照されたEARライブラリ内のcontext-rootをオーバーライドできます。表12-3では、ライブラリ参照においてcontext-rootをオーバーライドするXML要素について説明します。

表12-3 weblogic-application.xmlの共有Java EEライブラリ・オーバーライド用の要素

要素

説明

context-root

ライブラリで宣言されているcontext-root要素をオーバーライドする文字列値(オプション)。この要素が存在しない場合は、ライブラリのcontext-rootが使用されます。

参照元アプリケーション(たとえば、ユーザー・アプリケーション)のみが、ライブラリで宣言されているcontext-root要素をオーバーライドできます。

override-value

ライブラリで宣言されているcontext-root要素をオーバーライドする際のlibrary-context-root-override要素の値を指定する文字列値(オプション)。これらの要素が存在しない場合は、ライブラリのcontext-rootが使用されます。

次の例では、context-root-overrideを指定しています。これがライブラリの1つで指定された古いcontext-rootと、代わりに使用する(オーバーライド)新しいcontext-rootを参照します。

<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1</implementation-version>
<exact-match>true</exact-match>
</library-ref>
<library-context-root-override>
<context-root>webapp</context-root>
<override-value>mywebapp</override-value>
</library-context-root-override>

上記の例では、現行のアプリケーションがmyLibraryを参照します。これには、webappのcontext-rootが格納されています。この参照をオーバーライドする唯一の方法は、webappをmywebappにマップするlibrary-context-root-overrideを宣言することです。

スタンドアロン・モジュールとしてデプロイされた共有Java EEライブラリのURI

スタンドアロン・モジュール(EJBまたはWebアプリケーション)としてデプロイされた共有Java EEライブラリのURIを参照する場合、モジュールURIは、共有Java EEライブラリのデプロイメント名に対応している必要があります。これは、デプロイメント時に手動で割り当てた名前でも、デプロイされたアーカイブ・ファイルの名前でも、デプロイされた展開アーカイブ・ディレクトリの名前でもよいです。同じモジュールを異なるファイル名で、または別の場所から再デプロイする場合、デフォルト・デプロイメント名も変わるため、適切なURIを使用するように参照側アプリケーションを更新する必要があります。

この問題を避けるには、すべての共有Java EEライブラリを、スタンドアロン・モジュールではなく、エンタープライズ・アプリケーションとしてデプロイします。スタンドアロンJava EEモジュールとしてライブラリをデプロイする場合は、既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前をURIとして使用します。

Java EEアプリケーションまたはモジュールからのオプション・パッケージの参照

Java EEアーカイブ(JAR、WAR、RAR、EAR)は、アーカイブのマニフェスト・ファイルの属性を使用して1つまたは複数の登録済みオプション・パッケージを参照できます。

表12-4 オプション・パッケージ参照用のマニフェスト属性

属性

説明

Extension-List logical_name [...]

オプション・パッケージの依存関係の論理名を定義する文字列値(必須)。Extension-List属性で複数の値を使用すると、複数のオプション・パッケージの依存関係を指定できます。例:

Extension-List: dependency1 dependency2

[logical_name-]Extension-Name

オプション・パッケージの依存関係の名前を識別する文字列値(必須)。この値は、オプション・パッケージのマニフェスト・ファイルで定義されたExtension-Name属性の名前と一致する必要があります。

1つのアーカイブから複数のオプション・パッケージを参照する場合は、Extension-Name属性に適切な論理名を付加します。例:

dependency1-Extension-Name: myOptPkg

[logical_name-]Specification-Version

オプション・パッケージの必要な仕様バージョンを定義する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の仕様バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットでspecification-version値を指定した場合、アーカイブは設定した値を下回らない最新の仕様バージョンに一致するパッケージを使用します。使用可能なすべてのパッケージが設定されたspecification-versionよりも古い場合、アーカイブをデプロイできません。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アーカイブでは、パッケージのマニフェスト・ファイルのSpecification-Version属性に完全一致する文字列値を持つオプション・パッケージが必要になります。(表12-2を参照。)

1つのアーカイブから複数のオプション・パッケージを参照する場合は、Specification-Version属性に適切な論理名を付加します。

[logical_name-]Implementation-Version

オプション・パッケージの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の実装バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アーカイブは設定した値を下回らない最新の実装バージョンに一致するパッケージを使用します。使用可能なすべてのライブラリが、構成されたimplementation-versionよりも古い場合、アプリケーションをデプロイすることはできません。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アーカイブでは、パッケージのマニフェスト・ファイルのImplementation-Version属性に完全一致する文字列値を持つオプション・パッケージが必要になります。(表12-2を参照。)

1つのアーカイブから複数のオプション・パッケージを参照する場合は、Implementation-Version属性に適切な論理名を付加します。

たとえば、依存関係のあるアーカイブの場合、マニフェスト・ファイルの以下の単純なエントリでは、myAppPkgおよびmy3rdPartyPkgという2つのオプション・パッケージを参照します。

Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg

この例では、仕様バージョン2.0以降のmyAppPkgが必要になります。

Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0

この例では、仕様バージョン2.0以降のmyAppPkg、実装バージョンが完全一致するmy3rdPartyPkgが必要になります。

Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0
3rdparty-Implementation-Version: 8.1GA

デフォルトでは、WebLogic Serverは、アプリケーションまたはモジュールをデプロイする際にマニフェスト・ファイルのオプション・パッケージに対する参照を解決できない場合、警告を出力しますが、デプロイメントは続行します。この動作を変更するには、WebLogic Serverの起動時に、コマンド・ラインまたはサーバーの起動を制御するコマンド・スクリプト・ファイルで、システム・プロパティweblogic.application.RequireOptionalPackagesをtrueに設定します。このシステム・プロパティをtrueに設定すると、WebLogic Serverは、マニフェスト・ファイルのオプション・パッケージの参照を解決できない場合、アプリケーションまたはモジュールのデプロイを試行しません。

weblogic.appmergeを使用したライブラリの結合

weblogic.appmergeはライブラリを1つのアプリケーションに結合するために使用するツールです(コンテンツと記述子がそれぞれ結合されます)。結合されたアプリケーションをディスクに書き込む機能もあります。その後でweblogic.appmergeを使用し、ディスクに書き込んだ結合されたアプリケーションを調べることで、ライブラリの結合を理解することもできます。

- CLIからのweblogic.appmergeの使用

- Antタスクとしてのweblogic.appmergeの使用

CLIからのweblogic.appmergeの使用

次の構文を使用してweblogic.appmergeを呼び出します。

java weblogic.appmerge [options] <ear, jar, war file, or directory>

有効なオプションを表12-5に示します。

表12-5 weblogic.appmergeのオプション

オプション

説明

-help

標準の使用方法メッセージを出力します。

-version

バージョン情報を出力します。

-output <file>

代替的な出力アーカイブまたはディレクトリを指定します。これが設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。

-plan <file>

デプロイメント・プラン(オプション)を指定します。

-verbose

より冗長な出力を提供します。

-library <file>

ライブラリのカンマ区切りのリスト。各ライブラリは、マニフェストで設定されていない場合、その名前とバージョンを次の構文で設定できます。

<file> [@name=<string>@libspecver=<version> @libimplver=<version|string>].

-librarydir <dir>

指定したディレクトリ内のすべてのファイルをライブラリとして登録します。

-writeInferredDescriptors

アプリケーションまたはモジュールに、デプロイメント記述子がアノテーション情報と共に格納されることを指定します。

例:

$ java weblogic.appmerge -output CompleteSportsApp.ear -library Weather.war,Calendar.ear SportsApp.ear

Antタスクとしてのweblogic.appmergeの使用

Antタスクではコマンド・ライン・ユーティリティと同様の機能を提供しています。source、output、librarydir、plan、およびverboseの各属性と、複数の<library>下位要素がサポートされています。次に例を示します。

<taskdef name="appmerge" classname="weblogic.ant.taskdefs.j2ee.AppMergeTask"/>
<appmerge source="SportsApp.ear" output="CompleteSportsApp.ear">
<library file="Weather.war"/>
<library file="Calendar.ear"/>
</appmerge>

分割開発ディレクトリ環境への共有Java EEライブラリの統合

BuildXMLGenには、1つまたは複数の共有Java EEライブラリ・ディレクトリを含むビルド・ターゲットを生成するための-librarydirオプションがあります。「weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成」を参照してください。

wlcompileおよびwlappc Antタスクには、アプリケーション・ビルドのクラスパスに含める1つまたは複数の共有Java EEライブラリを指定するためのlibrarydir属性とlibrary要素があります。「分割開発ディレクトリでのアプリケーションのビルド」を参照してください。

共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ

共有Java EEライブラリを1つまたは複数のWebLogic Serverインスタンスに登録するには、ターゲット・サーバーにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有Java EEライブラリは、ライブラリを参照するアプリケーションのデプロイ先と同じWebLogic Serverインスタンスに登録する必要があります。必要なライブラリを登録していないサーバー・インスタンスに参照側アプリケーションをデプロイする場合、参照側アプリケーションのデプロイメントは失敗します。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverでのライブラリの登録に関する項を参照してください。

WebLogic Server管理コンソールを使用して共有Java EEライブラリをインストール(デプロイ)する場合の詳細な手順については、「Java EEライブラリのインストール」を参照してください。WebLogic Server管理コンソールを使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバーまたはクラスタにライブラリをデプロイする場合の手順については、「Java EEライブラリのサーバーまたはクラスタへの割当て」を参照してください。

繰返しの開発プロセスの一部としてwldeploy Antタスクを使用する場合は、library、libImplVer、およびlibSpecVer属性を使用して共有Java EEライブラリをデプロイします。詳細およびその他のサンプルについては、wldeploy Antタスクのリファレンスを参照してください。

共有Java EEライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係にあるアプリケーションは、ターゲット・サーバーが必要なすべてのライブラリを登録していて、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のライブラリを参照するアプリケーションのデプロイに関する項を参照してください。

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

このトピックでは、大部分において、エンタープライズ・アプリケーションでのみ参照可能な共有Java EEライブラリについて説明しています。ただし、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション・ライブラリと非常に似ていますが、参照方法が多少異なります。

注意:

わかりやすくするため、この項では、別のWebアプリケーションのみによって参照される共有Java EEライブラリの呼称として、Webアプリケーション・ライブラリという用語を使います。

具体的には:

- Webアプリケーション・ライブラリは、別のWebアプリケーションでのみ参照可能です。

- Webアプリケーションは、Webアプリケーション・ライブラリを参照する場合に、weblogic-application.xmlファイルではなくweblogic.xmlデプロイメント記述子ファイルを更新します。要素は、「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」で説明されているものとほぼ同じです。唯一の違いは、<library-ref>の<context-root>子要素がここでは無視されることです。

- Webアプリケーションのweblogic.xmlデプロイメント記述子ファイルから、別のタイプの共有Java EEライブラリ(EJB、エンタープライズ・アプリケーション、プレーンJARファイル)を参照することはできません。

こうした参照方法の違いを除けば、Webアプリケーション・ライブラリを作成、パッケージ化、デプロイする方法は、通常の共有Java EEライブラリの場合と同じです。

WebアプリケーションにおけるWebアプリケーション・ライブラリの使用

標準の共有Java EEアプリケーションをアプリケーション・ライブラリとしてWebLogic Serverにデプロイできるのと同様に、標準のWebアプリケーションをWebアプリケーション・ライブラリとしてWebLogic Serverにデプロイし、他のWebアプリケーションがこれらのライブラリを参照できるようにすることが可能です。

Webアプリケーション・ライブラリを使用するとコードとリソースの再利用が容易になります。また、Webアプリケーションが使用する可能性のあるサード・パーティのWebアプリケーションまたはフレームワークを分離するのにも役立ちます。さらに、共通のリソースをライブラリとして個別にパッケージ化し、様々なWebアプリケーションで参照されるようにすることもできます。こうすると、そのリソースを各Webアプリケーションにバンドルする必要がなくなります。WebアプリケーションにWebアプリケーション・ライブラリを含める場合、コンテナはデプロイメント時に、すべての静的リソース、クラス、およびJARファイルをWebアプリケーションに結合します。

Webアプリケーション・ライブラリを使用する最初の手順は、Webアプリケーションをwebapp-libraryとして登録することです。それには、WebLogic Server管理コンソールまたはweblogic.Deployerツールを使用してWebアプリケーションをライブラリとしてデプロイします。他のWebアプリケーションにこのライブラリを参照させるには、次のように、各アプリケーションのweblogic.xmlファイルで、Webアプリケーション・ライブラリを指すlibrary-ref要素を指定する必要があります。

<library-ref>
<library-name>BaseWebApp</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1beta</implementation-version>
<exact-match>false</exact-match>
</library-ref>

複数のライブラリがある場合、CLASSPATH/resourceパスの優先順位は、weblogic.xmlファイルでlibrary-ref要素が出現する順序に従います。

LibraryRuntimeMBeanに登録された共有Java EEライブラリ情報へのアクセス

デプロイされた各共有Java EEライブラリは、LibraryRuntimeMBeanで表されます。このMBeanを使用すると、名前やバージョンなど、ライブラリ自体の情報を取得できます。また、デプロイされたアプリケーションに関連付けられたApplicationRuntimeMBeanを取得することもできます。ApplicationRuntimeMBeanでは、アプリケーションが使用するライブラリにアクセスする際に、次の2種類の方法を用いることができます。

- getLibraryRuntimes()は、weblogic-application.xmlファイルで参照される共有Java EEライブラリを返します。

- getOptionalPackageRuntimes()は、マニフェスト・ファイルで参照されるオプション・パッケージを返します。

詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください。

共有Java EEライブラリの参照時のモジュールの優先順位

エンタープライズ・アプリケーションが1つまたは複数の共有Java EEライブラリを参照し、アプリケーションがWebLogic Serverにデプロイされている場合、サーバーは内部で参照側のエンタープライズ・アプリケーションのweblogic-application.xmlファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。これは、次の順序で行われます。

1. エンタープライズ・アプリケーションがデプロイされると、WebLogic Serverはweblogic-application.xmlデプロイメント記述子を読み込みます。

2. WebLogic Serverは、参照対象の任意の共有Java EEライブラリのデプロイメント記述子を読み込みます。ライブラリのタイプ(エンタープライズ・アプリケーション、EJBまたはWebアプリケーション)によって、読み込まれるファイルはweblogic-application.xml、weblogic.xml、weblogic-ejb-jar.xmlなどになります。

3. WebLogic Serverは、参照される共有Java EEライブラリのデプロイメント記述子を最初に(一度に参照される順番で)結合し、そのライブラリの記述子ファイルの上に参照側のエンタープライズ・アプリケーションのweblogic-application.xmlファイルを結合します。

記述子ファイルの結合方法の結果、weblogic-application.xmlファイルで最初に参照される共有Java EEライブラリの記述子の要素が、最後にあるものよりも優先されます。エンタープライズ・アプリケーションの記述子自体の要素は、ライブラリの記述子のすべての要素よりも優先されます。

たとえば、myAppというエンタープライズ・アプリケーションが、それぞれエンタープライズ・アプリケーションとしてパッケージ化されている2つの共有Java EEライブラリmyLibAとmyLibBをその順序で参照するとします。myAppアプリケーションとmyLibAアプリケーションには、myEJBというEJBモジュール、myLibAアプリケーションとmyLibBアプリケーションには、myOtherEJBというEJBモジュールがあります。

さらに、myAppアプリケーションがデプロイされると、クライアントがmyAppアプリケーションを介してmyEJBモジュールを呼び出すとします。この場合、参照する側のアプリケーションのモジュールは参照対象のアプリケーションのモジュールよりも優先されるので、WebLogic Serverは、実際にはmyLibAのEJBではなくmyAppアプリケーションのEJBを呼び出します。クライアントがmyOtherEJBのEJBを呼び出すと、WebLogic ServerはmyLibAのEJBを呼び出します。これは、myAppのweblogic-application.xmlファイルで最初にライブラリが参照され、同じ名前を持つmyLibBアプリケーションのEJBよりも優先されるためです。

共有Java EEライブラリを使用する場合のベスト・プラクティス

共有Java EEライブラリおよびオプション・パッケージを開発する際には、以下のベスト・プラクティスに留意してください。

- 1つまたは複数のJava EEモジュール(EJB、Webアプリケーション、エンタープライズ・アプリケーションまたはプレーンJavaクラス)を複数のエンタープライズ・アプリケーション間で共有する場合、共有Java EEライブラリを使用します。

- EJB JARファイルなどのスタンドアロンJava EEモジュールを共有Java EEライブラリとしてデプロイする場合は、エンタープライズ・アプリケーション内にモジュールをパッケージ化します。これにより、スタンドアロン・モジュールのURIがデプロイメント名から派生することになるので、URIの競合を防ぐことができます。

- スタンドアロンJava EEモジュールとして共有Java EEライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前をURIとして使用します。

- 複数のJava EEアーカイブ・ファイルで複数のJavaクラスを共有する場合は、オプション・パッケージを使用します。

- ドメイン全体のアプリケーションで使用できるようにする必要があるクラスがあり、それらのクラスを頻繁には更新しない場合(たとえば、ドメイン内でサード・パーティのクラスを共有する必要がある場合)は、共有Java EEライブラリやオプション・パッケージではなく、ドメインの/libサブディレクトリを使用します。/libサブディレクトリ内のクラスは、ドメイン内のWebLogic Serverインスタンスで実行しているすべてのJava EEアプリケーションで(別のシステム・レベル・クラスローダー内で)使用できるようになります。

- 依存関係があるアプリケーションに対しては、バージョンの要件を具体的に指定する必要がない場合でも、仕様バージョンと実装バージョンを必ず指定します。共有Java EEライブラリに対してバージョンを指定すると、複数のバージョンの共有ファイルをテスト用にデプロイできます。

- 共有Java EEライブラリごとにExtension-Name値を必ず指定します。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ・デプロイメントと展開されたアーカイブ・デプロイメントでは異なります。デプロイメント・コマンドで任意の値に設定できます。

- 共有Java EEライブラリとしてデプロイメントするWebアプリケーションを開発する場合は、一意なコンテキスト・ルートを使用します。このコンテキスト・ルートが、依存関係のあるJava EEアプリケーションのコンテキスト・ルートと競合する場合、EARのweblogic-application.xmlデプロイメント記述子のcontext-root要素を使用して、ライブラリのコンテキスト・ルートをオーバーライドします。

- 組織の管理者またはデプロイ担当者に配布するために、共有Java EEライブラリをアーカイブ・ファイルとしてパッケージ化します。開発時に、展開されたアーカイブ・ディレクトリからライブラリをデプロイすると、更新および繰返しの再デプロイメントを簡単に実行できます。

- 依存関係があるアプリケーションとアーカイブのデプロイ先となるすべてのWebLogic Serverインスタンスに共有Java EEライブラリをデプロイします。参照側アプリケーションのデプロイ先となるサーバー・インスタンスにライブラリが登録されていない場合、参照側アプリケーションのデプロイメントは失敗します。

13 アプリケーション・ライフサイクル・イベントのプログラミング

この章では、WebLogic Server のアプリケーション・ライフ・サイクル・イベントに応答するアプリケーションの作成方法について説明します。

この章の内容は次のとおりです。

- アプリケーション・ライフサイクル・イベントの理解

- weblogic-application.xmlへのイベントの登録

- 基本的なライフサイクル・リスナー機能のプログラミング

- URIパラメータを指定した場合と指定しない場合のライフサイクル・イベントの構成例

- 再デプロイメント時のアプリケーション・ライフサイクル・イベントの動作の理解

- アプリケーション・バージョン・ライフサイクル・イベントのプログラミング

注意:

アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。起動クラスと停止クラスに関するこの章の情報は、後方互換性のためにのみ提供されています。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用してください。

アプリケーション・ライフサイクル・イベントの理解

アプリケーション・ライフサイクル・リスナー・イベントは、デプロイメント、アンデプロイメント、および再デプロイメント時の動作を開発者が制御できるハンドルを提供します。この項では、アプリケーション・ライフサイクル・リスナー・イベントの使用方法について説明します。

WebLogic Serverには、リスナー・クラス、停止クラス、および起動クラスを拡張するときに使用できる4つのアプリケーション・ライフサイクル・イベントがあります。以下のものが含まれます。

- リスナー - 任意のイベントにアタッチできます。リスナーのメソッドの例は次のとおりです。

- public void preStart(ApplicationLifecycleEvent evt) {}
preStartイベントは、準備フェーズを開始、またはアプリケーションのデプロイメント・プロセスを開始します。

- public void postStart(ApplicationLifecycleEvent evt) {}
postStartイベントは、アクティブ化フェーズを終了、またはアプリケーションのデプロイメント・プロセスを終了します。アプリケーションがデプロイされます。

- public void preStop(ApplicationLifecycleEvent evt) {}
preStopイベントは、非アクティブ化フェーズを開始、またはアプリケーションの削除またはアンデプロイメントのプロセスを開始します。

- public void postStop(ApplicationLifecycleEvent evt) {}
postStopイベントは、削除フェーズを終了、またはアプリケーションの削除またはアンデプロイメントのプロセスを終了します。

- 停止クラスはpostStopイベントのみを取得します。

注意:

アプリケーション・スコープの停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。代わりに、ライフサイクル・リスナーを使用してください。

- 起動クラスはpreStartイベントのみを取得します。

注意:

アプリケーション・スコープの停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。代わりに、ライフサイクル・リスナーを使用してください。

起動クラスおよび停止クラスでは、main{}メソッドのみを実装します。リスナー用に提供されたメソッドを実装した場合は、無視されます。

ApplicationLifecycleListenerにremove{}メソッドは提供されていません。イベントが、デプロイメントでの起動時(prestartとpoststart)およびアンデプロイメントでの停止時(prestopとpoststop)にのみ開始されるためです。

weblogic-application.xmlへのイベントの登録

これらのイベントを使用するには、weblogic-application.xmlデプロイメント記述子に登録する必要があります。エンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。以下の要素を定義します。

- listener - ユーザー定義のアプリケーション・ライフサイクル・リスナーを登録するときに使用します。これらは、抽象ベース・クラスweblogic.application.ApplicationLifecycleListenerを拡張するクラスです。

- shutdown - ユーザー定義の停止クラスを登録するときに使用します。

- startup - ユーザー定義の起動クラスを登録するときに使用します。

基本的なライフサイクル・リスナー機能のプログラミング

抽象クラス(WebLogic Server付属のクラス) weblogic.application.ApplicationLifecycleListenerを拡張することにより、リスナーを作成します。作成したリスナーは、コンテナの検索対象になります。

WebLogic ServerのApplicationLifecycleListener抽象クラスに提供されている次のメソッドをオーバーライドし、必要な機能を追加してアプリケーションを拡張します。

- preStart{}

- postStart{}

- preStop{}

- postStop{}

例13-1は、ApplicationLifecycleListenerをオーバーライドする方法を示します。この例では、パブリック・クラスMyListenerがApplicationLifecycleListenerを拡張しています。

例13-1 MyListener

import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyListener extends ApplicationLifecycleListener {
public void preStart(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(preStart) -- we should always see you..");
} // preStart
public void postStart(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(postStart) -- we should always see you..");
} // postStart
public void preStop(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(preStop) -- we should always see you..");
} // preStop
public void postStop(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(postStop) -- we should always see you..");
} // postStop
public static void main(String[] args) {
System.out.println
("MyListener(main): in main .. we should never see you..");
} // main
}

例13-2に、停止クラスを実装する方法を示します。停止クラスは、preStopイベントおよびpostStopイベントにアタッチできます。この例では、パブリック・クラスMyShutdownはApplicationLifecycleListenerを拡張しません。これは、weblogic-application.xmlデプロイメント記述子で宣言された停止クラスはWebLogic Server固有のインタフェースに依存しないためです。

例13-2 MyShutdown

import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyShutdown {
public static void main(String[] args) {
System.out.println
("MyShutdown(main): in main .. should be for post-stop");
} // main
}

例13-3に、起動クラスを実装する方法を示します。起動クラスは、preStartイベントおよびpostStartイベントにアタッチできます。この例では、パブリック・クラスMyStartupはApplicationLifecycleListenerを拡張しません。これは、weblogic-application.xmlデプロイメント記述子で宣言された起動クラスはWebLogic Server固有のインタフェースに依存しないためです。

例13-3 MyStartup

import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyStartup {
public static void main(String[] args) {
System.out.println
("MyStartup(main): in main .. should be for pre-start");
} // main
}

ロールベースのアプリケーション・ライフサイクル・リスナーの構成

run-as-principal-name要素を使用して起動イベントや停止イベントに対してユーザーIDを指定できる、ロールベース機能を備えたアプリケーション・ライフサイクル・イベントを構成できます。ただし、アプリケーション・ライフサイクル・リスナー用に定義されたrun-as-principal-name IDが管理者である場合、アプリケーション・デプロイヤには管理者権限が必要です。管理者権限がない場合、デプロイメントは失敗します。

1. 「基本的なライフサイクル・リスナー機能のプログラミング」で説明した基本的なプログラミング手順に従います。

2. listener要素内に、run-as-principal-name要素を追加して、イベントの起動や停止を行う権限のあるユーザーを指定します。例:

<listener>
<listener-class>myApp.MySessionAttributeListenerClass</listener-class>
<run-as-principal-name>javajoe</run-as-principal-name>
</listener>

ここに指定するIDはシステムの有効なユーザー名である必要があります。run-as-principal-nameを指定しない場合、アプリケーション・ライフサイクル・リスナーの実行のためのrun-as IDとしては、デプロイメント・イニシエータのユーザーIDが使用されます。

URIパラメータを指定した場合と指定しない場合のライフサイクル・イベントの構成例

次の例に、weblogic-application.xmlデプロイメント記述子ファイルでアプリケーション・ライフサイクル・イベントを構成する方法を示します。URIパラメータは必須ではありません。アプリケーションの$CLASSPATH内であれば任意の位置にクラスを配置できます。ただし、$CLASSPATHにクラスの位置を定義する必要があります。EARにAPP-INF/classesディレクトリまたはAPP-INF/libディレクトリが存在する場合は、これらのディレクトリにリスナーを配置できます。この場合、リスナーは自動的に$CLASSPATHに含まれます。

次の例に、URIパラメータを使用してアプリケーション・ライフサイクル・イベントを構成する方法を示します。この例では、アーカイブfoo.jarはクラスを含み、EARファイルの最上位に存在します。(例: myEar/foo.jar)

例13-4 URIパラメータを使用したアプリケーション・ライフサイクル・イベントの構成

<listener>
<listener-class>MyListener</listener-class>
<listener-uri>foo.jar</listener-uri>
</listener>
<startup>
<startup-class>MyStartup</startup-class>
<startup-uri>foo.jar</startup-uri>
</startup>
<shutdown>
<shutdown-class>MyShutdown</shutdown-class>
<shutdown-uri>foo.jar</shutdown-uri>
</shutdown>

次の例に、URIパラメータを使用せずにアプリケーション・ライフサイクル・イベントを構成する方法を示します。

例13-5 URIパラメータを使用しないアプリケーション・ライフサイクル・イベントの構成

<listener>
<listener-class>MyListener</listener-class>
</listener>
<startup>
<startup-class>MyStartup</startup-class>
</startup>
<shutdown>
<shutdown-class>MyShutdown</shutdown-class>
</shutdown>

再デプロイメント時のアプリケーション・ライフサイクル・イベントの動作の理解

アプリケーションの完全な再デプロイメントが発生する場合にのみ、アプリケーション・ライフサイクル・イベントが開始されます。アプリケーションの完全な再デプロイメント時に、アプリケーション・ライフサイクル・イベントが登録済みであれば、アプリケーション・ライフサイクルはまず停止シーケンスを開始し、次にクラスを再初期化し、その後開始シーケンスを実行します。

たとえば、完全なアプリケーション・ライフサイクル・イベント・セット(preStart、postStart、preStop、postStop)に対してリスナーが登録されている場合、完全な再デプロイメント時に次のイベント・シーケンスが表示されます。

1. preStop{}

2. postStop{}

3. 初期化が開始されます。(デバッグ・フラグを設定していない場合、初期化は表示されません。)

4. preStart{}

5. postStart{}

アプリケーション・バージョン・ライフサイクル・イベントのプログラミング

次の項では、WebLogic Serverのアプリケーション・バージョン・ライフサイクル・イベントに応答するアプリケーションの作成方法について説明します。

- アプリケーション・バージョン・ライフサイクル・イベントの動作の理解

- アプリケーション・バージョン・ライフサイクル・イベントの種類

- アプリケーション・バージョン・ライフサイクル・イベントを使用する場合の本番デプロイメント・シーケンスの例

アプリケーション・バージョン・ライフサイクル・イベントの動作の理解

WebLogic Serverはアプリケーション・バージョン・ライフサイクル・イベントの通知を提供しており、ApplicationVersionLifecycleListenerクラスを拡張してweblogic-application.xmlでライフサイクル・リスナーを指定できます。エンタープライズ・アプリケーションのデプロイメント記述子の要素とURIパラメータを指定した場合と指定しない場合のライフサイクル・イベントの構成例を参照してください。

アプリケーション・バージョン・ライフサイクル・イベントは次のように呼び出されます。

- 静的なデプロイメントと動的なデプロイメントの両方の場合。

- 匿名IDとユーザーIDのいずれかを使用して。

- 現在のアプリケーションがバージョン管理されている場合のみ。それ以外の場合、バージョン・ライフサイクル・イベントは無視されます。

- リスナーを登録しているバージョンを含めて、すべてのアプリケーション・バージョンについて。イベントが特定のバージョンに属しているかどうかを調べるには、ApplicationVersionLifecycleEvent.isOwnVersionメソッドを使用します。バージョン・ライフサイクル・イベントの種類の詳細は、ApplicationVersionLifecycleEventクラスを参照してください。

アプリケーション・バージョン・ライフサイクル・イベントの種類

WebLogic Serverには4つのアプリケーション・バージョン・ライフサイクル・イベントがあります。

- public void preDeploy(ApplicationVersionLifecycleEvent evt)

- preDeloyイベントは、アプリケーション・バージョンのデプロイまたは再デプロイ操作が開始されたときに呼び出されます。

- public void postDeploy(ApplicationVersionLifecycleEvent evt)

- postDeloyイベントは、アプリケーション・バージョンが正常にデプロイまたは再デプロイされたときに呼び出されます。

- public void preUndeploy(ApplicationVersionLifecycleEvent evt)

- preUndeloyイベントは、アプリケーション・バージョンのアンデプロイ操作が開始されたときに呼び出されます。

- public void postDelete(ApplicationVersionLifecycleEvent evt)

- postDeleteイベントは、アプリケーション・バージョンが削除されたときに呼び出されます。

注意:

postDeleteイベントは、アプリケーション・バージョン全体が完全に削除された後にのみ起動されます。これには、モジュールのアンデプロイやターゲットのサブセットからのアンデプロイなどの部分的なアンデプロイは含まれません。

アプリケーション・バージョン・ライフサイクル・イベントを使用する場合の本番デプロイメント・シーケンスの例

以下の表では、デプロイメント(V1)、本番再デプロイメント(V2)、およびアンデプロイ(V2)の例を示します。

表13-1 デプロイメント・アクションとアプリケーション・バージョン・ライフ・サイクル・イベントのシーケンス

デプロイメント・アクション

時間

バージョンV1

バージョンV2

バージョンV1のデプロイメント

T0

preDeploy(V1)が呼び出されます。

バージョンV1のデプロイメント

T1

デプロイメントが開始されます。

バージョンV1のデプロイメント

T2

V1のアプリケーション・ライフサイクル・リスナーが登録されます。

バージョンV1のデプロイメント

T3

V1がアクティブなバージョンとなり、デプロイメントが完了します。

バージョンV1のデプロイメント

T4

postDeploy(V1)が呼び出されます。

バージョンV1のデプロイメント

T5

アプリケーション・リスナーがpostDeploy(V1)を取得します。

バージョンV2の本番再デプロイメント

T6

preDeploy(V2)が呼び出されます。

バージョンV2の本番再デプロイメント

T7

アプリケーション・バージョン・リスナーがpreDeploy(V1)を受け取ります。

バージョンV2の本番再デプロイメント

T8

デプロイメントが開始されます。

バージョンV2の本番再デプロイメント

T9

V2のアプリケーション・ライフサイクル・リスナーが登録されます。

バージョンV2の本番再デプロイメント

T10

デプロイ(V2)が成功すると、V1はアクティブなバージョンでなくなります。

デプロイ(V2)が成功すると、V2はV1に代わってアクティブなバージョンとなります。

デプロイメントが完了します。

バージョンV2の本番再デプロイメント

T11

postDeploy(V2)が呼び出されます。

注意:このイベントはデプロイメントが失敗した場合でも発生します。

バージョンV2の本番再デプロイメント

T12

アプリケーション・バージョン・リスナーがpostDeploy(V2)を取得します。デプロイ(V2)が失敗した場合、V1はアクティブなままとなります。

バージョンV2の本番再デプロイメント

T13

アプリケーション・リスナーがpostDeploy(V2)を取得します。

バージョンV2の本番再デプロイメント

T14

デプロイ(V2)が成功すると、V1はリタイアを開始します。

バージョンV2の本番再デプロイメント

T15

V1のアプリケーション・リスナーが登録解除されます。

バージョンV2の本番再デプロイメント

T16

V1がリタイアされます。

V2のアンデプロイメント

T17

preUndeploy(v2)が呼び出されます。

V2のアンデプロイメント

T18

アプリケーション・リスナーは呼び出されたpreUndeploy(v2)を取得します。

V2のアンデプロイメント

T19

アンデプロイメントが開始されます。

V2のアンデプロイメント

T20

V2がアクティブなバージョンでなくなります。

V2のアンデプロイメント

T21

V2のアプリケーション・バージョン・リスナーが登録解除されます。

V2のアンデプロイメント

T22

アンデプロイメントが完了します。

V2のアンデプロイメント

T23

アプリケーション全体がアンデプロイされると、postDelete(V2)が呼び出されます。

注意:このイベントはアンデプロイメントが失敗した場合でも発生します。

14 コンテキスト伝播のプログラミング

この章では、WebLogic Serverアプリケーションでコンテキスト伝播APIを使用する方法を説明します。

この章の内容は次のとおりです。

- コンテキストの伝播の理解

- コンテキスト伝播のプログラミング: 主な手順

- クライアントのコンテキスト伝播のプログラミング

- アプリケーションのコンテキスト伝播のプログラミング

コンテキストの伝播の理解

コンテキストの伝播により、プログラマは情報をアプリケーションと関連付けできます。さらに、下流のコンポーネントは、この情報を送り元に戻せるように、情報に対し追加または修正を行えます。コンテキストの伝播では、WorkContextを介してリクエストに情報をアタッチします。この情報は、PropagationModeを介して、コンテキスト伝播をサポートしている任意のプロセスにリクエストとともに伝えられます。コンテキストの伝播は、作業領域、作業コンテキスト、またはアプリケーション・トランザクションとしても知られています。

通常、コンテキストの伝播を使用するのは、アプリケーションの不可欠な一部である情報ではなく、アプリケーションの外部または別のアプリケーションに情報(通常はリクエストに関連する情報)を運ぶ必要があるアプリケーションです。たとえば、診断モニター、アプリケーション・トランザクション、アプリケーションのロード・バランシングなどがそれに当たります。コンテキストの伝播ではリクエストに情報を関連付けることができるので、データ管理が大幅に簡素化されます。これは、アプリケーションごとにリクエスト・データのマップを保持し、カスタム・コードを実装してアプリケーション間またはスレッド間で情報を伝送する方法とは対照的です。

コンテキスト伝播はアプリケーション内で発生することがあります。たとえば、アプリケーションからワーク・マネージャ経由で作業が送信されると、処理の一部が別のスレッド内で発生します。コンテキスト伝播で別のスレッドに情報を伝送するには、PropagationModeを使用します。

コンテキスト伝播のプログラミングでは、最初にWorkContextMapとWorkContextを作成するクライアント・アプリケーションのコードを記述し、次にこのデータを取得および必要に応じて使用する呼出し対象のアプリケーション自体のコードを記述します。呼出し対象のアプリケーションは、EJB、Webサービス、サーブレット、JMSトピックまたはキューなど、どのような種類のものでも構いません。詳細は、「コンテキスト伝播のプログラミング: 主な手順」を参照してください。

WebLogicコンテキスト伝播APIはweblogic.workareaパッケージにあります。次の表に、主なインタフェースとクラスを示します。

表14-1 WebLogicコンテキスト伝播APIのインタフェースとクラス

インタフェースまたはクラス

説明

WorkContextMapインタフェース

アプリケーションにデータを付け、アプリケーション・リクエストを介してその情報を伝播するコンテキスト伝播のメイン・インタフェース。WorkContextMapsは、クライアントまたはアプリケーションのJNDI環境の一部で、java:comp/WorkContextMapという名前をルックアップしてJNDIからアクセスできます。

WorkContextインタフェース

アプリケーションとともに渡されるユーザー・データのマーシャリングおよびアンマーシャリングに使用するインタフェース。このインタフェースには、単純な8ビットASCIIコンテキスト(AsciiWorkContext)、longコンテキスト(LongWorkContext)、Serializableコンテキスト(SerializableWorkContext)、Stringコンテキスト(StringWorkContext)のデータをマーシャリングおよびアンマーシャリングするために4つの実装クラスがあります。

WorkContextには、PrimitiveWorkContextというサブインタフェースが1つあります。これは、特に単独のプリミティブ・データ項目をマーシャリングおよびアンマーシャリングする場合に使用します。

WorkContextOutput/Inputインタフェース

WorkContext実装をそれぞれマーシャリングおよびアンマーシャリングするためのプリミティブ・ストリームを表すインタフェース。

PropagationModeインタフェース

WorkContextsの伝播プロパティを定義します。WorkContextがローカルで伝播されるか、スレッド間で伝播されるか、RMI呼出し間で伝播されるか、JMSキューおよびトピック間で伝播されるか、SOAPメッセージ間で伝播されるかを指定します。指定しなかった場合のデフォルトは、同一スレッド内のリモート呼出しとローカル呼出し間でデータを伝播します。

PrimitiveContextFactoryクラス

プリミティブ・データのみを格納するWorkContextsを作成するためのコンビニエンス・クラス。

コンテキスト伝播の完全なAPIドキュメントについては、「weblogic.workareaのJavadoc」を参照してください。

コンテキスト伝播のプログラミング: 主な手順

次に、WebLogic Serverでコンテキスト伝播を使用する高度な手順について説明します。この例では、クライアント上で情報をリクエストに関連付ける方法、サーバー上でその情報を取得する方法、およびサーバー・インスタンスによって更新された値を取得する方法について説明します。この手順では、反復的な開発環境を設定済みで、weblogic.workarea APIを使用してコンテキスト伝播を使用するよう更新する既存のクライアントおよびアプリケーションがあることを前提にしています。

1. クライアント・アプリケーションを更新してWorkContextMapオブジェクトとWorkContextオブジェクトを作成し、ユーザー・データをコンテキストに追加します。

「クライアントのコンテキスト伝播のプログラミング」を参照してください。

2. クライアント・アプリケーションが(WebLogic ServerにデプロイされたJava EEコンポーネントで実行されるのではなく)スタンドアロンの場合、そのCLASSPATHにJava EEアプリケーション・クライアント(シン・クライアントともいいます)が含まれるようにします。

『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。

3. アプリケーション(EJB、Webサービス、サーブレットなど)をさらに更新してWorkContextMapを作成し、追加するコンテキストとユーザー・データをクライアント・アプリケーションから取得します。

「アプリケーションのコンテキスト伝播のプログラミング」を参照してください。

クライアントのコンテキスト伝播のプログラミング

次のサンプルJavaコードでは、Webサービスを呼び出すスタンドアロンJavaクライアントを示します。また、この例では、weblogic.workarea.*コンテキスト伝播APIを使用してユーザー情報を呼出しに関連付ける方法も示します。コンテキスト伝播に該当するコードを太字で示し、サンプルの後で説明を加えます。

コンテキスト伝播の完全なAPIドキュメントについては、「weblogic.workareaのJavadoc」を参照してください。

注意:

Webサービスとそれらを呼び出すクライアント・アプリケーションの作成の詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』を参照してください。

package examples.workarea.client;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import weblogic.workarea.WorkContextMap;
import weblogic.workarea.WorkContext;
import weblogic.workarea.PrimitiveContextFactory;
import weblogic.workarea.PropagationMode;
import weblogic.workarea.PropertyReadOnlyException;
/**
* This is a simple standalone client application that invokes the
* the <code>sayHello</code> operation of your WorkArea Web service.
*
*/
public class Main {
public final static String SESSION_ID= "session_id_key";
public static void main(String[] args)
throws ServiceException, RemoteException, NamingException, PropertyReadOnlyException{
YourWorkAreaService service = new YourWorkAreaService(args[0] + "?WSDL");
YourWorkAreaPortType port = service.getWorkAreaPort();
WorkContextMap map = (WorkContextMap)new InitialContext().lookup("java:comp/WorkContextMap");
WorkContext stringContext = PrimitiveContextFactory.create("A String Context");
// Put a string context
map.put(SESSION_ID, stringContext, PropagationMode.SOAP);
try {
String result = null;
result = port.sayHello("Hi there!");
System.out.println( "Got result: " + result );
} catch (RemoteException e) {
throw e;
}
}
}

上記の例では:

- 次のコードは、必要なweblogic.workarea.*クラス、インタフェース、および例外をインポートする方法を示しています。

import weblogic.workarea.WorkContextMap;
import weblogic.workarea.WorkContext;
import weblogic.workarea.PrimitiveContextFactory;
import weblogic.workarea.PropagationMode;
import weblogic.workarea.PropertyReadOnlyException;

- YourWorkAreaServiceおよびYourWorkAreaPortTypeに、WebサービスのWorkAreaのサービスとポートの実装を代入します。

- 次のコードは、コンテキスト伝播固有のJNDI名java:comp/WorkContextMapのJNDIルックアップを実行することでWorkContextMapを作成する方法を示しています。

WorkContextMap map = (WorkContextMap)
new InitialContext().lookup("java:comp/WorkContextMap");

- 次のコードは、PrimitiveContextFactoryを使用してWorkContextを作成する方法を示しています。この例では、WorkContextは、単純な文字列値A String Contextで構成されています。文字列値は、呼び出されるWebサービスに渡されるユーザー・データです。

WorkContext stringContext =
PrimitiveContextFactory.create("A String Context");

- 次のコードは、stringContextをSESSION_IDキーでWorkContextMapに保存します。伝播モードのSOAPを指定すると、stringContextの伝播はSOAPメッセージを介して、コンテキスト伝播をサポートしているサーバーに送信されます。

map.put(SESSION_ID, stringContext, PropagationMode.SOAP);

アプリケーションのコンテキスト伝播のプログラミング

次のサンプルJavaコードでは、Webサービスを実装するシンプルなJava Webサービス(Java Web Service: JWS)ファイルを示します。JWSファイルには、Webサービスの呼出しに関連付けられるユーザー・データを取得するためのコンテキスト伝播コードも含まれます。コンテキスト伝播に該当するコードを太字で示し、サンプルの後で説明を加えます。

コンテキスト伝播の完全なAPIドキュメントについては、「weblogic.workareaのJavadoc」を参照してください。

注意:

Webサービスとそれらを呼び出すクライアント・アプリケーションの作成の詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』を参照してください。

package examples.workarea;
import javax.naming.InitialContext;
// Import the Context Propagation classes
import weblogic.workarea.WorkContextMap;
import weblogic.workarea.WorkContext;
import javax.jws.WebMethod;
import javax.jws.WebService;
import weblogic.jws.WLHttpTransport;
@WebService(name="WorkAreaPortType",
serviceName="WorkAreaService",
targetNamespace="http://example.org")
@WLHttpTransport(contextPath="workarea",
serviceUri="WorkAreaService",
portName="WorkAreaPort")
/**
* This JWS file forms the basis of simple WebLogic
* Web service with a single operation: sayHello
*
*/
public class WorkContextAwareWebService {
public final static String SESSION_ID = "session_id_key";
@WebMethod()
public String sayHello(String message) {
try {
WorkContextMap map = (WorkContextMap) new InitialContext().lookup("java:comp/WorkContextMap");
WorkContext modifiedLocalWC = PrimitiveContextFactory.create(localwc.get() + " could be replaced by a new value...");
map.put(SESSION_ID, newLocalWC, PropagationMode.SOAP);
System.out.println("local context: " + localwc);
System.out.println("sayHello: " + message);
return "The server received message: " + message + ", with SESSION_ID: " + localwc;
} catch (Throwable t) {
return "error";
}
}
}

上記の例では:

- 次のコードは、必要なコンテキスト伝播APIをインポートする方法を示しています。ここでは、WorkContextMapインタフェースとWorkContextインタフェースのみが要求されています。

import weblogic.workarea.WorkContextMap;
import weblogic.workarea.WorkContext;

- 次のコードは、コンテキスト伝播固有のJNDI名java:comp/WorkContextMapのJNDIルックアップを実行することでWorkContextMapを作成する方法を示しています。

WorkContextMap map = (WorkContextMap)
new InitialContext().lookup("java:comp/WorkContextMap");

- 伝播モードはSOAPのみで、サーバーにはリクエストの伝播が、クライアントにはレスポンスの伝播がそれぞれ発生します。次のコードは、サーバー・インスタンスでstringContextを変更する方法を示しています。

WorkContext modifiedLocalWC = PrimitiveContextFactory.create(localwc.get() + " could be replaced by a new value...");

- 次のコードは、作業コンテキストを更新された値で置換します。サーバーからレスポンスが返された後、クライアント上でSESSION_IDを取得すると、サーバーによって更新された値がクライアントで表示されるようになります。

map.put(SESSION_ID, newLocalWC, PropagationMode.SOAP);

15 WebLogic ServerでのJavaMailのプログラミング

この章では、WebLogic Server でJavaMailをプログラミングしてWebLogic Serverアプリケーションに電子メール機能を追加する方法を説明します。

この章の内容は次のとおりです。

- WebLogic ServerアプリケーションでのJavaMailの使用の概要

- JavaMail構成ファイルの理解

- WebLogic Server用のJavaMailの構成

- JavaMailを使用したメッセージの送信

- JavaMailを使用したメッセージの読込み

WebLogic ServerアプリケーションでのJavaMailの使用の概要

WebLogic ServerにはJavaMail APIバージョン1.4参照実装が含まれています。JavaMail APIを使用すると、WebLogic Serverアプリケーションに電子メール機能を追加できます。JavaMailを使用すると、自社ネットワークまたはインターネット上のIMAP (Internet Message Access Protocol)対応およびSMTP (Simple Mail Transfer Protocol)対応のメール・サーバーにJavaアプリケーションからアクセスできます。JavaMailはメール・サーバー機能を持っていないので、JavaMailを使用するにはメール・サーバーが必要です。

JavaMail APIの使用方法に関する詳細なドキュメントは、http://www.oracle.com/technetwork/java/javamail-138606.htmlで参照できます。この項では、WebLogic Server環境でJavaMailを使用する方法について説明しています。

weblogic.jarファイルには、次のJavaMail APIパッケージが含まれています。

- javax.mail

- javax.mail.event

- javax.mail.internet

- javax.mail.search

weblogic.jarファイルには、JavaMailで必要なJAF (Java Activation Framework)パッケージも含まれています。

javax.mailパッケージには、Internet Message Access Protocol (IMAP)およびSimple Mail Transfer Protocol (SMTP)メール・サーバーのプロバイダが含まれています。JavaMail用に独自のPOP3プロバイダがあります。これは、weblogic.jarには含まれていません。POP3プロバイダは、使用する場合、http://www.oracle.com/technetwork/java/javamail/index-138643.htmlからダウンロードし、それをWebLogic Serverクラスパスに追加できます。

JavaMail構成ファイルの理解

JavaMailは、システムのメール・トランスポート機能を定義する構成ファイルに依存します。weblogic.jarファイルには、標準構成ファイルが入っています。このファイルにより、IMAPおよびSMTPメール・サーバーがJavaMail向けに使用可能になり、JavaMailが処理できるデフォルトのメッセージ・タイプが定義されます。

JavaMailを拡張してサポートされるトランスポート、プロトコル、およびメッセージのタイプを追加する場合を除いて、JavaMail構成ファイルを変更する必要はありません。JavaMailを拡張する場合は、http://www.oracle.com/technetwork/java/javamail-138606.htmlを参照してください。次に、拡張したJavaMailパッケージをweblogic.jarの前のWebLogic Serverクラスパスに追加します。

WebLogic Server用のJavaMailの構成

WebLogic Serverで使用するためにJavaMailを構成するには、WebLogic Server管理コンソールでメール・セッションを作成します。これにより、あらかじめ構成しておくセッション・プロパティを使用して、サーバー側モジュールとアプリケーションでJNDIを用いてJavaMailサービスにアクセスできるようになります。たとえば、メール・セッションを作成すると、メール・ホスト、転送および格納プロトコル、デフォルトのメール・ユーザーをWebLogic Server管理コンソールで指定できるため、JavaMailを使用するモジュールでこれらのプロパティを設定する必要はありません。メール・セッションは単一のjavax.mail.Sessionオブジェクトを作成し、JNDIを通じてそのオブジェクトを必要とするすべてのモジュールで利用できるようにするため、多数の電子メール・ユーザーを持つアプリケーションではメリットが得られます。

WebLogic Server管理コンソールによるメール・セッションの作成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJavaMailへのアクセスの構成に関する項を参照してください。

メール・セッションで設定したプロパティ・セットは、オーバーライドするプロパティを含むjava.util.Propertiesオブジェクトを作成すると、コード内でオーバーライドできます。「JavaMailを使用したメッセージの送信」を参照してください。メール・セッション・オブジェクトをJNDIでルックアップした後、Propertiesオブジェクトを使用してSession.getInstance()メソッドを呼び出し、カスタマイズしたセッションを取得します。

JavaMailを使用したメッセージの送信

WebLogic Serverモジュール内からJavaMailを使用してメッセージを送信する手順は次のとおりです。

1. JNDI (ネーミング)、JavaBean Activation、JavaMailパッケージをインポートします。java.util.Properties:もインポートします。

import java.util.*;
import javax.activation.*;
import javax.mail.*;
import javax.mail.internet.*;
import javax.naming.*;

2. JNDIでメール・セッションを次のようにルックアップします。

InitialContext ic = new InitialContext();
Session session = (Session) ic.lookup("myMailSession");

3. WebLogic Server管理コンソールで設定したセッションのプロパティをオーバーライドする必要がある場合は、java.util.Propertiesオブジェクトを作成してオーバーライドするプロパティを追加します。getInstance()を呼び出して、新しいプロパティの新しいセッション・オブジェクトを取得します。

Properties props = new Properties();
props.put("mail.transport.protocol", "smtp");
props.put("mail.smtp.host", "mailhost");
// use mail address from HTML form for from address
props.put("mail.from", emailAddress);
Session session2 = session.getInstance(props);

4. MimeMessageを作成します。次の例で、to、subject、およびmessageTxtは文字列の変数で、ユーザーが入力した内容が入ります。

Message msg = new MimeMessage(session2);
msg.setFrom();
msg.setRecipients(Message.RecipientType.TO,
InternetAddress.parse(to, false));
msg.setSubject(subject);
msg.setSentDate(new Date());
// Content is stored in a MIME multi-part message
// with one body part
MimeBodyPart mbp = new MimeBodyPart();
mbp.setText(messageTxt);
Multipart mp = new MimeMultipart();
mp.addBodyPart(mbp);
msg.setContent(mp);

5. メッセージを送信します。

Transport.send(msg);

JNDIルックアップでは、障害が発生するとNamingException例外がスローされます。JavaMailでは、トランスポート・クラスの特定またはメール・ホストとの通信に失敗した場合にMessagingExceptionがスローされます。コードをtryブロックの中に配置し、これらの例外を捕捉するようにしておきます。

JavaMailを使用したメッセージの読込み

JavaMail APIを使用すると、メッセージ・ストアに接続できます。メッセージ・ストアはIMAPサーバーまたはPOP3サーバーとなります。メッセージはフォルダに保存されます。IMAPの場合、メッセージ・フォルダはメール・サーバー上に格納されます。メッセージ・フォルダには、受信したメッセージが入るフォルダとアーカイブされたメッセージが入るフォルダがあります。POP3の場合は、メッセージの到着時にメッセージを保存するフォルダをサーバーが提供します。クライアントは、POP3サーバーに接続するときに、メッセージを取得してクライアントのメッセージ・ストアに転送します。

フォルダは、ディスクのディレクトリと同じような階層構造になっています。フォルダにはメッセージまたは他のフォルダを格納できます。デフォルトのフォルダは構造の最上位にあります。特別なフォルダ名であるINBOXは、ユーザーのプライマリ・フォルダのことを指し、デフォルト・フォルダの内部にあります。受信したメールを読み込むには、ストアからデフォルト・フォルダを取得して、次にデフォルト・フォルダからINBOXフォルダを取得します。

APIでは、指定した数または範囲のメッセージを読み取る、またはメッセージの特定の部分をあらかじめ取り出してフォルダのキャッシュに入れるなど、メッセージの読込みについて複数のオプションを提供しています。詳細は、JavaMail APIを参照してください。

WebLogic Serverモジュール内からPOP3サーバーで受信したメッセージを読み込む手順は次のとおりです。

1. JNDI (ネーミング)、JavaBean Activation、JavaMailパッケージをインポートします。java.util.Properties:もインポートします。

import java.util.*;
import javax.activation.*;
import javax.mail.*;
import javax.mail.internet.*;
import javax.naming.*;

2. JNDIでメール・セッションを次のようにルックアップします。

InitialContext ic = new InitialContext();
Session session = (Session) ic.lookup("myMailSession");

3. WebLogic Server管理コンソールで設定したセッションのプロパティをオーバーライドする必要がある場合は、Propertiesオブジェクトを作成してオーバーライドするプロパティを追加します。getInstance()を呼び出して、新しいプロパティの新しいセッション・オブジェクトを取得します。

Properties props = new Properties();
props.put("mail.store.protocol", "pop3");
props.put("mail.pop3.host", "mailhost");
Session session2 = session.getInstance(props);

4. セッションからStoreオブジェクトを取得し、connect()メソッドを呼び出してメール・サーバーに接続します。接続の認証を行うには、接続メソッドでメール・ホスト、ユーザー名、およびパスワードを提供する必要があります。

Store store = session.getStore();
store.connect(mailhost, username, password);

5. デフォルト・フォルダを取得し、そのフォルダを使用してINBOXフォルダを取得します。

Folder folder = store.getDefaultFolder();
folder = folder.getFolder("INBOX");

6. フォルダ内のメッセージを、メッセージの配列に読み込みます。

Message[] messages = folder.getMessages();

7. メッセージの配列にあるメッセージを処理します。メッセージ・クラスには、ヘッダー、フラグ、メッセージの内容など、メッセージの様々な部分にアクセスできるメソッドがあります。

IMAPサーバーからのメッセージの読込みは、POP3サーバーからのメッセージの読込みと同様です。ただしIMAPの場合は、フォルダを作成および操作し、フォルダ間でメッセージを転送するメソッドがJavaMail APIで提供されています。IMAPサーバーを使用すると、POP3サーバーを使用する場合よりも少ないコードで、多機能なWebベースのメール・クライアントを実装できます。POP3では、おそらくデータベースまたはフォルダを表すためのファイル・システムを使用して、WebLogic Serverからメッセージ・ストアを管理するコードを記述する必要があります。

16 トピックのスレッド化とクラスタリング

この章では、WebLogic Server でのスレッドの使用方法と、WebLogic Serverクラスタで使用するアプリケーションのプログラミング方法について説明します。

この章の内容は次のとおりです。

- WebLogic Serverでのスレッドの使用

- ワーク・マネージャAPIを使用した低レベルなスレッド化

- WebLogic Serverクラスタのアプリケーションのプログラミング

WebLogic Serverでのスレッドの使用

WebLogic Serverは高度なマルチスレッド・アプリケーション・サーバーであり、ホストしているモジュールのリソースの割り当て、同時実行性、およびスレッドの同期化を慎重に管理します。WebLogic Serverのアーキテクチャを最大限に活用するには、標準Java EE APIを使用して作成したアプリケーション・モジュールを構築する必要があります。

通常、サーバー側モジュールで新たなスレッドの作成が必要にならないアプリケーション設計をします。

- 独自のスレッドを作成するアプリケーションはあまり効率がよくありません。JVMのスレッドは、慎重に割り当てる必要のある限られたリソースです。サーバーの負荷が増大すると、アプリケーションは停止するか、WebLogic Serverで障害を引き起こすことがあります。デッドロックやスレッドの不足のような問題は、アプリケーションに重い負荷がかかるまで発生しないことがあります。

- マルチスレッド・モジュールは複雑なため、デバッグが困難になります。アプリケーションが生成したスレッドとWebLogic Serverスレッドの間の対話の場合、特に予測や分析が難しくなります。

これらの警告にもかかわらず、スレッドの作成が適切な状況もあります。たとえば、複数のリポジトリを検索して、結合された結果セットを返すアプリケーションの場合、メイン・クライアント・スレッドを同期的に使用する代わりに、各リポジトリの新しいスレッドを非同期的に使用して検索を実行すると、より速く結果が返されることがあります。

アプリケーション・コードでのスレッドの使用を決定したら、アプリケーションが作成するスレッドの数を制限できるようにスレッド・プールを作成します。JDBC接続プールのように、指定した数のスレッドをプールに割り当て、実行可能なクラスのプールから利用できるスレッドを取得します。プール内のすべてのスレッドが使用中の場合は、スレッドが戻されるまで待機します。スレッド・プールを使用すると、パフォーマンスの問題を回避し、WebLogic Serverの実行スレッドとアプリケーションの間のスレッドの割当ても最適化できます。

スレッドでデッドロックが発生しそうな場所を把握しておき、デッドロックが発生したら確実に処理します。設計を慎重に見直して、スレッドがセキュリティ・システムを危険にさらすことのないようにしておきます。

WebLogic Serverスレッドとの望ましくない対話を避けるには、WebLogic Serverモジュールの中でスレッドの呼出しを使用しないようにします。たとえば、作成するスレッドからは、エンタープライズBeanやサーブレットを使用しないでください。アプリケーション・スレッドは、TCP/IP接続による外部サービス、またはファイルの適切なロックや読み書きを行う外部サービスとの対話のような、独立していて分離されたタスクに使用するのが最適です。存続期間が短く、1つの目的を実行して終了する(スレッドをプールに戻します)スレッドの方が、他のスレッドと競合しません。

WebLogic Server上にデプロイされているアプリケーションにパッケージ化されるモジュール内に、デーモン・スレッドを作成しないようにしてください。サーブレットなどのアプリケーション・モジュール内にデーモン・スレッドを作成すると、元のデプロイメント内に作成されたデーモンが実行中のままになるので、アプリケーションを再デプロイできなくなります。

障害のポイントにクライアントを追加して、負荷が次第に大きくなるような状況でマルチスレッドのコードをテストします。アプリケーションのパフォーマンスとWebLogic Serverの動作を監視し、本番環境で障害が発生しないことを確認しておきます。

ワーク・マネージャAPIを使用した低レベルなスレッド化

ワーク・マネージャは、作業項目を同時に実行するための簡単なAPIを提供します。これにより、Java EEベースのアプリケーション(サーブレットやEJBを含む)において作業項目の同時実行をスケジューリングでき、スループットとレスポンス時間を向上させることができます。アプリケーションでは、同時実行する作業項目をワーク・マネージャに送信し、後でその結果を収集できます。ワーク・マネージャが提供する一般的な「結合」演算によって、いずれかの作業項目が完了するのを待機したり、すべての作業項目が完了するのを待機したりできます。アプリケーション・サーバー仕様のワーク・マネージャでは、アプリケーション・サーバーでサポートされる低レベル・スレッド化APIを使用することもできますが、ほとんどのアプリケーションでは使用が難しく、サーブレットやEJBのような管理対象の環境での使用は適切ではありません。

詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

WebLogic Serverクラスタのアプリケーションのプログラミング

WebLogic ServerのクラスタにデプロイされるJSPおよびサーブレットは、セッション・データを保持するために特定の要件に従う必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のHTTPセッション状態のレプリケーションに関する条件に関する項を参照してください。

WebLogic ServerクラスタでデプロイされるEJBには、EJBのタイプによって制約があります。クラスタ内の様々なEJBタイプの機能については、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のWebLogic Enterprise JavaBeansの理解に関する項を参照してください。EJBは、EJBデプロイメント記述子でプロパティを設定することでクラスタにデプロイできます。

クラスタ内でデプロイメント用にEJBまたはカスタムRMIオブジェクトを開発する場合は、『Oracle WebLogic Server JNDIアプリケーションの開発』のクラスタ環境でのWebLogic JNDIの使用に関する項を参照して、クラスタリングされたオブジェクトをJNDIツリーにバインドする影響について理解してください。

17 WebLogic Serverアプリケーション用のOSGiバンドルの開発

この章では、WebLogic Server でのOSGi環境と、OSGiバンドルをWebLogic Serverにデプロイする方法について説明します。アプリケーションでOSGiを使用する開発者達は、OSGiサービス・レジストリ、クラス・ローダー、その他のOSGiサービスなどのOSGiの機能を簡単に共有することができます。

OSGiの全般的な情報については、http://www.osgi.orgを参照してください。

この章の内容は次のとおりです。

- OSGiの理解

- WebLogic Server OSGiの実装に提供されている機能

- OSGiフレームワークの構成

- OSGiバンドルの作成

- OSGiバンドルのデプロイ

- JNDIからのデプロイされたバンドル・オブジェクトへのアクセス

- WebLogic Serverを経由したOSGiロギングの使用

- OSGiバンドル用のフィルタリング・クラスローダーの構成

- OSGIのサンプル

OSGiの理解

OSGiとは、OracleがメンバーとなっているOSGi Allianceによって開発および保守されているJavaモジュール方式システムです。

Javaアプリケーションの包括的な運用環境については、次のOSGiの仕様書と関連Javadocにまとめて説明されています。

- OSGiサービス・プラットフォーム・コア仕様は、http://www.osgi.org/Release4/Downloadからダウンロードできます。

- OSGi Javadocは、http://www.osgi.org/Release4/Javadocから入手できます。

OSGi Alliance Technology Webページ(http://www.osgi.org/About/Technology)には、次のように記載されています。「OSGiテクノロジは、Java向けの動的モジュール・システムです。OSGiサービス・プラットフォームは、Javaを、ソフトウェアの統合そして開発のための最適な環境に変える機能を提供します。Javaは、多種多様なプラットフォーム上の製品をサポートするために必要な移植性を提供します。OSGiテクノロジは、小規模で、再利用可能なコラボレイティブ・コンポーネントから各種のアプリケーションを構築できるようにする、標準化されたプリミティブを提供します。これらのコンポーネントは、1つのアプリケーションに構成してデプロイすることができます。」

OSGi Architecture Webページ(http://www.osgi.org/About/WhatIsOSGi)には、OSGiテクノロジについて次にようにさらに詳細に説明されています。「...Java用の動的コンポーネント・システムを定義する一連の仕様です。これらの仕様によって、アプリケーションが多種多様な(再利用可能な)コンポーネントから(動的に)構成される、開発モデルが使用可能になります。OSGiの仕様では、コンポーネントがその実装を他のコンポーネントから見えないようにすることでき、その一方で、複数のコンポーネント間で具体的に共有されるオブジェクトである各種サービスを使用して通信することが可能です。この驚くほど簡単なモデルは、ソフトウェア開発プロセスのほとんどあらゆる側面に広範な影響を及ぼします。」

「Benefits of Using OSG」(http://www.osgi.org/About/WhyOSGi)で説明されているように、OSGiはユーザーに次の利点をもたらします。

- インタフェースの実装者とユーザーのための、パッケージ・ワイヤリングのバージョニング。

- 「uses」ディレクティブは、クラス・ローダーのインテリジェント・ワイヤリングを可能にし、一貫性のあるクラス・スペースを確保するのに役立ちます。

- 柔軟かつ動的なセキュリティ。

- アクティブ・レジストリを介した動的なサービス・ワイヤリング。

- 複数のベンダーによって提供される各種の標準的なOSGiの仕様。

WebLogic Server OSGiの実装に提供されている機能

WebLogic Serverを使用すると、サーバー構成に、(OsgiFrameWorkMBean MBeansによって管理される)OSGiフレームワークのリストを追加することができます。OSGiフレームワークが起動されると、フレームワークに対するバンドル・オブジェクトが、ローカル・サーバーJNDIツリーに配置されます。その結果、アプリケーションはJNDIからこのバンドルを取得し、その後、それをOSGiシステムへのエントリ・ポイントとして使用することができます。

アプリケーションは、独自のOSGiバンドルをデプロイすることもできます。アプリケーション・クラスローダー階層の中では、選択したフレームワーク・インスタンスの特定の1つのOSGiバンドルを使用できます。

WebLogic Serverでは次の操作が可能です。

- Weblogic Server管理コンソールおよびWLSTからのOSGiフレームワークの1つ以上のインスタンスの構成および管理。
WebLogic Serverには、OSGiフレームワークのApache Felix実装が含まれます。Felixの詳細は、http://felix.apache.orgを参照してください。

- 独自のOSGiバンドルの作成およびデプロイ。
WebLogic Serverには、OSGi APIを格納するOSGiバンドルが含まれます。このAPIを使用して、独自のOSGiバンドルを作成することができます。

- アプリケーション・クラスローダー階層の中では、選択したフレームワーク・インスタンスの特定の1つのOSGiバンドルを使用できます。

- JNDIからのOSGiバンドルへの直接的なアクセス。

- OSGiバンドルのデプロイおよびアンデプロイ。

- WebLogic Serverロギング・メカニズムによるOSGiステータスの記録。

- ユーザーが選択したOSGiサービスの組込み。

- OSGiの永続性の有効化。

- デプロイされたバンドルに対するOSGiバンドル開始レベルの管理。

これらのトピックについては、この後の項で説明します。

OSGiフレームワークの構成

OSGiサービス・プラットフォーム・コア仕様では、次のように説明されています。「このフレームワークは、OSGiサービス・プラットフォーム仕様の中核を成しており、バンドルと呼ばれる拡張およびダウンロードが可能なアプリケーションのデプロイメントをサポートする、セキュアで管理された汎用のJavaフレームワークを提供します。」

WebLogic Serverには、OSGiフレームワークのFelix実装が含まれます。Felix OSGiフレームワークの1つ以上のインスタンスを構成および管理できます。

注意:

WebLogic Serverは、Felixフレームワークのみをサポートしています。その他のOSGiフレームワークはサポートされておらず、テストされていません。

この項では、次の内容について説明します。

- OSGiフレームワーク・インスタンスの構成

- OSGiフレームワーク永続性の構成

OSGiフレームワーク・インスタンスの構成

OSGiフレームワークは、デフォルトでWebLogic Serverに含まれていますが、自動的には起動されません。

WebLogic Serverの起動時にOSGiフレームワークを起動するように、WebLogic Serverを構成する必要があります。これは、好みに応じて、次の4つの方法で行うことができます。

- WebLogic Server管理コンソールを使用して、OSGiフレームワーク・インスタンスを構成します。

- DOMAIN_HOME\config\config.xmlデプロイメント記述子ファイルを編集することで、OSGiサーバーのエントリを追加して、属性値を設定します。WebLogic Serverインスタンスで使用するOSGiフレームワークを指定します。

- WLSTを使用して、OSGiフレームワークを作成し、属性値を設定します。この場合、WLSTではDOMAIN_HOME\config\config.xmlデプロイメント記述子ファイルに値を格納します。

- Javaプログラムを記述して、OSGiフレームワークを作成し、属性値を設定します。

4つのすべてのケースにおいて、OSGiフレームワーク・インスタンスの構成は、OsgiFrameWorkMBeanによって制御されます。OsgiFrameWorkMBeanに関連付けられたフレームワークごとに、WebLogic Serverが一意の名前を使用してOSGiフレームワークを起動します。

表17-1に示すように、OSGiフレームワーク属性を構成します。

表17-1 OSGiフレームワーク属性

属性

使用方法

Target

この属性は必須です。このアイテムをデプロイできる現在のドメインにあるサーバーまたはクラスタのリストから、MBeanをデプロイするターゲット(サーバーまたはクラスタ)を選択する必要があります。

名前

フレームワーク・インスタンスの名前。指定されたフレームワーク・インスタンスの名前は、WebLogic Serverサーバー・インスタンス内で一意である必要があります。

Implementation Class

org.osgi.framework.launch.FrameworkFactoryクラスに対するフレームワーク実装クラスの名前。デフォルト値はorg.apache.felix.framework.FrameworkFactoryです。

Deploy Installation Bundles

OSGiバンドルをフレームワークにインストールするかどうかを決定します。この属性は、デフォルトでは「populate」です。詳細は、「フレームワークにバンドルをインストールする際に必要なパラメータ」を参照してください。

Dynamically Created

MBeanを動的に作成するか、config.xmlに対して永続化するかどうかを決定します。この構成は、Weblogic Server管理コンソールを使用しており、この属性が表示されない場合に、常に永続化されます。

Init Properties

フレームワークを初期化するときに使用する標準のFelixプロパティ。標準のすべてのプロパティおよびフレームワークに固有のすべてのプロパティを設定できます。

Javaプログラムからの初期プロパティの設定の例については、例17-3を参照してください。

Apache Felixフレームワークの構成プロパティについては、http://felix.apache.org/site/apache-felix-framework-configuration-properties.htmlに説明されています。

Framework Boot delegation

org.osgi.framework.bootdelegationプロパティの名前。この値は(設定されている場合)、初期プロパティに指定されている値よりも優先されることに注意してください。

Framework System Packages Extra

org.osgi.framework.system.packages.extraプロパティの名前。この値は(設定されている場合)、初期プロパティに指定されている値よりも優先されることに注意してください。

Register Global Data Sources

ブール値。グローバル・データ・ソースをOSGiサービス・レジストリに追加する場合に、trueを返します。

Register Global Work Managers

ブール値。グローバル・ワーク・マネージャをOSGiサービス・レジストリに追加する場合に、trueを返します。

管理コンソールからのOSGiフレームワーク・インスタンスの構成

Weblogic Server管理コンソールからOSGiフレームワークを構成することができます。次のステップを実行します:

1. WebLogic Server管理コンソールの左パネルで、「サービス」を展開します。

2. 左パネルで、「OSGiフレームワーク」をクリックします。

3. 「OSGiフレームワークのサマリー」ページで、「新規」をクリックします。

OSGiフレームワークをすでに作成してある場合は、かわりに「クローンの作成」をクリックして、既存のフレームワークを新しいフレームワークの基準として使用することもできます。

4. 「新しいOSGiフレームワークを作成」ページで、このフレームワーク・インスタンスの名前を付けます。この名前は一意である必要があります。

5. 「次」をクリックします。

6. 「OSGiフレームワーク・ターゲット」ページで、このOSGiフレームワークをデプロイするサーバーまたはクラスタを選択します。

7. 「終了」をクリックします。

8. 「OSGiフレームワークのサマリー」ページで、作成したフレームワークを選択します。

9. 「フレームワークの設定」ページで、デフォルト値を調べて、それらが環境にとって適切であることを確認します。属性の説明は、表17-1を参照してください。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOSGiフレームワークの構成に関する項を参照してください。

config.xmlからのOSGiフレームワーク・インスタンスの構成

例17-1は、WebLogic Serverで使用するOSGiフレームワークを追加するようにconfig.xmlを更新する例を示しています。</domain>要素の直前に<osgi-framework>要素を追加します。

複数のOSGiフレームワーク・インスタンスを追加する必要がある場合は、複数の<osgi-framework>要素を追加します。各<name>要素はサーバー内で一意である必要があることを忘れないでください。

この要素を追加した後、WebLogic Serverインスタンスを再起動する必要があります。

例17-1 config.xmlからのOSGiフレームワーク・インスタンスの構成

<osgi-framework>
<name>test-osgi-frame</name>
<target>AdminServer</target>
</osgi-framework>

WLSTからのOSGiフレームワーク・インスタンスの構成

例17-2は、WLSTを使用してWebLogic Serverインスタンスで使用するOSGiフレームワークを追加する例を示しています。

例17-2 WLSTからのOSGiフレームワーク・インスタンスの構成

java weblogic.WLST

connect('weblogic', 'password')
edit()
startEdit()
wls:/mydomain/edit !> cmo.createOsgiFramework('test-osgi-frame')
[MBeanServerInvocationHandler]com.bea:Name=test-osgi-frame,Type=OsgiFramework
targetServer=cmo.lookupServer('AdminServer')
cd('OsgiFrameworks')
cd('test-osgi-frame')
cmo.addTarget(targetServer)
wls:/mydomain/edit !> save()
wls:/mydomain/edit !> activate()
wls:/mydomain/edit/OsgiFrameworks> ls('a')
drw-   test-osgi-frame
wls:/mydomain/edit/OsgiFrameworks> cd('test-osgi-frame')
wls:/mydomain/edit/OsgiFrameworks/test-osgi-frame> ls('a')
-rw-   DeployInstallationBundles                    populate
-rw-   DeploymentOrder                              1000
-r--   DynamicallyCreated                           false
-rw-   FactoryImplementationClass                   org.apache.felix.framework.F
rameworkFactory
-r--   Id                                           0
-rw-   InitProperties                               null
-rw-   Name                                         test-osgi-frame
-rw-   Notes                                        null
-rw-   OrgOsgiFrameworkBootdelegation               null
-rw-   OrgOsgiFrameworkSystemPackagesExtra          null
-rw-   RegisterGlobalDataSources                    true
-rw-   RegisterGlobalWorkManagers                   true
-r--   Type                                         OsgiFramework

JavaプログラムからのOSGiフレームワーク・インスタンスの構成

例17-3は、Javaプログラムを使用してWebLogic Serverインスタンスで使用するOSGiフレームワークを追加する例を示しています。各操作については、コード内のコメントで説明されています。

例17-3 JavaプログラムからのOSGiフレームワークの構成

/**...imports omitted
*/
/**
* Create an OSGi framework instance with the designated name
*
* @param frameworkName
*/
protected void createOSGiFrameworkInstance(String frameworkName) {
createOSGiFrameworkInstance(frameworkName, null, null, null, null, null);
}

protected void createOSGiFrameworkInstance(String frameworkName,
String isRegisterGlobalWorkManagers,
String isRegisterGlobalDataSources,
String deployInstallationBundles,
String orgOsgiFrameworkBootdelegation,
String orgOsgiFrameworkSystemPackagesExtra) {
createOSGiFrameworkInstance(frameworkName,
null,
isRegisterGlobalWorkManagers,
isRegisterGlobalDataSources,
deployInstallationBundles,
orgOsgiFrameworkBootdelegation,
orgOsgiFrameworkSystemPackagesExtra);
}

/**
* Create a fresh framework
*
* @param isRegisterGlobalWorkManagers
* @param isRegisterGlobalDataSources
* @param deployInstallationBundles
* @param orgOsgiFrameworkBootdelegation
* @param orgOsgiFrameworkSystemPackagesExtra
*/
protected void createOSGiFrameworkInstance(String frameworkName,
Properties initProp,
String isRegisterGlobalWorkManagers,
String isRegisterGlobalDataSources,
String deployInstallationBundles,
String orgOsgiFrameworkBootdelegation,
String orgOsgiFrameworkSystemPackagesExtra) {

frameworkInstances.add(frameworkName);

if (initProp == null) {
initProp = new Properties();
}
initProp.setProperty("wlstest.framework.instance.name", frameworkName);
//initProp.setProperty("felix.cache.locking", "false");
//initProp.setProperty("org.osgi.framework.storage.clean", "onFirstInit");

MBeanServerConnection connection = null;

try {

// Initiate the necessary MBean facilities.
connection = initConnection();
// Switch the edit session on.
ObjectName domainMBean = startEditSession(connection);

// Get the current WebLogic server MBean:
ObjectName serverMBean = null;
ObjectName[] serverMBeans = (ObjectName[]) connection.getAttribute(domainMBean, "Servers");
for (ObjectName objectName : serverMBeans) {
log("found server: " + objectName);
serverMBean = objectName;
}

// Get or create an OsgiFrameworkMBean:
ObjectName osgiFrameworkMBean = null;
ObjectName[] osgiFrameworkMBeans = (ObjectName[]) connection.getAttribute(domainMBean, "OsgiFrameworks");
log("osgiFrameworkMBeans.length=" + osgiFrameworkMBeans.length);
for (ObjectName objectName : osgiFrameworkMBeans) {
String osgiFrameworkName = (String) connection.getAttribute(objectName, "Name");
log("--------------> " + osgiFrameworkName);
if (osgiFrameworkName.equals(frameworkName)) {
osgiFrameworkMBean = objectName;
log("Found OSGi framework instance: " + frameworkName);
break;
}
}

if (osgiFrameworkMBean != null) {
log("Will destroy the framework instance: " + osgiFrameworkMBean);
connection.invoke(osgiFrameworkMBean,
"removeTarget",
new Object[] { serverMBean },
new String[] { "javax.management.ObjectName" });
connection.invoke(domainMBean,
"destroyOsgiFramework",
new Object[] { osgiFrameworkMBean },
new String[] { "javax.management.ObjectName" });
}

log("Will create a new framework instance from scratch");
osgiFrameworkMBean = (ObjectName) connection.invoke(domainMBean,
"createOsgiFramework",
new Object[] { frameworkName },
new String[] { "java.lang.String" });

// Set common properties:
if (initProp != null) {
Attribute initPropAttr = new Attribute("InitProperties", initProp);
connection.setAttribute(osgiFrameworkMBean, initPropAttr);
}
Attribute systemPackagesExtraAttr = new Attribute("OrgOsgiFrameworkSystemPackagesExtra",
"javax.naming,weblogic.work,javax.sql");
connection.setAttribute(osgiFrameworkMBean, systemPackagesExtraAttr);
connection.invoke(osgiFrameworkMBean,
"addTarget",
new Object[] { serverMBean },
new String[] { "javax.management.ObjectName" });

// Set individual property to the OSGi framework instance:
if (isRegisterGlobalWorkManagers != null) {
Attribute attr = new Attribute("RegisterGlobalWorkManagers", Boolean.parseBoolean(isRegisterGlobalWorkManagers));
connection.setAttribute(osgiFrameworkMBean, attr);
}

if (isRegisterGlobalDataSources != null) {
Attribute attr = new Attribute("RegisterGlobalDataSources", Boolean.parseBoolean(isRegisterGlobalDataSources));
connection.setAttribute(osgiFrameworkMBean, attr);
}

if (deployInstallationBundles != null) {
Attribute attr = new Attribute("DeployInstallationBundles", deployInstallationBundles);
connection.setAttribute(osgiFrameworkMBean, attr);
}

if (orgOsgiFrameworkBootdelegation != null) {
Attribute attr = new Attribute("OrgOsgiFrameworkBootdelegation", orgOsgiFrameworkBootdelegation);
connection.setAttribute(osgiFrameworkMBean, attr);
}

if (orgOsgiFrameworkSystemPackagesExtra != null) {
Attribute attr = new Attribute("OrgOsgiFrameworkSystemPackagesExtra", orgOsgiFrameworkSystemPackagesExtra);
connection.setAttribute(osgiFrameworkMBean, attr);
}

MBeanInfo mi = connection.getMBeanInfo(osgiFrameworkMBean);
log("Attributes are as below:");
for (MBeanAttributeInfo mai : mi.getAttributes()) {
Object value = connection.getAttribute(osgiFrameworkMBean, mai.getName());
System.out.printf("    %-40s = %s\n", mai.getName(), value);
}

// Save your changes
ObjectName cfgMgr = (ObjectName) connection.getAttribute(service, "ConfigurationManager");
connection.invoke(cfgMgr, "save", null, null);

フレームワークにバンドルをインストールする際に必要なパラメータ

OsgiFrameWorkMBean MBeanのDeploy Installation Bundles属性は、osgi-libディレクトリ(この章の後半の「OSGiバンドルのosgi-libディレクトリへのデプロイ」で説明)に存在するバンドルをフレームワークに実際にインストールするかどうかを制御します。

Deploy Installation Bundlesパラメータには、次の値を指定できます。

- ignore — このディレクトリ内のいずれのバンドルも、インストールおよび起動されません。

- populate — 可能な場合は、バンドルがインストールおよび起動されます。これがデフォルトです。さらに、osgi-libディレクトリ内のバンドルを使用可能にするために、ブート委任クラスパス・パラメータに別のパッケージをいくつか追加します(まだそこに存在しない場合)。
これらのバンドルが適切に解決されておらずそのために起動できない場合には、システムが起動しない原因としてなんらかの障害が発生したとは見なされません。

OSGiフレームワーク永続性の構成

OSGiには、永続性メカニズムがあります(http://www.osgi.org/javadoc/r4v43/org/osgi/framework/launch/Framework.htmlで説明)。この永続性メカニズムでは、インストールされているすべてのバンドルが、各バンドルの永続性自動起動設定に従って起動されます。

この永続性メカニズムは、デフォルトでは無効になっています。ただし、表17-1に示されている標準のFelix初期プロパティを使用して、OSGi永続性メカニズムを有効にすることができます。

注意: WebLogic Serverは、OSGi永続性メカニズムに直接は関与していません。特に、WebLogic Serverは他のサーバーにデータをフェイルオーバーしません。

OSGiサービスの使用

標準のOSGiサービスをOSGiバンドルで使用できるようにすることができます。このためには、Felixフレームワークに対する正しいパッケージをインポートして、アプリケーション・バンドルが必要な認可を持っていることを確認します。

これらのサービスについては、OSGiサービス・プラットフォーム・コア仕様(http://www.osgi.org/Download/File?url=/download/r4v43/r4.core.pdf)に説明されています。サービスの例として、標準のフレームワーク供給サービス(Package Admin Service、Conditional Permission Admin Service、StartLevel Serviceなど)があげられます。

OSGiサービス・イベントをリスニングする簡単なバンドルを作成する例については、「Apache Felix Tutorial Example 1, Service Event Listener Bundle」を参照してください。

OSGiバンドルの作成

独自のOSGIバンドルを作成するには、OSGi APIバンドル(WebLogic Serverに付属)を使用します。

簡単なバンドルを作成する例については、「Apache Felix Tutorial Example 1, Service Event Listener Bundle」を参照してください。この例で説明されているように、マニフェスト・ファイルのImport-Package属性は、外部パッケージに対するバンドルの依存関係を、フレームワークに通知します。アクティベータを含むすべてのバンドルは、org.osgi.frameworkをインポートする必要があります。アクティベータには、コアOSGiクラス定義が含まれているからです。

OSGiバンドルのデプロイ

この項では、次の内容について説明します。

- ターゲット・システムにOSGiバンドルをデプロイする準備

- osgi-libディレクトリへのOSGiバンドルのデプロイ

ターゲット・システムにOSGiバンドルをデプロイする準備

アプリケーションに適切なものとして、JAR、EARまたはWARファイル内からOSGiバンドルをデプロイすることができます。

これを実行する前に、まず、バンドルで使用するOSGiフレームワークを指定して、WebLogic Serverに対するバンドルを特定する必要があります。

注意:

指定したOSGiフレームワーク・インスタンスがターゲット・サーバー上に存在しない場合、OSGiバンドルのデプロイは失敗します。

これを行う方法は、バンドルがWARファイル内とEARファイル内のどちらにあるかに依存します。

- WAR — フレームワーク・インスタンスとバンドル名が、Webアプリケーションのweblogic.xmlデプロイメント記述子ファイルの要素内にある必要があります。

- EAR — フレームワーク・インスタンスとバンドル名が、アプリケーションのweblogic-application.xmlデプロイメント記述子ファイルの要素内にある必要があります。
EARファイルにWARファイルが含まれている場合、埋め込まれたWARファイルからweblogic.xmlデプロイメント記述子ファイルを使用して、WARファイル内のバンドルをデプロイします。

次の項では、必要な手順について詳しく説明します。

WebLogic Serverデプロイメント記述子の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

エンタープライズ・アプリケーションとしてバンドルをデプロイする準備

OSGiバンドルをデプロイする前に、まず次のことを実行する必要があります。

1. 「OSGiフレームワーク・インスタンスの構成」で説明されているように、DOMAIN_HOME\config\config.xmlデプロイメント記述子ファイルまたはWLSTを使用して、OSGiフレームワークのエントリを追加します。

2. OSGiバンドルを含むEARファイルで、weblogic-application.xmlデプロイメント記述子ファイルに、OSGiフレームワークの名前とバンドル自体の名前の両方を追加します。

例17-1は、WebLogic Serverで使用するOSGiフレームワークを追加するようにconfig.xmlを更新する例を示しています。

例17-4は、OSGiフレームワークの名前およびバンドルの名前と場所の両方を追加するようにweblogic-application.xmlを更新する例を示しています。

例17-4 weblogic-application.xmlへのフレームワークとバンドルの追加

<osgi-framework-reference>
<name>test-osgi-frame</name>
<application-bundle-symbolic-name>com.oracle.weblogic.test.client
</application-bundle-symbolic-name>
<bundles-directory>rashi/osgi-lib</bundles-directory>
</osgi-framework-reference>

例17-4のスタンザは、「test-osgi-frame」という名前のOSGiフレームワークにアタッチすること、およびそのOSGiフレームワークからクラスを検索するためにそのサーバーでcom.oracle.weblogic.test.clientというシンボリック名を持つバンドルを検索することを、WebLogic Serverに伝えます。

Webアプリケーションとしてバンドルをデプロイする準備

WARファイルとしてバンドルをインストールする前に、まず次のことを実行する必要があります。

1. 「OSGiフレームワーク・インスタンスの構成」で説明されているように、DOMAIN_HOME\config\config.xmlデプロイメント記述子ファイルまたはWLSTを使用して、OSGiフレームワークのエントリを追加します。

2. webアプリケーションのweblogic.xmlデプロイメント記述子ファイルに、OSGiフレームワークの名前とバンドル自体の名前の両方を追加します。

例17-1は、WebLogic Serverで使用するOSGiフレームワークを追加するようにconfig.xmlを更新する例を示しています。

例17-5は、OSGiフレームワークの名前およびバンドルの名前と場所の両方を追加するようにweblogic.xmlを更新する例を示しています。

例17-5 weblogic.xmlへのフレームワークとバンドルの追加

<osgi-framework-reference>
<name>test-osgi-frame</name>
<application-bundle-symbolic-name>com.oracle.weblogic.test.client
</application-bundle-symbolic-name>
<bundles-directory>rashi/osgi-lib</bundles-directory>
</osgi-framework-reference>

例17-4のスタンザは、「test-osgi-frame」という名前のOSGiフレームワークにアタッチすること、およびそのOSGiフレームワークからクラスを検索するためにそのサーバーでcom.oracle.weblogic.test.clientというシンボリック名を持つバンドルを検索することを、WebLogic Serverに伝えます。

グローバル・ワーク・マネージャ

ワーク・マネージャでは、定義したルールに基づいて、さらには実際の実行時パフォーマンスの統計をモニターすることによって、作業の優先順位を決められます。こうした情報は、後にアプリケーションのパフォーマンスを最適化するためにも使用されます。『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。

表17-1で説明されているように、Register Global Work Managers MBean属性がtrueに設定されている場合、OSGi実装はグローバル・ワーク・マネージャを利用することができます。

例17-7に示すように、Javaアプリケーションから使用中のグローバル・ワーク・マネージャを決定することができます。

例17-6 グローバル・ワーク・マネージャの決定

// Get the global scoped work manager service:
ServiceReference[] refWmSvcs = bc.getServiceReferences(WorkManager.class.getCanonicalName(),
"(name=GlobalScopedWorkManager)");
if (refWmSvcs != null) {
logger.setAttribute(frameworkInstanceName, bundleIdentifier + "_WorkManager_Count", refWmSvcs.length);
for (int i = 0; i < refWmSvcs.length; i++) {
ServiceReference refWmSvc = refWmSvcs[i];
WorkManager wm = (WorkManager) bc.getService(refWmSvc);
logger.setAttribute(frameworkInstanceName, bundleIdentifier + "_WorkManager" + (i + 1), wm.getName());
bc.ungetService(refWmSvc);
}
}

グローバル・データ・ソース

『Oracle WebLogic Serverの理解』のWebLogic Serverデータ・ソースに関する項で説明されているように、WebLogic Serverでデータベース接続を構成するには、JDBCデータ・ソースとマルチ・データ・ソースを構成し、次にWebLogicドメインのサーバーまたはクラスタに対してJDBCリソースをターゲット化またはデプロイします。

表17-1で説明されているように、Register Global Data Sources MBean属性がtrueに設定されている場合、OSGi実装はグローバル・データ・ソースを利用することができます。

例17-7に示すように、Javaアプリケーションから使用中のグローバル・データ・ソースを決定することができます。

例17-7 グローバル・データ・ソースの決定

// Get the global data source services:
ServiceReference[] refDsSvcs = bc.getServiceReferences(DataSource.class.getCanonicalName(), "(name=OsgiDS)");
if (refDsSvcs != null) {
logger.setAttribute(frameworkInstanceName, bundleIdentifier + "_DataSource_Count", refDsSvcs.length);
for (int i = 0; i < refDsSvcs.length; i++) {
String data = null;
ServiceReference refDsSvc = refDsSvcs[i];
DataSource ds = (DataSource) bc.getService(refDsSvc);
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
conn = ds.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("select * from dual");
rs.next();
data = rs.getString(0);
} catch (SQLException e) {

osgi-libディレクトリへのOSGiバンドルのデプロイ

注意:

「フレームワークにバンドルをインストールする際に必要なパラメータ」で説明されているように、OsgiFrameWorkMBean MBeanのDeploy Installation Bundles属性は、osgi-libディレクトリに存在するバンドルを実際にインストールするかどうかを制御します。この属性はデフォルトでtrueになっており、バンドルがインストールされます。

1の起動レベルでバンドルをデプロイするには、WL_HOME/server/osgi-libディレクトリを作成し(まだ存在しない場合)、次にそのディレクトリにアーカイブ・ファイル(EAR、WAR)ファイルをコピーします。

このディレクトリ内の、.jar、.earまたは.warが最後に付いているファイルはすべて、起動時にフレームワークにインストールされるOSGiバンドルと見なされます。

WL_HOME/server/osgi-libは、サーバーを初めて起動するときにのみ参照され、それ以降に行われる変更については監視されません。新しいOSGiバンドルを、WL_HOME/server/osgi-libディレクトリに追加して、デプロイする場合は、WebLogic Serverを再起動する必要があります。

バンドルに対する起動レベルと実行レベルの設定

1の起動レベルでバンドルをデプロイするには、アーカイブ・ファイル(EAR、WAR)ファイルを、WL_HOME/server/osgi-libディレクトリにコピーします。

また、WL_HOME/server/osgi-libディレクトリは、サブディレクトリに基づいた起動レベルおよび実行レベルのスキームもサポートしています。

1から32Kの間の数値(2、3、4など)で始まる名前を持つサブディレクトリを作成した場合、これらのディレクトリの下のアーカイブ・ファイルがインストールされ、指定された実行レベルで起動されます。

JNDIからのデプロイされたバンドル・オブジェクトへのアクセス

OSGiサーバーが起動されると、バンドル・オブジェクトが、ローカル・サーバーJNDIツリーに配置されます。その結果、アプリケーションはJNDIからこのバンドルを取得し、その後、それをOSGiシステムへのエントリ・ポイントとして使用することができます。

org.osgi.framework.Bundleは、アプリケーションのjava:app/osgi/Bundle JNDI環境に配置されます。

アプリケーション・クラスローダー階層の中では、選択したフレームワーク・インスタンスの特定の1つのOSGiバンドルを使用できます。

例17-8は、JNDIから作成するバンドルにアクセスする方法を示しています。

例17-8 JNDIからのOSGiバンドルへのアクセス

public static final String BUNDLE_JNDI_NAME = "java:app/osgi/Bundle";
...
String bundleSymbolicName = null;

Bundle bundle = null;
OsgiInfo info = new OsgiInfo();
List<String> errorMessages = new ArrayList<String>();

try {
Context initCtx = new InitialContext();
bundle = (Bundle) initCtx.lookup(Constants.BUNDLE_JNDI_NAME);
} catch (NamingException e) {
errorMessages.add(e.toString());
System.out.println("Failed to lookup bundle from JNDI due to " + e);
}

if (bundle != null) {

bundleSymbolicName = bundle.getSymbolicName() + "_" + bundle.getVersion();
info.setCurrentBundle(bundleSymbolicName);

BundleContext bc = bundle.getBundleContext();

if (bc != null) {

// Get the start level service:
StartLevel startLevelSvc = null;
ServiceReference startLevelSr = bc.getServiceReference("org.osgi.service.startlevel.StartLevel");
if (startLevelSr != null) {
startLevelSvc = (StartLevel) bc.getService(startLevelSr);
}

List<String> allInstalledBundles = new ArrayList<String>();
List<String> allActivatedBundles = new ArrayList<String>();
Map<String, List<String>> services = new HashMap<String, List<String>>();
Map<String, String> startLevels = new HashMap<String, String>();

for (Bundle b : bc.getBundles()) {

// Collect all the installed and activated bundles:
String bundleId = b.getSymbolicName() + "_" + b.getVersion();
allInstalledBundles.add(bundleId);
if (b.getState() == Bundle.ACTIVE) {
allActivatedBundles.add(bundleId);
}

// Collect the registered services:
ServiceReference[] srs = b.getRegisteredServices();
if (srs != null) {
List<String> list = new ArrayList<String>();
for (ServiceReference sr : srs) {
list.add(sr + "-->" + bc.getService(sr));
}
services.put(bundleId, list);
}

// Collect the start levels:
if (startLevelSvc != null) {
startLevels.put(bundleId, startLevelSvc.getBundleStartLevel(b) + "");
}
}

info.setAllInstalledBundles(allInstalledBundles);
info.setAllActivatedBundles(allActivatedBundles);
info.setRegisteredServices(services);
info.setStartLevels(startLevels);

// Query the work manager services:
List<String> workManagers = new ArrayList<String>();
try {
ServiceReference[] wmSrs = bc.getServiceReferences(WorkManager.class.getCanonicalName(), null);
if (wmSrs != null) {
for (ServiceReference sr : wmSrs) {
WorkManager wm = (WorkManager) bc.getService(sr);
workManagers.add(wm.getName());
}
}
} catch (InvalidSyntaxException e) {
e.printStackTrace(System.out);
}
info.setWorkManagers(workManagers);

// Query the data source services:
List<String> dataSources = new ArrayList<String>();
try {
ServiceReference[] dsSrs = bc.getServiceReferences(DataSource.class.getCanonicalName(), null);
if (dsSrs != null) {
for (ServiceReference sr : dsSrs) {
dataSources.add(sr.getProperty("name").toString());
}
}
} catch (InvalidSyntaxException e) {
e.printStackTrace(System.out);
}
info.setDataSources(dataSources);

}
}

String bundleFileName = null;
try {
BundleIntrospect introspection = new BundleIntrospect();
bundleFileName = introspection.whichBundleFile();
info.setCurrentBundleFileName(bundleFileName);
} catch (Throwable e) {
errorMessages.add(e.toString());
//e.printStackTrace(System.out);
}
info.setErrorMessages(errorMessages);

return info;

}

}

WebLogic Serverを経由したOSGiロギングの使用

OSGiログ・サービス, バージョン1.0.0のApache Felix実装は、デフォルトでは、インストール・ディレクトリWL_HOME/server/osgi-libにインストールされます。

WL_HOME/server/osgi-libには、OSGiバンドルcom.oracle.weblogic.osgi.logger_1.0.0.jarもインストールされます。このバンドルはOSGiロギング・サービスに登録され、OSGiロガーからWebLogic Serverロガーにログを送信します。

ロガーのシステム名は、OSGiForAppsです。表17-2に示すように、OSGiとWebLogic Serverの間でメッセージの重大度レベルがマッピングされます。

表17-2 OSGiとWebLogic Serverロギングの重大度マッピング

OSGiの重大度レベル

WebLogic Serverの重大度レベル

LogLevel.LOG_ERROR

Severities.ERROR

LogLevel.LOG_WARNING

Severities.WARNING

LogLevel.LOG_INFO

Severities.INFO

LogLevel.LOG_DEBUG

Severities.DEBUG

OSGiバンドル用のフィルタリング・クラスローダーの構成

フィルタリング・クラスローダーを使用すると、OSGiバンドルとしてデプロイされる代替ライブラリ・バージョンの使用を指定することができます。

FilteringClassLoaderを構成して、特定のパッケージがアプリケーションからロードされることを指定するには、アプリケーションからロードされるパッケージのリストを記述しているweblogic-application.xmlに、prefer-application-packages記述子要素を追加します。次の例は、org.apache.log4j.*パッケージとantlr.*パッケージがシステム・クラスローダーではなくアプリケーションからロードされることを示します。

<prefer-application-packages>
<package-name>org.apache.log4j.*</package-name>
<package-name>antlr.*</package-name>
</prefer-application-packages>

パッケージがOSGiバンドルである場合、WEB-INF/libまたはWEB-INF/osgi-libにパッケージを配置します。WEB-INF/osgi-libに直接OSGiバンドルの依存関係を追加するか、またはOSGiフレームワーク・インスタンスでorg.osgi.framework.system.packages.extraプロパティ(表17-1を参照)を構成して、アプリケーションが必要とする必須のjavaxパッケージをエクスポートすることができます。

フィルタリング・クラスローダーの詳細は、「フィルタリング・クラスローダーの使用」を参照してください。

OSGIのサンプル

WebLogic Serverには、OSGiバンドルをWebLogic Serverにデプロイする方法を実証するサンプルが含まれています。WebLogic Serverのサンプルをインストールした場合、OSGiのサンプル・ソース・コードは、ORACLE_HOMEwl_server/examples/src/examples/osgi/osgiAppにあります。ここで、ORACLE_HOMEは、WebLogic Serverのコード・サンプルを構成するディレクトリを示します。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

2つの簡単なバンドル(クライアントとサーバー)があります。サーバー・バンドル(ServerBundle)は、クライアント・バンドル(ClientBundle)がインポートするパケットをエクスポートします。

このサンプルは、デプロイされたOSGiバンドルを表示するHTMLページを生成します。

18 WebLogic ServerでのWebSocketプロトコルの使用方法

WebLogic Server では、WebSocketプロトコル(RFC 6455)をサポートします。これは、TCPプロトコル経由で、2つのピア間の全二重通信を可能にします。WebLogic ServerにはWebSocketプロトコルとそれに付随するAPIが実装されているので、クライアントと双方向通信するアプリケーションを開発およびデプロイすることができます。いかなる種類のクライアント/サーバー通信にもWebSocketプロトコルを使用できますが、World Wide Web Consortium (W3C) JavaScript WebSocket APIを使用するWebページを実行するブラウザとの通信には、この実装が最もよく使用されます。WebLogic ServerにWebSocketプロトコルを実装することにより、Javaクライアントもサポートされます。

この章の内容は次のとおりです。

- WebSocketプロトコルの理解

- WebLogic ServerのWebSocketの実装の理解

- WebSocketアプリケーションの作成の概要

- エンドポイントの作成

- WebSocket接続のライフサイクル・イベントの処理

- WebSocketエンドポイントでのリソースの定義、注入およびアクセス

- メッセージの送信

- WebSocketメッセージのエンコーディングとデコーディング

- エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する方法

- クライアントの状態の管理

- サーバー・エンドポイントのプログラムによる構成

- Java API for WebSocketを使用するアプリケーションの構築

- WebSocketアプリケーションのデプロイ

- プロキシ・サーバーでのWebSocketの使用

- WebSocketクライアントの記述

- WebSocketアプリケーションの保護

- WebSocketメッセージングのプロトコル・フォールバックの有効化

- 非推奨のAPIからJSR 356 Java API for WebSocketへのアプリケーションの移行

- WebLogic ServerでのJava API for WebSocketの使用例

WebSocketプロトコルの理解

WebSocketとは、単一のTCP接続を介したクライアントとサーバー間の双方向同時通信を可能にするアプリケーション・プロトコルです。WebSocketプロトコルを使用すると、クライアントとサーバーはそれぞれ独立してデータを送信できます。HTML5仕様(http://www.w3.org/TR/html5/)の一部として、WebSocketプロトコルは、ほとんどのブラウザによってサポートされています。WebSocketプロトコルをサポートしているブラウザには、エンドポイントへの接続、メッセージの送信、およびWebSocketイベント(接続を開く、メッセージを受信、接続を閉じるなど)へのコールバック・メソッドの割当てを行うJavaScript APIが搭載されています。

WebSocketプロトコルの全般的な情報については、http://tools.ietf.org/html/rfc6455を参照してください。

HTTPリクエスト/レスポンス・モデルの限界

HTTPで使用されている従来のリクエスト/レスポンス・モデルでは、クライアントがリソースをリクエストし、サーバーがレスポンスを返します。このやり取りは常にクライアントによって開始されるので、クライアントが先にリクエストを出さなければ、サーバーはデータを送信できません。このモデルは、変更頻度の低いドキュメントをクライアントが時々リクエストするような場合にWorld Wide Webで問題なく機能しましたが、コンテンツの更新が頻繁で、よりインタラクティブなWebエクスペリエンスが求められるようになるにしたがって、このアプローチの限界が次第に明らかになってきました。WebSocketプロトコルは、クライアントとサーバー間に全二重通信チャネルを提供することで、このような限界に取り組みます。WebSocketは、他のクライアント・テクノロジ(JavaScriptやHTML5など)と組み合せて、Webアプリケーションのユーザー・エクスペリエンスをより豊かにすることができます。

WebSocketエンドポイント

WebSocketアプリケーションでは、サーバーがWebSocketエンドポイントをパブリッシュし、クライアントがそのエンドポイントのURIを使用してサーバーに接続します。

WebSocketエンドポイントは、次に示すいずれかの形式のURIで表現されます。

ws://host:port/path?query
wss://host:port/path?query

wsスキームは、暗号化されていないWebSocket接続を表します。

wssスキームは、暗号化されたWebSocket接続を表します。

これらの形式の残りの構成要素を次に示します。

host

[RFC3986]の3.2.2項で定義されているホスト。

port

オプション。[RFC3986]の3.2.3項で定義されているポート。デフォルトのポート番号は、80 (非暗号化接続の場合)および443 (暗号化接続の場合)です。

path

[RFC3986]の3.3項で定義されているパス。WebSocketエンドポイントのパスは、サーバー内のエンドポイントの場所を示します。

query

オプション。[RFC3986]の3.4項で定義されている問合せ。

WebSocketプロトコルのハンドシェイク・リクエスト

WebSocket接続を開始するために、クライアントはサーバーがパブリッシュしたWebSocketエンドポイントにハンドシェイク・リクエストを送信します。クライアントは、エンドポイントのURIを使用してエンドポイントの場所を指定します。ハンドシェイク・リクエストが検証に合格し、サーバーがリクエストを受け入れると、接続が確立されます。ハンドシェイクは既存のHTTPベースのインフラストラクチャと互換性があります。つまり、WebサーバーではハンドシェイクをHTTP接続のアップグレード・リクエストとして解釈します。

例18-1 WebSocketクライアントからのハンドシェイク・リクエスト

次の例は、クライアントからのハンドシェイク・リクエストを示しています。

GET /path/to/websocket/endpoint HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: http://localhost
Sec-WebSocket-Version: 13

例18-2 WebSocketクライアントからのハンドシェイク・リクエストに対するサーバー・レスポンス

次の例は、クライアントからのハンドシェイク・リクエストに対するサーバーからのハンドシェイク・レスポンスを示しています。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=

サーバーは、認識された操作をSec-WebSocket-Keyヘッダーの値に適用して、Sec-WebSocket-Acceptヘッダーの値を生成します。クライアントは、同じ操作をSec-WebSocket-Keyヘッダーの値に適用します。その結果がサーバーから受信した値と一致する場合、接続が正常に確立されます。ハンドシェイクに成功すると、クライアントとサーバーはメッセージを相互送信できます。

WebSocketプロトコルのメッセージングとデータ転送

接続が確立されると、WebSocketプロトコルは対称性を示します。つまり、クライアントとWebLogic Serverインスタンスは、接続が開いている間はいつでもメッセージを相互送信可能で、その接続をいつでも閉じることができます。通常、クライアントは1つのサーバーとのみ接続しますが、サーバーは複数のクライアントから接続を受け入れます。

WebSocketは、テキスト・メッセージ(UTF-8でエンコードされたもの)とバイナリ・メッセージをサポートします。WebSocketの制御フレームは、close、pingおよびpong (pingフレームへのレスポンス)です。pingフレームとpongフレームには、アプリケーション・データが含まれている場合もあります。

WebLogic ServerのWebSocketの実装の理解

WebLogic ServerのWebSocketの実装では、JSR 356 Java API for Websocketがサポートされます。Java API for WebSocketの詳細は、JSR 356の仕様を参照してください。

http://www.jcp.org/en/jsr/detail?id=356

注意:

リリース12.1.2で導入された固有のWebLogic Server WebSocket APIは非推奨になりましたが、下位互換性のために引き続きサポートされます。

JSR 356 Java API for WebSocketは固有のWebLogic Server WebSocket APIと共存できますが、アプリケーションに両方のAPIに対するコールを含めることはできません。アプリケーションで使用できるのは、一方のAPIのみです。

非推奨になったAPIの使用方法の詳細は、Oracle WebLogic Server 12c (12.1.2)のドキュメント(『Oracle WebLogic Serverアプリケーションの開発12c (12.1.2)』の第17章「WebLogic ServerでのWebSocketの使用」)を参照してください。

WebLogic ServerのWebSocketの実装には、次のコンポーネントが含まれています。

- WebSocketプロトコルの実装

- WebLogic WebSocket Java API

- WebSocketメッセージングのプロトコル・フォールバック

- WebSocketサンプル・アプリケーション

WebSocketプロトコルの実装

WebLogic ServerでのWebSocketプロトコルの実装は、JSR 356 Java API for WebSocketのリファレンス実装によって提供されます。このWebSocketプロトコルの実装では、接続アップグレードの処理、接続の確立と管理およびクライアントとのやり取りの処理を行います。

WebLogic WebSocket Java API

WebLogic WebSocket APIは、JSR 356 Java API for WebSocketのリファレンス実装によって提供されます。このAPIは次パッケージで構成されます。

javax.websocket.server

このパッケージには、サーバーのエンドポイントを作成および構成するためのアノテーション、クラスおよびインタフェースが含まれています。

javax.websocket

このパッケージには、クライアントとサーバーのエンドポイントに共通のアノテーション、クラスおよびインタフェースが含まれています。

これらのパッケージのAPIリファレンスに関するドキュメントは、Java EE 7のAPI仕様の次の各項を参照してください。

- Package javax.websocket

- Package javax.websocket.server

WebSocketメッセージングのプロトコル・フォールバック

プロトコル・フォールバックは、WebSocketプロトコルがサポートされていない場合に、WebSocketメッセージングの代替転送方法を使用するためのメカニズムを提供します。通常、WebSocketプロトコルがサポートされない理由は、WebSocketオブジェクトが使用できないためか、WebSocketフレームがファイアウォールによってブロックされているためです。このリリースでサポートされている代替転送方法は、HTTPロング・ポーリングのみです。

プロトコル・フォールバックを使用すると、実行時環境でWebSocketプロトコルがサポートされているかどうかにかかわらず、標準のプログラミングAPIを使用してWebSocketメッセージングを実行できます。詳細は、「WebSocketメッセージングのプロトコル・フォールバックの有効化」を参照してください。

WebSocketサンプル・アプリケーション

WebLogic Serverのサンプル・コンポーネントをマシンにインストールして構成すると、WebSocketのサンプルを使用してWebLogic ServerでのWebSocketの使用方法を実際に確認できます。このようなサンプルの実行の詳細は、『Oracle WebLogic Serverの理解』の「サンプル・アプリケーションおよびサンプル・コード」を参照してください。

WebSocketアプリケーションの作成の概要

Java API for WebSocket (JSR-356)では、WebアプリケーションにWebSocketエンドポイントを作成、構成およびデプロイできます。また、JSR-356で指定されているWebSocketクライアントAPIを使用すると、任意のJavaアプリケーションからリモートのWebSocketエンドポイントにアクセスできます。

WebSocketエンドポイントの作成およびデプロイの手順を次に示します。

1. エンドポイント・クラスを作成します。

2. エンドポイントのライフサイクル・メソッドを実装します。

3. エンドポイントにビジネス・ロジックを追加します。

4. Webアプリケーション内にエンドポイントをデプロイします。

エンドポイントの作成

Java API for WebSocketでは、次の種類のエンドポイントを作成できます。

- アノテーション付きエンドポイント

- プログラム的なエンドポイント

プログラム的なエンドポイントとアノテーション付きエンドポイントでは手順が異なります。多くの場合、プログラム的なエンドポイントよりもアノテーション付きエンドポイントの方が簡単に作成およびデプロイできます。

注意:

サーブレットとは対照的に、WebSocketエンドポイントは複数回インスタンス化されます。コンテナは、デプロイメントURIへの接続ごとに1つのエンドポイント・インスタンスを作成します。各インスタンスは1の接続のみに関連付けられます。この動作では、エンドポイント・インスタンスのコードを実行しているスレッドは常に1つのみなので、接続ごとにユーザーの状態を簡単に維持でき、デプロイメントが簡素化されます。

アノテーション付きエンドポイントの作成

アノテーション付きエンドポイントを作成すると、エンドポイント・クラスのメソッドにアノテーションを付けることによって、WebSocket接続のライフサイクル・イベントを処理できます。詳細は、「アノテーション付きWebSocketエンドポイントでのライフサイクル・イベントの処理」を参照してください。アノテーション付きエンドポイントは、アプリケーションに自動的にデプロイされます。
Java API for WebSocketでは、アノテーション付きサーバー・エンドポイントとアノテーション付きクライアント・エンドポイントを作成できます。

アノテーション付きサーバー・エンドポイントの作成手順:

1. サーバー・エンドポイントを表すPlain Old Java Object (POJO)クラスを記述します。
このクラスには、引数を取らないパブリック・コンストラクタが必要です。

2. javax.websocket.server.ServerEndpointアノテーションでPOJOクラスのクラス宣言にアノテーションを付けます。
このアノテーションは、クラスがWebSocketサーバー・エンドポイントを表していることを示します。

3. ServerEndpointアノテーションのvalue要素を、エンドポイントのデプロイ先の相対パスに設定します。
パスはフォワード・スラッシュ(/)で開始する必要があります。

例18-3 アノテーション付きサーバー・エンドポイント・クラスの宣言

次の例は、アノテーション付きサーバー・エンドポイント・クラスの宣言方法を示しています。プログラム的なエンドポイント・クラスを宣言して同じエンドポイントを表す方法の例は、例18-5を参照してください。

この例では、アノテーション付きサーバー・エンドポイント・クラスEchoEndpointを宣言します。エンドポイントは、アプリケーションからの相対パス/echoにデプロイされます。

import javax.websocket.server.ServerEndpoint;
...
@ServerEndpoint("/echo")
public class EchoEndpoint {
...
}

例18-4 アノテーション付きクライアント・エンドポイント・クラスの宣言

アノテーション付きクライアント・エンドポイントの作成手順:

1. クライアント・エンドポイントを表すPlain Old Java Object (POJO)クラスを記述します。
このクラスは、引数を取るコンストラクタを持つことができます。ただし、このようなエンドポイントからサーバー・エンドポイントに接続するには、インスタンスを取得するconnectToServerメソッドの変数を使用する必要があります。クラスを取得する変数は使用できません。詳細は、「Java WebSocketクライアントのサーバー・エンドポイントへの接続」を参照してください。

2. avax.websocket.ClientEndpointアノテーションでPOJOクラスのクラス宣言にアノテーションを付けます。
このアノテーションは、クラスがWebSocketクライアント・エンドポイントを表していることを示します。

次の例は、アノテーション付きクライアント・エンドポイント・クラスの宣言方法を示しています。

この例では、アノテーション付きクライアント・エンドポイント・クラスExampleEndpointを宣言します。

import javax.websocket.ClientEndpoint;
...
@ClientEndpoint
public class ExampleEndpoint {
...
}

プログラム的なエンドポイントの作成

プログラム的なエンドポイントを作成するには、エンドポイントのスーパークラスのメソッドをオーバーライドして、WebSocket接続のライフサイクル・イベントを処理する必要があります。詳細は、「プログラム的なWebSocketエンドポイントでのライフサイクル・イベントの処理」を参照してください。プログラム的なエンドポイントは、アプリケーションに自動的にデプロイされません。エンドポイントは明示的にデプロイする必要があります。詳細は、「アプリケーション内でのプログラム的なエンドポイントへのパスの指定」を参照してください。

プログラム的なエンドポイントを作成するには、javax.websocket.Endpointクラスを拡張します。

例18-5は、プログラム的なエンドポイント・クラスの宣言方法を示しています。アノテーション付きエンドポイント・クラスを宣言して同じエンドポイントを表す方法の例は、例18-3を参照してください。

例18-5 プログラム的なエンドポイント・クラスの宣言

この例では、プログラム的なエンドポイント・クラスEchoEndpointを宣言します。アプリケーション内でこのエンドポイントへのパスを指定する方法を示した例は、例18-6を参照してください。

import javax.websocket.Endpoint;
...
public class EchoEndpoint extends Endpoint {
...
}

アプリケーション内でのプログラム的なエンドポイントへのパスの指定

リモート・クライアントがプログラム的なエンドポイントに接続できるようにするには、アプリケーション内でエンドポイントへのパスを指定する必要があります。

アプリケーション内でプログラム的なエンドポイントへのパスを指定する手順:

1. javax.websocket.server.ServerEndpointConfig.Builder.create静的メソッドを呼び出して、javax.websocket.server.ServerEndpointConfig.Builderクラスのインスタンスを取得します。

createメソッドの呼出しでは、次の情報をパラメータとしてメソッドに渡します。

- エンドポイントのクラス

- エンドポイントを使用可能にするアプリケーションからの相対パス

2. 前の手順で取得したServerEndpointConfig.Builderオブジェクト上で、buildメソッドを呼び出します。

アプリケーションをデプロイすると、エンドポイントが次のURIで使用可能になります。

ws://host:port/application/path

このURIの次の項目を置き換えます。

host

アプリケーションが稼働しているホスト。

port

WebLogic Serverのクライアント・リクエストのリスニング・ポート。

application

アプリケーションのデプロイ名。

path

createメソッドの呼出しで指定したパス。

たとえば、ローカル・ホスト上で稼働している/echoappアプリケーションからの相対パス/echoにあるエンドポイントのURIは、ws://localhost:8890/echoapp/echoです。

例18-6は、このタスクを1行のJavaコードで実行する方法を示しています。

例18-6 アプリケーション内でのプログラム的なエンドポイントへのパスの指定

この例では、アプリケーション内でのプログラム的なエンドポイントEchoEndpoint (例18-5で作成)へのパスとして、/echoを指定します。

import javax.websocket.server.ServerEndpointConfig.Builder;
...
ServerEndpointConfig.Builder.create(EchoEndpoint.class, "/echo").build();
...

WebSocket接続のライフサイクル・イベントの処理

WebSocket接続のライフサイクル・イベントの処理方法は、接続のエンドポイントがアノテーション付きエンドポイントかプログラム的なエンドポイントかによって異なります。詳細については、以下を参照してください。

- アノテーション付きWebSocketエンドポイントでのライフサイクル・イベントの処理

- プログラム的なWebSocketエンドポイントでのライフサイクル・イベントの処理

アノテーション付きWebSocketエンドポイントでのライフサイクル・イベントの処理

アノテーション付きWebSocketでのライフサイクル・イベントの処理では、次のタスクを実行します。

1. イベントを処理するメソッドをエンドポイント・クラスに追加します。

メソッドで使用可能なパラメータは、イベントの指定に使用するアノテーションによって定義されます。

2. メソッドの処理対象であるイベントを指定するアノテーションを使用して、メソッドの宣言にアノテーションを付けます。

表18-1は、WebSocketエンドポイントのライフサイクル・イベントと、その処理メソッドを指定するためのアノテーション(javax.websocketパッケージで利用可能)を示しています。この表には、これらのメソッドで最もよく使用されるパラメータが例示されています。各例では、オプションのjavax.websocket.Sessionパラメータが使用されています。Sessionオブジェクトは、WebSocketエンドポイントのペア間の対話を表します。

アノテーションで使用可能なパラメータの組合せの詳細は、アノテーションのAPIリファレンスを参照してください。

表18-1 WebSocketエンドポイントのライフサイクル・イベントに使用するjavax.websocketのアノテーション

イベント

アノテーション

例

Connection opened

OnOpen

@OnOpen
public void open(Session session,
EndpointConfig conf) { }

Message received

OnMessage

@OnMessage
public String message (String msg) { }

Error

OnError

@OnError
public void error(Session session,
Throwable error) { }

Connection closed

OnClose

@OnClose
public void close(Session session,
CloseReason reason) { }

Connection openedイベントの処理

Connection openedイベントを処理して、新しいWebSocketの対話が開始されたことをユーザーに通知します。

Connection openedイベントを処理するには、イベントを処理するメソッドにOnOpenアノテーションを付けます。

例18-7は、Connection openedイベントの処理方法を示しています。

例18-7 Connection openedイベントの処理

この例では、WebSocket接続が開いたときに、セッションの識別子が出力されます。

import javax.websocket.OnOpen;
import javax.websocket.Session;
...
@OnOpen
public void openedConnection (Session session) {
System.out.println("WebSocket opened: " + session.getId());
}
...

Message receivedイベントの処理

Java API for WebSocketでは、次のタイプの受信メッセージを処理できます。

- テキスト・メッセージ

- バイナリ・メッセージ

- Pongメッセージ

1. 受信メッセージ・タイプを処理するメソッドをエンドポイント・クラスに追加します。

メッセージの受信に使用するパラメータのデータ型が、次の表に示したメッセージ・タイプと一致することを確認してください。

メッセージ・タイプ

メッセージ受信用パラメータのデータ型

テキスト

メッセージの受信方法に応じて、次のいずれかのデータ型が使用されます。

- メッセージ全体を受信する場合: java.lang.String

- その型と同等のJavaプリミティブ型またはクラス型に変換されたメッセージ全体を受信する場合: 同等のプリミティブ型またはクラス型

- メッセージを部分的に受信する場合: String型とBoolean型の組合せ

- メッセージ全体をブロッキング・ストリームとして受信する場合: java.io.Reader

- Javaオブジェクトとしてエンコードされたメッセージを受信する場合: エンドポイントにテキスト・デコーダがある任意の型(javax.websocket.Decoder.Textまたはjavax.websocket.Decoder.TextStream)

バイナリ

メッセージの受信方法に応じて、次のいずれかのデータ型が使用されます。

- メッセージ全体を受信する場合: バイト配列またはjava.nio.ByteBuffer

- メッセージを部分的に受信する場合: バイト配列とBoolean型の組合せ、またはByteBuffer型とBoolean型の組合せ

- メッセージ全体をブロッキング・ストリームとして受信する場合: java.io.InputStream

- Javaオブジェクトとしてエンコードされたメッセージを受信する場合: エンドポイントにバイナリ・デコーダがある任意の型(javax.websocket.Decoder.Binaryまたはjavax.websocket.Decoder.BinaryStream)

Pong

javax.websocket.PongMessage

2. メソッドの宣言にOnMessageアノテーションを付けます。

エンドポイントでは最大で3つのメソッドに@OnMessageアノテーションを付けられます(テキスト、バイナリ、pongのメッセージ・タイプごとに1つずつ)。

注意:

アノテーション付きエンドポイントの場合は、受信メッセージを処理するメソッドをエンドポイント・クラスに追加します。メッセージ・ハンドラ・クラスを個別に作成する必要はありません。ただし、プログラム的なエンドポイントの場合は、メッセージ・ハンドラ・クラスを個別に作成する必要があります。

アノテーション付きエンドポイントとプログラム的なエンドポイントとの間で、受信メッセージの処理方法を比較するには、例18-8および例18-12を参照してください。

例18-8 アノテーション付きエンドポイントでの受信テキスト・メッセージの処理

次の例は、アノテーション付きエンドポイントでの受信テキスト・メッセージの処理方法を示しています。

この例では、このエンドポイントのピアにメッセージを返信することで、すべての受信テキスト・メッセージに応答します。OnMessageアノテーションの付いたメソッドはエンドポイント・クラスのメソッドで、個別のメッセージ・ハンドラ・クラスではありません。

プログラム的なエンドポイントで同じ操作を実行する方法の例は、例18-12を参照してください。

import java.io.IOException;

import javax.websocket.OnMessage;
import javax.websocket.Session;
...
@OnMessage
public String onMessage(String msg) throws IOException {
return msg;
}
...

例18-9 全タイプの受信メッセージの処理方法

この例では、受信したテキスト・メッセージ、バイナリ・メッセージおよびpongメッセージを処理します。テキスト・メッセージは、Stringオブジェクトとしてメッセージ全体が受信されます。バイナリ・メッセージは、ByteBufferオブジェクトとしてメッセージ全体が受信されます。

import java.nio.ByteBuffer;

import javax.websocket.OnMessage;
import javax.websocket.PongMessage;
import javax.websocket.Session;
...
@OnMessage
public void textMessage(Session session, String msg) {
System.out.println("Text message: " + msg);
}
@OnMessage
public void binaryMessage(Session session, ByteBuffer msg) {
System.out.println("Binary message: " + msg.toString());
}
@OnMessage
public void pongMessage(Session session, PongMessage msg) {
System.out.println("Pong message: " +
msg.getApplicationData().toString());
}
...

Errorイベントの処理

処理する必要があるErrorイベントは、WebSocketプロトコルでモデル化されていないイベントのみです。次に例を示します。

- 接続時の問題

- メッセージ・ハンドラからのランタイム・エラー

- メッセージ・デコード時の変換エラー

Errorイベントを処理するには、イベント処理のメソッドにOnErrorアノテーションを付けます。

例18-10は、Errorイベントの処理方法を示しています。

例18-10 Errorイベントの処理

この例では、Errorイベントに応答して、スタック・トレースを出力します。

import javax.websocket.OnError;
import javax.websocket.Session;

...
@OnError
public void error(Session session, Throwable t) {
t.printStackTrace();
...
}

Connection closedイベントの処理

Connection closedイベントを処理する必要があるのは、接続を閉じる前になんらかの特別な処理が必要な場合のみです(たとえば、接続が閉じられた後でデータを使用できなくなる前に、IDなどのセッション属性やセッションが保持している任意のアプリケーション・データを取得する場合など)。

Connection closedイベントを処理するには、イベント処理のメソッドにOnCloseアノテーションを付けます。

例18-11は、Connection closedイベントの処理方法を示しています。

例18-11 Connection closedイベントの処理

この例では、Connection closedイベントに応答して、Someone is disconnecting...というメッセージを出力します。

import javax.websocket.OnClose;
import javax.websocket.Session;
...
@OnClose
public void bye(Session remote) {
System.out.println("Someone is disconnecting...");
}
...

プログラム的なWebSocketエンドポイントでのライフサイクル・イベントの処理

表18-2は、プログラム的なWebSocketエンドポイントでのライフサイクル・イベントの処理方法をまとめたものです。

表18-2 プログラム的なWebSocketエンドポイントでのライフサイクル・イベントの処理

イベント

処理方法

Connection opened

EndpointクラスのonOpen抽象メソッドをオーバーライドします。

Message received

1. エンドポイント・クラスにメッセージ・ハンドラ・インタフェースjavax.websocket.MessageHandler.Partialまたはjavax.websocket.MessageHandler.Wholeを実装することを宣言します。

2. エンドポイントのSessionオブジェクトのaddMessageHandlerメソッドを呼び出して、メッセージ・ハンドラを登録します。

3. エンドポイント・クラスに実装されているメッセージ・ハンドラ・インタフェースのonMessageメソッドを実装します。

Error

オプション: EndpointクラスのonErrorメソッドをオーバーライドします。

このメソッドをオーバーライドしないと、エラー発生時に、エンドポイントがEndpointクラスから継承したonErrorメソッドがコールされます。

Connection closed

オプション: EndpointクラスのonCloseメソッドをオーバーライドします。

このメソッドをオーバーライドしないと、接続が閉じられる前に、エンドポイントがEndpointクラスから継承したonCloseメソッドがコールされます。

例18-12は、Connection openedイベントとMessage receivedイベントを処理して、プログラム的なエンドポイントで受信テキスト・メッセージを処理する方法を示しています。

例18-12 プログラム的なエンドポイントでの受信テキスト・メッセージの処理

この例では、すべての受信テキスト・メッセージをエコーします。この例では、EndpointクラスのonOpenメソッド(このクラスで唯一の抽象メソッド)をオーバーライドします。

Sessionパラメータは、このエンドポイントとリモートのエンドポイント間の対話を表します。addMessageHandlerメソッドはメッセージ・ハンドラを登録し、getBasicRemoteメソッドはリモート・エンドポイントを表すオブジェクトを返します。

メッセージ・ハンドラは、無名内部クラスとして実装されています。エンドポイントでテキスト・メッセージを受信すると、メッセージ・ハンドラのonMessageメソッドが呼び出されます。

メッセージの送信の詳細は、「メッセージの送信」を参照してください。

アノテーション付きエンドポイントで同じ操作を実行する方法の例は、例18-8を参照してください。

import java.io.IOException;
import javax.websocket.EndpointConfig;
import javax.websocket.MessageHandler;
import javax.websocket.Session;
...
@Override
public void onOpen(final Session session, EndpointConfig config) {
session.addMessageHandler(new MessageHandler.Whole<String>() {
@Override
public void onMessage(String msg) {
try {
session.getBasicRemote().sendText(msg);
} catch (IOException e) { ... }
}
});
}
...

WebSocketエンドポイントでのリソースの定義、注入およびアクセス

Java API for WebSocketでは、Contexts and Dependency Injection (CDI)を使用して、WebSocketエンドポイントに必要なリソースを注入したり、リソースにアクセスしたりできます。注入されたリソースは、WebSocket接続のライフサイクル・イベントを処理するメソッド内から使用できます。

CDIの詳細は、Contexts and Dependency Injection for the Java EE platformの使用方法を参照してください。

WebSocketエンドポイントでリソースを定義、注入およびアクセスする手順:

1. 注入するリソースを表すマネージドBeanを定義します。

詳細は、「マネージドBeanの定義」を参照してください。

2. エンドポイント・クラスで、マネージドBeanを注入します。

詳細は、「Beanの注入」を参照してください。

3. 必要に応じて、関連するメソッド内から、注入されたBeanのメソッドを呼び出します。

次の例では、WebSocketエンドポイントでリソースを定義、注入およびアクセスする方法を示します。

- 例18-13

- 例18-14

例18-13 WebSocketエンドポイントでのマネージドBeanの定義

この例では、マネージドBeanクラスInjectedSimpleBeanを定義します。

import javax.annotation.PostConstruct;

public class InjectedSimpleBean {

private static final String TEXT = " (from your server)";
private boolean postConstructCalled = false;

public String getText() {
return postConstructCalled ? TEXT : null;
}

@PostConstruct
public void postConstruct() {
postConstructCalled = true;
}

}

例18-14 WebSocketエンドポイントでのリソースの注入およびアクセス

この例では、InjectedSimpleBeanマネージドBeanクラスのインスタンスを、サーバー・エンドポイントSimpleEndpointに注入します。エンドポイントがメッセージを受信すると、注入されたBean上でgetTextメソッドが呼び出されます。メソッドからテキスト(sent from your server)が返されます。その後で、元のメッセージと収集されたデータの連結メッセージがエンドポイントから返信されます。

InjectedSimpleBeanマネージドBeanクラスは、例18-13で定義されています。

import javax.websocket.OnMessage;
import javax.websocket.server.ServerEndpoint;

import javax.annotation.PostConstruct;
import javax.inject.Inject;

@ServerEndpoint(value = "/simple")
public class SimpleEndpoint {

private boolean postConstructCalled = false;

@Inject
InjectedSimpleBean bean;

@OnMessage
public String echo(String message) {
return postConstructCalled ?
String.format("%s%s", message, bean.getText()) :
"PostConstruct was not called";
}

@PostConstruct
public void postConstruct() {
postConstructCalled = true;
}

}

メッセージの送信

Java API for WebSocketでは、次のタイプのメッセージをエンドポイントからその接続ピアに送信できます。

- テキスト・メッセージ

- バイナリ・メッセージ

- Pingフレーム

エンドポイントの単一ピアへのメッセージ送信

エンドポイントの単一ピアにメッセージを送信する手順:

1. 接続のSessionオブジェクトを取得します。

Sessionオブジェクトは、エンドポイントのライフサイクル・メソッドのパラメータとして使用できます。このオブジェクトを取得する方法は、送信するメッセージがピアから受け取ったメッセージに対する応答であるかどうかによって異なります。

- メッセージが応答である場合は、メッセージを受信したメソッド内からSessionオブジェクトを取得します。

- メッセージが応答でない場合は、Connection openedイベントを処理するメソッドで、Sessionオブジェクトをエンドポイント・クラスのインスタンス変数として保存します。このように保存することで、他のメソッドからSessionオブジェクトにアクセスできるようになります。

2. Sessionオブジェクトを使用して、javax.websocket.RemoteEndpointのサブインタフェースのいずれかを実装するオブジェクトを取得します。

- メッセージの同期送信を行う場合は、RemoteEndpoint.Basicオブジェクトを取得します。このオブジェクトでは、ブロッキング・メソッドでメッセージを送信できます。
RemoteEndpoint.Basicオブジェクトを取得するには、Session.getBasicRemote()メソッドを呼び出します。

- メッセージの非同期送信を行う場合は、RemoteEndpoint.Asyncオブジェクトを取得します。このオブジェクトでは、非ブロッキング・メソッドでメッセージを送信できます。
RemoteEndpoint.Asyncオブジェクトを取得するには、Session.getAsyncRemote()メソッドを呼び出します。

3. 前の手順で取得したRemoteEndpointオブジェクトを使用して、メッセージをピアに送信します。

次のリストでは、メッセージをピアに送信する場合に使用できるメソッドの一部を示します。

- void RemoteEndpoint.Basic.sendText(String text)
テキスト・メッセージをピアに送信します。このメソッドは、メッセージ全体が送信されるまでブロックします。

- void RemoteEndpoint.Basic.sendBinary(ByteBuffer data)
バイナリ・メッセージをピアに送信します。このメソッドは、メッセージ全体が送信されるまでブロックします。

- void RemoteEndpoint.sendPing(ByteBuffer appData)
pingフレームをピアに送信します。

- void RemoteEndpoint.sendPong(ByteBuffer appData)
pongフレームをピアに送信します。

例18-15では、この操作手順を使用して、すべての受信テキスト・メッセージに応答する方法を示します。メッセージをメソッドの戻り値として送信する方法の例は、例18-8を参照してください。

例18-15 エンドポイントの単一ピアへのメッセージ送信

この例では、このエンドポイントのピアにメッセージを返信することで、すべての受信テキスト・メッセージに応答します。

import java.io.IOException;

import javax.websocket.OnMessage;
import javax.websocket.Session;
...
@OnMessage
public void onMessage(Session session, String msg) {
try {
session.getBasicRemote().sendText(msg);
} catch (IOException e) { ... }
}
...

エンドポイントのすべてのピアへのメッセージ送信

一部のWebSocketアプリケーションでは、アプリケーションのWebSocketエンドポイントのすべての接続ピアに対してメッセージを送信する必要があります。次に例を示します。

- 株式アプリケーションでは、すべての接続クライアントに株価情報を送信する必要があります。

- チャット・アプリケーションでは、1人のユーザーからのメッセージを、同じチャット・ルーム内の他のすべてのクライアントに送信する必要があります。

- オンライン・オークション・アプリケーションでは、アイテムのすべての入札者に最新の付け値を送信する必要があります。

しかし、エンドポイント・クラスの各インスタンスは1つの接続およびピアにのみ関連付けられます。したがって、エンドポイントのすべてのピアにメッセージを送信するには、同じエンドポイントへの接続を表す開いているWebSocketセッションすべてに対して、操作を繰り返す必要があります。

エンドポイントのすべてのピアにメッセージを送信する手順:

1. エンドポイントへの接続を表す開いているWebSocketセッションをすべて取得します。

そのためには、エンドポイントのSessionオブジェクト上でgetOpenSessionsメソッドを呼び出します。

2. 前の手順で取得した開いているセッションそれぞれにメッセージを送信します。

a. セッションを使用して、RemoteEndpointオブジェクトを取得します。

b. RemoteEndpointオブジェクトを使用して、メッセージを送信します。
詳細は、「エンドポイントの単一ピアへのメッセージ送信」を参照してください

例18-16 エンドポイントのすべてのピアへのメッセージ送信

この例では、受信テキスト・メッセージをすべての接続ピアに転送します。

import java.io.IOException;

import javax.websocket.OnMessage;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
...
@ServerEndpoint("/echoall")
public static class EchoAllEndpoint {
@OnMessage
public void messageReceived(Session session, String msg) {
for (Session sess : session.getOpenSessions()) {
try {
sess.getBasicRemote().sendText(msg);
} catch (IOException e) {
// handle exception
}
}
}
}

エンドポイントのすべてのピアにメッセージを送信する場合の効率性の確保

多数のメッセージが送信される実際のアプリケーションでは、複数のスレッドを使用することで、アプリケーションからメッセージを効率的に送信できるようになります。

開いているWebSocket接続が多すぎる場合、1つのスレッドを使用してメッセージをブロードキャストすることは非効率です。なぜなら、繰り返しプロセスにおいては、クライアントがメッセージを受信するのにかかる時間は、その場所に依存するからです。何千ものWebSocket接続が開いていると、繰り返しが遅くなるため、一部のクライアントはメッセージを早く受信するようになりますが、メッセージの受信がかなり後になるクライアントも出てきます。この遅れは、特定の状況では許容できません。たとえば、株式アプリケーションでは、各クライアントができるかぎり早く株価データを受信する必要があります。

効率を上げるために、アプリケーションで、開いているWebSocket接続を複数のグループに分割し、複数のスレッドを使用して、WebSocket接続の各グループにメッセージをブロードキャストすることができます。

WebSocketエンドポイントのスレッド・セーフティの確保

Java API for WebSocketの仕様では、Java EE実装においてはエンドポイント・クラスを接続ごとに1回ずつインスタンス化することが求められています。この要件によって、WebSocketエンドポイント・クラスのコードを実行しているスレッドは常に1つのみであることが保証されるので、WebSocketエンドポイントのデプロイメントが容易になります。エンドポイントに新規スレッドを導入する場合は、複数のスレッドからアクセスされる変数およびメソッドがスレッド・セーフであることを保証する必要があります。

WebSocketメッセージのエンコーディングとデコーディング

Java API for WebSocketでは、エンコーダとデコーダを使用して、WebSocketメッセージとカスタムJavaタイプ間での変換をサポートします。このメカニズムでは、オブジェクトのシリアライズとデシリアライズからビジネス・ロジックが切り離されるので、WebSocketアプリケーションがシンプルになります。

エンコーダはJavaオブジェクトを取得して、WebSocketのテキスト・メッセージまたはバイナリ・メッセージとして送信可能な表現を生成します。たとえば、エンコーダは通常、JavaScript Object Notation (JSON)表現、Extensible Markup Language (XML)表現またはバイナリ表現を生成します。デコーダは逆の役割を果します。つまり、WebSocketメッセージを読み取ってJavaオブジェクトを作成します。

注意:

複数のJavaタイプを同じタイプのWebSocketメッセージとして送受信する必要がある場合は、タイプの定義で共通クラスを拡張します。たとえば、JavaタイプMessageAおよびMessageBをテキスト・メッセージとして送受信する必要がある場合は、これらのタイプの定義で共通クラスMessageを拡張します。

このようにタイプを定義することにより、単一のデコーダ・クラスの実装で、複数のタイプに対応できます。

WebSocketメッセージとしてのJavaオブジェクトのエンコーディング

テキスト・メッセージ用エンコーダとバイナリ・メッセージ用エンコーダは、それぞれ複数指定できます。エンドポイントと同様に、エンコーダ・インスタンスは1つのWebSocket接続およびピアにのみ関連付けられます。したがって、エンドポイント・インスタンスのコードを実行しているスレッドは常に1つのみです。

JavaオブジェクトをWebSocketメッセージとしてエンコードする手順:

1. WebSocketメッセージとして送信するカスタムJavaタイプごとに、WebSocketメッセージのタイプに適したインタフェースを実装します。

- テキスト・メッセージには、javax.websocket.Encoder.Text<T>を実装します。

- バイナリ・メッセージには、javax.websocket.Encoder.Binary<T>を実装します。

これらのインタフェースはencodeメソッドを指定します。

2. エンドポイントでエンコーダ実装が使用されるように指定します。

- アノテーション付きエンドポイントの場合は、エンコーダ実装の名前をServerEndpointアノテーションのencodersオプション要素に追加します。

- プログラム的なエンドポイントの場合は、エンコーダ実装の名前のリストをjavax.websocket.server.ServerEndpointConfig.Builderオブジェクトのencodersメソッドのパラメータとして渡します。

3. RemoteEndpoint.BasicまたはRemoteEndpoint.AsyncインタフェースのsendObject(Object data)メソッドを使用して、オブジェクトをメッセージとして送信します。

コンテナはタイプの一致するエンコーダを検索し、それを使用してオブジェクトをWebSocketメッセージに変換します。

次の例では、Javaタイプcom.example.game.message.MessageAおよびcom.example.game.message.MessageBをテキスト・メッセージとして送信する方法を示します。

- 例18-17

- 例18-18

- 例18-19

例18-17 エンコーダ・インタフェースの実装

この例では、Encoder.Text<MessageA>インタフェースを実装します。

package com.example.game.encoder;

import javax.websocket.EncodeException;
import javax.websocket.Encoder;
import javax.websocket.EndpointConfig;

import com.example.game.message.MessageA;
...
public class MessageATextEncoder implements Encoder.Text<MessageA> {
@Override
public void init(EndpointConfig ec) { }
@Override
public void destroy() { }
@Override
public String encode(MessageA msgA) throws EncodeException {
// Access msgA's properties and convert to JSON text...
return msgAJsonString;
}
...
}

Encoder.Text<MessageB>を実装する場合も同様です。

例18-18 アノテーション付きWebSocketエンドポイント用のエンコーダの定義

この例では、エンコーダ・クラスMessageATextEncoder.classおよびMessageBTextEncoder.classを、WebSocketサーバー・エンドポイントEncEndpointに定義します。

package com.example.game;

import javax.websocket.server.ServerEndpoint;

import com.example.game.encoder.MessageATextEncoder;
import com.example.game.encoder.MessageBTextEncoder;
...

@ServerEndpoint(
value = "/myendpoint",
encoders = { MessageATextEncoder.class, MessageBTextEncoder.class }
...
)
public class EncEndpoint { ... }

例18-19 WebSocketメッセージとしてエンコードされたJavaオブジェクトの送信

この例では、sendObjectメソッドを使用して、MessageAオブジェクトおよびMessageBオブジェクトをWebSocketメッセージとして送信します。

import javax.websocket.Session;
...
import com.example.game.message.MessageA;
import com.example.game.message.MessageB;
...
MessageA msgA = new MessageA(...);
MessageB msgB = new MessageB(...);
session.getBasicRemote.sendObject(msgA);
session.getBasicRemote.sendObject(msgB);
...

JavaオブジェクトとしてのWebSocketメッセージのデコーディング

エンコーダとは異なり、バイナリ・メッセージ用デコーダとテキスト・メッセージ用デコーダは、それぞれ最大で1つしか指定できません。エンドポイントと同様に、デコーダ・インスタンスは1つのWebSocket接続およびピアにのみ関連付けられているので、デコーダ・インスタンスのコードを実行しているスレッドは常に1つのみです。

WebSocketメッセージをJavaオブジェクトとしてデコードする手順:

1. WebSocketメッセージのタイプに適したインタフェースを実装します。

- テキスト・メッセージには、javax.websocket.Decoder.Text<T>を実装します。

- バイナリ・メッセージには、javax.websocket.Decoder.Binary<T>を実装します。

これらのインタフェースはwillDecodeメソッドおよびdecodeメソッドを指定します。

2. エンドポイントでデコーダ実装が使用されるように指定します。

- アノテーション付きエンドポイントの場合は、デコーダ実装の名前をServerEndpointアノテーションのdecodersオプション要素に追加します。

- プログラム的なエンドポイントの場合は、デコーダ実装の名前のリストをjavax.websocket.server.ServerEndpointConfig.Builderオブジェクトのdecodersメソッドのパラメータとして渡します。

3. Message receivedイベントを処理するエンドポイントのメソッドで、カスタムJavaタイプがパラメータとして取得されるようにします。

詳細は、「WebSocket接続のライフサイクル・イベントの処理」を参照してください。

指定されたデコーダでデコード可能なメッセージをエンドポイントが受信すると、コンテナはカスタムJavaタイプをパラメータとして取得するメソッドをコールします(このメソッドが存在する場合)。

次の例では、WebSocketテキスト・メッセージをJavaタイプcom.example.game.message.MessageAおよびcom.example.game.message.MessageBとしてデコードする方法を示します。

- 例18-20

- 例18-21

- 例18-22

この例では、Javaタイプcom.example.game.message.MessageAおよびcom.example.game.message.MessageBでcom.example.game.message.Messageクラスが拡張されているものと仮定します。

例18-20 デコーダ・インタフェースの実装

この例では、Decoder.Text<Message>インタフェースを実装します。

エンドポイントで使用できるテキスト・メッセージ用デコーダは1つのみなので、Messageスーパークラスのデコーダを実装することになります。このデコーダを使用して、Messageのサブクラスをデコードします。

package com.example.game.decoder;

import javax.websocket.DecodeException;
import javax.websocket.Decoder;
import javax.websocket.EndpointConfig;

import com.example.game.message.Message;
import com.example.game.message.MessageA;
import com.example.game.message.MessageB;
...

public class MessageTextDecoder implements Decoder.Text<Message> {
@Override
public void init(EndpointConfig ec) { }
@Override
public void destroy() { }
@Override
public Message decode(String string) throws DecodeException {
// Read message...
if ( /* message is an A message */ )
return new MessageA(...);
else if ( /* message is a B message */ )
return new MessageB(...);
}
@Override
public boolean willDecode(String string) {
// Determine if the message can be converted into either a
// MessageA object or a MessageB object...
return canDecode;
}
}

例18-21 アノテーション付きWebSocketエンドポイント用のデコーダの定義

この例では、デコーダ・クラスMessageTextDecoder.classを、WebSocketサーバー・エンドポイントEncEndpointに定義します。

完全を期すため、この例には、例18-18で示したエンコーダ・クラスMessageATextEncoder.classおよびMessageBTextEncoder.classの定義も含まれています。

package com.example.game;

import javax.websocket.server.ServerEndpoint;

import com.example.game.encoder.MessageATextEncoder;
import com.example.game.encoder.MessageBTextEncoder;
import com.example.game.decoder.MessageTextDecoder;
...
@ServerEndpoint(
value = "/myendpoint",
encoders = { MessageATextEncoder.class, MessageBTextEncoder.class },
decoders = { MessageTextDecoder.class }
)
public class EncEndpoint { ... }

例18-22 JavaオブジェクトとしてエンコードされたWebSocketメッセージの受信

この例では、MessageAオブジェクトおよびMessageBオブジェクトを受信するmessageメソッドを定義します。

import javax.websocket.OnMessage;
import javax.websocket.Session;
...
import com.example.game.message.Message;
import com.example.game.message.MessageA;
import com.example.game.message.MessageB;
...
@OnMessage
public void message(Session session, Message msg) {
if (msg instanceof MessageA) {
// We received a MessageA object...
else if (msg instanceof MessageB) {
// We received a MessageB object...
}
}

エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する方法

ServerEndpointアノテーションを使用すると、レベル1のURIテンプレートを使用して、エンドポイント・デプロイメントURIの一部分をアプリケーション・パラメータとして指定できます。URIテンプレートでは、変数拡張を使用してURIの範囲を示します。URIテンプレートの詳細は、http://tools.ietf.org/html/rfc6570を参照してください。

エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する手順:

1. ServerEndpointアノテーションのvalue要素を、使用するURIテンプレートに設定します。

URIテンプレートで、拡張する各変数をカッコで囲みます。

2. 拡張する各変数を、次のいずれかのイベント・タイプを処理するメソッドのパラメータとして宣言します。

- Connection opened

- Connection closed

- Message received

パラメータの型は、String型、プリミティブ型、またはこれらのボックス・バージョンです。

3. javax.websocket.server.PathParamアノテーションで、パラメータの宣言にアノテーションを付けます。

4. PathParamアノテーションのvalue要素を、変数の名前に設定します。

5. パラメータを取得するメソッドの本文に、変数の拡張ロジックを記述します。

例18-23は、エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する方法を示しています。

例18-23 エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する方法

この例では、エンドポイント・デプロイメントURIを、変数{room-name}が含まれるURIテンプレートとして指定します。この変数は、openメソッドのroomNameパラメータで拡張され、ユーザーがどのチャット・ルームに参加するかを決定します。

import javax.websocket.EndpointConfig;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.PathParam;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/chatrooms/{room-name}")
public class ChatEndpoint {
@OnOpen
public void open(Session session,
EndpointConfig c,
@PathParam("room-name") String roomName) {
// Add the client to the chat room of their choice ...
}
...
}

{room-name}変数を拡張するopenメソッドの本文のコードは、この例には示していません。

ローカルのJava EEサーバーでポート8080を使用し、chatappというWebアプリケーション内にエンドポイントをデプロイしている場合、クライアントは次のURIを使用してエンドポイントに接続できます。

http://localhost:8080/chatapp/chatrooms/currentnews
http://localhost:8080/chatapp/chatrooms/music
http://localhost:8080/chatapp/chatrooms/cars
http://localhost:8080/chatapp/chatrooms/technology

クライアントの状態の管理

コンテナでは、接続ごとにエンドポイント・クラスのインスタンスが作成されるので、クライアントの状態の情報を格納するためのインスタンス変数を定義して使用することができます。

また、Session.getUserPropertiesメソッドには、ユーザー・プロパティを格納するための変更可能なマップが用意されています。

すべての接続クライアント共通の情報を格納するには、クラス(静的)変数を使用できますが、これらの変数へのスレッドセーフ・アクセスが保証されている必要があります。

例18-24は、クライアントの状態を保持する方法を示しています。

例18-24 クライアントの状態の保持

この例では、受信テキスト・メッセージに対して、各クライアントから受け取った直前のメッセージの内容を返します。

import java.io.IOException;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/delayedecho")
public class DelayedEchoEndpoint {
@OnOpen
public void open(Session session) {
session.getUserProperties().put("previousMsg", " ");
}
@OnMessage
public void message(Session session, String msg) {
String prev = (String) session.getUserProperties()
.get("previousMsg");
session.getUserProperties().put("previousMsg", msg);
try {
session.getBasicRemote().sendText(prev);
} catch (IOException e) { ... }
}
}

サーバー・エンドポイントのプログラムによる構成

Java API for WebSocketでは、コンテナでサーバー・エンドポイント・インタフェースを作成する方法を構成できます。次に関して、エンドポイントを構成するカスタム・ロジックを提供できます。

- WebSocket接続のハンドシェイク・リクエストの詳細へのアクセス

- Origin HTTPヘッダーのカスタム・チェックの実行

- WebSocketハンドシェイク・レスポンスの変更

- クライアントから要求されるWebSocketサブプロトコルの選択

- エンドポイント・インスタンスのインスタンス化と初期化の制御

- サーバー・エンドポイントでサポートされる拡張機能の指定

プログラムを使用してサーバー・エンドポイントを構成する手順:

1. javax.websocket.server.ServerEndpointConfig.Configuratorクラスを拡張します。

2. 次の表を参照して、カスタム・ロジックが必要な構成操作を実行するメソッドをオーバーライドします。

構成操作

オーバーライドするメソッド

WebSocket接続のハンドシェイク・リクエストの詳細へのアクセス

modifyHandshake

Origin HTTPヘッダーのカスタム・チェックの実行

checkOrigin

WebSocketハンドシェイク・レスポンスの変更

modifyHandshake

クライアントから要求されるWebSocketサブプロトコルの選択

getNegotiatedSubprotocol

エンドポイント・インスタンスのインスタンス化と初期化の制御

getEndpointInstance

サーバー・エンドポイントでサポートされる拡張機能の指定

getNegotiatedExtensions

3. サーバー・エンドポイント・クラスで、ServerEndpointアノテーションのconfigurator要素をコンフィギュレータ・クラスに設定します。

次の例は、プログラムを使用してサーバー・エンドポイントを構成する方法を示しています。

- 例18-25

- 例18-26

例18-25 ServerEndpointConfig.Configuratorクラスの拡張

この例では、ServerEndpointConfig.Configuratorクラスを拡張して、ハンドシェイク・リクエスト・オブジェクトをエンドポイント・インスタンスで使用できるようにします。

import javax.websocket.HandshakeResponse;
import javax.websocket.server.ServerEndpointConfig.Configurator;
import javax.websocket.server.HandshakeRequest;
...
public class CustomConfigurator extends ServerEndpointConfig.Configurator {

@Override
public void modifyHandshake(ServerEndpointConfig conf,
HandshakeRequest req,
HandshakeResponse resp) {

conf.getUserProperties().put("handshakereq", req);
}
...
}

例18-26 サーバー・エンドポイント・クラスのカスタム・コンフィギュレータの指定

この例では、カスタム・コンフィギュレータ・クラスCustomConfigurator.classを、サーバー・エンドポイント・クラスMyEndpointに指定します。

カスタム・コンフィギュレータを使用すると、サーバー・エンドポイント・クラスのインスタンスがハンドシェイク・リクエスト・オブジェクトにアクセスできるようになります。サーバー・エンドポイント・クラスは、ハンドシェイク・リクエスト・オブジェクトを使用して、ハンドシェイク・リクエストの詳細(ヘッダーやHttpSessionオブジェクトなど)にアクセスします。

import javax.websocket.EndpointConfig;
import javax.websocket.HandshakeResponse;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.HandshakeRequest;
import javax.websocket.server.ServerEndpoint;
import java.util.List;
import java.util.Map;
...
@ServerEndpoint(
value = "/myendpoint",
configurator = CustomConfigurator.class
)
public class MyEndpoint {

@OnOpen
public void open(Session s, EndpointConfig conf) {
HandshakeRequest req = (HandshakeRequest) conf.getUserProperties()
.get("handshakereq");
Map<String,List<String>> headers = req.getHeaders();
...
}
}

Java API for WebSocketを使用するアプリケーションの構築

WebLogic Serverでは、wlserver/server/lib/api.jarファイル内にJava API for WebSocketが用意されています。Java API for WebSocketを使用するアプリケーションを構築するには、アプリケーションのコンパイル時にクラスパスにこのライブラリを定義します。

Mavenを使用して、Java API for WebSocketを使用するアプリケーションを構築することもできます。Mavenを使用する場合は、Java API for WebSocketが格納されているMavenアーティファクト(javax.websocket.javax.websocket-api:1.0)をMavenセントラルから取得します。詳細は、「WebLogic Mavenプラグインの使用方法」を参照してください。

WebSocketアプリケーションのデプロイ

WebLogic Serverでは、標準のJava EE Webアプリケーション・アーカイブ(WAR)の一部としてWebSocketアプリケーションをデプロイします。これは、スタンドアロンのWebアプリケーションまたはエンタープライズ・アプリケーション内のWARモジュールのいずれかとして行います。

web.xmlファイルやその他のデプロイメント記述子でWebSocketエンドポイントを構成したり、WebSocketエンドポイントを登録または有効にするために動的な操作を実行する必要はありません。

ただしオプションで、表18-3に表示されているコンテキスト初期化プロパティを設定できます。これらのプロパティがWebLogic Server固有で、JSR 356の仕様に含まれていないことを示すため、それぞれの完全修飾名には接頭辞weblogic.websocketが付いています。

表18-3 WebSocketアプリケーションのコンテキスト初期化プロパティ

プロパティ

タイプ

説明

weblogic.websocket.tyrus.incoming-buffer-size

Integer

メッセージ受信用の内部の最大バッファ・サイズ(バイト)。アプリケーションは、このサイズを超えるメッセージを処理できません。

このパラメータは、次のサーバー・セッションおよびクライアント・セッションに影響します。

- 同じアプリケーション内のすべてのサーバー・セッション

- アプリケーション内のサーバーによってインスタンス化されたjavax.websocket.server.ServerContainerオブジェクトに接続しているクライアント・セッションのみ
クライアント・セッションのこの設定は、クライアント・エンドポイントに同じ名前のプロパティを設定することでオーバーライドできます。詳細は、「WebSocketクライアント・エンドポイントのプログラムによる構成」を参照してください。

デフォルトのバッファ・サイズは4194315 (ペイロードに4MB、フレームのオーバーヘッドに11バイト)です。

weblogic.websocket.tyrus.session-max-idle-timeout

Integer

接続のアイドル・タイムアウト後の最大時間(ミリ秒)デフォルト値は30000 (30秒に相当)です。

例18-27は、WebSocketアプリケーションにコンテキスト初期化プロパティを設定する方法を示しています。

例18-27 WebSocketアプリケーションのコンテキスト初期化プロパティの設定

この例では、WebSocketアプリケーションにコンテキスト初期化パラメータを次のように設定します。

- メッセージ受信用の内部の最大バッファ・サイズを16777227バイトに設定します。

- 接続のアイドル・タイムアウト後の最大時間を60,000ミリ秒(1分に相当)に設定します。

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" ...>
...
<context-param>
<param-name>weblogic.websocket.tyrus.incoming-buffer-size</param-name>
<param-value>16777227</param-value>
</context-param>
<context-param>
<param-name>weblogic.websocket.tyrus.session-max-idle-timeout</param-name>
<param-value>60000</param-value>
</context-param>
</web-app>

WebSocketアプリケーションの監視

WebSocketアプリケーションおよびエンドポイントのメッセージ統計およびランタイム・プロパティを監視できます。エンドポイント・レベルでの監視は個々のエンドポイントごとに情報を収集し、一方、アプリケーション・レベルでの監視は指定されたアプリケーションで内デプロイしているすべてのエンドポイントからの情報を集約します。

WebSocket監視プロパティ

次の表には、実行時に監視されるプロパティのタイプの詳細と監視がアプリケーション・レベルまたはエンドポイント・レベルのいずれで起こるかが示されています。メッセージ関連プロパティでは、WebLogic Serverはメッセージ・サイズにバイトを使用し、テキスト、バイナリおよびコントロールの3つのタイプのメッセージ・テキストを区別します。

プロパティ

説明

監視レベル

オープン・セッション数

WebSocketアプリケーションまたはエンドポイントの現行オープン・セッションの数。

アプリケーション、エンドポイント

最大オープン・セッション数

サーバー起動以来のWebSocketアプリケーションまたはエンドポイントのオープン・セッションの最大数。

アプリケーション、エンドポイント

エラー数

各エラーが発生した回数を示したエラーのリスト。エラーはスローできるクラス名で表されます。

アプリケーション、エンドポイント

送信メッセージ数

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントに送信されたメッセージの数。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

受信メッセージ数

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントが受信したメッセージの数。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

送信メッセージ数/秒

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントに送信された1秒当たりのメッセージの数。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

受信メッセージ数/秒

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントが受信した1秒当たりのメッセージの数。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

最小送信メッセージ・サイズ

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントに送信されたメッセージの最小サイズ。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

最小受信メッセージ・サイズ

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントが受信したメッセージの最小サイズ。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

最大送信メッセージ・サイズ

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントに送信されたメッセージの最大サイズ。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

最大受信メッセージ・サイズ

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントが受信したメッセージ最大サイズ。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

平均送信メッセージ・サイズ

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントに送信されたメッセージの平均サイズ。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

平均受信メッセージ・サイズ

監視が始まった時点からWebSocketアプリケーションまたはエンドポイントが受信したメッセージの平均サイズ。

統計は個々のメッセージ・タイプ(テキスト、バイナリおよびコントロール)ごと、および合計数として表示されます。

アプリケーション、エンドポイント

エンドポイント・パス

アプリケーション・コンテキスト・ルートに対するエンドポイントが登録されたパス。

エンドポイントのみ

エンドポイント・クラス名

エンドポイント・クラスの名前。

エンドポイントのみ

実行時にWebSocketアプリケーションおよびエンドポイントの監視されたメトリックにアクセスするには、次のMBeansを使用します。

- WebAppComponentRuntimeMBean

- WebsocketApplicationRuntimeMBean

- WebsocketBaseRuntimeMBean

- WebsocketEndpointRuntimeMBean

- WebsocketMessageStatisticsRuntimeMBean

管理コンソールまたはFusion Middleware Controlを使用してWebSocketアプリケーションおよびエンドポイントを監視するには、次のオンライン・ヘルプ・トピックを参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebSocketアプリケーションの監視に関する項

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebSocketアプリケーションの監視に関する項

プロキシ・サーバーでのWebSocketの使用

WebSocketアプリケーションにアクセスするクライアントは、WebLogic Serverインスタンスに直接接続するか、またはWebSocketプロトコルをサポートするWebプロキシ・サーバーを介して接続する必要があります。

次のプロキシ・サーバーはWebSocketプロトコルをサポートします。

- Oracle Traffic Director

- Oracle HTTP Server (リリース12.1.3以降)

- Apache 2.2 or 2.4 (Oracle WebLogicのWebサーバー・プラグイン(12.1.2.0.0)とともに使用される場合)

WebSocketクライアントの記述

通常、WebSocketクライアント・アプリケーションはブラウザ・ベースのクライアントです。Java API for WebSocketは、Java WebSocketクライアントの記述にも使用できます。

ブラウザ・ベースのWebSocketクライアントの記述

ブラウザ・ベースのWebSocketクライアント・アプリケーションは、通常、HTML5技術(HTMLマークアップ、CSS3、WebSocket JavaScript APIを利用するJavaScriptなど)の複合体です。HTML5の詳細は、http://www.w3.org/TR/html5/を参照してください。

ほとんどのブラウザでは、WebSocketプロトコルを作成して動かすために使用できるW3C WebSocket APIをサポートしています。W3C WebSocket APIの詳細は、http://www.w3.org/TR/websockets/を参照してください。

実行時環境でWebSocketプロトコルのサポートが保証されていない場合は、ブラウザ・ベースのクライアントでJavaScript API for WebSocketのフォールバックを使用してください。このAPIは、標準のW3C WebSocket API実装を提供します。また、このAPIは、WebSocketプロトコルがサポートされていない場合に、WebSocketメッセージングの代替転送方法を使用するためのメカニズムも提供します。詳細は、「WebSocketメッセージングのプロトコル・フォールバックの有効化」を参照してください。

次の手順は、WebSocketプロトコルを使用してWebLogic Serverインスタンスにメッセージを送信する、クライアント上の実行フローの例を示しています。

1. クライアントは、ws://またはwss://プロトコル接頭辞を使用して、WebSocketエンドポイントをホストするサーバーへのWebSocket接続を開きます。詳細は、「セキュアなWebSocket接続の確立」を参照してください。

var url = ((window.location.protocol == "https:") ? "wss:" : "ws:")
+ "//" + window.location.host
+ "/websocket-helloworld-wls/helloworld_delay.ws";

var ws = new WebSocket(url);

2. クライアントは、リスナーをWebSocketオブジェクトに登録して、メッセージのオープン、クローズ、受信などのイベントに応答します。受信したイベントや情報に基づき、クライアントは適切なアクションを実行します。

ws.onopen = function(event) {
document.getElementById("status").innerHTML = "OPEN"
}

ws.onmessage = function(event) {
msg = event.data
document.getElementById("short_msg").innerHTML =
event.data;
}

3. クライアントは、アプリケーションの必要に応じて、WebSocketオブジェクトを介してサーバーにメッセージを送信します。

function sendMsg() {
// Check if connection is open before sending
if(ws == null || ws.readyState != 1) {
document.getElementById("reason").innerHTML
= "Not connected can't send msg"
} else {
ws.send(document.getElementById("name").value);
}
}

<input id="send_button" class="button" type="button" value="send" onclick="sendMsg()"/>

Java WebSocketクライアントの記述

javax.websocketパッケージには、クライアントとサーバーのエンドポイントに共通のアノテーション、クラス、インタフェースおよび例外が含まれています。このパッケージのAPIを使用して、サーバーを記述する場合と同じようにJava WebSocketクライアントを記述します。クライアントの記述に固有の追加のプログラミング・タスクについては、後続の項で説明します。

WebSocketクライアント・エンドポイントのプログラムによる構成

WebLogic Serverには、コンテナでクライアント・エンドポイント・インタフェースを作成する方法を構成するプロパティが用意されています。これらのプロパティがWebLogic Server固有で、JSR 356の仕様に含まれていないことを示すため、それぞれの完全修飾名には接頭辞weblogic.websocketが付いています。

WebLogic Serverは次のプロパティを提供します。

- HTTPプロキシ構成。WebSocketプロトコル(RFC 6455)で定義されているように、WebLogic Serverでは、HTTPプロキシ経由でリモート・サーバーのWebSocketエンドポイントにクライアント接続できます。
HTTPプロキシ構成プロパティを表18-4に示します。

- Secure Sockets Layer (SSL)構成。WebLogic Serverでは、wssスキームを使用してSSL経由でリモート・サーバーのWebSocketエンドポイントにクライアント接続できます。
SSL構成プロパティを表18-5に示します。

- 受信メッセージのバッファ・サイズ。WebLogic Serverでは、WebSocketクライアント・エンドポイントの受信メッセージのサイズを制限できます。
バッファ・サイズ構成プロパティを表18-6に示します。

表18-4 Java WebSocketクライアントのHTTPプロキシ構成プロパティ

プロパティ

タイプ

説明

weblogic.websocket.client.PROXY_HOST

String

HTTPプロキシ・ホストの名前。JavaScriptクライアントのプロキシ設定を構成する場合は、このプロパティを指定する必要があります。

weblogic.websocket.client.PROXY_PORT

Integer

オプション。HTTPプロキシ・ホストへの接続に使用するポート番号。ポート番号なしでHTTPプロキシ・ホストを指定する場合、ポート番号はデフォルトの80になります。

weblogic.websocket.client.PROXY_USERNAME

String

オプション。プロキシ・ホストにログインするためのユーザー名。

weblogic.websocket.client.PROXY_PASSWORD

String

オプション。プロキシ・ホストにログインするためのユーザー名。

表18-5 Java WebSocketクライアントのSSL構成プロパティ

プロパティ

タイプ

説明

weblogic.websocket.client.SSL_PROTOCOLS

String

オプション。サポートされているSSLプロトコル・バージョンのカンマ区切りリスト。

weblogic.websocket.client.SSL_TRUSTSTORE

String

オプション。キーストア・ファイル(SSL暗号化で使用するセキュリティ証明書を格納)へのパス。

weblogic.websocket.client.SSL_TRUSTSTORE_PWD

String

オプション。キーストアのパスワード。

表18-6 Java WebSocketクライアントのバッファ・サイズ構成プロパティ

プロパティ

タイプ

説明

weblogic.websocket.tyrus.incoming-buffer-size

Integer

メッセージ受信用の内部の最大バッファ・サイズ(バイト)。クライアントは、このサイズを超えるメッセージを処理できません。

このプロパティが設定されている場合は、表18-3に表示された同じ名前のコンテキスト初期化プロパティの値がオーバーライドされます。

デフォルトのバッファ・サイズは4194315 (ペイロードに4MB、フレームのオーバーヘッドに11バイト)です。

注意:

クライアント・エンドポイントは、クライアントをサーバー・エンドポイントに接続する前に構成してください。

プログラムを使用してWebSocketクライアント・エンドポイントを構成する手順:

1. javax.websocket.ClientEndpointConfigオブジェクトを取得します。

a. javax.websocket.ClientEndpointConfig.Builder.create静的メソッドを呼び出して、ClientEndpointConfig.Builderクラスのインスタンスを取得します。

b. 前の手順で取得したClientEndpointConfig.Builderオブジェクト上で、buildメソッドを呼び出します。

2. 変更する各構成プロパティを新しい値に設定します。

a. 前の手順で取得したClientEndpointConfigオブジェクト上でgetUserPropertiesメソッドを呼び出し、ユーザー・プロパティが格納された変更可能なjava.util.Mapオブジェクトを取得します。

b. 前の手順で取得したMapオブジェクト上で、putメソッドを呼び出します。
putメソッドの呼出しでは、プロパティ名とその新しい値をパラメータとしてメソッドに提供します。

例18-28は、プログラムを使用してWebSocketクライアント・エンドポイントを構成する方法を示しています。

例18-28 WebSocketクライアント・エンドポイントのプログラムによる構成

この例では、プログラムを使用してWebSocketクライアント・エンドポイントを次のように構成します。

- HTTPプロキシ・ホスト名をproxy.example.comに設定します。

- HTTPプロキシ・ホストへの接続に使用するポート番号を80に設定します。

- キーストア・ファイルへのパスを/export/keystoreに設定します。

- キーストアのパスワードをchangeitに設定します。

- メッセージ受信用の内部の最大バッファ・サイズを16777227バイト(ペイロードに16MB、フレームのオーバーヘッドに11バイト)に設定します。

...
import javax.websocket.ClientEndpointConfig;
...
ClientEndpointConfig cec = ClientEndpointConfig.Builder.create().build();
// configure the proxy host
cec.getUserProperties().put("weblogic.websocket.client.PROXY_HOST",
"proxy.example.com");
// configure the proxy port
cec.getUserProperties().put("weblogic.websocket.client.PROXY_PORT", 80);
// configure the trust keystore path
cec.getUserProperties().put("weblogic.websocket.client.SSL_TRUSTSTORE",
"/export/keystore");
// configure the trust keystore's password
cec.getUserProperties().put("weblogic.websocket.client.SSL_TRUSTSTORE_PWD",
"changeit");
// for receiving 16 Mbyte payload
cec.getUserProperties().put("weblogic.websocket.tyrus.incoming-buffer-size",
16 * 1024 * 1024 + 11);
...

Java WebSocketクライアントのサーバー・エンドポイントへの接続

Java WebSocketクライアントをサーバー・エンドポイントに接続する手順:

1. javax.websocket.ContainerProvider.getWebSocketContainer()静的メソッドを呼び出して、クライアントのjavax.websocket.WebSocketContainerインスタンスを取得します。

2. 前の手順で取得したWebSocketContainerオブジェクト上で、オーバーロードしたconnectToServerメソッドを呼び出します。

メソッドを呼び出す際の変数は、エンドポイントがアノテーション付きエンドポイントかプログラム的なエンドポイントかによって、またJava EEサービス(依存性の注入など)のサポートが必要かによって異なります。

エンドポイントのタイプ

Java EEサービスのサポート

connectToServerメソッドの変数

アノテーション付き

オプション

connectToServer(Object annotatedEndpointInstance,
URI path)

アノテーション付き

必須

connectToServer(Class<?> annotatedEndpointClass,
URI path)

プログラム的

オプション

connectToServer(Endpoint endpointInstance,
ClientEndpointConfig cec,
URI path)

プログラム的

必須

connectToServer(Class<? extends Endpoint> endpointClass,
ClientEndpointConfig cec,
URI path)

connectToServerメソッドの呼出しでは、次の情報をパラメータとしてメソッドに提供します。

- クライアントのWebSocketエンドポイント

- サーバーのWebSocketエンドポイントへの完全パス

クライアント・エンドポイントがプログラム的なエンドポイントの場合は、エンドポイントの構成情報も提供する必要があります。

例18-29は、Java WebSocketクライアントをサーバー・エンドポイントに接続する方法を示しています。

例18-29 Java WebSocketクライアントのサーバー・エンドポイントへの接続

この例では、Java WebSocketクライアントClientExampleをWebSocketサーバー・エンドポイント(ws://example.com:80/echoserver/echo)に接続します。WebSocketクライアント・エンドポイントはクラスExampleEndpointで表現されます。ExampleEndpointクラスの宣言を**INTERNAL XREF ERROR**に示します。

import java.io.IOException;
import java.net.URI;

import javax.websocket.CloseReason;
import javax.websocket.ContainerProvider;
import javax.websocket.Session;
import javax.websocket.WebSocketContainer;
...

public class ClientExample {

public static void main(String[] args) throws Exception {
WebSocketContainer container = ContainerProvider.getWebSocketContainer();
Session session = container.connectToServer(ExampleEndpoint.class,
new URI("ws://example.com:80/echoserver/echo"));
...
session.close();
}

WebSocketクライアントからメッセージをディスパッチするためのスレッドの最大数の設定

デフォルトで、WebSocketクライアントからメッセージをディスパッチするための最大スレッド数は、使用可能なプロセッサの数によって異なります。

- 使用可能なプロセッサ数が20以下の場合、最大スレッド数は20です。

- 使用可能なプロセッサ数が20を超える場合、最大スレッド数は使用可能なプロセッサ数と同数です。

WebSocketクライアントからメッセージをディスパッチするための最大スレッド数を設定する手順:

1. クライアント・アプリケーションを起動するjavaコマンドで、システム・プロパティweblogic.websocket.client.max-aio-threadsを必要な数に設定します。

例18-30は、WebSocketクライアントからメッセージをディスパッチするための最大スレッド数を設定する方法を示しています。

例18-30 WebSocketクライアントからメッセージをディスパッチするための最大スレッド数の設定

この例では、WebSocketクライアントClientExampleからメッセージをディスパッチするための最大スレッド数を50に設定します。

java -Dweblogic.websocket.client.max-aio-threads=50 ClientExample

WebSocketアプリケーションの保護

WebLogic Serverでは、Webアプリケーション・アーカイブ(WAR)の一部としてWebSocketアプリケーションをデプロイします。これは、スタンドアロンのWebアプリケーションまたはエンタープライズ・アプリケーション内のWARモジュールのいずれかとして行います。したがって、Webアプリケーションの保護に適用する多くのセキュリティ上の措置を、WebSocketアプリケーションに適用することができます。Webアプリケーションのセキュリティの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のセキュアなWebアプリケーションの開発に関する項を参照してください。

次の項では、WebLogic ServerにおけるWebSocketアプリケーションのセキュリティに関する考慮事項について説明します。

- 検証済の生成元ポリシーの適用

- WebSocketクライアントの認証と認可

- セキュアなWebSocket接続の確立

- 複合コンテンツの回避

検証済の生成元ポリシーの適用

最新のブラウザでは、ある生成元からロードされたWebページ上で実行されているスクリプトが、別の生成元のリソースとやりとりしないようにするために、同一生成元ポリシーが使用されています。WebSocketプロトコル(RFC 6455)では、サーバーが生成元横断接続に同意するかどうかを決定できる、検証済の生成元ポリシーが使用されています。

スクリプトがWebSocketアプリケーションにオープニング・ハンドシェイク・リクエストを送信すると、WebSocketハンドシェイク・リクエストを使用してOrigin HTTPヘッダーが送信されます。アプリケーションは、Originを検証しない場合、すべての生成元からの接続を受けれ入れます。予想される生成元以外の生成元からの接続を受け入れないようにアプリケーションを設定すると、WebSocketアプリケーションは、接続を拒否することができます。

javax.websocket.server.ServerEndpointConfig.Configuratorクラスを拡張することにより、WebSocketアプリケーションでOriginが確実に検証されるようにできます。

次のコード・サンプルは、検証済の生成元ポリシーを適用する方法を示しています。

...
import javax.websocket.server.ServerEndpointConfig;

public class MyConfigurator extends ServerEndpointConfig.Configurator {
...
private static final String ORIGIN = "http://www.example.com:7001";

@Override
public boolean checkOrigin(String originHeaderValue) {
return ORIGIN.equals(originHeaderValue)
}
}
...

詳細は、「サーバー・エンドポイントのプログラムによる構成」を参照してください。

注意:

ブラウザ以外のクライアント(Javaクライアントなど)では、WebSocketハンドシェイク・リクエストを使用してOrigin HTTPヘッダーを送信する必要はありません。WebSocketハンドシェイク・リクエストにOriginヘッダーが含まれない場合、リクエストはブラウザ以外のクライアントからのものであり、ハンドシェイク・リクエストにOriginヘッダーが含まれる場合、ブラウザから、またはブラウザ以外のクライアントからの場合があります。

ブラウザ以外のクライアントが、Originヘッダーを送信するかどうかは不定なため、ブラウザ以外のクライアントには、ブラウザ生成元セキュリティ・モデルは推奨さません。

WebSocketクライアントの認証と認可

WebSocketプロトコル(RFC 6455)では、ハンドシェイク処理時のWebSocketクライアントの認証方法を指定しません。標準のWebコンテナ認証および認可機能を使用すると、未認可のクライアントがサーバー上でWebSocket接続を開かないようにすることができます。

Webアプリケーションでサポートされている<auth-method要素の構成はすべて、WebSocketアプリケーションにも使用できます。これらの認証タイプとして、BASIC、FORM、CLIENT-CERTなどがあげられます。詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のセキュアなWebアプリケーションの開発に関する項を参照してください。

WebSocketアプリケーションのweb.xmlデプロイメント記述子ファイルで該当する<security-constraint要素を構成することにより、アプリケーション内のエンドポイントへのパスをセキュリティで保護することができます。クライアントは、<security-constraintを構成することで、WebSocketハンドシェイク・リクエストを送信する前に認証する必要があります。そうしない場合、サーバーはWebSocketハンドシェイク・リクエストを拒否します。<security-constraint要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweb.xmlデプロイメント記述子要素に関する項を参照してください。

次のコード・サンプルは、アプリケーション内のエンドポイントへのパスをセキュリティで保護する方法を示しています(ここで、パスは/demoです)。

<security-constraint>
<web-resource-collection>
<web-resource-name>Secured WebSocket Endpoint</web-resource-name>
<url-pattern>/demo</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>user</role-name>
</security-role>

WebSocketクライアントの認証

BASICおよびDIGEST認証方式を実装し、javax.websocket.ClientEndpointConfig.Configuratorクラスを使用してハンドシェイクのメッセージ・ヘッダーを操作することにより特定のクライアントを許可するように、WebSocketアプリケーションを構成できます。クライアントがWebSocket接続を作成することをアプリケーションが認可しない場合、サーバーはそのクライアントからのWebSocketハンドシェイク・リクエストを拒否します。

ハンドシェイクのオープン時にクライアントから渡されたOriginヘッダーの値をチェックするには、javax.websocket.server.ServerEndpointConfig.ConfiguratorクラスのcheckOriginメソッドを使用します。カスタム・チェックを使用する場合は、このメソッドをオーバーライドできます。詳細は、「サーバー・エンドポイントのプログラムによる構成」を参照してください。

認証用のJSR356コード・サンプルが必要です。

セキュアなWebSocket接続の確立

WebSocket接続を確立するために、クライアントはハンドシェイク・リクエストをサーバーに送信します。wsスキームを使用してWebSocket接続を開く場合、ハンドシェイク・リクエストはプレーンHTTPリクエストになります。確立されたWebSocket接続を介して転送されるデータは暗号化されません。

セキュアなWebSocket接続を確立し、データがインターセプトされないようにするには、WebSocketアプリケーションが、wssスキームを使用する必要があります。wssスキームを使用すると、クライアントがハンドシェイク・リクエストをHTTPSリクエストとして送信し、転送データがTLS/SSLで暗号化されます。

HTTPSハンドシェイク・リクエストのみを受け入れるようにWebSocketアプリケーションを構成することができます。この場合、すべてのWebSocket接続を暗号化する必要があり、暗号化されていないWebSocketハンドシェイク・リクエストは拒否されます。WebSocketアプリケーションのweb.xmlデプロイメント記述子ファイルで<user-data-constraint要素を指定します。<user-data-constraint要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweb.xmlデプロイメント記述子要素に関する項を参照してください。

次のコード・サンプルは、<user-data-constraint>要素の構成方法を示しています。

<security-constraint>
<web-resource-collection>
<web-resource-name>Secured WebSocket Endpoint</web-resource-name>
<url-pattern>/demo</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

複合コンテンツの回避

スクリプトではws:// URI (プレーンHTTPリクエストを使用)を通してWebSocket接続を開こうとし、一方でトップレベルのWebページがHTTPSリクエストを通して取得される場合、そのWebページは複合コンテンツと呼ばれます。ほとんどのブラウザは複合コンテンツを許可しなくなっていますが、まだ許可しているものもあります。WebSocketアプリケーションでは混合コンテンツを回避する必要があります。なぜなら、これによってJSESSIONIDやCookieなどの保護する必要がある特定の情報の公開が可能になるからです。

混合コンテンツの詳細は、http://www.w3.org/TR/wsc-ui/#securepageのWeb Security Context: User Interface Guidelinesを参照してください。

WebSocket接続に対する制限の指定

WebSocket接続に制限を指定すると、クライアントによってサーバーのリソース(メモリーやソケットなど)が使い果されてしまうことを回避できます。

WebSocket接続には次の制限を指定できます。

- 最大メッセージ・サイズ。WebSocket接続に最大メッセージ・サイズを設定するには、onMessageアノテーションのmaxMessageSize要素をバイト単位のサイズに設定します。

- アイドル・タイムアウト値。WebSocket接続にアイドル・タイムアウト値を設定するには、次のいずれかのメソッドを呼び出します。

- 個別の接続には、SessionオブジェクトのsetMaxIdleTimeoutメソッドを呼び出します。

- コンテナ全体では、WebSocketContainerオブジェクトのsetDefaultMaxSessionIdleTimeoutメソッドを呼び出します。

WebSocketメッセージングのプロトコル・フォールバックの有効化

プロトコル・フォールバックは、WebSocketプロトコルがサポートされていない場合に、WebSocketメッセージングの代替転送方法を使用するためのメカニズムを提供します。通常、WebSocketプロトコルがサポートされない理由は、WebSocketオブジェクトが使用できないためか、WebSocketフレームがファイアウォールによってブロックされているためです。このリリースでサポートされている代替転送方法は、HTTPロング・ポーリングのみです。

プロトコル・フォールバックを使用すると、実行時環境でWebSocketプロトコルがサポートされているかどうかにかかわらず、標準のプログラミングAPIを使用してWebSocketメッセージングを実行できます。

注意:

WebSocketフォールバックをサポートするには、サーバーで固有のWebLogic Server WebSocket APIではなく、JSR 356 Java API for WebSocketを使用する必要があります。

クライアント・アプリケーションでJavaScript API for WebSocketフォールバックを使用する方法

JavaScript API for WebSocketのフォールバックは、標準のW3C WebSocket APIと追加のAPIの実装を提供するので、WebSocketフォールバックが簡単に行えます。JavaScript API for WebSocketのフォールバックの詳細は、『JavaScript API Reference for WebSocket Fallback』を参照してください。W3C WebSocket APIの詳細は、http://www.w3.org/TR/websockets/を参照してください。

標準のW3C WebSocket JavaScript APIを使用する場合は、WebSocketプロトコルがサポートされているかどうか気にせずにアプリケーションのコードを記述できます。

WebSocketフォールバックの構成

WebLogic Serverには、WebSocketフォールバックを構成するプロパティが用意されています(表18-7を参照)。

表18-7 WebSocketフォールバックの構成プロパティ

プロパティ

タイプ

デフォルト

説明

baseUrl

string

.

scriptsディレクトリの場所(ページのHTMLコンテキストからの相対パス)。

scriptsディレクトリの構造は保持する必要があります。作成後、scriptsディレクトリはアクセス可能な場所であればどこに移動しても構いませんが、その内容は変更できません。

debug

integer

0

デバッグ・レベル。

ENCODE_FOR_IE_BELOW

integer

10

Internet Explorerブラウザのバージョンを示し、これよりも古い場合、フレーム・データにはBase16エンコーディングを使用します。

ENFORCE_ENCODING

ブール

いいえ

Base16エンコーディングを使用するかどうかを示します。

NB_TRY_FOR_EACH_TRANSPORT

integer

2

特定の転送方法で接続を確立する最大連続再試行回数。

PING_INTERVAL

integer

25000

サーバーに送信する連続ping間の時間間隔(ミリ秒)。

SERVER_PING_ENABLED

ブール

true

クライアントからサーバーへのping送信が有効かどうか。

transport

string

なし

実行する転送方法(次のいずれかの転送方法):

- WebSocket

- XMLHttpRequest

TRY_AGAIN_INTERVAL

integer

1000

失敗した接続試行を同じ転送方法で再試行するまでの時間間隔(秒)。転送の再試行回数は増加しません。

この時間(ミリ秒)内での接続に失敗すると、再試行回数が1ずつ増加します。

WEBSOCKET_CREATION_TIMEOUT

integer

1000

WebSocket接続の作成が失敗したと判断されるまでの時間(ミリ秒)。

WebSocketプロトコルを使用できる場合は、プロトコル・フォールバックが有効であっても、WebLogic Serverではこのプロトコルが使用されます。WebLogtic Serverでは、接続試行が失敗すると、TRY_AGAIN_INTERVALプロパティおよびNB_TRY_FOR_EACH_TRANSPORTプロパティの値を次のように使用して、WebSocketプロトコルが使用可能かどうかを判断します。

- TRY_AGAIN_INTERVALの時間(ミリ秒)内に接続が確立されない場合は、同じ転送方法で再試行されます。この転送の再試行回数は増加しません。

- TRY_AGAIN_INTERVALの時間(ミリ秒)内での接続に失敗すると、再試行回数が1ずつ増加します。

- 再試行回数がNB_TRY_FOR_EACH_TRANSPORTの値に達すると、次の転送方法が試行されます。

- 最後の転送方法の再試行回数がNB_TRY_FOR_EACH_TRANSPORTの値に達すると、接続が閉じられます(つまり、クライアント上でonclose関数がコールされます)。

WebSocketフォールバックの構成手順:

1. 必要な構成プロパティを設定するJSONオブジェクトを作成します。

これらのプロパティの詳細は、表18-7を参照してください。

2. オブジェクトをパラメータとして次のいずれかの関数に渡します。

- フォールバック・メカニズムがあるかどうか保証できない場合は、WebSocketオブジェクトを作成する前に、オブジェクトをパラメータとしてOraSocket.configure関数に渡します。
WebSocketフォールバックのJavaScriptライブラリが使用できない場合に、アプリケーションが失敗しないようにするには、try/catchブロック内でOraSocket.configure関数をコールします。

- あるいは、オブジェクトをWebSocketオブジェクトのコンストラクタの第2パラメータ(オプション)として渡します。

例18-31は、WebSocketフォールバックの構成方法を示しています。

例18-31 WebSocketフォールバックの構成

この例では、XMLHttpRequest転送を実行して、デバッグ・レベルを10に設定し、クライアントからサーバーへのping送信を無効化します。

...
try {
var config = {};
config = { transport: XMLHttpRequest, debug: 10, SERVER_PING_ENABLED: false };
OraSocket.config(config);
} catch (err) {
console.log("Error creating WebSocket:" + JSON.stringify(err));
}
...

WebSocketオブジェクトの作成

WebSocketオブジェクトは、クライアントからリモート・ホストへのWebSocket接続を表します。

WebSocketオブジェクトを作成するには、WebSocketコンストラクタを呼び出して、次の情報をパラメータとして渡します。

- クライアントの接続先URL

- (オプション) WebSocketフォールバックの構成設定が格納されているJSONオブジェクト
JSONオブジェクトの詳細は、「WebSocketフォールバックの構成」を参照してください。

例18-32は、WebSocketオブジェクトの作成方法を示しています。

表18-32 WebSocketオブジェクトの作成

この例では、WebSocketオブジェクトwsを作成します。例では、JavaScriptの標準関数を使用して、このコードが含まれているドキュメントのURLから、クライアントが接続するURLを判別します。

...
var URI_SUFFIX = "/websocket-101/ws-101-app";
var ws;
var connectionStatus = "Connecting...";
var calledBy = document.location.toString();
var machine, port, secured;
var regExp = new RegExp("(http|ws)(.?):[/]{2}([^/|^:]*):?(\\d*)/(.*)");
var matches = regExp.exec(calledBy);
secured = matches[2];
machine = matches[3];
port    = matches[4];
...
statusFld  = document.getElementById('status');
...
try
{
var wsURI = "ws" + secured + "://" + machine + ":" + port + URI_SUFFIX;
ws = new WebSocket(wsURI);
}
catch (err)
{
var mess = 'WebSocket creation error:' + JSON.stringify(err);
connectionStatus = "<font color='red'>Unable to connect.</font>";
if (statusFld !== undefined)
statusFld.innerHTML = mess;
else
alert(mess);
}
...

JavaScript WebSocketクライアントのライフサイクル・イベントの処理

JavaScript WebSocketクライアントのライフサイクル・イベントの処理では、WebSocketオブジェクトのコールバック関数(表18-8を参照)を記述します。この表には、イベント・タイプ別の処理方法を示した例への相互参照も提供されています。

表18-8 ライフサイクル・イベントを処理するコールバック関数

イベント

コールバック関数

例

Connection opened

onopen

例18-33

Message received

onmessage

例18-34

Error

onerror

例18-35

Connection closed

onclose

例18-36

注意:

この例で使用するws WebSocketオブジェクトの作成方法は、例18-32を参照してください。

例18-33 JavaScript WebSocketクライアントのConnection openedイベントの処理

この例では、JavaScriptの標準関数を使用して、接続が開いたときに現在の日付と時刻、メッセージConnection openedを順に表示します。

...
ws.onopen = function()
{
try
{
var text;
try
{
text = 'Message:';
}
catch (err)
{
text = '<small>Connected</small>';
}
promptFld.innerHTML = text;
if (nbMessReceived === 0)
statusFld.innerHTML = "";
statusFld.innerHTML += ((nbMessReceived === 0?"":"<br>") + "<small>" +
(new Date()).format("d-M-Y H:i:s._ Z") +
"</small>:<font color='blue'>" +
' Connection opened.' + "</font>");
statusFld.scrollTop = statusFld.scrollHeight;
nbMessReceived++;
}
catch (err) {}
};
...

例18-34 JavaScript WebSocketクライアントのMessage receivedイベントの処理

この例では、JavaScriptの標準関数を使用して、メッセージを受信したときに現在の日付と時刻、メッセージの内容を順に表示します。

...
ws.onmessage = function(message) // message/event
{
var json = {};
if (typeof(message.data) === 'string')
{
try
{
json = JSON.parse(message.data);
}
catch (e)
{
console.log(e);
console.log('This doesn\'t look like valid JSON: ' + message.data);
}
}
if (json.type !== undefined && json.type === 'message' &&
typeof(json.appdata.text) === 'string') // it's a single message, text
{
var dt = new Date();
/**
* Add message to the chat window
*/
var existing = contentFld.innerHTML; // Content already there
var toDisplay = "";
try { toDisplay = json.appdata.text; }
catch (err) {}
contentFld.innerHTML = existing +
('At ' +
+ (dt.getHours() < 10 ? '0' + dt.getHours() : dt.getHours()) + ':'
+ (dt.getMinutes() < 10 ? '0' + dt.getMinutes() : dt.getMinutes())
+ ': ' + toDisplay + '<br>');
contentFld.scrollTop = contentFld.scrollHeight;
}
else // Unexpected
{
var payload = {};
}
};
...

例18-35 JavaScript WebSocketクライアントのErrorイベントの処理

この例では、JavaScriptの標準関数を使用して、エラー発生時に現在の日付と時刻、エラー・メッセージを順に表示します。

...
ws.onerror = function(error)
{
if (nbMessReceived === 0)
statusFld.innerHTML = "";
statusFld.innerHTML += ((nbMessReceived === 0?"":"<br>") + "<small>" +
(new Date()).format("d-M-Y H:i:s._ Z") +
"</small>:<font color='red'>" + error.err + "</font>");
statusFld.scrollTop = statusFld.scrollHeight;
nbMessReceived++;
};
...

例18-36 JavaScript WebSocketクライアントのConnection closedイベントの処理

この例では、JavaScriptの標準関数を使用して、接続が閉じたられたときに現在の日付と時刻、メッセージConnection closedを順に表示します。

...
ws.onclose = function()
{
if (nbMessReceived === 0)
statusFld.innerHTML = "";
statusFld.innerHTML += ((nbMessReceived === 0?"":"<br>") + "<small>" +
(new Date()).format("d-M-Y H:i:s._ Z") +
"</small>:<font color='blue'>" + ' Connection closed' +
"</font>");
promptFld.innerHTML = 'Connection closed';
};
...

JavaScript WebSocketクライアントからのメッセージの送信

JavaScript WebSocketクライアントからメッセージを送信する手順:

1. メッセージ送信用の関数を定義します。

2. メッセージ送信用の関数の本文内で、WebSocketオブジェクトのsend関数をコールします。

3. メッセージ送信用に定義した関数をコールします。

次の例では、JavaScript WebSocketクライアントからメッセージを送信する方法を示します。

- 例18-37

- 例18-38

例18-37 メッセージ送信用の関数の定義

この例では、メッセージ送信用の関数sendを定義します。

この例で使用するws WebSocketオブジェクトの作成方法は、例18-32を参照してください。

...
var send = function(mess)
{
ws.send(mess);
};
...

例18-38 メッセージ送信用の関数のコール

この例では、ユーザーが「Send」をクリックするとsend関数がコールされ、テキスト・フィールドの内容が送信されます。

send関数の定義方法は、例18-37を参照してください。

...
<input type="text" id="input" style="border-radius:2px; border:1px solid #ccc;
margin-top:10px; padding:5px; width:400px;"
placeholder="Type your message here"/>
<button onclick="javascript:send(document.getElementById('input').value);">Send</button>
...

WebSocketフォールバックのクライアント・ライブラリのパッケージ化と場所の指定

Webアプリケーションのscriptsディレクトリにorasocket.min.jsファイルをパッケージ化します。

クライアント・アプリケーションに次のscript要素を追加して、orasocket.min.jsの場所を指定します。

<script type="text/javascript" src="scripts/orasocket.min.js"></script>

WebSocketフォールバックの有効化

デフォルトで、WebSocketフォールバックは無効になっています。

WebSocketフォールバックを有効化するには、アプリケーションのデプロイメント記述子ファイルweb.xmlでcom.oracle.tyrus.fallback.enabledコンテキスト・パラメータをtrueに設定します。

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" ...>
...
<context-param>
<description>Enable fallback mechanism</description>
<param-name>com.oracle.tyrus.fallback.enabled</param-name>
<param-value>true</param-value>
</context-param>
</web-app>

非推奨のAPIからJSR 356 Java API for WebSocketへのアプリケーションの移行

WebLogic Server 12.1.3以降、パッケージweblogic.websocketおよびweblogic.websocket.annotationは非推奨となり、将来のリリースでは削除される予定です。これらのパッケージが削除された後は、WebSocketプロトコル経由の接続にこれらのパッケージを使用できなくなります。

使用中のWebSocketアプリケーションとWebLogic Serverの将来のリリースとの互換性を確保するには、非推奨になったパッケージのかわりにJSR 356 Java API for WebSocketを使用してください。

JSR 356 APIと固有のWebLogic Server WebSocket APIとの比較

表18-9は、WebSocketアプリケーション開発タスクの実行で使用する固有のWebLogic Server WebSocket APIと、それに対応するJSR 356 APIを示しています。この表には、アノテーション付きエンドポイント用のJSR 356 APIのみが表示されています。また、タスク別に、JSR 356 APIを使用してタスクを実行するための操作手順への相互参照も提供されています。

表18-9 JSR 356 APIと固有のWebLogic Server WebSocket APIとの比較

タスク

固有のWebLogic Server WebSocket API

JSR 356 API

操作手順

サーバー・エンドポイント・クラスの作成

1. WebSocketListenerインタフェースまたはWebSocketAdapterスーパークラス

2. WebSocketアノテーション

ServerEndpointアノテーション

アノテーション付きエンドポイントの作成

Connection openedイベントの処理

WebSocketListenerオブジェクトのonOpenメソッド

イベントを処理するメソッドのOnOpenアノテーション

Connection openedイベントの処理

Message receivedイベントの処理

WebSocketListenerオブジェクトのオーバーロードしたonMessageメソッドの次のいずれかの変数:

- テキスト・データ・フレームで構成されたメッセージの場合:
onMessage(WebSocketConnection connection, String payload)

- バイナリ・データ・フレームで構成されたメッセージの場合:
onMessage(WebSocketConnection connection, byte[] payload)

イベントを処理するメソッドのOnMessageアノテーション

Message receivedイベントの処理

Errorイベントの処理

WebSocketListenerオブジェクトのonErrorメソッド

イベントを処理するメソッドのOnErrorアノテーション

Errorイベントの処理

Connection closedイベントの処理

WebSocketListenerオブジェクトのonCloseメソッド

イベントを処理するメソッドのOnCloseアノテーション

Connection closedイベントの処理

メッセージの送信

WebSocketConnectionオブジェクトの次のいずれかのメソッド:

- send(String message)

- send(byte[] message)

- sendPing

- sendPong

- stream(boolean last, String fragment)

- stream(boolean last, byte[] fragment, int off, int length)

1. Sessionインタフェース

2. Sessionオブジェクトの次のいずれかのメソッド:
getBasicRemote()

getAsyncRemote()

3. RemoteEndpoint.BasicオブジェクトまたはRemoteEndpoint.Asyncオブジェクトの次のいずれかのメソッド:
sendText

sendBinary

sendPing

sendPong

エンドポイントの単一ピアへのメッセージ送信

エンドポイントに接続しているすべてのピアへのメッセージ送信

1. WebSocketConnectionオブジェクトのgetWebSocketContextメソッド

2. 前のコールで取得したWebSocketContextオブジェクトのgetWebSocketConnectionsメソッド

SessionオブジェクトのgetOpenSessionsメソッド

エンドポイントのすべてのピアへのメッセージ送信

WebSocket接続の最大メッセージ・サイズの設定

WebSocketアノテーションのmaxMessageSize要素

onMessageアノテーションのmaxMessageSize要素

WebSocket接続のアイドル・タイムアウト値の設定

WebSocketアノテーションのtimeout要素

次のうちいずれか:

- 個別の接続の場合: SessionオブジェクトのsetMaxIdleTimeoutメソッド

- コンテナ全体の場合: WebSocketContainerオブジェクトのsetDefaultMaxSessionIdleTimeoutメソッド

WebSocket接続の最大オープン接続数の設定

WebSocketアノテーションのmaxConnections要素

JSR 356 Java API for Websocketではサポート対象外

固有のWebSocketサーバー・エンドポイントで使用するAPIをJSR 356 APIに変換する方法

固有のWebSocketサーバー・エンドポイントで使用するAPIをJSR 356 APIに変換する手順:

1. WebSocketクラスをアノテーション付きサーバー・エンドポイント・クラスに変換します。
WebSocketクラスからアノテーション付きエンドポイント・クラスへの変換は、WebSocketクラスからプログラム的なエンドポイント・クラスへの変換よりも、変更が少なくて済みます。

a. クラス宣言からextends WebSocketAdapter句またはimplements WebSocketListener句を削除して、WebSocketクラスをPOJOクラスに変換します。

b. クラス宣言のweblogic.websocket.annotation.WebSocketアノテーションをjavax.websocket.server.ServerEndpointアノテーションで置き換えます。
詳細は、「アノテーション付きエンドポイントの作成」を参照してください。

注意:

既存のエンドポイントのpathPatterns要素に/*接尾辞が含まれている場合、/*接尾辞と同じ結果が得られるようにコードを書き換える必要があります。詳細は、「パスのパターン文字列の/*接尾辞の置換え」を参照してください。

2. ライフサイクル・イベントを処理する各メソッドの宣言に、そのメソッドの処理対象であるイベントを指定するアノテーションを付けます。
詳細は、「アノテーション付きWebSocketエンドポイントでのライフサイクル・イベントの処理」を参照してください。

3. weblogic.websocket.WebSocketConnectionインタフェースへの各参照を、javax.websocket.Sessionインタフェースへの参照で置き換えます。

4. WebSocketConnectionオブジェクト上の各メソッド呼出しを、Sessionオブジェクト上の対応するメソッドの呼出しで置き換えます。
たとえば、WebSocketConnectionオブジェクトのcloseメソッドは、weblogic.websocket.ClosingMessageオブジェクトをパラメータとして取得します。Sessionオブジェクトのcloseメソッドで、これに対応するパラメータはjavax.websocket.CloseReasonオブジェクトです。

5. メッセージを送信するためには、Sessionオブジェクト上の各メソッドの呼出しを次のように変更します。

a. getBasicRemoteメソッドまたはgetAsyncRemoteメソッドの呼出しを追加して、このエンドポイントのピアを表すオブジェクトへの参照を取得します。

b. 非推奨になったAPIのメッセージ送信用のメソッドを、JSR 356 API.の対応するメソッドで置き換えます。
JSR 356 APIのメソッドは、前の手順で参照を取得したjavax.websocket.RemoteEndpoint.Basicオブジェクトまたはjavax.websocket.RemoteEndpoint.Asyncオブジェクトのメソッドです。

詳細は、「メッセージの送信」を参照してください。

非推奨のAPIのメソッド

RemoteEndpoint.Basicのメソッド

RemoteEndpoint.Asyncのメソッド

send(String message)

sendText(String text)

次のいずれかのメソッド:

sendText(String text)

sendText(String text,
SendHandler handler)

send(byte[] message)

sendBinary(ByteBuffer data)

次のいずれかのメソッド:

sendBinary(ByteBuffer data)

sendBinary(ByteBuffer data,
SendHandler handler)

sendPing(byte[] message)

sendPing(ByteBuffer applicationData)

sendPing(ByteBuffer applicationData)

sendPong(byte[] message)

sendPong(ByteBuffer applicationData)

sendPong(ByteBuffer applicationData)

stream(boolean last,
String fragment)

sendText(String partialMessage,
boolean isLast)

対応するメソッドはありません。

stream(boolean last,
byte[] fragment,
int off,
int length)

sendBinary(ByteBuffer partialByte,
boolean isLast)

対応するメソッドはありません。

6. import句で、非推奨になったAPIのクラスに対する参照を、エンドポイントで使用しているJSR 356 APIのクラスに対する参照で置き換えます。

7. サーバー・エンドポイントを使用するアプリケーションを再コンパイルして再デプロイします。

パスのパターン文字列の/*接尾辞の置換え

非推奨になったAPIのWebSocketアノテーションのpathPatterns要素では、パスのパターン文字列で/*接尾辞を使用できます。/*接尾辞を使用すると、/*接尾辞の前に記述されたパス・パターンで始まるすべてのリソース・パスとパス・パターンが照合されます。たとえば、リソース・パス/ws/chatは、パス・パターン/ws/*に一致します。

JSR 356 APIには、/*接尾辞に相当する機能はありません。既存のエンドポイントで/*接尾辞が使用されている場合、/*接尾辞と同じ結果が得られるようにコードを書き換える必要があります。コードの書換え方法は、/*接尾辞がエンドポイントURIの変数パス・パラメータを表しているのか、エンドポイントの追加データを表しているのかによって異なります。

エンドポイントURIの変数パス・パラメータを表す/*接尾辞の置換え

パスのパターン文字列の/*接尾辞は、エンドポイントURIの1つ以上の変数パス・パラメータを表している場合があります。このような場合は、/*接尾辞のかわりにURIテンプレートを使用します。

JSR 356 APIではレベル1のURIテンプレートのみをサポートし、そこではパス・パラメータはスラッシュ(/)で明確に区切られます。したがって、URIテンプレートでは、既存のエンドポイントの/*接尾辞にかわる変数パス・パラメータごとに1つの拡張変数を定義する必要があります。

たとえば、既存のエンドポイントの/*接尾辞を1つの変数パス・パラメータで置き換える場合は、次の例で示すようにURIテンプレートを定義します。

/ws/{param1}

URI /ws/testは、前の例のテンプレートに一致します。param1変数はtestに拡張されます。

同様に、既存のエンドポイントの/*接尾辞を2つの変数パス・パラメータで置き換える場合は、次の例で示すようにURIテンプレートを定義します。

/ws/{param1}/{param2}

URI /ws/test/chatは、前の例のテンプレートに一致します。param1変数はtestに、param2変数はchatにそれぞれ拡張されます。

詳細は、「エンドポイント・デプロイメントURIの一部をアプリケーション・パラメータとして指定する方法」を参照してください。

エンドポイントの追加データを表す/*接尾辞の置換え

パスのパターン文字列の/*接尾辞は、URIの一部として転送される、エンドポイントの追加情報を表している場合があります。このような場合は、/*接尾辞のかわりに問合せパラメータを使用します。

JSR 356の仕様では、問合せパラメータの使用が禁止されたり制限されることはありません。したがって、次の条件を満たせば、問合せパラメータを使用して任意のデータを転送できます。

- URLの長さが最大許容長より短いこと。

- すべてのデータが適切にエンコードされていること。

エンドポイントの問合せパラメータを取得するには、必要な形式でパラメータを取得できる、エンドポイントのSessionオブジェクトのメソッドを呼び出します。

- 問合せ全体が含まれている単一の文字列としてパラメータを取得するには、getQueryStringメソッドを呼び出します。例18-39を参照してください。

- 問合せパラメータのリストが含まれているマップとしてパラメータを取得するには、getRequestParameterMapメソッドを呼び出します。例18-40を参照してください。

例18-39 問合せパラメータを単一の文字列として取得する方法

この例では、リクエストURI /echo?foo=bar,baz,mane,padme,humの問合せパラメータをアプリケーション出力"# foo=bar,baz,mane,padme,hum"として取得します。

import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
...
@ServerEndpoint("/echo")
public class EchoEndpoint {

@OnOpen
public void onOpen(Session session) throws IOException {
System.out.println("# " + session.getQueryString());
}

// ...
}

例18-40 問合せパラメータをマップとして取得する方法

この例では、リクエストURI /echo?foo=bar&foo=baz&foo=mane&foo=padme&foo=humの問合せパラメータをList<String> # [bar, baz, mane, padme, hum]として取得します。

import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.HandshakeRequest;
import javax.websocket.server.ServerEndpoint;
import java.util.List;
import java.util.Map;
...
@ServerEndpoint("/echo")
public class EchoEndpoint {

@OnOpen
public void onOpen(Session session) throws IOException {
System.out.println("# " + session.getRequestParameterMap().get("foo"));
}

// ...
}

固有のWebSocketサーバー・エンドポイントで使用するAPIをJSR 356 APIに変換する例

例18-41は、固有のWebSocketサーバー・エンドポイントで使用するAPIを、非推奨になったAPIからJSR 356 APIに変換する方法を示しています。

例18-41 WebSocketサーバー・エンドポイントで使用するAPIをJSR 356 APIに変換する方法

この例では、WebSocketサーバー・エンドポイントで使用するAPIを、非推奨になったAPIからJSR 356 APIに変換する場合に必要な変更を示します。

この例では、非推奨になったコードの行は//コメント文字を使用してコメント・アウトされています。JSR 356 APIのコード行は、コメント//JSR 356で示しています。

package examples.webapp.html5.websocket;

//import weblogic.websocket.ClosingMessage;       Deprecated
//import weblogic.websocket.WebSocketAdapter;     Deprecated
//import weblogic.websocket.WebSocketConnection;  Deprecated
//import weblogic.websocket.annotation.WebSocket; Deprecated

import javax.websocket.CloseReason;              //JSR 356
import javax.websocket.OnMessage;                //JSR 356
import javax.websocket.Session;                  //JSR 356
import javax.websocket.server.ServerEndpoint;    //JSR 356

import java.io.IOException;

//@WebSocket(  Deprecated
//  timeout = -1,  Deprecated
//  pathPatterns = {"/ws"}   Deprecated
//)
@ServerEndpoint("/ws") //JSR 356
//public class MessageListener extends WebSocketAdapter {  Deprecated
public class MessageListener {
//@Override  Not required. Replaced by @OnMessage in a POJO class
@OnMessage //JSR 356
//public void onMessage(WebSocketConnection connection, String payload) { Deprecated
public void onMessage(Session connection, String payload) //JSR 356
throws IOException {                                     //JSR 356
// Sends message from the browser back to the client.
String msgContent = "Message \"" + payload + "\" has been received by server.";
try {
//    connection.send(msgContent); Deprecated
connection.getBasicRemote().sendText(msgContent); //JSR 356
} catch (IOException e) {
//    connection.close(ClosingMessage.SC_GOING_AWAY); Deprecated
connection.close(new                                             //JSR 356
CloseReason(CloseReason.CloseCodes.GOING_AWAY, "Going away.")); //JSR 356
}
}
}

WebLogic ServerでのJava API for WebSocketの使用例

例18-42では、WebLogic ServerでJava API for WebSocketを使用します。この例では、ユーザーがクライアントから送信したテキストを、サーバー・エンドポイントでエコーします。ユーザーがテキスト・メッセージを送信すると、サーバーはそのメッセージにテキスト(from your server)を追加してユーザーにメッセージを返信します。

例18-42 WebLogic ServerでのJava API for WebSocketの使用方法

package com.example.websocket.sample.echo;

import java.io.IOException;

import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/echo")
public class EchoEndpoint {

@OnOpen
public void onOpen(Session session) throws IOException {
session.getBasicRemote().sendText("onOpen is invoked.");
}

@OnMessage
public String echo(String message) {
return message + " (from server)";
}

@OnError
public void onError(Throwable t) {
t.printStackTrace();
}

}

A エンタープライズ・アプリケーションのデプロイメント記述子の要素

この付録では、エンタープライズ・アプリケーション・デプロイメント記述子application.xml (Java EE標準デプロイメント記述子)およびweblogic-application.xml (WebLogic固有のアプリケーション・デプロイメント記述子)について説明します。

Java EEアノテーションの使用により、標準のapplication.xmlデプロイメント記述子は省略可能になりました。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子にかわるものです。Java EEアノテーションと依存関係インジェクションの使用を参照してください。

weblogic-application.xmlファイルも、WebLogic Serverの拡張機能を使用していない場合は省略可能です。

この付録の内容は次のとおりです。

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

- weblogic-application.xmlスキーマ

- application.xmlスキーマ

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

次の項では、「weblogic-application.xmlスキーマ」で定義されている様々な要素について説明します。weblogic-application.xmlファイルは、application.xml Java EEデプロイメント記述子を拡張したWebLogic Server固有のデプロイメント記述子です。ここでは、アプリケーションで参照される共有Java EEライブラリやEJBキャッシングなどの機能を構成します。

ファイルは、アプリケーション・アーカイブのMETA-INFサブディレクトリにあります。次の項では、ファイル内に表示される要素について説明します。

weblogic-application

weblogic-application要素は、アプリケーションのデプロイメント記述子のルート要素です。

次の表では、weblogic-application要素内で定義できる要素について説明します。

表A-1 weblogic-application要素

要素

必須?

ファイル内での最大数

説明

<ejb>

オプション

1

WebLogicアプリケーションの構成要素となるEJBモジュールに固有の情報が含まれます。現在、ejb要素では、アプリケーションのエンティティBeanによって使用される任意の数のアプリケーション・レベル・キャッシュを指定できます。

ejb要素内で定義できる要素の詳細は、「ejb」を参照してください。

<xml>

オプション

1

対象アプリケーションに固有なXML処理のパーサーおよびエンティティ・マッピングに関する情報を指定します。

xml要素内で定義できる要素の詳細は、「xml」を参照してください。

<jdbc-connection-pool>

オプション

制限なし

ゼロまたはそれ以上。アプリケーション・スコープのJDBC接続プールを指定します。

jdbc-connection-pool要素内で定義できる要素の詳細は、「jdbc-connection-pool」を参照してください。

<security>

オプション

1

アプリケーションのセキュリティ情報を指定します。

security要素内で定義できる要素の詳細は、「security」を参照してください。

<application-param>

オプション

制限なし

ゼロまたはそれ以上。アプリケーションに関連のあるコンテナ・インスタンスの動作に影響を与える、入力されないパラメータの指定に使用します。ここに示すパラメータが、現在サポートされています。また、weblogic-application.xml内のこれらのパラメータでは、リクエストおよびレスポンスに使用するデフォルトのエンコーディングを決定できます。

- webapp.encoding.default - JDKでサポートされるエンコーディングを表す文字列に設定できます。設定すると、これによりサーブレットのリクエストとレスポンスの処理に使用されるデフォルトのエンコーディングが定義されます。この設定は、webapp.encoding.usevmdefaultがtrueに設定されている場合には無視されます。この値はまた、リクエスト・ストリームについてはweblogic.xmlのinput-charset要素によってオーバーライドされます。

- webapp.encoding.usevmdefault - trueにもfalseにも設定できます。trueであれば、デフォルト・エンコーディングの定義にはシステム・プロパティfile.encodingが使用されます。

次のパラメータを使用すると、このアプリケーションに含まれるWebアプリケーションの動作に影響を与えます。

- webapp.getrealpath.accept_context_path - trueにもfalseにも設定可能な、互換性スイッチ。trueに設定すると、サーブレットAPI getrealpathに対する呼出しにおいて、Webアプリケーションのコンテキスト・パスの使用が許可されます。

例:

<application-param>
<param-name>webapp.encoding.default
</param-name>
<param-value>UTF8</param-value>
</application-param>

application-paramの要素内で定義できる要素の詳細は、「application-param」を参照してください。

<classloader-structure>

オプション

制限なし

classloader-structure要素を使うと、このアプリケーションのクラスローダーの構成を定義できます。宣言は、クラスローダーの階層を表し、特定のモジュールを特定のノードに関連付ける、ツリー構造で表現されます。モジュールのクラスは、この要素と関連付けられたクラスローダーによってロードされます。

例:

<classloader-structure>

<module-ref>

<module-uri>ejb1.jar</module-uri>

</module-ref>

</classloader-structure>

<classloader-structure>

<module-ref>

<module-uri>ejb2.jar</module-uri>

</module-ref>

</classloader-structure>

classloader-structure要素内で定義できる要素の詳細は、「classloader-structure」を参照してください。

<listener>

オプション

制限なし

ゼロまたはそれ以上。ユーザー定義のアプリケーション・ライフサイクル・リスナーの登録に使用します。これらは、抽象ベース・クラスweblogic.application.ApplicationLifecycleListenerを拡張するクラスです。

listener要素内で定義できる要素の詳細は、「listener」を参照してください。

<singleton-service>

オプション

制限なし

ゼロまたはそれ以上。ユーザー定義のsingleton servicesの登録に使用します。これらは、インタフェースweblogic.cluster.singleton.SingletonServiceを実装するクラスです。

singleton-service要素内で定義できる要素の詳細は、「singleton-service」を参照してください。

<startup>

オプション

制限なし

ゼロまたはそれ以上。ユーザー定義の起動クラスの登録に使用します。

startup要素内で定義できる要素の詳細は、「startup」を参照してください。

注意: アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、アプリケーション・ライフサイクル・イベントのプログラミングを参照してください。

<shutdown>

オプション

制限なし

ゼロまたはそれ以上。ユーザー定義の停止クラスの登録に使用します。

shutdown要素内で定義できる要素の詳細は、「shutdown」を参照してください。

注意: アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、アプリケーション・ライフサイクル・イベントのプログラミングを参照してください。

<module>

オプション

制限なし

JMSまたはJDBCモジュールなど、単独のWebLogicアプリケーション・モジュールを表します。

この要素には次の子要素があります。

- name - モジュールの名前。

- type - モジュールの種類。有効な値は、JMS、JDBC、InterceptionまたはGARです。

- path - モジュールを完全に記述するXMLファイルのパス。エンタープライズ・アプリケーションのルートを基準にした相対パスで指定します。

次の例では、XMLファイルjms/Workflows-jms.xmlで完全に記述されたWorkflowsというJMSモジュールの指定方法を示します。

<module>
<name>Workflows</name>
<type>JMS</type>
<path>jms/Workflows-jms.xml</path>
</module>

<library-ref>

オプション

制限なし

共有Java EEライブラリへの参照してください。

library要素内で定義できる要素の詳細は、「library」を参照してください。

<fair-share-request>

オプション

制限なし

ワーク・マネージャ・リクエスト・クラスの一種であるフェア・シェア・リクエスト・クラスを指定します。フェア・シェア・リクエスト・クラスは、リクエストの処理に必要なスレッド使用時間の平均比率を指定します。

<fair-share-request>要素は、次の子要素を取ることができます。

- name - フェア・シェア・リクエスト・クラスの名前。

- fair-share - スレッド使用時間の平均比率を表す整数値。

ワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

<response-time-request>

オプション

制限なし

ワーク・マネージャ・クラスの一種であるレスポンス時間リクエスト・クラスを指定します。具体的には、レスポンス時間リクエスト・クラスは、レスポンス時間の目標値(ミリ秒)を指定します。

<response-time-request>要素は、次の子要素を取ることができます。

- name - レスポンス時間リクエスト・クラスの名前。

- goal-ms - レスポンス時間の目標値を示す整数。

ワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

<context-request>

オプション

制限なし

ワーク・マネージャ・クラスの一種であるコンテキスト・リクエスト・クラスを指定します。コンテキスト・リクエスト・クラスは、現在のユーザーまたは現在のユーザーのグループなどのコンテキスト情報を基に、リクエスト・クラスをリクエストに割り当てます。

<context-request>要素は、次の子要素を取ることができます。

- name - コンテキスト・リクエスト・クラスの名前。

- context-case - コンテキストを記述する要素。

<context-case>要素は、それ自身で次の子要素を取ることができます。

- user-nameまたはgroup-name - コンテキストが適用されるユーザーまたはグループ。

- request-class-name - リクエスト・クラスの名前。

ワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

<max-threads-constraint>

オプション

制限なし

ワーク・マネージャ制約max-threads-constraintを指定します。ワーク・マネージャ制約は、リクエストの実行用に割り当てられるスレッドの最大数と最小数、およびWebLogic Serverがリクエストを拒否するまでにキューまたは実行できるリクエストの合計数を定義します。

max-threads-constraintは、制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。

<max-threads-constraint>要素は、次の子要素を取ることができます。

- name - max-thread-constraintの名前。

- countまたはpool-name - 同時スレッドの最大数を示す整数、または最大数を決める接続プールの名前。

ワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

<min-threads-constraint>

オプション

制限なし

ワーク・マネージャ制約min-threads-constraintを指定します。ワーク・マネージャ制約は、リクエストの実行用に割り当てられるスレッドの最大数と最小数、およびWebLogic Serverがリクエストを拒否するまでにキューまたは実行できるリクエストの合計数を定義します。

min-threads-constraintは、デッドロックを回避するために、制約対象のリクエストに割り当てられるスレッドの数を保証します。

<min-threads-constraint>要素は、次の子要素を取ることができます。

- name - min-thread-constraintの名前。

- count - スレッドの最小数を示す整数。

ワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

<capacity>

オプション

制限なし

ワーク・マネージャ制約capacityを指定します。ワーク・マネージャ制約は、リクエストの実行用に割り当てられるスレッドの最大数と最小数、およびWebLogic Serverがリクエストを拒否するまでにキューまたは実行できるリクエストの合計数を定義します。

capacity制約を指定すると、サーバーの容量制限に達した場合にのみリクエストが拒否されるようになります。

<capacity>要素は、次の子要素を取ることができます。

- name - capacity制約の名前。

- count - スレッドの容量を示す整数。

ワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

<work-manager>

オプション

制限なし

アプリケーションに関連付けられたワーク・マネージャを指定します。

work-manager要素内で定義できる要素の詳細は、「work-manager」を参照してください。

ワーク・マネージャの詳細は、「ワーク・マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

<application-admin-mode-trigger>

オプション

制限なし

アプリケーションを管理モードにするために必要なスタック・スレッドの数を指定します。

次の子要素を指定できます。

- max-stuck-thread-time - スレッドがスタック内に残る最大時間(秒)。

- stuck-thread-count - スタック・スレッド・ワーク・マネージャをトリガーするスタック・スレッドの数。

<session-descriptor>

オプション

制限なし

サーブレット・セッションの構成パラメータのリストを指定します。

<session-descriptor>要素内で定義できる要素の詳細は、「session-descriptor」を参照してください。

<library-context-root-override>

オプション

制限なし

ゼロまたはそれ以上。アプリケーションで参照されるライブラリのデプロイメント記述子に指定されているWebモジュールのコンテキスト・ルートのオーバーライドに使用されます。

<library-context-root-override>要素内で定義できる要素の詳細は、「library-context-root-override」を参照してください。

<component-factory-class-name>

オプション

1

この要素をorg.springframework.jee.interfaces.SpringComponentFactoryに設定して、Spring拡張機能を有効にします。この要素は、EJB、Web、およびアプリケーション記述子に含まれます。アプリケーション・レベルの記述子は、モジュール・レベルの記述子によって上書きされます。null (デフォルト)に設定すると、Spring拡張機能は無効になります。

<prefer-application-packages>

オプション

1

ClassLoader構成をフィルタするために使用されます。アプリケーションからロードするクラスのパッケージ・リストを指定します。

<prefer-application-resources>

オプション

1

ClassLoader構成をフィルタするために使用されます。リソースがシステム・クラスローダーにある場合でも、いつもアプリケーションからロードする必要があるリソースのリストを指定します。

リソース・ローディング動作は、<prefer-application-packages>を使用したリソース・ローディング動作と異なることに注意してください。

この場合、アプリケーション・リソースがシステム・リソースより優先されます。この要素に記録されたリソースはシステム・クラスローダーでルックアップされることはありません。

<fast-swap>

オプション

1

Fastswapデプロイメントを使用するかどうかを指定します - 使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスが再定義されるため、再デプロイメントを最小限に抑えることができます。

詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

<fast-swap>要素内で定義できる要素の詳細は、「fast-swap」を参照してください。

ejb

次の表では、ejb要素内で定義できる要素について説明します。

表A-2 ejb要素

要素

必須?

ファイル内での最大数

説明

<entity-cache>

オプション

制限なし

ゼロまたはそれ以上。entity-cache要素は、実行時にエンティティEJBインスタンスをキャッシュに入れるときに使用される名前付きアプリケーション・レベル・キャッシュの定義に使用されます。個々のエンティティBeanは、使用するアプリケーション・レベル・キャッシュのキャッシュ名を参照します。個々のキャッシュを参照するエンティティBeanの数に制限はありません。

アプリケーション・レベル・キャッシュを使用するには、weblogic-ejb-jar.xml記述子の<entity-cache-ref要素を使用してキャッシュを指定する必要があります。その場合、Exclusivecacheおよびmultiversioncacheという2つのデフォルト・キャッシュが使用されます。アプリケーションの設定で、これらのデフォルト・キャッシュを明示的に定義して、非デフォルト値を指定する場合もあります。キャッシング戦略では、デフォルト・キャッシュは変更できません。デフォルトで、キャッシュは最大サイズとして値1000を指定してmax-beans-in-cacheを使用します。

例:

<entity-cache>

<entity-cache-name>ExclusiveCache</entity-cache-name>

<max-cache-size>

<megabytes>50</megabytes>

</max-cache-size>

</entity-cache>

entity-cache要素内で定義できる要素の詳細は、「entity-cache」を参照してください。

<start-mbds-with- application

オプション

1

アプリケーションを使用してメッセージドリブンBeanS (MDBS)を起動できるようにEJBコンテナを構成できます。trueに設定されると、コンテナはアプリケーションの一部としてMDBSを起動します。falseに設定されると、コンテナはMDBSをキューに保持し、ポートでのリスニングが開始されたときにサーバーによってMDBSが起動されます。

entity-cache

次の表では、entity-cache要素内で定義できる要素について説明します。

表A-3 entity-cache要素

要素

必須?

ファイル内での最大数

説明

<entity-cache-name>

必須

1

エンティティBeanキャッシュに一意の名前を指定します。この名前は、earファイル内で一意であることが必要で、空の文字列は使用できません。

例:

<entity-cache-name>ExclusiveCache</entity-cache-name>

<max-beans-in-cache>

オプション

この要素を指定した場合、<max-cache-size>を同時に指定することはできません。

1

キャッシュ内で許容されるエンティティBeanの最大数を指定します。限度に達すると、Beanに対してパッシブ化が行われる場合があります。このメカニズムでは、個々のエンティティBeanが必要とする実際のメモリー・サイズは考慮されません。この要素は、1以上の値に設定できます。

デフォルト値: 1000

<max-cache-size>

オプション

この要素を指定した場合、<max-beans-in-cache>を同時に指定することはできません。

1

エンティティ・キャッシュのメモリー・サイズの限度をバイト単位またはMB単位で指定するときに使用されます。max-cache-size要素を使用して最大サイズが指定されたキャッシュをBeanが使用する場合、Beanプロバイダでweblogic-ejb-jar.xml記述子のBeanの平均サイズを見積る必要があります。デフォルトでは、Beanの平均サイズは100バイトと想定されます。

ejb要素内で定義できる要素の詳細は、「max-cache-size」を参照してください。

<max-queries-in-cache>

オプション

1

指定した時点にエンティティ・キャッシュに表示可能なSQL問合せの最大数を指定します。

<caching-strategy>

オプション

1

EJBコンテナが特定のアプリケーション・レベル・キャッシュでエンティティBeanインスタンスを管理するときに使用する一般的な戦略を指定します。キャッシュによって、メモリー内のエンティティBeanインスタンスがバッファに移され、対応する主キー値に関連付けられます。

caching-strategy要素の値は、以下のいずれかに限られます。

- Exclusive - 主キー値ごとにメモリー内の1つのBeanインスタンスをキャッシュします。この一意のインスタンスは、通常、使用時にEJBコンテナの排他的ロックを使用してロックされ、同時にそのインスタンスを使用するトランザクションは1つのみになります。

- MultiVersion - 指定した主キー値に対してメモリー内の複数のBeanインスタンスをキャッシュします。各インスタンスを複数のトランザクションで同時に使用できます。

デフォルト値: MultiVersion

例:

<caching-strategy>Exclusive</caching-strategy>

max-cache-size

次の表では、max-cache-size要素内で定義できる要素について説明します。

表A-4 max-cache-size要素

要素

必須?

ファイル内での最大数

説明

<bytes>

<bytes>または<megabytes>の指定が必須です

1

バイト単位で示されるエンティティ・キャッシュのメモリー・サイズ。

<megabytes>

<bytes>または<megabytes>の指定が必須です

1

MB単位で示されるエンティティ・キャッシュのメモリー・サイズ。

xml

次の表では、xml要素内で定義できる要素について説明します。

表A-5 xml要素

要素

必須?

ファイル内での最大数

説明

<parser-factory>

オプション

1

エンタープライズ・アプリケーション用の特定のXMLパーサーまたはトランスフォーマの指定に使用される親要素。

parser-factory要素内で定義できる要素の詳細は、「parser-factory」を参照してください。

<entity-mapping>

オプション

制限なし

ゼロまたはそれ以上。エンティティ・マッピングを指定します。マッピングにより、特定のパブリックIDまたはシステムIDの代替エンティティURIが指定されます。このエンティティURIを検索するデフォルトの場所は、lib/xml/registryディレクトリです。

entity-mapping要素内で定義できる要素の詳細は、「entity-mapping」を参照してください。

parser-factory

次の表では、parser-factory要素内で定義できる要素について説明します。

表A-6 parser-factory要素

要素

必須?

ファイル内での最大数

説明

<saxparser-factory>

オプション

1

対象アプリケーションのみで必要とされるXML解析用のSAXParserファクトリを設定できます。この要素によって、SAXスタイル解析に使用されるファクトリが指定されます。saxparser-factory要素の設定をしないと、サーバーXMLレジストリで構成されたSAXParserファクトリ・スタイルが使用されます。

デフォルト値: サーバーXMLレジストリの設定

<document-builder-factory>

オプション

1

対象アプリケーションのみで必要とされるXML解析用のドキュメント・ビルダー・ファクトリを設定できます。この要素によって、DOMスタイル解析に使用されるファクトリが決定されます。document-builder-factory要素を設定しないと、サーバーXMLレジストリで構成されたDOMスタイルが使用されます。

デフォルト値: サーバーXMLレジストリの設定

<transformer-factory>

オプション

1

対象アプリケーションのみで必要とされるスタイル・シート処理用のトランスフォーマ・エンジンを設定できます。この要素の値を指定しないと、サーバーXMLレジストリで構成された値が使用されます。

デフォルト値: サーバーXMLレジストリの設定

entity-mapping

次の表では、entity-mapping要素内で定義できる要素について説明します。

表A-7 entity-mapping要素

要素

必須?

ファイル内での最大数

説明

<entity-mapping-name>

必須

1

このエンティティ・マッピングの名前を指定します。

<public-id>

オプション

1

マップされたエンティティのパブリックIDを指定します。

<system-id>

オプション

1

マップされたエンティティのシステムIDを指定します。

<entity-uri>

オプション

1

マップされたエンティティのエンティティURIを指定します。

<when-to-cache>

オプション

1

有効値は、次のとおりです。

- cache-on-reference

- cache-at-initialization

- cache-never

デフォルト値はcache-on-referenceです。

<cache-timeout-interval>

オプション

1

秒単位で整数値を指定します。

jdbc-connection-pool

注意:

jdbc-connection-pool要素は非推奨です。エンタープライズ・アプリケーションでデータ・ソースを定義するには、アプリケーションとともにJDBCモジュールをパッケージ化します。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCアプリケーション・モジュールのデプロイメントの構成に関する項を参照してください。

次の表では、jdbc-connection-pool要素内で定義できる要素について説明します。

表A - 8 jdbc-connection-pool要素

要素

必須?

ファイル内での最大数

説明

<data-source-jndi-name>

必須

1

アプリケーション固有のJNDIツリーにおけるJNDI名を指定します。

<connection-factory>

必須

1

デフォルトの接続ファクトリ設定のオーバーライドを定義する接続パラメータを指定します。

- user-name - 省略可能。user-name要素は、JDBCDataSourceFactoryMBeanのUserNameのオーバーライドに使用されます。

- url - 省略可能。url要素は、JDBCDataSourceFactoryMBeanのURLオーバーライドに使用されます。

- driver-class-name - 省略可能。driver-class-name要素は、JDBCDataSourceFactoryMBeanのDriverNameのオーバーライドに使用されます。

- connection-params - ゼロまたはそれ以上。

- parameter+ (param-value、param-name) - 1つまたは複数

connection-factory要素内で定義できる要素の詳細は、「connection-factory」を参照してください。

<pool-params>

オプション

1

プールの動作に影響を与えるパラメータを定義します。

pool-params要素内で定義できる要素の詳細は、「pool-params」を参照してください。

<driver-params>

オプション

1

WebLogic Serverドライバの動作を設定します。

driver-params要素内で定義できる要素の詳細は、「driver-params」を参照してください。

<acl-name>

オプション

1

非推奨。

connection-factory

次の表では、connection-factory要素内で定義できる要素について説明します。

表A - 9 connection-factory要素

要素

必須?

ファイル内での最大数

説明

<factory-name>

オプション

1

config.xmlファイル内のJDBCDataSourceFactoryMBeanの名前を指定します。

<connection-properties>

オプション

1

接続ファクトリの接続プロパティを指定します。connection-properties要素について定義できる要素は、次のとおりです。

- user-name - 省略可能。JDBCDataSourceFactoryMBeanのUserNameのオーバーライドに使用されます。

- password - 省略可能。JDBCDataSourceFactoryMBeanのPasswordのオーバーライドに使用されます。

- url - 省略可能。JDBCDataSourceFactoryMBeanのURLのオーバーライドに使用されます。

- driver-class-name - 省略可能。JDBCDataSourceFactoryMBeanのDriverNameのオーバーライドに使用されます。

- connection-params - ゼロまたはそれ以上。接続を確立する際にドライバに渡されるパラメータの設定に使用されます。例:

<connection-params>
<parameter>
<description>Desc of param
</description>
<param-name>foo</param-name>
<param-value>xyz</param-value>
</parameter>
</connection-params>

pool-params

次の表では、pool-params要素内で定義できる要素について説明します。

表A - 10 pool-params要素

要素

必須?

ファイル内での最大数

説明

<size-params>

オプション

1

プール内の接続数に影響を与えるパラメータを定義します。

- initial-capacity - 省略可能。initial-capacity要素は、プールの初期化時に作成される物理的なデータベース接続数を定義します。デフォルト値は1です。

- max-capacity - 省略可能。max-capacity要素は、プールに含める物理的なデータベースの最大接続数を定義します。ただし、JDBCドライバによってこの値がさらに制限されることがあります。デフォルト値は1です。

- capacity-increment - 省略可能。capacity-increment要素は、プール容量を拡張するときの増分を定義します。サービス・リクエストのために利用可能となる物理的な接続が他にないとき、プールは必要なデータベースの物理的な接続数を作成し、プールに追加します。プール内の接続数は、max-capacityで設定された物理的な最大接続数を超えないように保持されます。デフォルト値は1です。

- shrinking-enabled - 省略可能。shrinking-enabled要素は、使用されていない接続が検出された場合に、プールの容量をinitial-capacityに戻すかどうかを指定します。

- shrink-period-minutes - 省略可能。shrink-period-minutes要素は、リクエストを満たすためにインクリメンタルに増やした接続プールを縮小するまで待機する時間(分単位)を定義します。縮小を可能にするには、shrinking-enabled要素をtrueに設定しておく必要があります。

- shrink-frequency-seconds - 省略可能。

- highest-num-waiters - 省略可能。

- highest-num-unavailable - 省略可能。

<xa-params>

オプション

1

XA DataSourceのパラメータを定義します。

- debug-level - 省略可能。整数。debug-level要素はXA処理のデバッグ・レベルを定義します。デフォルト値は0です。

- keep-conn-until-tx-complete-enabled - 省略可能。ブール値。Keep-conn-until-tx-complete-enabled要素をtrueに設定すると、トランザクションが完了するまで、XA接続プールによって同一のXA接続が分散トランザクションに関連付けられます。

- end-only-once-enabled - 省略可能。ブール値。end-only-once-enabled要素をtrueに設定すると、保留中の各XAResource.start()メソッドに対するXAResource.end()メソッドの呼出しが一度に限られます。

- recover-only-once-enabled - 省略可能。ブール値。recover-only-once-enabled要素をtrueに設定すると、リソースに対するリカバリの呼出しが一度に限られます。

- tx-context-on-close-needed - 省略可能。tx-context-on-close-needed要素は、様々なJDBCオブジェクト(たとえば、結果セット、ステートメント、接続など)をクローズするときにXAドライバで分散トランザクション・コンテキストが必要な場合、trueに設定します。trueに設定されると、いずれかのトランザクション・コンテキスト内にないJDBCオブジェクトをクローズするときにスローされるSQL例外は無条件で受け入れられます。

- new-conn-for-commit-enabled - 省略可能。ブール値。new-conn-for-commit-enabled要素をtrueに設定すると、特定の分散トランザクションのコミットおよびロールバック処理に専用のXA接続が使用されます。

<xa-params> Continued...

オプション

1

- prepared-statement-cache-size - 非推奨。オプション。prepared-statement-cache-size要素は、プリペアド文のキャッシュ・サイズの設定に使用します。このキャッシュ・サイズは、特定の接続から作成されるプリペアド文の数を表し、後で使用できるようにキャッシュに格納されます。プリペアド文のキャッシュ・サイズを0に設定すると、オフになります。

注意: Prepared-statement-cache-sizeは非推奨です。driver-params/prepared-statementのcache-sizeを使用します。詳細は、「driver-params」を参照してください。

- keep-logical-conn-open-on-release - 省略可能。ブール値。keep-logical-conn-open-on-release要素をtrueに設定すると、XAの物理接続がXA接続プールに戻されてもJDBCの論理接続はオープンしたまま保持されます。デフォルト値はfalseです。

- local-transaction-supported - 省略可能。ブール値。XAドライバがグローバル・トランザクションを使用しないSQLをサポートする場合にはlocal-transaction-supportedをtrueに設定し、そうでない場合はfalseに設定します。デフォルト値はfalseです。

- resource-health-monitoring-enabled - 省略可能。resource-health-monitoring-enabled要素は、ターゲット接続プールに対してJTAリソース状態モニター機能を有効にする場合にはtrueに設定します。

<xa-params> Continued...

オプション

1

- xa-set-transaction-timeout - 省略可能。
次で使用: xa-params

例:

<xa-set-transaction-timeout>

true

</xa-set-transaction-timeout>

- xa-transaction-timeout - 省略可能。
xa-set-transaction-timeoutの値をtrueに設定すると、トランザクション・マネージャはXAResource.startを呼び出す前にリソースに対してsetTransactionTimeoutを呼び出します。トランザクション・マネージャは、グローバル・トランザクション・タイムアウト値を渡します。この属性が0より大きい値に設定されていると、この値がグローバル・トランザクション・タイムアウトに代わって使用されます。

デフォルト値: 0

次で使用: xa-params

例:

<xa-transaction-timeout>

30

</xa-transaction-timeout>

- rollback-localtx-upon-connclose - 省略可能。
rollback-localtx-upon-connclose要素がtrueの場合、接続プールは接続をプールに戻す前に、その接続に対してrollback()を呼び出します。

デフォルト値: false

次で使用: xa-params

例:

<rollback-localtx-upon-connclose>

true </rollback-localtx-upon-connclose>

<login-delay-seconds>

オプション

1

各物理データベース接続を作成するまでにかかる遅延時間(秒数)を設定します。データベース・サーバーによっては、複数の接続リクエストが短い間隔で繰り返されると処理できないことがあります。このプロパティを使用すると、データベース・サーバーが追いつけるように、少し遅れて作成することができます。この遅延は、データベースの物理的な接続が確立すると、プールの初期作成時とプールの存続期間中の両方で必ず行われます。

<leak-profiling-enabled>

オプション

1

JDBC接続リーク・プロファイリングを有効化します。接続リークは、プールからの接続がclose()メソッドの呼出しで明示的にクローズされていない場合に発生します。接続リーク・プロファイリングがアクティブの場合、プールは接続オブジェクトがプールから割り当てられ、クライアントに与えられたときにスタック・トレースを格納します。接続リークが検出されたとき(接続オブジェクトのガベージ・コレクションが行われたとき)に、このスタック・トレースが報告されます。

この要素はリソースを余計に使用し、接続プール処理を遅くする可能性があるので、本番での使用はお薦めしません。

<connection-check-params>

オプション

1

- プール内の接続がまだ有効であることを確認するチェックを行うかどうかを指定し、行う場合の時期と方法を定義します。

- table-name - 省略可能。table-name要素は、スキーマ内で問合せできる表を定義します。

- check-on-reserve-enabled - 省略可能。check-on-reserve-enabled要素がtrueに設定されると、ユーザーに接続が渡される前に毎回接続がテストされます。

- check-on-release-enabled - 省略可能。check-on-release-enabled要素がtrueに設定されると、ユーザーが接続をプールに戻すときに毎回接続がテストされます。

- refresh-minutes - 省略可能。refresh-minutes要素が定義されると、定期的(指定された分単位の時間)にトリガーされます。トリガーによって、プール内の各接続がまだ有効であることを確認するチェックが行われます。

- check-on-create-enabled - 省略可能。trueに設定すると、接続は作成時にテストされます。

- connection-reserve-timeout-seconds - 省略可能。プールからの接続を予約する呼出しのタイムアウト後の秒数。

- connection-creation-retry-frequency-seconds - 省略可能。プールがデータベースへの接続を確立しようとする再試行の頻度。

- inactive-connection-timeout-seconds - 省略可能。予約された接続が強制的に解放されてプールに戻されるまでの非アクティブ期間の秒数。

<connection-check-params>
Continued...

オプション

1

- test-frequency-seconds - 省略可能。データベース接続テストの周期の秒数。test-frequency-secondsの期間が終わるたびに、未使用のデータベース接続はtable-nameを使ってテストされます。テストに合格しない接続は閉じられ、有効な物理データベース接続を再確立するために再び開かれます。table-nameが設定されていない場合、テストは実行されません。

- init-sql - 省略可能。接続が作成されたときに自動的に実行されるSQL問合せを指定します。

<jdbcxa-debug-level>

オプション

1

これは内部設定です。

<remove-infected-connections-enabled>

オプション

1

アプリケーションが基底のベンダー接続オブジェクトを要求した場合に、接続がプールから削除されるかどうかを制御します。この属性を有効化すると、(接続がプールから削除され、新しい接続に置き換わるために)基本的に接続のプールを無効化することになるので、パフォーマンスに影響を与えます。

driver-params

次の表では、driver-params要素内で定義できる要素について説明します。

表A - 11 driver-params要素

要素

必須?

ファイル内での最大数

説明

<statement>

オプション

1

driver-params文を定義します。省略可能な要素profiling-enabledが含まれます。

例:

<statement>

<profiling-enabled>true

</profiling-enabled>

</statement>

<prepared-statement

オプション

1

JDBCのプリペアド文キャッシュ・プロファイリングの実行を有効化します。有効化されると、プリペアド文キャッシュ・プロファイルが後で分析できるように外部ストレージに格納されます。この機能はリソースを消費するので、本番サーバーでは無効にすることをお薦めします。デフォルト値はfalseです。

- profiling-enabled - 省略可能。

- cache-profiling-threshold - 省略可能。cache-profiling-threshold要素は、文リクエストの数(これを超えるとプリペアド文キャッシュの状態がログに記録される)を定義します。この要素は出力量を最小化します。この機能はリソースを消費するので、本番サーバーでは無効にすることをお薦めします。

- cache-size - 省略可能。cache-size要素は、プリペアド文キャッシュのサイズを返します。このキャッシュ・サイズは、特定の接続から作成されるプリペアド文の数を表し、後で使用できるようにキャッシュに格納されます。

- parameter-logging-enabled - 省略可能。SQLラウンドトリップ・プロファイリング時に、プリペアド文パラメータの値を格納できます。parameter-logging-enabled要素を使用すると、文パラメータを格納できるようになります。この機能はリソースを消費するので、本番サーバーでは無効にすることをお薦めします。

- max-parameter-length - 省略可能。SQLラウンドトリップ・プロファイリング時に、プリペアド文パラメータの値を格納できます。max-parameter-length要素は、JDBC SQラウンドトリップ・プロファイリングのパラメータとして渡される文字列の最大の長さを定義します。この機能はリソースを消費するため、パラメータのデータ長を制限して、出力量を減らす必要があります。

- cache-type - 省略可能。

<row-prefetch-enabled>

オプション

1

各ResultSetについて、クライアントとWebLogic Serverの間での行のプリフェッチを有効にするかどうかを指定します。

外部クライアントがJDBCを使用してWebLogic Server経由でデータベースにアクセスするとき、行のプリフェッチを行うと1回のサーバー・アクセスでサーバーからクライアントに複数の行を取り出すことになるので、パフォーマンスが向上します。クライアントとWebLogic Serverが同一のJVM内にある場合は、この設定が無視され、行のプリフェッチは使用されません。

<row-prefetch-size>

オプション

1

クライアント用にプリフェッチする結果セットの行数を指定します。

最適値は問合せの詳細によって異なります。一般的に、この数を増やすと特定の値に達するまでパフォーマンスが向上します。その値に達すると、それ以上数を増やしてもパフォーマンスはそれほど向上しません。

注意: 通常、100行に達した後では、パフォーマンスの向上が見られなくなります。ほとんどの状況では、デフォルト値で問題ありません。

この要素の有効な値は2から65536までです。デフォルト値は48です。

<stream-chunk-size>

オプション

1

必要に応じてWebLogic Serverからクライアントに取得されるストリーム・データ型のデータ・チャンク・サイズを指定します。

security

次の表では、security要素内で定義できる要素について説明します。

表A - 12 security要素

要素

必須?

ファイル内での最大数

説明

<realm-name>

オプション

1

アプリケーションが使用するセキュリティ・レルムの名前を指定します。指定されていなければ、システムのデフォルト・レルムが使用されます。

<security-role-assignment>

オプション

制限なし

アプリケーション・ワイドなセキュリティ・ロールと、1つまたは複数のWebLogic Serverプリンシパルとのマッピングを宣言します。

例:

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

application-param

次の表では、application-param要素内で定義できる要素について説明します。

表A - 13 application-param要素

要素

必須?

ファイル内での最大数

説明

<description>

オプション

1

アプリケーション・パラメータを説明します。

<param-name>

必須

1

アプリケーション・パラメータの名前を定義します。

<param-value>

必須

1

アプリケーション・パラメータの値を定義します。

classloader-structure

次の表では、classloader-structure要素内で定義できる要素について説明します。

表A - 14 classloader-structure要素

要素

必須?

ファイル内での最大数

説明

<module-ref>

オプション

制限なし

module-ref要素内で定義できる要素は次のとおりです。

- module-uri - ゼロまたはそれ以上。module-ref要素内で定義されます。

<classloader-structure>

オプション

制限なし

アプリケーションのクラスローダー構造の任意のネスティングを有効にします。ただし、このバージョンのWebLogic Serverでは、指定可能な階層は3レベルまでです。

listener

次の表では、listener要素内で定義できる要素について説明します。

表A-15 listener要素

要素

必須?

ファイル内での最大数

説明

<listener-class>

必須

1

ApplicationLifecycleListenerのユーザーによる実装の名前。

<listener-uri>

オプション

1

実装が格納されているEAR内のJARファイル。listener-uriを指定していない場合は、クラスがアプリケーションから参照可能であると見なされます。

<run-as-principal-name>

オプション

1

アプリケーション・ライフサイクル・イベントを起動および停止するユーザーIDを指定します。ここに指定するIDはシステムの有効なユーザー名である必要があります。run-as-principal-nameを指定しない場合、アプリケーション・ライフサイクル・リスナーの実行のためのrun-as IDとしては、デプロイメント・イニシエータのユーザーIDが使用されます。

注意: アプリケーション・ライフサイクル・リスナー用に定義されたrun-as-principal-name IDが管理者である場合、アプリケーション・デプロイヤには管理者権限が必要です。これがない場合、デプロイメントは失敗します。

singleton-service

次の表では、singleton-service要素内で定義できる要素について説明します。

表A - 16 singleton-service要素

要素

必須?

ファイル内での最大数

説明

<class-name>

必須

1

アプリケーションのデプロイ中に実行するクラスの名前を定義します。

<singleton-uri>

オプション

1

singleton-serviceが格納されているEAR内のJARファイルを定義します。singleton-uriが定義されていない場合は、クラスがアプリケーションから参照可能であると見なされます。

startup

次の表では、startup要素内で定義できる要素について説明します。

注意:

アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、アプリケーション・ライフサイクル・イベントのプログラミングを参照してください。

表A - 17 startup要素

要素

必須?

ファイル内での最大数

説明

<startup-class>

必須

1

アプリケーションのデプロイ中に実行するクラスの名前を定義します。

<startup-uri>

オプション

1

startup-classが格納されているEAR内のJARファイルを定義します。startup-uriが定義されていない場合は、クラスがアプリケーションから参照可能であると見なされます。

shutdown

次の表では、shutdown要素内で定義できる要素について説明します。

注意:

アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、アプリケーション・ライフサイクル・イベントのプログラミングを参照してください。

表A - 18 shutdown要素

要素

必須/省略可能

ファイル内での最大数

説明

<shutdown-class>

必須

1

アプリケーションのアンデプロイ時に実行するクラスの名前を定義します。

<shutdown-uri>

オプション

1

shutdown-classが格納されているEAR内のJARファイルを定義します。shutdown-uri要素を指定していない場合はクラスがアプリケーションから参照可能であると見なされます。

work-manager

次の表では、work-manager要素内で定義できる要素について説明します。

ワーク・マネージャの例および情報については、「ワーク・マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

表A - 19 work-manager要素

要素

必須?

ファイル内での最大数

説明

<name>

必須

1

ワーク・マネージャの名前。

<response-time-request-class>

オプション

1

<work-manager>のこの子要素の詳細は、「weblogic-application」の<response-time-request>要素の説明を参照してください。

この要素を指定した場合、<fair-share-request-class>、<context-request-class>、または<request-class-name>を同時に指定することはできません。

<fair-share-request-class>

オプション

1

<work-manager>のこの子要素の詳細は、「weblogic-application」の<fair-share-request>要素の説明を参照してください。

この要素を指定した場合、<response-time-request-class>、<context-request-class>、または<request-class-name>を同時に指定することはできません。

<context-request-class>

オプション

1

<work-manager>のこの子要素の詳細は、「weblogic-application」の<context-request>要素の説明を参照してください。

この要素を指定した場合、<fair-share-request-class>、<response-time-request-class>、または<request-class-name>を同時に指定することはできません。

<request-class-name>

オプション

1

リクエスト・クラスの名前。

この要素を指定した場合、<fair-share-request-class>、<context-request-class>、または<response-time-request-class>を同時に指定することはできません。

<min-threads-constraint>

オプション

1

<work-manager>のこの子要素の詳細は、「weblogic-application」の<min-threads-constraint>要素の説明 を参照してください。

この要素を指定した場合、<min-threads-constraint-name>を同時に指定することはできません。

<min-threads-constraint-name>

オプション

1

min-thread-constraint制約の名前。

この要素を指定した場合、<min-threads-constraint>を同時に指定することはできません。

<max-threads-constraint>

オプション

1

<work-manager>のこの子要素の詳細は、「weblogic-application」の<max-threads-constraint>要素の説明を参照してください。

この要素を指定した場合、<max-threads-constraint-name>を同時に指定することはできません。

<max-threads-constraint-name>

オプション

1

max-thread-constraint制約の名前。

この要素を指定した場合、<max-threads-constraint>を同時に指定することはできません。

<capacity>

オプション

1

<work-manager>のこの子要素の詳細は、「weblogic-application」の<capacity>要素の説明を参照してください。

この要素を指定した場合、<capacity-name>を同時に指定することはできません。

<capacity-name>

オプション

1

スレッドの容量制約の名前。

この要素を指定した場合、<capacity>を同時に指定することはできません。

<work-manager-shutdown-trigger>

オプション

1

スタック・スレッドに応答してワーク・マネージャを停止できるスタック・スレッド・ワーク・マネージャ・コンポーネントの指定に使用します。

次の子要素を指定できます。

- max-stuck-thread-time - スレッドがスタック内に残る最大時間(秒)。

- stuck-thread-count - スタック・スレッド・ワーク・マネージャをトリガーするスタック・スレッドの数。

この要素を指定した場合、<ignore-stuck-threads>を同時に指定することはできません。

<ignore-stuck-threads>

オプション

1

スレッドがスタックした場合でも、ワーク・マネージャがスタック・スレッドを無視して停止を回避するかどうかを指定します。

この要素を指定した場合は、<work-manager-shutdown-trigger>を同時に指定することはできません。

session-descriptor

次の表では、session-descriptor要素内で定義できる要素について説明します。

表A - 20 session-descriptor要素

要素

必須?

ファイル内での最大数

説明

<timeout-secs>

オプション

1

セッションがタイムアウトするまでの秒数を指定します。

デフォルト値は3600秒です。

<invalidation-interval-secs>

オプション

1

セッション無効化トリガーの間隔を秒数で指定します。

デフォルト値は60秒です。

<debug-enabled>

オプション

1

HTTPセッションのデバッグを有効にするかどうかを指定します。

デフォルト値はfalseです。

<id-length>

オプション

1

セッションIDの長さを指定します。

デフォルト値は52です。

<tracking-enabled>

オプション

1

HTTPリクエスト間のセッション・トラッキングを有効にするかどうかを指定します。

デフォルト値はtrueです。

<cache-size>

オプション

1

JDBCとファイル永続化セッションのキャッシュ・サイズを指定します。

デフォルト値は1028です。

<max-in-memory-sessions>

オプション

1

メモリー/レプリケートされたセッションの最大セッション数を指定します。

デフォルト値は -1(制限なし)です。

<cookies-enabled>

オプション

1

Webアプリケーション・コンテナがレスポンスにCookieを設定するかどうかを指定します。

デフォルト値はtrueです。

<cookie-name>

オプション

1

セッション・トラッキングを実行するCookieの名前を指定します。

デフォルト名はJSESSIONIDです。

<cookie-path>

オプション

1

セッション・トラッキングCookieのパスを指定します。

デフォルト値は/です。

<cookie-domain>

オプション

1

セッション・トラッキングCookieのドメインを指定します。

デフォルト値はnullです。

<cookie-comment>

オプション

1

セッション・トラッキングCookieのコメントを指定します。

デフォルト値はnullです。

<cookie-secure>

オプション

1

セッション・トラッキングCookieが安全であることを示すかどうかを指定します。

デフォルト値はfalseです。

<cookie-max-age-secs>

オプション

1

セッション・トラッキングCookieの最大存続期間を指定します。

デフォルト値は-1(制限なし)です。

<persistent-store-type>

オプション

1

セッション永続性の格納の種類を指定します。

以下の値を指定できます。

- memory - デフォルト値。

- replicated -クラスタリングが必要です。

- replicated_if_clustered - クラスタリングされていない場合のデフォルト値はmemoryです。

- file

- jdbc

- Cookie

<persistent-store-cookie-name>

オプション

1

Cookieベースのセッションの永続性を使用する場合に、属性名と値を保持するCookieの名前を指定します。

デフォルト値はWLCOOKIEです。

<persistent-store-dir>

オプション

1

fileベースのセッションの永続性を使用する場合に、ディレクトリの名前を指定します。ディレクトリは、Webアプリケーション用に定義された一時ディレクトリを基準にします。

デフォルト値はsession_dbです。

<persistent-store-pool>

オプション

1

jdbcベースのセッションの永続性を使用する場合に、JDBC接続プールの名前を指定します。

<persistent-store-table>

オプション

1

jdbcベースのセッションの永続性を使用する場合に、データベース表の名前を指定します。

デフォルト値はwl_servlet_sessionsです。

<jdbc-column-name-max-inactive-interval>

オプション

1

jdbcベースのセッションの永続性を使用する場合に、wl_max_inactive_interval列の代替名を指定します。長い列名をサポートしていない一部のデータベースでは必須です。

<jdbc-connection-timeout-secs>

オプション

1

非推奨

<url-rewriting-enabled>

オプション

1

URLの書換えが有効化されているかどうかを指定します。

デフォルト値はtrueです。

<http-proxy-caching-of-cookies>

オプション

1

WebLogic Serverが次のHTTPヘッダーをレスポンスに追加するかどうかを指定します。

Cache-control: no-cache=set-cookie

このヘッダーにより、プロキシ・キャッシュがCookieをキャッシュしてはならないことが指定されます。

デフォルト値はtrueで、その場合ヘッダーは追加されません。ヘッダーをレスポンスに追加する場合は、この要素をfalseに設定します。

<encode-session-id-in-query-params>

オプション

1

WebLogic Serverがパス・パラメータのセッションIDをエンコードするかどうかを指定します。

デフォルト値はfalseです。

<monitoring-attribute-name>

オプション

1

複数のセッションの実行時情報をタグ付けする場合に使用します。たとえば、一意であることが保証されるusername属性がある場合は、この要素をusernameに設定します。

<sharing-enabled>

オプション

1

複数のWebアプリケーション間でHTTPセッションを共有するかどうかを指定します。

デフォルト値はfalseです。

library-ref

次の表では、library-ref要素内で定義できる要素について説明します。

詳細情報および例については、共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

表A-21 library要素

要素

必須?

ファイル内での最大数

説明

<library-name>

必須

1

参照される共有Java EEライブラリの名前を指定します。

<specification-version>

オプション

1

最低限の仕様バージョン要件を指定します。

<implementation-version>

オプション

1

最低限の実装バージョン要件を指定します。

<exact-match>

オプション

1

指定した仕様バージョンおよび実装バージョンと参照したライブラリの仕様バージョンおよび実装バージョンが完全一致する必要があるどうかを指定します。

デフォルト値はfalseです。

<context-root>

オプション

1

参照されるWebアプリケーションの共有Java EEライブラリのコンテキスト・ルートを指定します。

library-context-root-override

次の表では、参照されるEARライブラリ内のcontext-root要素をオーバーライドするためにlibrary-context-root-override要素内で定義できる要素について説明します。「library-ref」を参照してください。

詳細情報および例については、共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

表A-22 library-context-root-override要素

要素

必須?

ファイル内での最大数

説明

<context-root>

オプション

1

ライブラリ内で宣言されているcontext-root要素をオーバーライドします。この要素が存在しない場合は、ライブラリのcontext-rootが使用されます。

参照元アプリケーション(たとえば、ユーザー・アプリケーション)のみが、ライブラリで宣言されているcontext-root要素をオーバーライドできます。

<override-value>

オプション

1

ライブラリで宣言されているcontext-root要素をオーバーライドする際のlibrary-context-root-override要素の値を指定します。これらの要素が存在しない場合は、ライブラリのcontext-rootが使用されます。

fast-swap

次の表では、fast-swap要素内で定義できる要素について説明します。

FastSwapデプロイメントの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

表A-23 fast-swap要素

要素

必須?

ファイル内での最大数

説明

<enabled>

オプション

1

アプリケーションにFastSwapデプロイメントを有効にするにはtrueに設定します。

<refresh-interval>

オプション

1

受信HTTPリクエストを受信する場合、FastSwapはアプリケーション・クラスの変更をチェックします。refresh-intervalの秒数内で到着する後続のHTTPリクエストは、変更のチェックをトリガーしません。refresh-intervalの秒数が経過した後で最初に到着したHTTPリクエストによって、FastSwapによるクラスの変更のチェックが発生します。

<redefinition-task-limit>

オプション

1

再定義タスクによってFastSwapクラスの再定義が非同期的に実行されます。JMXインタフェースを使ってこれを制御および検査することができます。

FastSwapシステムによって保存される再定義タスクの数を指定します。タスクの数がこの制限を超える場合は、古いタスクが自動的に削除されます。

weblogic-application.xmlスキーマ

weblogic-application.xmlデプロイメント記述子ファイルのXMLスキーマについては、http://xmlns.oracle.com/weblogic/weblogic-application/1.6/weblogic-application.xsdを参照してください。

application.xmlスキーマ

application.xmlデプロイメント記述子の要素の詳細は、http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_7.xsdのJava EE 6スキーマを参照してください。

B wldeploy Antタスクのリファレンス

この付録では、アプリケーションおよびスタンドアロン・モジュールをWebLogic Serverにデプロイするツールについて説明します。

この付録の内容は次のとおりです。

- wldeploy Antタスクの概要

- wldeployを使用する基本手順

- wldeploy用build.xmlファイルのサンプル

- wldeploy Antタスクの属性のリファレンス

wldeploy Antタスクの概要

wldeploy Antタスクでは、Ant XMLファイルに指定する属性を使用してweblogic.Deployerの機能を実行できます。wldeployを他のWebLogic Server Antタスクとともに使用して、以下を実行する単一のAntビルド・スクリプトを作成できます。

- wlcompile、appc、およびWebサービスAntタスクを使用してソースからアプリケーションをビルドします。

- wlserverおよびwlconfig Antタスクを使用して、新しいWebLogic Serverドメインを作成、起動、および構成します。

- wldeploy Antタスクを使用して、新しく作成したドメインに、コンパイル済みアプリケーションをデプロイします。

wlserverおよびwlconfigの詳細は、Antタスクを使用したWebLogic Serverドメインの構成と使用を参照してください。wlcompileの詳細は、分割開発ディレクトリでのアプリケーションのビルドを参照してください。

wldeployを使用する基本手順

wldeploy Antタスクを使用するには:

1. 環境を設定します。

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

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

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

2. ステージング・ディレクトリで、Antビルド・ファイル(デフォルトはbuild.xml)を作成します。WebLogic Serverと一緒にインストールされたものとは異なるAntを使用する場合は、wldeploy Antタスクを定義することから始めます。

<taskdef name="wldeploy" classname="weblogic.ant.taskdefs.management.WLDeploy"/>

3. 必要に応じて、新しいWebLogic Serverドメインを作成するためのタスク定義とwlserverおよびwlconfigタスクの呼出しをビルド・スクリプトに追加します。wlserverおよびwlconfigの詳細は、Antタスクを使用したWebLogic Serverドメインの構成と使用を参照してください。

4. wldeployの呼出しを追加して、アプリケーションを1つまたは複数のWebLogic Serverインスタンスまたはクラスタにデプロイします。「wldeploy用build.xmlファイルのサンプル」および「wldeploy Antタスクの属性のリファレンス」を参照してください。

5. ステージング・ディレクトリでantと入力し、必要であればこのコマンドにターゲットの引数を渡して、build.xmlファイルで指定されたAntタスク(1つまたは複数)を実行します。

prompt> ant

wldeploy用build.xmlファイルのサンプル

次の例では、アプリケーションを単一のWebLogic Serverインスタンスにデプロイするwldeployのデプロイ先を示しています。

<target name="deploy">
<wldeploy
action="deploy" verbose="true" debug="true"
name="DeployExample" source="output/redeployEAR"
user="weblogic" password="weblogic"
adminurl="t3://localhost:7001" targets="myserver" />
</target>

次の例では、アプリケーションをアンデプロイする場合に対応するタスクを示します。この例では、アプリケーションをアンデプロイまたは再デプロイする際に、ソース・アーカイブ・ファイルまたは展開ディレクトリではなく、そのデプロイされた名前のみを指定します。

<target name="undeploy">
<wldeploy
action="undeploy" verbose="true" debug="true"
name="DeployExample"
user="weblogic" password="weblogic"
adminurl="t3://localhost:7001" targets="myserver"
failonerror="false" />
</target>

次の例では、アプリケーションの部分的な再デプロイを実行する方法を示します。この例では、アプリケーション内の単一のWARファイルのみが再デプロイされます。

<target name="redeploy_partial">
<wldeploy
action="redeploy" verbose="true"
name="DeployExample"
user="weblogic" password="weblogic"
adminurl="t3://localhost:7001" targets="myserver"
deltaFiles="examples/general/redeploy/SimpleImpl.war" />
</target>

次の例では、wldeployのネストされた<files>子要素を使用して、アプリケーション内でアンデプロイする特定のファイルを指定します。

<target name="undeploy_partial">
<wldeploy
action="undeploy" verbose="true" debug="true"
name="DeployExample"
user="weblogic" password="weblogic"
adminurl="t3://localhost:7001" targets="myserver"
failonerror="false">
<files
dir="${current-dir}/output/redeployEAR/examples/general/redeploy"
includes="SimpleImpl.jsp" />
</wldeploy>
</target>

次の例では、ソース・ファイルがoutput/myLibraryディレクトリにあるmyLibraryというJava EEライブラリをデプロイする方法を示します。

<target name="deploy">
<wldeploy action="deploy" name="myLibrary"
source="output/myLibrary" library="true"
user="weblogic" password="weblogic"
verbose="true" adminurl="t3://localhost:7001"
targets="myserver" />
</target>

wldeploy Antタスクの属性のリファレンス

次の項では、wldeploy Antタスクの属性および子要素<files>について説明します。

主な属性

次の表では、wldeploy Antタスクの主な属性について説明します。

これらの属性は、weblogic.Deployerコマンドの引数の一部に対応します。Oracleは、反復的な開発プロセスの一部としてアプリケーションを簡単にデプロイおよびテストできるように、weblogic.DeployerコマンドのAntタスク・バージョンを提供しています。ただし、通常、本番環境でアプリケーションをデプロイする場合、wldeploy Antタスクではなくweblogic.Deployerコマンドを使用します。したがって、wldeploy Antタスクの属性の完全な定義については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンドライン・リファレンスに関する項を参照してください。次の表に簡単なサマリーを示します。

表B-1 wldeploy Antタスクの属性

属性

説明

データ型

action

実行するデプロイメント・アクション。

有効な値は、deploy、cancel、undeploy、redeploy、distribute、start、およびstopです。

文字列

adminmode

デプロイメント・アクションによってアプリケーションが管理モードになるように指定します。

管理モードでは、アプリケーションへのアクセスは構成済の管理チャネルに制限されます。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです - つまり、デフォルトでは、アプリケーションは、すべてのクライアントがすぐにアクセスできるように本番モードでデプロイされます。

ブール

adminurl

管理サーバーのURL。

この属性の値の形式は、protocol://host:portです - ここで、protocolはhttpまたはt3、hostは管理サーバーが実行されているホスト、portは管理サーバーがリスニングしているポートです。

注意: HTTPプロトコルを使用するには、WebLogic Server管理コンソールでhttpトンネリングのオプションを有効にする必要があります。

文字列

allversions

アプリケーションのすべてのバージョンに適用するアクション(再デプロイ、停止など)を指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

altappdd

デプロイメントに使用する代替Java EEデプロイメント記述子(application.xml)の名前を指定します。

この属性を指定せず、エンタープライズ・アプリケーションをデプロイする場合、デフォルトのデプロイメント記述子はapplication.xmlという名前で、アプリケーションのメイン・ディレクトリまたはアーカイブ(source属性で指定)のMETA-INFサブディレクトリに置かれます。

文字列

altwlsappdd

デプロイメントに使用する代替WebLogic Serverデプロイメント記述子(weblogic-application.xml)の名前を指定します。

この属性を指定せず、エンタープライズ・アプリケーションをデプロイする場合、デフォルトのデプロイメント記述子はweblogic-application.xmlという名前で、アプリケーションのメイン・ディレクトリまたはアーカイブ(source属性で指定)のMETA-INFサブディレクトリに置かれます。

文字列

appversion

デプロイされるアプリケーションのバージョン識別子。

文字列

debug

wldeployデバッグ・メッセージを有効にします。

ブール

deleteFiles

サーバーのステージング・ディレクトリから静的ファイルを削除するかどうかを指定します。

この属性は、展開されたデプロイメント、およびstageモードを使用してデプロイされたアプリケーションでのみ有効です。この属性を使用するときは、ターゲット・サーバーを指定する必要があります。

deleteFiles属性を指定すると、デプロイメント時にステージング領域にコピーされたファイルのみが削除されます。

この属性は、action="redeploy"と一緒にしか使用できません。

deleteFiles属性では指定したすべてのファイルが削除されるので、deleteFilesを使用する場合は慎重を期し、また、本番環境では使用しないことをお薦めします。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

deltaFiles

再デプロイするアプリケーションのルート・ディレクトリを基準にして、ファイルのカンマ区切りまたはスペース区切りのリストを指定します。

この属性は、アプリケーションの部分再デプロイを実行する際、必ずaction="redeploy"と組み合わせて使用します。

文字列

enableSecurityValidation

セキュリティ・データの検証を有効にするかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

externalStage

デプロイメントでexternal_stageデプロイメント・モードを使用するかどうかを指定します。

このモードでは、Antタスクはデプロイメント・ファイルをターゲット・サーバーにコピーしません。かわりに、デプロイメント・ファイルがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。

stage、nostageまたはexternal_stageのいずれかの属性のみを指定できます。何も指定しない場合、管理ターゲット・サーバーに対するデフォルトのデプロイメント・モードはstage、単一のサーバーでの管理サーバーに対するデフォルト・モードはnostageです。

「ステージング・モードによるデプロイメント・ファイルのコピーの制御」を参照してください。

ブール

failonerror

WebLogic Server Antタスクで使用されるグローバル属性。ビルド中にエラーが発生した場合、タスクを失敗させるかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はtrueです。

ブール

graceful

既存のHTTPクライアントが作業を完了した後でアプリケーションを停止します。

この属性は、アプリケーションを停止またはアンデプロイする場合にのみ使用できます。つまり、action="stop"かaction="undeploy"のいずれかも指定する必要があります。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

id

デプロイメントのステータスの取得やデプロイメントの取消しに使用されるID。

デプロイ時に一意のIDをアプリケーションに割り当て、以降の再デプロイ、アンデプロイ、停止などではそのIDを使用します。

この属性を指定しない場合、Antタスクがアプリケーションに一意のIDを割り当てます。

文字列

ignoresessions

このオプションでは、現在のHTTPセッションが完了するのを待機せずに、アプリケーションを直ちに管理モードにします。

この属性は、アプリケーションを停止またはアンデプロイする場合にのみ使用できます。つまり、action="stop"かaction="undeploy"のいずれかも指定する必要があります。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

libImplVer

Java EEライブラリまたはオプション・パッケージの実装のバージョンを指定します。

この属性は、ライブラリまたはパッケージのマニフェスト・ファイルに実装のバージョンが含まれていない場合にのみ使用できます。この属性は、library属性との組み合わせでのみ指定できます。

共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

文字列

library

デプロイメントを共有Java EEライブラリまたはオプション・パッケージとして指定します。Java EEライブラリまたはオプション・パッケージをデプロイまたは分散する場合はlibrary属性を指定する必要があります。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

ブール

libSpecVer

Java EEライブラリまたはオプション・パッケージの仕様のバージョンを指定します。

この属性は、ライブラリまたはパッケージのマニフェスト・ファイルに仕様バージョンが含まれていない場合にのみ使用できます。この属性は、library属性との組み合わせでのみ指定できます。

共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。

文字列

name

デプロイ済みのアプリケーションのデプロイメント名。

この属性を指定しない場合、WebLogic Serverは、アーカイブ・ファイルまたは展開ディレクトリに基づくデプロイメント名をアプリケーションに割り当てます。

文字列

nostage

デプロイメントでnostageデプロイメント・モードを使用するかどうかを指定します。

このモードでは、Antタスクはデプロイメント・ファイルをターゲット・サーバーにコピーせず、source属性で指定された固定の場所に残します。ターゲット・サーバーは、デプロイメント・ファイルの同じコピーにアクセスします。

stage、nostageまたはexternal_stageのいずれかの属性のみを指定できます。何も指定しない場合、管理ターゲット・サーバーに対するデフォルトのデプロイメント・モードはstage、単一のサーバーでの管理サーバーに対するデフォルト・モードはnostageです。

「ステージング・モードによるデプロイメント・ファイルのコピーの制御」を参照してください。

ブール

noversion

wldeploy Antタスクが管理サーバーにあるバージョン関連のすべてのコード・パスを無視することを指定します。この動作は、デプロイメント・ソース・ファイルが(管理サーバーではなく)管理ターゲット・サーバーにあり、external_stageステージング・モードを使用する場合に有用です。

このオプションを使用する場合、バージョン指定されたアプリケーションは使用できません。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

nowait

wldeployが(バックグラウンド・タスクとしてデプロイすることによって)デプロイメント呼出しを行った後、ただちに復帰するかどうかを指定します。

ブール

partition

アプリケーションまたはライブラリに対するデプロイメント処理を実行するリソース・グループに関連付けられているパーティションの名前を指定します。

次のデプロイメント処理のpartition属性を指定できます: deploy、undeploy、redeploy、distribute、startおよびstop。

partition属性はパーティション管理者にとっては省略可能です。

アプリケーションのパーティション・リソース・グループへのデプロイの詳細は、『WebLogic Server MTの使用』のアプリケーションのデプロイに関する項を参照してください。

文字列

password

管理パスワード。

ビルド・ファイルまたはpsなどのプロセス・ユーティリティでパスワードがプレーン・テキストで表示されないようにするには、まずWebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用して有効なユーザー名と暗号化されたパスワードを構成ファイルに格納します。次に、Antビルド・ファイルでusernameとpasswordの両属性を省略します。これらの属性を省略すると、wldeployはデフォルト構成ファイルの値を使用してログインを試みます。

デフォルト以外の構成ファイルとキー・ファイルからユーザー名およびパスワードを取得する場合は、wldeployでuserconfigfile属性およびuserkeyfile属性を使用します。

パスワードの格納と暗号化の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstoreUserConfigのコマンド・リファレンスに関する項を参照してください。

文字列

plan

アプリケーションまたはモジュールをデプロイするときに使用するデプロイメント・プランを指定します。

デフォルトでは、プランが格納されているアプリケーションのルート・ディレクトリからデプロイする場合でも、wldeployは利用可能なデプロイメント・プランを使用しません。

文字列

planversion

デプロイメント・プランのバージョン識別子。

文字列

remote

サーバーが別のマシンに配置されているかどうかを指定します。これはファイル名の転送方法に影響します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです - つまり、Antタスクは、すべてのソース・パスがローカル・マシン上の有効なパスであると見なします。

ブール

removePlanOverride

redeployまたはupdateデプロイメント処理中にオーバーライドされたデプロイメント・プランを削除します。

リソース・グループにデプロイされたアプリケーションまたはライブラリでは、リソース・グループが参照するリソース・グループ・テンプレートで定義されたデフォルト・アプリケーション構成をオーバーライドできます。アプリケーション・オーバーライドを削除するには、removePlanOverride属性を指定します。

redeployデプロイメント処理にremovePlanOverride属性を指定できます。

アプリケーション構成のオーバーライドの詳細は、『WebLogic Server MTの使用』のアプリケーション構成のオーバーライドに関する項を参照してください。

文字列

resourceGroup

アプリケーションまたはライブラリのデプロイメント処理を実行するパーティションまたはドメイン・レベルのリソース・グループの名前を指定します。

deploy処理およびdistribute操作には、resourceGroup属性を設定してアプリケーションまたはライブラリをデプロイまたは配布するリソース・グループの名前を指定する必要があります。パーティションの場合、指定したパーティションに存在するリソース・グループが1つのみの場合、resourceGroup属性は省略可能です。

サポートされているその他のデプロイメント処理の場合、WebLogicサーバーは一意のアプリケーション名からリソース・グループを導出するため、resourceGroup属性は指定しません。

ドメイン・レベルまたはパーティション・レベルでリソース・グループにアプリケーションをデプロイする詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のパーティション・リソース・グループへのアプリケーションのデプロイに関する項を参照してください。

文字列

resourceGroupTemplate

アプリケーションまたはライブラリのデプロイ処理を実行するリソース・グループ・テンプレートの名前を指定します。

次のデプロイメント処理のresourceGroupTemplate属性を指定できます: deploy、undeploy、redeployおよびdistribute。

リソース・グループ・テンプレートにアプリケーションをデプロイする詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のリソース・グループ・テンプレートを使用したアプリケーション・デプロイメントに関する項を参照してください。

文字列

retiretimeout

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。

この属性を指定した場合、ユーザーは、すでに実行中のアプリケーションの新しいバージョンを開始、デプロイ、再デプロイすると見なされます。

詳細については、「本番環境でのアプリケーションの再デプロイメント」を参照してください。

int

securityModel

このデプロイメントで使用するセキュリティ・モデルを指定します。指定可能なセキュリティ・モデルは次のとおりです。

- デプロイメント記述子のみ

- カスタム・ロール

- カスタム・ロールおよびポリシー

- セキュリティ・レルム構成(詳細モデル)

この属性で有効な実際の値はDDOnly、CustomRoles、CustomRolesAndPolicy、またはAdvancedです。

これらのセキュリティ・モデルの詳細は、「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

文字列

source

デプロイするアーカイブ・ファイルまたは展開ディレクトリ。

ファイル

stage

デプロイメントでstageデプロイメント・モードを使用するかどうかを指定します。

このモードでは、Antタスクは、ターゲット・サーバーのステージング・ディレクトリにデプロイメント・ファイルをコピーします。

stage、nostageまたはexternal_stageのいずれかの属性のみを指定できます。何も指定しない場合、管理ターゲット・サーバーに対するデフォルトのデプロイメント・モードはstage、単一のサーバーでの管理サーバーに対するデフォルト・モードはnostageです。

「ステージング・モードによるデプロイメント・ファイルのコピーの制御」を参照してください。

ブール

submoduletargets

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。

この属性の値は、JMSサーバー名のカンマ区切りのリストです。

「JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用」を参照してください。

文字列

targets

アプリケーションがデプロイされるターゲット・サーバーのリスト。

この属性の値は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。

アプリケーションのデプロイ時にターゲット・リストを指定しない場合、ターゲットのデフォルトは管理サーバー・インスタンスになります。

文字列

timeout

デプロイメントが正常に終了するのを待機する最大秒数。

int

upload

デプロイメントの前にソース・ファイルが管理サーバーのアップロード・ディレクトリにコピーされるかどうかを指定します。

この属性は、リモート・マシンで作業していて、デプロイメント・ファイルを管理サーバーに他の手段でコピーできない場合に使用します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

usenonexclusivelock

デプロイメント・アクション(デプロイ、再デプロイ、停止など)が、そのアクションを実行している同じユーザーによってすでに取得されている、ドメインの既存のロックを使用するように指定します。

この属性は、ユーザーが複数のデプロイメント・ツール(Antタスク、コマンド・ライン、WebLogic Server管理コンソールなど)を同時に使用しており、いずれかのツールでドメインのロックをすでに取得している場合に有用です。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです。

ブール

user

管理ユーザー名。

文字列

userconfigfile

管理ユーザー名および管理パスワードを取得するために使用するユーザー構成ファイルの場所を指定します。このオプションは、プレーン・テキストのパスワードをインラインまたはpsなどのプロセス・レベルのユーティリティで表示したくない場合に、ビルド・ファイルでuserおよびpassword属性のかわりに使用します。

userconfigfile属性を指定する前に、『WebLogic Server WLSTコマンド・リファレンス』の説明に従い、WebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用して、まずファイルを生成する必要があります。

文字列

userkeyfile

ユーザー構成ファイル(userconfigfile属性)に格納されたユーザー名とパスワードの情報を暗号化および復号化するために使用するユーザー・キー・ファイルの場所を指定します。

userkeyfile属性を指定する前に、『WebLogic Server WLSTコマンド・リファレンス』の説明に従い、WebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用して、まずキー・ファイルを生成する必要があります。

文字列

verbose

wldeployで詳細出力メッセージを表示するかどうかを指定します。

ブール

ネストされた<files>子要素

wldeploy Antタスクには、デプロイメント・アクションの実行対象となるファイルのリスト(アンデプロイするJSPのリストなど)を指定するためにネストできる<files>子要素もあります。

注意:

WebLogic Serverリリース9.0以降では、<files>を使用してアプリケーションのファイルのリストを再デプロイすることは非推奨になりました。この場合、代わりにwldeployのdeltaFiles属性を使用します。

<files>要素は、実際のタスク名の違いを除いて、標準的な<fileset> Antタスクと同じ処理を行います。したがって、<files>要素で指定可能な属性のリファレンス情報については、Apache Ant Webサイト(http://ant.apache.org/manual/Types/fileset.html)を参照してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。