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

現在WebLogic Serverドメインにデプロイされているアプリケーションおよびモジュールの一般的なメンテナンス・タスクを実行する方法を学習します。

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

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

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

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

• アプリケーションおよびモジュールのパラレル・デプロイメントの有効化

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

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

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

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

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

• ReadyAppフレームワークの使用

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

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 password 
   -name myapp.ear -deploy -targets newmodule.war@myserver 
   -source /myapp/myapp.ear

このコマンドでは、アプリケーション内のその他のモジュールは再デプロイせずに、新しいモジュールをデプロイします。EARファイル内のアーカイブされたモジュールの正しいファイル拡張子(上の例では.war)を指定する必要があります。

アプリケーションおよびモジュールのパラレル・デプロイメントの有効化

複数のアプリケーションのデプロイメントまたは複数のモジュールを含む単一アプリケーションのデプロイメントが必要なユース・ケースの場合、パラレル・デプロイメントによって、サーバーの起動など、起動時間と実行後デプロイメント時間が改善されます。

マルチテナント環境の場合、パラレル・デプロイメントによって、複数のパーティション間での複数のアプリケーションのデプロイメントが改善されます。『WebLogic Server MTの使用』のマルチテナント環境でのパラレル・デプロイメントの有効化に関する項を参照してください。

アプリケーションとリソースをデプロイする場合、それらは、まずデプロイメント全体のタイプに基づきセットにソートされます。次に、「サーバー起動時のデプロイメント順序の変更」で説明する順序に従い、各セットはデプロイメント・プロセスを開始します。

一連のアプリケーション内で、デプロイメント順序番号が同じアプリケーションを相互に並行してデプロイできるため、パフォーマンスが向上します。

ノート:

デフォルトで、WebLogic Server 12.2.1以降で作成または更新されたWebLogicドメインでは、アプリケーションのパラレル・デプロイメントは有効化されています。(モジュールのパラレル・デプロイメントはデフォルトで無効化されています。)

バージョン12.2.1より前のWebLogic Serverインスタンスで実行されるアプリケーションには、内部依存関係が存在する場合があり、これはデプロイメント順序で指定する必要があります。そのデプロイメント順序を指定しない場合、WebLogic Serverはその依存関係を検出できません。こうした依存関係は、12.2.1より前のWebLogic Serverでシリアル・デプロイメントを使用していれば満たされていました。しかし、シリアル・デプロイメントからパラレル・デプロイメントに移行するときに、これらの依存関係で違反が発生するリスクがあり、その違反のためにデプロイメントが失敗する場合があります。したがって、バージョン12.2.1より前のWebLogic Serverで作成したドメインでは、パラレル・デプロイメントがデフォルトで無効になっています。『Oracle WebLogic Serverのアップグレード』のパラレル・デプロイメントに関する項を参照してください。

次の項では、アプリケーション・アーカイブ内のアプリケーションおよびモジュールのパラレル・デプロイメントを有効にする方法について説明します。

• アプリケーションのパラレル・デプロイメントの有効化

• モジュールのパラレル・デプロイメントの有効化

アプリケーションのパラレル・デプロイメントの有効化

アプリケーションのパラレル・デプロイメントを有効にするには、DomainMBeanのParallelDeployApplications属性を構成します。この属性が有効な場合、デプロイメント順序が同じアプリケーションは相互に並行してデプロイされるため、パフォーマンスが向上します。ParallelDeployApplications属性はデフォルトで有効化されています。

リソースとアプリケーションの全体のデプロイ順序は変更されないため、通常のデプロイ順序でアプリケーションよりも優先されるデプロイメント・タイプ(JDBCシステム・リソースやJava EEライブラリなど)が、アプリケーションがデプロイされる前に完全にデプロイされることが保証されます。

ノート:

相互依存のないアプリケーションのみを並行してデプロイする必要があります。あるアプリケーションが他のアプリケーションに依存する場合、このアプリケーションの依存関係順序は、依存する対象のアプリケーションよりも高くなる必要があります。そうでない場合、その依存する対象のアプリケーションのデプロイメント前に依存アプリケーションでデプロイが試行されると、パラレルのアクティブ化で依存の失敗が発生する可能性があります。

モジュールのパラレル・デプロイメントの有効化

1つのアプリケーション・アーカイブ内のモジュールを相互に並行してデプロイするように構成できます。ドメイン内のすべてのアプリケーションのモジュールのパラレル・デプロイメントを有効にするには、DomainMBeanのParallelDeployApplicationModules属性を構成します。ParallelDeployApplicationModules属性はデフォルトで無効です。

