WebLogic Server デプロイメント

このリリースの WebLogic Server では、新しいデプロイメント プロトコルとして 2 フェーズ デプロイメントが導入されました。これを利用すると、サーバ間、特にクラスタ化されているサーバ間でデプロイメント ステートの一貫性を容易に維持できます。「2 フェーズ デプロイメント」を参照してください。

アプリケーションは、WebLogic Server Administration Console、weblogic.Deployer ユーティリティ、WebLogic Builder、または自動デプロイメントを使用してデプロイできます。これらのデプロイメント ツールについては、「デプロイメント ツールおよび手順」で説明されています。

以下の節で WebLogic Server のデプロイメントについて説明します。

• 2 フェーズ デプロイメント

• リソースおよびアプリケーションのデプロイメント順序

• アプリケーションのステージング

• デプロイメント ツールおよび手順

• デプロイメント補足ドキュメント

 

---

2 フェーズ デプロイメント

新しい 2 フェーズ デプロイメント プロトコルを利用すると、ドメインの一貫性を容易に維持できます。旧バージョンの WebLogic Server では、アプリケーションのデプロイ時に、管理サーバによってアプリケーション ファイルのコピーがすべての対象サーバに送信され、その後、対象サーバにアプリケーションがロードされました。したがって、対象サーバへのデプロイメントが一部でも失敗すると、対象サーバ間のデプロイメント ステートにおける一貫性が失われました。

最新リリースの WebLogic Server では、まず、すべての対象サーバに対するアプリケーションが準備され、次に別フェーズでアプリケーションがアクティブ化されます。準備フェーズまたはアクティブ化フェーズでアプリケーションのデプロイメントが失敗すると、クラスタへのデプロイメントが失敗します。

従来の WebLogic Server デプロイメント プロトコルの使用については、「WebLogic Server 6.x のデプロイメント プロトコルの使用」を参照してください。

新しいデプロイメント プロトコルでは、デプロイされるアプリケーションに関して以下の新機能がサポートされています。

• クラスタのデプロイメント ステートの一貫性。クラスタを対象としたアプリケーションがクラスタ メンバーのいずれかに対して準備フェーズで失敗した場合、アクティブ化フェーズでは、どのクラスタ メンバーに対してもアプリケーションはアクティブ化されません。このため、クラスタの均一性が保証されます。

• アプリケーションの順序設定。サーバの起動時に、アプリケーションのアクティブ化順序を設定します。「リソースおよびアプリケーションのデプロイメント順序」を参照してください。

• アプリケーション スコープのコンフィグレーション。特定のリソースをアプリケーション用にコンフィグレーションし、スコープとして設定できます。これには、接続プール、セキュリティ レルム、および XML 関連リソースがあります。「アプリケーション スコーピングの概要」を参照してください。

• 再デプロイメントの改善。再デプロイする前にアンデプロイを行う必要はありません。 「Administration Console によるアプリケーションの更新」、「アーカイブされたアプリケーションのアンデプロイメントと再デプロイメント」、および「展開形式によるアプリケーションの再デプロイメント」を参照してください。

  注意: 再デプロイ中には、アプリケーションがクライアントから使用できなくなります。 そのため、プロダクション環境では再デプロイメントを使用しないことをお勧めします。

• API の改善。単純な API では、コンフィグレーションと実際のデプロイメント処理とが別になっています。デプロイメントが要求されると、この API によって必要なコンフィグレーション (MBean) が自動的に作成されます。また、デプロイメント処理は MBean 自体では行われないので、ユーザは、デプロイメント要求が開始されるまで、デプロイ済みのアプリケーションに影響を与えることなく、コンフィグレーション (対象リストなど) を変更できます。 「デプロイメント管理 API」に加えて、weblogic.management.deploy で API ドキュメントも参照してください。

• デプロイメント ステータス。デプロイメントの進行状況の追跡が、特にデプロイ先が複数の場合に容易になりました。 「weblogic.Deployer ユーティリティの使用例」、および Administration Console オンライン ヘルプの「タスク」を参照してください。

管理サーバの再起動

管理サーバを停止および再起動すると、保留中のデプロイメント要求が取り消されます。クラスタへのデプロイ中に、クラスタ内の対象サーバのいずれかが停止している場合、管理サーバを再起動すると、その対象サーバは復帰したときにデプロイメント要求を受け取れなくなります。

準備フェーズとアクティブ化フェーズ

2 フェーズ モデルでは、アプリケーションを対象サーバにデプロイする前に準備フェーズの成功を確認することで、クラスタ内でデプロイメント ステートの矛盾が発生しにくくなっています。準備フェーズで失敗したデプロイメントは、アクティブ化フェーズに進みません。

準備フェーズ

第 1 フェーズであるデプロイメントの準備フェーズでは、ファイルを配布またはコピーし、アプリケーションとそのコンポーネントを検証し、エラー チェックを実行してアクティブ化に備えます。準備フェーズの目的は、作成されたアプリケーションおよびそのコンポーネントがデプロイ可能な状態にあるか確認することです。

アクティブ化フェーズ

第 2 フェーズであるアクティブ化フェーズでは、対応するサーバのサブシステムを使用してアプリケーションとコンポーネントの実際のデプロイメントまたはアクティブ化が行われます。アプリケーションは、アクティブ化フェーズを経てクライアントに対して使用可能になります。

 

---

リソースおよびアプリケーションのデプロイメント順序

デフォルトでは、WebLogic Server は、サーバレベルのリソース (JDBC に続いて JMS) をデプロイしてからアプリケーションおよびスタンドアロン モジュールをデプロイします (その後に起動クラスが実行される)。 起動クラスの実行の順序はコンフィグレーション可能です (起動クラスの実行とデプロイメントの順序設定を参照)。

アプリケーションの順序の設定

アプリケーションは、コネクタ、EJB、Web アプリケーションの順にデプロイされます。WebLogic Server 7.0 では、アプリケーションについてロード順を選択できます。「Application」の ApplicationMBean LoadOrder 属性を参照してください。

アプリケーション コンポーネントの順序の設定

アプリケーションが EAR の場合、application.xml デプロイメント記述子に宣言されている順序で、個々のコンポーネントがロードされます。「エンタープライズ アプリケーション デプロイメント記述子ファイル」を参照してください。

起動クラスの実行とデプロイメントの順序設定

デフォルトでは、サーバで JMS サービスと JDBC サービスが初期化され、アプリケーションおよびスタンドアロン モジュールがデプロイされた後に WebLogic Server の起動クラスが実行されます。

JMS サービスと JDBC サービスが使用可能になった後、アプリケーションとモジュールがアクティブ化される前に起動タスクを実行する場合は、Administration Console の [アプリケーション デプロイメントの前に実行] オプションを選択します(または StartupClassMBean の LoadBeforeAppActivation 属性を「true」に設定する)。

