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

11g リリース1 (10.3.6)

B60990-05(原本部品番号:E13706-07)

目次

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

はじめに

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

- 表記規則

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

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

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

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

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

- サーブレット

- JavaServer Pages

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

- Enterprise JavaBeanモジュール

- EJBの概要

- EJBとWebLogic Server

- コネクタ・モジュール

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

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

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

- WebLogic Webサービス

- JMSおよびJDBCモジュール

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

- 外部診断記述子の使用

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

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

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

- EJBGen

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

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

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

- 開発ソフトウェア

- 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

- libclasspath Antタスクの使用

- libclasspathタスクの定義

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

- libclasspathの主な属性

- ネストされるlibclasspathの要素

- librarydir

- library

- libclasspath Antタスクの例

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

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

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

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

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

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

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

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

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

- Webアプリケーション

- EJB

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

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

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

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

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

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

- weblogic.BuildXMLGen構文

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

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

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

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

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

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

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

- wlcompile Antタスクの属性

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

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

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

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

- wlappc Antタスクの属性

- wlappc Antタスクの構文

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

- weblogic.appcリファレンス

- weblogic.appcの構文

- weblogic.appcのオプション

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

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

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

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

- wlpackage Antタスクの例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 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

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

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

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

- クラスのロード

- prefer-web-inf-classes要素

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

- クラス・キャッシュの構成

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

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

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

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

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

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

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

- ネスティングの深さ

- モジュール・タイプ

- 重複エントリ

- インタフェース

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

- 処理中の作業

- 開発用途のみ

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

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

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

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

- FilteringClassLoaderの構成

- リソースのロード順序

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

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

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

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

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

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

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

9 共有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ライブラリを使用する場合のベスト・プラクティス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- JavaMail構成ファイルの理解

- WebLogic Server用のJavaMailの構成

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

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

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

- WebLogic Serverでのスレッドの使い方

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

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

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® Fusion Middleware

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

11g リリース1 (10.3.6)

B60990-05(原本部品番号:E13706-07)

2011年11月

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

Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発, 11g リリース1(10.3.6)

B60990-05

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

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

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

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

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

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

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

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

はじめに

ここでは、このガイド『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診断フレームワーク・モジュール

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

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

- 開発ソフトウェア

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

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

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

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

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

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

オラクル社は、次のように説明しています。Java EE 5の焦点は、開発の容易さにあります。Java EE 5では、記述するコードが少なくなっています。定型コードの多くは削除され、可能な限りデフォルト値が使用され、アノテーションを広範に使用することによって、デプロイメント記述子の必要性が低減されています。

- EJB 3.0では、EJBをより簡単にプログラミングできます。具体的には、必要となるプログラミング・アーティファクトの数を減らし、Beanファイルをより簡単かつ直感的にプログラミングできるようにするEJB固有のメタデータ・アノテーションのセットが導入されています。EJB 3.0のもう1つの目標は、永続性フレームワークを標準化し、エンティティBeanプログラミング・モデルとオブジェクト・リレーショナル(O/R)マッピング・モデルの複雑さを軽減することです。WebLogic Serverでは、EJB仕様バージョン2.1も引続きサポートされています。

- Java EE 5では、簡略化されたWebサービスがサポートされると共に、最新のWebサービスAPIが含まれており、サービス指向アーキテクチャ(SOA)には理想的な実装プラットフォームとなっています。

- JavaServer Faces (JSF)技術とJSP Standard Tag Library (JSTL)によって、Webアプリケーションが簡単に構築できるようになっています。Java EE 5では、AJAXなど、Web 2.0向けのアプリケーション構築のために豊富なシン・クライアント技術がサポートされています。

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

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

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

詳細は、Java EE仕様(http://docs.oracle.com/javaee/5/api/)を参照してください。

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

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

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

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

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

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

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

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

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

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

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)は、ビジネス・タスクまたはエンティティを実装するサーバー側Javaモジュールで、EJB仕様に基づいて記述されています。EJBには、セッションBean、エンティティBean、およびメッセージドリブンBeanの3種類があります。

Enterprise JavaBeans (EJB) 3.0は、コンポーネント・ベースのビジネス・アプリケーションを開発およびデプロイメントするためのJava EE 5技術です。EJB 2.Xは強力で有用な技術ですが、プログラミング・モデルは複雑でわかりにくく、非常に単純なEJBでも複数のJavaファイルとデプロイメント記述子を作成する必要がありました。このような複雑さが、EJBの普及を妨げていました。

そのため、EJB仕様バージョン3.0では、EJBをより簡単にプログラムできるようにすることが目標の1つになっています。具体的には、必要となるプログラミング・アーティファクトの数を減らし、Beanファイルをより簡単かつ直感的にプログラミングできるようにするEJB固有のメタデータ・アノテーションのセットが導入されています。EJB 3.0仕様のもう1つの目標は、永続性フレームワークを標準化し、エンティティBeanプログラミング・モデルとオブジェクト・リレーショナル(O/R)マッピング・モデルの複雑さを軽減することです。

Enterprise JavaBeans 3.0の詳細は、Oracle WebLogic Server WebLogic Enterprise JavaBeansバージョン3.0のプログラミングを参照してください。

Enterprise JavaBeans 2.Xの詳細は、「Enterprise JavaBeansの理解」を参照してください。

EJBの概要

セッションBeanは、単一のセッション時に単一のクライアントに代わって特定のビジネス・タスクを実行します。セッションBeanは、ステートフルにもステートレスにもなりますが、永続的ではありません。クライアントでセッションBeanの利用が終わると、そのBeanは消えてなくなります。

エンティティBeanは、データ・ストア(通常はリレーショナル・データベース・システム)のビジネス・オブジェクトを表します。永続性(データのロードと保存)は、Beanで管理される場合とコンテナで管理される場合があります。データ・オブジェクトをメモリー内で表現するだけではなく、エンティティBeanにはそれらが表すビジネス・オブジェクトの動作をモデル化するメソッドがあります。エンティティBeanは、複数のクライアントで同時にアクセスでき、当然ながら永続的です。

コンテナは、メッセージドリブンBeanのインスタンスを作成するか、またはインスタンスをプールから割り当てて、メッセージを処理します。JMS宛先でメッセージが受信されると、メッセージドリブンBeanではメッセージを処理するためにそれ自身のインスタンスがプールから割り当てられます。メッセージドリブンBeanは、クライアントとは関連付けられません。それらは単に到着したメッセージを処理するだけです。

EJBとWebLogic Server

Java EEでは、EJB仕様をサポートするEJBサーバーの間でモジュールを確実に移植できるように、開発とデプロイメントのロールが明確に区別されます。WebLogic ServerにEJBをデプロイするには、そのEJBのセキュリティ、トランザクション、およびライフ・サイクルの各ポリシーを実行するクラスを生成するWebLogic Server appcコンパイラが動作している必要があります。「wlappcを使用したモジュールおよびアプリケーションのビルド」を参照してください。

Java EE指定のデプロイメント記述子ejb-jar.xmlでは、EJBアプリケーションにパッケージ化されたエンタープライズBeanが記述されます。この記述子では、Beanのタイプと名前、そしてホーム・インタフェースとリモート・インタフェースおよび実装クラスの名前が定義されます。また、ejb-jar.xmlデプロイメント記述子では、Beanのセキュリティ・ロールおよびBeanのメソッドのトランザクション動作も定義されます。

追加のデプロイメント記述子では、WebLogic固有のデプロイメント情報が提供されます。コンテナ管理のエンティティBean固有のweblogic-cmp-rdbms-jar.xmlデプロイメント記述子では、Beanがデータベースの表にマップされます。weblogic-ejb-jar.xmlデプロイメント記述子では、JNDIバインド名、クラスタリングやキャッシュの構成などのWebLogic Server環境に固有の追加情報が提供されます。

コネクタ・モジュール