アプリケーションごとにモジュールの並行デプロイを有効化するには、AppDeploymentMBeanのParallelDeployModules属性を構成します。この属性を設定すると、個々のアプリケーションのドメイン値がオーバーライドされます。

ノート:

交差依存のないモジュールが含まれるアプリケーションのモジュールのパラレル・デプロイメントのみ有効にすることができます。モジュールが他のモジュールに依存する場合、その依存する対象のモジュールのデプロイメント前に依存モジュールでデプロイが試行されると、パラレル・デプロイメントで依存の失敗が発生する可能性があります。

ノート:

アプリケーションについてJava EEの<initialize-in-order>要素を指定してtrueに設定する場合、モジュールのパラレル・デプロイメントが有効か無効かに関係なく、アプリケーション内のモジュールは、application.xmlで定義されている順序に従いデプロイされます。

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

デフォルトでは、WebLogic Serverは特定の順序でアプリケーションおよびリソースをデプロイします。

1. キャッシュ

2. 内部アプリケーション

3. JDBCシステム・リソース

4. デプロイメント・ハンドラ

5. JMSシステム・リソース

6. リソース依存デプロイメント・ハンドラ

7. 起動クラス

8. WLDFシステム・リソース

9. Java EEライブラリおよびオプション・パッケージ

10. アプリケーションおよびスタンドアロン・モジュール

11. Coherenceクラスタ・システム・リソース

12. カスタム・システム・リソース(このモジュール・タイプはcustom-resourceデプロイメント・ディスクリプタ(DD)要素にマップされます)

    ノート:

    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 Administration Consoleオンライン・ヘルプ』の起動クラスの構成に関する項を参照してください。

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

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

「図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アプリケーションをデプロイする場合は、2つの方法のいずれかで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を使用すると、デプロイメント・コマンドで使用する独自のタスク識別番号を割り当てたり、長時間実行中のデプロイメント・タスクをモニターしたり取り消したりできます。

たとえば、以下のコマンドでは、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()

ReadyAppフレームワークの使用

ReadyAppフレームワークでは、フレームワークに登録されているアプリケーションのREADYまたはNOT READY状態を宣言できます。このフレームワークによって、完全には機能していないWebLogic Serverインスタンスにトラフィックがルーティングされなくなります。

WebLogic Serverにデプロイされたアプリケーションで初期化中に非同期の動作が発生すると、WebLogic Serverはアプリケーションが初期化を終了する前にRUNNING状態になる場合があります。この状況では、ロード・バランサまたはWebLogic Serverのその他のインスタンスが、まだ完全に機能していないサーバーに早期にトラフィックをルーティングする可能性があります。アプリケーションがリクエストを処理する準備ができているかどうかの判断をサーバーに依存すると、結果がエラーになる場合があります。

ReadyAppフレームワークにはREADYおよびNOT READY状態が導入されており、これを使用して、内部や外部のアプリケーションは、そのアプリケーションが動作しているサーバーおよびパーティションの状態に影響を及ぼすことができます。

たとえば、ReadyAppフレームワークに登録されたアプリケーションがRUNNING状態のWebLogic Serverのインスタンスからのリクエストを処理する準備ができていない場合、サーバー状態はアプリケーションがready()メソッドを呼び出すまではNOT READYに設定されます。

EARベースまたはWARベースのアプリケーションによるReadyAppフレームワークの構成

ReadyAppフレームワークを使用するには、次のコードをアプリケーションのWebLogicデプロイメント・ディスクリプタ(META-INF\weblogic-application.xml)に追加することでEARベースまたはWARベースのアプリケーションをフレームワークに登録します。

<wls:ready-registration>true</wls:ready-registration>

アプリケーションが起動すると、状態はNOT READYに設定されます。ReadyAppフレームワークに登録されたアプリケーションは、いずれもアプリケーションがWebLogic Serverからアンデプロイされたときに自動的に登録解除されます。

ノート:

接頭辞wls:は、weblogic-application.xmlファイルの内容によっては必要でない場合があります。他のタグに接頭辞がない場合、接頭辞を無視できます。

アプリケーションが初期化を終了してリクエストを処理する準備ができたら、初期化が完了したコードに次の行を追加することでアプリケーションをREADY状態に設定します。

weblogic.application.ready.ReadyLifecycleManager.getInstance().ready();