JMS サービスと JDBC サービスが使用可能になる前に起動タスクを実行する場合は、Administration Console の [Run Before Application Activations] オプションを選択します (または StartupClassMBean の LoadBeforeAppDeployments 属性を「true」に設定する)。

次の図は、WebLogic Server でいつ起動クラスが実行されるかを簡単に示しています。

図5-1 起動クラスの実行

 

詳細については、StartupClassMBean の Javadoc を参照してください。

 

---

アプリケーションのステージング

このリリースの WebLogic Server では、デプロイを行う前にアプリケーション ファイルをコピーするかどうか、およびコピーする場合のコピー先およびコピー主体を、ステージング モードで指定できます。ステージングとは、デプロイ元となる場所にアプリケーション ファイルをコピーすることです。サーバはそれぞれステージング モードを持っています。デプロイメントの実行後は、アプリケーションのステージング モードは変更できません。 ステージング モードをいつ使用するかについては、「アプリケーション デプロイメントのベスト プラクティス」を参照してください。

ステージング モード

使用可能なステージング モードは以下のとおりです。

• nostage: アプリケーション ファイルを別の場所にコピーしません。

  nostage モードの場合、サーバはサーバにデプロイされたアプリケーションをソース ディレクトリから直接実行します。このモードでは、Web アプリケーション コンテナが JSP およびサーブレットに対する変更を検出します。

• stage : アプリケーション ファイルをデプロイメント対象のサーバにコピーします。

  stage モードでは、デプロイメント操作を実行すると、管理サーバは、ソース ファイルを対象サーバのステージング ディレクトリに開きます。 対象サーバは、このディレクトリからアプリケーションを初期化して実行します。

• external_stage : WebLogic Server ではなくユーザが、デプロイメントの前にアプリケーション ファイルをサーバのステージング ディレクトリにコピーします。

  デプロイメントは、各対象サーバのステージング ディレクトリのアプリケーション名と同じ名前を持つディレクトリにコピーされます。

  external stage モードは、外部エンティティがファイルの配布先として想定しているステージング ディレクトリからアプリケーションが起動することを意味します。このモードは、環境をサードパーティ ツールで管理している場合に便利です。

注意: nostage または external_stage のいずれかを使用するには、デプロイするファイルが管理サーバ マシンからアクセス可能でなければなりません。管理サーバ マシンにファイルをコピーするか、またはファイルを管理サーバ マシンから使用可能な共有ディレクトリに入れます。

ステージング モードでは次のようにデフォルト設定されます。

• 管理対象サーバの場合、ステージング モードはデフォルトで stage となります。つまり、デフォルトのステージング動作ではアプリケーション ファイルが対象の管理対象サーバにコピーされます。

• 管理サーバの場合、ステージング モードはデフォルトで nostage となります。つまり、デフォルトのステージング動作では指定したソースの場所からのデプロイが行われます。

次の表では、ステージング属性およびパスの設定がアプリケーションのデプロイメントに与える影響について説明します。

表5-1 デプロイメントのステージング モード

ステージング モード	ステージング ディレクトリ	管理サーバのデプロイメント動作	管理対象サーバのデプロイメント動作
stage	絶対パス、相対パス	アプリケーション ファイルは、サーバ ステージング ディレクトリ内のアプリケーション デプロイメントに基づいて付けられた名前のディレクトリにコピーされ、そのディレクトリ (たとえば、server/stage/myapp/app.ear) からアクティブ化される。 ステージング パスが相対パスの場合、パスはサーバのルート ディレクトリを基準にしている。	管理サーバと同じ。
nostage	絶対パス、相対パス	ステージング パスは無視され、ファイルはコピーされない。ファイルは、管理サーバ上の場所または管理サーバからアクセス可能な共有ディレクトリからデプロイされる。	管理サーバと同じ (デプロイするには、ソース ファイルが管理対象サーバ マシンからアクセス可能でなければならない)。
external_stage	絶対パス、相対パス	ファイルはコピーされないが、デプロイメント ファイルはサーバ ステージング ディレクトリ内のデプロイメントに基づいて付けられた名前のサブディレクトリにあるものと見なされ、そこからロードされる。たとえば、デプロイメント名「myextapp」を使用してアプリケーションをデプロイし、サーバ ステージング ディレクトリが .¥myserver¥stage の場合は、デプロイメント ファイルが .¥myserver¥stage¥myextapp で使用可能であることをデプロイメント前に確認しておく必要がある。 ステージング パスが相対パスの場合、パスはサーバのルート ディレクトリを基準にしている。	管理サーバと同じ (デプロイメント ファイルが管理対象サーバのステージング ディレクトリの適切なサブディレクトリにコピーされていることを確認する必要がある)。

ステージング モードおよびディレクトリのコンフィグレーション

デフォルトでは、アプリケーションを管理対象サーバにデプロイすると、アプリケーションはデプロイ先サーバのステージング エリア (ServerMBean.StagingDirectoryName) にステージングされ、そこからデプロイされます。ステージングは、ServerMBean.StagingMode 属性または ApplicationMBean.StagingMode 属性を使用して無効にできます。 ServerMBean.StagingMode 属性は、そのサーバにデプロイされているすべてのアプリケーションに適用されます。 この属性は ApplicationMBean.StagingMode によってオーバライドされます。

ステージング モードをいつ使用するかについては、「アプリケーション デプロイメントのベスト プラクティス」を参照してください。

ここで取り上げた属性の Javadoc については、WebLogic クラスの Javadoc を参照してください。

ステージングのシナリオ

以下で説明する特定の共通タスクを実行するようにシステムをコンフィグレーションできます。

アプリケーションをソースの場所からデプロイする

アプリケーションまたは特定サーバの StagingMethod 属性を nostage にコンフィグレーションします。アプリケーションでこの属性をコンフィグレーションする場合、この設定は weblogic.Deployer ツールを使用してサーバでアプリケーションがコンフィグレーションされるときに行います。

このモードは、単一サーバで漸進的な開発を行う場合に便利です。また、複数のサーバがアプリケーションの同じコピーを使用する共有ディスク環境でも役立ちます。

アプリケーションを既知のステージング エリアからデプロイする

既知のディレクトリを指すように、各サーバの StagingDirName 属性をコンフィグレーションします。実際の EAR、JAR、WAR、および RAR ファイルは、そのディレクトリ内で対象アプリケーション名を持つディレクトリに配置します。

アプリケーション ファイルを管理対象サーバに配布する

StagingMode 属性を stage に設定した場合、WebLogic Server では、ソースからステージング ディレクトリにファイルがコピーされます。stage モードを使用してデプロイするには、次の手順に従います。

1. stage モードを使用するように管理対象サーバをコンフィグレーションし、各サーバが使用するステージング ディレクトリを指定します。

2. デプロイするファイルがドメインの管理サーバからアクセス可能であることを確認します。管理サーバ マシンにファイルをコピーするか、またはファイルを管理サーバ マシンから使用可能な共有ディレクトリに入れます。

3. Administration Console を使用して管理対象サーバにファイルをデプロイします。

