Oracle® Fusion Middleware

Oracle WebLogic Server 12.1.3アプリケーションのデプロイメント

12c (12.1.3)

E56252-03(原本部品番号:E41940-03)

2015年8月

このドキュメントでは、WebLogic Server 12.1.3インスタンスまたはクラスタへのJava EEアプリケーションまたはアプリケーション・モジュールのデプロイについて説明します。

Oracle Fusion Middleware Oracle WebLogic Server 12.1.3へのアプリケーションのデプロイ, 12c (12.1.3)

E56252-03

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

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

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

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

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

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

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

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

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

目次

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

はじめに

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

- ルール

1 概要とロードマップ

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

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

- 標準の互換性

- デプロイメントの用語

- 関連ドキュメント

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

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

- デプロイメント・プロセスの概要

- Java EEデプロイメントの実装

- WebLogic Serverのデプロイメント機能

- 追加のデプロイメント構成プロパティ

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

- 本番アプリケーションを分離するための管理モード

- デプロイ可能なJDBC、JMS、およびWLDFアプリケーション・モジュール

- エンタープライズ・アプリケーションのモジュール・レベルでのデプロイメントと再デプロイメント

- 本番アプリケーションの安全な再デプロイメント

- デプロイメントに必要なセキュリティ・ロール

- サポートされるデプロイメント・ユニット

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

- Webアプリケーション

- Enterprise JavaBean

- リソース・アダプタ

- Webサービス

- Java EEライブラリ

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

- JDBC、JMS、およびWLDFモジュール

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

- デプロイメント・ツール

- weblogic.Deployer

- WebLogic Server管理コンソール

- WLST

- 開発者用のデプロイメント・ツール

3 アプリケーションおよびモジュールのデプロイメント準備

- デプロイするファイルのパッケージ化

- アーカイブ・ファイルの使用

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

- デプロイメント記述子を含まない展開されたEARディレクトリをデプロイする場合のJava EEルール

- アーカイブ・ファイルからの展開されたアーカイブ・ディレクトリの作成

- デフォルト・デプロイメント名の理解

- アプリケーションのネーミング要件の理解

- デプロイメント・バージョン文字列の理解

- アプリケーションのインストール・ディレクトリの作成

- アプリケーションのインストール・ディレクトリを作成する手順

- FastSwapデプロイメントによる再デプロイメントの最小化

- FastSwapデプロイメントの仕組み

- FastSwapでサポートされるアプリケーション構成

- アプリケーションにおけるFastSwapの有効化

- FastSwapプロセスの概要

- AntでのJMXインタフェースの使用

- FastSwapでサポートされるアプリケーション・タイプと変更

- FastSwap使用時の制限

- FastSwapでサポートされない変更の処理

- デプロイメント・ファイルの準備のベスト・プラクティス

4 本番デプロイメントのためのアプリケーションの構成

- デプロイメント構成プロセスの理解

- デプロイメント構成のライフサイクル

- アプリケーションのデプロイメント記述子の理解

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

- 本番デプロイメント構成の目標

- 一般的なデプロイメント構成のワークフロー

- 単一のデプロイメント・プランを使用するアプリケーション

- 単一デプロイメント・プランのワークフローの利点

- 単一デプロイメント・プランの所有権および制限事項

- 複数のデプロイメント・プランを使用するアプリケーション

- 複数デプロイメント・プランのワークフローの利点

- 複数デプロイメント・プランの所有権および制限事項

- アプリケーションを構成するための新しいデプロイメント・プランの作成

- デプロイメント・ファイルを準備する

- アプリケーション・アーカイブをインストールする

- デプロイメント・プランに構成の変更を保存する

- デプロイメント・プランの内容の理解

- 既存のデプロイメント・プランを使用したアプリケーションの構成

- 汎用ファイル・ロード・オーバーライド

- オーバーライドの仕組み

- ディレクトリ構造

- アプリケーションの使用方法

- 追加の構成タスク

- アプリケーション構成管理のベスト・プラクティス

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

- エクスポート・プロセスの概要

- デプロイメント構成のエクスポートの目標

- デプロイメント構成をエクスポートするためのツール

- デプロイメント・プロパティの分類の理解

- アプリケーションのデプロイメント構成をエクスポートする手順

- エクスポートのためのアプリケーション・ファイルのステージング

- weblogic.PlanGeneratorを使用したテンプレート・デプロイメント・プランの生成

- 管理コンソールを使用したデプロイメント・プランのカスタマイズ

- エクスポートされたアプリケーションおよびテンプレート・デプロイメント・プランのインストール

- 選択されたチューニング・プロパティの変数の追加

- カスタマイズされたデプロイメント・プランの取得

- デプロイメント・プランの手動によるカスタマイズ

- デプロイメント・プランからの変数の削除

- 管理者入力を必要とするnull変数の割当て

- エクスポートされたデプロイメント構成の検証

- デプロイメント構成のエクスポートのベスト・プラクティス

6 weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ

- 一般的なデプロイメント・シナリオの概要

- リモート・クライアントからのデプロイメント・ファイルのアップロード

- アプリケーションまたはプランを更新する場合のアップロードの動作

- 単一サーバー・ドメインへのデプロイ

- デプロイメント・プランによるアプリケーションのデプロイ

- preStart期間中にJNDIからシステム・リソースをルックアップするアプリケーションのデプロイ

- サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定

- デプロイメント・ターゲットの理解

- 1つまたは複数のターゲットへのデプロイ

- クラスタ・ターゲットへのデプロイ

- すべての構成済みクラスタ・メンバーへの一貫性のあるデプロイメントの強制

- モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ

- モジュールターゲット指定の構文

- Webアプリケーション・モジュールのターゲット指定

- モジュールの起動と停止

- JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ

- アプリケーション・スコープのJMS、JDBC、およびWLDFモジュールのターゲット指定

- JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用

- デフォルトのサブモジュールのターゲット指定

- スタンドアロンJMSモジュールのサブモジュール・ターゲット

- アプリケーション・スコープのJMSモジュールにおけるサブモジュールのターゲット指定

- ステージング・モードによるデプロイメント・ファイルのコピーの制御

- ステージング・モードとベスト・プラクティス

- nostageモードのデプロイメントの使用

- nostageモードの構文

- stageモードのデプロイメントの使用

- stageモードの構文

- external_stageモードのデプロイメントの使用

- external_stageモードの構文

- サーバーのデフォルト・ステージング動作の変更

- デプロイメント・プランのステージング

- 本番環境へのアプリケーションの配布

- アプリケーションの配布

- 配布されたアプリケーションの管理モードでの起動

- 配布されたアプリケーションの起動

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

- 共有ライブラリに対するデプロイメント動作の理解

- WebLogic Serverでのライブラリの登録

- デプロイメント時のライブラリのバージョン指定

- ライブラリを参照するアプリケーションのデプロイ

- アプリケーションのデプロイのベスト・プラクティス

7 開発ドメインへのアプリケーションの自動デプロイ

- 自動デプロイメントの有効化と無効化

- アーカイブされたアプリケーションの自動デプロイ、再デプロイ、およびアンデプロイ

- 展開アーカイブの自動デプロイ、再デプロイ、およびアンデプロイ

- 自動デプロイメントの制限事項

8 本番環境でのアプリケーションの再デプロイメント

- 再デプロイメント戦略の概要

- 本番再デプロイメント

- インプレース再デプロイメント

- 静的ファイルの部分的な再デプロイメント

- Java EEモジュールの部分的な再デプロイメント

- 様々な再デプロイメント戦略をいつ使用するかの理解

- 本番再デプロイメントを使用したアプリケーションの更新

- 本番再デプロイメントのしくみ

- クラスタにおける本番再デプロイメント

- 本番再デプロイメントの要件と制限事項

- 開発の要件

- デプロイメントの要件

- 本番再デプロイメントの更新に関する制限事項

- アプリケーションのバージョン識別子の指定

- デプロイメントおよび再デプロイメント中のバージョン識別子の割当て

- デプロイされたアプリケーションのバージョン情報の表示

- アプリケーションの新しいバージョンの再デプロイ

- リタイアされるアプリケーションのアンデプロイ

- 本番再デプロイメント・プロセスのロールバック

- RMIクライアント・リクエストの処理の正常な停止

- 本番アプリケーションの新しいバージョンの配布

- アプリケーションの新しいバージョンを配布する手順

- アプリケーションをクライアントで使用できるようにする方法

- 本番再デプロイメントの使用のベスト・プラクティス

- アプリケーションおよびスタンドアロン・モジュールに対するインプレース再デプロイメントの使用方法

- インプレースでのアプリケーションおよびモジュールの再デプロイ

- インプレースでのアプリケーションおよびモジュールの再デプロイのベスト・プラクティス

- Java EEモジュールを更新するための部分的な再デプロイメントの使用

- EARでJava EEモジュールを更新する場合の制限事項

- EARでJava EEモジュールを更新する場合のベスト・プラクティス

- デプロイされたアプリケーションにおける静的ファイルの更新

- アプリケーションのデプロイメント構成の更新

- 管理コンソールを使用しての構成の変更

- 構成の変更の格納方法

- 別のデプロイメント・プランを使用するためのアプリケーションの更新

- デプロイメント構成変更のための再デプロイメント動作の理解

9 デプロイされたアプリケーションの管理

- 本番アプリケーションのオフライン

- アプリケーションの停止によるクライアント・アクセスの制限

- アプリケーションまたはモジュールのアンデプロイ

- 共有ライブラリおよびパッケージのアンデプロイ

- デプロイされたエンタープライズ・アプリケーションへの新しいモジュールの追加

- サーバー起動時のデプロイメント順序の変更

- アプリケーションおよびスタンドアロン・モジュールのデプロイメント順序の変更

- エンタープライズ・アプリケーションにおけるモジュールのデプロイメント順序の変更

- 起動クラスの実行およびデプロイメントの順序付け

- 既存のデプロイメントのターゲット・リストの変更

- Webアプリケーション・デプロイメントからのファイルの削除

- 長時間かかるデプロイメント・タスクの管理

- 内部アプリケーションのオンデマンド・デプロイメント

- 内部アプリケーションのタイプ

- オンデマンド・デプロイメントの構成

- 管理コンソールを使用したオンデマンド・デプロイメントの構成

- WLSTを使用したオンデマンド・デプロイメントの構成

A weblogic.Deployerコマンド行リファレンス

- weblogic.Deployerに必要な環境

- weblogic.Deployerを呼び出すための構文

- SSLの引数

- 接続の引数

- ユーザー資格証明の引数

- 共通の引数

- コマンドとオプション

- Cancel

- 構文

- 例

- Deploy

- 構文

- 例

- Distribute

- 構文

- 例

- Listapps

- 構文

- 例

- List、Listtask

- 構文

- 例

- Purgetasks

- 構文

- 例

- Redeploy

- 構文

- 例

- Start

- 構文

- 例

- Stop

- 構文

- 例

- Undeploy

- 構文

- 例

- Update

- 構文

- 例

- config.xmlファイルの例および対応するweblogic.Deployerコマンド

B weblogic.PlanGeneratorコマンド行リファレンス

- weblogic.PlanGeneratorの概要

- weblogic.PlanGeneratorに必要な環境

- weblogic.PlanGeneratorを呼び出すための構文

- オプション

- 一般的なweblogic.PlanGeneratorタスク

- アプリケーションのルート・ディレクトリにおける初期状態のデプロイメント・プランの作成

- 既存のプランに基づく新しいデプロイメント・プランの作成

- デプロイメント・プランへエクスポートされるコンポーネントの制御

C デプロイメント用のWebLogic Mavenプラグインの使用

- デプロイメント用WebLogic Mavenプラグインの構成と使用

- 安全なユーザー資格証明の提供

- デプロイメントの目標

- deploy

- undeploy

- redeploy

- start-app

- stop-app

- list-apps

- update-app

- help

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

はじめに

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

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

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

Oracleサポートへのアクセス

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

表記規則

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

規則

意味

太字

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

斜体

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

固定幅フォント

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

1 概要とロードマップ

この章では、このガイドOracle WebLogic Server 12.1.3へのアプリケーションのデプロイの内容と構成について説明します。

この章には次の項が含まれます:

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

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

- 標準の互換性

- デプロイメントの用語

- 関連ドキュメント

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

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

このドキュメントは以下の読者を対象にしています。

- Java EEアプリケーションまたはアプリケーション・モジュールを、WebLogic Serverインスタンスまたはクラスタにデプロイする管理者。通常の本番環境では、複数のWebLogic Serverインスタンスまたはクラスタが複数のマシン上で動作しています。また、1つまたは複数のアプリケーション・モジュール・アーカイブ・ファイルがすでにテストされ、本番サーバーにデプロイできる状態にあることも想定しています。

- 開発環境でのアプリケーションのデプロイメント、管理者またはデプロイヤへの配信を目的としたアプリケーションのパッケージ化、テスト環境、ステージング環境、または本番環境へのデプロイメントを目的としたアプリケーションの構成の作成およびエクスポート、などを行う開発者。

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

- この章第1章「概要とロードマップ」では、このガイドの構成を説明し、WebLogic Serverのこのリリースで導入されている新しいデプロイメント機能に焦点を当てています。

- 第2章「WebLogic Serverデプロイメントの理解」では、WebLogic Serverで使用されるデプロイメント機能の概要を示します。

- 第3章「アプリケーションおよびモジュールのデプロイメント準備」では、アプリケーションおよびモジュール・ファイルをWebLogic Serverへのデプロイメントのために準備する方法について説明します。

- 第4章「本番デプロイメントのためのアプリケーションの構成」では、特定のWebLogic Serverの環境にデプロイするためにアプリケーションを構成する方法について説明します。

- 第5章「新しい環境にデプロイするためのアプリケーションのエクスポート」では、アプリケーションのWebLogic Serverデプロイメント構成をカスタム・デプロイメント・プランにエクスポートする方法について説明します。カスタム・デプロイメント・プランは、アプリケーションを非開発環境にデプロイする際に使用します。

- 第6章「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」では、WebLogic Serverにアプリケーションをデプロイするための基本的な技術および高度な技術について説明します。

- 第7章「開発ドメインへのアプリケーションの自動デプロイ」では、単一サーバーの開発環境で評価またはテストを行うために、くスタンドアロン・サーバー(管理サーバー)にアプリケーションを迅速にデプロイする方法について説明します。

- 第8章「本番環境でのアプリケーションの再デプロイメント」では、本番環境にデプロイしたアプリケーションを安全に更新、再デプロイ、および再構成する方法について説明します。

- 第9章「デプロイされたアプリケーションの管理」では、デプロイされたアプリケーションおよびモジュールを管理する際に管理者が実行する一般的なタスクについて説明します。

- 付録A「weblogic.Deployerコマンド行リファレンス」では、weblogic.Deployerツール構文に関する詳細なリファレンスを提供します。

- 付録B「weblogic.PlanGeneratorコマンド行リファレンス」では、weblogic.PlanGeneratorユーティリティを使用して基本的なデプロイメント・プランを作成する方法について説明します。

- 付録C「デプロイメントでのWebLogic Mavenプラグインの使用」では、アプリケーションのデプロイ、再デプロイ、更新、起動および停止などを実行するための、WebLogic Mavenプラグインの使用について説明します。

標準の互換性

WebLogic Serverは、Java EE 6仕様を実装しています。Java EE 6には、デプロイメント仕様JSR-88が含まれています。この仕様には、アプリケーションをアプリケーション・サーバーに構成およびデプロイする際に、デプロイメント・ツールおよびアプリケーション・サーバー・プロバイダで使用する標準APIが記述されています。

WebLogic Serverは、Java EEデプロイメント仕様に準拠するように、JSR-88サービス・プロバイダ・インタフェース(SPI)プラグインとモデル・プラグインの双方を実装しています。WebLogic Serverに対してJava EEアプリケーションおよびモジュールを構成、デプロイ、および再デプロイするには、(APIのWebLogic Server拡張を使用せずに) WebLogic Serverプラグインとともに基本的なJava EEデプロイメントAPIデプロイメント・ツールを使用できます。『Oracle WebLogic Serverの理解』のWebLogic Serverの互換性に関する項を参照してください。

デプロイメントの用語

このドキュメントでは、一貫して次のWebLogic Serverデプロイメント用語が使用されます。

- アプリケーション - エンド・ユーザーがコンピューティング・タスクを実行するために集合的に使用する1つまたは複数のソフトウェア・プログラム。

- アプリケーション・インストール・ディレクトリ: アプリケーションまたはモジュール用の、デプロイメント・ファイルおよび生成されたデプロイメント構成アーティファクトの整理を支援するために設計された、WebLogic Serverディレクトリ構造。アプリケーション・ルート・ディレクトリとも言います。

- アプリケーション・モジュール: JMSまたはJDBCリソースの構成に使用するXMLドキュメント。アプリケーション・モジュールには以下の2種類があります。

- スタンドアロン - リソースはグローバルJNDIツリーにバインドされます。

- アプリケーション・スコープ - エンタープライズ・アプリケーションの一部としてバンドルされ、アプリケーション自体にスコープされます。

- アプリケーション・バージョン: デプロイされたアプリケーションのバージョンを識別する文字列値。バージョン文字列を使用する互換性のあるアプリケーションでは、WebLogic Server本番再デプロイメント戦略を使用できます。

- デプロイメント構成: 特定のWebLogic Serverドメインにアプリケーションをデプロイするために必要となるデプロイメント記述子の値を定義するプロセス。アプリケーションまたはモジュールに関するデプロイメント構成は、Java EEデプロイメント記述子、WebLogic Server記述子、およびWebLogic Serverデプロイメント・プランという、3種類のXMLドキュメントに格納されます。

- デプロイメント記述子 - デプロイメント時にアプリケーションまたはモジュールのJava EE動作またはWebLogic Server構成を定義するのに使用される、XMLドキュメント。

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

- 配布 - WebLogic Serverが、デプロイメント・ソース・ファイルをデプロイメントのターゲット・サーバーにコピーするプロセス。

- 本番再デプロイメント - 新しいバージョンの本番アプリケーションを、それより前のバージョンと一緒にデプロイする一方で、HTTP接続を自動的に管理してクライアント・アクセスが中断しないようにする、WebLogic Server再デプロイメント戦略。

- ステージング・モード: デプロイメント・ファイルを、ドメイン内のターゲット・サーバーで使用できるようにするために、WebLogic Serverで使用される方法。ステージング・モードにより、ファイルをデプロイ前にターゲット・サーバーに配布(コピー)するかどうかが判断されます。

関連ドキュメント

アプリケーションおよびモジュールのWebLogic Serverへのデプロイの詳細は、次のドキュメントを参照してください。

- WebLogicデプロイメントAPIの理解 - Java EE仕様を実装および拡張するWebLogic ServerデプロイメントAPIについて説明します。このAPIは、すべてのWebLogic Serverデプロイメント・ツールで使用します。

- 『Oracle WebLogic Serverアプリケーションの開発』では、wldeploy Antタスクを使用して開発中にアプリケーションをデプロイする方法を説明し、エンタープライズ・アプリケーションのWebLogic Serverデプロイメント記述子に関する情報を提供します。

- WebLogic Server Java EEプログラミングに関するガイド群。各Java EEアプリケーションおよびモジュールで使用されるJava EEおよびWebLogic Serverデプロイメント記述子について説明します。

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

- Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発

- Oracle WebLogic Serverリソース・アダプタの開発

- Oracle WebLogic Server JAX-WS Webサービスの開発

- WebLogic Deployment APIによるアプリケーションのデプロイ

- 『Oracle WebLogic Server JDBCアプリケーションの開発』では、JDBCアプリケーション・モジュールのXMLデプロイメント記述子について説明します。

- 『Oracle WebLogic Server JMSアプリケーションの開発』では、JMSアプリケーション・モジュールのXMLデプロイメント記述子について説明します。

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

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

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

この章では、WebLogic Server 12.1.3アプリケーション・デプロイメント機能について説明します。

この章には次の項が含まれます:

- デプロイメント・プロセスの概要

- Java EEデプロイメントの実装

- WebLogic Serverのデプロイメント機能

- サポートされるデプロイメント・ユニット

- デプロイメント・ツール

デプロイメント・プロセスの概要

アプリケーション・デプロイメントという用語は、WebLogic Serverドメインにおいて、アプリケーションまたはモジュールをクライアント・リクエストの処理に使用できるようにするプロセスを指します。アプリケーション・デプロイメントは、一般的に次のタスクを伴います。

- アプリケーションおよびモジュールのデプロイメント準備

- 本番デプロイメントのためのアプリケーションの構成

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

- weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ

- 本番環境でのアプリケーションの再デプロイメント

- デプロイされたアプリケーションの管理

Java EEデプロイメントの実装

WebLogic Serverは、Java EE 6仕様を実装しています。Java EE 6には、デプロイメント仕様JSR-88が含まれています。この仕様には、アプリケーションをアプリケーション・サーバーに構成およびデプロイする際に、デプロイメント・ツールおよびアプリケーション・サーバー・プロバイダで使用する標準APIが記述されています。

WebLogic Serverは、Java EEデプロイメント仕様に準拠するように、JSR-88サービス・プロバイダ・インタフェース(SPI)プラグインとモデル・プラグインの双方を実装しています。WebLogic Serverに対してJava EEアプリケーションおよびモジュールを構成、デプロイ、および再デプロイするには、(APIのWebLogic Server拡張を使用せずに) WebLogic Serverプラグインとともに基本的なJava EEデプロイメントAPIデプロイメント・ツールを使用できます。Java EEデプロイメントAPI構成プロセスで生成されたWebLogic Server構成は、図2-1に示すように、デプロイメント・プランおよび1つまたは複数の生成されたWebLogic Serverデプロイメント記述子ファイル内に格納されます。WebLogic Serverデプロイメント記述子は、WebLogic Server構成データを格納するために、必要に応じて生成されます。

図2-1 Java EEデプロイメントAPIによるアプリケーションの構成

Java EEデプロイメントAPIのデプロイメント・ツールで生成されたWebLogic Serverデプロイメント・プランにより、構成セッション中にアプリケーションのために生成されたWebLogic Serverデプロイメント記述子が識別されます。

Java EEデプロイメントAPIは、Java EE準拠のアプリケーション・サーバーで使用するためのアプリケーションおよびモジュールを構成する、簡単かつ標準化された方法を提供しますが、この仕様では以前のWebLogic Serverで利用できた多くのデプロイメント機能に対応していません。そのため、WebLogic Serverでは、Java EEデプロイメントAPI仕様に重要な拡張を行い、「WebLogic Serverのデプロイメント機能」に記載の機能をサポートしています。

WebLogic Serverのデプロイメント機能

Weblogic Serverは、アプリケーションを本番環境に確実にデプロイして管理するのに役立つ以下の高度なデプロイメント機能をサポートしています。

- 追加のデプロイメント構成プロパティ

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

- 本番アプリケーションを分離するための管理モード

- デプロイ可能なJDBC、JMS、およびWLDFアプリケーション・モジュール

- エンタープライズ・アプリケーションのモジュール・レベルでのデプロイメントと再デプロイメント

- 本番アプリケーションの安全な再デプロイメント

- デプロイメントに必要なセキュリティ・ロール

追加のデプロイメント構成プロパティ

Java EEデプロイメントAPIデプロイメント仕様を使用すると、アプリケーションをデプロイするために必要なベンダー固有の記述子の値を生成でき、一方、WebLogic ServerにおけるJava EEデプロイメントAPIの拡張機能では、次のような多くの追加デプロイメント・プロパティを構成できます。

- アプリケーションの動作に必要な外部リソースの名前

- 他のアプリケーションが独自に使用するために参照できる、デプロイ済みのアプリケーション内に提供されるサービスに対して宣言された名前(JNDI名)

- WebLogic Server上のアプリケーションのパフォーマンスと動作を制御するチューニング・プロパティ

これらのデプロイメント・プロパティは、WebLogic Serverデプロイメント・プランに格納できます。

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

基本的なJava EEデプロイメントAPI構成プロセスでは、標準化されたデプロイメント・ツールを使用して、Java EEアプリケーションを複数のアプリケーション・サーバー製品に簡単にデプロイできます。しかし、アプリケーションの構成を組織内のある環境から別の環境へ移行するプロセスには使用できません。一方、Java EEデプロイメントAPIを拡張したWebLogic ServerデプロイメントAPIでは、アプリケーションの構成をエクスポートして複数のWebLogic Server環境(テスト、ステージング、および本番ドメインなど)にデプロイするプロセスがサポートされています。「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。

本番アプリケーションを分離するための管理モード

アプリケーションの分散により、デプロイメント・ファイルがターゲット・サーバーにコピーされ、アプリケーションが準備状態に置かれます。その後は、アプリケーションを管理モードで起動できます。それにより、アプリケーションにアクセスできるのが構成された管理チャネルのみになるため、アプリケーションを外部クライアント接続に対して開いたり、接続されたクライアントを中断させたりすることなく、最終テストを実行できます。アプリケーションを管理モードで起動するには、「分散されたアプリケーションの管理モードでの起動」で説明するように-adminmodeオプションを使用します。「本番環境へのアプリケーションの分散」および「本番アプリケーションの新しいバージョンの分散」を参照してください。

最終テスト実行後は、アプリケーションをアンデプロイしてさらに変更を加えるか、アプリケーションを本番モードで起動して、全般的にクライアントで使用可能にできます。

「アプリケーションの配布」を参照してください。

デプロイ可能なJDBC、JMS、およびWLDFアプリケーション・モジュール

JDBC、JMS、およびWLDFリソースは、アプリケーション・モジュールとして格納できます。これらのモジュールは複数サーバーまたはクラスタにスタンドアロン状態でデプロイすることも、アプリケーション・スコープのリソースとしてエンタープライズ・アプリケーション内に含めることも可能です。スタンドアロンのJDBC、JMSおよびWLDFアプリケーション・モジュールを使用すると、複数のWebLogic Serverドメイン内でリソースを簡単にレプリケートできるようになります。アプリケーション・スコープのリソース・モジュールを使用すると、複数の環境への移植性を最大限に高めるために、アプリケーション・モジュール自体の中にアプリケーションが必要とするリソースをすべて含めることができるようになります。アプリケーション・スコープのリソースの使用の詳細は、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。WebLogic Serverへのスタンドアロン・リソースまたはアプリケーション・スコープのリソースのデプロイについては、「JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ」を参照してください。

エンタープライズ・アプリケーションのモジュール・レベルでのデプロイメントと再デプロイメント

WebLogic Serverでは、エンタープライズ・アプリケーションの個々のモジュールを、様々なサーバー・ターゲットに割り当てることも、エンタープライズ・アプリケーションで利用可能なモジュールのサブセットのみをデプロイすることもできます。これにより柔軟性の高いパッケージング・オプションが得られ、関連するモジュールのグループをまとめてエンタープライズ・アプリケーション内でバンドルし、選択したモジュールのみをドメイン内の個々のサーバーにデプロイできます。

本番アプリケーションの安全な再デプロイメント

WebLogic Serverにより、アプリケーションに対する現在のHTTPクライアントに影響を与えることなく、本番アプリケーションの新しいバージョンを、安全に更新および再デプロイできます。本番再デプロイメントは、アプリケーションのダウンタイムなしに、また変更を加えるために冗長なサーバーを作成することなく、バグ・フィックスや、新しい機能を実現するのに役立ちます。詳細については、「本番環境でのアプリケーションの再デプロイメント」を参照してください。

デプロイメントに必要なセキュリティ・ロール

「Admin」および「Deployer」ユーザーの組込みセキュリティ・ロールにより、WebLogic Server管理コンソールを使用し、デプロイメント・タスクを実行することが可能です。「AppTester」セキュリティ・ロールにより、管理モードに対してデプロイされたアプリケーションのバージョンをテストできます。WebLogicドメインを超えてデプロイする場合、「CrossDomainConnector」ロールにより、外部のドメインからドメイン間の呼び出しを実行することができます。セキュリティ・ロールすべての完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のデフォルト・グローバル・ロールの項を参照してください。

サポートされるデプロイメント・ユニット

デプロイメント・ユニットは、Java EE仕様に従って構成されており、WebLogic Serverにデプロイ可能なJava EEアプリケーション(エンタープライズ・アプリケーションまたはWebアプリケーション)、あるいはスタンドアロンJava EEモジュール(EJB、リソース・アダプタなど)を参照します。

デプロイメント・ユニットのタイプごとに、必要なファイル、およびアプリケーションまたはモジュールのディレクトリ構造内での各ファイルの位置がJava EE仕様で定義されています。デプロイメント・ユニットは、EJBとサーブレットのJavaクラス、リソース・アダプタ、Webページとサポート・ファイル、XML形式のデプロイメント記述子、およびその他のモジュールで構成されています。

Java EEでは、どのようにデプロイメント・ユニットをターゲット・サーバーにデプロイするかは指定されておらず、標準のアプリケーションおよびモジュールの構造のみが指定されています。WebLogic Serverは、以下のタイプのデプロイメント・ユニットをサポートします。

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

- Webアプリケーション

- Enterprise JavaBean

- リソース・アダプタ

- Webサービス

- Java EEライブラリ

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

- JDBC、JMS、およびWLDFモジュール

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

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

エンタープライズ・アプリケーションは、次に示す1つ以上のJava EEアプリケーションまたはモジュールで構成されます。

- Webアプリケーション

- Enterprise JavaBeans (EJB)モジュール

- リソース・アダプタ・モジュール

エンタープライズ・アプリケーションは、.ear拡張子付きでアーカイブ・ファイルとしてパッケージ化されますが、一般には展開したEARディレクトリとしてデプロイされます。展開したEARディレクトリは、アプリケーション用にJAR、WARおよびRARモジュールのすべて(展開したフォーマットで)、またエンタープライズ・アプリケーション、およびそのバンドル・アプリケーションやモジュール用にXML記述子ファイルを含みます。『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

Webアプリケーション

Webアプリケーションは常に以下のファイルを含みます。

- 1つのサーブレットまたはJSPページ、およびヘルパー・クラス

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

Webアプリケーションは、JSPタグ・ライブラリ、静的な.htmlおよびイメージ・ファイル、サポート・クラスや.jarファイル、さらにWebアプリケーション用にWebLogic Server固有の要素を構成するweblogic.xmlデプロイメント記述子を含む場合があります。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。

Enterprise JavaBean

Enterprise JavaBeans (EJBs)は、再利用可能なJavaコンポーネントで、ビジネス・ロジックを実装し、コンポーネント・ベースの分散ビジネス・アプリケーションの開発を可能にします。EJBモジュールは、.jar拡張子がついたアーカイブ・ファイルとしてパッケージ化されますが、通常展開したアーカイブのディレクトリとしてデプロイされます。EJBのアーカイブ・ファイルまたは展開したアーカイブ・ディレクトリは、コンパイルしたEJBクラス、オプションの生成クラスおよびEJBのXMLデプロイメント記述子を含みます。EJBの様々なタイプの情報は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』を参照してください。

リソース・アダプタ

リソース・アダプタ(別称:コネクタ)は、Java EEプラットフォームにEnterprise Information System (EIS)インテグレーションを追加します。コネクタはシステム・レベルのソフトウエア・ドライバを提供し、WebLogic Serverはこれを使用してEISに接続します。コネクタはJavaクラスと、必要に応じてEISとの対話に必要なネイティブなコンポーネントを含みます。『Oracle WebLogic Serverリソース・アダプタの開発』を参照してください。

Webサービス

Webサービスとは、ネットワーク上の他のシステムからも利用でき、分散型Webベース・アプリケーションのコンポーネントとして共有および使用可能な、1つのエンティティにまとめられた一連の関数です。Webサービスは一般的に、カスタマ・リレーションシップ・マネージメント・システム、注文処理システムなどの既存のバックエンド・アプリケーションとインタフェースします。

Webサービス・モジュールはJavaクラス、あるいはWebサービスを実装するEJBのどちらかを含む場合があります。Webサービスは、実装に応じて、Webアプリケーション・アーカイブ(WAR)またはEJBモジュール(JAR)のどちらかとしてパッケージ化されます。通常、WARまたはEJB JARファイルは、さらにエンタープライズ・アプリケーションにパッケージ化されます。『Oracle WebLogic Server JAX-WS Webサービスの開発』を参照してください。

Java EEライブラリ

Java EEライブラリはスタンドアロンのJava EEモジュールか、複数のJava EEモジュールがパッケージされ、デプロイメント時にJava EEアプリケーション・コンテナに共有ライブラリとして登録されたエンタープライズ・アプリケーション(EAR)です。Java EEライブラリの登録後、weblogic-application.xmlデプロイメント記述子でライブラリを参照するエンタープライズ・アプリケーションをデプロイできるようになります。参照側の各アプリケーションは、デプロイメントの際に共有Java EEライブラリ・モジュールのコピーを受け取り、アプリケーション自体の一部としてパッケージ化されているかのように、これらのモジュールを使用できます。Java EEライブラリ・サポートを利用すると、共有モジュールを各依存アプリケーションに物理的に追加しなくても、複数のエンタープライズ・アプリケーション間で1つ以上のJava EEモジュールを簡単に共有できます。

この項で説明したように、共有ライブラリのデプロイメント・ファイルは、標準のエンタープライズ・アプリケーションまたはJava EEモジュールのどちらかに類似しています。共有ライブラリは、MANIFEST.MFファイルの内容のみが、標準EARやモジュールのそれと異なります。Java EEライブラリをアセンブルおよび構成する方法と、Java EEライブラリを利用するエンタープライズ・アプリケーションを構成する方法については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」では、Java EEライブラリおよびJava EEライブラリを参照するエンタープライズ・アプリケーションのデプロイ方法について説明します。

オプション・パッケージ

オプション・パッケージは、Java EEライブラリと似た機能を提供しており、これを使用すると複数のアプリケーション間で単一のJARファイルを簡単に共有できます。ただし、オプション・パッケージは、エンタープライズ・アプリケーションとしてではなく、(スタンドアロンまたはエンタープライズ・アプリケーション内の)個々のJava EEモジュールとして機能します。たとえば、複数のWebアプリケーションで必要とされるサード・パーティのWebアプリケーション・フレームワーク・クラスを、単一のJARファイル内にパッケージ化およびデプロイし、ドメイン内の複数のWebアプリケーション・モジュールから参照することが可能です。

オプション・パッケージは、デプロイメント記述子を持たない基本的なJARファイルとして供給されます。単にJARをデプロイメント時にオプション・パッケージとして指定すれば、WebLogic Serverは選択したターゲット・サーバーにファイルを登録します。オプション・パッケージが登録されると、MANIFEST.MFファイルでオプション・パッケージを参照するJava EEモジュールおよびアプリケーションをデプロイできます。オプション・パッケージをアセンブルおよび構成する方法と、オプション・パッケージを利用するJava EEモジュールを構成する方法については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」では、オプション・パッケージ、およびオプション・パッケージを参照するJava EEモジュールのデプロイ方法を説明します。

JDBC、JMS、およびWLDFモジュール

JMS、JDBC、またはWebLogic診断フレームワーク(WLDF)・アプリケーション・モジュールは、スタンドアロンのリソースとしてデプロイ可能です。その場合、リソースはデプロイメント中にターゲット指定したドメインで、またはエンタープライズ・アプリケーションの一部として使用可能です。エンタープライズ・アプリケーションの一部としてデプロイしたアプリケーション・モジュールは、同梱したアプリケーション(アプリケーション・スコープのリソース)でのみ利用可能です。アプリケーション・スコープのリソースを使用することにより、アプリケーションは常に必要なリソースへ確実にアクセスでき、アプリケーションを新しい環境にデプロイする処理が簡素化されます。

システム・モジュールと対照的に、アプリケーション・モジュールの所有者は、モジュールをデプロイする管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。つまり、JDBC、JMS、およびWLDFアプリケーション・モジュールに対しては、管理者の制御が及ぶ範囲のほうが、より制限されています。アプリケーション・モジュールをデプロイする際、管理者はモジュールで指定されていたリソース・プロパティを変更できますが、リソースの追加や削除は行えません。

システム・モジュールは、WebLogic Server管理コンソールを介して管理者が作成し、必要に応じて管理者により変更または削除可能です。同様に管理者が作成したスタンドアロンのアプリケーション・モジュールは、モジュールを新しいドメインにデプロイするのみで、複数のWebLogic Server環境におけるグローバル・リソースの再作成に使用できます。

JDBC、JMS、およびWLDFモジュールのデプロイ方法の詳細は、次を参照してください。

- JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ

- Oracle WebLogic Server JMSリソースの管理

- Oracle WebLogic Server JDBCデータ・ソースの管理

- Oracle WebLogic Server診断フレームワークの構成と使用

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

Java EE仕様では、クライアント・アプリケーションのアーカイブ・ファイル(.jarファイル)をモジュールとしてエンタープライズ・アプリケーション(.earファイル)内に組み込むことができます。Java EEクライアント・アプリケーション・モジュールには、クライアントJVM(Java仮想マシン)で実行するJavaクラスと、EJB(Enterprise JavaBeans)、およびクライアントによって使用されるその他のWebLogic Serverリソースに関するデプロイメント記述子が収められます。これによりサーバー側とクライアント側のコンポーネントを1つのユニットとして配布できます。EAR内で、Java EE標準のapplication-client.xmlデプロイメント記述子およびWebLogic Server weblogic-appclient.xml記述子を使用して、クライアント・モジュールを定義します。

デプロイメント・ツール

Weblogic Serverでは、アプリケーションの構成とデプロイに役立つ次のツールが用意されています。

- weblogic.Deployer

- WebLogic Server管理コンソール

- WLST

- 開発者用のデプロイメント・ツール

weblogic.Deployer

weblogic.Deployerでは、コマンド・ライン・ベースのインタフェースを使用して、デプロイメントの基本的なタスクおよび高度なタスクの両方を実行できます。weblogic.Deployerは、WebLogic Serverのデプロイメント機能にコマンド行からアクセスする必要がある場合、またはサポートされていないデプロイメント・タスクをWebLogic Server管理コンソールを使用して実行する必要がある場合に使用します。

WebLogic Server管理コンソール

WebLogic Server管理コンソールに用意されているWebベースの一連のデプロイメント・アシスタントを使用して、デプロイ手順を実行できます。WebLogic Server管理コンソールでは、デプロイメント・ステータスを変更およびモニターしたり、デプロイメント・ユニットが起動され実行されている間に、選択したデプロイメント記述子の値を変更したりできます。

WebLogic Server管理コンソールは、基本的なデプロイメントの機能をインタラクティブに実行する必要があり、サポートされているブラウザにアクセスできる場合に使用します。

WLST

WebLogic Scripting Tool (WLST)は、アプリケーション・デプロイメント構成およびデプロイ操作を含めたドメイン構成タスクを自動化できるコマンド行インタフェースです。詳細は、『WebLogic Scripting Toolの理解』を参照してください。

開発者用のデプロイメント・ツール

WebLogic Serverには、アプリケーションおよびスタンドアロン・モジュールをデプロイするための次のようなツールが備わっています。

- wldeploy。weblogic.DeployerユーティリティのAntタスク・バージョンです。デプロイメント・タスクを自動化するには、Antのbuild.xmlファイルにwldeployコマンドを配置し、Antを実行してそのコマンドを実行します。

- weblogic-maven-pluginは、WebLogic Server用のMavenプラグインで、これを使用するとweblogic.Deployerによってサポートされているものと同様のデプロイメント操作を実行できます。このプラグインによって、Maven環境内からWebLogic ServerへMavenを使用して構築されたアプリケーションのデプロイ、再デプロイ、更新などを実行できるようになります。

- weblogic.PlanGenerator。開発者が複数のWebLogic Server環境へのデプロイメント用にアプリケーションの構成をエクスポートできる、コマンド行ツールです。

- デプロイメントAPI。Javaクラスを使用してデプロイメント・タスクをプログラム的に実行できます。

- autodeployドメイン・ディレクトリ。開発環境で評価またはテストを行うためのアプリケーションを素早くデプロイできます。

3 アプリケーションおよびモジュールのデプロイメント準備

この章では、WebLogic Server 12.1.3へのデプロイメントについて、アプリケーションとモジュールを準備する方法を説明します。

この章には次の項が含まれます:

- デプロイするファイルのパッケージ化

- デフォルト・デプロイメント名の理解

- アプリケーションのネーミング要件の理解

- デプロイメント・バージョン文字列の理解

- アプリケーションのインストール・ディレクトリの作成

- FastSwapデプロイメントによる再デプロイメントの最小化

- デプロイメント・ファイルの準備のベスト・プラクティス

デプロイするファイルのパッケージ化

WebLogic Serverは、jarユーティリティまたはAntのjarツールを使用してアーカイブ・ファイルとしてパッケージ化されたデプロイメント、または展開されたアーカイブ・ディレクトリとしてパッケージ化されたデプロイメントをサポートしています。

注意:
一般に、アーカイブ・ファイルを使用して、より効率的に管理対象サーバー上にアプリケーションのデプロイができます。ただし、アプリケーションの再デプロイメントが必要とされるため、Webコンテンツの更新などのアプリケーションの更新がより難しくなります。

- アーカイブ・ファイルの使用

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

- アーカイブ・ファイルからの展開されたアーカイブ・ディレクトリの作成

アーカイブ・ファイルの使用

アーカイブ・ファイルは、アプリケーションまたはモジュールのクラス、静的ファイル、ディレクトリ、およびデプロイメント記述子ファイルをすべて含む単一のファイルです。大半の本番環境において、管理者がデプロイメント用に受け取るアプリケーションは、アーカイブ・ファイルとして格納されます。

jarユーティリティを使用してパッケージ化されたデプロイメント・ユニットには、タイプ別に特定のファイル拡張子が付きます。

- EJBおよびクライアント・アーカイブは、.jarファイルとしてパッケージ化されます。

- Webアプリケーションは、.warファイルとしてパッケージ化されます。

- リソース・アダプタは、.rarファイルとしてパッケージ化されます。

- エンタープライズ・アプリケーションは、.earファイルとしてパッケージ化され、Webアーカイブ(.warファイル)、EJBアーカイブ(.jarファイル)、コネクタ・アーカイブ(.rarファイル)およびクライアント・アーカイブ(.jarファイル)などの他のJava EEモジュールを含めることができます。

- Webサービスは、Javaクラスを使用して実装したか、EJBを使用して実装したかに応じて、.warファイル、.jarファイルのいずれかとしてパッケージ化できます。通常、.warまたは.jarファイルは、さらにエンタープライズ・アプリケーション.earファイルにパッケージ化されます。

- Java EEライブラリは、エンタープライズ・アプリケーション(.earファイル)か、標準のJava EEモジュールとしてパッケージ化されます。

- クライアント・アプリケーションおよびオプション・パッケージは、.jarファイルとしてパッケージ化されます。

アーカイブ・ファイルに加えて、特定の環境についてアプリケーションを構成する別個のファイルである、デプロイメント・プランを受け取ることになる場合があります。デプロイメント・プランについての詳細は、「本番デプロイメントのためのアプリケーションの構成」で説明しています。

展開されたアーカイブ・ディレクトリの使用

展開されたアーカイブ・ディレクトリには、JARアーカイブと同じファイルおよびディレクトリが格納されています。展開されたアーカイブ・ディレクトリの使用を選択すると、それ以前にアーカイブされたデプロイメントを手動で復元することが必要になる場合があります。ただし、それらのファイルとディレクトリは、ファイル・システム上に直接存在し、jarユーティリティを使用して単一のアーカイブ・ファイルにパッケージ化されていません。

次のような状況下であれば、展開されたアーカイブ・ディレクトリからのデプロイを選択できます。

- デプロイメント後に、エンタープライズ・アプリケーションを部分的に更新する必要がある場合。エンタープライズ・アプリケーションを展開されたアーカイブ・ディレクトリとしてデプロイすると、アーカイブ・ファイルを再作成することなく、アプリケーションの個々のモジュールを更新しやすくなります。

- 定期的に更新される静的ファイルを含むWebアプリケーションまたはエンタープライズ・アプリケーションをデプロイする場合。この場合は、アプリケーションを展開されたディレクトリとしてデプロイする方が便利です。そうすればアーカイブを再作成せずに静的ファイルを更新とリフレッシュできるからです。

- アプリケーション・コンテキストを通じてファイル・システムに直接I/Oを実行するWebアプリケーション(たとえば、自身の一部を動的に編集または更新しようとするWebアプリケーション)をデプロイする場合。この場合、I/O操作を実行するモジュールには、操作を実行するための物理ファイル・システム・ディレクトリが必要です。仕様により、アプリケーションをアーカイブとしてデプロイする時点でファイルを取得することはできません。

デプロイメント記述子を含まない展開されたEARディレクトリをデプロイする場合のJava EEルール

Java EE仕様では、アーカイブされたEAR (エンタープライズ・アプリケーション・アーカイブ)をデプロイメント記述子を含まない状態でJava EE準拠のサーバーにデプロイすることが推奨されています。正常のデプロイするには、すべてのコンテナで、妥当なデフォルト値の設定か、アノテーション付きのクラスの使用が必要になります。WebLogic Serverでは、この規定のサポートの他に、デプロイメント記述子のない展開されたEARディレクトリのデプロイも可能になります。

こうしたデプロイメントがディレクトリに適用される場合、EARとそのネストされたモジュールの特定には一定のルールが使用されます。そうでないと、WebLogic Server管理コンソールまたはデプロイメント・ツールは、それらのディレクトリを、展開された有効なJava EEディレクトリとして処理しません。

- WEB-INF/web.xml記述子のない展開されたアーカイブWebアプリケーションについては、ディレクトリ名に.war接尾辞が付いている必要があります。

- META-INF/application.xml記述子のない展開されたアーカイブ・エンタープライズ・アプリケーションについては、ディレクトリ名に.ear接尾辞が必要です。アプリケーション内では、展開されたWebモジュールのディレクトリ名に.war接尾辞が必要です。同様に、展開されたEJBモジュールには.jar接尾辞と展開されたRARモジュールには.rar接尾辞を指定する必要があります。

- 展開されたエンタープライズ・アプリケーションにMETA-INF/application.xml記述子が含まれていない場合は、モジュールのデプロイ順が未定義になり、デプロイ順が基底のFile.listFiles()メソッド順序に依存します。モジュールを特定の順序でデプロイするには、application.xml記述子を追加し、その順序でモジュールをリストする必要があります。

アーカイブ・ファイルからの展開されたアーカイブ・ディレクトリの作成

展開されたアーカイブ・ディレクトリとしてデプロイするアーカイブ・ファイルがある場合は、jarユーティリティを使用してアーカイブ・ファイルを専用ディレクトリに復元します。例:

mkdir /myapp
cd /myapp
jar xvf /dist/myapp.ear

復元するアーカイブ・ファイルに他のモジュール・アーカイブ・ファイル(たとえば、JARファイルやWARファイルを含むエンタープライズ・アプリケーションまたはWebサービス)が含まれていて、それらのモジュールの部分的な更新を行う場合には、組み込まれたアーカイブ・ファイルも展開する必要があります。各モジュールをアーカイブ・ファイルと同じ名前のサブディレクトリに解凍する必要があります。たとえば、myejb.jarという名前のモジュールは、展開したエンタープライズ・アプリケーション・ディレクトリの/myejb.jarサブディレクトリに復元します。

注意:
展開した.EARファイルのアーカイブ・モジュールに異なるサブディレクトリ名を使用する場合は、アプリケーション自体の中で使用しているこれらのモジュールへの参照を修正する必要があります。たとえば、manifest.mfファイルのapplication.xmlおよびCLASSPATHのエントリに指定されているURI値を更新する必要があります。

デフォルト・デプロイメント名の理解

初めて、1つまたは複数のWebLogic Serverインスタンスにアプリケーションまたはスタンドアロン・モジュールをデプロイする場合、デプロイメント・ファイル、ターゲット・サーバー、および選択したその他の構成オプションを総体的に記述するためにデプロイメント名を指定します。次に、デプロイメント名を使用して、すべてのターゲット・サーバー上のデプロイメント・ユニットの再デプロイまたは停止を簡単に行えます。デプロイメント名を使用することによって、ドメイン内の複数サーバー間のデプロイメント・ユニットを操作する場合のデプロイメント・ファイルおよびターゲット・サーバーの再識別が簡単に行えます。

デプロイメント時にデプロイメント名を指定しない場合、デプロイメント・ツールによってデプロイメント・ソース・ファイルに基づくデフォルトの名前が選択されます。アーカイブ・ファイルの場合、weblogic.Deployerはアーカイブ・ファイル名からファイル拡張子を抜いて使用します。たとえば、ファイルmyear.earのデフォルト・デプロイメント名は、myearとなります。展開されたアーカイブ・ディレクトリの場合、weblogic.Deployerはデプロイする最上位ディレクトリの名前を使用します。自動的にデプロイされたアプリケーションおよびスタンドアロン・モジュールは、その他のアプリケーション用に記載されるとおりに、計算された名前を取得します。これにはファイル拡張子は付かず、アンダースコアで始まる文字列が先頭に追加されることもありません。

Java EEライブラリおよびオプション・パッケージの場合、weblogic.Deployerはライブラリのマニフェスト・ファイルで指定されている名前を使用します。ライブラリのマニフェスト・ファイルで名前が指定されていなければ、-nameオプションで名前を指定できます。

WebLogic Server 12.1.1の時点で、Java EE 6仕様に準拠し、アプリケーション名を指定する追加の方法(application.xml内の<application-name>要素)があります。スタンドアロン・モジュールの場合、それぞれのデプロイメント記述子に<module-name>要素を指定できます。デプロイメント記述子内で提供されるアプリケーション名(application.xml内のapplication-nameまたはweb.xml内のmodule-name)は、weblogic.Deployer -nameオプションまたはマニフェスト・アプリケーション名属性によってもオーバーライドされます。

ネーミングの優先順位は、高い順に次のとおりとなります。

- -name weblogic.Deployerオプション。

- マニフェスト・ファイルで指定される名前。

- デプロイメント記述子で指定される名前。

- デプロイメント・ソース・ファイルに基づいて計算された名前。

提供または計算されたアプリケーション/モジュール名がすでに使用されている場合、WebLogic Serverによって数字の接尾辞が追加され、その名前は一意の名前に変更されます。

アプリケーションのネーミング要件については次のアプリケーションのネーミング要件の理解に関する項を、デフォルト以外のデプロイメント名の指定についてはweblogic.Deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。

アプリケーションのネーミング要件の理解

アプリケーションのWebLogic Serverへのデプロイを正常に実行するには、アプリケーション名が有効であることが必要です。アプリケーションのネーミング要件は、次のとおりです。

- アプリケーション名は、次の文字のみを含む必要があります。

- a-z

- A-Z

- 0-9

- _ (アンダースコア)

- - (ハイフン)

- . (ピリオド)

それ以外の文字をアプリケーション名に含めることはできません。

- 文字. (ピリオド)を含むアプリケーション名には、少なくとも1つの別の文字が含まれている必要があります。「.」および「..」は、有効なアプリケーション名にはなりません。

- アプリケーション名の長さは、215文字未満とする必要があります。

デプロイメント・バージョン文字列の理解

デプロイメント名に加えて、アプリケーションまたはモジュールには、バージョン文字列を関連付けることもできます。バージョン文字列により、アプリケーションの初期デプロイメントと、後の再デプロイされたバージョンが区別されます。たとえば、問題点を修正したり、新しい機能を追加したりするために、アプリケーションを後から更新する場合があります。本番システムでは、アプリケーションの最初のデプロイメントと後続のデプロイメントの双方についてバージョン文字列を維持することが非常に重要です。そうすることで、既存のクライアントに対するサービスを中断させることなく、アプリケーションのバージョンを更新し、再デプロイを行えます。詳細については、「本番環境でのアプリケーションの再デプロイメント」を参照してください。

アプリケーションのマニフェスト・ファイルにバージョン文字列を指定します。開発チームは他のデプロイメント・ファイルと一緒にこのファイルを提供する必要があります。『Oracle WebLogic Serverアプリケーションの開発』のアプリケーションのバージョンの割当に関する項では、バージョン文字列を指定する際の規約について説明しています。

アプリケーションのインストール・ディレクトリの作成

アプリケーションのインストール・ディレクトリにより、生成された構成ファイルはコア・アプリケーション・ファイルから分離されるため、構成ファイルはアプリケーション自体を乱すことなく、簡単に変更または置換できます。このディレクトリ構造はまた、同じアプリケーション・デプロイメント・ファイルの複数バージョンの整理と維持にも役立ちます。

次の図では、デプロイ可能なアプリケーションまたはモジュールの1つのバージョンを格納するアプリケーション・インストール・ディレクトリの階層を示します。

図3-1 アプリケーションのインストール・ディレクトリ

すべての新しい本番デプロイメントを、WebLogic Serverドメインにデプロイする前に、アプリケーションのインストール・ディレクトリにコピーしておくことをお薦めします。このディレクトリ構造からデプロイすることで、デプロイメント・ユニットと関連付けられたファイルをすべて簡単に識別できるようになります。WebLogic Server管理コンソールを使用してインストール・ルートをデプロイするだけで、WebLogic Server管理コンソールが自動的にデプロイメント・プランやWebLogic Serverデプロイメント記述子など、構成中に生成された関連ファイルを見つけます。

アプリケーションのインストール・ディレクトリを作成する手順

アプリケーションのインストール・ディレクトリを作成するには:

1. システム上でアプリケーションおよびモジュールのデプロイメント・ファイルを格納する最上位ディレクトリを選択します。以下のベスト・プラクティスにしたがってください。

- WebLogic Serverドメイン・ディレクトリ内にデプロイメント・ファイルを格納しません。

- 可能であればソース・コントロールを使用して、デプロイメント・ソース・ファイルを維持します。

- 可能であれば、ドメイン内の管理サーバーおよび管理対象サーバーからアクセスできるディレクトリにデプロイメント・ファイルを格納します。

次の手順では、サンプル・デプロイメント・ディレクトリc:\deployments\productionを使用しています。

2. デプロイするアプリケーションまたはモジュール専用のサブディレクトリを作成します。

mkdir c:\deployments\production\myApplication

3. デプロイしているアプリケーションのバージョンを指定するために、アプリケーション・ディレクトリの下にサブディレクトリを作成します。アプリケーションの正確なバージョン文字列を使用して、サブディレクトリに名前を付けます。例:

mkdir c:\deployments\production\myApplication\91Beta

4. バージョン・サブディレクトリは、ディレクトリのデプロイ元であるインストール・ルート・ディレクトリとなります。バージョン・サブディレクトリの下に、appおよびplanという名前のサブディレクトリを作成します。

mkdir c:\deployments\production\myApplication\91Beta\app
mkdir c:\deployments\production\myApplication\91Beta\plan

注意:
アプリケーションに関連付けられたデプロイメント・プランが複数ある場合は、各プランにつき1つの\planサブディレクトリを作成します。たとえば、アプリケーションmyApplicationの91Betaバージョンに関連付けられたデプロイメント・プランが2つある場合は、\planサブディレクトリを2つ作成します。次に例を示します。

- mkdir c:\deployments\production\myApplication\91Beta\plan1

- mkdir c:\deployments\production\myApplication\91Beta\plan2

5. アプリケーション・ソース・デプロイメント・ファイルを\appサブディレクトリにコピーします。アーカイブ・ファイルからデプロイしている場合は、次のように、単にアーカイブ・ファイルをコピーします。

cp c:\downloads\myApplication.ear c:\deployments\production\myApplication\91Beta\app

展開されたアーカイブ・ディレクトリからデプロイしている場合は、展開されたアーカイブ・ディレクトリ全体を\appにコピーします。

cp -r c:\downloads\myApplication c:\deployments\production\myApplication\91Beta\app

その結果、新しいディレクトリc:\deployments\production\myApplication\91Beta\app\myApplicationが作成されます。

6. アプリケーションについて、1つまたは複数のデプロイメント・プランがある場合は、それらを\planサブディレクトリにコピーします。
アプリケーションのデプロイメント・プランが1つの場合は、次のようになります。

cp c:\downloads\myApplicationPlans\plan.xml c:\deployments\production\myApplication\91Beta\plan

アプリケーションのデプロイメント・プランが2つの場合は、次のようになります。

cp c:\downloads\myApplicationPlans\plan1.xml c:\deployments\production\myApplication\91Beta\plan1
cp c:\downloads\myApplicationPlans\plan2.xml c:\deployments\production\myApplication\91Beta\plan2

注意:
既存のデプロイメント・プランがなければ、「本番デプロイメントのためのアプリケーションの構成」で説明するように、WebLogic Server管理コンソールを使用して作成できます。WebLogic Server管理コンソールは、アプリケーションのインストール・ディレクトリの\planサブディレクトリに、新しく生成されたデプロイメント・プランを自動的に格納します。

7. WebLogic Server管理コンソールを使用してアプリケーションをインストールするには、アプリケーションのインストール・ディレクトリを選択します。デフォルトでは、plan.xmlという名前のプランが\planサブディレクトリ内にあれば、WebLogic Server管理コンソールはそれを使用します。WebLogic Server管理コンソールは、\planサブディレクトリ以外のサブディレクトリ内にあるプランを識別しません。つまり、\plan1または\plan2サブディレクトリ内のプランは、WebLogic Server管理コンソールでは識別されません。したがって、アプリケーションのプランが複数ある場合は、config.xmlの中で、使用するプランを指定する必要があります。「本番デプロイメントのためのアプリケーションの構成」を参照してください。config.xmlについては、『構成ウィザードによるWebLogicドメインの作成』を参照してください。
アプリケーションをインストール後は、必要に応じてアプリケーションを構成、デプロイ、または配布できます。

注意:
weblogic.Deployerツールを使用しているときは、アプリケーションのインストール・ディレクトリを指定できず、利用可能なplan.xmlファイルがツールによってデフォルトで使用されることはありません。デプロイメントに使用する実際のデプロイメント・ファイルおよびプランを指定する必要があります。「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。

FastSwapデプロイメントによる再デプロイメントの最小化

Webアプリケーション開発者は、デプロイされたアプリケーションに変更を加えたら、その変更をブラウザをリフレッシュしてすぐに確認したいと考えています。Java EEサイドで作業中の変更を確認するには、開発者は通常、次のサイクルを行う必要があります。

編集 ->ビルド ->デプロイ ->テスト

これらのステップでは、多くの記述子要素が必要であり、Java EEを使用したアプリケーション開発が複雑で最初の工程に負担がかかるのはそのためです。これらのステップのビルド・サイクルとデプロイ・サイクルは、Javaおよび使用するアプリケーション・サーバーで必要になります。IDEでは、段階的なコンパイル・サポートによって編集ステップとビルド・ステップをシームレスに行うことができます。また、サーバー側では、WebLogic Server FastSwapデプロイメント機能がデプロイ・サイクルとテスト・サイクルのシームレス化を実現しています。

FastSwapデプロイメントの仕組み

Java EE 5では、クラスローダーを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。しかし、クラス(宣言されたフィールドとメソッド)の形式が変更できないという制限によって、Java EE動的クラスの再定義は大幅に制限されます。FastSwapの目的は、WebLogic Serverにおいてこの制限をなくし、新しい形式のクラスを動的に再定義できるようにして反復的な開発を容易にすることです。

FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。かわりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。

FastSwapでサポートされるアプリケーション構成

FastSwapデプロイメントを使用する場合、次のアプリケーション構成がサポートされます。

- FastSwapは、WebLogic Serverが開発モードで実行している場合にのみサポートされます。本番モードの場合は、自動的に無効になります。

- 展開されたディレクトリ内のクラス・ファイルへの変更のみサポートされます。アーカイブされたアプリケーション内のクラス・ファイルや、アプリケーションのクラスパスに含まれるアーカイブされたJARファイルへの変更はサポートされません。以下に例を示します。

- EARに含まれるアーカイブされたWARとしてWebアプリケーションがデプロイされる場合、クラスへの変更はFastSwapエージェントによって認識されません。

- 展開されたWebアプリケーション内のJavaクラスへの変更は、WEB-INF/classesディレクトリ内でのみサポートされ、FastSwapエージェントはWEB-INF/libに含まれるアーカイブされたJARへの変更は認識しません。

アプリケーションにおけるFastSwapの有効化

アプリケーションでFastSwapを有効にするには、weblogic-application.xmlファイルに次の要素を追加します。

<fast-swap>
<enabled>true</enabled>
</fast-swap>

weblogic-application.xml要素の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

スタンドアロンのWebアプリケーションでFastSwapを有効にするには、weblogic.xmlファイルに<fast-swap要素を追加します。weblogic.xml要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。

FastSwapプロセスの概要

FastSwapデプロイメント・プロセスの手順を以下に示します。

1. 記述子レベルでFastSwapが有効になると、アプリケーションがWebLogic Serverにデプロイされ、適切なクラスローダーがインスタンス化されます。

2. ブラウザをオープンして動作中のアプリケーションを確認します。次に、メソッドまたはクラス(あるいはその両方)を変更(追加/編集/削除)し(「FastSwap使用時の制限」を参照)、コンパイルします。
EclipseやIntelliJなどのIDEを使用して、Javaファイルが保存時にコンパイルされるように保存時にコンパイルするオプションを設定することをお薦めします。FastSwapエージェントはJavaファイルをコンパイルしません。

3. ブラウザをリフレッシュするか、アプリケーションに新しいリクエストを送信します。
FastSwapエージェントは、クラスパスに含まれるすべてのディレクトリを検索することによって、最後の反復処理から変更されたすべてのクラスを検索しようとします。展開されたアプリケーションが単一のWebアプリケーションである場合、次のディレクトリに対してタイムスタンプに基づいてクラス・ファイルの変更の有無が調査されます。

ExampleApp/APP-INF/classes
ExampleApp/webapp/WEB-INF/classes

FastSwapエージェントは、アプリケーションの変更されたクラスを再定義し、リクエストを処理します。

AntでのJMXインタフェースの使用

「ヘッドレス」アプリケーション(Webアプリケーションを経由しないアプリケーション)の場合、クラスの再定義はJMXインタフェースを使用して明示的に初期化できます。JMXインタフェースを使用するAntタスクは、クラスの再定義の初期化に使用できます。Ant FastSwapタスクの例を次に示します。

例3-1 AntでのJMXインタフェースの使用

<project name='MyProject' default='all' >
<taskdef name='fast-swap'  classname='com.bea.wls.redef.ant.FastSwapTask'/>
<target name='all'>
<!--
Redefine classes which have changed since they were last loaded.
Required parameters:
adminUrl: Connection url
user: User name
password: User password
server: Managed server name
application: Deployed application name
Optional parameters:
module: Name of the module within the application.
If not specified, all modules within the application
will be processed.
failonerror: Default=true. If true, task will fail if fast-swap failed.
Otherwise, a message will be displayed and the task will
return success.
timeout: Default=300. Timeout in seconds.
classnames: Comma separated list of classnames to process. If not
specified, all classes within specified modules (if any)
in the application will be considered.
-->
<fast-swap
adminUrl='t3://localhost:7001'
user='weblogic'
password='weblogic'
server='myserver'
application='SimpleApp'
module='SimpleAppCookie'
failonerror='false'
timeout='30'
classnames='examples.servlets.CookieCounter1,
examples.servlets.CookieCounter2,
examples.servlets.CookieCounter'
/>
</target>
</project>

FastSwapでサポートされるアプリケーション・タイプと変更

FastSwapは、展開形式でデプロイされたPOJO (JAR)、Webアプリケーション(WAR)、およびエンタープライズ・アプリケーション(EAR)でサポートされます。FastSwapは、リソース・アダプタ(RAR)ではサポートされません。

FastSwapでサポートされる変更のタイプを以下に示します。

- 静的メソッドの追加

- 静的メソッドの削除

- インスタンス・メソッドの追加

- インスタンス・メソッドの削除

- 静的メソッド本体の変更

- インスタンス・メソッド本体の変更

- 静的フィールドの追加

- 静的フィールドの削除

- インスタンス・フィールドの追加

- インスタンス・フィールドの削除

次の表に、FastSwapでサポートされる変更タイプの詳細を示します。

表3-1 サポートされるアプリケーション・タイプおよび変更

スコープ

Javaの変更タイプ

サポート

ノート

Javaクラス

メソッドの追加

はい

finalizeメソッドの追加はサポートされません。

インスタンス(非抽象)

メソッドの削除

はい

finalizeメソッドの追加はサポートされません。

a)フィールドの追加

はい

b)フィールドの削除

はい

c)メソッド本体の変更

はい

d)コンストラクタの追加

はい

e)コンストラクタの削除

はい

f)フィールド修飾子の変更

はい

g)メソッド修飾子の変更

はい

クラス・レベル(静的)

メソッドの追加

はい

メソッドの削除

はい

メソッド本体の変更

はい

クラス階層の変更

実装インタフェースのリストの変更

いいえ

「SuperClass」拡張の変更

いいえ

抽象Javaクラス

抽象メソッドの追加

はい

抽象メソッドの削除

はい

インスタンスでサポートされるその他のすべての変更(a - g)

はい

「final」 Javaクラス

インスタンスでサポートされる変更(a - g)

はい

「final」 Javaメソッド

インスタンスでサポートされる変更(a - g)

はい

「final」 Javaフィールド

インスタンスでサポートされる変更(a - g)

はい

Enum

定数の追加

いいえ

定数の削除

いいえ

メソッドの追加/削除

いいえ

無名内部クラス

フィールドの追加/削除

NA

Java言語でサポートされない

メソッドの追加/削除

いいえ

静的内部クラス

インスタンスでサポートされる変更(a - g)

はい

メンバー内部クラス(非静的内部クラス)

インスタンスでサポートされる変更(a - g)

はい

ローカル内部クラス

インスタンスでサポートされる変更(a - g)

はい

Javaインタフェース

メソッドの追加

はい

Javaリフレクション

既存のフィールド/メソッドへのアクセス

はい

新しいメソッドへのアクセス

いいえ

リフレクションでは新しいメソッドは公開されません。一部の合成メソッドは公開されます。

新しいフィールドへのアクセス

いいえ

リフレクションでは新しいフィールドは公開されません。

クラスのアノテーション

メソッド/フィールド・アノテーションの追加または削除

いいえ

アノテーション・タイプ

メソッド/属性の追加または削除

いいえ

例外クラス

インスタンスでサポートされる変更(a - g)

はい

EJBインタフェース

メソッドの追加/削除

いいえ

EJBインタフェースの変更には、フル・サポートではないリフレクションを使用。

EJB 3.0セッション/MDB

EJB実装クラス

メソッドの追加/削除

いいえ

EJBクラスによって参照されるサポート・クラスは変更可能です。

フィールドの追加/削除

いいえ

EJB 3.0エンティティBean

メソッドの追加/削除

いいえ

EJBクラスによって参照されるサポート・クラスは変更可能です。

フィールドの追加/削除

いいえ

EJBインターセプタ

メソッドの追加/削除

いいえ

EJBクラスによって参照されるサポート・クラスは変更可能です。

フィールドの追加/削除

いいえ

FastSwap使用時の制限

FastSwapデプロイメントを使用する場合、次のような制限が適用されます。

- Javaリフレクションの結果には、新しく追加されたフィールドとメソッドが含まれず、削除されたフィールドとメソッドが含まれます。その結果、リフレクションAPIを使用すると、予期しない結果になる可能性があります。

- 既存のクラスの階層は、FastSwapでは変更できません。たとえば、クラスの実装インタフェースのリストの変更や、クラスのスーパークラスの変更はサポートされません。

- Javaアノテーションの追加または削除は、FastSwapではサポートされません(上述のリフレクション変更に関係するため)。

- EJBインタフェースの追加または削除は、EJBコンパイル・ステップで実行時に変更を反映する必要があるため、FastSwapではサポートされません。

- Enumの定数の追加または削除はサポートされません。

- finalizeメソッドの追加または削除はサポートされません。

- フィールド名を変更する場合、オブジェクトの状態は保持されません。これは、古い名前のフィールドを削除し、新しい名前のフィールドを追加する場合の変更です。この場合、古いフィールドの状態はすべて、名前変更後のフィールドに持ち越されません。インスタンスの値がリセットされることを踏まえた上でフィールド名を変更してください。

FastSwapでサポートされない変更の処理

FastSwapが有効な場合、クラスを再コンパイルした後にFastSwapは既存のクラスローダーにクラスを再定義しようとします。行った変更がFastSwapでサポートされる変更のスコープ外である場合、再定義は失敗し、JVMによってWebLogic Serverウィンドウとサーバー・ログ・ファイルにUnsupportedOperationExceptionがスローされます。アプリケーションは変更を反映しませんが、実行は継続されます。

変更を反映するには、アプリケーション・タイプと変更の範囲に応じて、アプリケーションまたは影響を受けるモジュール(部分的な再デプロイ)を再デプロイします。

デプロイメント・ファイルの準備のベスト・プラクティス

アプリケーションおよびモジュールのデプロイメント準備を行う際には、次のベスト・プラクティスをお薦めします。

- デプロイするのがアーカイブ・ファイルであっても展開されたアーカイブ・ディレクトリであっても、「アプリケーションのインストール・ディレクトリの作成」で説明したように、デプロイメント・ファイルはアプリケーションのインストール・ディレクトリに格納します。インストール・ディレクトリを使用することで、WebLogic Server管理コンソールはデプロイメント・ファイルおよび構成ファイルの場所を認識できるので、デプロイメント・プロセスが簡素化されます。

- 必要に応じて、以前のバージョンのアプリケーションに簡単に戻れるよう、アプリケーションのインストール・ディレクトリ全体を、ソース・コントロール・システムで管理します。

4 本番デプロイメントのためのアプリケーションの構成

この章では、アプリケーションを本番WebLogic Server 12.1.3環境にデプロイするための構成方法について説明します。

この章には次の項が含まれます:

- デプロイメント構成プロセスの理解

- 一般的なデプロイメント構成のワークフロー

- アプリケーションを構成するための新しいデプロイメント・プランの作成

- デプロイメント・プランの内容の理解

- 既存のデプロイメント・プランを使用したアプリケーションの構成

- 汎用ファイル・ロード・オーバーライド

- 追加の構成タスク

- アプリケーション構成管理のベスト・プラクティス

デプロイメント構成プロセスの理解

通常、管理者やデプロイヤが開発チームまたは品質保証チームから新しいアプリケーションや新しいバージョンのアプリケーションを受け取る場合、アプリケーションは開発環境またはテスト環境用に構成されています。そのアプリケーションでは、特定のリソース名やパフォーマンス・チューニング設定(アプリケーションが最後にデプロイされた開発環境またはQA環境で使用されていたターゲット・サーバー上で利用可能なリソースに一致する名前や設定)が使用されている可能性があります。

開発環境およびテスト環境は、アプリケーションが最終的にデプロイされる本番環境とは著しく異なっている可能性があるため、管理者は本番環境について有効かつ適切なリソース名およびパフォーマンス・チューニング・パラメータを使用するように、アプリケーションを構成する必要があります。

- デプロイメント構成のライフサイクル

- アプリケーションのデプロイメント記述子の理解

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

- 本番デプロイメント構成の目標

デプロイメント構成のライフサイクル

アプリケーションのデプロイメント構成は、アプリケーションのライフサイクルにおいて、いくつかの時点で行われる可能性があります。デプロイメント構成の各フェーズでは一般に、様々なデプロイメント・ファイルの作成と処理が行われます。

1. 開発構成 - 開発中、プログラマはアプリケーションまたはモジュールのJava EEデプロイメント記述子を作成します。プログラマは、また、WebLogic Server開発環境にデプロイするアプリケーションを構成するWebLogic Serverデプロイメント記述子を作成します。『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

注意:
WebLogic Server開発環境の外部で開発されたアプリケーション(たとえば、サンプル・アプリケーション、またはPetStoreなどサード・パーティのJava EEアプリケーション)には、Java EE記述子しか含まれていない場合があります。

2. エクスポート構成 - アプリケーションを開発からリリースする前に、プログラマまたは設計者は必要に応じて、アプリケーションのデプロイメント構成をWebLogic Serverデプロイメント・プランにエクスポートできます。構成のエクスポートによって、開発者がアプリケーションのWebLogic Serverデプロイメント記述子ファイルで定義したデプロイメント・プロパティの全部または一部のためのデプロイメント・プラン変数が作成されます。「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。
アプリケーションのエクスポートにより、組織における別分野のデプロイヤ(QAチームの技術者、本番管理者など)が、プログラマの開発環境とは異なる環境へ、アプリケーションを簡単にデプロイできるようになります。理想的なデプロイメント・プランには、新しい環境でアプリケーションをデプロイする前にデプロイヤが変更する必要のあるすべてのプロパティが含まれています。

3. デプロイメント時の構成 - 管理者またはデプロイヤは、ターゲット環境にアプリケーションをデプロイする前に、アプリケーションの構成を行います。デプロイメント時の構成では、以下を使用できます。

- 開発時に作成されたWeblogic Serverデプロイメント構成およびデプロイメント・プラン

- これらの開発構成およびデプロイメント・プランの修正版

- それぞれの組織のデプロイメント構成ワークフローに応じ、デプロイヤがその環境用に事前に作成したカスタム・デプロイメント・プラン

「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。

4. デプロイメント後の構成 - アプリケーションがターゲット環境にデプロイされた後は、管理者またはデプロイヤは新しいデプロイメント・プランでの再デプロイメントによって、またはWebLogic Server管理コンソールを使用した既存のデプロイメント・プランの更新および再デプロイメントによって、アプリケーションを再構成できるようになります。「本番環境でのアプリケーションの再デプロイメント」および「デプロイされたアプリケーションの管理」を参照してください。

デプロイメント構成は、アプリケーションのライフサイクルにおける様々な時点で、様々な人間によって行われるため、管理者、デプロイヤ、および開発者は互いに協力して、繰返し実行できる構成ワークフローを組織のために作成する必要があります。「一般的なデプロイメント構成のワークフロー」を参照してください。

アプリケーションのデプロイメント記述子の理解

アプリケーションの基本的なデプロイメント構成は、デプロイメント記述子として知られる複数のXMLドキュメントで定義されます。これらは、デプロイメント用に提供されるアプリケーション・アーカイブ・ファイルの一部として用意されています。デプロイメント記述子ファイルは、別個の2つのカテゴリに分類されます。

- Java EEデプロイメント記述子。アプリケーションのデプロイ先に関係なく、Java EEアプリケーションまたはモジュールの基本的構成および動作を定義します。各Java EEアプリケーションおよびモジュールには、Java EE仕様で定義されている特定のJava EEデプロイメント記述子が必要です。

- WebLogic Serverデプロイメント記述子は、特定のWebLogic Server環境でアプリケーションが使用するリソースの依存関係およびチューニング・パラメータを定義します。

本番デプロイメントを行うためには、Java EEとWebLogic Serverの双方のデプロイメント記述子を、開発チームが所有するアプリケーションのソース・コードの一部として扱う必要があります。本番環境にデプロイするアプリケーションの構成を行うために、アプリケーション・デプロイメント記述子を編集することはしないでください。かわりに、構成の変更をWebLogic Serverデプロイメント・プラン(次の項で説明)内に永続化します。

注意:
DTDベースのデプロイメント記述子を使用するアプリケーションでデプロイメント・プランを使用することはできません。このアプリケーションは、スキーマ・ベースの記述子を使用するようアップグレードする必要があります。

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

WebLogic Serverデプロイメント・プランは、前述したように特定のWebLogic Server環境へのデプロイメント用にアプリケーションを構成するために使用する任意のXMLドキュメントです。デプロイメント・プランでは、通常はアプリケーションのWebLogic Serverデプロイメント記述子で定義するようなデプロイメント・プロパティ値の設定を指定したり、WebLogic Serverデプロイメント記述子ですでに定義されているプロパティ値をオーバーライドしたりします。アプリケーションをエクスポートするときに、デプロイメント・プランは通常、開発中に作成したWebLogic Serverデプロイメント記述子内の選択されたプロパティをオーバーライドするよう機能します。

注意:
Java EEまたはWebLogic専用デプロイメント記述子を構成またはオーバーライドできますが、一時ラベル付きのアイテムは除きます。
JSR 88 DConfigBeansのセッター・メソッド(記述子要素の値の変更用)および削除メソッド(記述子要素の削除用)を使用し、デプロイメント・プランを更新できます。また、標準記述子およびWebLogic専用記述子用のgetDescriptorBean()によって返される記述子のBeanツリーから、セッター・メソッドと削除メソッドを呼び出すことも可能です。これらのメソッドによって、プランはオーバーライドされます。『WebLogic Deployment APIによるアプリケーションのデプロイ』のデプロイメントのためのアプリケーションの構成に関する項を参照してください。

通常は、開発者が関連アプリケーション・ファイルとともにデプロイメント・プランを作成し、管理者やデプロイヤに配布します。配布を受けた管理者やデプロイヤは、特定の環境(ステージング、テスト、本番など)にあわせてプランを更新します。デプロイメント・プランは、アプリケーション・アーカイブや展開されたアーカイブ・ディレクトリの外部に格納します。ベスト・プラクティスとしては、単一のアプリケーションの各デプロイメント・プランを、アプリケーションのルート・ディレクトリにおける、それぞれの専用planサブディレクトリに格納することをお薦めします(「アプリケーションのインストール・ディレクトリの作成」を参照)。

デプロイメント・プランを使用すると、管理者はアプリケーション・アーカイブに含まれているデプロイメント記述子ファイルを変更することなく、アプリケーションを複数の様々なWebLogic Server環境にデプロイするためのWebLogic Server構成を簡単に変更できます。構成の変更は、変更するWebLogic Server記述子プロパティの場所と、それらのプロパティに割り当てる値の双方を定義する、デプロイメント・プラン内の変数を追加または変更することによって適用されます。アプリケーションをデプロイしている管理者は、デプロイメント・プランを変更するのみで済みます。元のデプロイメント・ファイルとデプロイメント記述子は、変更されないままです(図4-1を参照)。それぞれの環境のデプロイメント構成ワークフローを決定するには、「一般的なデプロイメント構成のワークフロー」を参照してください。

図4-1 WebLogic Serverデプロイメント・プラン

本番デプロイメント構成の目標

管理者にとって、アプリケーションを本番デプロイメント用に構成する際の第一の目標は、ターゲットWebLogic Server環境に適した有効な新しいデプロイメント・プランを生成することです。具体的には、デプロイメント・プランはすべての外部リソース参照を解決し、アプリケーションがターゲット環境において使用可能である有効なリソースを参照するようにする必要があります。アプリケーションの構成でターゲット・サーバーについて有効な外部リソースが定義されていなければ、アプリケーションはデプロイできません。

デプロイメント・プランでは、必要に応じてWebLogic Serverチューニング・パラメータを定義またはオーバーライドして、ターゲット環境におけるリソースの理想的な使用方法を実現できます。チューニング・パラメータの定義は、アプリケーションのデプロイを正常に実行するために必須というわけではありません。アプリケーションのデプロイメント記述子とデプロイメント・プランで、チューニング・パラメータが定義されていなければ、WebLogic Serverはデフォルト値を使用します。

一般的なデプロイメント構成のワークフロー

デプロイメント・プランを使用すると、複数のWebLogic Server環境にデプロイするためのアプリケーションの構成の、便利で繰返し可能なワークフローを定義できます。本番アプリケーションのための構成ワークフローには、デプロイ可能なアプリケーションを作成およびパッケージ化する開発および設計チームと、各ターゲットWebLogic Server環境の管理者またはデプロイヤとの間で協力が必要です。

組織のための理想的なデプロイメント構成ワークフローは、次の要素によって決まります。

- 同じアプリケーションをデプロイするそれぞれの環境の数

- 各ターゲット環境によって提供されるリソースの違い

- 各ターゲット環境の変更頻度

- アプリケーションのJava EE構成の変更頻度

- 組織内の様々な分野における構成情報に対する所有権の要件

次の項では、デプロイメント・プランの管理、および複数のWebLogic Serverドメインへのアプリケーションのデプロイのための一般的なデプロイメント構成ワークフローについて説明します。

単一のデプロイメント・プランを使用するアプリケーション

様々なデプロイメント環境の正確な構成を理解している組織では、単一の精密に定義されたデプロイメント・プランを使用して、アプリケーションを複数のWebLogic Serverドメインにデプロイできます。単一デプロイメント・プランの構成ワークフローは、次のように機能します。

1. 開発チームは、管理者およびデプロイヤと協力して、すべてのターゲット環境で使用するためのマスター・デプロイメント・プランを作成します。ターゲット環境の数は、組織の構成によって異なります。共通のデプロイメント環境には、1つまたは複数の品質保証(QA)またはテスト・ドメイン、ステージング・ドメイン、および本番ドメインが含まれます。
このフェーズでチームが作成するデプロイメント・プランは、ターゲット環境ごとに異なると分かっているすべての構成プロパティの変数を定義します。たとえばこのプランで、環境間で異なっており、アプリケーションがデプロイ可能になる前に構成が必要なリソース名のための空の変数を定義する場合があります。またこのプランでは、デプロイヤが環境において変更するかもしれない共通のチューニング・パラメータのデフォルト値を定義することもあります。

開発中におけるデプロイメント・プランの作成の詳細は、「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。

2. あるバージョンのアプリケーションのリリース準備が整うと、開発チームはそのアプリケーションのデプロイメント・ファイルをパッケージ化し、デプロイメント・ファイルとマスター・デプロイメント・ファイルの双方を、各ターゲット環境のデプロイヤに配信します。

3. 各デプロイヤは、WebLogic Server管理コンソールを使用してアプリケーションをインストールし、構成に使用するデプロイメント・プランを識別します。WebLogic Server管理コンソールは、対象ドメインで使用可能なリソースに基づき、デプロイメント構成全体を検証します。その後、プランで定義されている構成可能なプロパティ(および、すべての無効なプロパティ)のリストを、編集のためにデプロイヤに提示します。

図4-2 単一デプロイメント・プランのワークフロー

4. デプロイヤは、WebLogic Server管理コンソールを使用して、デプロイメント・プランで定義されたプロパティを対話形式で構成します。null値、またはターゲットWebLogic Serverインスタンスまたはクラスタについて無効な値を持つデプロイメント・プラン変数を構成しないと、アプリケーションがデプロイ可能になりません。すでに有効な値を持つデプロイメント・プラン変数は、デプロイメント前に変更する必要はありません。
各環境のデプロイヤは、構成変更をデプロイメント・プランで定義されたプロパティのみに制限することに同意しています。追加の構成変更が必要な場合、デプロイヤはマスター・デプロイメント・プランを変更する開発または設計チームに、それらの必要性を伝えなくてはなりません。

単一デプロイメント・プランのワークフローの利点

単一デプロイメント・プランのワークフローを使用する利点は、次のとおりです。

- 開発または設計チームが、アプリケーションのデプロイメント構成を制御できます。

- アプリケーションをターゲット環境にデプロイする際に、デプロイヤが行わなければならない構成上の判断の数が減少します。

- アプリケーションと関連付けられた構成ファイルの数が最小限に留められ、デプロイメント構成情報のソース・コントロール・システムへの格納が容易になります。

全般に、単一デプロイメント・プランのワークフローを使用するのは、組織におけるターゲット環境が少数かつ詳しく理解されており、各環境で標準化されたデプロイメント構成を簡単にレプリケートする必要がある場合です。

単一デプロイメント・プランの所有権および制限事項

単一のデプロイメント・プランのワークフローでは、開発または設計チームが、デプロイメント・プランの所有権を保持しており、デプロイヤがプランに対して行える変更は、プラン内で定義される変数に限定されていることを前提としています。デプロイヤが、デプロイメント・プランで定義されているプロパティのみを変更する場合、それらの変更は変数の更新として、同じデプロイメント・プランに書き戻されます。

しかし、WebLogic Serverでは、デプロイヤがWebLogic Server管理コンソールを使用して変更できる構成プロパティに関しては、制限を設けていません。デプロイヤが、元来はプラン内で定義されていなかったデプロイメント・プロパティを構成する場合、管理コンソールは変数エントリが追加された新しいデプロイメント・プランを生成し、その新しいプランを、デプロイメントまたは再デプロイメント操作に使用します。これによりデプロイヤが、開発チーム所有のマスター・デプロイメント・プランとは大幅に異なるデプロイメント・プランを使用するという状況が生じる可能性があります。

マスター・デプロイメント・プランに新しく変更を組み込むには、デプロイヤは管理コンソールによって作成されカスタマイズされた、新しいデプロイメント・プランを取得します。理想的には、これらの変更は、マスター・デプロイメント・プランに適用されます。

複数のデプロイメント・プランを使用するアプリケーション

頻繁に変更される数多くのデプロイメント環境を有する組織では、複数のデプロイメント・プランを備える構成ワークフローを使用する必要があります。複数デプロイメント・プランのワークフローでは、各デプロイメント・プランは開発チームではなく、アプリケーションのデプロイヤが所有しています。複数デプロイメント・プランの構成ワークフローは、次のように機能します。

1. 開発チームは、あるバージョンのパッケージ化されたアプリケーション・デプロイメント・ファイル(Java EEおよびWebLogic Server記述子を含む)をリリースします。リソース定義のためのエクスポートされた変数、または共通のチューニング可能なパラメータを備えるテンプレート・デプロイメント・プランは、これに含めても含めなくてもかまいません。

2. アプリケーションをデプロイする前に、各デプロイヤは、ターゲット環境用にアプリケーションを構成するためのカスタム・デプロイメント・プランを生成します。
カスタム・デプロイメント・プランの作成は、テンプレートのデプロイメント・プラン(またはデプロイメント・プランなしで)により開始し、WebLogic Server管理コンソールを使用してアプリケーションのデプロイメント構成に変更を加えることが可能です。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデプロイメント・プランの更新に関する項を参照してください。

3. 環境にあわせてデプロイメント構成を定義後、各デプロイヤはカスタム・デプロイメント・プランを取得して、それをアプリケーションの将来的なデプロイメントに備えて維持します。カスタム構成プランは、必要に応じて新しいバージョンを追跡したり元に戻したりできるように、ソース・コントロール・システムに格納することをお薦めします。

図4-3 複数デプロイメント・プランのワークフロー

4. その後のリリースでは、各デプロイヤはカスタマイズされたデプロイメント・プランを使用して、アプリケーションをデプロイメントのために構成します。カスタマイズされたプランを使用すると、デプロイヤはweblogic.Deployerでデプロイメントを実行したり、WLSTでデプロイメントを自動化したりできます。

複数デプロイメント・プランのワークフローの利点

複数デプロイメント・プランのワークフローを使用する利点は、次のとおりです。

- 管理者またはデプロイヤが、アプリケーションの構成と環境の構成を両方とも一緒に管理できるようになります。

- デプロイヤが、アプリケーションをグローバルに構成するカスタム・プランを使用して、デプロイメント・プロセスを自動化できます。

全般に、複数デプロイメント・プランのワークフローを使用するのは、組織におけるデプロイメント環境の数が多く、頻繁に変更されるために単一のマスター・デプロイメント・プランを維持することが困難または不可能である場合です。

複数デプロイメント・プランの所有権および制限事項

複数デプロイメント・プランのワークフローでは、(プログラミングあるいは設計チームではなく)デプロイヤまたは管理者が、アプリケーション用にデプロイメント構成を所有し管理するものと想定します。また、アプリケーションの基本的なJava EEの構成はほとんど変更しないことを想定しますが、それは特定のJava EEの構成変更が、デプロイヤのカスタム構成プランを無効にするためです。たとえば、エンタープライズ・アプリケーション内のモジュールが追加、削除、または変更された場合、そのモジュールを参照するカスタム・デプロイメント・プランは無効になります。この場合、各デプロイヤはWebLogic Server管理コンソールを使用してアプリケーションを構成することで、カスタム・プランを再作成する必要があります。

アプリケーションを構成するための新しいデプロイメント・プランの作成

WebLogic Server管理コンソールは、ドメインにインストールしたアプリケーションのデプロイメント・プロパティを対話形式で変更すると、アプリケーションの有効なXMLデプロイメント・プランを自動的に生成(または更新)します。生成されたデプロイメント・プランを後のデプロイメントにおけるアプリケーションの構成に使用することもできますし、デプロイメント・プロパティを繰返し編集および保存することで新しいバージョンのデプロイメント・プランを生成することもできます。

注意:

- weblogic.PlanGeneratorを使用して、Java EEデプロイメント記述子のみを使用した基本的なWebLogic Serverデプロイメント・プランを生成することもできます。「weblogic.PlanGeneratorコマンド行リファレンス」を参照してください。

WebLogic Server管理コンソールを使用してのデプロイメント・プランの生成は、次の手順を伴います。

1. デプロイメント・ファイルを準備する

2. アプリケーション・アーカイブをインストールする

3. デプロイメント・プランに構成の変更を保存する

デプロイメント・ファイルを準備する

次の手順に従って、デプロイメント用のアプリケーションを準備します。

1. アプリケーションをデプロイするための新しいルート・ディレクトリと、appおよびplanサブディレクトリを作成します。例:

mkdir c:\sample_root
mkdir c:\sample_root\app
mkdir c:\sample_root\plan

2. 手順1で作成したc:\sample_root\appディレクトリにアプリケーションを保存します。

アプリケーション・アーカイブをインストールする

WebLogic Server管理コンソールでは、アプリケーション・インストール・アシスタントを使用して、新しいWebLogic Server環境に構成およびデプロイする新しいアプリケーションを簡単にインストールできます。アプリケーションまたはモジュールをインストールしてデプロイメント・ターゲットを選択すると、WebLogic Serverドメインでデプロイメント・ファイルが使用可能になり、必要に応じて構成、配布、およびデプロイできます。

アプリケーションをWebLogic Serverドメインにインストールするには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーションおよびモジュールのインストールに関する項の手順に従います。

デプロイメント・プランに構成の変更を保存する

WebLogic Server管理コンソールを使用して、「アプリケーション・アーカイブをインストールする」でインストールしたアプリケーションのデプロイメント構成プロパティを編集し、構成をデプロイメント・プランに保存します。

1. 「構成」ページで、必要に応じてアプリケーションの構成プロパティを1つ以上編集します。たとえば、セッション無効化間隔を80秒に、「セッション・タイムアウト」を8000秒に変更します。

2. 「保存」をクリックして変更を保存します。WebLogic Server管理コンソールは、構成の変更を新しいデプロイメント・プランに格納します。ルート・ディレクトリからアプリケーションをデプロイした場合、WebLogic Server管理コンソールは新しいデプロイメント・プランを自動的にルート・ディレクトリの\planサブディレクトリに入れます。たとえば、c:\sample_root\plan\Plan.xmlとなります。

デプロイメント・プランの内容の理解

例4-1に、「アプリケーションを構成するための新しいデプロイメント・プランの作成」の手順で生成したサンプル・デプロイメント・プランを示します。

例4-1 サンプル・デプロイメント・プラン

<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan">
<application-name>sample_root</application-name>
<variable-definition>
<variable>
<name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name>
<value>80</value>
</variable>
<variable>
<name>SessionDescriptor_TimeoutSecs_11029744772011</name>
<value>8000</value>
</variable>
</variable-definition>
<module-override>
<module-name>myApp.ear</module-name>
<module-type>ear</module-type>
<module-descriptor external="false">
<root-element>weblogic-application</root-element>
<uri>META-INF/weblogic-application.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>application</root-element>
<uri>META-INF/application.xml</uri>
</module-descriptor>
</module-override>
<module-override>
<module-name>myWebApp.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name>
<xpath>/weblogic-web-app/session-descriptor/invalidation-interval-secs</xpath>
</variable-assignment>
<variable-assignment>
<name>SessionDescriptor_TimeoutSecs_11029744772011</name>
<xpath>/weblogic-web-app/session-descriptor/timeout-secs</xpath>
</variable-assignment>
</module-descriptor>
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
</module-descriptor>
</module-override>
<module-override>
<module-name>sample_root</module-name>
<module-type>ear</module-type>
<module-descriptor external="false">
<root-element>weblogic-application</root-element>
<uri>META-INF/weblogic-application.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>application</root-element>
<uri>META-INF/application.xml</uri>
</module-descriptor>
</module-override>
<config-root>C:\sample_root\plan</config-root>
</deployment-plan>

デプロイメント・プラン内の基本要素は、以下の関数に対する処理を行います。

- deployment-plan。デプロイメント・プランのすべての内容をカプセル化します。

- application-name。アプリケーションまたはモジュールのデプロイメント名に対応します。

- variable-definition。1つまたは複数のvariable要素を定義します。各variableは、プラン内で使用される変数のname、および割り当てるvalue (nullでも可)を定義します。「サンプル・デプロイメント・プラン」に示すサンプル・プランには、「セッション無効化間隔」および「セッション・タイムアウト」プロパティに加えた変更に対する変数定義が含まれます。

- module-override要素。デプロイメント・プランがオーバーライドする、各モジュールの名前、種類、およびデプロイメント記述子を定義します。module-descriptor要素には、必要に応じて、記述子内のプロパティのオーバーライドに使用される変数名を識別するvariable-assignment、およびプロパティがオーバーライドされる記述子内の正確な場所を含めることができます。
「サンプル・デプロイメント・プラン」に示すサンプル・プランには、エンタープライズ・アプリケーションのモジュール・オーバーライド要素、組込みWebアプリケーション、およびそれらを格納するルート・ディレクトリが含まれます。weblogic.xml記述子ファイルのmodule-descriptorエントリは、2つのvariable-assignment要素を含み、「デプロイメント・プランに構成の変更を保存する」の例で変更したセッション無効化間隔および「セッション・タイムアウト」プロパティのプロパティ値をオーバーライドします。

デフォルトでは、variable-assignment要素の値は記述子内で定義済みの値に追加されます。variable-assignment要素内のoperation下位要素を、それぞれreplaceまたはremoveの各値に設定することにより、variable-assignment要素が記述子内で定義された値に取って代わるように、またはこれらの値を削除するように、この動作を変更することができます。

たとえば、ある開発者が、ejb-jar.xmlでejbRoleという名前のセキュリティ・ロールのみにアクセスを許可するポリシーを作成したとします。

...
<assembly-descriptor>
<security-role>
<role-name>ejbRole</role-name>
</security-role>
<method-permission>
<role-name>ejbRole</role-name>
<method>
<ejb-name>ejb.SearchHandlerWrapperEJB</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
</assembly-descriptor>
...

weblogic-ejb-jar.xmlのsecurity-role-assignment要素では、ejbRoleがuser1という名前のプリンシパルにマップされています。

...
<security-role-assignment>
<role-name>ejbRole</role-name>
<principal-name>user1</principal-name>
</security-role-assignment>
...

ここで、デプロイメント・プランを使用してweblogic-ejb-jar.xmlで定義されているsecurity-role-assignment要素をオーバーライドし、ejbRoleをuser1ではなくuser2にマップしたいとします。このオーバーライドは、デプロイメント・プラン内のvariable、variable-assignment、およびoperation要素に適切な値を設定することで実現できます。operationの値は、必ずreplaceに設定します。

...
<variable> <name>SecurityRoleAssignment_ejbRole_PrincipalNames_11168815313911</name>
<value>user2</value>
</variable>

<variable-assignment>
<name>SecurityRoleAssignment_ejbRole_PrincipalNames_11168815313911</name>
<xpath>/weblogic-ejb-jar/security-role-assignment/[role-name="ejbRole"]/principal-name</xpath>
<operation>replace</operation>
</variable-assignment>

WebLogic Serverデプロイメント・プランの内容の詳細は、http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsdを参照してください。

既存のデプロイメント・プランを使用したアプリケーションの構成

デプロイメント用に受け取るアプリケーションは、構成情報の可変レベルを備えている可能性があります。アプリケーションに現行の構成プランがある場合、「デプロイメント・ファイルの準備」で説明しているように単にアプリケーションを準備し、アプリケーション・ルートのplanサブディレクトリにデプロイメント・プランを配置します。次に、「アプリケーション・アーカイブをインストール」の命令を使用し、アプリケーションをインストールします。WebLogic Server管理コンソールは1つのプランが有効であれば、アプリケーション・ルート・ディレクトリの\planサブディレクトリで、自動的にplan.xmlという名前のデプロイメント・プランを使用します。アプリケーションで複数のプランが有効であれば、それらは\planサブディレクトリ(たとえば\plan1および\plan2)に配置され、WebLogic Server管理コンソールはそれらを認識できません。したがってconfig.xmlは使用するプランを指定する必要があります。config.xmlの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン構成ファイルに関する項を参照してください。

新しいアプリケーションおよび既存のデプロイメント・プランをインストール後、WebLogic Server管理コンソールはデプロイメント・プランの構成を、インストールの際に選択されたターゲット・サーバーおよびクラスタと比較して検証します。デプロイメント・プランに、空(null)の変数が格納されている、またはデプロイメント・プランで構成された値の中に、ターゲット・サーバー・インスタンスについて有効でないものがある場合は、デプロイメント・プランをオーバーライドしてからでなければ、アプリケーションをデプロイすることはできません。また、「デプロイメント・プランに構成の変更を保存する」で説明したように、アプリケーションをデプロイするターゲット環境に、よりよく適合させるため、チューニング・パラメータを構成することも可能です。アプリケーションの構成に対して加えた変更は、新しいデプロイメント・プランに保存されます。

アプリケーションの構成がデプロイ先の環境に対して完全に適合している有効なデプロイメント・プランがある場合は、WebLogic Server管理コンソールとweblogic.Deployerユーティリティのどちらかを使用して、デプロイメントに使用するデプロイメント・プランでアプリケーションをデプロイできます。

注意:
weblogic.Deployerユーティリティで使用するデプロイメント・プランはいずれも完全なものであり、ターゲット・サーバーについて有効であることが必要です。weblogic.PlanGeneratorでは、プランの作成時に個々のデプロイメント・プロパティを設定またはオーバーライドすることはできません。weblogic.Deployerを使用して、新しいアプリケーションおよび既存のデプロイメント・プランをデプロイするには、「デプロイメント・プランによるアプリケーションのデプロイ」を参照してください。

デプロイメント・プランを使用して、application.xmlデプロイメント記述子で定義されたcontext-root要素をオーバーライドできます。次の例では、plan.xmlファイルを使用して、アプリケーションのcontext-rootを変更する方法を示します(関連セクションを太字で表示)。

例4-2 デプロイメント・プランを使用したアプリケーションのcontext-rootの変更

<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan">
<application-name>test</application-name>
<variable-definition>
<variable>
<name>myNewRoot</name>
<value>DEF</value>
</variable>
</variable-definition>
<module-override>
<module-name>test</module-name>
<module-type>ear</module-type>
<module-descriptor external="false">
<root-element>application</root-element>
<uri>META-INF/application.xml</uri>
<variable-assignment>
<name>myNewRoot</name>
<xpath>/application/module/web/[context-root="ABC"]/</xpath>
<operation>replace</operation>
</variable-assignment>
</module-descriptor>
</module-override>
<config-root>D:\Cases\WLS\PlanXML\test</config-root>
</deployment-plan>

例4-2では、次のようになります。

- application.xmlファイルで定義されたcontext-rootは、ABCです。

- デプロイメント・プランを使用すると、context-rootがABCからDEFに正常に変更されます。

- アプリケーションへのアクセスに使用されるURLは、http://localhost:7001/ABC/index.htmlからhttp://localhost:7001/DEF/index.htmlに変更されます。

汎用ファイル・ロード・オーバーライド

この機能により、アプリケーション固有のファイルを配置し、既存のプラン・ディレクトリ構造で、オプションのサブディレクトリ(名前は/AppFileOverrides)の中にオーバーライドできます。この新しいオプションのサブディレクトリの有無により、ファイルのオーバーライドがデプロイメントのために可能かどうかを制御します。このサブディレクトリが存在する場合、デプロイメントのために内部のClassFinderはアプリケーションおよびモジュールのクラスローダーの前面に追加されます。結果として、ファイル・オーバーライドの階層規約は、既存のクラスローダーおよびアプリケーションのリソース・ロード規約および動作に従います。WebLogic Serverアプリケーション・クラスロードの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーションのクラスロードに関する項を参照してください。

注意:
このメカニズムは、リソースのオーバーライドのみであり、クラスについてはオーバーライドしません。

アプリケーション固有のファイルがあり、内容がWebLogic Serverには不透明なため、オーバーライド・ファイルが提供されるとき、ファイル全体の内容がオーバーライドされます。

オーバーライドの仕組み

/AppFileOverridesサブディレクトリに配置されるファイルは、残りのプラン・ディレクトリの内容とともにステージングされて配布され、すべてのターゲットに対して有効となります。その後、現行のクラスローダーを使用して、アプリケーションはこれらのファイルをリソースとしてロードすることができます(たとえば、ClassLoader.getResourceAsStreamメソッドを使用。)これは、構成とオーバーライドしたファイルの提供状況によって、アプリケーションでオーバーライドしたファイルまたはパッケージ化したファイルを見つけます。

Webアプリケーションの場合、アプリケーション・ファイル・オーバーライドは、クラスパスに関連付けられた(WEB-INF/classesおよびWEB-INF/libに存在する)リソースにのみ適用され、Webアプリケーションのリソース・パスに対しては適用されません。したがって、オーバーライドは、Webアプリケーションがclassloader.getResourceAsStream()メソッドを使用してリソースをルックアップする場合には適用されますが、ServletContext.getResourceAsStream()メソッドを呼び出す場合には適用されません。

この機能を使用するには、以下を行う必要があります。

- デプロイメント・プランを指定する(「アプリケーションを構成するための新しいデプロイメント・プランの作成」を参照)。

- プラン内にconfig-rootを指定します。

- config-root/AppFileOverridesサブディレクトリを指定します。

ディレクトリ構造

/AppFileOverridesサブディレクトリの内容には、既存のプラン・ディレクトリ構造と、記述子のオーバーライド用にすでに存在するディレクトリ命名規則が適用されます。ディレクトリ命名規則については、「デプロイするファイルのパッケージ化」を参照してください。

アプリケーション・ファイル・オーバーライドを可能にすれば、ディレクトリのClassFinderがアプリケーションおよびモジュール・レベルのクラス・ローダーに追加されることになります。これは/AppFileOverridesサブディレクトリ(プラン・ディレクトリにあります)内の適切なルート・ディレクトリを指します。アプリケーションのクラス・ローダーの前面に挿入されるClassFinderには、AppDeploymentMBean.getLocalPlanDir + separator + "/AppFileOverrides"の構造が与えられます。モジュールのクラスロード前面に挿入されるClassFinderには、AppDeploymentMBean.getLocalPlanDir + separator + "/AppFileOverrides" + separator + moduleURIの構造が与えられます。

例:

表4-1 汎用ファイル・オーバーライドのディレクトリ構造

ディレクトリ

説明

install-root/plan/AppFileOverrides

メイン・アプリケーション・クラスローダーのクラスパスの前に挿入されるディレクトリ

install-root/plan/AppFileOverrides/WebApp1.war/...

WebApp1.warクラスローダーのクラスパスの前に挿入されるディレクトリ

install-root/plan/AppFileOverrides/WebApp2.war/...

WebApp2.warクラスローダーのクラスパスの前に挿入されるディレクトリ

アプリケーションの使用方法

重要なことは、アプリケーションは、ファイルの内容および形式を制御し、アプリケーション・コードによってファイルの内容へのアクセスを制御するということです。ベスト・プラクティスは、汎用ファイル・ロード・オーバーライドを、環境固有のプロパティ・ファイルを指定したアプリケーション・コードで使用し、それらのプロパティ・ファイルをアプリケーションのクラスローダーを使用してリソースとしてロードすることです。以下に、アプリケーション・コードによって実行可能な例を示します。

Properties myAppProps = new Properties();
InputStream iostream =
Thread.currentThread().getContextClassLoader().getResourceAsStream("myCfg/myApp.properties");
myAppProps.load(iostream);

追加の構成タスク

その他のデプロイメント構成タスクについては、次の項を参照してください。

- 「デプロイメント・プランによるアプリケーションのデプロイ」。weblogic.Deployerツールを使用して、有効なデプロイメント・プランとともにアプリケーションをデプロイする方法について説明します。付録A「weblogic.Deployerコマンド行リファレンス」を参照してください。

- 「アプリケーションのデプロイメント構成の更新」。現在デプロイされているアプリケーションのデプロイメント構成を更新する方法について説明します。

- 「新しい環境にデプロイするためのアプリケーションのエクスポート」。開発者が、weblogic.PlanGeneratorツールを使用してポータブル・デプロイメント・プランを作成できる方法について説明します。

- 「weblogic.PlanGeneratorコマンド行リファレンス」。weblogic.PlanGeneratorツールに関する詳細なリファレンスを提供します。

アプリケーション構成管理のベスト・プラクティス

- 複数バージョンのWebLogic Serverデプロイメント記述子ファイルではなく、常にデプロイメント・プランを使用して、複数のデプロイメント構成を管理します。

- アプリケーションの既存のデプロイメント・プランは各々、常にアプリケーション・ルート・ディレクトリの専用planサブディレクトリに格納します。

- 組織において、いくつかの環境に対し、標準化された繰返し行えるデプロイメントが必要とされている場合は、「単一のデプロイメント・プランを使用するアプリケーション」のワークフローを使用して、ソース・コントロール・システム内で単一のデプロイメント・プランを維持します。

- WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメント構成に大幅な変更を行う場合は、今後の使用に備えて、更新されたデプロイメント・プランのバックアップを作成するか、安全に格納します。複数環境の構成情報、およびアプリケーションの複数バージョンを維持できるよう、ソース・コントロール・システム内にアプリケーション・ルート・ディレクトリ全体を格納することをお薦めします。

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

この章では、WebLogic Server 12.1.3でアプリケーションのデプロイメント構成をカスタム・デプロイメント・プランにエクスポートする方法について説明します。これを読むと管理者は、非開発用環境へも簡単にアプリケーションをデプロイできます。

この章には次の項が含まれます:

- エクスポート・プロセスの概要

- デプロイメント・プロパティの分類の理解

- アプリケーションのデプロイメント構成をエクスポートする手順

- エクスポートのためのアプリケーション・ファイルのステージング

- weblogic.PlanGeneratorを使用したテンプレート・デプロイメント・プランの生成

- 管理コンソールを使用したデプロイメント・プランのカスタマイズ

- デプロイメント・プランの手動によるカスタマイズ

- エクスポートされたデプロイメント構成の検証

- デプロイメント構成のエクスポートのベスト・プラクティス

エクスポート・プロセスの概要

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

管理者は、アプリケーションおよびカスタム・デプロイメント・プランの双方を、WebLogic Server管理コンソールを使用してインストールできます。WebLogic Server管理コンソールでは、デプロイメント・プランを検証し、特定のデプロイメントに必要な構成プロパティを更新できます。

デプロイメント・プランの詳細は、「デプロイメント・プランの内容の理解」を参照してください。

デプロイメント構成のエクスポートの目標

デプロイメント構成をエクスポートするにあたっての主な目標は、次のとおりです。

- アプリケーションの外部リソースの要件を、デプロイメント・プラン内において、null変数として公開すること。アプリケーションが要求するいかなる外部リソースも、アプリケーションが別の環境にデプロイされた場合には、変更の対象となります。たとえば、開発環境で使用されるデータ・ソースのJNDI名は、テストや本番で使用されるものとは異なっている可能性があります。これらのJNDI名を変数として公開することにより、デプロイヤはアプリケーションをデプロイする際に、簡単に利用可能なリソースを使用したり、必要なリソースを作成したりできます。空(null)の変数を使用することで、アプリケーションがデプロイ可能になる前に、デプロイヤは有効なリソース名の指定を強制されることになります。

- チューニング・パラメータなど、さらなる構成可能なプロパティを、デプロイメント・プラン内の変数として公開すること。開発環境において受け入れ可能なある特定のチューニング・パラメータが、本番環境では受け入れられない場合があります。たとえば、開発マシン上ではEJBキャッシングのためのデフォルト値または最小値を受け入れば十分であっても、本番クラスタで許容できるパフォーマンスを維持するためには、よりレベルの高いキャッシングを行う必要があるかもしれません。選択されたチューニング可能な値をデプロイメント・プラン変数としてエクスポートすると、管理者はアプリケーションをデプロイする際に、重要なチューニング・パラメータに注力しやすくなります。WebLogic Server管理コンソールでは、デプロイメント・プラン内で変数としてエクスポーズされているチューニング・パラメータを強調表示しますが、それらをデプロイメント前に変更するようデプロイヤに要求することはありません。

デプロイメント構成をエクスポートするためのツール

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

- weblogic.PlanGenerator。WebLogic Serverデプロイメント記述子の選択されたカテゴリについて、null変数を備えるテンプレート・デプロイメント・プランを作成します。エクスポート・プロセスを開始しているところであり、デプロイメント記述子のクラス全体に対してnull変数を備えるテンプレート・デプロイメント・プランを作成する必要がある場合は、このツールの使用をお薦めします(「デプロイメント・プロパティの分類の理解」を参照)。通常は、余分な変数定義を削除したり、個々のプロパティのための変数を追加したりするために、手動またはWebLogic Server管理コンソールでweblogic.PlanGeneratorが作成したデプロイメント・プランを手動で変更する必要があります。

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

デプロイメント・プロパティの分類の理解

(すべてのJava EEモジュール記述子、ならびにJDBC、JMS、およびWLDFアプリケーション・モジュールのための)各WebLogic Serverデプロイメント記述子プロパティは、次の4つのカテゴリのうちの1つに分類できます。

- 構成不可プロパティは、デプロイメント構成セッション中に管理者が変更することはできません。構成不可プロパティは、アプリケーションの基本的操作にとって基礎的なアプリケーション動作を記述するために使用されます。たとえば、ejb-nameプロパティの値を変更すると、EJBアプリケーション・コードの変更も必要になるので、このプロパティは構成不可に分類されます。

- 依存関係プロパティ。Java EEデプロイメント記述子で定義されたリソースの依存関係を解決します。たとえば、EJBのJava EE記述子が、EJBコードで使用されるデータ・ソース名を定義している場合、WebLogic Server記述子は依存関係プロパティを使用して、ターゲットWebLogic Serverドメインで構成されている実際のデータ・ソースに、データ・ソース名をバインドします。

- 宣言プロパティは、他のアプリケーションで使用できるリソースを宣言します。たとえば、EJBのJNDI名は、他のアプリケーションまたはモジュールがEJBへのアクセスに使用するEJB名を宣言します。

- 構成可能プロパティは、依存関係プロパティまたは宣言プロパティに分類されない、その他のプロパティです。一般に、構成可能プロパティは、デプロイされたアプリケーションに対するWebLogic Server固有の機能やチューニング・パラメータを有効化または構成します。たとえば、EJBのWebLogic Server記述子は、WebLogic ServerがメモリーにキャッシュするEJBの数を定義することがあります。

これらのカテゴリは、デプロイメント・プランにおいて変数として公開するプロパティを選択するために、構成公開・プロセス中に使用します。たとえば、アプリケーションのWebLogic Serverデプロイメント記述子内で「dependencies」としてタグ付けされたすべてのプロパティの変数定義を含む、新しいデプロイメント・プランを生成できます。変数はその後、別のリソース名を持つ環境へアプリケーションをデプロイしている管理者によって簡単に変更できます。

変更可能な記述子プロパティ(依存関係、宣言、および構成可能プロパティ)はすべて、動的プロパティまたは非動的プロパティとしてさらに分類されます。動的プロパティはデプロイされたアプリケーション内で変更でき、その変更を有効化するのに再デプロイは必要ありません。非動的プロパティは変更できますが、変更を有効化するのに再デプロイメントが必要です。WebLogic Server管理コンソールは、非動的プロパティを、再デプロイメントが必要であるときにそれを通知するものとして識別します。

アプリケーションのデプロイメント構成をエクスポートする手順

アプリケーションのデプロイメント構成をエクスポートするには通常、以下の手順を実行します。

1. エクスポートのためのアプリケーション・ファイルのステージング

2. weblogic.PlanGeneratorを使用したテンプレート・デプロイメント・プランの生成

3. 管理コンソールを使用したデプロイメント・プランのカスタマイズ

4. デプロイメント・プランの手動によるカスタマイズ

5. エクスポートされたデプロイメント構成の検証

次の項では、各手順について詳しく説明します。

エクスポートのためのアプリケーション・ファイルのステージング

デプロイメント構成をエクスポートする前に、アプリケーション・ファイルをアプリケーション・インストール・ディレクトリに入れておくことをお薦めします。インストール・ディレクトリを使用すると、デプロイメント・プランなどの生成された構成ファイルが、エクスポート中に自動的に\planサブディレクトリへコピーされます。

アプリケーションのインストール・ディレクトリを作成するには:

1. アプリケーションの最上位インストール・ディレクトリを作成します。

mkdir c:\exportapps\myApplication

2. \appおよび\planサブディレクトリを作成します。

mkdir c:\exportapps\myApplication\app
mkdir c:\exportapps\myApplication\plan

3. エクスポートするアプリケーションを完全に\appサブディレクトリへコピーします。アプリケーションはアーカイブ形式でも、展開されたアーカイブ形式でもかまいません。

cp -r c:\dev\myApplication c:\exportapps\myApplication\app

\appディレクトリには、配布された完全なアプリケーションが格納されている必要があります。また、開発環境へのデプロイメントに使用するWebLogic Server記述子ファイルを格納することができます。

アプリケーションをエクスポートする際に、インストール・ディレクトリを使用しないことを選択した場合は、weblogic.PlanGeneratorに対して-planオプションを使用し、生成されたプランの場所とファイル名を指定することをお薦めします。デフォルトでは、weblogic.PlanGeneratorは生成されたファイルをTEMP/weblogic-install/application_name/configディレクトリに格納します。TEMPは現在の環境における一時ディレクトリです。これは、Windowsプラットフォームの場合、生成された構成ファイルがC:\Documents and Settings\username\Local Settings\Temp\weblogic\install\myApplication.ear\configに格納されることを意味します。生成されたファイルを既知の場所に置くには、-planオプションを使用します。

weblogic.PlanGeneratorを使用したテンプレート・デプロイメント・プランの生成

weblogic.PlanGeneratorツールは、デプロイメント記述子のカテゴリ全体に対するnull変数(宣言、構成な可能プロパティなど)を備えたテンプレート・デプロイメント・プランを迅速かつ簡単に生成する方法を提供します。アプリケーションのすべての依存関係についてnull変数を備える新しいデプロイメント・プランを生成するためには、weblogic.PlanGeneratorの使用をお薦めします。これにより、アプリケーションに必要なすべてのグローバル・リソースが、アプリケーションを新しい環境にデプロイする必要がある管理者によって、簡単に構成できるようになります。

インストール・ルート・ディレクトリ内でステージングされるアプリケーションを使用する場合、weblogic.PlanGeneratorを使用するための基本的な構文は、次のとおりです。

java weblogic.PlanGenerator -root install_root category

説明:

install_rootは、アプリケーションおよびプランのルート・ディレクトリの完全修飾名を指定します。

categoryは、変数を作成するWebLogic Serverデプロイメント記述子のカテゴリを指定します。(各カテゴリの説明は、「デプロイメント・プロパティの分類の理解」を参照してください。)テンプレート・デプロイメント・プランを生成するには、デフォルト・オプションである-dependenciesオプションのみを使用する必要があります。これにより、アプリケーションが必要とする外部リソースに対する変数が制限されるためです。

注意:
-dependenciesオプションは、可能性のあるすべての動的に構成可能なデプロイメント・プロパティに対してnull変数を作成します。そのため、アプリケーションには不要であるかもしれない多数の変数定義が作成される場合があります。-declarationsオプションは通常、必須ではありません。宣言プロパティは一般に、アプリケーションの基本機能と関連付けられており、新しい環境へのデプロイメントの前に変更されるべきではないからです。

例:

java weblogic.PlanGenerator -root c:\exportapps\myApplication -dependencies

java weblogic.PlanGenerator -root c:\exportapps\myApplication

-dependenciesがデフォルトのオプションであるためweblogic.PlanGeneratorコマンドで指定する必要がなく、したがって同義である上記のコマンドの場合、weblogic.PlanGeneratorは選択されたアプリケーション内のすべてのJava EEデプロイメント記述子を検査し、アプリケーションに対する外部リソースを構成するすべての関連WebLogic Serverデプロイメント・プロパティについて、null変数を備えるデプロイメント・プランを作成します。WebLogic Server管理コンソールを使用している管理者は、アプリケーションがデプロイできるようになる前に、このテンプレート・デプロイメント・プランを使って各null変数に有効なリソース名とチューニング・プロパティを割り当てるよう指示されます。

管理コンソールを使用したデプロイメント・プランのカスタマイズ

「weblogic.PlanGeneratorを使用したテンプレート・デプロイメント・プランの生成」で生成されたテンプレート・デプロイメント・プランには、アプリケーションの外部の依存関係を解決するデプロイメント・プロパティのみが格納されています。テンプレート・プランを全般的にカスタマイズして、アプリケーションの1つまたは複数のWebLogic Serverチューニング・プロパティを追加します。WebLogic Server管理コンソールを使用すると、必要に応じて、個々のデプロイメント記述子プロパティのデプロイメント・プラン変数を簡単に追加できます。WebLogic Server管理コンソールを使用してデプロイメント・プランをカスタマイズするには、次の手順を実行します。

1. エクスポートされたアプリケーションおよびテンプレート・デプロイメント・プランのインストール

2. 選択されたチューニング・プロパティの変数の追加

3. カスタマイズされたデプロイメント・プランの取得

エクスポートされたアプリケーションおよびテンプレート・デプロイメント・プランのインストール

WebLogic Server管理コンソールを使用してデプロイメント構成を変更するには、まず「アプリケーションのインストール・ディレクトリを作成する手順」の説明に従って、アプリケーションおよび既存のデプロイメント・プランをインストールする必要があります。

選択されたチューニング・プロパティの変数の追加

エクスポート・アプリケーションのインストール後、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデプロイメント・プランの更新に関する項の手順に従い、デプロイメント・プランに新規のチューニング・プロパティを追加します。

カスタマイズされたデプロイメント・プランの取得

WebLogic Server管理コンソールを使用してアプリケーションのデプロイメント構成を変更する場合、デプロイメント・プロパティに対する変更は、WebLogic Serverデプロイメント・プランや、生成されたWebLogic Serverデプロイメント記述子ファイルに格納されます。アプリケーションのデプロイメント・プラン内の変数として定義されているデプロイメント・プロパティを変更した場合、変更は新しいバージョンのプラン・ファイルに書き戻されます。インストール・ディレクトリからインストールされたアプリケーションの場合、デフォルトではWebLogic Server管理コンソールは生成された構成ファイルをplanサブディレクトリに格納します。

デプロイメント・プランの手動によるカスタマイズ

場合によっては、テキスト・エディタを使用して手動でカスタム・デプロイメント・プランを編集する必要があります。これが必要となるのは、以下の理由がある場合です。

- 既存のデプロイメント・プラン変数を削除する必要があります。

- プラン内の生成された変数にnull値を割り当てる必要があります。

注意:
WebLogic Server管理コンソールを使って、変数定義をデプロイメント・プランから削除したり、デプロイメント・プロパティに対してnull値を割り当てたりすることはできません。

デプロイメント・プランのエントリを手動で編集する前に、http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsdおよび「デプロイメント・プランの内容の理解」を参照してください。

デプロイメント・プランからの変数の削除

デプロイメント・プラン内のvariable-definitionスタンザは、WebLogic Serverデプロイメント記述子プロパティのオーバーライドに使用される変数の名前と値を定義します。module-override要素には、所定のデプロイメント記述子に変数がどこで適用されるのかを定義するvariable-assignment要素を1つまたは複数、含めることができます。デプロイメント・プランから変数を削除するには、テキスト・エディタを使用して以下を削除します。

- variable-definitionスタンザのvariable定義

- 削除される変数を参照するすべてのvariable-assignment要素

管理者入力を必要とするnull変数の割当て

既存の変数定義にnull値を割り当てるには、単にvariable要素内のvalue下位要素の中にある任意のテキスト値を、<value xsi:nil="true"></value>に変更します。この場合xsiネームスペースは、xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"と定義されています。次に例を示します。

...
<variable-definition>
<variable>
<name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name>
<value>80</value>
</variable>
</variable-definition>
...

これを次のように変更します。

...
<variable-definition>
<variable>
<name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name>
<value xsi:nil="true"></value>
</variable>
</variable-definition>
...

エクスポートされたデプロイメント構成の検証

WebLogic Server管理コンソールは、新しくインストールされたアプリケーションまたはモジュールのデプロイメント構成を自動的に検証します。エクスポート・プロセス中に作成したカスタム・デプロイメント・プランを検証するには:

1. 「選択されたチューニング・プロパティの変数の追加」に記載の手順に従い、カスタム・デプロイメント・プランの最終バージョンとともにアプリケーションまたはモジュールをインストールします。WebLogic Server管理コンソールは、インストール・ディレクトリのplanサブディレクトリ内にplan.xmlという名前のデプロイメント・プランがあれば、それを自動的に使用します。

2. 「デプロイメントのサマリー」ページで、インストールしたアプリケーションまたはモジュールの名前を選択します。

3. 「デプロイメント・プラン」>「依存関係」タブを選択します。

4. デプロイされたモジュールについて構成された依存関係が、選択されたターゲット・サーバーについて有効であることを確認します。

デプロイメント構成のエクスポートのベスト・プラクティス

アプリケーションのデプロイメント構成をエクスポートする際には、以下のベスト・プラクティスに留意してください。

- アプリケーションをエクスポートするにあたっての主な目標は、アプリケーションの外部リソースの依存関係のすべてについてnull変数を作成することです。これによりデプロイヤは確実に、ターゲット環境で使用可能なリソースに基づいてリソース名を割り当てることができるようになります。

- weblogic.PlanGeneratorは、リソースの依存関係のエクスポートにのみ使用します。一般に、デプロイメント記述子プロパティの他のカテゴリをエクスポートするのにweblogic.PlanGeneratorを使用すると、デプロイメント・プラン内に生じる変数が過多になります。

- デプロイメント・プランに個々のチューニング・プロパティ値を追加する、またはカスタム・デプロイメント・プランを検証するには、WebLogic Server管理コンソールを使用します。

- WebLogic Server管理コンソールでもweblogic.PlanGeneratorでも、プランから変数を削除したり、変数に対してnull値を設定したりすることはできません。これらのタスクを完了させる必要がある場合は、テキスト・エディタを使用します。

6 weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ

この章では、weblogic.Deployerユーティリティを使用して、WebLogic Server 12.1.3の管理者がコマンド行ベースの対話的なデプロイメント・タスクを実行する方法について説明します。

この章には次の項が含まれます:

- 一般的なデプロイメント・シナリオの概要

- リモート・クライアントからのデプロイメント・ファイルのアップロード

- 単一サーバー・ドメインへのデプロイ

- デプロイメント・プランによるアプリケーションのデプロイ

- preStart期間中にJNDIからシステム・リソースをルックアップするアプリケーションのデプロイ

- サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定

- モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ

- JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ

- ステージング・モードによるデプロイメント・ファイルのコピーの制御

- 本番環境へのアプリケーションの配布

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

- アプリケーションのデプロイのベスト・プラクティス

一般的なデプロイメント・シナリオの概要

以下の節では、一般的なデプロイメント・タスクをいくつかの一般的なカテゴリにまとめています。最も基本的なタスクから始まり、より高度なタスクへと進みます。アプリケーションをデプロイする前に、「本番デプロイメントのためのアプリケーションの構成」で説明されている適切なタスクを実行します。

- 「リモート・クライアントからのデプロイメント・ファイルのアップロード」 - アプリケーションまたはモジュールをリモート・クライアントから管理サーバーにアップロードする方法について説明します。

- 「単一サーバー・ドメインへのデプロイ」 - アプリケーションまたはモジュールを単一サーバーWebLogicドメインへデプロイする基本について説明します。

- 「デプロイメント・プランによるアプリケーションのデプロイ」 - アプリケーションを完全に構成するデプロイメント・プランとともにアプリケーションをデプロイする方法について説明します。

- 「preStart期間中にJNDIからシステム・リソースをルックアップするアプリケーションのデプロイ」 - JNDIを介してシステム・リソースをルックアップするアプリケーションをデプロイする方法について説明します。

- 「サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定」 - WebLogic Serverのターゲットのすべての種類と、デプロイメント時にターゲットを指定する方法について説明します。

- 「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」: エンタープライズ・アプリケーション内の個々のモジュールを別々のWebLogic Serverターゲットに割り当てる方法について説明します。

- 「JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ」 - WebLogic Serverドメインで、スタンドアロンおよびアプリケーション・スコープのJDBC、JMS、およびWLDFモジュールをデプロイする方法について説明します。

- 「ステージング・モードによるデプロイメント・ファイルのコピーの制御」 - WebLogic Serverのファイル・コピーの動作を制御するために、デフォルト以外のステージング・モードを使用する方法について説明します。

- 「本番環境へのアプリケーションの配布」 - 新しいアプリケーションを、クライアント・リクエストの処理に対して使用可能な状態にしないで、本番環境に直接デプロイしてテストする方法について説明します。

- 「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」 - Java EEライブラリとオプション・パッケージをWebLogic Server環境にデプロイする方法、これらの共有リソースを参照するアプリケーションやモジュールをデプロイおよび管理する方法について説明します。

- 「アプリケーションのデプロイのベスト・プラクティス」 - 主なデプロイメントのプラクティスをまとめています。

リモート・クライアントからのデプロイメント・ファイルのアップロード

ドメインにアプリケーションまたはモジュールをデプロイするには、デプロイメント・ファイルがドメインの管理サーバーからアクセス可能でなければなりません。デプロイメント・ファイルが管理サーバー・マシン上にない場合、またはネットワークにマウントされたディレクトリを通じて管理サーバー・マシンから使用できない場合は、-uploadオプションを使用して、デプロイする前にファイルをアップロードします。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -upload c:\localfiles\myapp.ear

展開されたアーカイブ・ディレクトリをアップロードするには、アーカイブ・ファイル名のかわりにディレクトリ名を指定します(たとえば、c:\localfiles\myappEar)。

管理サーバー・マシンにファイルをアップロードすると、アーカイブ・ファイルはサーバーのアップロード・ディレクトリに自動的に配置されます。このディレクトリのパスは、「サーバーのデフォルト・ステージング動作の変更」にある手順にしたがって構成できます。

アプリケーションまたはプランを更新する場合のアップロードの動作

ローカルとリモート(アップロード)のデプロイメント操作を混在させる場合は、アプリケーションのデプロイの過程を追跡するプロセスを用いることが重要です。以下のような一連のイベントを検討してください。

1. 管理者または開発者は、次の情報を使用して、管理対象サーバーを持つ管理サーバーに、デプロイメント・プラン(productionEnvPlan.xml)を含めたアプリケーション(myapp.ear)をデプロイした場合。

java weblogic.Deployer -adminurl http://test:7001 -username weblogic
-password weblogic -deploy c:\localfiles\myapp.ear
-plan c:\localfiles\productionEnvPlan.xml

2. 管理者または開発者は管理対象サーバー上でWebLogic Portalを使用し、myapp.earアプリケーションに対していくつかの構成変更を保存した場合。アプリケーションを保存すると、WebLogic Portalは次の情報を使用してアプリケーションを更新します。

java weblogic.Deployer -adminurl http://test:7001 -username weblogic
-password weblogic -update -name myapp.ear -upload
-plan c:\localfiles\nuPlan.xml

3. リモート・マシンにあるアプリケーションとデプロイメント・プラン・ファイルが、管理サーバーのアップロード・ディレクトリにアップロードされた場合。デプロイメントが更新され、構成ではc:\domain\servers\adminServerName\upload\plan\nuPlan.xmlのデプロイメント・プランが使用されます。

この時点で、アプリケーション(c:\localfiles\myapp.ear)とデプロイメント・プラン(c:\localfiles\productionEnvPlan.xml)から派生した動作を想定している管理者または開発者は、混乱してしまう可能性があります。管理者または開発者が、

- アプリケーションとデプロイメント・プラン・ファイルを確認すると、ファイルは変更されていません。新しい動作の説明はつかないように見えます。

- c:\localfiles\myapp.earアプリケーション・ファイルまたはc:\localfiles\productionEnvPlan.xmlデプロイメント・プランxmlファイルに変更を加えた場合、アップロード・ディレクトリ内のデプロイメント構成の変更は、失われるおそれがあります。

単一サーバー・ドメインへのデプロイ

1つの管理サーバーのみで構成される単一サーバーのWebLogic Serverドメインは、アプリケーションまたはモジュールをデプロイするシナリオとしては最も単純なものになります。ドメインと同じマシンにあるファイルをデプロイする場合は、管理サーバーの接続引数を指定して-deployコマンドを使用し、ファイルの場所を指定します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy c:\localfiles\myapp.ear

「デフォルト・デプロイメント名の理解」で説明されているように、上記のコマンドでWebLogic Serverは、myappというデフォルト・デプロイメント名を作成します。myappはデプロイメント・ファイルの名前から拡張子を除いたものです。デフォルト以外のデプロイメント名を指定する場合は、次のように-nameオプションを使用します。

java weblogic.Deployer -adminurl http://localhost:7001
-username weblogic -password weblogic -deploy
-name myTestApplication c:\localfiles\myapp.ear

アプリケーションまたはモジュールを複数のターゲットにデプロイする方法については、「サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定」を参照してください。

デプロイメント・プランによるアプリケーションのデプロイ

weblogic.Deployerを使用してアプリケーションをデプロイする場合、デプロイメント・プランとWebLogic Serverデプロイメント記述子では、対象の環境の有効なコンフィグレーションを定義する必要があります。定義されていない場合、デプロイメントは失敗します。つまり、アプリケーションの必須のリソース・バインディングに対してnullの変数を定義したデプロイメント・プランを指定して、weblogic.Deployerを使用することはできません。

weblogic.Deployerを使用してアプリケーションとデプロイメント・プランをデプロイするには、-deployコマンドと一緒に-planオプションを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -name myTestDeployment
-source /myDeployments/myApplication.ear
-targets myCluster -stage
-plan /myDeployments/myAppPlan.xml

アプリケーションのルート・ディレクトリからデプロイし、デプロイメント・プランが/planサブディレクトリにある場合でも、実際のデプロイメント・ソース・ファイルと、デプロイメントに使用するプランの両方を指定する必要があります。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -name myTestDeployment
-source /myDeployments/installedApps/myApplication/app/myApplication.ear
-targets myCluster -stage
-plan /myDeployments/installedApps/myApplication/plan/plan.xml

デプロイメント・プランを指定してアプリケーションをデプロイまたは配布する場合、アプリケーションのソース・ファイルと一緒に、デプロイメント・プランと生成済みデプロイメント記述子がターゲット・サーバーのステージング・ディレクトリにコピーされます。

アプリケーション・アーカイブとは別にデプロイメント・プランのステージングもできます。「デプロイメント・プランのステージング」を参照してください。

preStart期間中にJNDIからシステム・リソースをルックアップするアプリケーションのデプロイ

preStartアプリケーション・ライフサイクル・リスナーはアプリケーションの準備フェーズ中(編集セッションがアクティブ化のときに発生)に呼び出されるため、同じ編集セッション中に新しいシステム・リソースを作成し、そのシステム・リソースを使用するアプリケーションをデプロイすると、システム・リソースのJNDIルックアップは失敗します。たとえば、WebLogic Server管理コンソールで編集ロックを取得し、新しいJDBCシステム・リソースを作成して、同じ編集セッション中に(つまり、WebLogic Server管理コンソールで変更をアクティブ化する前に)、そのJDBCシステム・リソースを使用するアプリケーションをデプロイする場合、システム・リソースがアクティブになる前にpreStartアプリケーション・ライフサイクル・リスナーが呼び出されるため、JDBCシステム・リソースのJNDIルックアップは失敗します。preStartライフサイクル・リスナーでJNDIからシステム・リソースをルックアップするには、起動時または別の編集セッションでシステム・リソースを作成してから、システム・リソースを使用するアプリケーションをデプロイすることをお薦めします。例:

1. WebLogic Server管理コンソールで「ロックして編集」をクリックして、編集ロックを取得します。

2. 必要なシステム・リソースを作成します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの作成に関する項を参照してください。

3. WebLogic Server管理コンソールで「変更のアクティブ化」をクリックして、編集セッションを完了します。

4. WebLogic Server管理コンソールで「ロックして編集」をクリックして、別の編集ロックを取得します。

5. ステップ2で作成したシステム・リソースを使用するアプリケーションをデプロイします。WebLogic Server管理コンソールからアプリケーションをデプロイする方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーションおよびモジュールのデプロイに関する項を参照してください。

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

サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定

ほとんどの本番環境では、通常、WebLogic Serverドメインに構成されている1つまたは複数の管理対象サーバーにアプリケーションをデプロイします。場合によっては、サーバーがWebLogic Serverクラスタに含まれていたり、仮想ホストがWebアプリケーションのリクエストの転送に使用されていることがあります。デプロイメント・ターゲットとは、アプリケーションまたはモジュールをデプロイできるサーバーまたはサーバーの集合のことです。

デプロイメント・ターゲットの理解

デプロイメント・ターゲットとは、アプリケーションまたはスタンドアロン・モジュールをデプロイするサーバーまたはサーバーのグループです。デプロイメント・プロセス中に、ドメインで構成されている使用可能なターゲットからターゲットのリストを選択します。モジュールをデプロイした後でターゲットのリストを変更できます。

次の表では、WebLogic Serverのすべての有効なデプロイメント・ターゲットについて説明し、各ターゲットにデプロイできるモジュールの種類を示します。

表6-1 WebLogic Serverのデプロイメント・ターゲット

ターゲット・タイプ

説明

有効なデプロイメント

WebLogic Serverインスタンス

単一サーバー・ドメインの管理サーバー、管理対象サーバーなどのWebLogic Serverインスタンス。

Java EEアプリケーション

Java EEモジュール

JMS、JDBC、またはWLDFモジュール

Java EEライブラリ

クラスタ

複数のWebLogic Serverインスタンスの構成済みクラスタ。

Java EEアプリケーション

Java EEモジュール

JMS、JDBC、またはWLDFモジュール

Java EEライブラリ

仮想ホスト

特定のDNS名に対するリクエストをWebLogic Serverインスタンスまたはクラスタにルーティングする、構成済のホスト名。詳細は、『Oracle WebLogic Serverサーバー環境の管理』の仮想ホスティングの構成に関する項を参照してください。

Webアプリケーション

JMSサーバー

WebLogic Serverドメインで構成されているJMSサーバー。

JMSモジュール内に定義されているJMSキューまたはトピック*

*スタンドアロン・アプリケーション・モジュールとしてデプロイされた場合、JMS、JDBCまたはWLDFリソースは、WebLogic Server管理コンソールではJava EEデプロイメントとして表示されます。

スタンドアロンのJMSアプリケーション・モジュールは、サーバー、クラスタ、または仮想ホストのターゲットに割り当てることができます。JMSモジュール内で定義されているキューおよびトピックは、さらに、構成済JMSサーバーに割り当てることができます。サブモジュールのターゲット指定の詳細については、「JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用」を参照。

1つまたは複数のターゲットへのデプロイ

1つのWebLogic Serverターゲットにデプロイするには、weblogic.Deployerの-targetsオプションの後に、構成済みのターゲット名を指定します。たとえば、companyHostという名前の構成済み仮想ホストにWebアプリケーションをデプロイするには、次のコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets companyHost c:\localfiles\myWebApp.ear

複数のターゲットは、カンマ区切りのリストを使用して指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets ManagedServer-1,ManagedServer-2
c:\localfiles\myapp.ear

クラスタ・ターゲットへのデプロイ

(-targets myclusterを使用して)クラスタ・ターゲットを指定すると、WebLogic Serverはデフォルトでクラスタ内のすべてのサーバー・インスタンスをターゲットに指定します。これは、ほとんどのクラスタにおいて薦められる均質なモジュール・デプロイメントに対応しています。クラスタ内の1つのサーバーのみにモジュールをデプロイする(モジュールをサーバーに「固定」する)場合は、ターゲットとして、クラスタではなく個別のサーバー・インスタンス名を指定します。このタイプのデプロイメントは一般的ではなく、固定されたサービスが必須とされる特別な状況においてのみ行うようにする必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ構成およびアプリケーション・デプロイメントの理解に関する項を参照してください。

注意:
クラスタ内の(1つのサーバーではなく)複数のサーバー・インスタンスのサブセットにデプロイメントを固定することはお薦めできません。その場合は警告メッセージが生成されます。

アプリケーションをクラスタ・ターゲットにデプロイする場合、WebLogic Serverは必ず、クラスタのすべての使用可能なメンバーにデプロイメントを正常にデプロイします。クラスタ内の使用可能なWebLogic Serverインスタンスのうち、アプリケーションをデプロイできないインスタンスが1つでもあると、デプロイメント全体が失敗して、クラスタ内のどのサーバーもそのアプリケーションを起動しません。つまり、デプロイメント処理は1つの論理単位として成功または失敗するので、クラスタにおける均一なデプロイメントが維持されます。

クラスタリングされたサーバーが、(管理サーバーと管理対象サーバーの間にネットワーク障害がある、クラスタ・メンバーが停止しているなどの理由で)デプロイメントの時点でアクセス不能である場合、そのサーバーは、ネットワーク接続が回復するまでデプロイメント・リクエストを受信しません。このデフォルトの動作によって、サーバーがオフラインに置かれている場合でも、ほとんどのデプロイメント処理が成功します。

すべての構成済みクラスタ・メンバーへの一貫性のあるデプロイメントの強制

デフォルトのクラスタ・デプロイメントの動作では、デプロイメントの時点でアクセス可能なすべてのクラスタリング・サーバー・インスタンスに対する、均一なデプロイメントが保証されます。ただし、ネットワークの停止が原因で、管理サーバーが1つまたは複数のクラスタリング・サーバーにアクセスできない場合、それらのサーバーは、ネットワーク接続が回復するまで、デプロイメント・リクエストを受信しません。再デプロイメント処理の場合、この動作は、アクセス不能なサーバーがデプロイ済みアプリケーションの古いバージョンを使用する一方で、アクセス可能なサーバーは新しいバージョンを使用するという状況につながる可能性があります。ネットワーク接続が回復した場合、以前に接続できなかったサーバーは、遅延した再デプロイメント・リクエストを受信して、突然アプリケーションを更新することになります。

WebLogic Serverドメインの起動時にClusterConstraintsEnabledオプションを設定すると、クラスタに対するWebLogic Serverのデフォルトのデプロイメント動作を変更することができます。ClusterConstraintsEnabledオプションは、クラスタ内に構成されているすべてのサーバーに対する、厳密なデプロイメントを強制します。クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合にのみ、クラスタへのデプロイメントが成功します。

警告:
非常に信頼性の高いネットワーク構成を備えていて、すべてのクラスタ・メンバーが常にデプロイメントおよび再デプロイメント・リクエストを受信できる場合以外は、ClusterConstraintsEnabledオプションを使用しないでください。ClusterConstraintsEnabledを使用する場合、使用不能なクラスタリング・サーバーがあると、たとえば、保守のために1つでもサーバーが停止していると、WebLogic Serverではクラスタへのすべてのデプロイメント処理が失敗します。

管理サーバーの起動時にドメインにClusterConstraintsEnabledを設定するには、適切な起動引数を指定します。

- -DClusterConstraintsEnabled=true - ドメイン内のサーバーに対する厳密なクラスタ・デプロイメントを強制します。

- -DClusterConstraintsEnabled=false - すべての使用可能なクラスタ・メンバーがアプリケーションまたはモジュールをデプロイするようにします。使用不能サーバーが、使用可能なクラスタリング・インスタンスへの正常なデプロイメントを妨げることはありません。これは、WebLogic Serverのデフォルトのデプロイメント動作に相当します。

モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ

エンタープライズ・アプリケーション(EARファイル)は、他のモジュール・タイプ(WARおよびJARアーカイブ)を含むことができるため、他のデプロイメント・ユニットとは異なります。WebLogic Server管理コンソールを使用してエンタープライズ・アプリケーションをデプロイする場合は、アーカイブのすべてのモジュールを1つのデプロイメント・ユニットとして一緒に割り当てることも、個々のモジュールを別々のサーバー、クラスタまたは仮想ホストに割り当てることもできます。

モジュール・レベルのターゲット指定を使用して、EAR内にあるモジュールのサブセットのみをデプロイすることもできます。複数のモジュールを1つの配布可能なEARにパッケージ化し、各ドメインに必要なモジュールのみを割り当てることによって、アプリケーションのパッケージ化と配布を簡素化することができます。

モジュールターゲット指定の構文

エンタープライズ・アプリケーション内の個々のモジュールを割り当てるには、module_name@target_name構文を使用します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name myEnterpriseApp
-targets module1@myserver1,module2@myserver2,module3@myserver3
-stage -deploy c:\localfiles\myEnterpriseApp.ear

Webアプリケーション・モジュールのターゲット指定

.earファイルの一部であるWebアプリケーション・モジュールを割り当てるには、Webアプリケーションのcontext-root名をモジュール名として使用するか、web-uriを指定します。

たとえば、myEnterpriseApp.earファイルのapplication.xmlファイルで次のように定義されている場合は、

<module>
<web>
<web-uri>myweb.war</web-uri>
<context-root>/welcome</context-root>
</web>
</module>

context-root名を使用してWebアプリケーション・モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name mywebapplication -targets /welcome@myserver1
-stage -deploy c:\localfiles\myEnterpriseApp.ear

web-uriを使用して、Webアプリケーション・モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name mywebapplication -targets myweb.war@myserver1
-stage -deploy c:\localfiles\myEnterpriseApp.ear

WebアプリケーションをデフォルトWebアプリケーションとしてデプロイするには、context-root要素の値を「/」に設定します。たとえば、myEnterpriseApp.earファイルのapplication.xmlファイルで次のように定義されている場合は、

<module>
<web>
<web-uri>myweb.war</web-uri>
<context-root>/</context-root>
</web>
</module>

context-root名を使用してWebアプリケーション・モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name mywebapplication -targets /@myserver1
-stage -deploy c:\localfiles\myEnterpriseApp.ear

モジュールの起動と停止

各子モジュールは、次の手順を実行すると起動または停止できます。

java weblogic.Deployer -username weblogic -password weblogic -adminurl
t3://localhost:7001 -name appName -start -targets moduls1@myserver1

java weblogic.Deployer -username weblogic -password weblogic -adminurl
t3://localhost:7001 -name appName -stop -targets moduls1@myserver1

注意:
モジュールに依存関係がある場合、本番環境でのモジュールの起動および停止に関する注意を参照してください。

JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ

スタンドアロンのJDBC、JMS、およびWLDFアプリケーション・モジュールは、スタンドアロンのJava EEモジュールと同様にデプロイできます。スタンドアロンのJDBC、JMS、またはWLDFアプリケーション・モジュールの場合、ターゲットのリストによって、モジュールを利用できるWebLogic Serverドメインが決定されます。アプリケーション・モジュール内で指定したJNDI名はグローバル名としてバインドされ、クライアントから使用可能になります。たとえば、スタンドアロンのJDBCアプリケーション・モジュールを1つのサーバー・ターゲットにデプロイした場合、そのJDBCモジュールで定義されているリソースを必要とするアプリケーションは、同じサーバー・インスタンスにのみデプロイできます。アプリケーション・モジュールを複数のサーバーに割り当てることも、WebLogic Serverクラスタに割り当てて他のサーバーでリソースを使用できるようにすることもできます。

JDBC、JMS、またはWLDFリソースをドメイン内のすべてのサーバーで使用できるようにする必要がある場合は、デプロイ可能なアプリケーション・モジュールではなく、システム・モジュールを作成します。『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・リソースの構成に関する項、『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic JDBCリソースの構成に関する項および『Oracle WebLogic Server診断フレームワークの構成と使用』の診断システム・モジュールの構成に関する項を参照してください。

注意:
JMSモジュールをデプロイしても、必ずしもそのモジュールが適切に割り当てられてアクティブになり、JNDI名が使用可能になっているとは限りません。JMSモジュールが適切に割り当てられるまで、JNDI名は使用可能になりません。詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソース構成の理解に関する項を参照してください。

アプリケーション・スコープのJMS、JDBC、およびWLDFモジュールのターゲット指定

JMS、JDBC、およびWLDFアプリケーション・モジュールは、アプリケーション・スコープのリソース・モジュールとして、エンタープライズ・アプリケーションに含まれる場合もあります。必要に応じて、デプロイメント時にモジュール・レベルのターゲット指定構文を使用して、アプリケーション・スコープのリソース・モジュールを、他のEARモジュールとは別に割り当てることができます。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name myEnterpriseApp
-targets myWebApp@myCluster,myJDBCModule@myserver1,myEJBModule@myserver1
-stage -deploy c:\localfiles\myEnterpriseApp.ear

JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用

JMSアプリケーション・モジュールの内部で定義されている特定のJMSリソースを、そのモジュールのターゲットで使用可能になっているJMSサーバーに、デプロイメント時にさらに割り当てることができます。このようなリソースをサブモジュールといいます。次のタイプのサブモジュールはJMSサーバーにデプロイする必要があります。

- キュー

- トピック

他のサブモジュールは、JMSサーバーに加えて、WebLogic Serverインスタンスやクラスタに割り当てることができます。

- 接続ファクトリ

- 外部サーバー

- SAFインポート済み宛先

- 共通分散トピック

- 共通分散キュー

デプロイメント時またはアンデプロイメント時にサブモジュールのターゲットを指定するには、モジュールターゲット指定の構文を拡張して、weblogic.Deployerに-submoduletargetsオプションを指定する必要があります。

デフォルトのサブモジュールのターゲット指定

『Oracle WebLogic Server JMSリソースの管理』のJMSモジュールとリソースのサブデプロイメントのターゲット指定に関する項で説明されているように、WebLogic Server管理コンソールからデプロイするときに、WebLogic Serverは、JMSアプリケーション・モジュール内のサブモジュール用に、デフォルトのJMSサーバー・ターゲットを選択します。

WLSTを使用してサブモジュールをデプロイするときには、以下のすべての条件が満たされる場合に、親モジュールのターゲットをJMSリソースのデフォルトのターゲットとして使用できます。

- アプリケーションに1つまたは複数のJMSモジュールが含まれています。

- モジュール・ターゲットに関連付けられたJMSサーバー・インスタンスが1つのみ存在します。

- -submoduletargetsオプションが指定されていません。

- defaultSubmoduleTargetsオプションがtrueです。

『WebLogic Scripting Tool』のデプロイメント・コマンドに関する項を参照してください。

スタンドアロンのJMSモジュールにおけるサブモジュールのターゲット指定

スタンドアロンのJMSモジュールの場合、サブモジュールのターゲット指定の構文は-submoduletargets submodule_name@target_nameになります。たとえば、1つのサーバー・インスタンスにスタンドアロンのJMSモジュールをデプロイする場合、JMSServer1というJMSサーバーにサブモジュールmyQueueを割り当てるには、次のコマンドを入力します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name myJMSModule
-targets ManagedServer1 -submoduletargets myQueue@JMSServer1
-deploy c:\localfiles\myJMSModule.xml

同じJMSモジュールをアンデプロイするには、次のコマンドを入力します。このコマンドでは、myJMSModuleの中に複数のサブモジュールがあると想定し、myQueueサブモジュールのみをアンデプロイします。他のサブモジュールは影響を受けません。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name myJMSModule
-undeploy -submoduletargets myQueue@JMSServer1

アプリケーション・スコープのJMSモジュールにおけるサブモジュールのターゲット指定

EAR内のアプリケーション・スコープのJMSモジュールの場合は、submodule_name@module_name@target_nameという構文を使用して、サブモジュールを割り当てます。たとえば、上記の例のキューがエンタープライズ・アプリケーションの一部としてパッケージ化されている場合は、次のコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name myEnterpriseApp
-targets ManagedServer1 -submoduletargets myQueue@myJMSModule@JMSServer1
-deploy c:\localfiles\myEnterpriseApp.ear

同じJMSモジュールをアンデプロイするには、次のコマンドを入力します。このコマンドでは、myEnterpriseAppの中に複数のサブモジュールがあると想定し、myQueueサブモジュールのみをアンデプロイします。他のサブモジュールは影響を受けません。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name myEnterpriseApp
-undeploy -submoduletargets myQueue@myJMSModule@JMSServer1

警告:
アプリケーション・スコープのリソースを含むアプリケーションをアンデプロイすると、そのリソースはアプリケーションと一緒に削除されます。そのため、JMS宛先の削除が原因で、トランザクションが破棄されたり、メッセージが失われたりする可能性があります。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のリソース登録解除の猶予期間に関する項を参照してください。
完全に削除するアプリケーションのみをアンデプロイするようにしてください。アプリケーションへのクライアント・アクセスを一時的に停止するには、「weblogic.Deployerコマンド行リファレンス」で説明するように、-stopコマンドを使用します。

JMSサブデプロイメントの詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSモジュールとリソースのサブデプロイメントのターゲット指定に関する項を参照してください。

ステージング・モードによるデプロイメント・ファイルのコピーの制御

デプロイメントのステージング・モードにより、デプロイメント・ファイルを、アプリケーションまたはスタンドアロン・モジュールをデプロイする必要があるターゲット・サーバーから使用できるようにする方法が決まります。WebLogic Serverのステージング・モードには、stageモード、nostageモード、external_stageモードの3種類があります。

- ステージング・モードとベスト・プラクティス

- nostageモードのデプロイメントの使用

- nostageモードの構文

- stageモードのデプロイメントの使用

- stageモードの構文

- external_stageモードのデプロイメントの使用

- external_stageモードの構文

- サーバーのデフォルト・ステージング動作の変更

- デプロイメント・プランのステージング

ステージング・モードとベスト・プラクティス

次の表では、デプロイメント・ステージング・モード別にそのモードを使用する場合の動作とベスト・プラクティスについて説明します。

表6-2 アプリケーション・デプロイメントのステージング・モード

デプロイメントのステージング・モード

動作

使用するタイミング

stage

管理サーバーは最初にデプロイメント・ユニットのソース・ファイルをターゲット・サーバーのステージング・ディレクトリにコピーします。(ステージング・ディレクトリはデフォルトでstageという名前であり、ターゲット・サーバーのルート・ディレクトリにあります。)

ターゲット・サーバーは次にデプロイメント・ファイルのローカル・コピーを使用してデプロイします。

- 小さいサイズまたは中程度のサイズのアプリケーションを複数のWebLogic Serverインスタンスにデプロイする場合。

- 小さいサイズまたは中程度のサイズのアプリケーションをクラスタにデプロイする場合。

nostage

管理サーバーはデプロイメント・ユニット・ファイルをコピーしません。代わりに、すべてのサーバーで同じデプロイメント・ファイルの物理コピーを使用してデプロイします。それらのファイルは、管理サーバーとターゲット・サーバーから直接アクセス可能でなければなりません。

展開されたアーカイブ・ディレクトリのnostageモード・デプロイメントでは、WebLogic ServerはデプロイメントのJSPまたはサーブレットに対する変更を自動的に検出し、デプロイメントをリフレッシュします。(この動作は必要に応じて無効にできます。)

- 単一サーバー・ドメインにデプロイする場合。

- 複数のホームがあるマシン上のクラスタにデプロイする場合。

- 使用可能なデプロイメント・ファイルが共有ディレクトリにある複数のターゲットまたはクラスタに、非常に大きいアプリケーションをデプロイする場合。

- 内容変更後、定期的に再デプロイする展開されたアーカイブ・ディレクトリをデプロイする場合。

- WebLogic Server管理コンソールを通じて選択されたデプロイメント記述子の動的更新を必要とするデプロイメント。

external_stage

管理サーバーはデプロイメント・ファイルをコピーしません。そのかわりに、デプロイメントの前に、(たとえば、デプロイメントの前に手動でファイルをコピーするなどして)デプロイメント・ファイルが正しいステージング・ディレクトリの位置にコピーされていることを管理者が確認する必要があります。

external_stageデプロイメントでは、管理サーバーは検証用にデプロイメント・ファイルのコピーを必要とします。ターゲット・サーバーのステージング・ディレクトリ内に存在するデプロイメント・ファイルのコピーは、デプロイメントの前には検証されません。

-noversionオプションを使用すると、デプロイメント・ファイルが管理サーバー上にあるという要件を無効にできる。ただし、-noversionオプションを使用するとバージョン情報は無視されるので、バージョン管理されているアプリケーションでは-noversionオプションを使用できない。詳細については、「共通の引数」を参照。

- デプロイメント・ファイルのターゲット・サーバーへの配布を手動で制御するデプロイメント。

- デプロイメント・ファイルを正しいステージング・ディレクトリにコピーするようにサード・パーティのアプリケーションまたはスクリプトで管理しているドメインにデプロイする場合。

- WebLogic Server管理コンソールを通じて選択されたデプロイメント記述子の動的更新(external_stageモードではサポートされない)を必要としないデプロイメント。

- アプリケーション・コンポーネントの部分的な再デプロイを必要としないデプロイメント。

サーバーのステージング・ディレクトリは、管理サーバーがstageモード・デプロイメント用のデプロイメント・ファイルをコピーするディレクトリです。また、external_stageモードを使用してアプリケーションをデプロイする前には、このディレクトリにデプロイメント・ファイルが配置されている必要があります。

ほとんどのデプロイメントでは、stageモードまたはnostageモードを使用します。アプリケーションまたはモジュールをデプロイするときに、WebLogic Serverのデプロイメント・ツールは適切なモードを使用します。たとえば、weblogic.DeployerまたはWLSTを使用してWebLogic Serverでアプリケーションをデプロイするとき、stageモードを指定しない場合、デフォルトのstageモードが使用されます。管理サーバーでは、デフォルトのstageモードはnostageで、管理対象サーバーではstageです。

以下の節では、アプリケーションまたはモジュールをデプロイするときに、デプロイメントのステージング・モードを明示的に設定する方法について説明します。

nostageモードのデプロイメントの使用

nostageモードでは、管理サーバーはアーカイブ・ファイルをソース位置からコピーしません。かわりに、各ターゲット・サーバーは、デプロイメント用の単一のソース・ディレクトリにあるアーカイブ・ファイルにアクセスする必要があります。nostageデプロイメントでは、ターゲット・サーバーのステージング・ディレクトリは無視されます。

たとえば、Java EEアプリケーションをクラスタ内の3つのサーバーにデプロイする場合、アプリケーションをデプロイするには各サーバーが(共有またはネットワーク・マウント・ディレクトリの)同じアプリケーション・アーカイブ・ファイルにアクセスできる必要があります。

注意:
nostageモードでは、デプロイメント・ファイルのソースは、デプロイ時にユーザーが指定するパスです(これに対し、stageモードでは各サーバーのステージング・ディレクトリのパスがソースになります)。ただし、WebLogic Serverは、nostageモードの場合でもデプロイメント・ファイルの一部を一時ディレクトリにコピーします。このため、ユーザーがアーカイブ形式デプロイメントの全体または一部を更新することが可能です。

nostageモードでは、Webアプリケーション・コンテナがJSPおよびサーブレットに対する変更を自動的に検出します。また、アプリケーションの一部のみを後から更新することもできます。そのためには、該当する部分をファイル・システムの1つの位置で更新し、再デプロイします。

WebLogic Server管理コンソールでは、管理サーバーのみにデプロイする場合(単一サーバー・ドメインの場合など)のデフォルト・モードとしてnostageモードが使用されます。weblogic.Deployerでは対象サーバーのステージング・モードを使用し、管理サーバーではnostageモードをデフォルトで使用します。同じマシンでサーバー・インスタンスのクラスタを実行する場合、または共有ディレクトリにアクセスできる複数のマシンに非常に大きいアプリケーションをデプロイする場合も、nostageモードを選択できます。非常に大きいアプリケーションをnostageモードでデプロイすると、ファイルがコピーされないため、デプロイ時間を短縮できます。

nostageモードの構文

nostageモードを使用するには、weblogic.Deployerのオプションとして-nostageを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name mydeploymentname
-targets myserver1,myserver2,myserver3 -nostage
-deploy c:\localfiles\myapp.ear

stageモードのデプロイメントの使用

stageモードでは、管理サーバーはマシンの元の位置から各ターゲット・サーバーのステージング・ディレクトリにデプロイメント・ファイルをコピーします。たとえば、stageモードを使用してクラスタ内の3つのサーバーにJava EEアプリケーションをデプロイする場合、管理サーバーは3つのサーバー・マシンのそれぞれのディレクトリにデプロイメント・ファイルをコピーします。各サーバーは、アーカイブ・ファイルのローカル・コピーを使用してJava EEアプリケーションをデプロイします。

ステージング・ディレクトリにファイルをコピーするときに、管理サーバーはデプロイメント名と同名のサブディレクトリを作成します。そのため、次のコマンドを使用してデプロイした場合、

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name mytestear -stage -targets mycluster
-deploy c:\Oracle\Middleware\wlserver_12.1\samples\server\medrecd\dist\physicianEar

myclusterの各サーバーのステージング・ディレクトリに新しいディレクトリmytestearが作成されます。デプロイメント名を指定しないと、次のようにデフォルトのデプロイメント名(およびステージング・サブディレクトリ)が使用されます。

- 展開されたアーカイブ・デプロイメントの場合、デプロイメント名およびステージング・サブディレクトリはデプロイするディレクトリの名前になります(上の例ではphysicianEar)。

- アーカイブされたデプロイメントの場合、デフォルトのデプロイメント名はアーカイブ・ファイルの名前から拡張子を除いた名前になります(たとえば、physicianEar.earをデプロイする場合のデプロイメント名とステージング・サブディレクトリはphysicianEar)。

WebLogic Server管理コンソールでは、複数のWebLogic Serverインスタンスにデプロイする場合のデフォルト・モードとして、stageモードを使用します。weblogic.Deployerではデフォルトとしてターゲット・サーバーのステージング・モードを使用し、管理対象サーバーではデフォルトでstageモードを使用します。

stageモードでは、ネットワーク停止により管理サーバーがアクセス不能になった場合でも、各サーバーがデプロイメント・ファイルのローカル・コピーを持つことが保証されます。ただし、非常に大きいアプリケーションを複数のサーバー、またはクラスタにデプロイする場合は、ターゲット・サーバーへのファイルのコピーに要する時間がかなり長くなることがあります。大きいファイルを複数のサーバーにコピーすることによるオーバーヘッドを防ぐには、nostageモードを検討してください。

stageモードの構文

stageモードを使用するには、weblogic.Deployerのオプションとして-stageを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -name mydeploymentname
-targets myserver1,myserver2,myserver3 -stage
-deploy c:\localfiles\myapp.ear

external_stageモードのデプロイメントの使用

external_stageモードではstageモードと同様に、ターゲット・サーバーはデプロイメント・ファイルのローカル・コピーを使用してデプロイします。ただし、external_stageモードでは、管理サーバーはターゲット・サーバーにデプロイメント・ファイルを自動的にコピーしません。そのため、デプロイメントの前に、各ターゲット・サーバーのステージング・ディレクトリにファイルをコピーする必要があります。手動でコピーすることも、自動化スクリプトを使用することもできます。

デプロイメント・ファイルは、各ターゲット・サーバーのステージング・ディレクトリ内で、デプロイメント名を反映した名前を持つサブディレクトリに格納されている必要があります。この名前は、デプロイメントに対してユーザーが入力する名前、またはデフォルトのデプロイメント名(展開されたアーカイブ・ディレクトリの名前、またはアーカイブ・ファイル名からファイル拡張子を除いた名前)のどちらでもかまいません。

external_stageモードは、使用することが少ないデプロイメント・ステージング・モードです。このモードは、通常、必要なファイルの自動コピーをサード・パーティのツールによって管理している環境でのみ使用します。非常に大きいアプリケーションを複数のマシンにデプロイする場合で共有ファイル・システムがない(nostageモードを使用できない)場合も、external_stageモードを使用できます。このような場合にexternal_stageモードを使用すると、デプロイメント時にファイルがコピーされないため、デプロイメントにかかる時間を短縮できます。

-noversionオプションを使用すると、デプロイメント・ファイルが管理サーバー上にあるという要件を無効にすることができます。ただし、-noversionオプションを使用するとバージョン情報は無視されるので、バージョン管理されているアプリケーションでは -noversionオプションを使用できません。詳細については、「共通の引数」を参照。

external_stageモードの構文

external_stageモードでアプリケーションをデプロイするには:

1. デプロイメント・ファイルが管理サーバーからアクセス可能であることを確認します。(「リモート・クライアントからのデプロイメント・ファイルのアップロード」を参照してください。)

2. デプロイメントのターゲット・サーバーごとに、デプロイメント名と同じ名前のサブディレクトリをステージング・ディレクトリに作成します。たとえば、デプロイメント名としてmyEARExternalを指定する場合は、各ターゲット・サーバーのステージング・ディレクトリにmyEARExternalというサブディレクトリを作成します。

注意:
デプロイメント時にデプロイメント名を指定しない場合、WebLogic Serverによってデフォルトの名前が選択されます。詳細は、「デフォルト・デプロイメント名の理解」を参照してください。

3. 本番再デプロイメントで使用するためにバージョン管理されたアプリケーションをデプロイする場合は、デプロイするアプリケーションのバージョンに対応するサブディレクトリを、アプリケーション・ディレクトリの下に作成します。たとえば、myEARExternalをバージョン・レベル2.0Betaでデプロイする場合、各ターゲット・サーバーのmyEARExternal\2.0Betaというステージング・ディレクトリに、デプロイメント・ファイルを置く必要があります。

4. 上記のステップ2または3で作成したステージング・サブディレクトリにデプロイメント・ファイルをコピーします。

5. weblogic.Deployerユーティリティを使用してアプリケーションまたはモジュールをデプロイします。例:

java weblogic.Deployer -adminurl http://localhost:7001 -name weblogic
-password weblogic -external_stage -name myEARExternal
-deploy c:\myapps\myear

サーバーのデフォルト・ステージング動作の変更

サーバーのステージング・モードは、デプロイ時に指定されたモードがない場合のデフォルトのデプロイメント・モードになります。たとえば、weblogic.Deployerを使用してアプリケーションまたはスタンドアロン・モジュールをデプロイするときにステージング・モードを指定しなかった場合、サーバーのステージング・モードが使用されます。デフォルトのステージング・モードは、管理サーバーではnostageで、管理対象サーバーではstageです。

注意:
サーバーのステージング・モードは、WebLogic Server管理コンソールを使用するか、JMXを通じてServerMBeanを直接変更することによってのみ、変更できます。
サーバーのステージング・モードを変更しても、既存のアプリケーションには影響しません。既存のアプリケーションのステージング・モードを変更するには、アプリケーション・デプロイメントをアンデプロイしてから、新しいステージング・モードで再デプロイする必要があります。

WebLogic Server管理コンソールを使用してサーバーのステージング・モードを設定するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーのステージング・モードの設定に関する項の手順に従ってください。ステージング・モードの詳細は、表6-2を参照してください。

デプロイメント・プランのステージング

アプリケーション・アーカイブとは別に、アプリケーションのデプロイメント・プランをステージングできます。これにより、アプリケーションがステージングされていない場合にデプロイメント・プランのステージングが可能になります。WebLogic Serverでは、weblogic.Deployerを使用したデプロイメント・プランのステージングには次の3つのオプションがあります。

- -planstage: デプロイメント・プランをターゲット・サーバーのステージング・ディレクトリにコピーします。

- -plannostage: デプロイメント・プランをターゲット・サーバーにコピーせず、所定の場所に配置します。

- -planexternal_stage: デプロイメント・プランをターゲット・サーバーにコピーしません。かわりに、デプロイメント・プランがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。デプロイメント・プランを手動でコピーしたり、サード・パーティのツールやスクリプトを使用することができます。

ステージング・モードが指定されていない場合は、デフォルトとしてアプリケーションのステージングに指定された値がデプロイメント・プランに使用されます。

たとえば、デプロイメント・プランのステージングが指定されていない場合、およびアプリケーションのステージングがstageに設定されている場合は、デプロイメント・プランのステージング・モードはplanstageに設定されます。

デプロイメント・プランのステージングおよびアプリケーションのステージングの両方が指定されていない場合は、デフォルトのアプリケーションのステージング・モードとしてサーバー設定が使用されます。たとえば、サーバー設定がステージングしないである場合、デプロイメント・プランのステージング・モードはplannostageに設定されます。この場合に、デプロイメント・プランのステージングが必要な場合は、指定する必要があります。

本番環境へのアプリケーションの配布

アプリケーションの分散とは、デプロイメント・ファイルをすべてのターゲット・サーバーにコピーして検証し、アプリケーションをデプロイメントの準備が整った状態にすることです。アプリケーションを分散したら、そのアプリケーションを管理モードで起動できます。管理モードでは、アプリケーションに対するアクセスが構成済の管理チャネルに制限されるので、外部のクライアント接続にアプリケーションを公開せずに、アプリケーションを本番環境に分散(またはアプリケーションの新しいバージョンを分散)できます。

管理モードの間は、構成済の管理チャネル経由でのみアプリケーションに接続できます。したがって、アプリケーションの最終(状態)チェックを、クライアントを中断させることなく本番環境で直接実行できます。最終テストを行ったら、アプリケーションをアンデプロイしてさらに変更を加えることも、アプリケーションを起動して一般のクライアントから利用できるようにすることもできます。

-adminmodeオプションを使用すると、アプリケーションを管理モードで起動できます。詳細は、「配布されたアプリケーションの管理モードでの起動」を参照してください。

WebLogicドメインを超えてデポロイする場合、CrossDomainConnectorロールにより、外部のドメインからドメイン間の呼び出しを実行することができます。すべてのセキュリティ・ロールの完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のデフォルトのグローバル・ロールに関する項を参照してください。

アプリケーションの配布

アプリケーションを配布するには、次の示すようにweblogic.Deployer -distributeコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -distribute -name myTestDeployment
/myDeployments/myApplication/

配布されたアプリケーションの管理モードでの起動

WebLogic Serverがデプロイメント・ファイルを配布したら、アプリケーションを管理モードで起動して、構成済の管理チャネル経由でアプリケーションへのアクセスやテストを行えるようにします。管理チャネルを構成する方法は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

配布されたアプリケーションを管理モードで起動するには、-adminmodeオプションを指定して-startコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -start -adminmode -name myTestDeployment
/myDeployments/myApplication/

配布されたアプリケーションの起動

構成済の管理チャネルを使用して配布されたアプリケーションの最終テストを行ったら、-adminmodeオプションを指定せずにweblogic.Deployer -startコマンドを使用して、アプリケーションを新しいクライアント接続にオープンできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -start -name myTestDeployment

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

WebLogic ServerのJava EEライブラリのサポートにより、複数のエンタープライズ・アプリケーション間で、1つまたは複数のJava EEモジュールまたはJARファイルを簡単に共有できます。Java EEライブラリは、スタンドアロンのJava EEモジュール、エンタープライズ・アプリケーション(EAR)内にパッケージ化された複数のJava EEモジュール、またはデプロイメント時にJava EEアプリケーション・コンテナに登録されるプレーンなJARファイルです。Java EEライブラリが登録されると、そのライブラリを参照するエンタープライズ・アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に共有Java EEライブラリ・モジュールのコピーを受け取り、アプリケーション自体の一部としてパッケージ化されているかのように、これらのモジュールを使用できます。

注意:
OracleのドキュメントとWebLogic Serverユーティリティでは、ライブラリという語をJava EEライブラリとオプション・パッケージの両方の意味で使用します。必要な場合にのみオプション・パッケージと呼びます。

- 共有ライブラリに対するデプロイメント動作の理解

- WebLogic Serverでのライブラリの登録

- デプロイメント時のライブラリのバージョン指定

- ライブラリを参照するアプリケーションのデプロイ

共有ライブラリに対するデプロイメント動作の理解

WebLogic Serverでは、参照側アプリケーションがデプロイされるときに共有ファイルと参照側アプリケーションをマージすることによって、共有Java EEライブラリをサポートしています。

まず、Java EEライブラリをデプロイして、そのデプロイメントがライブラリであることを示すことによって、1つまたは複数のWebLogic ServerインスタンスまたはクラスタにJava EEライブラリまたはオプション・パッケージを登録します(「WebLogic Serverでのライブラリの登録」を参照)。ライブラリまたはパッケージをデプロイしても、そのデプロイメントは必ずしもターゲット・サーバー上でアクティブになりません。かわりに、WebLogic Serverがデプロイメント・ファイルをターゲット・サーバーに配布し(nostageデプロイメント・モードが使用されている場合)、デプロイメント・ファイルの場所、デプロイメント名、ライブラリまたはパッケージのバージョン文字列情報などを記録します。

共有ライブラリまたはパッケージを参照するアプリケーションがデプロイされると、WebLogic Serverは名前とバージョン文字列の要件を、サーバーに登録済みのライブラリに照らしてチェックします。ライブラリまたはパッケージ名に完全に一致するものが見つからない場合、またはバージョン要件が満たされない場合、そのアプリケーションのデプロイメントは失敗します。

アプリケーションで参照されているすべてのライブラリと名前およびバージョン文字列が一致するものが見つかったら、WebLogic Serverはそのライブラリのクラスを参照側アプリケーションのクラスパスに追加し、メモリー内でアプリケーションとライブラリの両方のデプロイメント記述子を結合します。結果としてデプロイされるアプリケーションは、参照されるライブラリがアプリケーションそのものにバンドルされているかのように見えます。

Java EEライブラリの内容は、エンタープライズ・アプリケーション内の他のJava EEモジュールと同様にクラスローダーにロードされます。たとえば、EJBモジュールは参照側アプリケーションのクラスローダーの一部としてロードされますが、Webアプリケーション・モジュールはアプリケーション・クラスローダーの下のクラスローダーにロードされます。共有Java EEライブラリがEARからなる場合は、そのEARのAPP-INF/libまたはAPP-INF/classesサブディレクトリに格納されているクラスも、参照側アプリケーションから使用できるようになります。

現在デプロイされているアプリケーションによって参照されているJava EEライブラリまたはオプション・パッケージをアンデプロイすることはできません。共有ライブラリまたはパッケージをアンデプロイする必要がある場合は、まず、共有ファイルを使用するすべてのアプリケーションをアンデプロイしてください。定期的なアプリケーションの保守作業では、共有ライブラリまたはパッケージの新しいバージョンをデプロイしてから、共有ファイルの新しいバージョンを使用するために参照側アプリケーションを再デプロイする必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有ライブラリのマニフェスト属性の編集に関する項を参照してください。

WebLogic Serverでのライブラリの登録

共有Java EEライブラリは、WebLogic Serverコンテナにライブラリとして登録されている、標準のJava EEモジュールまたはエンタープライズ・アプリケーションです。Java EEライブラリをWebLogic Serverコンテナに登録するには、次の手順を実行します。

1. 操作するデプロイメント・ファイルが有効なJava EEライブラリまたはオプション・パッケージであることを確認します。『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリの作成に関する項を参照してください。

2. ライブラリまたはパッケージを登録するWebLogic Serverターゲットを選択します。共有ライブラリは、参照側アプリケーションをデプロイするのと同じWebLogic Serverインスタンスに登録する必要があります。(後で必要に応じて参照側アプリケーションをデプロイできるように、ドメイン内のすべてのサーバーにライブラリをデプロイしてもかまいません。)

3. ライブラリまたはパッケージを登録します。それには、選択した対象サーバーにファイルをデプロイし、-libraryオプションで、そのデプロイメントをライブラリまたはパッケージとして指定します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library /deployments/myLibraryApplication/

デプロイメント時のライブラリのバージョン指定

ベスト・プラクティスとして、開発チームでは常に、ライブラリまたはオプション・パッケージのバージョン文字列情報を、デプロイメントのマニフェスト・ファイルに含めるようにしてください。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有ライブラリのマニフェスト属性の編集に関する項を参照してください。

バージョン文字列情報を含まないライブラリまたはパッケージをデプロイする場合は、以下のいずれかまたは両方のオプションを使用して、コマンド行で指定することができます。

- libspecver - ライブラリまたはパッケージの仕様のバージョンを定義します。

- libimplver - ライブラリまたはパッケージの実装のバージョンを指定します。

例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
-password weblogic -deploy -targets myserver1,myserver2
-library -libspecver 700 -libimplversion 7.0.0.1Beta
/deployments/myLibraryApplication/

注意:
マニフェスト・ファイルとweblogic.Deployerコマンド行の両方でバージョン情報を指定して、両者の値が一致していない場合、デプロイメントは失敗します。
最初に仕様または実装のバージョンを指定しないでライブラリを登録した場合は、新しいバージョンを登録してバージョン文字列情報を指定する前に、ライブラリをアンデプロイする必要があります。

ライブラリまたはパッケージの複数のバージョンを登録できますが、各バージョンで同じバージョン文字列を使用する必要があります。たとえば、仕様のバージョンのみを持つライブラリを登録してから、仕様と実装の両方のバージョンを持つそのライブラリの新しいバージョンを登録することはできません。

ライブラリを参照するアプリケーションのデプロイ

必要なバージョンのライブラリおよびパッケージをデプロイしたら、そのライブラリを参照するエンタープライズ・アプリケーションやモジュールをデプロイできます。参照側アプリケーションを正常にデプロイするには、次の2つの条件を満たす必要があります。

- 参照されるすべてのライブラリがアプリケーションのターゲット・サーバーに登録されています。

- 登録されたライブラリは参照側アプリケーションのバージョン要件を満たしています。

参照側アプリケーションをデプロイする特別な構文はありません。標準のエンタープライズ・アプリケーションまたはJava EEモジュールの場合と同様にアプリケーションをデプロイします。

注意:
参照側アプリケーションは、共有ライブラリの様々なレベルのバージョン要件を指定して構成できます。

アプリケーションの構成では以下のいずれかが必要です。

- 共有ライブラリまたはパッケージの最新バージョン(最新の登録済みバージョン)

- ライブラリまたはパッケージの最小のバージョン(または最高のバージョン)

- ライブラリまたはパッケージの厳密なバージョン

バージョン要件が原因で参照側アプリケーションをデプロイできない場合は、競合しているライブラリまたはパッケージの必要なバージョンを登録してみてください。または、開発チームに相談して、アプリケーションのバージョン要件を緩和できるかどうかを判断してください。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーション内のライブラリ参照に関する項を参照してください。

注意:
Webアプリケーション・コンポーネントを含むEARライブラリがある場合は、コンテキスト・パスの競合が起きるため、ライブラリを参照する複数のアプリケーションをデプロイすることはできません。これは、EARライブラリ内の個々のWebアプリケーションに対してcontext-rootを設定できないからです。context-rootはライブラリ全体に対してのみ設定できます。

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

アプリケーションのデプロイのベスト・プラクティス

アプリケーションをデプロイするときには、以下のベスト・プラクティスをお薦めします。

- 複数サーバー・ドメインの管理サーバーは、管理の目的にのみ使用するようにしてください。複数サーバー・ドメインの管理サーバーにデプロイすることはできますが、開発中以外はお薦めしません。

- デプロイメント・ファイルを異なる複数のユーザーまたは環境に配布するときには、そのファイルをアーカイブ形式(.ear、.jar、.warなど)にパッケージ化します。

- デプロイする前に、「デプロイするファイルのパッケージ化」で説明されているシナリオを確認してください。たいていの場合は、アーカイブ形式よりも展開形式の方がアプリケーションのデプロイメントには便利です。

- WebLogic Server管理コンソール、weblogic.Deployerツール、wldeploy AntタスクおよびWLSTはすべて、アプリケーションをデプロイするための同様の機能を提供します。

- WebLogic Server管理コンソールは、デプロイメント・ファイルの正確な位置や、ターゲット・サーバーまたはデプロイされるアプリケーションの正確な名前などが不明な場合に、対話形式でデプロイメント・セッションを行うために使用します。

- weblogic.Deployerは、デプロイメント・コマンドを既存の管理シェル・スクリプトまたは自動化されたバッチ・プロセスと統合するために使用します。

- wldeployは、新しいアプリケーションを開発してデプロイするために分割開発ディレクトリと一緒に使用します。wldeployは、シェル・スクリプトではなくAntを使用する管理環境でweblogic.Deployerの代わりとして使用することもできます。

- デプロイメント・タスクを実行する自動化スクリプトを作成する場合は、WLSTを使用します。

- 開発時に独自のアプリケーションをデプロイするには、autodeployディレクトリではなくwldeployを使用します。autodeployディレクトリは、テスト環境または一時的な環境で新しいアプリケーションを素早く実行するのに最適です。たとえばサンプル・アプリケーションをダウンロードしてその機能を評価する場合は、autodeployディレクトリを使用すると、アプリケーションを開発サーバーに素早くデプロイできます。

7 開発ドメインへのアプリケーションの自動デプロイ

この章では、WebLogic Server 12.1.3における自動デプロイメントについて説明します。これは、評価またはテスト用に、スタンドアロン・サーバー(管理サーバー)に対しアプリケーションを迅速にデプロイするための手法で、評価あるいはテスト用です。この手段は単一サーバーの開発環境でのみ使用することをお薦めします。

注意:
アプリケーションを開発するとき、Oracleは自動デプロイメントでなく、WebLogic Server分割開発ディレクトリおよびwldeploy antタスクを使用するようお薦めします。『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリの作成に関する項を参照してください。

自動デプロイメントが有効な場合は、アプリケーションが管理サーバーの\autodeployディレクトリにコピーされると、その管理サーバーは新しいアプリケーションの存在を検出し、それを自動的にデプロイします(管理サーバーが動作している場合)。アプリケーションを\autodeployディレクトリにコピーしたときにWebLogic Serverが稼働していない場合、そのアプリケーションはWebLogic Serverの管理サーバーが次に起動したときにデプロイされます。自動デプロイメントは管理サーバーに対してのみデプロイします。

注意:
Windowsのファイル・ロックの制限により、アプリケーションが展開された場合、アプリケーション内のすべてのモジュールも展開されます。つまり、展開するアプリケーションまたはモジュールにJARファイルが含まれる場合、自動デプロイメントは使用できません。
自動デプロイメントは、開発環境において単一ターゲット・サーバーで使用することを想定されています。WebLogic Server管理コンソールなど、他のツールを使用して自動デプロイ済の展開されたアプリケーションにターゲットを追加した場合、アプリケーションを再デプロイしても新しいターゲット・サーバーに変更は伝わりません。

次の項では、開発環境で自動デプロイメントを使用する方法について説明します。

- 自動デプロイメントの有効化と無効化

- アーカイブされたアプリケーションの自動デプロイ、再デプロイ、およびアンデプロイ

- 展開アーカイブの自動デプロイ、再デプロイ、およびアンデプロイ

- 自動デプロイメントの制限事項

自動デプロイメントの有効化と無効化

WebLogic Serverドメインは、開発環境と本番環境の2つの異なるモードで実行できます。ただし、自動デプロイメント機能は開発モードでのみ使用できます。

開発モードでは、WebLogic Serverインスタンスはdomain_name/autodeployディレクトリ(domain_nameはWebLogic Serverドメインの名前)にあるアプリケーションを自動的にデプロイおよび更新できます。本番モードでは自動デプロイメント機能が無効になり、本番モードに切り替えた後でautodeployディレクトリに置いたアプリケーションはデプロイされません。開発モードから本番モードに切り替えた場合、以前にautodeployディレクトリからデプロイされたアプリケーションはデプロイされたままになります。本番モードに切り替えた後でそのようなアプリケーションをアンデプロイまたは再デプロイする場合は、手動でアンデプロイまたは再デプロイする必要があります(たとえば、「weblogic.Deployerコマンド行リファレンス」で説明するように、weblogic.Deployerコマンドと-undeployまたは-redeployオプションを使用します)。

デフォルトの場合、WebLogic Serverドメインは開発モードで動作します。ドメインのモードを指定するには、『構成ウィザードによるWebLogicドメインの作成』を参照してください。

アーカイブされたアプリケーションの自動デプロイ、再デプロイ、およびアンデプロイ

アーカイブされたアプリケーションを自動デプロイするには、そのアーカイブ・ファイルを/autodeployディレクトリにコピーします。WebLogic Serverはアプリケーションのデプロイメント・モードを自動的にstageモードに設定します。

自動デプロイされたデプロイメント・ユニットは、サーバーの稼働時に動的に再デプロイできます。動的に再デプロイするには、アーカイブ・ファイルの新バージョンを/autodeployディレクトリ内の既存ファイルに上書きコピーします。

自動デプロイ済みのアーカイブされたデプロイメント・ユニットをアンデプロイするには、/autodeployディレクトリからアプリケーションを削除します。WebLogic Serverは、アプリケーションを停止して構成から削除します。

注意:
サーバーがアクティブでないときに/autodeployディレクトリからアプリケーションを削除すると、サーバーが再びアクティブな状態になった場合でも、WebLogic Serverはアプリケーションが削除されたことを検出しません。ドメイン・ツリーの同期を保つために、サーバーがアクティブな状態の場合にのみ/autodeployディレクトリからアプリケーションを削除することをお薦めします。

展開アーカイブの自動デプロイ、再デプロイ、およびアンデプロイ

展開されたアーカイブ形式でアプリケーションを自動デプロイするには、展開されたアーカイブ・ディレクトリ全体を/autodeployディレクトリにコピーします。WebLogic Serverは、nostageデプロイメント・モードを使用して、展開されたアーカイブ・アプリケーションを自動的にデプロイします。

注意:
Windowsのファイル・ロックの制限により、展開されたEARディレクトリをデプロイするとき、そのディレクトリにアーカイブされたモジュール(JARファイル)が含まれている場合、JARファイルはデプロイメント中はロックされて、削除できなくなります。したがって、自動デプロイするアプリケーションが展開されている場合は、そこに含まれているモジュールもすべて展開しておく必要があります。
展開されたアーカイブ・ディレクトリ全体の内容が/autodeployディレクトリ内にない場合に、アプリケーションを展開されたアーカイブ形式でデプロイしようとすると、自動デプロイメントは失敗します。展開されたアーカイブ形式の大きなアプリケーションを/autodeployディレクトリへコピーするのは時間がかかるため、サーバーが非アクティブ状態にあるときに、展開されたアーカイブ・ディレクトリを/autodeployディレクトリにコピーすることをお薦めします。展開されたアーカイブ・ディレクトリ全体が/autodeployディレクトリにコピーされた後で、サーバーをアクティブ状態に戻すと、アプリケーションは自動デプロイされます。または、大きなアプリケーションはweblogic.Deployerを使用してデプロイすることをお薦めします。「weblogic.Deployerコマンド行リファレンス」を参照してください。

アプリケーションが展開されたアーカイブ形式で自動デプロイされている場合、管理サーバーは、展開されたアプリケーションのディレクトリ内でREDEPLOYというファイルを定期的に検索します。このファイルのタイムスタンプが変更されている場合、管理サーバーは展開ディレクトリを再デプロイします。

展開されたアプリケーション・ディレクトリ内のファイルを再デプロイするには:

1. 展開されたアプリケーション・ディレクトリを初めてデプロイする場合、REDEPLOYという名前の空のファイルを作成し、そのファイルを、デプロイするアプリケーションのタイプに応じて、WEB-INFまたはMETA-INFディレクトリに配置します。
展開されたエンタープライズ・アプリケーションには、最上位にMETA-INFディレクトリがあり、このディレクトリにapplication.xmlファイルが格納されています。

展開されたWebアプリケーションには、最上位にWEB-INFディレクトリがあり、このディレクトリにweb.xmlファイルが格納されています。

展開されたEJBアプリケーションには、最上位にMETA-INFディレクトリがあり、このディレクトリにejb-jar.xmlファイルが格納されています。

展開されたコネクタには、最上位にMETA-INFディレクトリがあり、このディレクトリにra.xmlファイルが格納されています。

注意:
REDEPLOYファイルは、デプロイしたアプリケーション全体またはスタンドアロン・モジュールに対してのみ機能します。展開したエンタープライズ・アプリケーションをデプロイした場合、REDEPLOYファイルは、エンタープライズ・アプリケーションの個別モジュール(Webアプリケーションなど)ではなく、アプリケーション全体の再デプロイメントを制御します。Webアプリケーション自体を展開したアーカイブ・ディレクトリとしてデプロイする場合、REDEPLOYファイルはWebアプリケーション全体の再デプロイメントを制御します。

2. 展開されたアプリケーションを再デプロイするには、更新されたファイルをそのディレクトリ内の既存のファイルに上書きコピーします。

3. 新しいファイルをコピーしたら、展開ディレクトリ内のREDEPLOYファイルのタイムスタンプを更新します。

管理サーバーは、タイムスタンプの変更を検出すると、展開ディレクトリのコンテンツを再デプロイします。

注意:
自動デプロイしたアプリケーションの再デプロイメントを開始する場合は常に、REDEPLOYファイルをtouchする(タイムスタンプを変更する)必要があります。サーバーが停止状態のときにアプリケーションを変更する場合でも、REDEPLOYファイルをtouchし、次回のサーバー起動時に変更が確実に適用されるようにする必要があります。

展開形式で自動デプロイしたアプリケーションをアンデプロイするには、weblogic.Deployer -undeployコマンドを使用するか、またはWebLogic Server管理コンソールを使用して、デプロイメントの構成を削除します。次に、/autodeployディレクトリからアプリケーション・ファイルを削除します。

注意:
サーバーがアクティブでないときに/autodeployディレクトリからアプリケーション・ファイルを削除すると、サーバーが再びアクティブな状態になった場合でも、WebLogic Serverはアプリケーション・ファイルが削除されたことを検出しません。ドメイン・ツリーの同期を保つために、サーバーがアクティブな状態の場合にのみ/autodeployディレクトリからアプリケーション・ファイルを削除することをお薦めします。

自動デプロイメントの制限事項

自動デプロイしたアプリケーションは、開発環境では大変便利ですが、いくつかの制限事項があります。

- 自動デプロイしたアプリケーションのconfig.xmlには構成がありません。したがって、WebLogic Server管理コンソールでは、自動デプロイしたアプリケーションに関連付けられた注意や対象のページがありません。これは、そうした情報のバッキング構成がないためです。

- 自動デプロイしたアプリケーションは、デプロイメント・プランに反映される構成処理をサポートしていないため、自動デプロイしたアプリケーションをデプロイメント・プランに関連づけることはできません。

- 自動デプロイしたアプリケーションでは、セキュリティ・ポリシーやセキュリティ・ロールを設定することができません。

- 自動デプロイしたアプリケーションをWebLogic Serverツールを使用してアンデプロイまたは再デプロイすることはできません。

8 本番環境でのアプリケーションの再デプロイメント

この章では、WebLogic Server 12.1.3の再デプロイメントを利用して、アプリケーションや本番環境でデプロイしたアプリケーションの一部を更新する方法について説明します。

この章には次の項が含まれます:

- 再デプロイメント戦略の概要

- 様々な再デプロイメント戦略をいつ使用するかの理解

- 本番再デプロイメントを使用したアプリケーションの更新

- 本番アプリケーションの新しいバージョンの配布

- アプリケーションおよびスタンドアロン・モジュールに対するインプレース再デプロイメントの使用方法

- Java EEモジュールを更新するための部分的な再デプロイメントの使用

- デプロイされたアプリケーションにおける静的ファイルの更新

- アプリケーションのデプロイメント構成の更新

再デプロイメント戦略の概要

本番環境にデプロイされたアプリケーションでは、顧客や内部クライアントに絶え間なくサービスを提供するために、24時間x 7日間の可用性がしばしば必要になります。WebLogic Serverでは、必要な可用性のレベルに基づいて本番アプリケーションを更新または修正できるように、柔軟性のある再デプロイメント戦略を提供しています。

本番再デプロイメント

本番再デプロイメント戦略では、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイします。WebLogic Serverは、新しいクライアント・リクエストのみが新しいバージョンに転送されるように、自動的にクライアント接続を管理します。再デプロイメント時にアプリケーションにすでに接続していたクライアントは、作業が完了するまで古いバージョンのアプリケーションを使用し続けます。作業が完了した時点で、WebLogic Serverは自動的に古いバージョンをリタイアします。

本番再デプロイメントを使用すると、アプリケーションを停止せずに(アプリケーションのクライアントへの可用性を中断することなく)、本番環境でアプリケーションの更新と再デプロイを行うことができます。本番再デプロイメントでは、アプリケーションのダウンタイムのスケジューリング、新しいバージョンのアプリケーションをホストするための冗長サーバーの設定、複数のバージョンのアプリケーションに対するクライアント・アクセスの手動での管理、古いバージョンのアプリケーションの手動でのリタイアなどの手間を省くことができます(これらの手動の手順については、「インプレースでのアプリケーションおよびモジュールの再デプロイ」を参照してください)。

本番再デプロイメントを-distributeコマンドと併用すると、アプリケーションの新しいバージョンをデプロイメント用に準備することができます。その後で、アプリケーションを管理モードでデプロイできます。管理モードでデプロイすると、クライアントから使用できるようにする前に、新しいバージョンのアプリケーションの最終健全性テストを本番環境で直接実行できます。「本番アプリケーションの新しいバージョンの分散」を参照してください。

本番再デプロイメントは、特定の種類のJava EEアプリケーションでのみサポートされます。詳細は、「本番再デプロイメントの更新に関する制限事項」を参照してください。本番再デプロイメントの手順および関連情報については、「本番再デプロイメントを使用したアプリケーションの更新」を参照してください。

インプレース再デプロイメント

インプレース再デプロイメントでは、実行中のアプリケーションのデプロイメント・ファイルを、更新されたデプロイメント・ファイルでただちに置き換えます。本番再デプロイメントとは対照的に、アプリケーションまたはスタンドアロンJava EEモジュールのインプレース再デプロイメントでは、アプリケーションのクライアントに対する中断のないサービスは保証されません。これは、WebLogic Serverがアプリケーションの実行中のクラスローダーをただちに削除して、更新されたアプリケーションのクラス・ファイルをロードする新しいクラスローダーで置き換えるためです。

注意:
インプレース再デプロイメントは、以前のバージョンのWebLogic Serverで使用された再デプロイメント戦略です。

WebLogic Serverは、バージョン識別子を指定していないJava EEアプリケーションや、本番再デプロイメントでサポートされていないJava EEアプリケーションおよびスタンドアロン・モジュールの場合に、インプレース再デプロイメント戦略を使用します。アプリケーションおよびスタンドアロンJava EEモジュールのインプレース再デプロイメントは、アプリケーションの定期的な停止時間中に、または、クライアントからアプリケーションへの既存の接続の維持にとって重要ではない時間に行うようにしてください。詳細は、「アプリケーションおよびスタンドアロン・モジュールに対するインプレース再デプロイメントの使用方法」を参照してください。

WebLogic Serverでは、デプロイ済アプリケーションまたはモジュールの部分的な再デプロイメントを行う場合に、インプレース再デプロイメント戦略を使用します。「静的ファイルの部分的な再デプロイメント」で説明するように、部分的な再デプロイメントでは、アプリケーション内の静的ファイルや、エンタープライズ・アプリケーション・デプロイメント内のJava EEモジュール全体を置き換えることができます。

静的ファイルの部分的な再デプロイメント

WebLogic Serverでは、アプリケーション全体を一度に再デプロイするのではなく、実行中のアプリケーションの中の選択したファイルを再デプロイすることができます。この機能は一般に、実行中のWebアプリケーションの静的ファイル(画像、静的なHTMLページ、JSPなど)の更新に使用します。部分的な再デプロイメントは、展開されたアーカイブ・ディレクトリを使用してデプロイされているアプリケーションでのみ使用できます。

静的ファイルの部分的な再デプロイメントは、アプリケーションの既存のクライアントには影響を与えません。WebLogic Serverはデプロイされているアプリケーションの静的ファイルを単に置き換えるだけです。更新後のファイルはリクエストされたときにクライアントに提供されます。「デプロイされたアプリケーションにおける静的ファイルの更新」を参照してください。

Java EEモジュールの部分的な再デプロイメント

部分的な再デプロイメントでは、デプロイされているエンタープライズ・アプリケーションの中の1つのモジュールまたはモジュールのサブセットを再デプロイすることもできます。この場合も、部分的な再デプロイメントは、展開されたアーカイブ・ディレクトリを使用してデプロイされているアプリケーションでのみサポートされます。

エンタープライズ・アプリケーション内のモジュールの再デプロイメントでは、インプレース再デプロイメント戦略を使用するため、モジュールに対する中断のないクライアント・アクセスは保証されません。このため、EAR内のJava EEモジュールの部分的な再デプロイメントは、アプリケーションの定期的なダウンタイム中に、または、アプリケーションに対するクライアント・アクセスの維持にとって重要ではない時間に行うようにしてください。「Java EEモジュールを更新するための部分的な再デプロイメントの使用」を参照してください。

様々な再デプロイメント戦略をいつ使用するかの理解

次の表では、WebLogic Serverの各再デプロイメント戦略の概要を示し、各戦略を使用するシナリオについて説明します。

表8-1 再デプロイメント戦略のサマリー

再デプロイメント戦略

サマリー

用途

本番再デプロイメント

アプリケーションの既存のバージョンと並行して、アプリケーションの新しいバージョンを再デプロイします。

- 中断のないクライアント・アクセスを要求するWebアプリケーションやエンタープライズ・アプリケーションをアップグレードします。

アプリケーションおよびモジュールのインプレース再デプロイメント

更新されたアプリケーションのクラス・ファイルをロードするために、アプリケーションのクラスローダーは新しいクラスローダーでただちに置き換えられます。WebLogic Serverでは再デプロイメント時の中断のないクライアント・アクセスを保証しないので、既存のクライアントの状態に関する情報は失われる可能性があります。

- 定期的な保守のためにオフラインにされたアプリケーションを置き換えます。

- 中断のないクライアント・アクセスを求めないアプリケーションをアップグレードします。

静的ファイルの部分的な再デプロイメント(インプレース再デプロイメント)

HTML、JSP、グラフィック・ファイル、その他の静的ファイルを、更新済ファイルでただちに置き換えます。

- アプリケーションのクライアントに影響を与えないWebアプリケーションの個々のファイルを更新します。

Java EEモジュールの部分的な再デプロイメント(インプレース再デプロイメント)

更新されたクラス・ファイルをロードするために、モジュールのクラスローダーは新しいクラスローダーでただちに置き換えられます。WebLogic Serverでは再デプロイメント時にモジュールへの中断のないクライアント・アクセスを保証しないので、既存のクライアントの状態に関する情報は失われる可能性があります。

- 定期的な保守のためにオフラインになっている、または中断のないクライアント・アクセスを必要としないエンタープライズ・アプリケーションのコンポーネントを置き換えます。

本番再デプロイメントを使用したアプリケーションの更新

WebLogic Serverは、アプリケーションの既存のクライアントに影響を与えずに、また、新しいクライアント・リクエストに対するアプリケーションの可用性を中断することなく、本番アプリケーションの更新済みの新しいバージョンを再デプロイできます。

本番再デプロイメントのしくみ

WebLogic Serverでは、アプリケーションの実行中の古いバージョンと並行して、新しいバージョンのアプリケーションをデプロイすることによって、本番再デプロイメントを実行します。再デプロイメントが行われている間は、一方のバージョンのアプリケーションが「アクティブ」になり、もう一方のバージョンは「リタイア中」になります。アクティブなバージョンのアプリケーションは、そのアプリケーションに対する新しいクライアント接続リクエストをすべて受信します。一方、リタイア中のバージョンのアプリケーションは、再デプロイメントが行われたときに存在していたクライアント接続のみを処理します。WebLogic Serverは、アプリケーションのすべての既存のクライアントが作業を終えた後で、または構成されているタイムアウトに達した時点で、リタイア中のバージョンのアプリケーションをアンデプロイします。

図8-1 本番再デプロイメント

アプリケーションの新しいバージョンを再デプロイすると、WebLogic Serverでは、新しくデプロイされたアプリケーションのバージョンをアクティブなバージョンとして扱い、古い方のバージョンのリタイアを開始します。リタイア期間中、WebLogic ServerはアプリケーションのHTTPセッションと進行中のトランザクションを自動的に追跡します。WebLogic Serverはセッションが完了するかタイムアウトするまで、各HTTPセッションを追跡します。進行中のトランザクションは、トランザクションが完了、ロールバック、またはトランザクションのタイムアウト期間に達するまで追跡されます。

古い方のアプリケーション・バージョンをアクティブにすると、本番再デプロイメントのプロセスをロールバックできます。この操作は、たとえば、新しいバージョンのアプリケーションに問題があると判断した場合や、クライアントを古い方のバージョンに戻したい場合などに必要になります。古い方のアプリケーション・バージョンをアクティブにするには、そのバージョンを再デプロイします。

クラスタにおける本番再デプロイメント

WebLogic Serverクラスタでは、クラスタリングされた各サーバー・インスタンスは、現在の作業負荷を完了した時点で、リタイア中のアプリケーション・バージョンのローカル・デプロイメントをリタイアします。つまり、アプリケーション・バージョンは、クラスタ内の他のサーバーでリタイアされる前に、クラスタリングされた一部のサーバー・インスタンスでリタイアされる可能性があります。ただし、クラスタのフェイルオーバー・シナリオでは、クライアントのフェイルオーバー・リクエストは、そのアプリケーション・バージョンがまだ使用可能であれば、常にセカンダリ・サーバーにある同じアプリケーション・バージョンで処理されます。同じアプリケーション・バージョンがセカンダリ・サーバーで使用可能でない場合、フェイルオーバーは成功しません。

本番再デプロイメントの要件と制限事項

本番再デプロイメント機能を使用するには、開発時およびデプロイメントの段階で、アプリケーションは以下の要件を満たす必要があります。

開発の要件

本番再デプロイメント戦略は以下のものに対してサポートされています。

- スタンドアロンのWebアプリケーション(WAR)モジュールと、クライアントがWebアプリケーション(HTTP)経由でアクセスするエンタープライズ・アプリケーション(EAR)。

- グローバルなJMS宛先からのインバウンドJMSメッセージまたはインバウンドJCAリクエストによってアクセスされるエンタープライズ・アプリケーション。

- 会話形式で信頼性のあるWebサービスなど、すべてのタイプのWebサービス(ただし、8.xのWebサービスは除く)。

- Coherenceキャッシュ・クライアント – ストレージが無効な管理対象Coherenceサーバーにデプロイされる、EAR内のグリッド・アーカイブ(GAR)モジュール。GAR内のクラスは、既存のデプロイメントとの後方互換性を備えている必要があります。

以下のものに対しては、本番再デプロイメントはサポートされません。

- スタンドアロンのEJBまたはRARモジュール。そのようなモジュールで本番再デプロイメントを使用しようとすると、WebLogic Serverは再デプロイメント・リクエストを拒否します。そのようなモジュールを再デプロイするには、バージョン識別子を削除して、モジュールを明示的に再デプロイします。

- JTSドライバを使用するアプリケーション。JDBCアプリケーション・モジュールの制限の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCアプリケーション・モジュールの制限に関する項を参照してください。

- DriverManager APIを通じてJDBCデータ・ソースを取得するアプリケーション。本番再デプロイメントを使用するには、アプリケーションはJNDIを使用してデータ・ソースをルックアップする必要があります。

- EJB 1.1のコンテナ管理による永続性(CMP) EJBを含むアプリケーション。CMP EJBを含むアプリケーションで本番再デプロイメントを使用するには、EJB 1.1 CMPではなくEJB 2.x CMPを使用します。

- Coherenceキャッシュ・サーバー – ストレージが有効な管理対象CoherenceサーバーにデプロイされるGARモジュール。

本番再デプロイメントでサポートされるのはHTTPクライアントとRMIクライアントのみです(「RMIクライアント・リクエストの処理の正常な停止」を参照)。開発および設計チームは、サポートされないクライアントが、本番再デプロイメントを使用しているアプリケーションにアクセスしないようにしておく必要があります。WebLogic Serverはサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、本番再デプロイメント時にはサポートされないクライアント接続を維持しません。

本番再デプロイメント中にアプリケーションの複数のバージョンがWebLogic Serverドメインで安全に共存できるようにするため、開発時には、特定の要件を満たすようにアプリケーションを設計する必要があります。本番再デプロイメントを使用するアプリケーションで要求されるプログラミング・ルールに関する情報は、『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用バージョン付きのアプリケーションの開発に関する項を参照してください。

エンタープライズ・アプリケーションにJCAリソース・アダプタ・モジュールが含まれる場合、モジュールは:

- JCA 1.5に準拠している必要があります

- weblogic.connector.extensions.Suspendableインタフェースを実装する必要があります

- enable-access-outside-appがfalse (デフォルト値)に設定されており、アプリケーション・スコープの方法で使用されていること

新しいバージョンのEARのリソース・アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース・アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンのEAR全体がリタイアされます。

リソース・アダプタの本番再デプロイメント要件の完全なリストについては、『Oracle WebLogic Serverリソース・アダプタの開発』の本番再デプロイメントに関する項を参照してください。

警告:
本番再デプロイメント戦略ではアプリケーションが特定のプログラミング規約を守る必要があるため、開発および設計スタッフが承認したアプリケーションでのみ、本番再デプロイメントを使用してください。Oracleのプログラミング規約に従わないアプリケーションで本番再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。

デプロイメントの要件

デプロイされるアプリケーションでは、そのアプリケーションで本番再デプロイメント処理を実行する前に、バージョン番号を指定する必要があります。つまり、バージョン指定されていないアプリケーションをデプロイし、その後でアプリケーションの新しいバージョンによる本番再デプロイメントを実行することはできません。

本番再デプロイメントの更新に関する制限事項

WebLogic Serverは一度に最大2つまで異なるバージョンのアプリケーションをホストできます。

新しいバージョンのアプリケーションを再デプロイするときに、以下の設定を変更することはできません。

- アプリケーションのデプロイメント・ターゲット

- アプリケーションのセキュリティ・モデル

- Webアプリケーションの永続ストアの設定

上記の機能を変更するには、まず、アプリケーションのアクティブなバージョンをアンデプロイする必要があります。

アプリケーションのバージョン識別子の指定

WebLogic Serverでは、現在デプロイされているアプリケーションと再デプロイされるアプリケーションが別々のバージョンを指定している場合に、本番再デプロイメント戦略を使用しようとします。

アプリケーションにバージョン識別子を割り当てるには、デプロイするEARまたはWARのMANIFEST.MFファイルに、一意のバージョン文字列を直接格納することをお薦めします。開発プロセスでは、新しいアプリケーションをリリースするたびに自動的にバージョン識別子をインクリメントしてから、アプリケーションをデプロイメント用にパッケージ化するようにしてください。

バージョン情報をこのように保持すると、本番ドメインでアプリケーションが再デプロイされるたびに本番再デプロイメント戦略が使用されます。『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用バージョン付きのアプリケーションの開発に関する項を参照してください。

デプロイメントおよび再デプロイメント中のバージョン識別子の割当て

本番再デプロイメント機能をテストする場合、またはマニフェスト・ファイルにバージョン文字列を含まないアプリケーションに対して本番再デプロイメントを使用する場合は、アプリケーションのデプロイまたは再デプロイ時に、-appversionオプションを使用して一意のバージョン文字列を手動で指定できます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -deploy -name myTestDeployment
-source /myDeployments/myApplication/91Beta
-targets myCluster -stage -appversion .91Beta

-appversionで指定されたバージョン文字列は、デプロイメント・ソース・ファイルでMANIFEST.MF内にバージョン文字列を指定していない場合にのみ適用されます。アプリケーションのバージョン文字列で有効な文字と文字形式に関する情報は、『Oracle WebLogic Serverアプリケーションの開発』のアプリケーション・バージョン・ルールに関する項を参照してください。

警告:
本番再デプロイメントに関するOracleのプログラミング規約にアプリケーションがしたがっていない限り、本番環境で-appversionを使用してデプロイまたは再デプロイしないでください。「本番再デプロイメントの要件と制限事項」を参照してください。プログラミング規約に従わないアプリケーションで本番再デプロイメントを使用すると、グローバルなリソースが破損したり、望ましくないアプリケーションの動作につながる可能性があります。

デプロイされたアプリケーションのバージョン情報の表示

WebLogic Server管理コンソールでは、すべてのデプロイ済みアプリケーションおよびモジュールのバージョン文字列情報と状態情報の両方が表示されます。この情報を表示するには、WebLogic Server管理コンソールの左ペインで「デプロイメント」ノードを選択します。

weblogic.Deployer -listappsコマンドを使用して、デプロイ済みアプリケーションのバージョン情報をコマンド行から表示することもできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -listapps

アプリケーションの新しいバージョンの再デプロイ

本番再デプロイメント戦略を使用してアプリケーションの新しいバージョンを再デプロイするには:

1. アプリケーションの1つのバージョンのみが、ドメインに現在デプロイされていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。

2. デプロイ済みアプリケーションと新しいアプリケーションで異なるバージョン文字列を持っていることを確認します。

1. 「デプロイされたアプリケーションのバージョン情報の表示」の指示にしたがって、アプリケーションの現在デプロイされているバージョンを確認します。

2. デプロイする新しいアプリケーション・ソースのMANIFEST.MFファイルにあるバージョン文字列を調べます。

jar xvf myApp.ear MANIFEST.MF
cat MANIFEST.MF

3. 新しいアプリケーションのデプロイメント・ファイルを、デプロイメントに適した場所に置きます。アプリケーションのデプロイメント・ファイルの各バージョンを一意のサブディレクトリに格納することをお薦めします。
たとえば、現在デプロイされているアプリケーションのファイルが次の場所に格納されている場合、

/myDeployments/myApplication/91Beta

更新されたアプリケーション・ファイルは、次のような新しいサブディレクトリに格納します。

/myDeployments/myApplication/1.0GA

警告:
nostageまたはexternal_stageモードのデプロイメントの場合は、古いバージョンのアプリケーションのデプロイメント・ファイルを上書きまたは削除しないでください。後でリタイアプロセスをロールバックして元のアプリケーション・バージョンに戻す場合に、元のデプロイメント・ファイルが必要になります。

4. 新しいアプリケーション・バージョンを再デプロイして、更新されたデプロイメント・ファイルを指定します。更新されたデプロイメント・ファイルのマニフェスト・ファイルに一意のバージョン識別子が含まれている場合は、次のようなコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/1.0GA

注意:
元の場所を変更した場合は、バージョン管理された既存のアプリケーションに対して-sourceオプションを指定しないでください。その場合、まずアプリケーションのデプロイを解除してから、デプロイしなおす必要があります。
詳細については、「再デプロイ」を参照してください。

新しいデプロイメント・ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割当て」を参照してください。

デフォルトでは、WebLogic Serverは、新しいクライアント・リクエストを処理するために、アプリケーションの新しく再デプロイされたバージョンをアクティブにします。既存のクライアントは作業が完了するまで古いアプリケーションを使用し続け、古いアプリケーションは安全にアンデプロイされます。

(クライアントが作業を終了したかどうかに関係なく)古いバージョンのアプリケーションがリタイアされるまでの期間を指定する場合は、-redeployコマンドと一緒に-retiretimeoutオプションを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
-retiretimeout 300

-retiretimeoutでは、古いバージョンのアプリケーションがリタイアされるまでの秒数を指定します。また、次のように、-undeployコマンドを使用し、古いアプリケーション・バージョンを指定して、古い方のアプリケーションをただちにリタイアすることもできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -undeploy -name myTestDeployment
-appversion .91Beta

5. アプリケーションの古いバージョンと新しいバージョンの両方がデプロイされていて、適切なバージョンがアクティブになっていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。

リタイアされるアプリケーションのアンデプロイ

WebLogic Serverがアプリケーションのあるバージョンをまだリタイアしていない場合、リタイアが完了するまで待たずにそのアプリケーションのバージョンをただちにアンデプロイできます。この操作は、たとえば、維持する必要のない長時間のクライアント・セッションが1つか2つのみあってアプリケーションがリタイア状態のままになっている場合などに必要になります。リタイア中のアプリケーション・バージョンのアンデプロイメントを行うには、-undeployコマンドを使用してそのアプリケーション・バージョンを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -undeploy -name myTestDeployment
-appversion .91Beta

注意:
リタイア中のバージョンのアプリケーションをアンデプロイする場合やリタイアのタイムアウトが発生するのを待つ場合に、-undeployコマンドに-gracefulオプションを指定することはできません。
-appversionオプションでアプリケーションのバージョンを明示的に指定しない場合、WebLogic Serverは、アプリケーションのアクティブなバージョンとリタイアされたすべてのバージョンをアンデプロイします。アプリケーションの古いバージョンがまだリタイアされていないときに、-appversionオプションを指定しないで-undeployコマンドを実行すると、WebLogic Serverはサーバー・ログに警告メッセージを記録し、リタイアされていないバージョンのアンデプロイは行いません。そのようなアプリケーションのバージョンを後でアンデプロイするには、-undeployコマンドを再び実行し、-appversionオプションでアプリケーションのバージョンを指定します。

本番再デプロイメント・プロセスのロールバック

本番再デプロイメント・プロセスを元に戻すと、アクティブなアプリケーションとリタイア中アプリケーションの状態が切り替わり、新しいクライアント接続リクエストはそれにしたがってリダイレクトされます。アプリケーションの新しくデプロイされたバージョンで問題が見つかった場合や、クライアントが新しいバージョンにアクセスしないようにする場合は、本番再デプロイメント・プロセスを元に戻す必要があります。

本番再デプロイメント・プロセスをロールバックするには、-redeployコマンドを再び発行して、古いバージョンのデプロイメント・ソース・ファイルを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myTestDeployment
-source /myDeployments/myApplication/91Beta
-retiretimeout 300

あるいは、古いバージョンのデプロイメント・ソース・ファイルを指定するかわりに、-appversionオプションを使用すると、以前のバージョンを指定できます。

デプロイメント・ファイルのマニフェストにバージョン識別子が含まれていない場合は、「デプロイメントおよび再デプロイメント中のバージョン識別子の割当て」を参照してください。

RMIクライアント・リクエストの処理の正常な停止

-rmigraceperiod属性を使用すると、アプリケーションをリタイア(-retirement)または正常停止(-graceful)する場合に、RMIクライアント・リクエストを処理するための猶予期間(秒単位)を指定できます。サーバー・インスタンスのワーク・マネージャは、新しいRMIクライアント・リクエストを受信せずに、猶予期間が経過するまでRMI呼出しを受け付けてスケジューリングします。猶予期間内に新しいRMIクライアント・リクエストが発生した場合、猶予期間はリセットされて、RMIクライアントの処理は以下の時点まで続行されます。

- 別のRMIリクエストによって猶予期間がリセットされる

- RMIクライアント・リクエストがないまま猶予期間が過ぎる

RMIクライアントがリタイアされたアプリケーションまたは停止しているアプリケーションへアクセスしようとした場合、オブジェクトを呼び出そうとすると、クライアントはNoSuchObjectExceptionを受け取ります。そのオブジェクトの新しいバージョンが使用可能である場合、アプリケーションはNoSuchObjectException例外を取得し、JNDI環境プロパティweblogic.jndi.WLContext.RELAX_VERSION_LOOKUPを使用してオブジェクトの新しいバージョンをルックアップして、アクティブなバージョンのアプリケーションからバインドを戻す必要があります。

たとえば、次のコマンドは、保留中のHTTPセッションまたは進行中の作業が完了した後で、アプリケーションを管理モードにします。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -stop -adminmode -graceful
-rmigraceperiod 30

正常なリタイアがT0秒で開始され、RMIリクエスト(msg1)がT1秒(T1 < (T0 + 30))で届いた場合、アプリケーションは追加のRMIクライアント・リクエストをT1 + 30秒間待機します。

- msg2がT2秒(T2 < (T1 +30))で届いた場合、msg2はスケジューリングされ、猶予期間はT2+30秒にリセットされます。

- 追加のリクエストがない場合、またはリクエスト(msg2)がT2秒(T2 > (T1 +30))で届いた場合、ワーク・マネージャはRMIリクエストのスケジューリングを停止します。

本番アプリケーションの新しいバージョンの配布

アプリケーションの新しいバージョンを配布すると、WebLogic Serverはその新しいアプリケーション・バージョンをデプロイメントのために準備します。その後で、アプリケーションを管理モードでデプロイすると、アプリケーションは構成済の管理チャネル経由でのみ使用できるようになります。外部のクライアントは、配布されて管理モードでデプロイされたアプリケーションにはアクセスできません。

-adminmodeオプションを使用すると、アプリケーションを管理モードで起動できます。詳細は、「配布されたアプリケーションの管理モードでの起動」を参照してください。

アプリケーションの古いバージョンは、新しいクライアント・リクエストと既存のクライアント・リクエストの両方を処理するために、アクティブなままです。新しいバージョンを管理モードで配布およびデプロイした場合、WebLogic Serverはアプリケーションの古いバージョンを自動的にはリタイアしません。

図8-2 新しいバージョンのアプリケーションの配布

管理チャネル経由で新しいアプリケーションのテストを完了したら、新しいアプリケーション・バージョンをアンデプロイするか起動します。アプリケーションを起動するとWebLogic Serverは新しいクライアント接続を更新されたアプリケーションにルーティングし、古い方のアプリケーション・バージョンのリタイアを開始します。

アプリケーションの新しいバージョンを配布する手順

アプリケーションの新しいバージョンを管理モードで配布する基本的な手順は、「アプリケーションの新しいバージョンの再デプロイ」で説明した手順と同じです。-redeployコマンドのかわりに、weblogic.Deployer -distributeコマンドを使用するのみです。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -distribute -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
-appversion 1.0GA

アプリケーションを配布したら、管理モードで起動します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -start -adminmode -name myTestDeployment
-source /myDeployments/myApplication/1.0GA
-appversion 1.0GA

アプリケーションを管理モードで起動すると、構成済管理チャネル経由でのみ使用できるようになります。『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

必要に応じて、配布されるアプリケーションのリタイア・ポリシーやタイムアウト期間を指定することもできます。

アプリケーションをクライアントで使用できるようにする方法

構成済の管理チャネルを使用して最終テストを行ったら、-adminmodeオプションを指定せずにweblogic.Deployer -startコマンドを使用すると、管理モードで実行中の配布されたアプリケーション・バージョンを新しいクライアント接続にオープンできます。

1. WebLogic Server管理コンソールを使用して、両方のアプリケーション・バージョンのバージョンおよび状態情報を表示します。

1. アプリケーションの両方のバージョンがまだデプロイされていることを確認します。

2. 管理モードで実行中のアプリケーション・バージョンのバージョン識別子をノートします。

2. weblogic.Deployerに-appversionオプションを使用して、管理モードで配布してデプロイされたアプリケーションを起動します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -start -name myTestDeployment
-appversion .91Beta

デフォルトでは、WebLogic Serverは、以前に配布されて管理モードで実行中のアプリケーション・バージョンに、新しいクライアント・リクエストをルーティングします。既存のクライアントは作業が完了するまで古いアプリケーションを使用し続け、古いアプリケーションは安全にアンデプロイされます。(クライアントが作業を終了したかどうかに関係なく)古いバージョンのアプリケーションが廃止されるまでの期間を指定する場合は、-retiretimeoutオプションを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -start -name myTestDeployment
-appversion .91Beta -retiretimeout 300

-retiretimeoutでは、古いバージョンのアプリケーションがリタイアされるまでの秒数を指定します。

3. WebLogic Server管理コンソールを使用して、以前に配布したアプリケーションがアクティブになり、それより前のアプリケーション・バージョンがリタイア中になっていることを確認します。「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。

本番再デプロイメントの使用のベスト・プラクティス

本番再デプロイメントを使用する場合は、以下のベスト・プラクティスに留意してください。

- 本番再デプロイメントに関するOracleのプログラミング・ルールにアプリケーションがしたがっていない限り、本番アプリケーションに対してバージョン文字列を指定しないでください。『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用バージョン付きのアプリケーションの開発に関する項を参照してください。

- アプリケーションがstageモードでデプロイされている場合は、本番再デプロイメントを使用するのが最も簡単です。stageモードの場合、WebLogic Serverは、デプロイされているアプリケーションの別々のバージョンごとに別々のディレクトリを自動的に作成します。これらのディレクトリは、サーバーで構成されているステージング・ディレクトリ内に格納されて(デフォルトでは、ドメイン・ディレクトリのserver_name/stageサブディレクトリ)、関連付けられたアプリケーション・バージョンがアンデプロイされるときに削除されます。

- nostageモードでデプロイする場合は、アプリケーションの新しい各バージョンを専用のサブディレクトリに格納します。こうすると、デプロイメント・ファイルの古いバージョンが上書きされなくなり、更新後に問題が見つかった場合に以前のアプリケーションに戻すことができます。

- external_stageモードでデプロイする場合は、各アプリケーション・バージョンのデプロイメント・ファイルを、各ターゲット・サーバーのステージング・ディレクトリの、適切なバージョンのサブディレクトリに格納する必要があります。たとえば、以前のサンプル・コマンドで使用されているバージョン指定されたアプリケーション・ファイルの場合は、デプロイメントおよび再デプロイメントの前に、各サーバーのステージング・ディレクトリ内の/myTestDeployment/.91Betaおよび/myTestDeployment/1.0GAサブディレクトリにコピーする必要があります。

アプリケーションおよびスタンドアロン・モジュールに対するインプレース再デプロイメントの使用方法

インプレース再デプロイメントでは、実行中のアプリケーションのデプロイメント・ファイルをただちにアンデプロイし、更新されたデプロイメント・ファイルで置き換えます。アプリケーション全体またはJava EEモジュールの再デプロイにインプレース再デプロイメントを使用すると、アプリケーションまたはモジュールはデプロイメント・プロセス中に使用できなくなり、既存のクライアントでは進行中の作業が失われる可能性があります。アプリケーションのクラス・ファイルとライブラリがクラスローダーからただちにアンデプロイされて、更新されたバージョンで置き換えられるため、このようなクライアント・サービスの中断が発生します。

アプリケーションおよびモジュールのインプレース再デプロイメントはアプリケーションのクライアントに悪影響を及ぼすため、次の場合を除いて、本番アプリケーションでは使用しないでください。

- 現在アプリケーションを使用しているクライアントがありません。

- 再デプロイメント中にアプリケーションへのクライアント・アクセスや進行中の作業が失われてもかまわません。

注意:
WebLogic Serverは、バージョン識別子を含まないアプリケーションの場合は、常にインプレース再デプロイメントを実行します。

また、部分的な再デプロイメント処理(アプリケーションの一部分にのみ影響を与える再デプロイメント・コマンド)でもインプレース再デプロイメントを使用する場合が多くあります。また、再デプロイされるファイルはアクティブなクライアント接続に悪影響を及ぼさないので、本番アプリケーションで部分的な再デプロイメントを使用できる場合もあります。表8-0では、部分的な再デプロイメントの種類と、デプロイされたアプリケーションに与える影響について説明します。

表8-2 部分的な再デプロイメントの動作

部分的な再デプロイメントの範囲

再デプロイメントの動作

推奨される使用方法

画像ファイル、静的なHTMLファイル、JSP

ソース・ファイルはディスク上でただちに置き換えられて、次のクライアント・リクエスト時に提供されます。

アプリケーションの定期的なダウンタイム中、またはクライアント接続や進行中の作業の維持にとって重要ではない時間にのみ使用します。

エンタープライズ・アプリケーションにおけるJava EEモジュール

すべてのファイルはただちに置き換えられます。Javaクラス・ファイルとライブラリはクラスローダーからアンロードされ、更新済ファイルで置き換えられます。

アプリケーションの定期的なダウンタイム中、またはクライアント接続や進行中の作業の維持にとって重要ではない時間にのみ使用します。

動的なプロパティの変更(パラメータのチューニングなど)を伴うデプロイメント・プラン

アプリケーションはインプレースで更新されます。アプリケーションがバージョン指定されている場合、プランのバージョンはインクリメントされません。

すべての本番環境で安全。

動的でないプロパティ(リソース・バインド)の変更を伴うデプロイメント・プラン

アプリケーションがバージョン指定されていて、本番再デプロイメントに適しており、再デプロイされる場合、WebLogic Serverはバージョン識別子をインクリメントし、本番再デプロイメント戦略を使用してアプリケーションを更新します。

そのアプリケーションで本番再デプロイメントを使用できない場合は、アプリケーション全体を再デプロイする必要があります。

本番再デプロイメントに適している、バージョン指定されたアプリケーションでは安全。「本番再デプロイメントを使用したアプリケーションの更新」を参照してください。

アプリケーションで本番再デプロイメントを使用できない場合は、アプリケーションの定期的なダウンタイム中、またはクライアント接続や進行中の作業の維持にとって重要ではない時間にのみ、デプロイメント・プランを更新します。

動的ではないプロパティの変更を含むデプロイメント・プランとともに、アプリケーションを(更新ではなく)再デプロイする必要があります。そのようなプランを伴うアプリケーションを更新しようとすると失敗します。

インプレースでのアプリケーションおよびモジュールの再デプロイ

インプレース再デプロイメント戦略を使用してアプリケーション全体またはスタンドアロン・モジュールを再デプロイするには、次の点に留意してください。

1. アプリケーションへのクライアント接続を保護するには、まずアプリケーションをオフラインにして、アプリケーションにアクセスしているクライアントがないことを確認します。
アプリケーションをオフラインにする具体的な方法は、WebLogic Serverドメインのアーキテクチャによって異なります。多くの場合、冗長サーバーやクラスタが作成されていて、アプリケーションのコピーを個別にホストしており、ロード・バランシング・ハードウェアまたはソフトウェアがサーバーやクラスタへのアクセスを管理しています。アプリケーションをオフラインにするには、ロード・バランシング・ポリシーを変更して、サーバーのセットまたはクラスタから冗長セットにすべてのクライアント接続を移します。

2. 新しいアプリケーションのデプロイメント・ファイルを、デプロイメントに適した場所に置きます。アプリケーションのデプロイメント・ファイルの各バージョンを一意のサブディレクトリに格納することをお薦めします。
たとえば、現在デプロイされているアプリケーションのファイル(SimpleEAR.earなど)が次の場所に格納されている場合、

/myDeployments/myApplication/91Beta/SimpleEAR.ear

更新されたアプリケーション・ファイルは、次のような新しいディレクトリに格納します。

/myDeployments/myApplication/1.0GA/SimpleEAR.ear

3. アプリケーションを再デプロイして、更新されたデプロイメント・ソース・ファイルを指定します。構成済みのすべてのターゲット・サーバーにアプリケーションを再デプロイするには、デプロイメント名のみを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -source /myDeployments/myApplication/1.0GA/SimpleEAR.ear -name myApp

アプリケーションがクラスタリングされていない複数のサーバー・インスタンスにデプロイされている場合は、次のようにターゲット・リストを指定すると、ターゲット・サーバーのサブセットにのみアプリケーションを再デプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -source /myDeployments/myApplication/1.0GA/SimpleEAR.ear -name myApp
-targets myserver1,myserver2

注意:
クラスタにデプロイされたアプリケーションについては、再デプロイメントは常に、クラスタ内のすべてのターゲット・サーバー・インスタンスで行われます。アプリケーションがクラスタ内のすべてのサーバーにデプロイされている場合は、そのアプリケーションをクラスタ内の一部のサーバーに再デプロイすることはできません。

4. アプリケーションをホストするサーバーまたはクラスタをオフラインにした場合は、再デプロイメントの完了後にホスト・サーバーをオンラインに戻します。

5. 必要な場合は、ロード・バランシング・ハードウェアまたはソフトウェアのロード・バランシング・ポリシーを回復して、一時的なサーバーからオンラインの本番サーバーにクライアントを戻します。

インプレースでのアプリケーションおよびモジュールの再デプロイのベスト・プラクティス

インプレース再デプロイメントを使用してアプリケーション全体またはスタンドアロン・モジュールを再デプロイする場合は、次の点に留意してください。

- ステージングされたアプリケーション全体を再デプロイする場合、デプロイメント・ファイルが管理対象サーバーにコピーされるときにネットワーク・トラフィックが増加するため、パフォーマンスに影響が出る可能性があります。非常に大きなアプリケーションがある場合は、external_stageモードを使用して、アプリケーションを再デプロイする前にデプロイメント・ファイルを手動でコピーすることを検討してください。「external_stageモードのデプロイメントの使用」を参照してください。

- WebLogic Serverクラスタにデプロイされたアプリケーションは、常にクラスタのすべてのメンバーに再デプロイする必要があります。クラスタリングされたアプリケーションをクラスタのサブセットに再デプロイすることはできません。

- エンタープライズ・アプリケーションを正常に再デプロイするには、アプリケーションのすべてのモジュールが正常に再デプロイされる必要があります。

- デフォルトでは、Webアプリケーションの再デプロイ時にWebLogic Serverが現在のユーザーのセッションを破棄します。再デプロイメント中にWebアプリケーションのユーザー・セッションを維持するには、weblogic.xmlデプロイメント記述子ファイルのcontainer-descriptorスタンザでsave-sessions-enabledを「true」に設定します。ただし、インプレース再デプロイメントが行われている間、アプリケーションは使用できなくなります。

Java EEモジュールを更新するための部分的な再デプロイメントの使用

デプロイ済エンタープライズ・アプリケーションの個別のモジュールを再デプロイする場合、weblogic.Deployerユーティリティでは別のコマンド形式を使用します。エンタープライズ・アプリケーションのモジュールのサブセットを再デプロイする場合は、ターゲット・サーバー・リストでmodulename@servernameと指定して、再デプロイするモジュールを指定します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -redeploy -name myApp
-targets mymodule1@myserver1,mymodule2@myserver2

注意:
-redeploy module-uriの使用は非推奨になりました。かわりに、本番再デプロイメントを使用するか、または-targets module@target構文を使用してモジュールを再デプロイします。

アプリケーションがクラスタにデプロイされている場合は、一部のサーバーではなくクラスタ全体にモジュールを再デプロイする必要があります。クラスタ内の一部のサーバーを指定すると、weblogic.Deployerは次のエラーで応答します。

An attempt to add server target target_name to module module_name has been rejected. This is because its parent cluster, cluster_name, is aso targeted by the module.

EARでJava EEモジュールを更新する場合の制限事項

次の制限は、エンタープライズ・アプリケーション内のモジュールの部分的な再デプロイメントを行う場合に適用されます。

- エンタープライズ・アプリケーション内の1つのJava EEモジュールを再デプロイすると、同じクラスローダーにロードされている他のJava EEモジュールに影響を与える可能性がある場合、weblogic.Deployerでは、影響を受けるすべてのモジュールを明示的に再デプロイする必要があります。影響を受けるJava EEモジュールのサブセットのみを部分的に再デプロイしようとすると、weblogic.Deployerは次のエラーを表示します。

Exception:weblogic.management.ApplicationException: [J2EE:160076] You must include all of [module_list] in your files list to modify [module]

- アプリケーションのデプロイメント記述子ファイルを変更した場合は、部分的な再デプロイメントを行おうとしても、コンテナはアプリケーション全体を再デプロイすることに留意してください。

- WEB-INF/lib内のJARファイルは、Webアプリケーションの他の部分から独立して再デプロイできません。WEB-INF/lib内のJARファイルの再デプロイ時、コンテナは自動的にアプリケーション全体を再デプロイしますが、状態を保持します。

EARでJava EEモジュールを更新する場合のベスト・プラクティス

エンタープライズ・アプリケーション・モジュールで部分的な再デプロイメントを行う場合は、次のベスト・プラクティスに留意してください。

- エンタープライズ・アプリケーション内のJava EEモジュールを再デプロイするために部分的な再デプロイメントを使用する場合は、更新されたモジュールのクラスローダーにロードされているすべてのクラスが再ロードされます。WebLogic Serverデプロイメント記述子でカスタムのクラスロード階層を定義すると、部分的な再デプロイメントによってアプリケーションの他のモジュールが受ける影響を最小限に抑えることができます。クラスローディングの動作の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーション・クラスローディングに関する項を参照してください。

- WEB-INF/classesディレクトリ内のクラスは、Webアプリケーションの他の部分とは独立して再デプロイできません。Webアプリケーションの再ロード間隔を設定して、(WEB-INF/classesディレクトリ全体ではなく)更新したクラスのみをデプロイできます。(詳細は、『Oracle WebLogic Serverアプリケーション、サーブレット、JSPの開発』のweblogic.xml Schemaに関する項を参照してください。)また、『Oracle WebLogic Serverアプリケーションの開発』の実行中プログラムのクラス変更に関する項と、「FastSwapデプロイメントによる再デプロイメントの最小化」も参照してください。

- デフォルトでは、Webアプリケーション・モジュールを再デプロイするときに、WebLogic Serverは現在のユーザー・セッションを破棄します。再デプロイメント中にWebアプリケーションのユーザー・セッションを維持するには、weblogic.xmlデプロイメント記述子ファイルのcontainer-descriptorスタンザでsave-sessions-enabledを「true」に設定します。ただし、インプレース再デプロイメントが行われている間、アプリケーションは使用できなくなります。

デプロイされたアプリケーションにおける静的ファイルの更新

本番環境では、アプリケーション全体を再デプロイせずに、Webアプリケーション・モジュールの静的なコンテンツ(HTMLファイル、イメージ・ファイル、JSPなど)をリフレッシュすることが必要になる場合があります。Webアプリケーションまたはエンタープライズ・アプリケーションを展開されたアーカイブ・ディレクトリとしてデプロイした場合は、weblogic.Deployerユーティリティを使用して、1つ以上の変更済静的ファイルをインプレースで更新できます。

デプロイメント・ユニット内に関連付けられた単一のファイルを再デプロイするには、redeployコマンドの最後にファイル名を指定します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name myApp -redeploy myApp/copyright.html

更新したファイルのパス名は、展開されたアーカイブ・ディレクトリのルート・ディレクトリを基準とする相対パスで常に指定します。前述の例では、Webアプリケーションはエンタープライズ・アプリケーションの一部としてデプロイされるため、モジュール・ディレクトリを(myApp/copyright.html)と指定しています。

Webアプリケーションが、エンタープライズ・アプリケーションの一部としてではなく、スタンドアロン・モジュールとしてデプロイされている場合は、ファイルを単独で指定します(copyright.html)。

単一のファイルではなくディレクトリ名を指定して、ファイルのディレクトリ全体を再デプロイすることもできます。例:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name myApp -redeploy myApp/myjsps

この例では、エンタープライズ・アプリケーションのmyjspsサブディレクトリにあるすべてのファイルとサブディレクトリが、インプレースで再デプロイされます。

アプリケーションのデプロイメント構成の更新

アプリケーションまたはスタンドアロン・モジュールをデプロイしたら、WebLogic Server管理コンソールまたはweblogic.Deployerを使用して、WebLogic Serverのデプロイメント構成を変更できます。

WebLogic Server管理コンソールでは、個々のデプロイメント構成プロパティを対話形式で変更できます。一方、weblogic.Deployerでは、アプリケーションの再構成に使用する更新されたデプロイメント・プラン・ファイルのみを指定できます。

管理コンソールを使用しての構成の変更

WebLogic Server管理コンソールを使用すると、アプリケーションのデプロイメント・プランに含まれていないプロパティを含む、アプリケーションのすべての再デプロイメント構成プロパティを再構成できます。アプリケーションがデプロイメント・プランとともにデプロイされた場合、コンソールでは、そのアプリケーションの「デプロイメント・プラン」ページに、デプロイメント・プランの構成プロパティが表示されます。

アプリケーションの他の構成ページを使用して、WebLogic Serverの他の構成プロパティを変更できます。構成で使用できる具体的なプロパティは、デプロイされているアプリケーションやJava EEモジュールの種類によって異なります。これらのページは、アプリケーションがデプロイメント・プランとともにデプロイされているかどうかにかかわらず使用できます。

一部の構成の変更は実行中の本番アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント構成変更のための再デプロイメント動作の理解」を参照してください。

構成の変更の格納方法

デプロイメント・プランで定義されたプロパティをWebLogic Server管理コンソールを使用して変更すると、コンソールは、変更した新しいプロパティの変数定義とプランで定義されている既存の変数を含む、新しいデプロイメント・プランを生成します。新しいデプロイメント・プランの保存先を選択できます。

別のデプロイメント・プランを使用するためのアプリケーションの更新

weblogic.Deployerユーティリティでは、アプリケーションで使用する新しいデプロイメント・プランを指定すると、アプリケーションのデプロイメント構成を更新できます。

注意:
更新されたデプロイメント・プランは、アプリケーションの現在のターゲット・サーバーで有効でなければなりません。有効でない場合、構成の更新は失敗します。

別の(有効な)デプロイメント・プランでアプリケーションを再構成するには、-updateコマンドを使用して、新しいデプロイメント・プラン・ファイルを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -update -name myTestDeployment
-plan /myDeployments/myNewPlan.xml

注意:
一部の構成の変更は実行中の本番アプリケーションに適用可能ですが、それ以外の変更にはアプリケーションの停止と再起動が必要になります。「デプロイメント構成変更のための再デプロイメント動作の理解」を参照してください。

デプロイメント構成変更のための再デプロイメント動作の理解

注意:
次の項で説明する再デプロイメント動作は、WebLogic Server管理コンソールおよびweblogic.Deployer -updateコマンドを使用して行われた両方の構成の変更に適用されます。

デプロイされているアプリケーションのデプロイメント構成を変更する場合、WebLogic Serverは再デプロイメント処理を使用して変更を適用します。使用される再デプロイメント戦略の種類は、適用される構成の変更の性質によって異なります。リソース・バインディング・プロパティの値を変更した場合は、構成の更新で、本番再デプロイメント戦略(そのアプリケーションが本番再デプロイメントをサポートしている場合)、またはアプリケーション全体に対してインプレース再デプロイメント戦略が使用されます。本番環境では、アプリケーション全体またはモジュールに対してインプレース再デプロイメントを実行することはお薦めできません。アプリケーションは最初にアンデプロイされるので、接続しているクライアントが進行中の作業を失うおそれがあるためです。詳細については、「再デプロイメント戦略の概要」を参照してください。

9 デプロイされたアプリケーションの管理

この章では、現在WebLogic Server 12.1.3のドメインにデプロイされているアプリケーションとモジュールの一般的な保守タスクを実行する方法について説明します。

この章には次の項が含まれます:

- 本番アプリケーションのオフライン

- 共有ライブラリおよびパッケージのアンデプロイ

- デプロイされたエンタープライズ・アプリケーションへの新しいモジュールの追加

- サーバー起動時のデプロイメント順序の変更

- 既存のデプロイメントのターゲット・リストの変更

- Webアプリケーション・デプロイメントからのファイルの削除

- 長時間かかるデプロイメント・タスクの管理

- 内部アプリケーションのオンデマンド・デプロイメント

本番アプリケーションのオフライン

WebLogic Serverでは、テストまたは保守目的でアプリケーションをオフラインにする方法が2つあります。

- アプリケーションの停止によるクライアント・アクセスの制限 - アプリケーションでクライアント・リクエストを処理できないようにしますが、WebLogic Serverドメインからデプロイメントは削除されません。アプリケーションを停止するとデプロイメントは管理モードになり、構成済の管理チャネルを使用して内部的なテストを実行できるようになります。

- アプリケーションまたはモジュールのアンデプロイ - アプリケーションでクライアント・リクエストを処理できないようにし、WebLogic Serverで生成したデプロイメント・ファイルをドメインから削除します。

アプリケーションの停止によるクライアント・アクセスの制限

「本番環境へのアプリケーションの配布」で説明するように、アプリケーションを配布して管理モードで起動すると、アプリケーションへのアクセスは構成済の管理チャネルに制限されます。実行中のアプリケーションでクライアント・リクエストの処理を停止して、そのアプリケーションを管理モードにすることもできます。本番環境では、報告された問題を確認するためにアプリケーションを停止したり、定期的な保守を行うためにアプリケーションを外部クライアントの処理から分離したりできます。

実行中のアプリケーションを管理モードにするには、-stopコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -stop -adminmode

デフォルトでは、WebLogic Serverは、保留中のHTTPセッションや進行中の作業を考慮せずに、アプリケーションをただちに停止します。アプリケーションでクライアント・リクエストの処理を停止して、そのアプリケーションを管理モードにする前に、保留中のHTTPセッションが作業を完了するのを待機する場合は、-gracefulオプションを追加します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -stop -adminmode -graceful

注意:
-appversionオプションでアプリケーションのバージョンを明示的に指定しない場合、-stopコマンドはアプリケーションのアクティブなバージョンのみを停止します。停止する他のアプリケーション・バージョン(または、アクティブなバージョンのかわりに停止するアプリケーション・バージョン)がある場合は、-appversionオプションで指定する必要があります。

以前に停止したアプリケーションを再起動して外部クライアントから使用できるようにするには、-startコマンドを使用してデプロイメント名を指定します。停止していたアプリケーションを使用可能にするために再デプロイする必要はありません。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -start

コマンドの詳細については、「起動」を参照してください。

アプリケーションまたはモジュールのアンデプロイ

新しいアプリケーションまたはスタンドアロン・モジュールをドメイン内のサーバーにデプロイした後、デプロイメント名は選択したデプロイメント・ファイルに関連付けられたままになります。すべてのサーバー上でデプロイメントを停止した後でもファイルは、WebLogic Server管理コンソールまたはweblogic.Deployerユーティリティを使用した再デプロイメントが有効な状態になっています。

デプロイメント名および関連付けられたデプロイメント・ファイルをドメインから削除するには、アプリケーションまたはスタンドアロン・モジュールを明示的にアンデプロイする必要があります。weblogic.Deployerを使用してデプロイメント・ユニットをドメインからアンデプロイするには、-undeployコマンドを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -undeploy

注意:
-targetsおよび-submoduletargetsフラグを指定なしで、-undeployコマンドを使用すると、すべてのWebLogic Serverインスタンスからアプリケーションまたはスタンドアロン・モジュールが完全に削除され、すべてのJMSサブモジュール・リソースのターゲット指定が解除されます。

デフォルトでは、WebLogic Serverは現在のクライアントや進行中の作業を中断して、アプリケーションをただちに停止してアンデプロイします。本番環境では、現在のHTTPクライアントが作業を完了できるように、「正常に(gracefully)」アンデプロイすることもできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -undeploy -graceful

デプロイメント・ユニットをアンデプロイしても、デプロイメントに使用した元のソース・ファイルは削除されません。ドメインからデプロイメントの構成が削除されるだけです。また、WebLogic Serverがデプロイメント時に作成したデプロイメント・ファイルも削除されます(たとえば、stageデプロイメント・モードでコピーされたファイルや、管理サーバーにアップロードされたファイルなど)。

アンデプロイ後にデプロイメント・ユニットを再デプロイする必要がある場合は、「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」の指示にしたがって、デプロイメント・ファイル、ターゲット、ステージング・モード、およびデプロイメント名を再び指定する必要があります。

共有ライブラリおよびパッケージのアンデプロイ

共有Java EEライブラリまたはオプション・パッケージは、そのライブラリまたはパッケージを参照するすべてのアプリケーションがアンデプロイされるまでは、アンデプロイできません。アプリケーションまたはパッケージを参照するアプリケーションがない場合は、「アプリケーションまたはモジュールのアンデプロイ」の手順にしたがってアンデプロイしてください。

デプロイされたエンタープライズ・アプリケーションへの新しいモジュールの追加

WebLogic Serverのモジュール・レベルのターゲット指定を利用すると、すでにデプロイされている他のモジュールを再デプロイしなくても、新しいエンタープライズ・アプリケーション・モジュールを追加およびデプロイできます。EAR内に新しいモジュールをデプロイするには、「モジュールターゲット指定の構文」で説明しているモジュール・レベルのターゲット指定構文を使用するのみです。

たとえば、myapp.earという名前のデプロイ済エンタープライズ・アプリケーションにモジュールnewmodule.warを追加する場合は(必要に応じてapplication.xmlファイルを更新)、次のようにweblogic.Deployerコマンドを使用してnewmodule.warをデプロイできます。

java weblogic.Deployer -username myname -password mypassword
-name myapp.ear -deploy -targets newmodule.war@myserver
-source /myapp/myapp.ear

このコマンドでは、アプリケーション内のその他のモジュールは再デプロイせずに、新しいモジュールをデプロイします。EARファイル内のアーカイブされたモジュールの正しいファイル拡張子(上の例では.war)を指定する必要があります。

サーバー起動時のデプロイメント順序の変更

デフォルトでは、WebLogic Serverは以下の順序でアプリケーションおよびリソースをデプロイします。

1. JDBCシステム・モジュール

2. JMSシステム・モジュール

3. Java EEライブラリおよびオプション・パッケージ

4. アプリケーションおよびスタンドアロン・モジュール

5. 起動クラス

注意:
WebLogic Serverセキュリティ・サービスは常に、サーバー・リソース、アプリケーション、および起動クラスがデプロイされる前に初期化されます。したがって、起動クラスを使用してカスタム・セキュリティ・プロバイダを構成することはできません。また、カスタム・セキュリティ・プロバイダの実装がJDBCなどのデプロイ済みサーバー・リソースに依存することもできません。

アプリケーションおよびスタンドアロン・モジュールのデプロイメント順序の変更

WebLogic Server管理コンソールでAppDeploymentMBean DeploymentOrder属性を設定して(または、AppDeploymentMBeanをプログラム的に使用して)、デプロイされたアプリケーションまたはスタンドアロン・モジュールのデプロイメント順序を変更することができます。DeploymentOrder属性は、デプロイメントの(相対的な)ロード順序を制御します。DeploymentOrderの値が小さいモジュールが、値の大きいモジュールよりも先にデプロイされます。デフォルトでは、各デプロイメント・ユニットのデプロイメント順序の値は100に構成されます。デプロイメント順序の値が同じデプロイメントは、デプロイメント名のアルファベット順にデプロイされます。すべての場合に、アプリケーションとスタンドアロン・モジュールは、WebLogic Serverインスタンスが依存するサブシステムを初期化した後でデプロイされます。

注意:
weblogic.Deployerユーティリティを使用してアプリケーションおよびスタンドアロン・モジュールのロード順序を変更することはできません。

WebLogic Server管理コンソールを使用してデプロイメントのデプロイ順を確認したり変更するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーのデプロイ順の変更に関する項の手順に従ってください。

エンタープライズ・アプリケーションにおけるモジュールのデプロイメント順序の変更

エンタープライズ・アプリケーションに含まれているモジュールは、application.xmlデプロイメント記述子で宣言されている順序でデプロイされます。『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーション・デプロイメント記述子要素に関する項を参照してください。

起動クラスの実行およびデプロイメントの順序付け

デフォルトでは、サーバーでJMSサービスとJDBCサービスが初期化され、アプリケーションおよびスタンドアロン・モジュールがデプロイされた後に、WebLogic Serverの起動クラスが実行されます。

JMSサービスとJDBCサービスが使用可能になった後、アプリケーションおよびモジュールがアクティブ化される前に起動タスクを実行する場合は、WebLogic Server管理コンソールで「アプリケーション・デプロイメントの前に実行」オプションを選択します(またはStartupClassMBeanのLoadBeforeAppActivation属性を「true」に設定します)。

JMSサービスとJDBCサービスが使用可能になる前に起動タスクを実行する場合は、WebLogic Server管理コンソールで「アプリケーション・アクティブ化の前に実行」オプションを選択します(またはStartupClassMBeanのLoadBeforeAppDeployments属性を「true」に設定します)。

WebLogic Server管理コンソールで「アプリケーションの前に実行」または「アプリケーション・アクティブ化の前に実行」を選択するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの起動クラスの構成に関する項を参照してください。

次の図は、WebLogic Serverでいつ起動クラスが実行されるかを簡単に示しています。

図9-1 起動クラスの実行

詳細は、StartupClassMBeanの詳細なJavadocsを参照してください。

既存のデプロイメントのターゲット・リストの変更

WebLogic Serverドメインでアプリケーションまたはスタンドアロン・モジュールをデプロイした後、新しいWebLogic Serverインスタンスを追加したり、既存のサーバー・インスタンスを削除したりして、ターゲット・サーバー・リストを変更できます。ターゲット・サーバーを削除した場合、ターゲット・リストだけが更新されます。デプロイメント・ユニットは、明示的にアンデプロイするまで、削除したサーバーにデプロイされた状態のままです。同様に、新しいターゲット・サーバーを追加した場合は、デプロイメント・ユニットを新しいサーバーに明示的にデプロイする必要があります。

weblogic.Deployerを使用して新しいサーバーをターゲット・リストに追加するには、-deployコマンドでターゲット・サーバーの新規リストを指定します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mydeploymentname -deploy
-targets server1, newserver

Webアプリケーション・デプロイメントからのファイルの削除

展開されたアーカイブ・ディレクトリを使用してWebアプリケーションをデプロイする場合、ファイルをリフレッシュするか(「デプロイされたアプリケーションにおける静的ファイルの更新」を参照)、デプロイメントからファイルを削除することによって、Webアプリケーションの静的なコンテンツを更新できます。ファイルを削除するには、weblogic.Deployerユーティリティにdelete_filesオプションを指定して使用します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mywebapp -delete_files mywebapp/copyright.html

更新されるファイルのパス名は、常に、展開されたアーカイブ・ディレクトリの最上位レベルから指定します。上記の例では、Webアプリケーションはmywebappという名前の展開されたアーカイブ・ディレクトリにあります。

注意:
-delete_filesオプションでは、指定されたすべてのファイル(ディレクトリを指定してディレクトリ内のファイルを指定していない場合は、指定されたディレクトリ内のすべてのファイル)が削除されるため、delete_filesオプションは慎重に使用し、本番環境ではdelete_filesオプションを使用しないことをお薦めします。

長時間かかるデプロイメント・タスクの管理

WebLogic Serverのデプロイメント・システムはデプロイメント・タスクに一意のIDを自動的に割り当てるので、デプロイメント・タスクの進捗状況を追跡して管理できます。weblogic.Deployerでは、デプロイメント・コマンドで使用するために独自のタスクIDを割り当てたり、長時間かかるデプロイメント・タスクのモニターや取消しを行えます。

たとえば、以下のコマンドでは、redeployPatch2というタスクIDを新しいデプロイメント処理に割り当てます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mymodule -targets myserver -id redeployPatch2
-nowait -deploy c:\localfiles\myapp.ear

このタスクのステータスを後でチェックできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -id redeployPatch2 -list

次のように、実行中のすべてのタスクのステータスをチェックできます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -listtask

タスクの完了に時間がかかりすぎる場合は、タスクを取り消すことができます。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -id redeployPatch2 -cancel

内部アプリケーションのオンデマンド・デプロイメント

起動時に、多くの内部アプリケーションがデプロイされます。これらの内部アプリケーションは、メモリーを消費し、デプロイメント時にCPU時間を必要とします。その結果、WebLogic Serverの起動時間と基本メモリーの占有量が増えてしまいます。これらの多くの内部アプリケーションはすべてのユーザーが必要なわけではないため、WebLogic Serverは、これらのアプリケーションをサーバーの起動時に常にデプロイするのではなく、最初のアクセス時に(必要なときに)待機およびデプロイするように更新されました。これにより、起動時間が短縮され、メモリー占有量が少なくなります。

内部アプリケーションのタイプ

2種類の異なるタイプの内部アプリケーションがあります。最初のタイプはユーザー・インタフェースを表示し、WebLogic Server管理コンソール、UDDIエクスプローラおよびWebLogic Serverテスト・クライアントを含みます。第2のタイプはユーザー・インタフェースを表示せず、デプロイメントおよび管理ファイル配布用に、UDDIならびに内部サーブレットを含みます。

ユーザー・インタフェース付きのアプリケーションのために、WebLogic Serverはオンデマンドのデプロイメントが進行中であることを示すステータス・ページを表示します。このページは2秒ごとにリフレッシュされます。内部のアプリケーションがデプロイメントを完了するとき、内部のアプリケーションにリダイレクトされます。このステータス・ページは、各アプリケーションの最初のアクセスで表示されます。以後の呼び出しで、アプリケーションをデプロイせず、内部のアプリケーションに対して直接ユーザー・インタフェースへ進みます。

オンデマンド・デプロイメントの構成

開発ドメインの場合、デフォルトでは内部アプリケーションがWebLogic Serverにより、オンデマンドでデプロイされます。本番モードドメインの場合、デフォルトでは内部アプリケーションがWebLogic Serverにより、サーバーのスタートアップとしてデプロイされます。デフォルトの動作は、Domain MBeanのInternalAppsDeployOnDemandEnabled属性を構成を変更すれば制御できます。構成設定は、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用すれば変更できます。

管理コンソールを使用したオンデマンド・デプロイメントの構成

WebLogic Server管理コンソールを使用してInternalAppsDeployOnDemandEnabled属性を変更するには、次の手順を実行します。

1. 「ロックして編集」ボタンで編集セッションを開始します。

2. ドメインを選択して、「構成」>「全般」ページを開きます。

3. 「内部アプリケーションのオンデマンド・デプロイメントを有効化」チェック・ボックスの設定を変更します。

4. 「変更」をクリックし、さらに「変更のアクティブ化」をクリックして、次回のWebLogic Serverの再起動で有効となるよう変更を保存します。

WLSTを使用したオンデマンド・デプロイメントの構成

WLSTを使用してInternalAppsDeployOnDemandEnabled属性を変更するには、次の手順を実行します。

connect()
edit()
startEdit()
cmo.setInternalAppsDeployOnDemandEnabled(false)
activate()

A weblogic.Deployerコマンド行リファレンス

この付録では、weblogic.Deployerユーティリティについて説明します。weblogic.Deployerは、WebLogic Server 12.1.3の管理者や開発者がデプロイメント操作をコマンド行で実行するためのJavaベースのデプロイメント・ツールです。

注意:
WebLogic Scripting Tool (WLST)を使用したデプロイメント操作の実行については、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

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

- weblogic.Deployerに必要な環境

- weblogic.Deployerを呼び出すための構文

- SSLの引数

- 接続の引数

- ユーザー資格証明の引数

- 共通の引数

- コマンドとオプション

- config.xmlファイルの例および対応するweblogic.Deployerコマンド

weblogic.Deployerに必要な環境

weblogic.Deployerユーティリティを使用するために環境を設定するには:

1. WebLogic Serverソフトウェアをインストールして構成します。詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

2. CLASSPATH環境変数にWebLogic Serverクラスを追加し、適切なJDKバイナリがPATHで使用可能になっていることを確認します。WebLogic Serverインストール・ディレクトリのserver/binサブディレクトリにあるsetWLSEnv.shまたはsetWLSEnv.cmdスクリプトを使用して、環境を設定できます。

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

3. 構成済の管理チャネルを介して管理サーバーに接続する場合は、weblogic.Deployerを実行するマシンでSSLを構成する必要があります。SSLを構成する手順は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

weblogic.Deployerを呼び出すための構文

java [SSL Arguments] weblogic.Deployer [Connection Arguments]
[User Credentials Arguments] COMMAND-NAME command-options
[Common Arguments]

コマンド名とオプションでは大文字と小文字は区別されません。weblogic.Deployerコマンドを使用するための詳細な構文と例については、「コマンドとオプション」を参照してください。

警告:
weblogic.Deployerコマンドを使用し、コマンド・ウィンドウまたはスクリプトで暗号化していないパスワードを入力すると、他人にのぞかれる恐れがあり、セキュリティ上危険です。安全にパスワードを入力する方法は、『Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護に関する項を参照してください。

SSLの引数

java [ -Dweblogic.security.TrustKeyStore=DemoTrust ]
[ -Dweblogic.security.JavaStandardTrustKeyStorePassPhrase=password ]
[ -Dweblogic.security.CustomTrustKeyStoreFileName=filename
-Dweblogic.security.TrustKeystoreType=jks
[-Dweblogic.security.CustomTrustKeyStorePassPhrase=password ]
]
[ -Dweblogic.security.SSL.hostnameVerifier=classname ]
[ -Dweblogic.security.SSL.ignoreHostnameVerification=true ]
weblogic.Deployer
[ User Credentials Arguments ]
COMMAND-NAME command-arguments

ドメイン全体の管理ポートを有効にしている場合、またはSSLで保護された他のリスニング・ポートを使用して管理リクエストを保護する場合は、weblogic.Deployerを呼び出すときにSSLの引数を含める必要があります。表A-1では、weblogic.DeployerユーティリティのすべてのSSLの引数について説明します。

表A-1 SSLの引数

引数

定義

-Dweblogic.security.TrustKeyStore=DemoTrust

weblogic.Deployerで、デモ用信頼キーストア(WL_HOME\server\lib\DemoTrust.jks)のCA証明書を信頼するようにします。

この引数は、接続先のサーバー・インスタンスがデモ用のIDと証明書を使用する場合は必須です。

デフォルトでは、weblogic.Deployerは、Java標準信頼キーストア(SDK_HOME\jre\lib\security\cacerts)のCA証明書のみを信頼します。

-Dweblogic.security.JavaStandardTrustKeyStorePassPhrase=password

Java標準信頼キーストアの保護に使用されたパスワード。

Java標準信頼キーストアがパスワードで保護されており、そのCA証明書を信頼する場合には、この引数を使用する必要があります。

デフォルトでは、Java標準信頼キーストアはパスワードで保護されていません。

-Dweblogic.security.CustomTrustKeyStoreFileName=filename
-Dweblogic.security.TrustKeystoreType=jks

weblogic.Deployerで、filenameにあるカスタム・キーストアのCA証明書を信頼するようにします。カスタム・キーストアを信頼するには、両方の引数を使用する必要があります。filenameはconfig.xmlに永続化されているServerMBean.CustomTrustKeyStoreFileName値と正確に一致する必要があります。CustomTrustKeyStoreFileName属性で指定された値が相対パス名の場合は、この引数でも同じ相対パス名を指定する必要があります。

-Dweblogic.security.CustomTrustKeyStorePassPhrase=password

カスタム・キーストアの保護に使用されたパスワード。

カスタム・キーストアがパスワードで保護されている場合にのみ、この引数を使用する必要があります。

-Dweblogic.security.SSL.hostnameVerifier=classname

カスタム・ホスト名検証クラスの名前。このクラスはweblogic.security.SSL.HostnameVerifierインタフェースを実装する必要があります。

-Dweblogic.security.SSL.ignoreHostnameVerification=true

ホスト名検証を無効にします。

接続引数

java [SSL Arguments] weblogic.Deployer
[-adminurl protocol://listen_address:port_number]
[User Credentials Arguments] COMMAND-NAME command-options [Common Arguments]

ほとんどのweblogic.Deployerコマンドでは、管理サーバー・インスタンスに接続するために、表A-2で説明する-adminurl引数を指定する必要があります。

表A-2 接続引数

引数

定義

-adminurl [protocol://]Admin-Server-listen-address:listen-port

管理サーバーのリスニング・アドレスとリスニング・ポート。

SSLで保護されていないポートを使用する場合の形式は-adminurl [protocol]Admin-Server-listen-address:port。有効なプロトコルはt3、http、iiop、およびiiops。

HTTPプロトコルでadminurlを使用するには、WebLogic Server管理コンソールでHTTPトンネリングのオプションを有効にする必要があります。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のHTTPトンネリングのためのWebLogic Serverの設定に関する項を参照してください。WebLogic Server管理コンソールでHTTPトンネリングを有効にする方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのHTTPプロトコルの構成に関する項を参照してください。

SSLで保護されているポートを使用する場合の形式は-adminurl secure-protocol://Admin-Server-listen-address:port。有効なセキュア・プロトコルはt3sおよびhttps。

構成済の管理チャネルを介して管理サーバーに接続するには、有効な管理ポートを次のように指定する必要があります。-adminurl secure-protocol://Admin-Server-listen-address:domain-wide-admin-port

この引数のデフォルト値はありません。

ユーザー資格証明の引数

java [ SSL Arguments ] weblogic.Deployer [Connection Arguments]
[ { -username username [-password password] } |
[ -userconfigfile config-file [-userkeyfile admin-key] ] ]
COMMAND-NAME command-options [Common Arguments]

ほとんどのweblogic.Deployerコマンドでは、WebLogic Server管理者のユーザー資格証明を指定する必要があります。

表A-3 ユーザー資格証明の引数

引数

定義

-username username

管理者のユーザー名。-usernameオプションを指定しても対応する-passwordオプションを指定しないと、weblogic.Deployerはパスワードを要求します。

-password password

管理者ユーザーのパスワード。

psなどのスクリプトやプロセス・ユーティリティで、パスワードがプレーン・テキストで表示されないようにするには、『WebLogic Server WLSTコマンド・リファレンス』で説明しているように、まずWebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用し、ユーザー名および暗号化したパスワードを構成ファイルに格納します。デフォルトの構成ファイルに保存している値を使用するように、weblogic.Deployerの-usernameおよび-passwordの両方のオプションを省略します。

デフォルト・ファイル以外で特定の構成ファイルおよびキー・ファイルを使用するには、weblogic.Deployerの-userconfigfileおよび-userkeyfileオプションを使用します。

-userconfigfile config-file

管理ユーザー名およびパスワード用に使用するユーザー構成ファイルのロケーションです。自動スクリプトまたは画面上にパスワードが表示させたくない場合、さらにpsのようなプロセス・レベルのユーティリティの場合、-userおよび-passwordオプションのかわりに、このオプションを使用します。-userconfigfile属性を指定する前に、『WebLogic Server WLSTコマンド・リファレンス』の説明に従い、WebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用してファイルを生成する必要があります。

-userkeyfile admin-key

ユーザー構成ファイル(-userconfigfileオプション)に保存しているユーザー名およびパスワード情報の暗号化・復号化び使用するユーザー・キー・ファイルのロケーションを指定します。-userkeyfile属性を指定する前に、『WebLogic Server WLSTコマンド・リファレンス』の説明に従い、WebLogic Scripting Tool (WLST)のstoreUserConfigコマンドを使用してファイルを生成する必要があります。

共通の引数

java [ SSL Arguments ] weblogic.Deployer [Connection Arguments]
[ { -username username [-password password] } |
[ -userconfigfile config-file [-userkeyfile admin-key] ] ]
COMMAND-NAME command-options [Common Arguments]

表A-4に示す共通の引数は、「コマンドとオプション」で説明するどのコマンドでも使用できます。

表A-4 weblogic.Deployerの共通の引数

引数名

説明

-advanced

weblogic.Deployerのすべてのアクションとオプションについて、詳細なコマンド行ヘルプ・テキストを出力します。

-debug

標準出力にデバッグ・メッセージを表示します。

-examples

一般的なタスクのコマンド行の例を表示します。

-help

よく使用するweblogic.Deployerのアクションとオプションについて、コマンド行ヘルプ・テキストを出力します。

-noexit

デフォルトでは、コマンドの処理中に例外が発生した場合、weblogic.DeployerはSystem.exit(1)を呼び出します。表示される終了値は、デプロイメント処理中に発生した障害の番号を示します。

-noexitオプションはバッチ処理の場合にこの動作をオーバーライドします。

-noversion

weblogic.Deployerが管理サーバーにあるバージョン関連のすべてのコード・パスを無視することを指定します。この動作は、デプロイメント・ソース・ファイルが(管理サーバーではなく)管理対象サーバーにあり、external_stageステージング・モードを使用する場合に役立ちます。

このオプションを使用する場合、バージョン指定されたアプリケーションは使用できません。

-nowait

weblogic.DeployerはタスクIDを出力し、アクションの完了を待たずに終了します。このオプションは複数のタスクを開始し、その後は-listアクションを使用してモニターします。

-output <raw | formatted>

(非推奨。)rawまたはformatted。weblogic.Deployerの出力メッセージの表示方法を制御します。両方の出力タイプに含まれる情報は同じですが、raw出力では埋め込みタブが使われません。デフォルトでは、weblogic.Deployerの表示はraw出力になります。

-remote

weblogic.Deployerが管理サーバーと同じマシンで動作していないこと、およびコマンドに指定するソース・パスが管理サーバー・マシン自体に対して有効であることを示します。-remoteオプションを使用しない場合、weblogic.Deployerはすべてのソース・パスをローカル・マシン上の有効なパスと想定します。

-timeout seconds

デプロイメント・タスクの完了までの最長待機時間(秒単位)。時間の経過後、weblogic.Deployerはデプロイメントの現在のステータスを出力して終了します。

-verbose

追加の進行状況メッセージ(デプロイメントの準備フェーズとアクティブ化フェーズについての詳細など)。

-version

weblogic.Deployerのバージョン情報を出力します。

コマンドとオプション

次の項では、WebLogic Serverでデプロイメント・タスクを実行するために使用するweblogic.Deployerコマンドとコマンド・オプションについて説明します。

- Cancel

- Deploy

- Distribute

- Listapps

- List、Listtask

- Purgetasks

- Redeploy

- Start

- Stop

- Undeploy

- Update

注意:
コマンド・オプションと区別するため、weblogic.Deployerコマンドは太字で示します。

Cancel

デプロイメント・タスクの実行を取り消そうとします。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-cancel task_id
[Common Arguments]

コマンドまたはオプション

定義

task_id

取り消すデプロイメント・タスクの識別子。識別子は、deploy、distribute、update、undeploy、redeploy、stop、およびstartコマンドでidオプションを使用して指定します。

例

以下のコマンドでは、デプロイメント処理を開始し、タスク識別子myDeploymentを指定します。

java weblogic.Deployer -adminurl http://localhost:7001
-username weblogic -password weblogic
-deploy ./myapp.ear -id myDeployment

デプロイメント・タスクがまだ完了していない場合、以下のコマンドはデプロイメント処理を取り消そうとします。

java weblogic.Deployer -adminurl http://localhost:7001
-username weblogic -password weblogic
-cancel -id myDeployment

Deploy

アプリケーションまたはモジュールをデプロイまたは再デプロイします。

注意:
deployの別名である-ACTIVATEコマンドは非推奨になりました。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-deploy [[-name] deployment_name] [-source] file
[-plan file] [-targets target_list] [-submoduletargets target_list]
[-upload]
[-stage | -nostage | -external_stage]
[-planstage | -plannostage | -planexternal_stage]
[-retiretimeout seconds]
[-library [-libspecver version] [-libimplver version]]
[-altappdd file] [-altwlsappdd file]
[-securityModel] [-enableSecurityValidation]
[-id task_id]
[Common Arguments]

コマンドまたはオプション

定義

-name deployment_name

新たにデプロイしたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名。
「構文」で示すように、-nameオプションとdeployment_name引数は両方とも省略可能です。deployコマンドでデプロイメント名を明示的に指定しない場合、名前は、指定されたデプロイメント・ファイルまたはディレクトリから次のように派生します。

- アーカイブ・ファイルの場合は、アーカイブ・ファイルの名前から拡張子を除いたものがデフォルト・デプロイメント名になります。たとえば、myear.earというファイルをデプロイする場合、デフォルトのデプロイメント名はmyearになります。

- 展開されたアーカイブ・ディレクトリの場合は、最上位ディレクトリの名前がデフォルト・デプロイメント名になります。

- アプリケーションのインストール・ルート・ディレクトリを指定する場合、デフォルト・デプロイメント名は、/appサブディレクトリ内のアーカイブ・ファイル名または展開されたアーカイブ・ディレクトリ名から派生します。

-source file

デプロイするアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリ。-sourceオプションを省略して、デプロイするファイルまたはディレクトリのみを指定できます。

-plan file

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

-targets target_list

アプリケーションまたはモジュールをデプロイするターゲット。
target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタにデプロイできます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

deployコマンドでターゲット・リストを指定しない場合、ターゲットのデフォルトは次のようになります。

- 新規デプロイメントの場合は管理サーバー・インスタンス。

- デプロイされているアプリケーションの場合はアプリケーションの現在のターゲット。

-submoduletargets target_list

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲット。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-upload

指定されたデプロイメント・ファイル(デプロイメント・プランと代替デプロイメント記述子も含む)を管理サーバーに転送します。このオプションは、リモート・マシンで作業している場合で、他の手段でデプロイメント・ファイルを管理サーバーにコピーできない場合に使用します。アプリケーション・ファイルは、配布およびデプロイメントの前にWebLogic Server管理サーバーのアップロード・ディレクトリにアップロードされます。

-stage | -nostage | -external_stage

アプリケーションをデプロイまたは配布するときに使用するステージング・モード。

- -stage: デプロイメント・ファイルをターゲット・サーバーのステージング・ディレクトリにコピーします。stageは、管理対象サーバーにデプロイまたは配布する場合に使用されるデフォルトのモード。

- -nostage - デプロイメント・ファイルはターゲット・サーバーにコピーされず、-sourceオプションで指定された固定の場所に残されます。ターゲット・サーバーは、デプロイメント・ファイルの同じコピーにアクセスします。nostageは、管理サーバーにデプロイまたは配布する場合(単一サーバー・ドメインなど)に使用されるデフォルト。

- -external_stage - デプロイメント・ファイルをターゲット・サーバーにコピーしません; かわりに、デプロイメント・ファイルがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。ファイルを手動でコピーしたり、サード・パーティのツールやスクリプトを使用したりできます。

「ステージング・モードによるデプロイメント・ファイルのコピーの制御」を参照してください。

-planstage | -plannostage | -planexternal_stage

アプリケーション・アーカイブとは別にデプロイメント・プランをデプロイまたは配布するときに使用するステージング・モード。

- -planstage: デプロイメント・プランをターゲット・サーバーのステージング・ディレクトリにコピーします。

- -plannostage: デプロイメント・プランをターゲット・サーバーにコピーせず、-planオプションで指定された所定の場所に配置します。

- -planexternal_stage: デプロイメント・プランをターゲット・サーバーにコピーしません。かわりに、デプロイメント・プランがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。デプロイメント・プランを手動でコピーしたり、サード・パーティのツールやスクリプトを使用することができます。

ステージング・モードが指定されていない場合は、デフォルトとしてアプリケーションのステージングに指定された値がデプロイメント・プランに使用されます。

-retiretimeout seconds

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをリタイアするまでの秒数。「アプリケーションの新しいバージョンの再デプロイ」を参照してください。

-library

共有Java EEライブラリまたはオプション・パッケージとしてのデプロイメント。Java EEライブラリまたはオプション・パッケージをデプロイまたは配布する場合は-libraryオプションを含める必要があります。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

-libspecver version

Java EEライブラリまたはオプション・パッケージの仕様のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに仕様のバージョンが含まれていない場合にのみ使用できます。-libversionは-libraryと一緒にしか使用できません。「WebLogic Serverでのライブラリの登録」を参照してください。

-libimplver version

Java EEライブラリまたはオプション・パッケージの実装のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに実装のバージョンが含まれていない場合にのみ使用できます。-libimplversionは-libraryと一緒にしか使用できません。「WebLogic Serverでのライブラリの登録」を参照してください。

-usenonexclusivelock

同じユーザーがドメインですでに取得している既存のロックを、デプロイメント処理で使用することを指定します。複数のデプロイメント・ツールを同時に使用していて、いずれかのツールでドメイン構成のロックをすでに取得している場合に便利。

-altappdd file

(非推奨。)デプロイメントに使用する代替Java EEデプロイメント記述子(application.xml)の名前。

-altwlsappdd file

(非推奨。)デプロイメントに使用する代替WebLogic Serverデプロイメント記述子(weblogic-application.xml)の名前。

-securityModel
[ DDOnly | CustomRoles |
CustomRolesAndPolicies |
Advanced ]

このデプロイメントで使用するセキュリティ・モデル。

-enableSecurityValidation

セキュリティ・データの検証を有効にします。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。distribute、deploy、redeploy、start、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

-deployコマンドの使用例については、次の項を参照してください。

- 単一サーバー・ドメインへのデプロイ

- デプロイメント・プランによるアプリケーションのデプロイ

- リモート・クライアントからのデプロイメント・ファイルのアップロード

- 1つまたは複数のターゲットへのデプロイ

- クラスタ・ターゲットへのデプロイ

- モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ

- アプリケーション・スコープのJMS、JDBC、およびWLDFモジュールのターゲット指定

- JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用

- nostageモードのデプロイメントの使用

- stageモードのデプロイメントの使用

- external_stageモードのデプロイメントの使用

- 本番環境へのアプリケーションの配布

- WebLogic Serverでのライブラリの登録

- ライブラリを参照するアプリケーションのデプロイ

Distribute

デプロイメント・ファイルをターゲット・サーバーにコピーして検証することで、デプロイメント用に準備します。

配布されたアプリケーションは、Startコマンドを使用して素早く起動できます。アプリケーションは、管理モードで起動することも、管理およびクライアント・リクエストに対応可能にすることもできます。管理モードの間、アプリケーションは、構成済の管理ポート経由で内部クライアントからのみアクセスできます。外部クライアントはアプリケーションにアクセスできなくなります。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-distribute [[-name] deployment_name] [-source] file
[-plan file] [-targets target_list] [-submoduletargets target_list]
[-upload]
[-stage | -nostage | -external_stage]
[-planstage | -plannostage | -planexternal_stage]
[-library [-libspecver version] [-libimplver version]]
[-altappdd file] [-altwlsappdd file]
[-securityModel] [-enableSecurityValidation]
[-id task_id]
[Common Arguments]

コマンドまたはオプション

定義

-name deployment_name

配布されるアプリケーションまたはモジュールに割り当てるデプロイメント名。
「構文」で示すように、-nameオプションとdeployment_name引数は両方とも省略可能です。デプロイメント名を明示的に指定しない場合、名前は、指定されたデプロイメント・ファイルまたはディレクトリから次のように派生します。

- アーカイブ・ファイルの場合は、アーカイブ・ファイルの名前から拡張子を除いたものがデフォルト・デプロイメント名になります(myear.earというファイルの場合はmyear)。

- 展開されたアーカイブ・ディレクトリの場合は、最上位ディレクトリの名前がデフォルト・デプロイメント名になります。

- アプリケーションのインストール・ルート・ディレクトリを指定する場合、デフォルト・デプロイメント名は、/appサブディレクトリ内のアーカイブ・ファイル名または展開されたアーカイブ・ディレクトリ名から派生します。

-source file

配布するアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリ。-sourceオプションを省略して、ファイルまたはディレクトリのみを指定できます。

-plan file

アプリケーションまたはモジュールと一緒に配布するデプロイメント・プラン(アプリケーションの構成に使用するプラン)。

-targets target_list

アプリケーションまたはモジュールを配布するターゲット。
target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタに配布できます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

distributeコマンドでターゲット・リストを指定しない場合、ターゲットのデフォルトは次のようになります。

- 新規デプロイメントの場合は管理サーバー・インスタンス。

- デプロイされているアプリケーションの場合はアプリケーションの現在のターゲット。

-submoduletargets target_list

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲット。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-upload

配布の前に指定したデプロイメント・プランを含め、指定したデプロイメント・ファイルを管理サーバーに転送します。このオプションは、リモート・マシンで作業している場合で、他の手段でデプロイメント・ファイルを管理サーバーにコピーできない場合に使用します。配布の前にアプリケーション・ファイルは、WebLogic Server管理サーバーのアップロード・ディレクトリにアップロードされます。

-stage | -nostage | -external_stage

アプリケーションをデプロイまたは配布するときに使用するステージング・モード。

- -stage - デプロイメント・ファイルを対象サーバーのステージング・ディレクトリにコピーします。stageは、管理対象サーバーにデプロイまたは配布する場合に使用されるデフォルトのモード。

- -nostage - デプロイメント・ファイルはターゲット・サーバーにコピーされず、-sourceオプションで指定された固定の場所に残されます。ターゲット・サーバーは、デプロイメント・ファイルの同じコピーにアクセスします。nostageは、管理サーバーにデプロイまたは配布する場合(単一サーバー・ドメインなど)に使用されるデフォルト。

- -external_stage - デプロイメント・ファイルをターゲット・サーバーにコピーしません; かわりに、デプロイメント・ファイルがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。ファイルを手動でコピーしたり、サード・パーティのツールやスクリプトを使用したりできます。

「ステージング・モードによるデプロイメント・ファイルのコピーの制御」を参照してください。

-planstage | -plannostage | -planexternal_stage

アプリケーション・アーカイブとは別にデプロイメント・プランをデプロイまたは配布するときに使用するステージング・モード。

- -planstage: デプロイメント・プランをターゲット・サーバーのステージング・ディレクトリにコピーします。

- -plannostage: デプロイメント・プランをターゲット・サーバーにコピーせず、-planオプションで指定された所定の場所に配置します。

- -planexternal_stage: デプロイメント・プランをターゲット・サーバーにコピーしません。かわりに、デプロイメント・プランがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。デプロイメント・プランを手動でコピーしたり、サード・パーティのツールやスクリプトを使用することができます。

ステージング・モードが指定されていない場合は、デフォルトとしてアプリケーションのステージングに指定された値がデプロイメント・プランに使用されます。

-library

デプロイメントを共有Java EEライブラリまたはオプション・パッケージとして指定します。Java EEライブラリまたはオプション・パッケージをデプロイまたは配布する場合は-libraryオプションを含める必要があります。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

-libspecver version

Java EEライブラリまたはオプション・パッケージの仕様のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに仕様のバージョンが含まれていない場合にのみ使用できます。-libversionは-libraryと一緒にしか使用できません。「WebLogic Serverでのライブラリの登録」を参照してください。

-libimplver version

Java EEライブラリまたはオプション・パッケージの実装のバージョン。このオプションは、ライブラリまたはパッケージのマニフェスト・ファイルに実装のバージョンが含まれていない場合にのみ使用できます。-libimplversionは-libraryと一緒にしか使用できません。「WebLogic Serverでのライブラリの登録」を参照してください。

-altappdd file

(非推奨。)デプロイメントまたは配布に使用する代替Java EEデプロイメント記述子(application.xml)の名前。

-altwlsappdd file

(非推奨。)デプロイメントまたは配布に使用する代替WebLogic Serverデプロイメント記述子(weblogic-application.xml)の名前。

-securityModel
[ DDOnly |
CustomRoles |
CustomRolesAndPolicies |
Advanced ]

このアプリケーションで使用されるセキュリティ・モデル。

-enableSecurityValidation

セキュリティ・データの検証を有効にします。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。distribute、deploy、redeploy、start、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

distributeコマンドはdeployと同じように動作しますが、WebLogic Serverはターゲット・サーバー上でアプリケーションまたはモジュールを起動しません。詳細は、Deployコマンドの例に関するリンクを参照してください。

Listapps

ドメインにデプロイ、配布、またはインストールされているアプリケーションおよびスタンドアロン・モジュールのデプロイメント名をリストします。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-listapps
[Common Arguments]

コマンドまたはオプション

定義

-listapps

ドメインにデプロイ、配布、またはインストールされているアプリケーションおよびスタンドアロン・モジュールのデプロイメント名をリストします。

例

「デプロイされたアプリケーションのバージョン情報の表示」を参照してください。

List、Listtask

ドメインで現在実行中のデプロイメント・タスクのステータスを表示します。

構文

java [SSL Arguments] weblogic.Deployer Connection Arguments
[User Credentials Arguments] <-list | -listtask> [task_id]
[Common Arguments]

コマンドまたはオプション

定義

task_id

表示するデプロイメント・タスクの識別子。

例

「長時間かかるデプロイメント・タスクの管理」を参照してください。

Purgetasks

weblogic.Deployerがリタイアされたデプロイメント・タスクをフラッシュすることを指定します。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-purgetasks

例

次のコマンドでは、weblogic.Deployerがリタイアされたデプロイメント・タスクをフラッシュすることを指定します。

java weblogic.Deployer -username
weblogic -password ... -adminurl t3://localhost:7001 -purgetasks
:
:
weblogic.Deployer invoked with options:-username weblogic -adminurl
t3://localhost:7001 -purgetasks
Currently there are no retired tasks.

Redeploy

実行中のアプリケーションまたは実行中のアプリケーションの一部を再デプロイします。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-redeploy [[-name] deployment_name] [-plan file]
[-targets target_list] [-submoduletargets target_list]
[-upload]
[-delete_files]
[-retiretimeout seconds] [-id task_id]
[-rmiGracePeriod seconds]
[Common Arguments]

コマンドまたはオプション

定義

-name deployment_name

デプロイされるアプリケーションまたはモジュールのデプロイメント名。-nameオプションは省略可能です。省略した場合、-source file引数から名前が取られます。

-source file

配布、デプロイ、または再デプロイするアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリ。
redeployコマンドと一緒に使用する場合、-sourceオプションでは、再デプロイする新しいデプロイメント・ファイルの場所を指定します(アプリケーションを新しいバージョンに更新する場合、または以前デプロイ済のバージョンにロールバックする場合など)。

注: 元の場所を変更した場合は、バージョン管理されていないアプリケーションまたはバージョン管理された既存のアプリケーションに対して、redeploy -sourceオプションを指定しないでください。その場合、まずアプリケーションのデプロイを解除してから、デプロイしなおす必要があります。

部分的な再デプロイメント用に複数のファイルを指定するには、-sourceオプションを省略してfilelistのみを指定します。

注意: エンタープライズ・アプリケーション内のJava EEモジュール全体を再デプロイするには、「Java EEモジュール更新のための部分的な再デプロイメントの使用」で説明しているモジュール・ターゲット指定構文-targets module@targetを使用します。

-plan file

配布、デプロイ、または再デプロイ時に使用するデプロイメント・プラン。
アプリケーションを再デプロイするときに、-planオプションを使用すると、再デプロイメント時に使用する更新済みの構成を指定できます。改訂されたデプロイメント・プランにリソース・バインドの変更が含まれている場合、WebLogic Serverは古いバージョンと並行して、アプリケーションの新しいバージョンを再デプロイしようとします。「アプリケーションのデプロイメント構成の更新」を参照してください。

-targets target_list

アプリケーションまたはモジュールを再デプロイするターゲット。
target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタに再デプロイできます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

注意: エンタープライズ・アプリケーション内のJava EEモジュール全体を再デプロイするには、「Java EEモジュール更新のための部分的な再デプロイメントの使用」で説明しているモジュール・ターゲット指定構文-targets module@targetを使用します。

redeployコマンドでターゲット・リストを指定しない場合、ターゲットのデフォルトは次のようになります。

- 新規デプロイメントの場合は管理サーバー・インスタンス。

- デプロイされているアプリケーションの場合はアプリケーションの現在のターゲット。

redeployコマンドと一緒にターゲット・リストを指定しない場合、アプリケーションは現在のすべてのターゲット・サーバーに再デプロイされます。

-submoduletargets target_list

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲット。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-upload

指定されたデプロイメント・ファイル(デプロイメント・プランと代替デプロイメント記述子も含む)を管理サーバーに転送します。このオプションは、リモート・マシンで作業している場合で、他の手段でデプロイメント・ファイルを管理サーバーにコピーできない場合に使用します。アプリケーション・ファイルは、配布およびデプロイメントの前にWebLogic Server管理サーバーのアップロード・ディレクトリにアップロードされます。

-delete_files

サーバーのステージング・ディレクトリから静的ファイルを削除します。delete_filesは、アーカイブされていないデプロイメント、および-stageモードを使用してデプロイされたアプリケーションでのみ有効です。このオプションを使用するときには、次の例のようにターゲット・サーバーを指定する必要があります。

java weblogic.Deployer -adminurl http://myserver:7001 -username weblogic
-password weblogic -name myapp
-targets myapp@myserver -redeploy
-delete_files myapp/tempindex.html

delete_filesは、デプロイメント時にステージング領域にコピーされたファイルのみを削除します。-nostageまたは-external_stageモードを使用してデプロイされたアプリケーションでdelete_filesオプションを使用した場合、ファイルは削除されません。

注意 : delete_filesは、redeployコマンドと一緒にしか使用できません。

-delete_filesオプションでは、指定されたすべてのファイル(ディレクトリを指定してディレクトリ内のファイルを指定していない場合は、指定されたディレクトリ内のすべてのファイル)が削除されるため、delete_filesオプションは慎重に使用し、本番環境ではdelete_filesオプションを使用しないことをお薦めします。

-retiretimeout seconds

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをリタイアするまでの秒数。「アプリケーションの新しいバージョンの再デプロイ」を参照してください。

-rmiGracePeriod seconds

正常停止またはリタイアの際にRMIの猶予期間内でRMIリクエストの受信がなくなるまで、ワーク・マネージャがRMI呼出しを受け付けてスケジューリングする時間(秒単位)。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。deploy、redeploy、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

redeployコマンドの使用例については、次の項を参照してください。

- アプリケーションの新しいバージョンの再デプロイ

- 本番再デプロイメント・プロセスのロールバック

- アプリケーションの新しいバージョンを配布する手順

- インプレースでのアプリケーションおよびモジュールの再デプロイ

- Java EEモジュールを更新するための部分的な再デプロイメントの使用

- デプロイされたアプリケーションにおける静的ファイルの更新

Start

ターゲット・サーバーで停止している(非アクティブな)アプリケーションをクライアントから使用できるようにします。startコマンドでは、デプロイメント・ファイルをターゲット・サーバーに再配布しません。adminmodeオプションを指定してアプリケーションを管理モードで起動すると、アプリケーションは構成済の管理チャネル経由でのみ使用できるようになります。startコマンドを発行するには、それ以前にdeployまたはdistributeコマンドを通じて、ファイルがすでに使用可能になっている必要があります。

注意:
startの別名であるactivateコマンドは非推奨になりました。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-start [-adminmode] [-name] deployment_name
[-appversion version] [-planversion version]
[-targets target_list] [-submoduletargets target_list]
[-retiretimeout seconds]
[-id task_id]
[Common Arguments]

コマンドまたはオプション

定義

-adminmode

アプリケーションを本番モード(デフォルト)ではなく管理モードで起動します。

-name deployment_name

デプロイされるアプリケーションまたはモジュールのデプロイメント名。nameオプションは省略できます。省略した場合は、deployment_nameから直接名前が取られます。(deployment_nameでファイル名またはディレクトリ名を指定している場合、デプロイメント名は指定されているファイル名から派生します。)

-appversion version

起動するアプリケーションのバージョン。

-planversion version

アプリケーションの起動時に使用するデプロイメント・プランのバージョン。

-targets target_list

アプリケーションまたはモジュールを起動するターゲット。
target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタで起動できます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

startコマンドでターゲット・リストを指定しない場合、ターゲットのデフォルトは次のようになります。

- 新規デプロイメントの場合は管理サーバー・インスタンス。

- デプロイされているアプリケーションの場合はアプリケーションの現在のターゲット。

startコマンドでターゲット・リストを指定しない場合は、アプリケーションの現在のすべてのターゲットでコマンドが実行されます。

-submoduletargets target_list

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲット。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-retiretimeout seconds

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをリタイアするまでの秒数。「アプリケーションの新しいバージョンの再デプロイ」を参照してください。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。distribute、deploy、redeploy、start、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

startコマンドの使用例については次の項を参照してください。

- 配布されたアプリケーションの起動

- アプリケーションをクライアントで使用できるようにする方法

- アプリケーションの停止によるクライアント・アクセスの制限

Stop

アプリケーションを非アクティブにして、管理およびクライアント・リクエストに対応できないようにします。アプリケーションのステージングされたファイルはすべて、ターゲット・サーバー上で以降のstart、deploy、redeploy、またはundeployの各アクションに使用できる状態になっています。必要に応じ、adminmodeオプションでアプリケーションを管理モードにして、クライアント・リクエストでアプリケーションを使用できなくすることもできます。管理モードの間、アプリケーションは構成済の管理チャネル経由でのみアクセス可能になります。

注意:
stopの別名であるdeactivateコマンドは非推奨になりました。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-stop [-adminmode] [-name] deployment_name
[-appversion version] [-planversion version]
[-targets target_list] [-submoduletargets target_list]
[-ignoresessions] [-graceful] [-rmiGracePeriod seconds]
[-id task_id]
[Common Arguments]

引数またはオプション

定義

-adminmode

実行中のアプリケーションを管理モードに切り替えて、構成済の管理チャネル経由で管理リクエストのみを受け付けることを指定します。このオプションを指定しない場合、実行中のアプリケーションは停止されて、再起動するまで管理リクエストもクライアント・リクエストも受け付けなくなります。

-name deployment_name

デプロイされるアプリケーションまたはモジュールのデプロイメント名。nameオプションは省略できます。省略した場合は、deployment_nameから直接名前が取られます。(deployment_nameでファイル名またはディレクトリ名を指定している場合、デプロイメント名は指定されているファイル名から派生します。)

-appversion version

デプロイされているアプリケーションのバージョン識別子。

-planversion version

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

-targets target_list

アプリケーションまたはモジュールを停止するターゲット。
target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタで停止できます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

stopコマンドでターゲット・リストを指定しない場合、ターゲットのデフォルトは次のようになります。

- 新規デプロイメントの場合は管理サーバー・インスタンス。

- デプロイされているアプリケーションの場合はアプリケーションの現在のターゲット。

stopコマンドでターゲット・リストを指定しない場合は、アプリケーションの現在のすべてのターゲットでコマンドが実行されます。

-submoduletargets target_list

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲット。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-graceful

既存のHTTPクライアントが作業を完了した後でアプリケーションを停止します。-gracefulオプションを指定しない場合、WebLogic Serverはアプリケーションまたはモジュールをただちに停止します。「本番アプリケーションのオフライン」を参照してください。

-rmiGracePeriod seconds

正常停止またはリタイアの際にRMIの猶予期間内でRMIリクエストの受信がなくなるまで、ワーク・マネージャがRMI呼出しを受け付けてスケジューリングする時間(秒単位)。

-ignoresessions

現在のHTTPセッションが完了するのを待機せずに、アプリケーションをただちに管理モードにします。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。distribute、deploy、redeploy、start、stop、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

「アプリケーションの停止によるクライアント・アクセスの制限」を参照してください。

Undeploy

デプロイメント・ユニットを停止して、ステージングされているファイルをターゲット・サーバーから削除します。

注意:
undeployの別名であるREMOVEコマンドは非推奨になりました。

警告:
アプリケーション・スコープのリソースを含むアプリケーションをアンデプロイすると、そのリソースはアプリケーションと一緒に削除されます。そのため、JMS宛先の削除が原因で、トランザクションが破棄されたり、メッセージが失われたりする可能性があります。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のリソース登録解除の猶予期間に関する項を参照してください。
完全に削除するつもりのアプリケーションのみをアンデプロイするようにしてください。アプリケーションへのクライアント・アクセスを一時的に停止する場合は、かわりにstopコマンドを使用します。詳細は、「Stop」を参照してください。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-undeploy [-name] deployment_name
[-appversion version] [-planversion version]
[-targets target_list] [-submoduletargets target_list]
[-graceful] [-ignoresessions] [-rmiGracePeriod seconds]
[-id task_id]
[Common Arguments]

コマンドまたはオプション

定義

-name deployment_name

デプロイされるアプリケーションまたはモジュールのデプロイメント名。nameオプションは省略できます。省略した場合は、deployment_nameから直接名前が取られます。(deployment_nameでファイル名またはディレクトリ名を指定している場合、デプロイメント名は指定されているファイル名から派生します。)

-appversion version

デプロイされているアプリケーションのバージョン識別子。

-planversion version

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

-targets target_list

アプリケーションまたはモジュールをアンデプロイするターゲット。
注意 :ターゲット・リストに含まれていないターゲットは削除されません。

target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタからアンデプロイできます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

-submoduletargets target_list

アンデプロイするJMSリソース。
注意 :ターゲット・リストに含まれていないサブモジュール・ターゲットは削除されません。

『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-graceful

既存のHTTPクライアントが作業を完了した後でアプリケーションを停止します。-gracefulオプションを指定しない場合、WebLogic Serverはアプリケーションまたはモジュールをただちに停止します。「本番アプリケーションのオフライン」を参照してください。
モジュールは停止後にアンデプロイされます。

-rmiGracePeriod seconds

正常停止またはリタイアの際にRMIの猶予期間内でRMIリクエストの受信がなくなるまで、ワーク・マネージャがRMI呼出しを受け付けてスケジューリングする時間(秒単位)。

-ignoresessions

現在のHTTPセッションが完了するのを待機せずに、アプリケーションをただちに停止してアンデプロイします。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。distribute、deploy、redeploy、start、stop、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

undeployコマンドの使用例については、次の項を参照してください。

- アプリケーションまたはモジュールのアンデプロイ

- スタンドアロンJMSモジュールのサブモジュール・ターゲット

Update

プラン・ファイルを再配布して、新しいプランの内容に基づいてアプリケーションを再構成することで、アプリケーションのデプロイメント・プランを更新します。

注意:
updateを使用してアプリケーションのリソース・バインドを更新することはできません。アプリケーションのリソース・バインドを更新するには、Redeployコマンドを使用する必要があります。

構文

java [SSL Arguments] weblogic.Deployer
Connection Arguments [User Credentials Arguments]
-update -plan deployment_plan [-name] deployment_name
[-appversion version] [-planversion version]
[-targets target_list] [-submoduletargets target_list]
[-upload] [-id task_id]
[Common Arguments]

引数またはオプション

定義

-plan deployment_plan

アプリケーションの構成の更新に使用するデプロイメント・プラン。指定されたデプロイメント・プランはアプリケーションのターゲット・サーバーで有効でなければなりません。たとえば、リソースが関連する記述子で以前に定義されていない限り、プランでは必要なリソースにnullの変数を指定できません。
更新処理では、デプロイメント・プランで変更されている(nullではない)値に対応する記述子のみを更新します。更新処理に使用されるプランにnull変数が含まれている場合、対応する記述子の現在の値は更新されません。

-name deployment_name

デプロイされるアプリケーションまたはモジュールのデプロイメント名。nameオプションは省略できます。省略した場合は、deployment_nameから直接名前が取られます。(deployment_nameでファイル名またはディレクトリ名を指定している場合、デプロイメント名は指定されているファイル名から派生します。)

-appversion version

デプロイされているアプリケーションのバージョン識別子。

-planversion version

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

-targets target_list

アプリケーションまたはモジュールを更新するターゲット。
target_list引数は、ターゲット・サーバー、クラスタまたは仮想ホストのカンマ区切りのリストです。各ターゲットはJava EEモジュール名で修飾できます(<module1>@<server1>)。こうすればエンタープライズ・アプリケーションの別々のモジュールを、別々のサーバーまたはクラスタで更新できます。詳細は、「モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ」を参照してください。

updateコマンドでターゲット・リストを指定しない場合、ターゲットのデフォルトは次のようになります。

- 新規デプロイメントの場合は管理サーバー・インスタンス。

- デプロイされているアプリケーションの場合はアプリケーションの現在のターゲット。

updateコマンドでターゲット・リストを指定しない場合は、アプリケーションの現在のすべてのターゲットでコマンドが実行されます。

-submoduletargets target_list

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲット。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

-upload

アプリケーションを更新する前に、新しいデプロイメント・プランを管理サーバーにアップロードします。

-id task_id

実行中のデプロイメント・タスクのタスク識別子。distribute、deploy、redeploy、update、start、stop、またはundeployコマンドで識別子を指定できます。その後で、cancelまたはlistコマンドの引数として使用できます。識別子が実行中の他のデプロイメント・タスクすべてを通して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

例

「別のデプロイメント・プランを使用するためのアプリケーションの更新」を参照してください。

config.xmlファイルの例および対応するweblogic.Deployerコマンド

この項では、アプリケーションのconfig.xmlファイルと、アプリケーションをデプロイするための対応するweblogic.Deployerコマンドを例示します。

次のように想定した場合、

- myclusterはクラスタ名

- D1C2S1とD1C2S2はサーバー名

- RemoteJMSServer1とRemoteJMSServer2はJMSサーバー名

アプリケーションのconfig.xmlファイルには次の内容が含まれます。

<AppDeployment
Name="dd-remote-cluster"
SourcePath="./udd-debug-deployment-on-remote-cluster-jms.xml"
Targets="mycluster">
<SubDeployment Name="RemoteCluster" Targets="mycluster"/>
<SubDeployment Name="D1C2S2" Targets="D1C2S2"/>
<SubDeployment Name="RemoteClusterServers" Targets="D1C2S1,D1C2S2"/>
<SubDeployment Name="RemoteClusterJMSServers"
Targets="RemoteJMSServer1,RemoteJMSServer2"/>
<SubDeployment Name="RemoteQueue1" Targets="RemoteJMSServer1"/>
</AppDeployment>

アプリケーションをデプロイするweblogic.Deployer -deployコマンドは次のようになります。

java weblogic.Deployer -adminurl t3://MySystem:10000 -username system
-password system -name dd-remote-cluster
-deploy "config\jms\udd-debug-deployment-on-remote-cluster-jms.xml"
-targets mycluster -submoduletargets RemoteCluster@mycluster,
D1C2S2@D1C2S2, RemoteClusterServers@D1C2S1,
RemoteClusterServers@D1C2S2, RemoteClusterJMSServers@RemoteJMSServer1,
RemoteClusterJMSServers@RemoteJMSServer2, RemoteQueue1@RemoteJMSServer1

B weblogic.PlanGeneratorコマンド行リファレンス

この付録では、weblogic.PlanGeneratorユーティリティの使用方法について説明します。weblogic.PlanGeneratorは、WebLogic Server 12.1.3デプロイメント構成の各部分をデプロイメント・プランにエクスポートする開発者向けに設計されたJavaベースのデプロイメント構成ツールです。

注意:
WebLogic Scripting Tool (WLST)を使用したデプロイメント構成操作の実行については、『WebLogic Scripting Toolの理解』も参照してください。

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

- weblogic.PlanGeneratorの概要

- weblogic.PlanGeneratorに必要な環境

- weblogic.PlanGeneratorを呼び出すための構文

- 一般的なweblogic.PlanGeneratorタスク

weblogic.PlanGeneratorの概要

weblogic.PlanGeneratorは、アプリケーションまたはスタンドアロン・モジュールのWebLogic Serverデプロイメント構成ファイルを生成します。weblogic.PlanGeneratorには、2つのプライマリな機能があります。

- 様々なカテゴリのWebLogic Serverデプロイメント記述子プロパティを、テンプレート・デプロイメント・プランの空(null)の変数にエクスポートします。必要に応じて、構成エクスポート・セッションへの入力に既存のデプロイメント・プランを使用することができます。テンプレート・プランは一般に、さらに変更を加えてからでなければ使用できません。「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。

- Java EEアプリケーションから単純な初期デプロイメント・プランを生成します。詳細は、「weblogic.PlanGeneratorを使用したテンプレート・デプロイメント・プランの生成」を参照してください。

デフォルトでは、weblogic.PlanGeneratorはアプリケーションのデプロイメント・プランをアプリケーションのルート・ディレクトリにあるplan.xmlという名前のファイルに書き込みます。アプリケーションがアプリケーションのルート・ディレクトリにない場合、weblogic.PlanGeneratorはplan.xmlを<your_dir>/config/deployments/<user>/<application_name>/planに書き込みます。各文字列の意味は以下のとおりです。

- your_dirは、プロパティjava.io.tmpdirで指定されている場合は、TEMPディレクトリ。プロパティjava.io.tmpdirが指定されていなければ、your_dirはWebLogic Serverのドメイン・ディレクトリです。

- userはユーザー名。

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

weblogic.PlanGeneratorに必要な環境

weblogic.PlanGeneratorユーティリティを使用するように環境を設定するには:

1. WebLogic Serverソフトウェアをインストールして構成します。詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

2. CLASSPATH環境変数にWebLogic Serverクラスを追加し、適切なJDKバイナリがPATHで使用可能になっていることを確認します。WebLogic Serverインストール・ディレクトリのserver/binサブディレクトリにあるsetWLSEnv.shまたはsetWLSEnv.cmdスクリプトを使用して、環境を設定できます。

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

weblogic.PlanGeneratorを呼び出すための構文

java weblogic.PlanGenerator [Options] [filespec]

filespecとしては、次のいずれかを指定できます。

- アーカイブ・ファイルへのフルパスまたは相対パス

- 展開されたアーカイブ・ディレクトリへのフルパスまたは相対パス

以下のことをお薦めします。

- アプリケーションをインストール・ルート・ディレクトリに格納します。

- weblogic.PlanGeneratorコマンド発行時に、「オプション」で説明する-rootオプションを付けてアプリケーションのインストール・ルート・ディレクトリを指定すること。

すべての場合において、filespecで識別されるアプリケーションには、有効なJava EEデプロイメント記述子ファイルが含まれている必要があります。

アプリケーション・ルート・ディレクトリを-rootオプションで指定しなかった場合、またはデプロイメント・プランのパスおよび名前を-planオプションで指定しなかった場合、デフォルトではweblogic.PlanGeneratorはアプリケーションのデプロイメント・プランをアプリケーションのルート・ディレクトリにあるplan.xmlという名前のファイルに書き込みます。アプリケーションのルート・ディレクトリが見つからない場合、weblogic.PlanGeneratorはplan.xmlを<your_dir>/config/deployments/<user>/<application_name>/planに書き込みます。各文字列の意味は次のとおりです。

- your_dirは、プロパティjava.io.tmpdirで指定されている場合は、TEMPディレクトリ。プロパティjava.io.tmpdirが指定されていなければ、your_dirはWebLogic Serverのドメイン・ディレクトリです。

- userはユーザー名。

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

オプション

次の表では、各weblogic.PlanGeneratorオプションを説明します。

表B-1 weblogic.PlanGeneratorのオプション

オプション

説明

-debug

デバッグ・モードを有効化します。

-plan plan_file

構成セッションのために作成するプラン・ファイルのパスおよび名前を識別します。

-useplan plan_file

初期化を行う既存のデプロイメント・プラン・ファイル。アプリケーションのルート・ディレクトリの指定に-rootを使用する場合、weblogic.PlanGeneratorは入力としてルート・ディレクトリ内の/plan/plan.xmlファイルがあればそれを使用します。それ以外の場合、weblogic.PlanGeneratorはrootディレクトリ内にプランを作成します。

weblogic.PlanGeneratorは、さらなるエクスポートされたプロパティを入力プランに追加します。すでに入力プラン内に存在したエクスポート済みプロパティは、すべて保持されます。

-root root_directory

プランの生成またはエクスポートを実行するアプリケーション・ルート・ディレクトリ。

category。categoryの有効な値は次のとおりです。

- -all

- -any

- -configurables

- -dependencies

- -declarations

- -dynamics

- -none

- -standard

様々なカテゴリのデプロイメント構成プロパティのためのテンプレート・デプロイメント・プラン内にnull変数定義を生成します。

- all - 編集可能なすべてのプロパティをエクスポートするプランを作成します。

- any - すべてのプロパティをエクスポートするプランを作成します。

- configurables - dependenciesおよびdeclarations以外の編集可能なすべてのプロパティをエクスポートするプランを作成します。

- dependencies - 外部リソース参照を解決するすべてのWebLogic Server記述子プロパティをエクスポートするプランを作成します。これがデフォルト値です。

- declarations - 他のアプリケーションおよびモジュールに対してリソースを宣言するすべてのプロパティをエクスポートするプランを作成します。

- dynamics - アプリケーションを再デプロイしなくても実行時に変更できるすべてのプロパティをエクスポートするプランを作成します。

- none - プロパティをエクスポートしないプランを作成します。

- standard - 標準の記述子を含むプランを作成します。

-variables [global | unique]

デプロイメント・プラン内に作成された変数名が、アプリケーションのすべてのモジュールにまたがって使用可能なのか、それとも特定のモジュール内でのみ使用可能なのかを指定します。たとえばロールの割当ては、EAR全体に適用される場合と、EAR内の単一のWebアプリケーションまたは他のモジュールにのみ適用される場合があります。デフォルトでは、PlanGeneratorはアプリケーション全体に適用されるグローバル変数を作成します。

-noexit

終了ではなく例外が発生します。

-module module_name

モジュールのみに対するプランを作成します。

-library </mylibs/lib.ear@name=mylib, /mylibs/lib2.ear@name=otherlib@libspecver=1@libimplver=2>

マージするライブラリをカンマ区切りで指定します。

-librarydir library_directory

マージするライブラリのディレクトリの場所です。

一般的なweblogic.PlanGeneratorタスク

次の項では、一般的な構成およびエクスポートのタスクを、weblogic.PlanGenerator構文の例とともに説明します。

アプリケーションのルート・ディレクトリにおける初期状態のデプロイメント・プランの作成

インストール・ルート・ディレクトリを使用してアプリケーションを格納する場合、ルート・ディレクトリを-rootオプションで指定していると、生成されたデプロイメント・プラン・ファイルは、ルート・ディレクトリのplanサブディレクトリに自動的に格納されます。

java weblogic.PlanGenerator -root /appRelease/MyApplication

上の例では、plan.xmlファイルは自動的に/appRelease/MyApplication/planに格納されます。

既存のプランに基づく新しいデプロイメント・プランの作成

次のコマンドでは、既存のプランを入力として使用し、アプリケーション・ルート・ディレクトリの/planサブディレクトリに新しいプランを生成します。

java weblogic.PlanGenerator -useplan /plans/MyApplication_template.xml
-root /appRelease/MyApplication

デプロイメント・プランへエクスポートされるコンポーネントの制御

テンプレート・デプロイメント・プランへエクスポートされるWebLogic Serverデプロイメント記述子コンポーネントの指定には、-all、-configurables、-dependencies、-declarations、-dynamics、および-noneの各オプションを使用できます。次のコマンドでは、構成可能なすべてのプロパティを、テンプレート・デプロイメント・プラン内のnull変数にエクスポートします。

java weblogic.PlanGenerator -root /appRelease/MyApplication -all

デプロイメント構成のエクスポートの詳細は、「新しい環境にデプロイするためのアプリケーションのエクスポート」を参照してください。

C デプロイメント用のWebLogic Mavenプラグインの使用

この付録では、WebLogic Server 12.1.3でのweblogic-maven-pluginを使用したデプロイメントについて説明します。

注意:
このプラグインはWebLogic Server 12.1.2では非推奨です。
かわりにWebLogic Server Mavenプラグインを使用することをお薦めします。詳細は、『継続的インテグレーションによるアプリケーションの開発』を参照してください。

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

この章で説明されているweblogic-maven-pluginは、WebLogic Server 11gリリース1で搭載され、コマンド行ユーティリティ(weblogic.Deployer)がサポートする操作と同様のデプロイメント操作をサポートします。

両方のプラグインは、Maven 2.xおよび3.xで保証されています。

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

- デプロイメント用WebLogic Mavenプラグインの構成と使用

- 安全なユーザー資格証明の提供

- デプロイメントの目標

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

サポートされているプラットフォームでMavenをダウンロードおよび構成するには、http://maven.apache.org/download.htmlを参照してください。セットアップの指示に従って、Mavenが環境で正しく動作することを確認してください。

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

デプロイメント用WebLogic Mavenプラグインの構成と使用

weblogic-maven-pluginを作成、インストール、および使用するには、次の手順を実行します。

注意:
これらの手順を正常に終了するには、コンピュータをインターネットに接続して、settings.xmlファイル(通常は$HOME/.m2/settings.xml)では必要なプロキシ設定を正しく構成する必要があります。詳細は、http://maven.apache.org/guides/mini/guide-proxies.htmlを参照してください。

1. 次のコマンドで、ORACLE_HOME/wlserver/server/lib/の下のWebLogic JarBuilderツール(wljarbuilder)を使用してプラグインJARファイルを作成します。

java -jar wljarbuilder.jar -profile weblogic-maven-plugin

weblogic-maven-plugin.jarには、weblogic-maven-plugin.jarのgroupId、artifactId、version、およびpackagingを指定するプロジェクト・オブジェクト・モデル(pom.xml)ファイルが含まれます。

groupId=com.oracle.weblogic
artifactId=weblogic-maven-plugin
version=12.1.1.0
packaging=maven-plugin

これらのフィールドは、プラグインを認識して、Mavenプロジェクトのコーディネート・システムとして稼働するMavenリポジトリに、特定の場所をマークします。

注意:
WebLogic Server 10.3.5の時点では、WebLogic Serverバージョン番号に合致するようプラグイン・バージョン番号が変更されたので、4桁の数字(10.3.5.0、10.3.6.0、12.1.1.0など)を含める必要があります。

2. 生成されたweblogic-maven-plugin.jarを一時ディレクトリ(/tmp)にコピーします。

例:

mkdir c:\tmp
cd c:\tmp
cp C:\ORACLE_HOME\wlserver\server\lib\weblogic-maven-plugin.jar c:\tmp

3. c:\tmpディレクトリ直下でweblogic-maven-plugin.jarからpom.xmlファイルを抽出します。

例:

jar xvf c:\tmp\weblogic-maven-plugin.jar
META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml

4. 次のコマンドで、ローカルMavenリポジトリにweblogic-maven-plugin.jarをプロビジョニングします。しかし、プラグインの短縮コマンド行ゴールの起動は、この手順を実行する前にステップ6の指示に従います。

mvn install:install-file
-Dfile=c:\tmp\weblogic-maven-plugin.jar
-DpomFile=META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml

通常コマンド出力は次のとおりです。

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'install'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [install:install-file] (aggregator-style)
[INFO] ------------------------------------------------------------------------
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-api/2.0.6/
maven-plugin-api-2.0.6.pom

Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.6/maven-2.0.6.pom

Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-project/2.0.6/
maven-project-2.0.6.pom

Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-settings/2.0.6/
maven-settings-2.0.6.pom
...................

Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-digest/
1.0/plexus-digest-1.0.jar

[INFO] [install:install-file {execution: default-cli}]
[INFO] Installing C:\tmp\weblogic-maven-plugin.jar to C:\depot\.m2\
repository\com\oracle\weblogic\weblogic-maven-plugin\12.1.1.0\weblogic-maven-plugin-12.1.1.0.jar
[INFO] Installing C:\tmp\META-INF\maven\com.oracle.weblogic\weblogic-maven-plugin
pom.xml to C:\depot\.m2\repository\com\oracle\weblogic\
weblogic-maven-plugin\12.1.1.0\weblogic-maven-plugin-12.1.1.0.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 7 seconds
[INFO] Finished at: Mon Nov 21 13:20:37 PST 2011
[INFO] Final Memory: 3M/15M
[INFO] ------------------------------------------------------------------------

注意:
mvn installコマンドで、Mavenゴールの実行を正常に行うために必要なMaven依存関係をインターネットからダウンロードするため、ローカル・マシンでmvn installを少なくとも一度実行する必要があります。

5. 次のいずれかの方法で、Mavenプラグインを使用します。

注意:
WebLogic Server 10.3.6からは、Mavenプロジェクト外でweblogic-maven-pluginゴールを実行できます。たとえば、weblogic:deployゴールをスタンドアロン・オペレーションとして使用し、任意のディレクトリからWARファイルをデプロイできます。ディレクトリには、Maven pom.xmlファイルが格納されている必要はありません。

- コマンド行: コマンド行からゴールを起動します。
たとえば、ゴールのフル・ネームを使用してデプロイします。

mvn com.oracle.weblogic:weblogic-maven-plugin:deploy

または、オプションで、短縮されたコマンド行ゴールの起動で構成した場合(ステップ6を参照してください)。

mvn weblogic:deploy

- POMファイル: アプリケーションのpom.xmlファイルに、Mavenプラグインを含めます。
プロジェクトの任意ライフサイクル・フェーズにプラグインを追加します。オプションで、実行タグをpom.xmlファイルに追加することで、ゴールをデフォルトMavenライフサイクル・フェーズに追加できます。ゴールが、Mavenライフサイクルの特定のフェーズにバインドされます。たとえば、例C-1で示すように、ゴールがMavenライフサイクルの「インストール」フェーズにバインドされます。それにより、mvn installコマンドを実行するたびにデプロイメント・プラグインも呼び出されます。

例C-1 Mavenプロジェクトpom.xmlファイル

<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<adminurl>t3://localhost:7001</adminurl>
<user>weblogic</user>
<password>weblogic123</password>
<upload>true</upload>
<action>deploy</action>
<remote>false</remote>
<verbose>true</verbose>
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source>
<name>${project.build.finalName}</name>
</configuration>
<!--
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
-->
</plugin>
.
.
.
</plugins>
</build>

6. オプションで、正式名(com.oracle.weblogic:weblogic-maven-plugin)のかわりに短縮名(weblogic)を使用できるように、プラグインをインストールできます。これによって使いやすさが飛躍的に向上します。これを実行するには、例C-2で示されるとおりにpom.xmlファイルを編集して<build>スタンザを追加し、weblogic-maven-pluginをインストールする前にmvn installコマンドを実行します。

1. $HOME/.m2ディレクトリに格納されているsettings.xmlファイルを次のように変更します。

<!-- pluginGroups
| This is a list of additional group identifiers that will be searched
| when resolving plugins by their prefix, for example, when invoking a
| command line like "mvn prefix:goal". Maven will automatically add the
| group identifiers "org.apache.maven.plugins" and "org.codehaus.mojo"
| if theses are not already contained in the list.
| -->
<pluginGroups>
<!-- pluginGroup
| Specifies a further group identifier to use for plugin lookup.
-->
<pluginGroup>com.oracle.weblogic</pluginGroup>
</pluginGroups>

2. c:\tmp\META-INF\maven\com.oracle.weblogic\weblogic-maven-plugin\pom.xmlファイルを次のとおりに編集します。

例C-2 pom.xmlファイル

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<packaging>maven-plugin</packaging>
<version>12.1.1.0</version>
<name>Maven Mojo Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.3</version>
<configuration>
<goalPrefix>weblogic</goalPrefix>
</configuration>
</plugin>
</plugins>
</build>

</project>

3. c:\tmp内から、mvn installコマンドを実行します。

mvn install

この手順によって、ローカルMaven環境が設定され、プラグインでweblogicゴール接頭辞を使用できるようになります。

4. c:\tmp内から、次に示すようにローカルMavenリポジトリにweblogic-maven-plugin.jarを指定します。

mvn install:install-file
c:\tmp\weblogic-maven-plugin.jar
-DpomFile=c:\tmp\META-INF\maven\com.oracle.weblogic\weblogic-maven-plugin\pom.xml

5. なお、短縮されたコマンド行ゴールの起動を使用できます。たとえば:

mvn weblogic:deploy

セキュア・ユーザー資格証明の付与

WebLogic Serverドメインに接続してデプロイメント処理を実行するには、weblogic-maven-pluginによって有効なユーザー資格証明を付与する必要があります。これを手早く簡単に実行するには、例C-1で示すように、Maven pom.xmlファイルにユーザー名とパスワードを直接指定します。ただし、この結果、ユーザー名とパスワードがクリア・テキスト形式で保存されます。こうしたパスワードの露出を防ぐには、ユーザー名とパスワードが暗号化形式で外部ファイルに保存されるセキュア構成認証メカニズムを任意で使用し、ファイルの暗号化に使用されたキーと共に、WebLogic Serverドメインの接続に使用するユーザー資格証明を付与します。詳細は、『WebLogic Scripting Toolの理解』のWLSTオンラインからのアクセスの保護に関する項およびユーザー資格証明の引数に関する項を参照してください。

次の手順では、WLSTを使用してユーザー構成ファイルとキー・ファイルを作成および保存する方法や、Maven pom.xmlファイルでそれらのファイルを参照する方法について説明します。

1. WLSTを呼び出し、稼働中の管理サーバーに接続したら、WLSTのstoreUserConfigコマンドを使用して、生成されるuserConfigFileおよびuserKeyFileの場所を指定します。

>java weblogic.WLST
wls:/offline>connect('weblogic','password')
wls:/mydomain/serverConfig>storeUserConfig('/tmp/wls.config','/tmp/wls.key')
Creating the key file can reduce the security of your system if it is not kept in
a secured location after it is created. Do you want to create the key file? y or n
y
The username and password that were used for this current WLS connection are
stored in /tmp/wls.config and /tmp/wls.key

これらのファイルが正常に機能しているかを検証するには、weblogic.Deployerを使用してWebLogic Serverドメインに接続し、-userconfigfileおよび-userkeyfileパラメータを次のとおりに使用します。

java weblogic.Deployer -adminurl t3://localhost:7001
-userconfigfile /tmp/wls.config -userkeyfile /tmp/wls.key –listapps

2. WebLogic Mavenプラグインを実装してセキュア構成認証メカニズムを使用するには、<ORACLE_HOME>/wlserver/server/lib/crypto.jarという追加ライブラリを、Mavenリポジトリにインストールして暗号化処理をサポートするとともに、pom.xmlファイルを使用してそのライブラリをweblogic-maven-pluginの依存関係として追加します。

1. crytpo.jarを次のとおりにMavenリポジトリにインストールします。

cd <ORACLE_HOME>
cd wlserver
cd server
cd lib
mvn install:install-file -Dfile=cryptoj.jar -DgroupId=com.oracle.cryptoj
-DartifactId=cryptoj -Dversion=1.0 -Dpackaging=jar

2. weblogic-maven-pluginおよびそのpom.xmlファイルを生成するには、「デプロイメント用WebLogic Mavenプラグインの構成と使用」のステップ1、2および3に従ってください。

3. pom.xmlを編集し、crytpo.jar依存関係とgoalPrefix、構成セクションを指定します。構成セクションを使用すると、プラグインの短縮コマンド行ゴールを呼び出せます。
例C-3の編集済のpom.xmlファイル([16-22]および[24-35]行目が変更)を参照してください。

例C-3 Mavenプロジェクトpom.xmlファイル

1:  <project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
2:    <modelVersion>4.0.0</modelVersion>
3:    <groupId>com.oracle.weblogic</groupId>
4:    <artifactId>weblogic-maven-plugin</artifactId>
5:    <packaging>maven-plugin</packaging>
6:    <version>12.1.1.0</version>
7:    <name>Maven Mojo Archetype</name>
8:    <url>http://maven.apache.org</url>
9:    <dependencies>
10:      <dependency>
11:        <groupId>org.apache.maven</groupId>
12:        <artifactId>maven-plugin-api</artifactId>
13:        <version>2.0</version>
14:      </dependency>
15:
16:      <!-- Dependency on cryptoj library -->
17:      <dependency>
18:        <groupId>com.oracle.cryptoj</groupId>
19:        <artifactId>cryptoj</artifactId>
20:        <version>1.0</version>
21:      </dependency>
22:    </dependencies>
23:
24:    <!-- Use weblogic goalPrefix -->
25:    <build>
26:      <plugins>
27:        <plugin>
28:          <artifactId>maven-plugin-plugin</artifactId>
29:          <version>2.3</version>
30:          <configuration>
31:             <goalPrefix>weblogic</goalPrefix>
32:          </configuration>
33:        </plugin>
34:      </plugins>
35:    </build>
36:  </project>

3. 次の2つのインストール・コマンドを使用して、weblogic-maven-pluginをMavenリポジトリにインストールします。最初のコマンドでは、編集済のpom.xmlファイルが黙示的に使用され、Mavenリポジトリ内でweblogic-maven-pluginが構成されます。2番目のコマンドでは、weblogic-maven-pluginライブラリがMavenリポジトリにインストールされます。
編集済のpom.xmlファイルが、これらのコマンドの実行先のディレクトリにあることを確認してください。

Maven 2.xの場合:

mvn install
mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml

Maven 3.xの場合:

mvn install -Dfile=weblogic-maven-plugin
mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml

4. pom.xmlを構成し、認証用にセキュア構成ファイルを使用します。
例C-4は、Java EE 5 Webアプリケーション用の完全に構成済のMaven pom.xmlを示します。[13-18]行目は、WLSTによって生成される関連外部ファイルの場所を識別するプロパティの作成に関する記述です。[67-69]行目は、認証用の安全な構成ファイルを使用して指定するための、<userConfigFile>および<userKeyfile>要素の使用方法を示します。

例C-4 セキュア認証に関するMaven pom.xml

1:  <project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2:    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
3:    <modelVersion>4.0.0</modelVersion>
4:
5:    <groupId>sab.demo.maven</groupId>
6:    <artifactId>webapp</artifactId>
7:    <packaging>war</packaging>
8:    <version>1.0-SNAPSHOT</version>
9:
10:    <name>webapp JEE5 Webapp</name>
11:    <url>http://maven.apache.org</url>
12:
13:    <!-- weblogic-maven-plugin properties -->
14:    <properties>
15:      <weblogic.adminurl>t3://localhost:7001</weblogic.adminurl>
16:      <weblogic.configfile>/tmp/wls.config</weblogic.configfile>
17:      <weblogic.keyfile>/tmp/wls.key</weblogic.keyfile>
18:    </properties>
19:
20:    <dependencies>
21:
22:      <dependency>
23:        <groupId>javax.servlet</groupId>
24:        <artifactId>servlet-api</artifactId>
25:        <version>2.5</version>
26:        <scope>provided</scope>
27:      </dependency>
28:
29:      <dependency>
30:        <groupId>javax.servlet.jsp</groupId>
31:        <artifactId>jsp-api</artifactId>
32:        <version>2.1</version>
33:        <scope>provided</scope>
34:      </dependency>
35:
36:      <dependency>
37:        <groupId>junit</groupId>
38:        <artifactId>junit</artifactId>
39:        <version>3.8.1</version>
40:        <scope>test</scope>
41:      </dependency>
42:
43:    </dependencies>
44:
45:    <build>
46:      <plugins>
47:        <plugin>
48:          <groupId>org.apache.maven.plugins</groupId>
49:          <artifactId>maven-compiler-plugin</artifactId>
50:          <version>2.0.2</version>
51:          <configuration>
52:            <source>1.5</source>
53:            <target>1.5</target>
54:          </configuration>
55:        </plugin>
56:
57:      <plugin>
58:          <groupId>com.oracle.weblogic</groupId>
59:          <artifactId>weblogic-maven-plugin</artifactId>
60:          <version>12.1.1.0</version>
61:          <configuration>
62:              <adminurl>${weblogic.adminurl}</adminurl>
63:              <!--
64:              <user>${weblogic.user}</user>
65:              <password>${weblogic.password}</password>
66:              -->
67:              <!-- Use external connection files -->
68:              <userConfigFile>${weblogic.configfile}</userConfigFile>
69:              <userKeyFile>${weblogic.keyfile}</userKeyFile>
70:              <source>
71:                  ${project.build.directory}/${project.build.finalName}.${project.packaging}
72:              </source>
73:              <name>${project.build.finalName}</name>
74:          </configuration>
75:       </plugin>
76:
77:      </plugins>
78:
79:      <finalName>webapp</finalName>
80:    </build>
81:  </project>

5. list-appsゴールを使用し、セキュア構成認証メカニズムが機能しているか確認します。このゴールは、デプロイメント処理を実行することはありませんが、ターゲット・サーバーへの接続、認証、および、現在デプロイ済のアプリケーションのリストの返却などは実行します。
注意: [INFO]出力は、発行されるweblogic.Deployer基本コマンドを示し、このコマンドでは-userconfigfileおよび-userkeyfileパラメータが使用されます。

mvn weblogic:list-apps
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building webapp JEE5 Webapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- weblogic-maven-plugin:12.1.1.0:list-apps (default-cli) @ webapp ---
weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -userconfigfile /tmp/wls.config -userkeyfile /tmp/wls.key -listapps
wls-rest
jersey-bundle [LibSpecVersion=1.1.1,LibImplVersion=1.1.5.1] <ACTIVE VERSION>
jsr311-api [LibSpecVersion=1.1.1,LibImplVersion=1.1.1] <ACTIVE VERSION>
ops-ear
webapp
jackson-jaxrs [LibSpecVersion=1.0,LibImplVersion=1.1.1] <ACTIVE VERSION>
jettison [LibSpecVersion=1.1,LibImplVersion=1.1] <ACTIVE VERSION>
jackson-core-asl [LibSpecVersion=1.0,LibImplVersion=1.1.1] <ACTIVE VERSION>
jackson-mapper-asl [LibSpecVersion=1.0,LibImplVersion=1.1.1] <ACTIVE VERSION>
Number of Applications Found : 9
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.150s
[INFO] Finished at: Mon Feb 21 12:31:22 CST 2011
[INFO] Final Memory: 12M/81M
[INFO] ------------------------------------------------------------------------

デプロイメントの目標

表C-1では、すべてのweblogic-maven-pluginゴールを一覧表示しています。

表C-1 Mavenプラグイン・デプロイメント・ゴール

ゴール名

説明

deploy

アプリケーションまたはモジュールをデプロイまたは再デプロイします。

undeploy

デプロイメントを停止して、ステージングされているファイルをターゲット・サーバーから削除します。

redeploy

実行中のアプリケーションまたは実行中のアプリケーションの一部を再デプロイします。

start-app

アプリケーションを開始します。

stop-app

アプリケーションを停止します。

list-apps

ドメインにデプロイ、配布、またはインストールされているアプリケーションおよびスタンドアロン・モジュールのデプロイメント名をリストします。

update-app

プラン・ファイルを再配布して、新しいプランの内容に基づいてアプリケーションを再構成することで、アプリケーションのデプロイメント・プランを更新します。

help

すべてのプラグイン・ゴールをリストします。

deploy

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:deploy

ショート・ネーム

weblogic:deploy

説明

アプリケーションまたはモジュールをデプロイします。

属性

デプロイメントの準備完了のアプリケーションが必要です。

パラメータ

表C-2 deployパラメータ

名前

タイプ

デフォルト

説明

name

文字列

none

新規にデプロイされたアプリケーションまたはスタンドアロン・モジュールに割り当てるデプロイメント名を指定します。このパラメータを指定しない場合は、WebLogic Serverは、アーカイブ・ファイルまたは展開されたディレクトリを基に、アプリケーションにデプロイメント名を割り当てます。

source

文字列

none

必須。デプロイするアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリを指定します。

plan

文字列

none

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

targets

文字列

none

アプリケーションまたはモジュールを配布およびデプロイするターゲットを指定します。このパラメータの値は、ターゲット・サーバー、クラスタ、または仮想ホストのコンマ区切りのリストです。

upload

ブール

false

trueのときは、デプロイメント前に、管理サーバーのアップロード・ディレクトリにソース・ファイルをコピーします。

stage

ブール

false

trueのときは、デプロイメント・ファイルをターゲット・サーバーのステージング・ディレクトリにコピーします。

nostage

ブール

true

trueのときは、デプロイメント・ファイルをターゲット・サーバーにコピーせずに、sourceパラメータで指定した所定の場所に配置します。

external_stage

ブール

false

trueのときは、デプロイメント・ファイルはターゲット・サーバーにコピーされません。かわりに、デプロイメント・ファイルがターゲット・サーバーのステージング・ディレクトリの正しいサブディレクトリにコピーされたことを確認する必要があります。ファイルを手動でコピーしたり、サード・パーティのツールやスクリプトを使用したりできます。

stage、nostageまたはexternal_stageのいずれかのパラメータのみを指定できます。何も指定しない場合、管理ターゲット・サーバーに対するデフォルトのデプロイメント・モードはstage、単一のサーバーと管理サーバーに対するデフォルト・モードはnostageです。

retiretimeout

整数

-1

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。

library

ブール

false

trueのときは、デプロイメントを共有Java EEライブラリまたはオプション・パッケージとして指定します。

libspecver

文字列

none

Java EEライブラリまたはオプション・パッケージのバージョンを指定します。このパラメータは、ライブラリまたはパッケージのマニフェスト・ファイルに仕様のバージョンが含まれていない場合にのみ使用できます。libversionはlibraryパラメータと一緒にしか使用できません。

libimplver

文字列

none

Java EEライブラリまたはオプション・パッケージの実装のバージョンを指定します。このパラメータは、ライブラリまたはパッケージのマニフェスト・ファイルに実装のバージョンが含まれていない場合にのみ使用できます。libimplversionはlibraryパラメータと一緒にしか使用できません。

usenonexclusivelock

ブール

false

trueのときは、同じユーザーがドメインですでに取得している既存のロックを、デプロイメント処理で使用することを指定します。複数のデプロイメント・ツールを同時に使用していて、いずれかのツールでドメイン構成のロックをすでに取得している場合に便利。

altappdd

文字列

none

デプロイメントに使用する代替Java EEデプロイメント記述子(application.xml)の名前を指定します。

altwlsappdd

文字列

none

デプロイメントに使用する代替WebLogic Serverデプロイメント記述子(weblogic-application.xml)の名前を指定します。

securityModel

文字列

none

このデプロイメントで使用するセキュリティ・モデルを指定します。デプロイメント記述子のみ、ロールのカスタマイズ、ロールとポリシーのカスタマイズ、セキュリティ・レルム構成(拡張モデル)などの指定可能なキュリティ・モデルがあります。このパラメータで有効な値はDDOnly、CustomRoles、CustomRolesAndPoliciesまたはAdvancedです。

enableSecuirtyValidation

ブール

false

trueのときは、セキュリティ・データの検証を有効にします。

id

文字列

none

実行中のデプロイメント・タスクのタスク識別子を指定します。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

submoduletargets

文字列

deploy

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。このパラメータの値は、JMSサーバー名のコンマ区切りのリストです。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

使用例

例C-5では、deployゴールの使用方法を説明します。

例C-5 deploy

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:deploy
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dtargets=AdminServer -Dsource=c:\apps\sample.war
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO]    task-segment: [com.oracle.weblogic:weblogic-maven-plugin:deploy]
[INFO] ------------------------------------------------------------------------
[INFO] [weblogic:deploy {execution: default-cli}]
weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -deploy -source c:\apps\sample.war -targets AdminServer
<Aug 9, 2010 5:54:22 PM PDT> <Info> <J2EE Deployment SPI> <BEA-260121>
<Initiating deploy operation for application,
sample.war [archive: c:\apps\sample.war], to Admin Server .>

Task 0 initiated: [Deployer:149026]deploy application sample.war on AdminServer.

Task 0 completed: [Deployer:149026]deploy application sample.war on AdminServer.

Target state: deploy completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Aug 09 17:54:23 PDT 2010
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

undeploy

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:undeploy

ショート・ネーム

weblogic:undeploy

説明

アプリケーションまたはモジュールをアンデプロイします。

属性

すでにデプロイされたアプリケーションが必要です。

パラメータ

表C-3 undeployのパラメータ

名前

タイプ

デフォルト

説明

name

文字列

none

必須。デプロイされたアプリケーションまたはモジュールのデプロイメント名を指定します。このパラメータを指定しない場合は、WebLogic Serverは、アーカイブ・ファイルまたは展開されたディレクトリを基に、アプリケーションにデプロイメント名を割り当てます。

appversion

文字列

none

デプロイされたアプリケーションのバージョン識別子を指定します。

planversion

文字列

none

デプロイメント・プランのバージョン識別子を指定します。

plan

文字列

none

アンデプロイするときに使用するデプロイメント・プランを指定します。

targets

文字列

none

アプリケーションまたはモジュールがアンデプロイされるターゲットを指定します。このパラメータの値は、ターゲット・サーバー、クラスタ、または仮想ホストのコンマ区切りのリストです。

retiretimeout

整数

-1

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。

graceful

文字列

false

trueのときは、既存のHTTPクライアントが作業を完了した時点でアプリケーションを停止します。gracefulパラメータを指定しない場合、WebLogic Serverはアプリケーションまたはモジュールをただちに停止させます。

ignoresessions

文字列

false

trueのときは、現在のHTTPセッションが完了するのを待機せずに、アプリケーションをただちに管理モードに切り替えます。

id

文字列

none

実行中のデプロイメント・タスクのタスク識別子を指定します。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

submoduletargets

文字列

deploy

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。このパラメータの値は、JMSサーバー名のコンマ区切りのリストです。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

使用例

例C-6では、undeployゴールの使用方法を説明します。

例C-6 undeploy

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:undeploy
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dtargets=AdminServer -Dname=sample.war
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO]    task-segment: [com.oracle.weblogic:weblogic-maven-plugin:undeploy]
[INFO] ------------------------------------------------------------------------
[INFO] [weblogic:undeploy {execution: default-cli}]
weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -undeploy -name sample.war -targets AdminServer
<Aug 9, 2010 10:41:16 PM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat
ing undeploy operation for application, sample.war [archive: null],
to AdminServer .>

Task 3 initiated: [Deployer:149026]remove application sample.war on AdminServer.

Task 3 completed: [Deployer:149026]remove application sample.war on AdminServer.

Target state: undeploy completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Aug 09 22:41:16 PDT 2010
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

redeploy

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:redeploy

ショート・ネーム

weblogic:redeploy

説明

アプリケーションまたはモジュールをデプロイします。

属性

デプロイメントの準備完了のアプリケーションが必要です。

パラメータ

表C-4 redeployのパラメータ

名前

タイプ

デフォルト

説明

name

文字列

none

必須。デプロイされたアプリケーションまたはモジュールのデプロイメント名を指定します。このパラメータを指定しない場合は、WebLogic Serverは、アーカイブ・ファイルまたは展開されたディレクトリを基に、アプリケーションにデプロイメント名を割り当てます。

nameパラメータを指定しない場合は、sourceパラメータを指定する必要があります。

source

文字列

none

再デプロイするアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリを指定します。

plan

文字列

none

再デプロイするときに使用するデプロイメント・プランを指定します。

targets

文字列

none

アプリケーションまたはモジュールを再デプロイするターゲットを指定します。このパラメータの値は、ターゲット・サーバー、クラスタ、または仮想ホストのコンマ区切りのリストです。

upload

文字列

false

trueのときは、再デプロイする前に、管理サーバーのアップロード・ディレクトリにソース・ファイルをコピーします。

delete_files

文字列

false

サーバーのステージング・ディレクトリから静的ファイルを削除します。このパラメータは、アーカイブされていないデプロイメント、およびstageモードを使用してデプロイされたアプリケーションでのみ有効です。このパラメータを使用するときには、ターゲット・サーバーを指定する必要があります。

retiretimeout

整数

-1

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。

filelist

文字列

none

再デプロイする1つ以上のファイルを指定します。

id

文字列

none

実行中のデプロイメント・タスクのタスク識別子を指定します。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

submoduletargets

文字列

deploy

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。このパラメータの値は、JMSサーバー名のコンマ区切りのリストです。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

使用例

例C-7では、redeployゴールの使用方法を説明します。

例C-7 redeploy

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:redeploy
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dtargets=AdminServer -Dname=sample.war
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO]    task-segment: [com.oracle.weblogic:weblogic-maven-plugin:redeploy]
[INFO] ------------------------------------------------------------------------
[INFO] [weblogic:redeploy {execution: default-cli}]
weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -redeploy -name sample.war
<Sep 9, 2010 10:12:27 PM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat
ing redeploy operation for application, sample.war [archive: null], to to configurd targets.>

Task 1 initiated: [Deployer:149026]redeploy application sample.war on AdminServer.

Task 1 completed: [Deployer:149026]redeploy application sample.war on AdminServer.

Target state: redeploy completed on ServervE AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 09 22:12:27 PDT 2010
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

start-app

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:start-app

ショート・ネーム

weblogic:start-app

説明

アプリケーションを開始します。

属性

すでにデプロイされたアプリケーションが必要です。

パラメータ

表C-5 start-appのパラメータ

名前

タイプ

デフォルト

説明

adminmode

ブール

false

trueのときは、本番モード(デフォルト)ではなく、管理モードでアプリケーションを起動します。管理モードでは、管理チャンネルを構成するアプリケーションへのアクセスを規制します。

name

文字列

none

必須。起動するデプロイ済アプリケーションまたはモジュールのデプロイメント名を指定します。

appversion

文字列

none

起動するアプリケーションのバージョンを指定します。

planversion

文字列

none

アプリケーションの起動時に使用するデプロイメント・プランのバージョンを指定します。

targets

文字列

none

アプリケーションまたはモジュールを起動するターゲットを指定します。このパラメータの値は、ターゲット・サーバー、クラスタ、または仮想ホストのコンマ区切りのリストです。

retiretimeout

整数

-1

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。

id

文字列

none

実行中のデプロイメント・タスクのタスク識別子を指定します。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

submoduletargets

文字列

deploy

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。このパラメータの値は、JMSサーバー名のコンマ区切りのリストです。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

使用例

例C-8では、start-appゴールの使用方法を説明します。

例C-8 start-app

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:start-app
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dtargets=AdminServer -Dname=sample.war
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO]    task-segment: [com.oracle.weblogic:weblogic-maven-plugin:start-app]
[INFO] ------------------------------------------------------------------------
[INFO] [weblogic:start-app {execution: default-cli}]
weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -start -name sample.war -targets AdminServer
<Aug 9, 2010 10:54:51 PM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat
ing start operation for application, sample.war [archive: null], to AdminServer
.>

Task 6 initiated: [Deployer:149026]start application sample.war on AdminServer.
Task 6 completed: [Deployer:149026]start application sample.war on AdminServer.
Target state: start completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Aug 09 22:54:52 PDT 2010
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

stop-app

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:stop-app

ショート・ネーム

weblogic:stop-app

説明

アプリケーションを停止します。

属性

すでにデプロイされたアプリケーションが必要です。

パラメータ

表C-6 stop-appのパラメータ

名前

タイプ

デフォルト

説明

adminmode

ブール

false

trueのときは、構成済の管理チャネル経由で管理リクエストのみを受け付けるように、アプリケーションを管理モードに切り替えます。このオプションを指定しない場合、実行中のアプリケーションは停止されて、再起動するまで管理リクエストもクライアント・リクエストも受け付けなくなります。

name

文字列

none

必須。停止するデプロイ済アプリケーションまたはモジュールのデプロイメント名を指定します。

appversion

文字列

none

デプロイされたアプリケーションのバージョン識別子を指定します。

planversion

文字列

none

デプロイメント・プランのバージョン識別子を指定します。

targets

文字列

none

アプリケーションまたはモジュールを停止するターゲットを指定します。このパラメータの値は、ターゲット・サーバー、クラスタ、または仮想ホストのコンマ区切りのリストです。

graceful

ブール

false

trueのときは、既存のHTTPクライアントが作業を完了した時点でアプリケーションを停止します。gracefulパラメータを指定しない場合、WebLogic Serverはアプリケーションまたはモジュールをただちに停止させます。

ignoresessions

ブール

false

trueのときは、現在のHTTPセッションが完了するのを待機せずに、アプリケーションをただちに管理モードに切り替えます。

rmiGraceperiod

整数

-1

正常停止またはリタイアの際にRMIの猶予期間内でRMIリクエストの受信がなくなるまで、ワーク・マネージャがRMI呼出しを受け付けてスケジューリングする時間(秒単位)を指定します。

retiretimeout

整数

-1

WebLogic Serverがこのアプリケーションまたはモジュールの現在実行中のバージョンをアンデプロイし、クライアントが新しいバージョンで開始できるようになるまでの秒数を指定します。

id

文字列

none

実行中のデプロイメント・タスクのタスク識別子を指定します。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

submoduletargets

文字列

deploy

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。このパラメータの値は、JMSサーバー名のコンマ区切りのリストです。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

使用例

例C-9では、stop-appゴールの使用方法を説明します。

例C-9 stop-app

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:stop-app
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dtargets=AdminServer -Dname=sample.war
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO]    task-segment: [com.oracle.weblogic:weblogic-maven-plugin:stop-app]
[INFO] ------------------------------------------------------------------------
[INFO] [weblogic:stop-app {execution: default-cli}]
weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -stop -name sample.war -targets AdminServer
<Aug 9, 2010 10:53:39 PM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat
ing stop operation for application, sample.war [archive: null], to AdminServer .
>

Task 5 initiated: [Deployer:149026]stop application sample.war on AdminServer.
Task 5 completed: [Deployer:149026]stop application sample.war on AdminServer.
Target state: stop completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Aug 09 22:53:39 PDT 2010
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

list-apps

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:list-apps

ショート・ネーム

weblogic:list-apps

説明

ドメインにデプロイ、配布、またはインストールされているアプリケーションおよびスタンドアロン・モジュールのデプロイメント名をリストします。

属性

なし。

パラメータ

このゴールでは、パラメータの要求や、オプションでパラメータの採用などはありません。

使用例

例C-10では、list-appsゴールの使用方法を説明します。

例C-10 list-apps

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:list-apps
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dtargets=AdminServer
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO]    task-segment: [com.oracle.weblogic:weblogic-maven-plugin:list-apps]
[INFO] ------------------------------------------------------------------------
[INFO] [weblogic:list-apps {execution: default-cli}]
weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -listapps
sample.war
Number of Applications Found : 1
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Aug 09 22:52:07 PDT 2010
[INFO] Final Memory: 4M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

update-app

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:update-app

ショート・ネーム

weblogic:update-app

説明

プラン・ファイルを再配布して、新しいプランの内容に基づいてアプリケーションを再構成することで、アプリケーションのデプロイメント・プランを更新します。

属性

すでにアプリケーションをデプロイされている場合があります。

パラメータ

表C-7 update-appのパラメータ

名前

タイプ

デフォルト

説明

name

文字列

none

必須。デプロイされたアプリケーションまたはモジュールのデプロイメント名を指定します。このパラメータを指定しない場合は、WebLogic Serverは、アーカイブ・ファイルまたは展開されたディレクトリを基に、アプリケーションにデプロイメント名を割り当てます。

plan

文字列

none

必須。アプリケーションの構成の更新に使用するデプロイメント・プランを指定します。指定されたデプロイメント・プランはアプリケーションのターゲット・サーバーで有効でなければなりません。たとえば、リソースが関連する記述子で以前に定義されていないかぎり、プランでは必要なリソースにnullの変数を指定できません。

更新処理では、デプロイメント・プランで変更されている(nullではない)値に対応する記述子のみを更新します。更新処理に使用されるプランにnull変数が含まれている場合、対応する記述子の現在の値は更新されません。

planversion

文字列

none

デプロイメント・プランのバージョン識別子を指定します。

targets

文字列

none

アプリケーションまたはモジュールを更新するターゲットを指定します。このパラメータの値は、ターゲット・サーバー、クラスタ、または仮想ホストのコンマ区切りのリストです。

upload

ブール

false

trueのときは、アプリケーションの更新前に、新規デプロイメント・プランを管理サーバーに転送します。

appversion

文字列

none

デプロイされたアプリケーションのバージョン識別子を指定します。

id

文字列

none

実行中のデプロイメント・タスクのタスク識別子を指定します。識別子が実行中のほかのすべてのデプロイメント・タスクに対して一意であることを確認してください。指定しない場合、システムによって一意の識別子が自動的に生成されます。

submoduletargets

文字列

deploy

JMSアプリケーション・モジュール内で定義されているリソースのJMSサーバー・ターゲットを指定します。このパラメータの値は、JMSサーバー名のコンマ区切りのリストです。『Oracle WebLogic Server JMSリソースの管理』のJMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用に関する項およびWLSTを使用したJMSサーバーおよびJMSシステム・リソースの管理に関する項を参照してください。

使用例

例C-11では、update-appゴールの使用方法を説明します。

例C-11 update-app

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:update-app
-Dadminurl=t3://myhost:7001 -Duser=weblogic
-Dpassword=mypassword -Dname=sample.war -Dremote=true
-Dupload=true -Dplan=c:\apps\sampleWar.plan

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype 12.1.1.0
[INFO] ------------------------------------------------------------------------
[INFO] --- weblogic-maven-plugin:12.1.1.0:update-app (default-cli)
@ weblogic-maven-plugin ---

weblogic.Deployer invoked with options:  -noexit -adminurl t3://myhost:7001
-user weblogic -update -plan c:\apps\sampleWar.plan sample.war -name sample.war -upload -remote
<Oct 18, 2010 10:30:47 AM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initia
ting update operation for application, sample.war [archive: null], to configured
targets.>

Task 8 initiated: [Deployer:149026]update application sample.war on AdminServer.
Task 8 completed: [Deployer:149026]update application sample.war on AdminServer.
Target state: update completed on Server AdminServer

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.188s
[INFO] Finished at: Mon Oct 18 10:30:49 PDT 2010
[INFO] Final Memory: 3M/15M
[INFO] ------------------------------------------------------------------------

使用方法の詳細は、weblogic.Deployerコマンド行リファレンスを参照してください。

help

フル・ネーム

com.oracle.weblogic:weblogic-maven-plugin:help

ショート・ネーム

weblogic:help

説明

サポートするすべてのデプロイメント・ゴールのリストを表示します。

属性

- なし。

使用例

例C-12では、helpゴールの使用方法を説明します。

例C-12 help

C:\>mvn  com.oracle.weblogic:weblogic-maven-plugin:help
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Mojo Archetype
[INFO] task-segment: [com.oracle.weblogic:weblogic-maven-plugin:help]
(aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [null:help {execution: default-cli}
The following are the goals available currently in Maven
deploy
list-apps
redeploy
start-app
stop-app
undeploy
update-app

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Wed Oct 05 14:00:01 PDT 2011
[INFO] Final Memory: 3M/15M
[INFO] ------------------------------------------------------------------------

トラブルシューティング

表C-8に、共通のMavenプラグイン・エラーとそれを解決する方法を示します。

表C-8 Mavenプラグイン・エラー

構成ステップ

エラー・メッセージ

解決

ステップ1: プラグインを作成します。

java –jar wljarbuilder.jar –profile weblogic-maven-plugin

wljarbuilder.jarファイルにアクセスできません

ORACLE_HOME/wlserver/server/lib/ディレクトリ内からコマンドを発行したかどうか確認してください。

ステップ3: weblogic-maven-pluginから、pom.xmlファイルを抽出します。

pom.xmlファイルは、一時ディレクトリ(\tmp)内で作成する必要があります。たとえば、c:\tmp\META-INF\maven\com.oracle.weblogic\weblogic-maven-plugin\pom.xmlのようになります。

ステップ4: Mavenリポジトリに、weblogic-maven-plugin.jarを提供します。

成功した場合、ビルドに成功したメッセージが表示されます。

ビルド・エラー

考えられる問題:

- weblogic-maven-plugin.jarを作成していません。(デプロイメント用WebLogic Mavenプラグインの構成と使用のステップ1を参照してください)。

- pom.xmlを一時ディレクトリ(\tmp)に抽出していません(デプロイメント用WebLogic Mavenプラグインの構成と使用のステップ3を参照してください)。

- Mavenを正しくインストールしていないか、またはリポジトリを提供していません。(http://maven.apache.org/guides/development/guide-building-m2.html参照してください)。

ステップ5: Mavenゴールを実行します。

成功した場合、ビルドに成功したメッセージが表示されます。

アーティファクトの解決に失敗しました

考えられる問題:

- mvn weblogic:goalを呼び出す前に、mvn installコマンドを1回以上実行する必要があります。Mavenの依存関係はインターネットから取得する必要があるため、この操作が必要です(デプロイメント用WebLogic Mavenプラグインの構成と使用に関する項のステップ3の注意を参照してください)。

- mvn installコマンドを、pom.xmlファイルを抽出した一時ディレクトリ以外の場所から実行しました。

- weblogic-maven-plugin.jarファイルをコピーし、pom.xmlファイルを抽出した一時ディレクトリ内に、pom.xmlファイルがありません。

ステップ6: プラグインの短縮名ゴール呼出しの使用

例:

$ mvn weblogic:help

ビルドの失敗

[エラー] 利用可能なゴールの中のプラグインorg.codehaus.mojo:weblogic-maven-plugin:2.9.1内にゴールの「ヘルプ」が見つかりませんでした...

よくある原因としては、「デプロイメント用WebLogic Mavenプラグインの構成と使用」のステップ6を全部実行していないことが考えられます。

- pom.xmlファイルを展開し、これを編集して<build>スタンザを追加済であるか確認してください。

<build>
<plugins>
<plugin>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.3</version>
<configuration>
<goalPrefix>weblogic</goalPrefix>
</configuration>
</plugin>
</plugins>
</build>

- pom.xmlファイルの編集後、ただしmvn install:install-fileコマンドを発行する前に、必要なmvn installを実行したか確認してください。

このエラーが発生したら、ステップ6に戻って記載どおりの操作を実行するだけで問題を解決できます。

- weblogic-maven-plugin.jarからpom.xmlを展開します。

- pom.xmlを編集し、<build>...</build>スタンザを追加します。

- mvn installを実行します。

- mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xmlを実行します。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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

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

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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

危険な用途への使用について

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。