コネクタ(別称リソース・アダプタ)には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 5.0アノテーション機能を使用します(http://docs.oracle.com/javaee/5/api/を参照)。第7章「Java EEアノテーションと依存関係インジェクションの使用」を参照してください。

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

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

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

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

- 開発が目的の場合は、WebLogic分割開発ディレクトリ構造をお薦めします。単一のアーカイブEARファイルまたは展開されたEARディレクトリ構造ではなく、分割開発ディレクトリではソース・ファイルと出力ファイルを分離する2つの並列ディレクトリが存在します。このディレクトリ構造は、単一のWebLogic Serverインスタンスでの開発用に最適化されています。第3章「分割開発ディレクトリ環境の作成」を参照してください。Oracleで提供されるwlpackage Antタスクを使用すると、JARユーティリティを使用することなくEARを作成できます。これは分割開発ディレクトリ構造のみを対象としています。「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オブジェクト)クラスで定義されるアノテーションから、モジュールを推測します。付録A「エンタープライズ・アプリケーションのデプロイメント記述子の要素」を参照してください。

WebLogic Webサービス

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

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

- Web上のサーバーによってホストされるWebサービス実装。WebLogic Webサービスは、WebLogic Serverによってホストされます。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構成ファイルに構成されます。

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

外部診断記述子の使用