external_stage モードを使用してアプリケーションをデプロイする

external_stage モードでは、デプロイメント ファイルを管理対象サーバに手動でコピーするか、またはファイルをコピーするアプリケーションあるいはスクリプトを用意する必要があります。external_stage モードを使用して、アプリケーションを管理対象サーバにデプロイするには、次の手順に従います。

1. stage モードを使用するように管理対象サーバをコンフィグレーションし、各サーバが使用するステージング ディレクトリを指定します。

2. 管理対象サーバのステージング エリアで、使用するデプロイメント名 (「mywar」など) を持つサブディレクトリを作成し、デプロイメント ファイルをそのサブディレクトリにコピーします。

3. デプロイするファイルがドメインの管理サーバからアクセス可能であることを確認します。管理サーバ マシンにファイルをコピーするか、またはファイルを管理サーバ マシンから使用可能な共有ディレクトリに入れます。

4. Administration Console で、同じデプロイメント名 (「mywar」) を使用して管理対象サーバにファイルをデプロイします。管理対象サーバは、上記の手順 2 でコピーしたデプロイメント ファイルを使用してデプロイします。

 

---

デプロイメント ツールおよび手順

WebLogic Server のデプロイメント ツールは、「デプロイメント管理 API」で説明したデプロイメント API へのインタフェースを提供します。

ここで説明するデプロイメント手順では、正しいディレクトリ構造を使用し、適切なデプロイメント記述子を含む、正常に機能する J2EE アプリケーションが作成されていることを前提にしています。デプロイメント記述子 (XML タグを使用して書式化されたテキスト ファイル) には、アプリケーションのディレクトリまたはアーカイブの内容を記述します。J2EE 仕様では、J2EE アプリケーションおよびそのコンポーネント用の標準的で移植性の高いデプロイメント記述子が定義されています。BEA は、アプリケーションおよびそのコンポーネントを WebLogic Server 環境にデプロイするための WebLogic 固有のデプロイメント記述子をさらに定義しています。 詳細については、「XML デプロイメント記述子」を参照してください。

WebLogic Server デプロイメント ツールの一覧を以下に示します。

• weblogic.Deployer ユーティリティ

• wldeploy Ant タスク

• WebLogic Server Administration Console

• WebLogic Builder

• 自動デプロイメント (開発モードのみ)

weblogic.Deployer ユーティリティ

weblogic.Deployer ユーティリティは WebLogic Server 7.0 の新機能で、非推奨となった以前の weblogic.deploy ユーティリティに代わるものです。weblogic.Deployer ユーティリティは、WebLogic Server デプロイメント API にコマンドライン インタフェースを提供する、Java ベースの開発ツールです。このユーティリティは、コマンドライン、シェル スクリプト、または Java 以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。

この節では、weblogic.Deployer ユーティリティを使って以下のタスクを実行する方法について説明します。

• 新しいアプリケーションをデプロイする

• 新しいアプリケーションをクラスタにデプロイする

• アプリケーション全体を再デプロイする

• EAR に新しく追加されたモジュールをデプロイする

• 展開されたアプリケーションの一部を再デプロイ (更新) する

• すべてのアクティブな対象でアプリケーションを非アクティブ化する (使用不可にする)

• 非アクティブ化したアプリケーションを再アクティブ化する

• すべての対象サーバからアプリケーションを削除する

• デプロイメント タスクを取り消す

• すべてのデプロイメント タスクの表示

• 単一のサーバにアプリケーションをデプロイまたは再デプロイする

• アプリケーションを追加サーバにデプロイする

weblogic.Deployer ユーティリティによるデプロイ作業

weblogic.Deployer ユーティリティを使用してアプリケーションまたはそのコンポーネントをデプロイする手順は次のとおりです。

1. WebLogic Server クラスをシステムの CLASSPATH に入れ、JDK が利用可能になるようにローカル環境を設定します。CLASSPATH の設定には、サーバの /bin ディレクトリにある setenv スクリプトを使用できます。

2. 次のコマンド構文を使用します。

   % java weblogic.Deployer [options] [-activate|-deactivate|-remove|-cancel|-list] [files]

また、デプロイ (再デプロイ、アンデプロイ、非アクティブ化、準備解除、または削除) の対象となるアーカイブ内の特定の -files を一覧表示することもできます。ファイル リストには、ファイル名およびアプリケーションのルートを基準にしたディレクトリを含めることができます。ディレクトリを指定すると、サブツリー全体がデプロイまたは再デプロイされます。

weblogic.Deployer のアクションおよびオプション

 

表5-2 weblogic.Deployer のアクション

アクション	説明
activate	-name で指定されたアプリケーションを -targets で指定されたサーバにデプロイまたは再デプロイする。
cancel	-id で識別されるタスクがまだ完了していない場合、そのタスクの取り消しを試みる。
deactivate	対象サーバのアプリケーションを非アクティブ化する。非アクティブ化されると、デプロイ済みのコンポーネントがサスペンドされ、ステージングされていたデータはそのまま残り、その後の再アクティブ化を待つ (このコマンドは 2 フェーズ デプロイメント プロトコルでのみ機能する)。
delete_files	ファイル リストに指定されたファイルを削除し、アプリケーションはアクティブ化したままにしておく。これは、アーカイブされていないアプリケーションにのみ適用される。対象のサーバは必ず指定する。
deploy	-activate の便利なエリアス。
examples	ツールの使用例を表示する。
help	ヘルプ メッセージを出力する。
list	-id で識別されるタスクのステータスを表示する。
remove	アプリケーションおよびステージング済みのデータを対象サーバから物理的に削除する。コンポーネントは非アクティブ化され、対象はアプリケーション コンフィグレーションから削除される。アプリケーションを完全に削除すると、関連する MBean もシステム コンフィグレーションから削除される (このコマンドは 2 フェーズ デプロイメント モデルでのみ機能する)。
undeploy	-unprepare の便利なエリアス。
unprepare	対象サーバ上で -name によって識別されるアプリケーションのクラスを非アクティブ化し、アンロードする。ステージングされたアプリケーション ファイルは、編集またはすぐに再ロードできるような状態で残す。
upload	指定されたソース ファイルを管理サーバに転送する。このオプションは、リモート システムを使用しているときに、リモート システムに常駐するアプリケーションをデプロイする場合に使用する。アプリケーション ファイルは、指定された対象サーバに配布される前に WebLogic Server 管理サーバにアップロードされる。
version	バージョン情報を出力する。

weblogic.Deployer のオプションは以下のとおりです。

 

表5-3 weblogic.Deployer のオプション