ready()メソッドに対する呼出しが、アプリケーションがリクエストを処理する準備ができていることをReadyAppフレームワークに示します。ただし、アプリケーションのREADY状態はサーバーまたはパーティションの準備ができていることを意味しません。サーバーまたはパーティションの準備ができる前に、登録された他のすべてのアプリケーションの準備ができていることを示す必要があります。

アプリケーションでリクエストの処理を停止する必要がある場合、(たとえばアプリケーションの再初期化が必要な場合)、次のメソッドを使用してアプリケーションの準備ができていないことを示します。

weblogic.application.ready.ReadyLifecycleManager.getInstance().notReady();

ノート:

アプリケーションがnotReady()メソッドを呼び出した後、アプリケーションがデプロイされたサーバーまたはパーティションはアプリケーションがready()メソッドを再度呼び出すまでNOT READY状態のままになります。

ready()およびnotReady()メソッドは、次のランタイム例外を引き起こす可能性があります。

• IllegalArgumentException: この例外は、コンポーネント起動コンテキストにより報告されたapplicationIdがnullのときに発生します。

• IllegalStateException: この例外は、アプリケーションが正しく登録されていないときに発生します。デプロイメント・ディスクリプタが適切に設定されていることを確認してください。

ReadyAppフレームワークのモニター

ReadyAppフレームワークの実行ステータスを確認するには、次のいずれかのメソッドを使用します。

• ReadyAppサーブレットのURLにアクセスします。

• WebLogic Server管理コンソールでDebugReadyApp属性を有効にします。

ReadyAppサーブレットのURLを使用したReadyAppフレームワークのモニター

ブラウザでhttp://{host:port}/weblogic/readyを指定します。ブラウザは、ステータス200 (READY)または503 (NOT READY)のいずれかを含むページを返します。hostおよびportを、必要なサーバーのホスト名およびポート番号と置き換えます。WebLogic Serverが実行中でない場合、エラー404のページが表示されます。

http://{host:port}/weblogic/ready URLでは、HTTPステータスのみが設定された空白ページが開きます。実際のステータスを表示するにはブラウザ・ツールを使用します。たとえば、Google Chromeブラウザにはページのステータスと待機時間を表示するデベロッパー ツールの設定があります。

WebLogic Server管理コンソールでDebugReadyApp属性を有効にすることによるReadyAppフレームワークのモニター

WebLogic Server管理コンソールでDebugReadyApp属性を有効にすることにより、ReadyAppフレームワークをモニターすることもできます。STDOUTのログが有効になっている場合、このモニタリング方法でログ・ファイルまたはコンソールに情報が書き込まれます。

WebLogic Server管理コンソールを使用してReadyAppフレームワークをモニターするには、次のようにします。

1. WebLogic Server管理コンソールにログインします(http://{host:port}/console/)。
2. 「環境」→「サーバー」→「MyServer」→「デバッグ」の順に選択します。
3. このサーバーの「デバッグ」設定で、「WebLogic」→「アプリケーション」の順に展開し、DebugReadyAppチェック・ボックスを選択して「有効化」をクリックします。
   この変更にWebLogic Serverの再起動は必要ありません。デバッグ属性の有効化の詳細は、サーバー: デバッグを参照してください。
4. デバッグするログの重大度レベルを設定します。
   1. 「環境」→「サーバー」→「MyServer」→「ロギング」→「詳細」の順に選択します。
   2. 「ログの最低の重大度」の重大度レベルを「デバッグ」に設定します。
   3. 「ログ」ファイルで、「重大度レベル」を「デバッグ」に設定します。
   4. 「保存」をクリックします。
      ロギングの詳細は、サーバー: ロギング: 一般を参照してください。
5. http://{host:port}/weblogic/readyにアクセスします。例9-1のような出力が表示されます:

例9-1 ReadyAppフレームワーク・ステータス

**********************
Ready App Map - Operation: Get Ready Status
Partition Id GLOBAL
Item 0 key: TestEar value: 1
Partition Id ratestp2
Item 0 key: ReadyApp2Test$ratestp2 value: 1
Partition Id ratestp1
Item 0 key: ReadyApp2Test$ratestp1 value: 1
**********************

例9-1では、3つのアプリケーションがサーバーのインスタンス(1つはGLOBALパーティション、2つはratestパーティション)にデプロイされます。値1は、これら3つのアプリケーションが準備できていないことを示します。ready()メソッドがこれらのアプリケーションで呼び出されると、値は0に設定されます。これはREADYステータスを示します。