WLSでは、外部診断記述子を使用できるため、診断記述子をインポートしていないアプリケーションに診断機能を統合することも可能です。この機能では、デプロイメント・ビュー、およびアプリケーションまたはモジュールのデプロイメントがサポートされ、デプロイメント・プラン(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に配置します。

XMLデプロイメント記述子

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

このJava EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナ用のJDK 5.0アノテーション機能を使用します。(http://docs.oracle.com/javaee/5/api/を参照)。アノテーションを使用すると、コンテナ内でのコンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、以前のバージョンのWebアプリケーション(2.4以前)、エンタープライズ・アプリケーション(1.4以前)、およびEnterprise JavaBeans (2.x以前)で必要だったデプロイメント記述子にかわるものです。第7章「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.2/weblogic-javaee.xsdスキーマの要素も含まれています。

最新のスキーマ情報は、Oracle WebLogic Serverスキーマ・ホームページ(http://www.oracle.com/technetwork/index.html)を参照してください。

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

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

スコープ

デプロイメント記述子

Webアプリケーション

Java EE

web.xml

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsdでServlet 2.5 Schemaを参照してください。

WebLogic

weblogic.xml

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

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

エンタープライズBean 3.0

Java EE

ejb-jar.xml

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

WebLogic

weblogic-ejb-jar.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.2/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 WebLogic Enterprise JavaBeansバージョン3.0のプログラミングを参照してください。

エンタープライズBean 2.1

Java EE

ejb-jar.xml

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

WebLogic

weblogic-ejb-jar.xml

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

Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミングの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 WebLogic Enterprise JavaBeansのプログラミングのweblogic-cmp-rdbms-jar.xmlデプロイメント記述子に関する項を参照してください。

Webサービス

Java EE

webservices.xml

http://java.sun.com/xml/ns/javaee/javaee_web_services_1_2.xsdでWeb Services 1.2 Schemaを参照してください。

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://java.sun.com/xml/ns/j2ee/connector_1_5.xsdでConnector 1.5 Schemaを参照してください。

WebLogic

weblogic-ra.xml

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

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

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

Java EE

application.xml

http://java.sun.com/xml/ns/javaee/application_5.xsdでApplication 5 Schemaを参照してください。

WebLogic

weblogic-application.xml

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

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

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

Java EE

application-client.xml

http://java.sun.com/xml/ns/javaee/application-client_5.xsdでApplication Client 5 Schemaを参照してください。

WebLogic

application-client.xml

スキーマ: http://xmlns.oracle.com/weblogic/weblogic-application-client/1.2/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.2/weblogic-jms.xsd

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

JDBCモジュール

WebLogic

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

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

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

デプロイメント・プラン

WebLogic

plan.xml

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

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

WLDFモジュール

WebLogic

weblogic-diagnostics.xml

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

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

モジュールまたはアプリケーションをパッケージ化する場合は、デプロイメント記述子を格納するディレクトリ(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 WebLogic Enterprise JavaBeansのプログラミングの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.PlanGeneratorよりも高い柔軟性があります。

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

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

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

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

開発ソフトウェア

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

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://ant.apache.org/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スクリプトを作成するクロス・プラットフォーム・スクリプトの使い方については、WL_HOME/samples/server/examples/src/examples/ejb20/basic/beanManaged/build.xmlなどの任意のWebLogic Serverサンプルを参照してください。

また、Antを使ってサンプルを構築する方法を説明したWebLogic Serverドキュメント(WL_HOME/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\wlserver_10.xなど)です。

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 Fusion Middleware Supported System Configurations」(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)を参照してください。

Webブラウザ

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

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

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

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

サード・パーティのソフトウェア製品を使用して、WebLogic Server開発環境を強化することができます。アプリケーション・サーバーをサポートする製品の開発者ツール情報の詳細は、「WebLogic Developer Tools Resources」(http://www.oracle.com/technetwork/developer-tools/index.html)を参照してください。

注意:

ソフトウェア・ベンダーに問い合わせて、使用しているプラットフォームと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 NTでは、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"/>

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_10.3)。

ファイル

いいえ

servername

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

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

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

文字列

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

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です - その場合、Antタスクはタイムアウトしません。

long

いいえ

timeoutSeconds

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

この属性のデフォルト値は0です - その場合、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ドメインを構成する方法について説明します。

注意::

wlconfig Antタスクは、MBeanサーバーと互換性のあるMBeanに対してのみ機能しますが、これはWebLogic Server 9.0以降では非推奨になりました。具体的には、wlconfig Antタスクは非推奨の独自APIであるweblogic.management.MBeanHomeを使用してWebLogic MBeanにアクセスするので、wlconfigは、MBeanを探す際に標準のJMXインタフェース(javax.management.MBeanServerConnection)を使用しません。つまり、wlconfigを使用してアクセスできるMBeanは、WebLogic Server MBeanリファレンスの非推奨になったMBeanのカテゴリにリストされているもののみということになります。

同等の機能を実現するには、WebLogic Scripting Tool (WLST)を使用する必要があります。『Oracle 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="weblogic">
</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サンプルで使用するようなリソースを定義したドメインが作成されます。『Oracle 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 Scripting Toolコマンド・リファレンスのstoreUserConfigのコマンド・リファレンスに関する項を参照してください。

文字列

いいえ

failonerror

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

ブール

いいえ

userconfigfile

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

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

ファイル

いいえ

userkeyfile

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

userkeyfile属性を指定する前に、WebLogic Scripting Toolコマンド・リファレンスの説明に従い、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属性で指定したメソッドに渡される引数のリスト(スペース区切り)。

文字列

いいえ

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-1 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>
.
.
.

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

次の項では、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コードからデプロイメント記述子ファイルを生成することができます。

図3-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は、アプリケーションのビルド・ディレクトリの最上位の位置にある.beabuild.txtファイルを調べてソース・ディレクトリの位置を確認します。ソース・ディレクトリを移動した場合は、.beabuild.txtファイルを編集して新しいソース・ディレクトリ名を指定してください。

「wldeployを使用したアプリケーションのデプロイメント」では、分割ディレクトリ環境からのデプロイメントを自動化するために使用できるwldeploy Antタスクが説明されています。

図3-2では、一般的なデプロイメント・プロセスを示します。このプロセスは、WebLogic Serverのツールでビルド・ディレクトリを指定することから始まります。この図で、コンパイルされたクラスと生成されたデプロイメント記述子はすべてビルド・ディレクトリにありますが、他のアプリケーション・リソース(静的ファイルや編集可能なデプロイメント記述子など)はどこにあるかわかりません。WebLogic Serverは隠された.beabuild.txtファイルを使用して、必要なリソースのあるアプリケーションのソース・ディレクトリを見つけます。

図3-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のインストール先の最上位ディレクトリです。

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

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

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

ディレクトリの例は、WL_HOME\samples\server\examples\src\examples\splitdirにインストールされたsplitdirサンプル・アプリケーションから利用します。WL_HOMEはWebLogic Serverのインストール・ディレクトリです。

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

次の図は、Webアプリケーション、EJB、共有ユーティリティ・クラスおよびサード・パーティ・ライブラリを持つエンタープライズ・アプリケーションのソース・ディレクトリの内容をまとめたものです。以降の項では、エンタープライズ・ソース・ディレクトリの個々の要素がどのように配置されるのかを詳しく説明します。

図3-3 エンタープライズ・アプリケーションのソース・ディレクトリの概要

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

分割開発ディレクトリ・プロジェクトの最上位ソース・ディレクトリは、エンタープライズ・アプリケーションを表します。次の図は、このディレクトリに必要な最小限のファイルとディレクトリを示しています。

図3-4 エンタープライズ・アプリケーションのソース・ディレクトリ

次の項で説明されるように、エンタープライズ・アプリケーション・ディレクトリには、Webアプリケーション、EJB、ユーティリティ・クラス、サード・パーティJarファイルなどを保持する1つまたは複数のサブディレクトリもあります。

Webアプリケーション

Webアプリケーションは、次の図に示されている基本的なソース・ディレクトリ・レイアウトを使用します。

図3-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は、次の図に示されているソース・ディレクトリ・レイアウトを使用します。

図3-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アプリケーションなどのアプリケーション・モジュールで使用されるライブラリです。

図3-7 Javaユーティリティ・クラスのディレクトリ

Javaユーティリティ・クラスのソースは、エンタープライズ・アプリケーションの最上位ディレクトリの指定したサブディレクトリに配置します。その指定のサブディレクトリの下では、標準のパッケージ・サブディレクトリ規約を使用します。

ビルド・プロセスの過程で、wlcompile Antタスクはjavacコンパイラを呼び出し、Javaクラスをビルド・ディレクトリの下のAPP-INF/classes/ディレクトリにコンパイルします。その結果、デプロイされているアプリケーションの他のモジュールからそれらのクラスが利用可能になります。

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

エンタープライズ・アプリケーションを拡張してサード・パーティの.jarファイルを使用するには、それらのファイルを次のようにAPP-INF\lib\ディレクトリに配置します。

図3-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ライブラリのビルド・ターゲットを作成します。第9章「共有Java EEライブラリおよびオプション・パッケージの作成」を参照してください。

- -username <username> - デプロイ・コマンドのためのユーザー名。

- -password <password> - ユーザー・パスワード。

weblogic.BuildXMLGenを実行した後は、生成されたbuild.xmlファイルを編集して開発環境のプロパティを指定します。編集する必要のあるプロパティについては、次の例を参照してください。

例3-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コマンドを入力することでコマンド・プロンプトで表示できます。

例3-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ソース・ディレクトリとビルド・ディレクトリは、WL_HOME/samples/server/medrecにインストールされます。WL_HOMEは、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サンプル・アプリケーションでは、次の図に示されているようにこの方式を使用します。

図3-9 MedRecの共有JARファイル

MedRecは、プロジェクトの複数のEARで共有されるユーティリティ・クラスでも同様のアプローチをとります。ユーティリティ・クラスのソースをそれらを必要とする各earのスコープの中に置くのではなく、MedRecはユーティリティ・クラスのソースをすべてのEARから独立して維持します。ユーティリティ・クラスをコンパイルした後、構築スクリプトはそれらをアーカイブし、ビルド・ディレクトリのそれらのクラスを使用する各EARのAPP-INF/LIBサブディレクトリにJARをコピーします(図3-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を開発用コンピュータにインストールします。

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

次の項では、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コンポーネントを出力ディレクトリにコンパイルします。

WL_HOME\samples\server\examples\build\helloWorldEar\APP-INF\classes\

WL_HOMEは、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タスクの属性

表4-1では、wlcompile固有のAntタスクの属性を示します。

表4-1 wlcompile Antタスクの属性

属性

説明

srcdir

ソース・ディレクトリ。

destdir

ビルド/出力ディレクトリ。

classpath

wlcompileで使用されるクラスパスを変更できます。

includes

ビルドから特定のディレクトリを含めることができます。

excludes

ビルドから特定のディレクトリを除外できます。

librarydir

クラスパスに追加するための共有Java EEライブラリのディレクトリを指定します。第9章「共有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サービスを使用するプログラムのコンパイルに必要なSun、WebLogic、およびその他のJavaクラスは、インストールしたWebLogic Serverのlibディレクトリのweblogic.jarファイルにパッケージ化されます。weblogic.jarファイル以外にも、コンパイラのCLASSPATHに以下を組み込みます。

- JDKディレクトリ内のlib\tools.jarファイル、または使用するJava開発キットに必要なその他の標準Javaクラス。

- Apache Antのexamples.propertyファイル(サンプル環境用)。このファイルについては、samples\server\examples\src\examples\examples.htmlにあるAntを使用してのサンプルの構築に関するWebLogic Serverドキュメントで説明されています。

- サード・パーティJavaツールまたはプログラムがインポートするサービスのクラス。

- コンパイルするプログラムによって参照されるその他のアプリケーション・クラス。

wlcompileとwlappcのライブラリ要素

library要素は、アプリケーションのビルドに必要な共有Java EEライブラリを表すモジュールの名前とオプションのバージョン情報の定義に使用されるオプションの要素です(第9章「共有Java EEライブラリおよびオプション・パッケージの作成」を参照)。library要素は、wlcompileおよびwlappcの両方とともに使用できます(「wlappcを使用したモジュールおよびアプリケーションのビルド」を参照)。

名前とバージョン情報は、ライブラリ要素の属性(「表4-2」を参照)として指定されます。

表4-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コンパイラは、デプロイメント用にJSPとコンテナ固有のEJBクラスを生成し、現在のJava EE仕様に準拠するためにデプロイメント記述子を検証します。appcは、モジュール間の検証チェックに加え、アプリケーション・レベルのデプロイメント記述子とアプリケーション内の個々のモジュールの間の検証チェックを実行します。

また、オプション・パッケージは、appcでJava EE共有ライブラリとしてサポートされます。そのため、オプション・パッケージ参照の検索では、アプリケーションおよびそのモジュールのすべてのマニフェストがスキャンされます。

wlappcは、weblogic.appcコンパイラに対するAntタスク・インタフェースです。次の項では、wlappcのオプションと使用方法について説明します。weblogic.appcとwlappc Antタスクは、エンタープライズ・アプリケーションを記述するapplication.xmlデプロイメント記述子に表示されている順番でモジュールをコンパイルします。

wlappc Antタスクの属性

表4-3では、wlappc固有のAntタスクのオプションを示します。これらのオプションは、weblogic.appcコマンド・ライン・オプションと似ていますが、いくつかの点で違いがあります。

注意:

weblogic.appcオプションのリストについては、「weblogic.appcリファレンス」を参照してください。

「wlcompileとwlappcのライブラリ要素」を参照してください。

表4-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ライブラリのディレクトリを指定します。第9章「共有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}" />

以下は、表4-3の2つのオプション(idlおよびidlOrverWrite)を呼び出すwlappc Antタスク・コマンドの例です。

<wlappc source="${dest.dir}"idl="true" idlOrverWrite="true" />

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

appcとwlappcでは、構文にいくつかの違いがあります。appcの場合、コマンド内に存在するフラグはブールです。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

高度な使用オプションを出力します。

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

次の項では、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ファイルを作成すると自動的に作成されます。

詳細なコマンドのリファレンスについては、付録B「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タスクの属性について説明します。

表5-1 wlpackage Antタスクの属性

属性

説明

データ型

必須?

tofile

wlpackage Antタスクによってパッケージ化された分割開発ディレクトリ・アプリケーションのEARアーカイブ・ファイルの名前。

文字列

tofileまたはtodirのどちらかの属性を指定する必要があります。

todir

wlpackage Antタスクによってパッケージ化された分割開発ディレクトリ・アプリケーションの展開ディレクトリの名前。

文字列

tofileまたはtodirのどちらかの属性を指定する必要があります。

srcdir

分割開発ディレクトリ・アプリケーションのソース・ディレクトリを指定します。

ソース・ディレクトリには、プロジェクトのすべての編集可能なファイル(Javaソース・ファイル、編集可能な記述子ファイル、JSP、静的コンテンツなど)が格納されます。

文字列

はい。

destdir

分割開発ディレクトリ・アプリケーションのビルド・ディレクトリを指定します。

既に、ソース・ディレクトリに対してwlcompile Antタスクを実行し、必要なコンポーネントがビルド・ディレクトリに生成されていることが前提となります。必要なコンポーネントとしては、コンパイル済みのJavaクラス、生成されたデプロイメント記述子などがあります。

文字列

はい。

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

次の項では、本番再デプロイメント方式を使用してアプリケーションをプログラムおよび管理する方法について説明します。

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

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

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

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

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

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

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

本番再デプロイメントを使用すると、デプロイされたアプリケーションを停止せずに(アプリケーションのクライアントへの可用性を中断することなく)、本番環境でアプリケーションの新しいバージョンを再デプロイできます。本番再デプロイメントのしくみは、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイすることです。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が、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文字までの長さを指定できます。文字列は、表6-1で示す有効な文字で構成する必要があります。

表6-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で利用できる読取り専用属性を示します。

表6-2 ApplicationMBeanの読取り専用のバージョン属性

属性名

説明

ApplicationName

アプリケーションのデプロイメント名を表す文字列

VersionIdentifier

同じアプリケーションのすべてのバージョンの中から、現在のアプリケーションのバージョンを一意に識別する文字列

ApplicationIdentifier

デプロイされたすべてのアプリケーションおよびバージョンの中から、現在のアプリケーションのバージョンを一意に識別する文字列

ApplicationRuntimeMBeanでも、新しい読取り専用属性のバージョン情報を利用できます。次の表を参照してください。

表6-3 ApplicationRuntimeMBeanの読取り専用のバージョン属性

属性名

説明

ApplicationName

アプリケーションのデプロイメント名を表す文字列

ApplicationVersion

アプリケーションのバージョンを表す文字列

ActiveVersionState

アクティブなアプリケーション・バージョンの現在の状態を示す整数。アクティブなバージョンの有効な状態は次のとおりです。

- ACTIVATED - アプリケーションの1つまたは複数のモジュールがアクティブで、新しいクライアント・リクエストで使用可能になっていることを示します。

- PREPARED - WebLogic Serverが、アプリケーションの1つまたは複数のモジュールを準備しているものの、まだアクティブになっていないことを示します。

- UNPREPARED - アプリケーションのどのモジュールも準備されておらず、アクティブになっていないことを示します。

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

管理者が本番再デプロイメント・プロセスを逆転させる場合もあるため、現在アクティブなバージョンが、最後にデプロイされたバージョンに対応しているとは限りません。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番再デプロイメント・プロセスのロールバックに関する項を参照してください。

7 Java EEアノテーションと依存関係インジェクションの使用

次の項では、メタデータ・アノテーションと依存関係インジェクションの概念について説明します。

- アノテーションの処理

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

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

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

アノテーションの処理

Java EEアノテーションの使用により、標準のapplication.xmlおよびweb.xmlデプロイメント記述子は省略可能になりました。このJava EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、およびJSPなどのWebコンテナ用のJDK 5.0アノテーション機能を使用します。(http://download.oracle.com/javaee/5/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アノテーションを付けることができます。コンテナは、必要に応じて環境エントリを解放し、インジェクション・フィールドまたはメソッドに使用されるプリミティブ型に一致させます。例7-1では、アプリケーション・コンポーネントで@Resourceアノテーションを使用して環境エントリを宣言する方法を示しています。

例7-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 WebLogic Enterprise JavaBeansバージョン3.0のプログラミングを参照してください。

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に注入されます。このアノテーションをクラスに適用すると、コンポーネントが実行時にルックアップするリソースが宣言されます。

属性

表7-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アノテーションは、複数のリソース宣言のコンテナとして機能します。

属性

表7-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で管理コンソールを使用して作成できます。詳細は、「セキュリティ・ロールの管理」を参照してください。

属性

表7-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で管理コンソールを使用して作成できます。詳細は、「セキュリティ・ロールの管理」を参照してください。

属性

表7-4 javax.annotation.security.RolesAllowedアノテーションの属性

名前

説明

データ型

必須?

value

Java EEコンテナのメソッドにアクセスできるセキュリティ・ロールのリストを指定します。

String[]

はい

javax.annotation.security.RunAs

ターゲット: クラス

Java EEコンテナを実際に実行するセキュリティ・ロールを指定します。

指定するセキュリティ・ロールは、WebLogic Serverのセキュリティ・レルム内に存在し、ユーザーまたはグループにマッピングされている必要があります。詳細は、「セキュリティ・ロールの管理」を参照してください。

属性

表7-5 javax.annotation.security.RunAsアノテーションの属性

名前

説明

データ型

必須?

value

Java EEコンテナが実行されるセキュリティ・ロールを指定します。

文字列

はい

8 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開発キット(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が発生します。

例8-1はprefer-web-inf-classes要素とその定義およびデフォルト値を示します。

例8-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アプリケーションのクラスローディング」で、このトピックについて説明しています。

クラス・キャッシュの構成

WebLogic Serverは、起動を高速化するためにクラス・キャッシュを有効にできます。キャッシュを有効にすると、サーバーは特定の基準に達するまでロードされるすべてのクラスを記録し、クラス定義を非表示のファイルに保持します。サーバーを再起動すると、キャッシュの有効性が既存のコード・ソースによりチェックされます。そして、サーバーは実行回数に記録されたクラスと同じ一連のクラスをバルク・ロードするためキャッシュ・ファイルを使用します。システム・クラスパスまたはその内容を変更すると、キャッシュは無効になり、サーバー再起動時に再作成されます。

クラス・キャッシュを使用する利点は次のとおりです。

- サーバーの起動時間が短縮されます。

- パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。

キャッシュは、最適化方法を使用して初期キャッシュ記録時間を最小化します。特定のクラスが記録されるまでキャッシュの記録は続行されます。

注意:

startWebLogicスクリプトを使用することで、クラス・キャッシュはサーバーの起動時に開発モードでサポートされます。デフォルトでは、クラス・キャッシュは無効になっており本番モードではサポートされません。開始時間の短縮はベンダーによって異なります。

1. クラス・キャッシュを有効にするには、startWebLogicスクリプトで環境変数(UNIXの場合CLASS_CACHE=true、Windowsの場合set CLASS_CACHE=true)を設定します。

2. 次のプロパティを使用して、クラス・キャッシュを構成します。

- ロギング: クラス・キャッシュの問題をデバッグするには、キャッシュを有効にする起動スクリプトの項に対してJAVA_OPTIONSで次のシステム・プロパティを配置することによりロギングを作動します。
-Dclass.load.log.level=finest -Dclass.load.log.file=/tmp/class-load-log.txt

ロギングには、詳細、より詳細、最も詳細の3つのレベルがあります。通常のキャッシュ操作中にロギングを有効にしないでください。ロギングするとサーバーの起動が遅くなります。デバッグするときのみロギングを使用します。

- 記録制限: クラス・キャッシングの記録制限が特定のクラスに設定されていますが、このクラスはユーザーの環境で別のクラスに構成できます。
-Dlaunch.complete=<fully qualified class name> たとえば、com.oracle.component.Foo

このプロパティで使用するクラスは、WebLogic Serverのクラスパスにある必要があります。

例8-2は、クラス・キャッシュが有効でロギングが選択された状態で修正したUNIXおよびWindowsのstartWebLogicスクリプトを示します。

例8-2 startWebLogicスクリプト

On UNIX

# CLASS CACHING
CLASS_CACHE=true
if [ "${CLASS_CACHE}" = "true" ] ; then
echo "Class caching enabled..."
JAVA_OPTIONS="${JAVA_OPTIONS} -Dlaunch.main.class=${SERVER_CLASS}
-Dlaunch.class.path="${CLASSPATH}"
-Dlaunch.complete=weblogic.store.internal.LockManagerImpl
-Dclass.load.log.level=finest
-Dclass.load.log.file=/tmp/class-load-log.txt
-cp ${WL_HOME}/server/lib/pcl2.jar"
export JAVA_OPTIONS
SERVER_CLASS="com.oracle.classloader.launch.Launcher"
fi

On Windows

@REM CLASS CACHING
set CLASS_CACHE=true
if "%CLASS_CACHE%"=="true" (
echo Class caching enabled...
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dlaunch.main.class=%SERVER_CLASS%
-Dlaunch.class.path="%CLASSPATH%" -Dclass.load.log.level=finest
-Dclass.load.log.file=C:\class-load-log.txt
-Dlaunch.complete=weblogic.store.internal.LockManagerImpl
-cp %WL_HOME%\server\lib\pcl2.jar
set SERVER_CLASS=com.oracle.classloader.launch.Launcher
)

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アプリケーションのクラスローディング概念を示しています。

図8-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クラスローダーを示していません。

図8-2 標準的なクラスローダーの階層

この階層は、EJB呼出し時にcall-by-referenceセマンティクスを使用できるようになるため、大半のアプリケーションにとって最適です。また、これにより他のモジュールに影響を与えることなくWebモジュールを個別に再ロードできるようになります。さらに、Webモジュールの1つで実行されているコードが、任意のEJBモジュールからのクラスをロードできるようになります。これは、使用しているEJBのインタフェースがWebモジュールに含まれることを防げるため便利です。これらの利点のいくつかは、厳密にはJava EEに準拠していないことに注意してください。

カスタム・モジュール・クラスローダーを作成できると、以下のことが可能になる代替的なクラスローダー構成を宣言するメカニズムが得られます。

- 個々のEJBモジュールを単独で再ロード

- モジュールのグループを、一緒に再ロード

- 特定のWebモジュールとEJBモジュールの親子関係を逆転

- EJBモジュール間でネームスペースを分離

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

Weblogic固有のアプリケーション・デプロイメント記述子weblogic-application.xml内でクラスローダーの階層を宣言できます。

この宣言のDTDは次のとおりです。

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

<!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要素の詳細は、付録A「エンタープライズ・アプリケーションのデプロイメント記述子の要素」を参照してください。

以下は、クラスローダーの宣言例です(weblogic-application.xmlのclassloader-structure要素で定義)。

例8-4 クラスローダーの宣言例

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

ネスティングの構成は、クラスローダーの階層を示します。上記のスタンザにより、次の図に示す階層がもたらされます。

図8-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)が含まれています。これは、前の項で説明した一般的なアプリケーション階層におけるサブツリーと考えられます。

図8-4 単一のEJBモジュールのクラスローダー階層の例

展開されたアプリケーションのルートを基準とした相対的な場所にあるファイルの部分的な更新を実行するには、次のコマンド・ラインを使用します。

例8-5 部分的ファイル更新の実行

java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy myejb/foo.class

-redeployコマンドの後で、更新したい展開アプリケーションのルートを基準として相対的にファイルのリストを指定します。これは、(上記のような)特定の要素へのパスであっても、モジュール(または任意の要素およびモジュールのセット)へのパスであってもかまいません。例:

例8-6 更新のための相対ファイル・リストの指定

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の構成

- リソースのロード順序

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

FilteringClassLoaderは、デプロイメント記述子を構成することで、特定のパッケージがシステム・クラスローダーによってロードされるのではなく、常にアプリケーションからロードされるように明示的に指定するメカニズムです。これによって、XercesやAntなどの代替バージョンのアプリケーションを使用できるようになります。FilteringClassLoaderを使用することにより、サード・パーティJARをバンドルしてアプリケーションに使用できますが、javaxパッケージまたはweblogicパッケージ内のクラスのようなAPIクラスに対してフィルタ処理を行うことはお薦めしません。

FilteringClassLoaderはアプリケーション・クラスローダーとシステム・クラスローダーの間に位置します。システム・クラスローダーの子であり、アプリケーション・クラスローダーの親となります。FilteringClassLoaderはloadClass(String className)メソッドをインターセプトして、weblogic-application.xmlファイルに指定されているパッケージのリストとclassNameを比較します。パッケージとclassNameが一致する場合、FilteringClassLoaderはClassNotFoundExceptionをスローします。この例外は、このクラスをアプリケーションからロードするようにアプリケーション・クラスローダーに通知します。

FilteringClassLoaderの構成

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」を参照してください。

フィルタリング・クラスローダーの構成のヘルプは、 「クラスローダー分析ツール(CAT)の使用」に関する項を参照してください。

リソースのロード順序

リソースのロード順序は、java.lang.ClassLoaderのgetResource()およびgetResources()メソッドがリソースを戻す順序です。フィルタが有効になっている場合、この順序はフィルタ処理が無効な場合とは若干異なります。フィルタが有効になっているということは、FilteringClassLoaderに1つまたは複数のパッケージ・パターンがあることを意味しています。フィルタがない場合(デフォルト)、リソースはクラスローダー・ツリーの上から下へという順序で収集されます。たとえば、Web (1)がリソースをリクエストすると、リソースはシステム(3)、アプリケーション(2)、Web(1)の順序でグループ化されます。図8-7を参照してください。

図8-7 システム・クラスローダーの使用

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の子(アプリケーション・クラスローダー)から呼出し側のクラスローダーまでのリソースが戻されます。図8-8では、(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)

注意:

FilteringClassLoaderの下で、リソースはデフォルトのJava EE委任モデルに従って返されます。FilteringClassLoaderの親に存在するリソースのみが、返される列挙の最後に追加されます。

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

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/1.4.2/docs/guide/jar/jar.html#JARを参照してください。

マニフェスト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は、開発モードでのみ内部オンデマンド・アプリケーションとしてデプロイされます。デプロイメントは初回のアクセス時に実行されます。サーバーが本番モードで稼働中の場合、自動的にデプロイされません。CAT Webアプリケーションは、WL_HOME/server/lib/wls-cat.warに格納されます。WebLogic Server(バージョン10.3.x以降)をそれにデプロイできます。

注意:

CATは、ログイン資格証明を暗号化せずに送信できるBasic認証を使用します。したがって、CATを使用して実行した後は、これをアンデプロイまたは停止し、本番環境ではCATをデプロイしないことをお薦めします。

CATが本番環境にデプロイされている場合は、ただちにCATにアクセスできないようにする必要があります。アクセスの停止の詳細は、次のトピックのいずれかを参照してください。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』の停止に関する項

- Oracle WebLogic Server管理コンソール・ヘルプのデプロイ済Webアプリケーションの停止に関する項

Basic認証については次の点に注意してください。

- ユーザー名とパスワードはBase64でエンコードされますが、Base64エンコーディングはセキュリティを目的として提供されているのではなく、ユーザー名またはパスワードに含まれる可能性があるHTTP非互換文字をHTTP互換にエンコードするためのものです。

- Basic認証により、システムが、リプレイ攻撃および介在者攻撃に対して脆弱になる可能性があります。

- 既存のブラウザでは、認証情報が無期限に保持されます。HTTPでは、サーバーがクライアントにこれらのキャッシュされた資格証明を破棄するように指示する方法が提供されていません。つまり、ブラウザを閉じる以外にサーバーがユーザーをログアウトさせる効果的な方法はありません。

CATの使用を開始するには:

- WebLogic Server管理コンソールで、「デプロイメント」 > 「app_name」 > 「テスト」を選択し、「クラスローダー分析ツール」リンクを選択します。コンソールのログイン資格証明情報を入力します。

- あるいは、ブラウザを開いてhttp://wls-host:port/wls-cat/へ移動し、コンソールのログイン資格証明情報を入力します。

CATには、現在実行中のアプリケーションとモジュールをすべて表示する単一のWeb GUIが実装されています。左側のナビゲーション・ペインでは、分析するアプリケーションやモジュールを選択できます。右側のペインには選択したアイテムの簡単な説明が表示されます。右側のペインを使用して、選択したアプリケーションやモジュールに関するアクションと分析を実行できます。CATを使用すると次を実行できます。

- クラスローディング競合の分析

- システムおよびアプリケーションのクラスローダーの表示

- レポートの生成

CATは、システム・クラスパス・クラスローダーやWebLogic Serverのメイン・アプリケーションのクラスローダーによってロードされ、フィルタリング、アプリケーション、およびモジュールのクラスローダーとして定義されたクラスを分析します。クラス、パッケージ、またはJARのレベルで分析を実行できます。選択する各アクションの結果は、基本ビューまたは詳細ビューで表示されます。

CATを使用して実行できるタスクの例を紹介します。

- アプリケーションおよびモジュールに関する基本情報の表示

- クラスローディング競合の分析

- 提案されたソリューションの確認

- フィルタリング・クラスローダーの構成に関する提案の取得

- クラスローダー階層および各クラスローダーのクラスパス全体の表示

- クラスローダーにおけるクラス(またはリソース)の検索

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

Java EEライブラリ機能により、複数のエンタープライズ・アプリケーション間で、種類が異なる1つまたは複数のJava EEモジュールを簡単に共有できます。Java EEライブラリは、デプロイメントに際してJava EEアプリケーション・コンテナに登録される1つまたは複数のモジュールです。詳細は、第9章「共有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モジュールを共有する必要がある場合は、第9章「共有Java EEライブラリおよびオプション・パッケージの作成」で説明されているJava EEライブラリ機能を使用します。

libディレクトリでJARを共有するには:

1. ドメイン内のすべてのサーバーを停止します。

2. 共有するJARファイルをドメイン・ディレクトリのlibサブディレクトリにコピーします。例:

mkdir c:\bea\wlserver_10.3\samples\domains\wl_server\lib
cp c:\3rdpartyjars\utility.jar
c:\bea\wlserver_10.3\samples\domains\wl_server\lib

注意:

WebLogic Serverは、起動時にlibディレクトリに読込みアクセスできるようにする必要があります。

管理サーバーは、libディレクトリ内のファイルを、リモート・マシン上の管理ターゲット・サーバーに自動的にコピーしません。管理ターゲット・サーバーが、管理サーバーと同じ物理ドメイン・ディレクトリを共有していない場合、管理ターゲット・サーバー・マシン上のdomain_name/libディレクトリに手動でJARファイルをコピーする必要があります。

3. ドメイン内の管理サーバーとすべての管理対象サーバーを起動します。

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

次の項では、共有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は、Java EE 5.0仕様の項8.2 Optional Package Supportに記載のとおり、オプション・パッケージをサポートしています。バージョニングについては、オプション・パッケージのバージョニングで説明しています(http://download.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://download.oracle.com/javase/1.4.2/docs/guide/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ファイルで指定します。表9-1で、有効な共有Java EEライブラリ・マニフェストの属性を示します。

表9-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

バージョン識別子に対してメジャー/マイナー・フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です(表9-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ライブラリを参照できます。表9-2では、ライブラリ参照を定義するXML要素を示します。

表9-2 weblogic-application.xmlの共有Java EEライブラリ参照用の要素

要素

説明

library-ref

library-refは、共有Java EEライブラリへの参照を定義する親要素です。他のすべての要素はlibrary-ref内に格納されます。

library-name

使用する共有Java EEライブラリの名前を指定する文字列値(必須)。library-nameは、ライブラリのマニフェスト・ファイルのExtension-Name属性の値に完全に一致する必要があります。(表9-2を参照してください。)

specification-version

共有Java EEライブラリの必要な仕様バージョンを定義する文字列値(オプション)。この要素を設定しなかった場合、アプリケーションは最新の仕様バージョンに一致するライブラリを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アプリケーションは、構成した値を下回らない最新の仕様バージョンに一致するライブラリを使用します。使用可能なすべてのライブラリが、構成されたspecification-versionよりも古い場合、アプリケーションをデプロイすることはできません。次のexact-match要素を使用すると、必要なバージョンをさらに絞り込むことができます。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アプリケーションでは、ライブラリのマニフェスト・ファイルのSpecification-Version属性に完全一致する文字列値を持つ共有Java EEライブラリが必要になります。(表9-2を参照してください。)

implementation-version

共有Java EEライブラリの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アプリケーションは最新の実装バージョンに一致するライブラリを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アプリケーションは、構成した値を下回らない最新の実装バージョンに一致するライブラリを使用します。使用可能なすべてのライブラリが、構成されたimplementation-versionよりも古い場合、アプリケーションをデプロイすることはできません。次のexact-match要素を使用すると、必要な実装バージョンをさらに絞り込むことができます。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アプリケーションでは、ライブラリのマニフェスト・ファイルのImplementation-Version属性に完全一致する文字列値を持つ共有Java EEライブラリが必要になります。(表9-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をオーバーライドできます。表9-3では、ライブラリ参照においてcontext-rootをオーバーライドするXML要素について説明します。

表9-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つまたは複数の登録済みオプション・パッケージを参照できます。

表9-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属性に完全一致する文字列値を持つオプション・パッケージが必要になります。(表9-2を参照してください。)

1つのアーカイブから複数のオプション・パッケージを参照する場合は、Specification-Version属性に適切な論理名を付加します。

[logical_name-]Implementation-Version

オプション・パッケージの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の実装バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アーカイブは設定した値を下回らない最新の実装バージョンに一致するパッケージを使用します。使用可能なすべてのライブラリが、構成されたimplementation-versionよりも古い場合、アプリケーションをデプロイすることはできません。

メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アーカイブでは、パッケージのマニフェスト・ファイルのImplementation-Version属性に完全一致する文字列値を持つオプション・パッケージが必要になります。(表9-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>

有効なオプションを表9-5に示します。

表9-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でのライブラリの登録に関する項を参照してください。

管理コンソールを使用して共有Java EEライブラリをインストール(デプロイ)する場合の詳細な手順については、「Java EEライブラリのインストール」を参照してください。管理コンソールを使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバーまたはクラスタにライブラリをデプロイする場合の手順については、「Java EEライブラリのサーバーまたはクラスタへの割当て」を参照してください。

繰返しの開発プロセスの一部としてwldeploy Antタスクを使用する場合は、library、libImplVer、およびlibSpecVer属性を使用して共有Java EEライブラリをデプロイします。詳細およびその他のサンプルについては、付録B「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.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 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ライブラリをデプロイします。参照側アプリケーションのデプロイ先となるサーバー・インスタンスにライブラリが登録されていない場合、参照側アプリケーションのデプロイメントは失敗します。

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

次の項では、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デプロイメント記述子に登録する必要があります。付録A「エンタープライズ・アプリケーションのデプロイメント記述子の要素」を参照してください。以下の要素を定義します。

- listener - ユーザー定義のアプリケーション・ライフサイクル・リスナーを登録するときに使用します。これらは、抽象ベース・クラスweblogic.application.ApplicationLifecycleListenerを拡張するクラスです。

- shutdown - ユーザー定義の停止クラスを登録するときに使用します。

- startup - ユーザー定義の起動クラスを登録するときに使用します。

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

抽象クラス(WebLogic Server付属のクラス) weblogic.application.ApplicationLifecycleListenerを拡張することにより、リスナーを作成します。作成したリスナーは、コンテナの検索対象になります。

WebLogic ServerのApplicationLifecycleListener抽象クラスに提供されている次のメソッドをオーバーライドし、必要な機能を追加してアプリケーションを拡張します。

- preStart{}

- postStart{}

- preStop{}

- postStop{}

例10-1に、ApplicationLifecycleListenerをオーバーライドする方法を示します。この例では、パブリック・クラスMyListenerがApplicationLifecycleListenerを拡張しています。

例10-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
}

例10-2に、停止クラスを実装する方法を示します。停止クラスは、preStopイベントおよびpostStopイベントにアタッチできます。この例では、パブリック・クラスMyShutdownはApplicationLifecycleListenerを拡張しません。これは、weblogic-application.xmlデプロイメント記述子で宣言された停止クラスはWebLogic Server固有のインタフェースに依存しないためです。

例10-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
}

例10-3に、起動クラスを実装する方法を示します。起動クラスは、preStartイベントおよびpostStartイベントにアタッチできます。この例では、パブリック・クラスMyStartupはApplicationLifecycleListenerを拡張しません。これは、weblogic-application.xmlデプロイメント記述子で宣言された起動クラスはWebLogic Server固有のインタフェースに依存しないためです。

例10-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)

例10-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パラメータを使用せずにアプリケーション・ライフサイクル・イベントを構成する方法を示します。

例10-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でライフサイクル・リスナーを指定できます。付録A「エンタープライズ・アプリケーションのデプロイメント記述子の要素」」と「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)の例を示します。

表10-1 デプロイメント・アクションとアプリケーション・バージョン・ライフサイクル・イベントのシーケンス

デプロイメント・アクション

時間

バージョンV1

バージョンV2

バージョンV1のデプロイメント

T0

preDeploy(V1)が呼び出されます。

T1

デプロイメントが開始されます。

T2

V1のアプリケーション・ライフサイクル・リスナーが登録されます。

T3

V1がアクティブなバージョンとなり、デプロイメントが完了します。

T4

postDeploy(V1)が呼び出されます。

T5

アプリケーション・リスナーがpostDeploy(V1)を取得します。

バージョンV2の本番再デプロイメント

T6

preDeploy(V2)が呼び出されます。

T7

アプリケーション・バージョン・リスナーがpreDeploy(V1)を受け取ります。

T8

デプロイメントが開始されます。

T9

V2のアプリケーション・ライフサイクル・リスナーが登録されます。

T10

デプロイ(V2)が成功すると、V1はアクティブなバージョンでなくなります。

デプロイ(V2)が成功すると、V2はV1に代わってアクティブなバージョンとなります。

デプロイメントが完了します。

T11

postDeploy(V2)が呼び出されます。

注意:このイベントはデプロイメントが失敗した場合でも発生します。

T12

アプリケーション・バージョン・リスナーがpostDeploy(V2)を取得します。デプロイ(V2)が失敗した場合、V1はアクティブなままとなります。

T13

アプリケーション・リスナーがpostDeploy(V2)を取得します。

T14

デプロイ(V2)が成功すると、V1はリタイアを開始します。

T15

V1のアプリケーション・リスナーが登録解除されます。

T16

V1がリタイアされます。

V2のアンデプロイメント

T17

preUndeploy(v2)が呼び出されます。

T18

アプリケーション・リスナーは呼び出されたpreUndeploy(v2)を取得します。

T19

アンデプロイメントが開始されます。

T20

V2がアクティブなバージョンでなくなります。

T21

V2のアプリケーション・バージョン・リスナーが登録解除されます。

T22

アンデプロイメントが完了します。

T23

アプリケーション全体がアンデプロイされると、postDelete(V2)が呼び出されます。

注意:このイベントはアンデプロイメントが失敗した場合でも発生します。

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

次の項では、アプリケーションでコンテキスト伝播APIを使用する方法を説明します。

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

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

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

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

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

コンテキストの伝播により、プログラマは情報をアプリケーションと関連付けできます。さらに、下流のコンポーネントは、この情報を送り元に戻せるように、情報に対し追加または修正を行えます。コンテキストの伝播は、作業領域、作業コンテキスト、またはアプリケーション・トランザクションとしても知られています。

通常、コンテキストの伝播を使用するのは、アプリケーションの不可欠な一部である情報ではなく、アプリケーションの外部に情報を運ぶ必要があるアプリケーションです。たとえば、診断モニター、アプリケーション・トランザクション、アプリケーションのロード・バランシングなどがそれに当たります。アプリケーションの外部にこの種類の情報を保持すると、無関係なAPIを使用しないでアプリケーション自体をクリーンにしておくことができます。また、サード・パーティ・コンポーネントなどの読取り専用コンポーネントに情報を追加することもできます。

コンテキスト伝播のプログラミングでは、最初にWorkContextMapとWorkContextを作成するクライアント・アプリケーションのコードを記述し、次にこのデータを取得および必要に応じて使用する呼出し対象のアプリケーション自体のコードを記述します。呼出し対象のアプリケーションは、EJB、Webサービス、サーブレット、JMSトピックまたはキューなど、どのような種類のものでも構いません。詳細は、「コンテキスト伝播のプログラミング: 主な手順」を参照してください。

WebLogicコンテキスト伝播APIはweblogic.workareaパッケージにあります。次の表に、主なインタフェースとクラスを示します。

表11-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.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サービスおよび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 the 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{
WorkAreaService service = new WorkAreaService_Impl(args[0] + "?WSDL");
WorkAreaPortType 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;

- 次のコードは、コンテキスト伝播固有の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");

- 最後に、次のコードは、キーSESSION_IDとともにコンテキスト・データをWorkContextMapに追加し、それを現在のスレッドに関連付ける方法を示しています。PropagationMode.SOAP定数は、伝播がSOAPメッセージを介して発生するように指定します。これは、クライアントがWebサービスを呼び出しているためです。

map.put(SESSION_ID, stringContext, PropagationMode.SOAP);

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

以下のサンプルJavaコードでは、Webサービスを実装するJava Webサービス(Java Web Service: JWS)ファイルを示します。JWSファイルには、Webサービスの呼出しに関連付けられるユーザー・データを取得するためのコンテキスト伝播コードも含まれます。コンテキスト伝播に該当するコードを太字で示し、サンプルの後で説明を加えます。

コンテキスト伝播の完全なAPIドキュメントについては、「weblogic.workareaのJavadoc」を参照してください。

注意:

Webサービスおよび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 WorkAreaImpl {
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 localwc = map.get(SESSION_ID);
System.out.println("local context: " + localwc);
System.out.println("sayHello: " + message);
return "Here is the message: '" + message + "'";
} 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");

- 次のコードは、キーを使用して現在のWorkContextMapからコンテキストのユーザー・データを取得する方法を示しています。ここでは、キーは、Webサービスを呼び出したときにクライアント・アプリケーションが設定したものと同じSESSION_IDです。

WorkContext localwc = map.get(SESSION_ID);

12 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://java.sun.com/products/javamail/index.htmlで参照できます。この項では、WebLogic Server環境でJavaMailを使用する方法について説明しています。

weblogic.jarファイルには、Sunが提供する次の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)メール・サーバーのプロバイダが含まれています。Sunには、JavaMail用に独自のPOP3プロバイダがあります。これは、weblogic.jarには含まれていません。使用する場合は、SunからそのPOP3プロバイダをダウンロードし、WebLogic Serverのクラスパスに追加できます。

JavaMail構成ファイルの理解

JavaMailは、システムのメール・トランスポート機能を定義する構成ファイルに依存します。weblogic.jarファイルには、Sunの標準構成ファイルが入っています。このファイルにより、IMAPおよびSMTPメール・サーバーがJavaMail向けに使用可能になり、JavaMailが処理できるデフォルトのメッセージ・タイプが定義されます。

JavaMailを拡張してサポートされるトランスポート、プロトコル、およびメッセージのタイプを追加する場合を除いて、JavaMail構成ファイルを変更する必要はありません。JavaMailを拡張する場合は、SunからJavaMailをダウンロードして、Sunの拡張追加の手順に従います。次に、拡張したJavaMailパッケージをweblogic.jarの前のWebLogic Serverクラスパスに追加します。

WebLogic Server用のJavaMailの構成

WebLogic Serverで使用するためにJavaMailを構成するには、WebLogic Server管理コンソールでメール・セッションを作成します。これにより、あらかじめ構成しておくセッション・プロパティを使用して、サーバー側モジュールとアプリケーションでJNDIを用いてJavaMailサービスにアクセスできるようになります。たとえば、メール・セッションを作成すると、メール・ホスト、トランスポートおよび格納プロトコル、デフォルトのメール・ユーザーを管理コンソールで指定できるため、JavaMailを使用するモジュールでこれらのプロパティを設定する必要はありません。メール・セッションは単一のjavax.mail.Sessionオブジェクトを作成し、JNDIを通じてそのオブジェクトを必要とするすべてのモジュールで利用できるようにするため、多数の電子メール・ユーザーを持つアプリケーションではメリットが得られます。

管理コンソールによるメール・セッションの使用の詳細は、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. 管理コンソールで設定したセッションのプロパティをオーバーライドする必要がある場合は、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. 管理コンソールで設定したセッションのプロパティをオーバーライドする必要がある場合は、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からメッセージ・ストアを管理するコードを記述する必要があります。

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

次の項では、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のような管理対象の環境での使用は適切ではありません。

詳細は、「ワーク・マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

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

WebLogic ServerのクラスタにデプロイされるJSPおよびサーブレットは、セッション・データを保持するために特定の要件に従う必要があります。詳細は、『Oracle WebLogic Serverクラスタの使用』のHTTPセッション状態のレプリケーションに関する条件に関する項を参照してください。

WebLogic ServerクラスタでデプロイされるEJBには、EJBのタイプによって制約があります。クラスタ内の複数のEJBの種類の機能については、『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のEnterprise JavaBeansの理解に関する項を参照してください。EJBは、EJBデプロイメント記述子でプロパティを設定することでクラスタにデプロイできます。

クラスタ内でデプロイメント用にEJBまたはカスタムRMIオブジェクトを開発する場合は、『Oracle WebLogic Server JNDIのプログラミング』のクラスタ環境でのWebLogic JNDIの使い方に関する項を参照して、クラスタリングされたオブジェクトをJNDIツリーにバインドする影響について理解してください。

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

次の項では、エンタープライズ・アプリケーション・デプロイメント記述子application.xml (Java EE標準デプロイメント記述子)およびweblogic-application.xml (WebLogic固有のアプリケーション・デプロイメント記述子)について説明します。

Java EEアノテーションの使用により、標準のapplication.xmlデプロイメント記述子は省略可能になりました。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要だったデプロイメント記述子にかわるものです。第7章「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デプロイメント記述子を拡張した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以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、第10章「アプリケーション・ライフサイクル・イベントのプログラミング」を参照してください。

<shutdown>

オプション

制限なし

ゼロまたはそれ以上。ユーザー定義の停止クラスの登録に使用します。

shutdown要素内で定義できる要素の詳細は、「shutdown」を参照してください。

注意: アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、第10章「アプリケーション・ライフサイクル・イベントのプログラミング」を参照してください。

<module>

オプション

制限なし

JMSまたはJDBCモジュールなど、単独のWebLogicアプリケーション・モジュールを表します。

この要素には次の子要素があります。

- name - モジュールの名前。

- type - モジュールの種類。有効な値は、JMS、JDBC、またはInterception。

- 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クラスが再定義されるため、再デプロイメントを最小限に抑えることができます。

詳細は、『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以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、第10章「アプリケーション・ライフサイクル・イベントのプログラミング」を参照してください。

表A - 17 startup要素

要素

必須?

ファイル内での最大数

説明

<startup-class>

必須

1

アプリケーションのデプロイ中に実行するクラスの名前を定義します。

<startup-uri>

オプション

1

startup-classが格納されているEAR内のJARファイルを定義します。startup-uriが定義されていない場合は、クラスがアプリケーションから参照可能であると見なされます。

shutdown

次の表では、shutdown要素内で定義できる要素について説明します。

注意:

アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。このクラスの代わりに、ライフサイクル・リスナー・イベントをアプリケーションで使用する必要があります。詳細は、第10章「アプリケーション・ライフサイクル・イベントのプログラミング」を参照してください。

表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要素内で定義できる要素について説明します。

詳細情報および例については、第9章「共有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」を参照してください。

詳細情報および例については、第9章「共有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デプロイメントの詳細は、『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.3/weblogic-application.xsdを参照してください。

application.xmlスキーマ

application.xmlデプロイメント記述子の要素の詳細は、http://java.sun.com/xml/ns/javaee/application_5.xsdのJava EE 5スキーマを参照してください。

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の詳細は、第2章「Antタスクを使用したWebLogic Serverドメインの構成と使用」を参照してください。wlcompileの詳細は、第4章「分割開発ディレクトリでのアプリケーションのビルド」を参照してください。

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の最上位ディレクトリです。

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の詳細は、第2章「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プロトコルを使用するには、管理コンソールで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属性との組み合わせでのみ指定できます。

第9章「共有Java EEライブラリおよびオプション・パッケージの作成」を参照してください。

文字列

library

デプロイメントを共有Java EEライブラリまたはオプション・パッケージとして指定します。Java EEライブラリまたはオプション・パッケージをデプロイまたは分散する場合はlibrary属性を指定する必要があります。

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

第9章「共有Java EEライブラリおよびオプション・パッケージの作成」を参照してください。

ブール

libSpecVer

Java EEライブラリまたはオプション・パッケージの仕様のバージョンを指定します。

この属性は、ライブラリまたはパッケージのマニフェスト・ファイルに仕様バージョンが含まれていない場合にのみ使用できます。この属性は、library属性との組み合わせでのみ指定できます。

第9章「共有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が(バックグラウンド・タスクとしてデプロイすることによって)デプロイメント呼出しを行った後、ただちに復帰するかどうかを指定します。

ブール

password

管理パスワード。

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

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

パスワードの格納と暗号化の詳細は、WebLogic Scripting Toolコマンド・リファレンスのstoreUserConfigのコマンド・リファレンスを参照してください。

文字列

plan

アプリケーションまたはモジュールをデプロイするときに使用するデプロイメント・プランを指定します。

デフォルトでは、プランが格納されているアプリケーションのルート・ディレクトリからデプロイする場合でも、wldeployは利用可能なデプロイメント・プランを使用しません。

文字列

planversion

デプロイメント・プランのバージョン識別子。

文字列

remote

サーバーが別のマシンに配置されているかどうかを指定します。これはファイル名の転送方法に影響します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseです - つまり、Antタスクは、すべてのソース・パスがローカル・マシン上の有効なパスであると見なします。

ブール

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タスク、コマンド・ライン、管理コンソールなど)を同時に使用しており、いずれかのツールでドメインのロックをすでに取得している場合に有用です。

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

ブール

user

管理ユーザー名。

文字列

userconfigfile

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

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

文字列

userkeyfile

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

userkeyfile属性を指定する前に、WebLogic Scripting Toolコマンド・リファレンスの説明に従い、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 © 2007, 2011, Oracle and/or its affiliates. All rights reserved.