オプション	説明
adminurl	https://<server>:<port> が管理サーバの URL。デフォルトは http://localhost:7001。
debug	出力ログのデバッグ メッセージをオンにする。
enforceClusterConstraints	クラスタの 1 つまたは複数のメンバーが使用できない場合に、クラスタへのデプロイメントが成功するか、または失敗するかを指定する。このオプションを「true」に設定すると、デプロイメントはクラスタのすべてのメンバーが使用可能な場合にのみ成功するようになる。
external_stage	ユーザが自身で、またはサードパーティ ツールを使用してサーバのステージング エリアにアプリケーションをコピーすることを示す。このオプションを指定すると、WLS は (対象サーバの) StagingDirectoryName/applicationName の下でアプリケーションを探す。
id	タスク識別子 -id はデプロイメント タスクでユニークな識別子である。-id は、-activate、-deactivate、または -remove コマンドで指定でき、-cancel または -list の引数として使用できる。-id は、既存のデプロイメント タスクすべてを通してユニークでなければならない。指定しない場合、システムが -id を自動的に生成する。
name	アプリケーションの -name には、デプロイされるアプリケーションの名前を指定する。この名前は、既存ないしコンフィグレーション済みのアプリケーション名、または新しいコンフィグレーション作成時に使用する名前でも可。
nostage	アプリケーションをステージングしないで、代わりに、-source オプションで指定した現在の場所からアプリケーションをデプロイする。 デフォルトは、管理サーバが nostage、管理対象サーバが stage。
nowait	アクションが開始されると、ツールがタスク ID を出力して終了する。これは複数のタスクを開始し、-list アクションを使用して後でモニタするために使用する。
output	raw または formatted を指定して、weblogic.Deployer 出力メッセージの表示方法を制御する。いずれの出力タイプでも同じ情報が表示されるが、raw 出力には埋め込みタグが含まれない。デフォルトでは、weblogic.Deployer は raw 出力を表示する。
password	パスワードをコマンドラインで指定する。パスワードを指定しないと、パスワードの入力が求められる。
remote	weblogic.Deployer が管理サーバと同じマシンで動作していないこと、およびソース パスがリモート サーバ上のパスなので変更せずに渡す必要があることを示す。
source	デプロイするアーカイブ、ファイルまたはディレクトリの場所を指定する。このオプションは、アプリケーション パスの設定に使用する。source オプションはルート ディレクトリまたはデプロイされるアーカイブを参照する必要がある。upload コマンドと共に使用すると、ソース パスはカレント ディレクトリに対する相対パスになる。upload を使用しない場合は、管理サーバのルート ディレクトリ、すなわち config.xml ファイルのあるディレクトリに対する相対パスとなる。
stage	デプロイメント前にアプリケーションを対象サーバのステージング ディレクトリにコピーする必要があることを示す。デフォルトは、管理サーバが nostage、管理対象サーバが stage。アプリケーションの作成時に stagingMethod 属性を設定すると、アプリケーションは常にステージングされる。この値は対象サーバの stagingMethod 属性をオーバーライドする。
targets	対象サーバ名とクラスタ名のカンマ区切りのリストを表示する (<server 1>,...<component>@<server N>)。各対象は J2EE コンポーネント名を使用して修飾できる。これによりアーカイブの各種コンポーネントをさまざまなサーバにデプロイできる。現在デプロイされているアプリケーションの場合、デフォルトは現在のすべての対象。新しいアプリケーションの場合、デフォルトで管理サーバにデプロイされる。
timeout	秒数。デプロイメント タスクの完了までの最長時間 (単位 : 秒) を指定する。時間が経過すると、weblogic.Deployer はデプロイメントの現在のステータスを出力して終了する。
user	ユーザ名。
userconfigfile	管理ユーザ名およびパスワードに使用するユーザ コンフィグレーション ファイルの場所を指定する。 このオプションは、自動化されたスクリプト、パスワードを画面上に表示しないようにする場合、または ps などのプロセスレベルのユーティリティにおいて、-user および -password オプションの代わりに使用する。 -userconfigfile オプションを指定する前に、weblogic.Admin STOREUSERCONFIG コマンドを使用してファイルを生成しておく必要がある。
userkeyfile	ユーザ コンフィグレーション ファイル (-userconfigfile オプション) に格納されたユーザ名およびパスワード情報の暗号化および解読に使用するユーザ キー ファイルの場所を指定する。 -userkeyfile オプションを指定する前に、weblogic.Admin STOREUSERCONFIG コマンドを使用してファイルを生成しておく必要がある。
verbose	追加の進行状況メッセージを表示する。

weblogic.Deployer ユーティリティの使用例

weblogic.Deployer ユーティリティの使用例を以下に示します。

新しいアプリケーションをデプロイする

java weblogic.Deployer -adminurl http://admin:7001 -name app -source /myapp/app.ear -targets server1,server2 -activate

新しいアプリケーションをクラスタにデプロイする

java weblogic.Deployer -adminurl http://admin:7001 -name app -source /myapp/app.ear -targets cluster1 -activate -enforceClusterConstraints

アプリケーション全体を再デプロイする

java weblogic.Deployer -source /myapp/app.ear -adminurl http://admin:7001 -name app -activate

注意: -source、つまり更新ファイルのリストを指定しない場合、アプリケーションに変更がないものと見なされるので、この処理は何の効果もありません。

Web アプリケーションを再デプロイするには、コマンドラインで -source および -target オプションの両方を指定する必要があります。

EAR に新しく追加されたモジュールをデプロイする

デプロイ済みのアプリケーション myapp.ear にモジュール newmodule.war を追加し、application.xml ファイルでそのモジュールを更新した場合は、次のコマンドを使用して newmodule.war を myapp.ear にデプロイできます。

java weblogic.Deployer -username myname -password mypassword -name myapp.ear -activate -targets newmodule.war@myserver -source /myapp/myapp.ear

このコマンドは、アプリケーション内のその他のモジュールは再デプロイせずに、新しいモジュールをデプロイします。

展開されたアプリケーションの一部を再デプロイ (更新) する

java weblogic.Deployer -adminurl http://admin:7001 -name app  -activate jsps/login.jsp

ここで、jsps は、展開された Web アプリケーションの最上位のディレクトリです。部分的な再デプロイメントは展開された WAR ファイルに関してのみサポートされています。パスは、元々デプロイされているアプリケーションのルートに対する相対パスです。 たとえば、作業ディレクトリで login.jsp ファイルを変更した場合、weblogic.Deployer コマンドを入力する前に、更新したファイルを、展開されたアプリケーションの適切なソース ディレクトリにコピーする必要があります。

すべてのアクティブな対象でアプリケーションを非アクティブ化する (使用不可にする)

java weblogic.Deployer -adminurl http://admin:7001 -name app  -deactivate

非アクティブ化したアプリケーションを再アクティブ化する

 java weblogic.Deployer -adminurl http://7001 -name app -activate

すべての対象サーバからアプリケーションを削除する

java weblogic.Deployer -adminurl http://admin:7001 -name app -targets server -remove

デプロイメント タスクを取り消す

java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag

すべてのデプロイメント タスクの表示

java weblogic.Deployer -adminurl http://admin:7001 -list

単一のサーバにアプリケーションをデプロイまたは再デプロイする

java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1

アプリケーションを追加サーバにデプロイする

java weblogic.Deployer -activate -name ArchivedEarJar -target server2

wldeploy Ant タスク

wldeploy Ant タスクを使用すると、Ant .xml ファイルで指定した属性を使用して weblogic.Deployer の機能を実行できます。 他の WebLogic Server Ant タスクと一緒に wldeploy を使用して、次のような単一の Ant ビルド スクリプトを作成できます。

• wlserver および wlconfig Ant タスクを使用して、新しい WebLogic Server ドメインを作成、起動、およびコンフィグレーションする。

• wldeploy Ant タスクを使用して、コンパイル済みアプリケーションを、新しく作成されたドメインにデプロイする。

wlserver および wlconfig の詳細については、『管理者ガイド』の「Ant タスクを使用した WebLogic Server ドメインのコンフィグレーション」を参照してください。

注意: WebLogic Server Ant タスクは、1.5 より前のバージョンの Ant とは互換性がありません。 また、WebLogic Server に含まれていないバージョンの Ant を使用する場合は、wldeploy を使用する基本手順の説明に従って、build.xml ファイルで wldeploy タスク定義を指定する必要があります。

wldeploy を使用する基本手順

wldeploy Ant タスクを使用するには、次の手順に従います。

1. 環境を設定します。

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

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

2. ステージング ディレクトリで、Ant ビルド ファイル (デフォルトは build.xml) を作成します。 WebLogic Server と一緒にインストールされているものとは異なる Ant を使用する場合は、最初に wldeploy Ant タスク定義を定義します。

   <taskdef name="wldeploy" classname="weblogic.ant.taskdefs.management.WLDeploy"/>

3. 必要に応じて、wlserver および wlconfig タスクのタスク定義と呼び出しをビルド スクリプトに追加して、新しい WebLogic Server ドメインを作成および起動します。 wlserver および wlconfig の詳細については、『WebLogic Server コマンド リファレンス』の「Ant タスクを使用した WebLogic Server ドメインのコンフィグレーション」を参照してください。

4. wldeploy の呼び出しを追加して、1 つまたは複数の WebLogic Server インスタンスまたはクラスタにアプリケーションをデプロイします。 wldeploy のサンプルの build.xml ファイルおよびwldeploy Ant タスクのリファレンスを参照してください。

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

   prompt> ant

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

次の出力は、アプリケーションを単一の WebLogic Server インスタンスにデプロイする wldeploy ターゲットを示しています。

<target name="deploy">
   <wldeploy action="activate"
      source="${build}/ejb11_basic_statelessSession.ear" name="ejbapp"
      user="a" password="a" verbose="true" adminurl="t3://localhost:7001"
      debug="true" targets="myserver"/>
</target>

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

次の表では、wldeploy Ant タスクの属性について説明します。 さまざまな用語の定義については、weblogic.Deployer のアクションおよびオプションを参照してください。

表5-4 wldeploy Ant タスクの属性

属性	説明	データ型	必須/省略可能
action	実行するデプロイメント アクション。 有効な値は、activate、deactivate、remove、cancel、list および unprepare。	String	省略可能
adminurl	管理サーバの URL。	String	省略可能
debug	wldeploy デバッグ メッセージを有効にする。	boolean	省略可能
id	ステータスの取得やデプロイメントの取り消しに使用される ID。	String	省略可能
name	デプロイ済みのアプリケーションのデプロイメント名。	String	省略可能
nostage	デプロイメントで nostage デプロイメント モードを使用するかどうかを指定する。	boolean	省略可能
nowait	wldeploy が (バックグラウンド タスクとしてデプロイすることによって) デプロイメント呼び出しの後直ちに復帰するかどうかを指定する。	boolean	省略可能
user	管理ユーザ名。	String	省略可能
password	管理パスワード。 ビルド ファイルまたは ps などのプロセス ユーティリティでプレーン テキストのパスワードを表示しないようにするには、まず、weblogic.Admin STOREUSERCONFIG コマンドを使用して、有効なユーザ名と暗号化されたパスワードをコンフィグレーション ファイルに格納する。 次に、Ant ビルド ファイルで username および password 属性の両方を省略する。 この属性を省略した場合、wldeploy はデフォルトのコンフィグレーション ファイルから取得した値を使用してログインしようとする。 デフォルト以外のコンフィグレーション ファイルおよびキー ファイルからユーザ名とパスワードを取得する場合は、wldeploy と一緒に userconfigfile および userkeyfile 属性を使用する。	String	省略可能
remote	サーバが別のマシンに配置されているかどうかを指定する。 これはファイル名の転送方法に影響する。	boolean	省略可能
source	デプロイするソース ファイル。	ファイル	省略可能
targets	デプロイ先となる対象サーバのリスト。	String	省略可能
timeout	デプロイメントが正常に終了するまでの最長待ち時間。	int	省略可能
userconfigfile	管理ユーザ名およびパスワードを取得するために使用するユーザ コンフィグレーション ファイルの場所を指定する。 このオプションは、プレーン テキストのパスワードをインラインで表示しないようにする場合や ps などのプロセスレベルのユーティリティにおいて、ビルド ファイルで user および password 属性の代わりに使用する。 「WebLogic Server コマンドライン リファレンス」の「STOREUSERCONFIG」で説明しているように、userconfigfile 属性を指定する前に、weblogic.Admin STOREUSERCONFIG コマンドを使用してファイルを生成しておく必要がある。	ファイル	省略可能
userkeyfile	ユーザ コンフィグレーション ファイル (userconfigfile 属性) に格納されたユーザ名およびパスワード情報の暗号化および解読に使用するユーザ キー ファイルの場所を指定する。 userkeyfile 属性を指定する前に、weblogic.Admin STOREUSERCONFIG コマンドを使用してファイルを生成しておく必要がある。	ファイル	省略可能
verbose	wldeploy で冗長出力メッセージを表示するかどうかを指定する。	boolean	省略可能
failonerror	WebLogic Server Ant タスクで使用されるグローバル属性。 ビルド中にエラーが発生した場合、タスクが失敗するかどうかを指定する。 この属性はデフォルトで true に設定される。	Boolean	省略可能

WebLogic Server Administration Console

この節では、Administration Console によるデプロイメント タスクの実行について説明します。Administration Console は、weblogic.Deployer ユーティリティと同じ機能をサポートしています。この機能によって、デプロイヤは新しいまたは更新したアプリケーションの提出、ステータスのクエリ、および保留中のデプロイメントの削除を行うことができます。

Administration Console を使用した J2EE アプリケーション デプロイメントのコンフィグレーション

WebLogic Server Administration Console を使用して J2EE アプリケーションをコンフィグレーションする手順は次のとおりです。

1. WebLogic Server Administration Console を起動します。

2. 作業を行うドメインを選択します。

3. Administration Console の左ペインで、[デプロイメント] をクリックします。

4. Administration Console の左ペインで、[アプリケーション] をクリックします。Administration Console の右ペインにテーブルが現れ、デプロイ済みのすべての J2EE アプリケーションが表示されます。

5. [新しい Application のコンフィグレーション] オプションを選択します。

6. コンフィグレーションするアーカイブ ファイル (WAR、EAR、RAR、JAR) の場所を確認します。

   注意: 展開されたアプリケーションやコンポーネント ディレクトリのコンフィグレーションを行うこともできます。WebLogic Server では、指定されたディレクトリおよびその下位のディレクトリにあるコンポーネントがすべてデプロイされることに注意してください。

7. ディレクトリまたはファイルの左の [選択] をクリックして選択し、次の操作に進みます。

8. [使用可能なサーバ] から対象サーバを選択します。

9. アプリケーションの名前を表示されたフィールドに入力します。

10. [コンフィグレーションとデプロイ] をクリックします。Administration Console によって [デプロイ] パネルが表示され、ここに対象 J2EE アプリケーションのデプロイメント ステータスおよびデプロイメント作業が示されます。

11. 使用できるタブで、以下の情報を入力します。

    • [コンフィグレーション] − ステージング モードを編集し、デプロイメント順を入力します。

    • [対象] − デプロイ先のサーバを [選択可] リストから [選択済み] リストに移動して、コンフィグレーション済み J2EE アプリケーションの対象サーバを指定します。

    注意: 対象を選択しない場合は、アプリケーションのコンフィグレーションだけが行われ、デプロイされません。mydomain/applications ディレクトリでこのアプリケーションにアクセスして、後で変更およびデプロイすることができます。

    • [デプロイ/アンデプロイ] − J2EE アプリケーションをすべてまたは選択した対象にデプロイするか、もしくは、すべてまたは選択した対象からアンデプロイします。J2EE アプリケーションをアンデプロイします。[デプロイ/アンデプロイ] はトグル オプションです。

    • [モニタ] − J2EE アプリケーションのセッション モニタを有効にします。

    • [メモ] − J2EE アプリケーションに関連するメモを入力します。

Administration Console を使用した J2EE アプリケーションのデプロイメント

WebLogic Server Administration Console を使用して J2EE アプリケーションをデプロイする手順は次のとおりです。

1. 左ペインの [デプロイメント] ノードを展開します。

2. [アプリケーション] ノードを右クリックします。

3. [新しい Application のコンフィグレーション] を選択します。

4. コンフィグレーションする展開されたアプリケーションを格納するアーカイブ (WAR、EAR、RAR、JAR) またはディレクトリの場所を確認します。

5. ディレクトリまたはファイルの左の [選択] をクリックして選択し、次の操作に進みます。ディレクトリを指定した場合、WebLogic Server は指定されたディレクトリおよびその下位のディレクトリにあるコンポーネントをすべてデプロイします。

6. [使用可能なサーバ] から対象サーバを選択します。

7. J2EE アプリケーションの名前を表示されたフィールドに入力します。

8. [コンフィグレーションとデプロイ] をクリックします。Administration Console によって [デプロイ] パネルが表示され、ここに対象 J2EE アプリケーションのデプロイメント ステータスおよびデプロイメント作業が示されます。

9. [デプロイ] ボタンを使って、その J2EE アプリケーションをすべてまたは選択した対象にデプロイするか、あるいは、すべてまたは選択した対象からアンデプロイします。

10. Web ブラウザからリソースにアクセスして、J2EE アプリケーションをテストします。次の URL からリソースにアクセスします。

    http://myServer:myPort/myApp/resource

    各値の説明は次のとおりです。

    • myServer は、WebLogic Server のホスト マシンの名前を表す。

    • myPort は、WebLogic Server がリクエストをリスンしているポート番号を表す。

    • myApp は、J2EE アプリケーション アーカイブ ファイルの名前 (myApp.ear など)、または J2EE アプリケーションを含むディレクトリの名前を表す。

    • resource は、JSP、HTTP サーブレット、HTML ページなどのリソースの名前を表す。

Administration Console を使用したデプロイ済みコンポーネントの参照

デプロイされたコンポーネントを Administration Console で表示する手順は次のとおりです。

1. Administration Console の左パネルから [デプロイメント] の下の [コンポーネント] を選択します。

2. 右ペインの [デプロイメント] テーブルでデプロイ済みのコンポーネントのリストを参照します。

Administration Console を使用したコンポーネントのアンデプロイメント

WebLogic Server Administration Console を使用してデプロイされているコンポーネントをアンデプロイする手順は次のとおりです。

1. Administration Console の左パネルから [デプロイメント] の下の [コンポーネント] を選択します。

2. コンポーネントの [デプロイメント] テーブルで、アンデプロイするコンポーネントを選択します。

3. [適用] をクリックします。

コンポーネントをアンデプロイしても、コンポーネント名は WebLogic Server から削除されません。コンポーネントは、Server セッションが終了するまでアンデプロイされた状態が続きます。ただし、アンデプロイ後にコンポーネントを変更した場合を除きます。サーバを再起動するまで、deploy 引数でデプロイメント名を再使用することはできません。次の節で説明するように、デプロイメントの更新にそのデプロイメント名を再使用できます。

Administration Console によるアプリケーションの更新

デプロイ済みの J2EE アプリケーションを更新する手順は次のとおりです。

1. Administration Console で、[デプロイメント] をクリックします。

2. [アプリケーション] オプションをクリックします。

3. 表示されたテーブルで、更新するアプリケーションの名前をクリックします。

4. 必要に応じてアプリケーション名とデプロイ ステータスを更新します。

   注意: 再デプロイ中には、アプリケーションがクライアントから使用できなくなります。 そのため、プロダクション環境では再デプロイメントを使用しないことをお勧めします。

5. [適用] をクリックします。

デプロイ済みアプリケーションにモジュールを追加し、追加したモジュールをデプロイする手順は次のとおりです。

1. 上記の手順 1 〜 5 によって、アプリケーションを再デプロイしてモジュールを追加します。

2. [デプロイメント｜アプリケーション] タブで表示されるテーブルのモジュール名をクリックします。>

3. [対象] タブを選択します。

4. 使用したいサーバを [選択可] 領域から [選択済み] 領域に移動し、[適用] をクリックします。

WebLogic Builder

WebLogic Builder は、J2EE アプリケーションのデプロイメント記述子を生成および編集するための WebLogic Server ツールです。このツールでは、単一のサーバにアプリケーションをデプロイすることもできます。

「WebLogic Builder」を参照してください。

自動デプロイメント

自動デプロイメントは、管理サーバにアプリケーションを迅速にデプロイするための手段です。自動デプロイメントは、アプリケーションをテストするための単一サーバの開発環境でのみ使用してください。プロダクション環境で使用したり、管理対象サーバにコンポーネントをデプロイするために使用したりすることは避けてください。

自動デプロイメントが有効な場合は、アプリケーションが管理サーバの ¥applications ディレクトリにコピーされると、その管理サーバは新しいアプリケーションの存在を検出し、それを自動的にデプロイします (管理サーバが動作している場合)。アプリケーションを ¥applications ディレクトリにコピーしたときに WebLogic Server が稼働していない場合、そのアプリケーションは WebLogic Server が次に起動したときにデプロイされます。自動デプロイメントは管理サーバに対してのみデプロイします。

注意: Windows NT では厳格なファイル ロック制限により、アプリケーションが展開された場合、アプリケーション内のすべてのコンポーネントも展開されます。すなわち、WebLogic Server では展開されたアプリケーションまたはコンポーネント内に JAR ファイルを入れることはできません。

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

WebLogic Server は、開発環境とプロダクション環境の 2 つの異なるモードで実行できます。開発モードは、アプリケーションをテストする場合に使用します。プロダクション環境への準備が整ったら、プロダクション モードで起動されたサーバにアプリケーションをデプロイします。

開発モードを使用すると、WebLogic Server は domain_name/applications ディレクトリ (domain_name は WebLogic Server のドメイン名) にあるアプリケーションを自動的にデプロイおよび更新します。つまり、開発モードでは自動デプロイを使用することになります。

プロダクション モードでは、自動デプロイメント機能は無効になります。代わりに、WebLogic Server Administration Console または weblogic.Deployer ツールを使用する必要があります。

デフォルトでは、WebLogic Server は開発モードで稼働します。サーバのモードを指定するには、以下のいずれかを実行します。

startWebLogic 起動スクリプトを使用する場合は、スクリプトを編集し、STARTMODE 変数を次のように設定します。

STARTMODE = false (開発モードを有効にする)

STARTMODE = true (プロダクション モードを有効にする)

コマンドラインで直接 weblogic.Server コマンドを入力してサーバを起動する場合、次のように -Dweblogic.ProductionModeEnabled オプションを使用します。

-Dweblogic.ProductionModeEnabled=false (開発モードを有効にする)

-Dweblogic.ProductionModeEnabled=true (プロダクション モードを有効にする)

開発モードおよびプロダクション モードにおける WebLogic Server の起動の詳細については、「WebLogic Server の起動と停止」を参照してください。

アプリケーションの自動デプロイメント

この機能は、開発中にアプリケーションをデプロイする場合に便利です。この機能を使用すると、あらかじめ定義しておいた自動デプロイメント ディレクトリにデプロイメントをコピーするだけで、アプリケーションまたは個々の J2EE モジュールが管理サーバにデプロイされます。このディレクトリはドメイン ディレクトリの下、たとえば、mydomain/applications にあります。

アーカイブされたアプリケーションのアンデプロイメントと再デプロイメント

自動デプロイされたアプリケーションまたはそのコンポーネントは、サーバの稼働時に動的に再デプロイできます。JAR、WAR、または EAR ファイルを動的に再デプロイするには、このファイルの新バージョンを、¥applications ディレクトリ内の既存のファイルに上書きコピーするだけです。

この機能を使用すると、開発者はメイクファイルの最後のステップとして ¥applications ディレクトリへのコピーを追加するだけで、サーバを更新できます。

アプリケーションを ¥applications ディレクトリから削除すると、そのアプリケーションはアンデプロイされ、コンフィグレーションから削除されます。

展開形式によるアプリケーションの再デプロイメント

展開形式で自動デプロイされたアプリケーションまたはコンポーネントも、動的に再デプロイできます。アプリケーションが展開形式でデプロイされている場合、管理サーバは、展開されたアプリケーションのディレクトリ内で 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 ファイルのタイムスタンプを更新します。

管理サーバは、タイムスタンプの変更を検出すると、展開されたディレクトリの内容を再デプロイします。

デプロイメント管理 API

デプロイメント タスクは、DeployerRuntimeMBean という、WebLogic 管理サーバに常駐するシングルトン (インスタンスが 1 つしかないオブジェクト) によって開始されます。この DeployerRuntimeMBean によって、アプリケーションをアクティブ化、非アクティブ化、および削除するためのメソッドが提供されます。これらのメソッドは、要求をカプセル化し、その進行状況を追跡する手段を提供する DeploymentTaskRuntimeMBean を返します。DeploymentTaskRuntimeMBean は、TargetStatus オブジェクトによってデプロイ先ごとに要求に関する処理ステータスを示します。

WebLogic Server デプロイメント管理 API は、以下の WebLogic Server MBean によって定義されます。

• DeployerRuntimeMBean - デプロイメント要求へのプログラム的なインタフェース。DeployerRuntimeMBean によってデプロイメント要求が行われると、アプリケーションと該当するコンポーネント コンフィグレーション MBean に対して、コンフィグレーション ステートが示されます。これらの MBean は、アプリケーションのデプロイメント ステートを WebLogic Server ドメインに保持します。

• DeploymentTaskRuntimeMBean - さまざまなデプロイメント タスクへのインタフェース。

デプロイメント管理 API は非同期です。クライアントは、ステータスをポーリングするか、ApplicationMBean 通知を使用してタスクがいつ完了したかを判別します。

WebLogic Serverのデプロイメント管理 API の詳細については、weblogic.management.deploy Javadoc を参照してください。

 

---

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

実際にアプリケーションをデプロイする場合のベスト プラクティスを以下に示します。

単一サーバでのデプロイメント

繰り返しデプロイメントが行われる環境では、すべてのファイルを展開形式で維持し、アプリケーションをソースの場所から直接デプロイする方法がもっとも効率的です。

単一サーバ環境 (管理サーバだけにデプロイ) で作業している場合、ディレクトリ ベースの自動デプロイメントを使用できます。すなわち、展開されたアプリケーションを mydomain/applications ディレクトリに配置するだけで、アプリケーションをデプロイできます。 詳細については、このマニュアルの「自動デプロイメント」を参照してください。

Web アプリケーションまたは Web サービスの変更テスト

• mydomain/applications ディレクトリにあるアプリケーションの JSP ファイルまたは静的データ ファイルを変更して、アプリケーションで変更を表示できます。

• 更新したサーブレット クラスを、mydomain/applications ディレクトリの Web アプリケーション (mydomain/applications/exploded_web_app_dir/WEB-INF/classes など) に直接コンパイルすることもできます。新しいクラスは Web アプリケーションに組み込まれ、追加手順は必要ありません。

• Web アプリケーション デプロイメント記述子に対する変更を組み込むには、mydomain/applications ディレクトリの WEB-INF/REDEPLOY ファイルを変更します。これによって自動デプロイヤがその変更を検出します。Web アプリケーションが再デプロイされます。

EJB およびリソース アダプタの変更テスト

EJB またはリソース アダプタ デプロイメント記述子に対する変更を組み込むには、mydomain/applications ディレクトリの META-INF/REDEPLOY ファイルを変更します。これによって、自動デプロイヤがその変更を検出します。EJB またはリソース アダプタが再デプロイされます。

注意: EJB がエンタープライズ アプリケーションの一部になっている場合、そのアプリケーション全体が再デプロイされます。

複数サーバでのデプロイメント

複数サーバ環境で作業している場合、weblogic.Deployer ツールを使用してアプリケーションをデプロイすることをお勧めします。

複数サーバ環境における変更テスト

アプリケーション ファイルに対して変更を行った場合、weblogic.Deployer ツールを使用してその変更をサーバに伝達する必要があります。サーバに伝達することにより、変更がデプロイ済みアプリケーションに組み込まれます。

Web アプリケーションに対する変更をサーバに伝達する方法を以下の手順で示します。この手順は、どのタイプのアプリケーションでも同じです。ただし、EJB がエンタープライズ アプリケーションに含まれる場合、アプリケーションおよびそのコンポーネント全体が再デプロイされます。

1. Administration Console または次のコマンドを使用して、Web アプリケーションをデプロイします。

   java weblogic.Deployer -adminurl http://adminAddr:7001 -name webapp -activate -source /myapp/webapp -targets managedserver1,managedserver2

2. JSP: /myapp/webapp/jsps/login.jsp に対して必要な変更を行います。

3. 行った変更を以下のように適用します。

   java weblogic.Deployer -adminurl http://adminAddr:7001 -name webapp -activate jsps/login.jsp

上記の例では、login.jsp が、Web アプリケーションがデプロイされているすべてのサーバに配布され、組み込まれます。

展開されたアプリケーションのファイル構造

デプロイ可能なユニットのパッケージ化の詳細については、「WebLogic Server アプリケーションのパッケージ化」を参照してください。

ディレクトリに複数のモジュールがあるが、全体的なアプリケーション記述子ファイルがない場合は、各モジュールを独自のディレクトリに格納し、独自の記述子ファイルを含める必要があります。つまり、非アーカイブ アプリケーションでは、アーカイブ内と同じく、各モジュールが他のモジュールと互いに独立していなければなりません。

sourceDirectory¥

               ¥Module1
                     WEB-INF¥
                             web.xml
                             Module1FilesDir

               ¥Module2
                     META-INF¥
                             ejb-jar.xml 
                             Module2FilesDir 

非 EAR デプロイメントを展開した場合、ソース ディレクトリは必ず A または B となる必要があります。

A.

 ¥Module1
         WEB-INF¥
                web.xml
                Module1FilesDir

B.

 ¥Module1
         WEB-INF¥
                web.xml
                Module1FilesDir

 ¥Module2
         META-INF¥
                ejb-jar.xml 
                Module2FilesDir 
 ¥Module3
         META-INF¥
                ra.xml 
                Module3FilesDir 

以下のディレクトリ構造はサポートされていないので、無効です。

sourceDirectory/

       META-INF¥ejb-jar.xml

       WEB-INF¥web.xml

       webfiles/

       ejbfiles/

moduledir/

       WEB-INF¥web.xml

       webfiles

       ejb.jar

moduledir/

       WEB-INF¥web.xml

       web1files

       web2/WEB-INF/web.xml

       web2/webfiles

ステージング モード

管理サーバの場合には nostage、管理対象サーバの場合には stage というデフォルト値を使用します。ただし、以下の場合を除きます。

• 管理サーバから管理対象サーバ マシンへのファイル コピーおよび配布管理にサードパーティのソリューションを使用する場合

• ドメイン内の異なるサーバ間でアプリケーション ソースを共有するため共有ファイル システムを使用する場合

自動デプロイメント

単一サーバ デプロイメントの開発設定では、自動デプロイメントのみ使用します。

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

複数モジュールによる展開デプロイメントでは、常に META-INF/application.xml で定義されたアプリケーション記述子を使用します。

部分的な再デプロイメント

モジュールまたはファイルを、アプリケーションの、参照を持つ他のモジュールに再デプロイする場合は、参照しているモジュールも再デプロイする必要があります。

エンタープライズ アプリケーションの一部であるコンポーネント間のクラス共有

エンタープライズ アプリケーションの一部であるコンポーネント間でクラスを共有するには、MANIFEST クラスパスを使用します。共有クラスを含む JAR ユーティリティは、その他のコンポーネント アーカイブの次に EAR にパッケージ化されます。これらのクラスを使用する各コンポーネントは、コンポーネント アーカイブ内の META-INF/MANIFEST.MF というファイルに Class-Path エントリを作成します。この方法は J2EE 標準の一部であり、アプリケーション サーバ間での移植性が必要な場合に使用します。

詳細については、マニフェスト クラスパスを参照してください。

 

---

WebLogic Server 6.x のデプロイメント プロトコルの使用

デフォルトでは、利用可能なすべてのデプロイメント ツールによって新しいアプリケーションをデプロイする場合は、2 フェーズ デプロイメント プロトコルが使用されます。現在の管理サーバでも、WebLogic Server 6.x デプロイメント プロトコルはサポートされています。このプロトコルは以下の場合に使用します。

• コンフィグレーション済みのアプリケーションで、2 フェーズ デプロイメント プロトコルを指定 (ApplicationMBean.TwoPhase=true) しない場合

• アプリケーションに複数のモジュールがあり、かつ EAR ではない場合

6.x のプロトコルを使用するアプリケーションを 2 フェーズ プロトコルを使用するようにコンフィグレーションするには、次のように、ドメインからアプリケーションを削除 (コンフィグレーションを削除) してから、アプリケーションを再度アクティブ化します。

1. weblogic.Deployer を使用してアプリケーションを削除します。次の形式でコマンドを入力します。

java weblogic.Deployer -adminurl http://admin:7001 -name app -targets server -remove

2. weblogic.Deployer を使用してアプリケーションを再度アクティブ化します。次の形式でコマンドを入力します。

java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1

新しいプロトコルを使用してアプリケーションが再デプロイされます。

 

---

デプロイメント補足ドキュメント

WebLogic Server デプロイメントの詳細については、以下のマニュアルを参照してください。

マニュアル	デプロイメントのトピック
WebLogic Builder	WebLogic Builder を使用して、J2EE アプリケーションおよびそのコンポーネント用の XML デプロイメント記述子ファイルを編集、生成する方法
Administration Console オンライン ヘルプ	デプロイメント タスクにおける Administration Console の使用方法
「クラスタのコンフィグレーションとアプリケーションのデプロイメント」	クラスタ化されたサーバへのデプロイ方法
WebLogic エンタープライズ Java Beans プログラマーズ ガイド	WebLogic Server EJB のデプロイ方法
WebLogic J2EE コネクタ アーキテクチャ	WebLogic Server J2EE コネクタのデプロイ方法
Web アプリケーションのアセンブルとコンフィグレーション	Weblogic Server Web アプリケーションのデプロイ方法
WebLogic JSP プログラマーズ ガイド	JSP からのアプレットのデプロイ方法
WebLogic Server アプリケーションのパッケージ化	WebLogic Server アプリケーション コンポーネントのパッケージ方法