図5.2.2.2-1
図5.2.2.2-2
図5.2.2.2-3
図5.2.2.2-4
図5.2.2.2-5
図5.2.2.2-6
WebOTX ASは以下に示す8種類のアプリケーションをサポートします。 アプリケーションは種類ごとにアーカイブの形式や拡張子が仕様で定められています。
| アプリケーションの種類 | 拡張子 | アーカイブ形式の仕様 |
|---|---|---|
| Webアプリケーション | .war | Java EE |
| EJBアプリケーション | .jar | Java EE |
| エンタープライズアプリケーション | .ear | Java EE |
| アプリケーションクライアント | .jar | Java EE |
| リソースアダプタ | .rar | Java EE |
| CORBAアプリケーション | .cpk | WebOTX AS固有 |
| 共有コンポーネント | .spk | WebOTX AS固有 |
| OSGiバンドル | .jar | OSGi |
WebアプリケーションはWebアプリケーションのためのコンテンツを格納します。静的なHTMLを提供するだけでなく、サーブレットやJSPを利用して動的にコンテンツを生成することもできます。
EJBアプリケーションにはEJB(Enterprise JavaBeans)を格納します。またEJBが利用するユーティリティクラスを含めることもできます。
エンタープライズアプリケーションは、Webアプリケーション,EJBアプリケーション,アプリケーションクライアント,リソースアダプタなどを1つ以上格納した統合アプリケーションです。JavaEEのアプリケーションを提供する場合、1つのEARでアプリケーションを組み立てることもできますし、また個別にWebアプリケーションやEJBアプリケーションなどを配備してアプリケーションを組み立てても構いません。さらには各アプリケーションを異なるサーバ上に配備することでアプリケーションを分散することができます。
Java EEアプリケーションクライアントはクライアントコンテナ上で動作するアプリケーションです。アプリケーションクライアントはRMI-IIOP経由でEJB等のサーバサイドアプリケーションにアクセスします。
リソースアダプタアーカイブにはリソースアダプタを格納します。リソースアダプタとは、EJBやWebアプリケーションが外部のエンタープライズシステムにアクセスできるようにするためのコンポーネントです。
OMGが標準化を行っているCORBAという仕様に準拠したアプリケーションです。Javaだけではなく、C/C++やCOBOLで実装することもできます。CORBAアプリケーションの形式にはR5形式とR4形式が存在します(「アプリケーション開発ガイド」参照)。
プロセスグループ間で共有するライブラリです。
OSGiの仕様に準拠したモジュールです。
サポートするアプリケーションの種類はWebOTX ASのエディションにより異なります。
| アプリケーションの種類 | Express | Standard | Enterprise |
|---|---|---|---|
| Webアプリケーション | ○ | ○ | ○ |
| EJBアプリケーション | ○ | ○ | ○ |
| エンタープライズアプリケーション | ○ | ○ | ○ |
| アプリケーションクライアント | ○ | ○ | ○ |
| リソースアダプタ | ○ | ○ | ○ |
| CORBAアプリケーション | × | × | ○ |
| 共有コンポーネント | × | ○ | ○ |
| OSGiバンドル | ○ | ○ | ○ |
作成したアプリケーションをWebOTX AS上で実行する場合、アプリケーションに対して次に示す運用操作を行います。
開発したアプリケーションを、各アプリケーションが準拠している仕様に基づきアーカイブします。
作成したアプリケーションをWebOTX ASの管理下におく作業です。アプリケーションを配備するためには、ドメインが起動している必要があります。配備するアプリケーションは、あらかじめearやwar等の形式でパッケージ化しておきます。
デフォルトでは配備後のアプリケーションは開始した状態にあります。開始した状態とは、配備されたアプリケーションが動作しており、クライアントからの要求を受け付けることができる状態です。また、停止した状態とは、アプリケーションが動作していない状態のことで、クライアントからの要求は受け付けることができません。停止した状態のアプリケーションは依然としてWebOTX ASの管理下にあります。簡単な運用操作によって、アプリケーションの開始状態と停止状態を切り替えることができます。
配備済みのアプリケーションを置換する作業を再配備と呼びます。再配備はアプリケーションの開発時に頻繁に行われる作業です。
インタフェースやオペレーション単位に設定した情報を引き継いだまま、配備済みのアプリケーションを置換する作業を置換と呼びます。 置換はすでに運用されている環境において、アプリケーションの小さな修正を適用したいときに有効です。 インタフェースやオペレーションが再配備前後ですべて一致している必要があり、異なっている場合置換することができません。
アプリケーションをWebOTX ASの管理下から除外する作業です。
アプリケーションのバージョニング機能を使用すると、同じ名前の複数のバージョンのアプリケーションを配備することができます。これによって、アプリケーションのアップグレードとロールバックが簡単になります。
バージョニング機能は、複数のバージョンのアプリケーションが同時に有効にならないことを保証します。そのため、アプリケーションのバージョンが異なるのであれば、同じコンテキストルートやJNDI名を持たせることができます。
また、アプリケーションの配備解除、停止、状態取得時に、アプリケーション名を指定する箇所でバージョンIDの部分にアスタリスク(*)をワイルドカードとして使用することができます。
アプリケーションにバージョンIDを付与するには、配備時のアプリケーション名の指定で、アプリケーション名の後にコロン(:)で区切ってバージョンIDを指定します。
otxadmin> deploy --name アプリケーション名:バージョンID アーカイブ名
具体例を挙げると、アーカイブ名が「hello.war」であるWebアプリケーションを、アプリケーション名を「hello」、バージョンIDを「1.0」として配備するには、次のようにします。
otxadmin> deploy --name hello:1.0 hello.war
バージョンIDは英数字で始まる必要があります。また、バージョンIDには英数字およびアンダースコア(_)、ハイフン(-)、ピリオド(.)を含めることができます。有効なバージョンIDの例は、以下のとおりです。
アプリケーションに対して設定や運用操作を行う際は、バージョンIDも含めた名前をアプリケーション名として指定する必要があります。例えば、アプリケーション名が「hello」、バージョンIDが「1.0」であるアプリケーションを開始するには、次のようにします。
otxadmin> enable hello:1.0
有効化したいバージョンのアプリケーションを開始することで、有効なバージョンを切り替えることができます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。
この状態で、「hello:3.0-BETA」を有効にするには、次のようにします。
otxadmin> enable hello:3.0-BETA
コマンド実行後の状態は以下のようになります。
新たに配備するバージョンを有効化したい場合は、アプリケーションを開始状態で配備します。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。
この状態で、「hello:3.0-BETA」という名前で新たに配備したアプリケーションを有効にするには、次のようにします。
otxadmin> deploy --name hello:3.0-BETA --enabled=true hello.war
コマンド実行後の状態は以下のようになります。
なお、deployコマンドの--enabledオプションのデフォルト値はtrueです。
アプリケーションの配備解除、停止、状態取得においては、バージョンIDにワイルドカードとしてアスタリスク(*)を指定することができます。有効なワイルドカードを含むバージョンIDの例は、以下のとおりです。
アプリケーションの配備解除でバージョンIDにワイルドカードを指定すると、マッチする全てのバージョンが配備解除されます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。
この状態で、以下のコマンドを実行します。
otxadmin> undeploy hello:1.*
上記のコマンドにより、「hello:1.0」と「hello:1.1」が配備解除されます。
以下のコマンドを実行すると、全てのバージョンが配備解除されます。
otxadmin> undeploy hello:*
アプリケーションの停止でバージョンIDにワイルドカードを指定すると、マッチするバージョンが停止されます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。
この状態で、以下のコマンドを実行すると、いずれのバージョンが有効状態であっても停止することができます。
otxadmin> disable hello:*
アプリケーションの状態取得でバージョンIDにワイルドカードを指定すると、マッチする全てのバージョンの状態が取得できます。
具体例として、以下のアプリケーションが配備されているとします。括弧の中はアプリケーションの状態を表しています。
この状態で、以下のコマンドを実行します。
otxadmin> show-component-status hello:1.*
上記のコマンドにより、以下のメッセージが表示されます。
otxadmin> show-component-status hello:1.* hello:1.0 の状態は 無効(disabled) です。 hello:1.1 の状態は 有効(enabled) です。
CORBAアプリケーション、共有コンポーネント、およびOSGiバンドルの配備では、バージョニング機能を使用することはできません。CORBAアプリケーション、共有コンポーネント、およびOSGiバンドル配備時にバージョンIDを付与すると、バージョンIDは無視されます。
バージョンIDを付与して配備を行うと、deployコマンドの--bindtypeオプション(名前サーバの登録方式)の既定値がtransient(一時的に扱う)になります(バージョンIDを付与しない場合の既定値はpersistent(永続的に扱う)です)。これは、バージョンIDを付与することで異なるバージョン間で同じJNDI名を使用することが可能になり、その場合、名前サーバへの登録・登録解除をアプリケーションの配備・配備解除時ではなく、アプリケーションの起動・停止時に行う必要があるためです。バージョンIDを付与した上で「名前サーバの登録方式」を「永続的に扱う」に設定する場合は、--bindtypeオプションでpersistentを明示的に指定してください。なお、CORBAアプリケーションはバージョンIDを付与してもバージョンIDが無視されるため、--bindtypeオプションの既定値はpersistentのままで変更はありません。また、統合運用管理ツールおよびWeb版統合運用管理コンソールで配備を行う場合は、バージョンIDを付与した場合でも「名前サーバの登録方式」の既定値に変更はありません。必要があれば、配備の際に「名前サーバの登録方式」で「一時的に扱う」を選択してください。
WebOTX AS V7およびWebOTX V6にバンドルしていた配備ツール、およびWebOTX V5にバンドルしていた展開ツールはV8で廃止になりました。WebOTX AS V8以降でGUIを用いた配備/配備解除を行う場合は、以下のツールを利用してください。
WebOTX ASに配備するアプリケーションは、エディションにより動作するプロセスが異なります。この章では、配備の観点からアプリケーションが動作するプロセスについての解説を行います。
アプリケーションが動作するプロセスは大きく分けて「エージェントプロセス」と「プロセスグループ」の二種類存在します。この節では、これらの違いについて解説します。
エージェントプロセスとは、WebOTX ASが動作している、コアとなるプロセスのことです。WebOTX AS Expressでは、配備したアプリケーションは全てエージェントプロセス上で動作します。このエディションでは、配備時には配備先の指定は必要ありません。
WebOTX AS Standard/Enterpriseでは、配備したアプリケーションはWebOTX ASのエージェントプロセスから分離された個別のプロセス上で動作します。このプロセスは多重化することができ、多重化したプロセス群のことを「プロセスグループ」と呼んでいます。
プロセスグループは、更に業務単位にまとめることができます。業務単位でまとめたプロセスグループ群を「アプリケーショングループ」と呼びます。
WebOTX AS Standard/Enterpriseで以下のアプリケーションを配備する際には、どのアプリケーショングループおよびプロセスグループに対しての配備なのかを指定する必要があります。
この節では、各ツールを使ってアプリケーショングループとプロセスグループを作成する方法を説明します。
運用管理コマンドを利用してアプリケーショングループとプロセスグループを作成する手順を説明します。なお運用管理コマンドの詳細については運用管理コマンドリファレンスの「create-apg」、「create-pg」を参照してください。
プロセスグループを作成する前に、それが属するアプリケーショングループを作成する必要があります。アプリケーショングループを作成するには、次に示すオペレーションcreate-apgを実行します。
otxadmin> create-apg アプリケーショングループ名
具体例を挙げると、「myapg」という名前のアプリケーショングループを作成するには、次のようにします。
otxadmin> create-apg myapg
次にプロセスグループを作成します。プロセスグループを作成するには、次に示すオペレーションcreate-pgを実行します。
otxadmin> create-pg --apgroup 所属アプリケーショングループ名 --kind 種別 --version バージョン プロセスグループ名
具体例を挙げると、「javaeepg」という名前の、「myapg」というアプリケーショングループに属するJava EE用のプロセスグループを作成するには、次のようにします。
otxadmin> create-pg --apgroup myapg --kind javaee --version 9 javaeepg
別の例を挙げると、「corba」という名前の、「yourapg」というアプリケーショングループに属する、Visual C++ 2005で実装したCORBAアプリケーションのためのプロセスグループを作成するには、次のようにします。
otxadmin> create-pg --apgroup yourapg --kind vc2005 --version 9 corba
統合運用管理ツールを利用して、アプリケーショングループとプロセスグループを作成する手順を説明します。
図5.2.2.2-1
図5.2.2.2-2
図5.2.2.2-3
図5.2.2.2-4
図5.2.2.2-5
図5.2.2.2-6
Web版統合運用管理コンソールを利用して、アプリケーショングループとプロセスグループを作成する手順を説明します。
図5.2.2.3-1
図5.2.2.3-2
図5.2.2.3-3
図5.2.2.3-4
図5.2.2.3-5
図5.2.2.3-6
配備時あるいは再配備時にプロセスグループを指定しても、別の配備先に自動調整される場合があります。 これは以下の場合です。
以下の表は、配備/再配備時のプロセスグループの指定と、実際の配備先についてまとめたものです。 太字で表示されている部分が調整された配備先になります。
※以下の表では、プロセスグループをPGと表記します。
| 配備 | 再配備 | |||||
|---|---|---|---|---|---|---|
| PG指定あり | PG指定なし | PG指定あり | PG指定なし | |||
| Express | Webアプリケーション | × | エージェントプロセス | × | エージェントプロセス | |
| EJB | × | エージェントプロセス | × | エージェントプロセス | ||
| リソースアダプタ | × | エージェントプロセス | × | エージェントプロセス | ||
| アプリケーションクライアント | × | エージェントプロセス | × | エージェントプロセス | ||
| エンタープライズアプリケーション | × | エージェントプロセス | × | エージェントプロセス | ||
| CORBAアプリケーション (Expressでは未サポート) |
× | × | × | × | ||
| 共有コンポーネント (Expressでは未サポート) |
× | × | × | × | ||
| OSGiバンドル | × | エージェントプロセス | × | エージェントプロセス | ||
| Standard | アドバンスト | Webアプリケーション | 指定したPG | × | 以前のPG | 以前のPG |
| EJB | 指定したPG | × | 以前のPG | 以前のPG | ||
| リソースアダプタ | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| アプリケーションクライアント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| エンタープライズアプリケーション (EJBまたはWARを含む) |
指定したPG | × | 以前のPG | 以前のPG | ||
| エンタープライズアプリケーション (EJBもWARも含まない) |
エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| CORBAアプリケーション (Standardでは未サポート) |
× | × | × | × | ||
| 共有コンポーネント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| OSGiバンドル | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| スタンダード | Webアプリケーション (EJBを含むが、WebサービスのEJBは含まない) | 指定したPG | × | 以前のPG | 以前のPG | |
| Webアプリケーション (EJBを含まないか、WebサービスのEJBを含む) | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| EJB | 指定したPG | × | 以前のPG | 以前のPG | ||
| EJB(Webサービス) | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| リソースアダプタ | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| アプリケーションクライアント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| エンタープライズアプリケーション (EJBを含むが、WebサービスのEJBは含まない) |
指定したPG | × | 以前のPG | 以前のPG | ||
| エンタープライズアプリケーション (EJBを含まないか、WebサービスのEJBを含む) |
エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| CORBAアプリケーション (Standardでは未サポート) |
× | × | × | × | ||
| 共有コンポーネント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| OSGiバンドル | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| Enterprise | アドバンスト | Webアプリケーション | 指定したPG | × | 以前のPG | 以前のPG |
| EJB | 指定したPG | × | 以前のPG | 以前のPG | ||
| リソースアダプタ | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| アプリケーションクライアント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| エンタープライズアプリケーション (EJBまたはWARを含む) |
指定したPG | × | 以前のPG | 以前のPG | ||
| エンタープライズアプリケーション (EJBもWARも含まない) |
エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| CORBAアプリケーション | 指定したPG | × | 以前のPG | 以前のPG | ||
| 共有コンポーネント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| OSGiバンドル | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| スタンダード | Webアプリケーション (EJBを含むが、WebサービスのEJBは含まない) | 指定したPG | × | 以前のPG | 以前のPG | |
| Webアプリケーション (EJBを含まないか、WebサービスのEJBを含む) | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| EJB | 指定したPG | × | 以前のPG | 以前のPG | ||
| EJB(Webサービス) | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| リソースアダプタ | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| アプリケーションクライアント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| エンタープライズアプリケーション (EJBを含むが、WebサービスのEJBは含まない) |
指定したPG | × | 以前のPG | 以前のPG | ||
| エンタープライズアプリケーション (EJBを含まないか、WebサービスのEJBを含む) |
エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| CORBAアプリケーション | 指定したPG | × | 以前のPG | 以前のPG | ||
| 共有コンポーネント | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
| OSGiバンドル | エージェントプロセス | エージェントプロセス | エージェントプロセス | エージェントプロセス | ||
作成したアプリケーションを配備する前に、アプリケーションを配備可能な形式にパッケージングします。アーカイブ内のディレクトリ構造やファイルの配置方法は、アプリケーションの種類ごとに定められています。この章では、アプリケーションのアーカイブの方法について解説します。
WebアプリケーションやEJBアプリケーションなどのJava EEのアプリケーションを配備する際には、標準仕様(JSR)に準拠した形式でパッケージングを行う必要があります。パッケージングの形式が標準化されているため、ポータビリティの高いアプリケーションの作成が可能になっています。WebOTX Developerでプロジェクトを作成することにより、パッケージングを自動化することができます。
ここではJava EEアプリケーションのパッケージングの解説は省略します。詳細はJava EEの仕様を参考にしてください。
Java EEの場合とは異なり、CORBAアプリケーションにはパッケージングに関する標準仕様はありません。ここで示すCORBAのパッケージングはWebOTX ASに固有の形式です。
CORBAアプリケーションをパッケージングするためには、最低限次の2つのファイルが必要です。
また、必要であれば次のファイルを準備してください。
| プロパティ | 説明 |
|---|---|
| component.initfunc | コンポーネント初期化ファイル名を指定します。 |
| component.id | コンポーネントIDを指定します。 |
| component.useshareif | 共有コンポーネントのifファイルを利用する場合trueを利用しない場合falseを指定します(既定値:false)。 |
| component.shareif | 共有コンポーネントのifファイルを利用する場合そのifファイル名を指定します。 |
| component.sharedComponentList | 利用する共有コンポーネントのアプリケーション名を記述します。複数ある場合はカンマ「,」で区切ります。 |
| sharedcomponent.allModuleUse | 共有コンポーネントを全てのアプリケーションから利用できるようにします。 |
なお、統合運用管理ツールおよびWeb版統合運用管理コンソールにはパッケージングされていないCORBAアプリケーションを配備する機能がありますので、CORBAアプリケーションのパッケージングは必須ではありません。
CORBAアプリケーションの形式にはR4形式とR5形式があります。CORBAアプリケーションの形式についての詳細は、「システム設計ガイド」を参照してください。
コマンドラインからCORBAアプリケーションをパッケージングするにはmakecpkコマンドを利用します。makecpkの詳細なリファレンスについては[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.5. パッケージ生成 > 4.5.1. makecpk ]を参照してください。
> makecpk corbaap.cpk module=corbaap.jar if=corbaap.if
> makecpk corbaap.cpk module=corbaap.jar if=corbaap.if prop=corbaap.properties
> makecpk corbaap.cpk module=corbaap.jar if=shareap.if id=AA initfunc=corbaap.create useshareif=true
共有コンポーネントはWebOTX AS固有のコンポーネントです。共有コンポーネントをパッケージングするためには、最低限次のファイルが必要です。
また共有コンポーネントがCORBAインタフェースを持つ場合、次のファイルも準備してください。
なお、統合運用管理ツールおよびWeb版統合運用管理コンソールにはパッケージングされていない共有コンポーネントを配備する機能がありますので、共有コンポーネントのパッケージングは必須ではありません。
コマンドラインから共有コンポーネントをパッケージングするにはmakecpkコマンドを利用します。makecpkの詳細なリファレンスについては[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.5. パッケージ生成 > 4.5.1. makecpk ]を参照してください。
> makecpk shareap.spk module=shareap.jar
> makecpk shareap.spk module=shareap.jar if=shareap.if
OSGiバンドルを配備する際には、OSGiの仕様に準拠した形式でパッケージングを行う必要があります。
ここではOSGiバンドルのパッケージングの解説は省略します。詳細はOSGiの仕様を参考にしてください。
配備とは、作成したアプリケーションをWebOTX ASの管理下におく作業です。 また再配備とは、WebOTX ASの管理下にあるアプリケーションを、新しいアプリケーションで置換することです。 置換に関しては、設定情報を保持したまま、再配備を行う作業です。 この章では、これらについて解説します。
WebOTX ASがアプリケーションを管理するために、配備の際にはアプリケーションに名前をつける必要があります。アプリケーションの名前は、WebOTX ASのドメイン内で一意でなければなりません。
アプリケーション名で使用可能な文字は、ASCII英数字、ハイフン(-)、アンダースコア(_)、ピリオド(.)のみです。 アプリケーション名の先頭には、ASCII英数字、アンダースコア(_)のみが使用可能です。 また、ファイル名として使用できない文字列はアプリケーション名として使用することはできません。 使用可能な文字の例外として、[ 5.1.4. アプリケーションのバージョニング機能 ] で使用するコロン(:)を1つだけ含めることができます。
アプリケーション名は、デフォルトではアーカイブのファイル名から拡張子を取り除いたものになります。例えば、アーカイブのファイル名が「sample.war」の場合、「sample」というアプリケーション名でWebOTX ASに配備されます。また、配備をサポートする各ツールは、アプリケーション名を明示的に指定する方法を提供しています。
EAR に含まれるモジュール名にコロン(:)、アスタリスク(*)、疑問符(?)、二重引用符(")、不等号(< および >)、バーティカルバー(|)、および連続するアンダースコア(_)を使用することはできません。
[ 製品構成と提供機能 > 3. 提供機能 > 3.4. TPモニタ > 3.4.1. アプリケーションの構成 > 3.4.1.3. プロセスグループ ]で示したとおり、WebOTX AS Standard/Enterpriseでは、配備の際にアプリケーショングループとプロセスグループの指定が必要な場合があります。
再配備時には、アプリケーショングループとプロセスグループを指定する必要がありません。自動的に、新しいアプリケーションを古いアプリケーションが配備されていたアプリケーショングループおよびプロセスグループに再配備されます。
この節では、Java EEのアプリケーションの配備/再配備について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。
運用管理コマンドのdeployオペレーションを利用してJava EEのアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。
配備するには、Java EEのアプリケーションのアーカイブを指定してオペレーションdeployを実行します。WebOTX AS Standard/Enterpriseの場合は、配備先のアプリケーショングループ名とプロセスグループ名を指定する必要があります。
otxadmin> deploy [--apgroup アプリケーショングループ名] [--pgroup プロセスグループ名] アーカイブ名
再配備するには、--forceオプションを付加します。
otxadmin> deploy --force アーカイブ名
具体例を挙げると、WebOTX AS Expressにおいてアーカイブ名が「hello.war」であるWebアプリケーションを配備し、その後再配備するには、次のようにします。
otxadmin> deploy hello.war
otxadmin> deploy --force hello.war
別の例を挙げると、WebOTX AS Enterpriseにおいてアーカイブ名が「sample.jar」であるEJBアプリケーションを配備し、その後再配備するには、次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。
otxadmin> deploy --apgroup apg --pgroup pg sample.jar
otxadmin> deploy --force sample.jar
運用管理コマンドのオペレーションdeploydirを利用してJava EEのアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploydir」を参照してください。
通常の配備では、アプリケーションをパッケージングし、そのアーカイブを配備します。オペレーションdeploydirを利用すると、パッケージング前のディレクトリ構造そのものを配備することができます。
配備するには、Java EEのアプリケーションが格納されているディレクトリのフルパスを指定してオペレーションdeploydirを実行します。配備対象のディレクトリのフルパスは、WebOTX ASが動作しているホストにおけるフルパスです。アプリケーションをクライアントマシンからサーバマシンへ転送する機能はありません。WebOTX AS Standard/Enterpriseでは、配備の際にアプリケーショングループとプロセスグループの指定が必要な場合があります。
otxadmin> deploydir [--apgroup アプリケーショングループ名] [--pgroup プロセスグループ名] ディレクトリのフルパス
再配備するには、--forceオプションを付加します。
otxadmin> deploydir [--apgroup アプリケーショングループ名] [--pgroup プロセスグループ名] --force ディレクトリのフルパス
具体例を挙げると、WebOTX AS Expressにおいてアプリケーションのディレクトリのフルパスが「C:\hello」であるWebアプリケーションを配備し、その後再配備するには、次のようにします。
otxadmin> deploydir C:\\hello
otxadmin> deploydir --force C:\\hello
※運用管理コマンドでは、ファイルパスのセパレータ '\' は "\\" として入力する必要があります。
別の例を挙げると、WebOTX AS Enterpriseにおいて、サーバ上でのディレクトリのフルパスが「C:\sample」であるWebアプリケーションを配備し、その後再配備するには次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。
otxadmin> deploydir --apgroup apg --pgroup pg C:\\sample
otxadmin> deploydir --force C:\\sample
オペレーションdeploydirは、システムの開発効率を上げるために提供しています。そのため本番環境ではdeploydirは利用せずに、deployを利用してください。オペレーションdeploydirは配備するディレクトリの内容を直接に書き換えてしまうため、配備するディレクトリのバックアップを取ってから実行してください。
deploydirでは、アーカイブファイルが解体された状態のディレクトリ配下の中にある配備記述子XMLファイルを直接変更できます。「オートデプロイ」の項で説明した構成情報ファイル「domain.xml」の同じ「das-config」要素内の中にある下記のダイナミックリロードに関する属性が有効になっていると、サーバは自動的に変更を検知し、アプリケーションを再ロードします。
| 属性 | 既定値 | 説明 |
|---|---|---|
| dynamic-reload-enabled | true | trueの場合、「.reload」ファイルのタイムスタンプをチェックし、更新されていればアプリケーションを読み込みなおします。 |
| dynamic-reload-poll-interval-in-seconds | 2 | ダイナミックリロードのポーリング間隔を指定します。単位は秒です。 |
「dynamic-reload-enabled」の設定を「true」に変更します。WebOTX ASに更新を知らせるために次の操作を行います。
モジュール
(Webアプリケーション(.war)、EJBアプリケーション(.jar)、アプリケーションクライアント(.jar)):
${INSTANCE_ROOT}/applications/<モジュール名>/.reload
統合運用管理ツールを利用して、Java EEのアプリケーションを配備する手順を説明します。
図5.4.3.3-1
図5.4.3.3-2
図5.4.3.3-3
図5.4.3.3-4
図5.4.3.3-5
図5.4.3.3-6
Web版統合運用管理コンソールを利用して、Java EEのアプリケーションを配備する手順を説明します。
図5.4.3.4-1
図5.4.3.4-2
図5.4.3.4-3
図5.4.3.4-4
オートデプロイ機能とは、アプリケーションのアーカイブファイルを次のディレクトリにコピーすることで自動的に配備を行う機能です。
${INSTANCE_ROOT}/autodeploy
配備が成功した場合には、ディレクトリautodeployに、[アーカイブファイル名]_deployedというファイルが作成されます。また配備が失敗した場合は、[アーカイブファイル名]_deployFailedというファイルが作成されます。これらのファイルの存在を確認することで、配備が正常に終了したかどうかを調べることができます。
再配備を行う場合は、再配備するアーカイブをディレクトリautodeployに上書きでコピーしてください。上書きするアーカイブのタイムスタンプは、上書きされるアーカイブのタイムスタンプと異なる必要があります。同じタイムスタンプのアーカイブで上書きした場合、配備処理は実行されません。
オートデプロイ機能は、配備が実行されるタイミングを制御することができません。例えば、アーカイブファイルのコピー中にオートデプロイが実行されると、ファイルの内容が不完全であるために配備に失敗します。そのため、本番環境ではオートデプロイ機能を利用することを推奨していません。代わりに、deployコマンドや統合運用管理ツール等から明示的に配備を実行してください。
WebOTX AS Standard/Enterpriseでは、配備時にアプリケーショングループとプロセスグループを指定する必要があります。オートデプロイ機能で配備先のアプリケーショングループとプロセスグループを指定するには、ディレクトリautodeployに、プロパティファイルautodeploy.propertiesを作成し、内容を適切に設定してください。プロパティファイルautodeploy.propertiesは、java.util.Propertiesが読み込める形式でなければいけません。プロパティファイルautodeploy.propertiesはドメイン起動時に読み込まれ、その後変更するたびに再読み込みされます。プロパティファイルautodeploy.propertiesに記述するプロパティの詳細を以下に示します。
| キー | 値の説明 |
|---|---|
| apg | 登録先アプリケーショングループ名。 |
| pg | 登録先プロセスグループ名。 |
| methodid | メソッド識別情報の割り当てのモードの指定。[ 5.8. 配備チューニング > 5.8.1. EJBのメソッド識別情報の割り当て抑止(Standard/Enterprise) ]参照。 |
オートデプロイ機能の各種設定は、${INSTANCE_ROOT}/config/domain.xmlに記述してあります。このdomain.xmlファイルの要素<das-config>の属性の値を編集することで、設定を変更することができます。domain.xmlの編集はドメインを停止してから行ってください。属性の詳細は以下の通りです。
| 属性 | 既定値 | 説明 |
|---|---|---|
| autodeploy-enabled | true | trueの場合、オートデプロイ機能が有効になります。falseの場合は、オートデプロイ機能は無効になり、動作しません。 |
| autodeploy-polling-interval-in-seconds | 2 | オートデプロイのためのディレクトリを監視する間隔(ポーリング間隔)です。単位は秒です。 |
| autodeploy-retry-timeout | 4 | オートデプロイのリトライを中止するまでのタイムアウト時間です。オートデプロイに失敗したアーカイブファイルは、次のポーリング時にリトライされます。これは、アーカイブのコピー中にオートデプロイが実行された場合に、はじめのオートデプロイで失敗しても、コピー完了後に再度オートデプロイを実行するためです。リトライタイムアウト時間が経過すると、以降のオートデプロイのリトライは実行されません。単位は秒です。 |
| autodeploy-dir | ${INSTANCE_ROOT}/autodeploy | オートデプロイのためのディレクトリを設定します。このディレクトリは、絶対パスを指定します。 |
| autodeploy-jsp-precompilation-enabled | false | trueの場合、配備中にJSPをコンパイルします。falseの場合、JSPのコンパイルは行いません。この場合はJSPの初回アクセス時に動的にコンパイルを実行します。 |
Java EEのアプリケーションへのアクセスパス（コンテキストパス）は通常パッケージング名（xxxx.war）の拡張子を除いた部分（xxxx）と等価となります。つまり Webブラウザからは
http://<host>/xxxx/
でアクセスすることになります。しかし、http://<host>/ としただけで特定のアプリケーションにアクセスしたい場合があります。このような場合は次のようにします（1 と 2 を実施）。
まず、対象となるアプリケーションを "/" への配備するための設定をします。
| <?xml version="1.0" encoding="UTF-8"?> <nec-web-app> <context-root>/</context-root> </nec-web-app> |
| <?xml version="1.0" encoding="UTF-8"?> <application ...> <web> <web-uri>sample.war</web-uri> <context-root>/</context-root> </web> </application> |
※application.xmlとnec-web.xmlの両方に設定がある場合は、nec-web.xmlが優先されます。
下記2つのコマンドを入力し、ドメイン再起動します。
a) otxadmin> create-jvm-options -Dwebotx.webcontainer.serverconfig.NoRoot=false
b) otxadmin> add-pg-javasystem-property --apgroup [apgroup_name] --javasystemprop webotx.webcontainer.serverconfig.NoRoot --value false [pgroup_name]
【注意点】
・内蔵Webサーバを利用している場合、(2) は実施する必要はありません。
・スタンダードモードの場合は (a) のみを設定します。アドバンスドモードでは、(a) と (b) の2箇所に設定する必要があります。
・その他、[ 注意制限事項 > 3. Webコンテナ > 3.1. 注意事項 > Webアプリケーションのルートコンテキスト("/")への割り当てについて ]も参照してください。
ホットスワップ機能とは、アプリケーションのクラスファイルを更新を検知し、配備を行うことなくアプリケーションの更新を反映する機能です。
ホットスワップ機能を有効にすると、アプリケーションのディレクトリ内のクラスファイルが監視されます。クラスファイルのタイムスタンプが変更されると、そのクラスファイルからロードされたクラスが再定義されます。
再定義に成功した場合も失敗した場合もログにメッセージが出力されます。再定義する前に実行中のメソッドは次回実行時に更新が反映されます。再定義に失敗した場合、再定義前のクラスがそのまま使用されます。
ホットスワップ機能を有効にするには、ドメインに対してホットスワップ機能を有効化した上で、個々のアプリケーションに対してホットスワップ機能を有効化する必要があります。そのため、ドメイン単位およびアプリケーション単位で、ホットスワップ機能の有効・無効を切り替えることができます。
ホットスワップ機能の各種設定は、${INSTANCE_ROOT}/config/domain.xmlに記述してあります。このdomain.xmlファイルの要素<das-config>の属性の値を編集することで、設定を変更することができます。設定の変更は運用管理ツールや運用管理コマンドを使用して行うことができます。domain.xmlを直接編集する場合はドメインを停止してから行ってください。属性の詳細は以下の通りです。
| 属性 | 既定値 | 説明 |
|---|---|---|
| hotswap-enabled | false | trueの場合、ドメインに対してホットスワップ機能が有効になります。falseの場合は、ホットスワップ機能が無効になり動作しません。 |
| hotswap-polling-interval-in-seconds | 2 | ホットスワップのためのディレクトリを監視する間隔(ポーリング間隔)です。単位は秒です。 |
また、domain.xmlファイルの要素<application>の属性の値を編集することで、アプリケーションに対する設定を変更することができます。設定の変更は運用管理ツールや運用管理コマンドを使用して行うことができます。domain.xmlを直接編集する場合はドメインを停止してから行ってください。属性の詳細は以下の通りです。
| 属性 | 既定値 | 説明 |
|---|---|---|
| hotswap-enabled | false | trueの場合、アプリケーションのディレクトリをホットスワップ機能の監視対象に追加します。falseの場合は、アプリケーションのディレクトリは監視対象にならず、クラスファイルの更新は検知されません。この設定の変更は、アプリケーションの再起動で反映されます。 |
アプリケーションに対するホットスワップ機能の設定は、配備時の--hotswapenabledオプションでも行うことができます。
アプリケーションがディレクトリ「C:/apps/hello」にwarを展開した形式で存在する場合について説明します。
ディレクトリ構成例は以下の通りです。
ホットスワップ機能を有効化する手順は以下の通りです。
[配備時に有効化する場合]
otxadmin> set server.admin-service.das-config.hotswap-enabled=true
otxadmin> deploydir --hotswapenabled C:/apps/hello
[配備後に有効化する場合]
otxadmin> deploydir C:/apps/hello
otxadmin> set server.admin-service.das-config.hotswap-enabled=true
otxadmin> set server.applications.application.hello.hotswap-enabled=true
otxadmin> disable hello otxadmin> enable hello
上記の設定を行って、ホットスワップ機能が有効になっている状態で、アプリケーション内のクラスファイル(例: HelloServlet.class)を更新すると、ロード済みのクラスが再定義されます。再定義に失敗した場合は、失敗原因とともにメッセージがログに出力されます。なお、更新されたクラスファイルのクラスがまだロードされていない場合は、再定義されません。その場合は、クラスがロードされるときに更新後のクラスファイルを読み込みます。
上記の例ではディレクトリ展開形式で配備したアプリケーションに対してホットスワップ機能を使用していますが、アーカイブ形式で配備したアプリケーションに対してもホットスワップ機能を使用することができます。
プロセスグループでホットスワップ機能を有効にするには、プロセスグループの「その他の引数」に以下の引数を追加する必要があります。
※ ${INSTALL_ROOT}はWebOTX ASのインストールディレクトリに置換してください。
-javaagent:${INSTALL_ROOT}/lib/deployment/hotswap-agent.jarこの節では、Java EEのアプリケーションの置換について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。
プロセスグループに配備したアプリケーションは、TPモニタの機能を最大限に引き出すために、メソッド単位で細粒度の設定を行う事が可能です。 しかしながら、細粒度であるが故にアプリケーションの構成変更の影響を受けやすく、再配備時にはTPモニタ関連の設定は初期値に戻ってしまいます。
アプリケーションの置換とは、「インタフェースに変更がない」という制約の下、TPモニタ関連の設定を保持したまま再配備を行う操作です。 アプリケーションの置換は、本番環境で動作しているアプリケーションに対して、そのアプリケーションの不具合の修正を目的としたリビジョンアップを行う場合に利用します。 アプリケーションの置換は、開発時のようにインタフェースが安定していない状況には向いていません。
「インタフェースに変更がない」とは、以下の条件を満たす事を指します。
上記の条件を満たさなかった場合、アプリケーションの置換は失敗し、エラーが返されます。
運用管理コマンドのreplaceオペレーションを利用してJava EEのアプリケーションを置換する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「replace」を参照してください。
置換するには、Java EEのアプリケーションのアーカイブを指定してオペレーションreplaceを実行します。
otxadmin> replace アーカイブ名
replaceは、旧アプリケーションが配備されていたプロセスグループを自働的に配備先として選択します。
具体例を挙げると、WebOTX AS Enterpriseにおいてアーカイブ名が「hello.war」であるWebアプリケーションを配備し、その後置換するには、次のようにします。
otxadmin> deploy --apgroup myapg --pgroup mypg hello.war
otxadmin> replace hello.war
統合運用管理ツールを利用して、Java EEのアプリケーションを置換する手順を説明します。
図5.4.4.2-1
図5.4.4.2-2
図5.4.4.2-3
図5.4.4.2-4
図5.4.4.2-5
図5.4.4.2-6
Web版統合運用管理コンソールを利用して、Java EEのアプリケーションを置換する手順を説明します。
図5.4.4.3-1
図5.4.4.3-2
図5.4.4.3-3
図5.4.4.3-4
ここではCORBAアプリケーションの配備について説明します。WebOTX AS EnterpriseのみがCORBAアプリケーションをサポートしています。
CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、配備を行うための条件が異なります。アプリケーショングループが起動状態で配備を行うことを、動的配備と呼びます。アプリケーショングループが停止状態で配備を行うことを、静的配備と呼びます。
R4形式のCORBAアプリケーションの場合、静的配備のみをサポートします。配備を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は配備できません。
R5形式のCORBAアプリケーションの場合は、動的配備も静的配備もサポートしています。ただし、動的配備を行う場合は以下の条件を満たす必要があります。
バージョン5のプロセスグループは動的配備をサポートしていませんので、アプリケーショングループを停止して静的配備を行ってください。
CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、再配備を行うための条件が異なります。アプリケーショングループが起動状態で再配備を行うことを、動的再配備と呼びます。アプリケーショングループが停止状態で再配備を行うことを、静的再配備と呼びます。
R4形式のCORBAアプリケーションの場合、静的再配備のみをサポートします。再配備を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は再配備できません。
R5形式のCORBAアプリケーションの場合は、動的再配備も静的再配備もサポートしています。ただし、動的再配備を行う場合は以下の条件を満たす必要があります。
バージョン5のプロセスグループは動的再配備をサポートしていませんので、アプリケーショングループを停止して静的再配備を行ってください。またCORBAアプリケーションが停止状態でない場合は、再配備ができません。CORBAアプリケーションを停止状態にすることで、再配備を行うことができます。CORBAアプリケーションを停止する際、実行中のオペレーションがエラーとなる可能性があります。
動的配備と動的配備解除を利用することにより、業務を停止せずにアプリケーションを置換することができます。手順を以下に示します。
WebOTX V6.5より、オペレーション数削減のために、業務実行において不要なCORBAオペレーションを表示しないようにしています。具体的には、R4形式で作成されたCORBAアプリケーションにおける、自動生成されたファクトリインタフェースのオペレーションのうち、CreateServerObject2とReleaseServerObject2の登録を行わないようにしています。これらは開発環境のIDLコンパイラ(woigenxx, woigenj)で作成したときに自動付加されます。WebOTX V6.4以前と同じように表示させたい場合は、以下の方法でドメインのJava VMオプションにシステムプロパティを設定してから配備しなおす必要があります。
設定するシステムプロパティは以下の通りです。
| プロパティ | 値 |
|---|---|
| com.nec.webotx.analyzeFactory | true/false (既定値:false CreateServerObject2, ReleaseServerObject2を表示しない) |
システムプロパティをJava VMオプションに追加します。設定手順は以下の通りです。
以下のツリーの[一般]画面内のJVMオプションに「-Dcom.nec.webotx.analyzeFactory=true」を追加します。
「ドメイン名」→「アプリケーションサーバ」→「JVM構成」→[一般]タグ
以下のコマンドでJava VMオプションの追加を行います（--user などのオプションは省いています）。
otxadmin> create-jvm-options -Dcom.nec.webotx.analyzeFactory=true
otxadmin> get server.java-config.jvm-options
この設定は、ドメイン再起動以降有効になります。配備時のみ影響するものであり、配備済みのCORBAアプリケーションには影響ありません。また、R4形式以外のアプリケーションにも影響はありません。なお、表示する設定にした場合、1ドメイン内に登録するオペレーション数が増加します。TPシステムの属性である「最大オペレーション数」を超えないように、事前の調整を行う必要があります。
運用管理コマンドを利用してCORBAアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。
配備するには、CORBAアプリケーションのアーカイブを指定してdeployオペレーションを実行します。deployオペレーションを実行する際には、配備先のアプリケーショングループ名とプロセスグループ名も指定する必要があります。
otxadmin> deploy --apgroup アプリケーショングループ名 --pgroup プロセスグループ名 アーカイブ名
再配備するには、--forceオプションを付加します。
otxadmin> deploy --force アーカイブ名
例えば、アーカイブ名が「corba.cpk」であるCORBAアプリケーションを配備し、その後再配備するには、次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。
otxadmin> deploy --apgroup apg --pgroup pg corba.cpk
otxadmin> deploy --force corba.cpk
統合運用管理ツールを利用して、CORBAアプリケーションを配備する手順を説明します。
図5.4.5.6-1
図5.4.5.6-2
図5.4.5.6-3
図5.4.5.6-4
図5.4.5.6-5
Web版統合運用管理コンソールを利用して、CORBAアプリケーションを配備する手順を説明します。
図5.4.5.7-1
図5.4.5.7-2
図5.4.5.7-3
ここでは、共有コンポーネントの配備について説明します。WebOTX AS Standard/Enterpriseが共有コンポーネントをサポートしています。
運用管理コマンドを利用して共有コンポーネントを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。
配備する場合は、共有コンポーネントのアーカイブを指定してdeployオペレーションを実行します。
otxadmin> deploy アーカイブ名
再配備するには、--forceオプションを付加します。
otxadmin> deploy --force アーカイブ名
具体例を挙げると、アーカイブ名が「shared.spk」である共有コンポーネントを配備し、その後再配備するには、次のようにします。
otxadmin> deploy shared.spk
otxadmin> deploy --force shared.spk
統合運用管理ツールを利用して、共有コンポーネントを配備する手順を説明します。
図5.4.6.2-1
図5.4.6.2-2
図5.4.6.2-3
図5.4.6.2-4
図5.4.6.2-5
Web版統合運用管理コンソールを利用して、共有コンポーネントを配備する手順を説明します。
図5.4.6.3-1
図5.4.6.3-2
図5.4.6.3-3
ここでは、OSGiバンドルの配備について説明します。
運用管理コマンドを利用してOSGiバンドルを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「deploy」を参照してください。
配備する場合は、--typeオプションにosgiと指定し、OSGiバンドルのアーカイブを指定してdeployオペレーションを実行します。
otxadmin> deploy --type osgi アーカイブ名
再配備するには、--forceオプションを付加します。再配備時も--typeオプションにosgiと指定する必要があります。
otxadmin> deploy --force --type osgi アーカイブ名
具体例を挙げると、アーカイブ名が「sample.jar」であるOSGiバンドルを配備し、その後再配備するには、次のようにします。
otxadmin> deploy --type osgi sample.jar
otxadmin> deploy --force --type osgi sample.jar
統合運用管理ツールを利用して、OSGiバンドルを配備する手順を説明します。
図5.4.7.2-1
図5.4.7.2-2
図5.4.7.2-3
図5.4.7.2-4
図5.4.7.2-5
Web版統合運用管理コンソールを利用して、OSGiバンドルを配備する手順を説明します。
図5.4.7.3-1
図5.4.7.3-2
図5.4.7.3-3
オートデプロイ機能とは、OSGiバンドルのアーカイブファイルを次のディレクトリにコピーすることで自動的に配備を行う機能です。
${INSTANCE_ROOT}/autodeploy/bundles
Java EEのアプリケーションのオートデプロイとは異なり、OSGiバンドルのオートデプロイは、WebOTXが使用するOSGiフレームワークの機能を利用しています。そのため、オートデプロイされたOSGiバンドルはWebOTXの運用管理ツールから管理することはできません。
また、Java EEのアプリケーションのオートデプロイの設定は、OSGiバンドルのオートデプロイには適用されません。
配備解除とは、WebOTX ASの管理下からアプリケーションを除外することです。この章では配備解除について解説します。
この節では、Java EEのアプリケーションの配備解除について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。
運用管理コマンドを利用してJava EEのアプリケーションを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
具体例を挙げると、アプリケーション名が「hello」であるアプリケーションを配備解除するには、次のようにします。
otxadmin> undeploy hello
統合運用管理ツールを利用して、Java EEのアプリケーションを配備解除する手順を説明します。
図5.5.1.2-1
図5.5.1.2-2
図5.5.1.2-3
Web版統合運用管理コンソールを利用して、Java EEのアプリケーションを配備解除する手順を説明します。
図5.5.1.3-1
図5.5.1.3-2
オートデプロイ機能での配備で利用した以下のディレクトリから、該当アーカイブを削除することで、自動的に配備解除が開始します。
${INSTANCE_ROOT}/autodeploy
ここではCORBAアプリケーションの配備解除について説明します。
CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、配備解除を行うための条件が異なります。アプリケーショングループが起動状態で配備解除を行うことを、動的配備解除と呼びます。アプリケーショングループが停止状態で配備解除を行うことを、静的配備解除と呼びます。
R4形式のCORBAアプリケーションの場合、静的配備解除のみをサポートします。配備解除を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は配備解除できません。
R5形式のCORBAアプリケーションの場合は、動的配備解除も静的配備解除もサポートしています。ただし、動的配備解除を行う場合は以下の条件を満たす必要があります。
バージョン5のプロセスグループは動的配備解除をサポートしていませんので、アプリケーショングループを停止して静的配備解除を行ってください。またCORBAアプリケーションが停止状態でない場合は、配備解除ができません。CORBAアプリケーションを停止状態にすることで、配備解除を行うことができます。ただし停止状態にする際、現在実行中のオペレーションがエラーになる可能性があります。安全な停止方法については[ 5.6. 開始と停止 > 5.6.1. Java EEのアプリケーションの開始と停止 > 5.6.1.1. コマンドを利用した開始と停止 ]を参照してください。
運用管理コマンドを利用してCORBAアプリケーションを配備解除する方法について説明します。CORBAアプリケーションを配備解除するための条件については[ 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
例えば、アプリケーション名が「corba」であるCORBAアプリケーションを配備解除するには、次のようにします。
otxadmin> undeploy corba
ここでは統合運用管理ツールを利用してCORBAアプリケーションを配備解除する手順を説明します。CORBAアプリケーションを配備解除するための条件については[ 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。
図5.5.2.3-1
図5.5.2.3-2
図5.5.2.3-3
ここではWeb版統合運用管理コンソールを利用してCORBAアプリケーションを配備解除する手順を説明します。CORBAアプリケーションを配備解除するための条件については[ 5.5.2.1. 動的配備解除と静的配備解除 ]を参照してください。
図5.5.2.4-1
図5.5.2.4-2
ここでは、共有コンポーネントの配備解除について説明します。
運用管理コマンドを利用して共有コンポーネントを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
例えば、アプリケーション名が「shared」である共有コンポーネントを配備解除するには、次のようにします。
otxadmin> undeploy shared
ここでは、統合運用管理ツールを利用して共有コンポーネントを配備解除する手順について説明します。
図5.5.3.2-1
図5.5.3.2-2
図5.5.3.2-3
ここでは、Web版統合運用管理コンソールを利用して共有コンポーネントを配備解除する手順について説明します。
図5.5.3.3-1
図5.5.3.3-2
ここでは、OSGiバンドルの配備解除について説明します。
運用管理コマンドを利用してOSGiバンドルを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
例えば、アプリケーション名が「sample」であるOSGiバンドルを配備解除するには、次のようにします。
otxadmin> undeploy sample
ここでは、統合運用管理ツールを利用してOSGiバンドルを配備解除する手順について説明します。
図5.5.4.2-1
図5.5.4.2-2
図5.5.4.2-3
ここでは、Web版統合運用管理コンソールを利用してOSGiバンドルを配備解除する手順について説明します。
図5.5.4.3-1
図5.5.4.3-2
オートデプロイ機能での配備で利用した以下のディレクトリから、該当アーカイブを削除することで、自動的に配備解除が開始します。オートデプロイ機能で配備したOSGiバンドルは、オートデプロイ機能による配備解除でしか配備解除できません。
${INSTANCE_ROOT}/autodeploy/bundles
アプリケーションが開始した状態とは、配備されたアプリケーションが動作しており、クライアントからの要求を受け付けることができる状態です。また、アプリケーションが停止した状態とは、アプリケーションが動作していない状態のことで、クライアントからの要求は受け付けることができませんが、アプリケーションは依然としてWebOTX ASの管理下にあります。この章ではアプリケーションの開始と停止について解説します。
この節では、Java EEのアプリケーションの開始と停止について説明します。特に断りがない限り、説明はJava EEアプリケーションの種類すべてに共通しているものとします。
運用管理コマンドを利用してJava EEのアプリケーションを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「enable」、「disable」を参照してください。
アプリケーションを開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。
otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名
具体例を挙げると、アプリケーション名が「myapp」であるアプリケーションを開始し、その後停止するには、次のようにします。
otxadmin> enable myapp
otxadmin> disable myapp
ここでは統合運用管理ツールを利用して、Java EEアプリケーションを開始/停止する手順を説明します。
まず、アプリケーションの開始から説明します。
図5.6.1.2-1
図5.6.1.2-2
図5.6.1.2-3
次に、アプリケーションの停止の手順について説明します。
図5.6.1.2-4
図5.6.1.2-5
図5.6.1.2-6
ここではWeb版統合運用管理コンソールを利用して、Java EEアプリケーションを開始/停止する手順を説明します。
まず、アプリケーションの開始から説明します。
図5.6.1.3-1
図5.6.1.3-2
図5.6.1.3-3
次に、アプリケーションの停止の手順について説明します。
図5.6.1.3-4
図5.6.1.3-5
図5.6.1.3-6
ここでは、CORBAアプリケーションの開始と停止について説明します。
CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、開始/停止の方法が異なります。
R4形式のCORBAアプリケーションの場合、アプリケーション単位の開始/停止はできません。プロセスグループの開始/停止、あるいはアプリケーショングループの開始/停止により、該当CORBAアプリケーションを開始/停止してください。
R5形式のCORBAアプリケーションの場合は、アプリケーション単位の開始/停止をサポートしています。ただし、アプリケーション単位の開始/停止を行う場合は以下の条件を満たす必要があります。
ただし、アプリケーション単位の開始が成功するためには、そのアプリケーションが属しているプロセスグループが開始している必要があります。
バージョン5のプロセスグループはアプリケーション単位の開始/停止をサポートしていませんので、プロセスグループの開始/停止、あるいはアプリケーショングループの開始/停止により、該当CORBAアプリケーションを開始/停止してください。
使用中のCORBAアプリケーションを停止してしまうと、以後はそのCORBAアプリケーションに対する呼び出しは失敗します。安全にCORBAアプリケーションの停止を行うためには、そのCORBAアプリケーションがクライアントから利用されていないか確認する必要があります。CORBAアプリケーションの利用状況ついては、以下の情報が参考になります。
モジュールアイドル時間が十分に長い場合、そのアプリケーションは利用されていないと判断できます。モジュールアイドル時間が-1の時は、オペレーションが実行中であることを示しています。
統合運用管理ツールを利用する場合、モジュールアイドル時間とモジュールアクティブオブジェクト数は以下の場所で確認できます。
図5.6.2.2-1
Web版統合運用管理コンソールを利用する場合、モジュールアイドル時間とモジュールアクティブオブジェクト数は以下の場所で確認できます。
図5.6.2.2-2
また、運用管理コマンドを利用する場合は、以下のようにします。
otxadmin> get applications.corba-applications.[アプリケーション名].[モジュール名].idleTime
otxadmin> get -m applications.[アプリケーション名].[モジュール名].[インタフェース名].activeObject-Current
具体例を挙げると、アプリケーション名が「myapp」、モジュール名が「corba.jar」、インタフェース名が「loopback」の場合、次のようになります。モジュール名に含まれるピリオド「.」は円マーク「\」でエスケープする必要がある点に注意してください。
otxadmin> get applications.corba-applications.myapp.corba\.jar.idleTime
otxadmin> get -m applications.myapp.corba\.jar.loopback.activeObject-Current
運用管理コマンドを利用してCORBAアプリケーションを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「enable」、「disable」を参照してください。
アプリケーション単位の開始/停止が可能な場合には、開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。
otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名
具体例を挙げると、アプリケーション名が「myapp」であるCORBAアプリケーションを開始し、その後停止するには、次のようにします。
otxadmin> enable myapp
otxadmin> disable myapp
アプリケーション単位の開始/停止がサポートされていない場合には、プロセスグループあるいはアプリケーショングループの開始/停止を行うことにより、該当CORBAアプリケーションを開始/停止します。プロセスグループの開始/停止にはオペレーションstart-pg/stop-pgを、アプリケーショングループの開始/停止にはオペレーションstart-apg/stop-apgを利用します。
otxadmin> start-pg プロセスグループ名
otxadmin> stop-pg プロセスグループ名
otxadmin> start-apg アプリケーショングループ名
otxadmin> stop-apg アプリケーショングループ名
具体例を挙げます。アプリケーショングループ「apg」、プロセスグループ「pg」に配備されているCORBAアプリケーション「myapp」があるとします。アプリケーショングループを開始することによりアプリケーションを開始し、プロセスグループを停止することによりアプリケーションを停止するには、以下のようにします。
otxadmin> start-apg apg
otxadmin> stop-pg pg
アプリケーション単位の開始/停止が可能な場合について開始と停止の方法を解説します。アプリケーショングループとプロセスグループの開始/停止の手順については[ 7. WebOTXの内部サービス > 7.1. TPシステム ]を参照してください。
まずCORBAアプリケーションを開始する手順を示します。
図5.6.2.4-1
図5.6.2.4-2
図5.6.2.4-3
次に、CORBAアプリケーションを停止する手順について解説します。
図5.6.2.4-4
図5.6.2.4-5
図5.6.2.4-6
アプリケーション単位の開始/停止が可能な場合について解説します。アプリケーショングループとプロセスグループの開始/停止の手順については[ 7. WebOTXの内部サービス > 7.1. TPシステム ]を参照してください。
まずCORBAアプリケーションを開始する手順を示します。
図5.6.2.5-1
図5.6.2.5-2
図5.6.2.5-3
次に、CORBAアプリケーションを停止する手順について解説します。
図5.6.2.5-4
図5.6.2.5-5
図5.6.2.5-6
この節では、OSGiバンドルの開始と停止について説明します。
運用管理コマンドを利用してOSGiバンドルを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスの「enable」、「disable」を参照してください。
OSGiバンドルを開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。
otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名
具体例を挙げると、アプリケーション名が「sample」であるOSGiバンドルを開始し、その後停止するには、次のようにします。
otxadmin> enable sample
otxadmin> disable sample
ここでは統合運用管理ツールを利用して、OSGiバンドルを開始/停止する手順を説明します。
まず、OSGiバンドルの開始から説明します。
図5.6.3.2-1
図5.6.3.2-2
図5.6.3.2-3
次に、OSGiバンドルの停止の手順について説明します。
図5.6.3.2-4
図5.6.3.2-5
図5.6.3.2-6
ここではWeb版統合運用管理コンソールを利用して、OSGiバンドルを開始/停止する手順を説明します。
まず、OSGiバンドルの開始から説明します。
図5.6.3.3-1
図5.6.3.3-2
図5.6.3.3-3
次に、OSGiバンドルの停止の手順について説明します。
図5.6.3.3-4
図5.6.3.3-5
図5.6.3.3-6
ライフサイクルモジュールについて説明します。
ライフサイクルモジュールとは、WebOTX ASの起動・停止のライフサイクルの状態に合わせ実行されるJavaクラスまたはモジュールであり、ユーザが作成した任意のクラスまたはモジュールをライフサイクルモジュールとすることが可能です。
WebOTX ASではライフサイクルの状態管理のために以下の状態を定義しています。ライフサイクルモジュールはこの状態により管理され、WebOTX ASのライフサイクルに同期した処理を実行します。
| 状態 | 説明 |
|---|---|
| INIT | 初期化処理中であることを表します |
| STARTUP | 起動処理中であることを表します |
| READY | サービス開始処理中であることを表します |
| SHUTDOWN | 停止処理中であることを表します |
| TERMINATION | リソース開放処理中であることを表します |
ライフサイクルモジュールが複数登録されている場合は、各ライフサイクルモジュールは並列に処理されます。たとえば、WebOTX ASが初期化の状態であるとき、全てのライフサイクルモジュールの状態はINITであり、全てのライクサイクルモジュールのINITイベントによる処理が終了するまで、次の状態には移行しません。
図5.7.1-1
ライフサイクルモジュールを登録する場合の流れについて説明します。
登録するコンポーネントとLifecycleListener実装クラスを作成します。登録に必要なファイルは以下のとおりです。
ライフサイクルモジュールをWebOTX ASに登録します。登録は統合運用管理ツールおよび運用管理コマンドで行なうことができます。
ライフサイクルモジュールの設定を変更します。この設定はライフサイクルモジュールの登録時にも行うことができます。登録後に設定の変更が必要な場合に行ってください。変更は統合運用管理ツールおよび運用管理コマンドで行なうことができます。
WebOTX ASへのライフサイクルモジュールの登録にはWebOTX ASとライフサイクルモジュールのインタフェースとして、LifecycleListenerインタフェースを実装したクラスを作成する必要があります。
LifecycleListenerインタフェースはPublicメソッドとしてhandleEventを持ちます。WebOTX ASはこのメソッドを呼び出し、LifecycleListener実装クラスに状態情報を保持したLifecycleEventクラスのオブジェクトを渡します。
LifecycleEventクラスは状態情報として以下のpublicかつstaticなフィールドを持ちます。
| フィールド名 | 説明 |
|---|---|
| INIT_EVENT | ライフサイクルモジュールの初期化処理中であることを表します |
| STARTUP_EVENT | ライフサイクルモジュールの起動処理中であることを表します |
| READY_EVENT | ライフサイクルモジュールのサービス開始処理中であることを表します |
| SHUTDOWN_EVENT | ライフサイクルモジュールの停止処理中であることを表します |
| TERMINATION_EVENT | ライフサイクルモジュールのリソース開放処理中であることを表します |
LifecycleListener実装クラスでは、この状態情報に応じた処理を実装する必要があります。
LifecycleListener実装クラスの実装方法については[ アプリケーション開発ガイド（共通） > 2. ライフサイクルモジュールの開発 ] を参照してください。
統合運用管理ツールよりライフサイクルモジュールの登録・登録削除および一覧を取得する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。
| LifecycleListener実装クラス名 | sample.SampleLifecycleModule |
|---|---|
| モジュールとLifecycleListener実装クラスを含むjarファイル名 | sample.jar |
| jarファイル配置位置 | Cドライブ直下 |
| ライフサイクルモジュールの登録名 | Sample |
| アプリケーショングループ名 | apg |
| プロセスグループ名 | pg |
以下の手順で登録します。なお、ここではライフサイクルモジュール名に加え、クラスパスと必須入力項目であるクラス名のみ指定しています。必要に応じて他の設定項目を入力して実行してください。
図5.7.4.1-1
WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループ上で動作させる場合は、追加で以下の作業も必要になります。
ドメインからライフサイクルモジュールを登録削除する手順を示します。WebOTX AS Standard/Enterpriseで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからライフサイクルモジュールを登録削除する必要がある点に注意してください。
図5.7.4.2-1
次に、プロセスグループからライフサイクルモジュールを登録削除する手順を示します。
まず、ドメインに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。
次に、プロセスグループに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。こちらはWebOTX AS Standard/Enterpriseでサポートしています。
図5.7.4.3-1
Web版統合運用管理コンソールよりライフサイクルモジュールの登録・登録削除および一覧を取得する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。
| LifecycleListener実装クラス名 | sample.SampleLifecycleModule |
|---|---|
| モジュールとLifecycleListener実装クラスを含むjarファイル名 | sample.jar |
| jarファイル配置位置 | Cドライブ直下 |
| ライフサイクルモジュールの登録名 | Sample |
| アプリケーショングループ名 | apg |
| プロセスグループ名 | pg |
以下の手順で登録します。なお、ここではライフサイクルモジュール名に加え、クラスパスと必須入力項目であるクラス名のみ指定しています。必要に応じて他の設定項目を入力して実行してください。
図5.7.5.1-1
WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループ上で動作させる場合は、追加で以下の作業も必要になります。
ドメインからライフサイクルモジュールを登録削除する手順を示します。WebOTX AS Standard/Enterpriseで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからライフサイクルモジュールを登録削除する必要がある点に注意してください。
図5.7.5.2-1
次に、プロセスグループからライフサイクルモジュールを登録削除する手順を示します。
まず、ドメインに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。
次に、プロセスグループに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。こちらはWebOTX AS Standard/Enterpriseでサポートしています。
図5.7.5.3-1
運用管理コマンドよりライフサイクルモジュールコンポーネントの登録および登録削除する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。
| LifecycleListener実装クラス名 | sample.SampleLifecycleModule |
|---|---|
| モジュールとLifecycleListener実装クラスを含むjarファイル名 | sample.jar |
| jarファイル配置位置 | Cドライブ直下 |
| ライフサイクルモジュールの登録名 | Sample |
| アプリケーショングループ名 | apg |
| プロセスグループ名 | pg |
ライフサイクルモジュールをドメインに登録するには、登録するコンポーネントとライフサイクルモジュールの初期設定情報を指定して、create-lifecycle-moduleコマンドを実行します。なお、ここではコマンドのオプションとしてclasspathと必須オプションであるclassnameのみ指定しています。必要に応じて他のオプションを指定して実行してください。
otxadmin> create-lifecycle-module -classname sample.SampleLifecycleModule -classpath C:/Sample.jar Sample
WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループに登録するには、登録するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を指定して、add-pg-lifecycle-moduleコマンドを実行します。
otxadmin> add-pg-lifecycle-module -apgroup apg pgroup pg Sample
ライフサイクルモジュールをドメインから登録削除するには、登録削除するライフサイクルモジュール名を指定して、delete-lifecycle-moduleコマンドを実行します。ただし、WebOTX AS Standard/Enterpriseをお使いで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからの登録削除を行う必要があります。
otxadmin> delete-lifecycle-module Sample
WebOTX AS Standard/Enterpriseにおいて、ライフサイクルモジュールをプロセスグループから登録削除するには、登録削除するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を指定して、remove-pg-lifecycle-moduleを実行します。
otxadmin> remove-pg-lifecycle-module -apgroup apg -pgroup pg Sample
ドメインに登録されたライフサイクルモジュールの一覧を取得するには、list-lifecycle-modulesコマンドをオプション指定なしで実行します。
otxadmin> list-lifecycle-modules
WebOTX AS Standard/Enterpriseにおいて、プロセスグループに登録されたライフサイクルモジュールの一覧を取得するには、オプションで一覧を取得したいプロセスグループのアプリケーショングループ名、プロセスグループ名を指定し、list-lifecycle-modulesコマンドを実行します。
otxadmin> list-lifecycle-modules -apgroup apg -pgroup pg
ライフサイクルモジュールはJMX仕様に基づき、WebOTX AS内で管理対象オブジェクト(Managed Object: MO)として登録され、管理されます。
登録されたライフサイクルモジュールは統合運用管理ツールまたは運用管理コマンドからその設定を変更することが可能です。ただし設定の変更を反映させるには、そのライフサイクルモジュールの登録先(ドメイン又はプロセスグループ)を再起動する必要があります。
ライフサイクルモジュールの設定項目についての一覧を以下に示します。なお、MOの詳細については [ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス ] を参照してください。また、設定方法については [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス ] を参照してください。
| 属性名 | 値 | 統合運用管理ツールでの表記 | Dotted Name | 説明 |
|---|---|---|---|---|
| name | 文字列 | ライフサイクルモジュール名 | server.applications.lifecycle-module.ライフサイクルモジュール名.name | ライフサイクルモジュール名です。ここで指定した名前でライフサイクルモジュールをドメインに登録します。ただし、文字列にスペースを混入させることはできません。 |
| class-name | 文字列 | ライフサイクルモジュールクラス名 | server.applications.lifecycle-module.ライフサイクルモジュール名.class-name | LifecycleListener実装クラスのクラス名を、パッケージ名を含めて指定します。 |
| classpath | 文字列 | クラスパス | server.applications.lifecycle-module.ライフサイクルモジュール名.classpath | ライフサイクルモジュールとして登録するコンポーネントのクラスパスです。クラスパスを複数指定する場合は各パスをWindows OSでは「；」、UNIX系OSでは「：」で区切ってください。また、クラスパスの通っているフォルダ/ディレクトリに格納する場合はクラスパスの指定は不要になります。(例. <INSTANCE_ROOT>/libなど) |
| load-order | 数値 | サービス実行順番 | server.applications.lifecycle-module.ライフサイクルモジュール名.load-order | サーバ起動時に、この起動順序番号に従って各モジュールが順次起動されます。既定ではドメインに登録された順序に従って起動されます。ライフサイクルモジュールの起動順序に依存関係がある場合はこの値を指定する必要があります。 |
| is-failure-fatal | true/false | サービス起動失敗時動作 | server.applications.lifecycle-module.ライフサイクルモジュール名.is-failure-fatal | 既定値falseを選択するとドメイン起動時にライフサイクルモジュールの起動処理に失敗した場合でもその起動処理を継続します。trueを選択すると、ライフサイクルモジュールの起動処理に失敗した場合にドメイン(またはプロセスグループ)を停止することができます。詳細は後述の「is-failure-fatalの設定効果について」をご覧ください。 |
| enabled | true/false | サービス起動設定 | server.applications.lifecycle-module.ライフサイクルモジュール名.enabled | ライフサイクルモジュールの有効の可否を決定します。 |
| description | 文字列 | 説明 | server.applications.lifecycle-module.ライフサイクルモジュール名.description | 登録したライフサイクルモジュールに関する説明書き欄です。 |
| property | 文字列 | (以下で解説) | server.applications.lifecycle-module.ライフサイクルモジュール名.property.プロパティ名 | ユーザにより定義可能なライフサイクルモジュールの任意のプロパティです。「プロパティ名＝値」の形式で指定してください。運用管理コマンドから複数指定する場合はプロパティの組を「：」で繋げてください。 |
属性propertyはライフサイクルモジュールの「一般」タグ内には表示されません。統合運用管理ツールからpropertyを取得・設定するにはツール上のライフサイクルモジュールの右クリックから「プロパティ一覧の取得」または「プロパティの設定」を実行してください。
図5.7.7.1-1
Web版統合運用管理コンソールの場合、左側のツリービューより作成したライフサイクルモジュールを選択し、「操作」リストの下の「プロパティ一覧の取得」または「プロパティの設定」を選択してください。
図5.7.7.1-2
なお、コマンドからpropertyを取得・設定するにはその他の設定項目同様にget・setコマンドを使用してください。
ライフサイクルモジュールの設定項目is-failure-fatalをtrueに設定する場合は、同時に次の設定を行ってください。
・ドメインを停止する場合(ドメインに登録されたライフサイクルモジュールに設定が適用されます)
otxadmin> set server.internal-lifecycle-module.LifecycleModuleService.is-failure-fatal=true
・プロセスグループを停止する場合(プロセスグループに登録されたライフサイクルモジュールに設定が適用されます)
otxadmin> set サーバ名.internal-lifecycle-module.LifecycleModuleService.is-failure-fatal=true
また、登録されているライフサイクルモジュールが複数ある場合は、そのライフサイクルモジュールのいずれかの起動が失敗すると、その起動順序によっては他のライフサイクルモジュールの起動処理がスキップされることがあります。 この時、各ライフサイクルモジュールの初期化が正常に行われなくなることがあります。例えば、ライフサイクルモジュール間に依存関係があり、登録した全てのライフサイクルモジュールが正常に起動することが前提条件にある場合は、上記の設定を行うことを推奨します。
WebOTX ASでは複数プロセスグループ上でライフサイクルモジュールの機能を提供するため、各プロセスグループ上からはドメインに登録されたライフサイクルモジュールの情報を参照し、設定情報を取得しています。したがって、ドメインに登録された情報への参照の有効・無効を設定することで、プロセスグループごとにライフサイクルモジュールの有効・無効を設定することができます。
以下の図はドメイン上のライフサイクルモジュールの情報を各プロセスグループから参照する場合のイメージです。ただし、ここでは各プロセスグループを表すのにアプリケーショングループ名とプロセスグループ名を-(ハイフン)でつないだサーバ名で表しています。
図5.7.7.2-1
参照の有効・無効設定を行うには、運用管理コマンドから以下の手順で変更します。
otxadmin> set サーバ名.application-ref.ライフサイクルモジュール名.enabled=true
または
otxadmin> set サーバ名.application-ref.ライフサイクルモジュール名.enabled=false
この章では主に配備処理を高速化する方法について解説します。アプリケーションの開発時には、配備／配備解除が頻繁に繰り返されるため、配備処理の高速化を意識することで開発効率が向上します。
TPモニタでは、オペレーション毎にトランザクション等の実行時情報を管理する機能を備えています。あるモジュールが配備されると、TPモニタでは個々のオペレーションを識別するために番号を付与して、内部管理テーブルと状態情報との関連付けを行います。EJBモジュールの場合には、オペレーションがリモートインタフェースのメソッドに該当します。
メソッド識別情報の割り当て範囲を限定することにより、配備処理中に行われる識別情報の生成数を削減し、配備処理にかかる時間の短縮およびメモリ消費量の削減が可能です。
割り当て方法は以下の中から選択できます。
全てのリモートメソッドに割り当てます。
おもにユーザ定義のメソッドについて割り当てます。リモートインタフェース、ホームインタフェースのメソッドの割り当てについてはEJB種別によって異なります。下記表を参照してください。
リモートメソッドに対しては割り当てません。
| メソッド名 | ステートレスSession Bean | ステートフルSession Bean | Entity Bean | メッセージドリブンBean |
|---|---|---|---|---|
| リモートインタフェース | ||||
| getEJBHome() | × | × | × | - |
| getPrimaryKey() | × | × | × | - |
| getHandle() | × | × | × | - |
| isIdentical(javax.ejb.EJBObject) | × | × | × | - |
| remove() | × | ○ | ○ | - |
| ホームインタフェース | ||||
| getEJBMetaData() | × | × | × | - |
| getHomeHandle() | × | × | × | - |
| remove(java.lang.Object) | × | × | ○ | - |
| remove(javax.ejb.Handle) | × | ○ | ○ | - |
| [EJB生成メソッド](例：create()メソッド) | × | ○ | ○ | - |
| [ファインダメソッド](例：findByPrimaryKey(String)メソッド) | - | - | ○ | - |
| ○ | 割り当てます |
|---|---|
| × | 割り当てません |
| - | 存在しません |
（注：メッセージドリブンBeanのonMessage()メソッド、タイマーBeanのejbTimeout()メソッドについてはリモートメソッドではありませんが、どのオプションでも割り当てられます。）
識別情報を割り当てなかったメソッドに対しては以下の機能が使用できなくなります。
しかしながら、割り当てるメソッド数を減らすことにより、モジュールの配備時間が向上し、消費メモリ量が削減されます。
注意：「割り当てない」オプションを使用すると障害発生時の原因解析が困難になる場合があります。頻繁に配備／配備解除を繰り返す開発時には有用ですが、本番環境では「ビジネスメソッドのみ割り当てる」もしくは「全てのリモートメソッドに対して割り当てる」を使用することを強く推奨します。
これらのオプションの指定は、EJBモジュールを配備操作する時に行います。以下では、配備操作を支援する機能毎に説明します。
コンポーネント配備ダイアログの「EJBメソッド識別情報の割り当て方法」で設定します。
deploy サブコマンドに「--methodid」オプションを指定します。
| --methodid all | 全てのリモートメソッドに対して割り当てる |
|---|---|
| --methodid limit | ビジネスメソッドのみ割り当てる (既定値) |
| --methodid none | 割り当てない |
ドメインのautodeployディレクトリ下のautodeploy.propertiesファイルで以下の指定をします。
| methodid=all | 全てのリモートメソッドに対して割り当てる |
|---|---|
| methodid=limit | ビジネスメソッドのみ割り当てる (既定値) |
| methodid=none | 割り当てない |
この章では、WebOTX AS が利用するクラスローダについて解説します。クラスローダについての知識は、アプリケーションが共通に利用するクラスファイルやJar ライブラリの配置場所を決定する際に役立ちます。
クラスローダは階層構造になっており、この階層構造に従ってクラスをロードします。Java VM
等からクラスのロードの要求があった場合、クラスローダはまず親のクラスローダにクラスのロード処理を委譲します。親のクラスローダでクラスがロードできなかった場合、そのクラスローダ自身でクラスをロードしようとします。それでもクラスが見つからない場合、NoClassDefFoundError
またはClassNotFoundException
がスローされます。WebOTX ASのクラスローダについて理解しておくことは、開発者や運用者がアプリケーション共通で使うJARアーカイブやアプリケーション・モジュールのためのリソース・ファイルを、どの位置に配置すべきかを決める際に重要な助けとなります。
WebOTX AS で利用しているクラスローダの階層を以下の図に示します。
図5.9.1-1
ブートストラップクラスローダからApplibsクラスローダまでは、同一Java VM 内で共通に利用するクラスローダです。破線で囲まれたクラスローダは、アプリケーションをロードするクラスローダです。WAR、EJB、EAR、ライフサイクルモジュールはクラスローダによって分離されているため、お互い干渉することなく動作することができます。RAR は他のアプリケーションから利用されるという性質上、コネクタクラスローダはドメイン内で共通に利用されます。Applibsクラスローダはドメイン内で共通ですが、アプリケーションからは配備時に指定したライブラリのみ参照可能です。また、共有コンポーネントクラスローダは、WebOTX AS Standard/Enterpriseで利用されます。
一般に、下位のクラスローダでロードしたクラスは上位のクラスローダでロードしたクラスを参照できますが、その逆はできません。つまり、上位のクラスローダでロードしたクラスは、下位のクラスローダでロードしたクラスを参照できず、NoClassDefFoundErrorまたはClassNotFoundExceptionの原因となります。アプリケーションを構築する上で、この原則に従うようにライブラリを配置する必要があります。
ここでは、ブートストラップクラスローダから共有コンポーネントクラスローダまでを解説します。同一Java VM 内で動作するすべてのアプリケーションは、これらのクラスローダを共有します。これらのクラスローダがロードする対象についての概要図を、以下の図に示します。
図5.9.2-1
図中の鍵括弧で囲まれた部分は、以下のパスを示しています。
[JAVA_HOME]JDK のインストール先を示しています。
[WEBOTX]WebOTX AS のインストール先を示しています。デフォルトのインストール先は、以下の通りです。
| OS | パス |
|---|---|
| Windows | C:\WebOTX |
| UNIX系 | /opt/WebOTX |
[DOMAIN]WebOTX AS で利用するドメインのパスを示しています。デフォルトのドメインを利用する場合は、以下のパスになります。
| OS | パス |
|---|---|
| Windows | C:\WebOTX\domains\domain1 |
| UNIX系 | /opt/WebOTX/domains/domain1 |
以降では、これらのクラスローダの詳細を解説します。
このクラスローダは、Java の標準のクラスライブラリをロードするクラスローダです。ブートストラップクラスローダに親のクラスローダはありません。ブートストラップクラスローダは、以下のJar ファイルから標準のクラスライブラリを読み込みます。
[JAVA_HOME]/jre/lib/*.jar
このパスはJDK 依存のパスであり、JDK のバージョンやJDK のベンダによって異なる可能性があります。
このクラスローダは、Java の拡張機能を読み込むクラスローダです。拡張クラスローダの親クラスローダはブートストラップクラスローダです。拡張クラスローダは、以下のJar ファイルから拡張機能を実装しているクラスライブラリを読み込みます。
[JAVA_HOME]/jre/lib/ext/*.jar
[DOMAIN]/lib/ext/*.jar
[JAVA_HOME]/jre/lib/extには、JDK が標準で提供する拡張機能のJar
ライブラリが配置されています。このパスはJDK 依存のパスであり、JDK のバージョンやJDK
のベンダによって異なる可能性があります。
[DOMAIN]/lib/ext にJarライブラリを配置すると、WebOTX AS
に対して拡張機能を提供することができます。アプリケーションでJDBC ドライバを利用する場合、このディレクトリにJDBC
ドライバを格納したJar ライブラリを配置する必要があります。
拡張クラスローダの詳細については、以下のJDK のマニュアルを参照してください。
http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/
http://docs.oracle.com/javase/jp/6/technotes/guides/extensions/
システムクラスローダは、WebOTX AS本体の起動に必要なライブラリのみをロードします。システムクラスローダの親クラスローダは拡張クラスローダです。
エージェントプロセスでは、domain.xmlの設定を変更することで、ユーザ定義のクラスをシステムクラスローダで読み込ませることができます。 ただし、この設定を正しく行うためにはWebOTX ASへの深い知識が必要になりますので、通常は共通クラスローダもしくは拡張クラスローダを利用してユーザ定義のクラスライブラリをロードします。
また、アプリケーション用のクラスローダは、システムクラスローダを親に持たないため、システムクラスローダのクラスパスに含まれるクラスやリソースをアプリケーション用のクラスローダから参照することはできません。WebOTX V8までの環境でclasspath-suffixや環境変数CLASSPATHを使用してユーザ定義のライブラリをロードしていた場合は、jarファイルを[DOMAIN]/lib/に置くか、server-classpathを使用することで、[5.9.2.5. 共通クラスローダ] でロードするように設定してください。
system-classpathdomain.xml
中の要素<java-config>の属性system-classpathで指定したクラスパスは、WebOTX AS本体の起動に必要なライブラリの後に読み込まれます。デフォルトではこの属性には何も指定されていません。
CLASSPATHdomain.xml
中の要素<java-config>で属性env-classpath-ignored="false"の指定があった場合、環境変数CLASSPATH
で指定されたクラスパスを読み込みます。環境変数CLASSPATHは、要素<java-config>の属性system-classpathで指定したクラスパスの後に読み込まれます。デフォルトでは属性env-classpath-ignored="true"が設定されており、環境変数CLASSPATHは読み込まれません。
WebOTX V8まで存在した属性classpath-prefixおよびclasspath-suffixは、WebOTX V9で廃止されました。また、WebOTX V8までシステムクラスローダのクラスパスを指定するために使用されていた属性server-classpathは、WebOTX V9では、後述の共通クラスローダのクラスパスを指定するために使用されます。
まとめると、エージェントプロセスのシステムクラスローダでは以下の順でクラスパスを検索します。
system-classpathに指定したクラスパスCLASSPATH
(env-classpath-ignored="false"の場合)一方プロセスグループにおいては、domain.xml
中のsystem-classpath等の設定は反映されません。これらのクラスパスに関する設定は、エージェントプロセスに対するものだからです。プロセスグループでは、そのプロセスグループに対して環境変数CLASSPATH
を設定することで、システムクラスローダにクラスパスを追加することができます。設定の反映には、アプリケーショングループの再起動が必要になります。統合運用管理ツールでの設定場所を、以下の図に示します。
図5.9.2.3-1
まとめると、プロセスグループのシステムクラスローダは、以下の順でクラスパスを検索します。
CLASSPATH (もし設定されていれば)パブリックAPIクラスローダは、配備されたアプリケーション用にWebOTXが明示的にエクスポートしているクラスを使用可能にします。この中には、Java EE APIなどが含まれます。パブリックAPIクラスローダの親クラスローダは拡張クラスローダです。パブリックAPIクラスローダは、以下の場所からクラスライブラリを読み込みます。
[WEBOTX]/modules/*.jar
[WEBOTX]/modules/にはWebOTXの動作に必要なJarファイルが配置されています。ここに配置されたファイルの構成を変更する事はサポート対象外であり、このディレクトリにユーザ定義のJarを配置してはいけません。
共通クラスローダは、ドメイン内で動作するアプリケーションで共通に利用するクラスをロードします。共通クラスローダの親クラスローダはパブリックAPIクラスローダです。
共通クラスローダは、以下の場所からクラスライブラリを読み込みます。
[WEBOTX]/lib/*.jar[DOMAIN]/lib/classes[DOMAIN]/lib/*.jar
[WEBOTX]/lib/にユーザ定義のJarを配置することは、サポート対象外です。
[DOMAIN]/lib/classesには、ドメイン内で共通に利用するクラスのクラスファイルを配置します。[DOMAIN]/libには、ドメイン内で共通に利用するクラスが格納されているJarファイルを配置します。
上記の位置に複数のアプリケーションで共通に利用するライブラリを配置すると、WAR ファイルやEARファイルの中にライブラリを含める必要がなくなります。ただし、共通するライブラリをバージョンアップ等の理由で置換すると、そのライブラリを利用する全てのアプリケーションが影響を受けます。また、ライブラリを追加・削除・置換する際には、ドメインを再起動する必要があります。
domain.xmlのserver-classpathやシステムプロパティcom.nec.webotx.enterprise.common-classpathを設定することで、ユーザ定義のクラスを共通クラスローダで読み込ませることができます。
server-classpathdomain.xml中の要素<java-config>の属性server-classpathで指定したクラスパスは、[DOMAIN]/lib/*.jarの後に読み込まれます。この設定は、エージェントプロセスとプロセスグループの両方で有効です。デフォルトではこの属性には何も指定されていません。
com.nec.webotx.enterprise.common-classpathシステムプロパティcom.nec.webotx.enterprise.common-classpathで指定したクラスパスは、server-classpathの後に読み込まれます。この設定は、エージェントプロセスと各プロセスグループごとに個別に設定できます。デフォルトではこのシステムプロパティは設定されていません。
このクラスローダは、WebOTX AS Standard/Enterpriseで利用可能であり、配備した共有コンポーネントをロードするクラスローダです。共有コンポーネントクラスローダの親クラスローダは共通クラスローダです。
共有コンポーネントの更新を行なう場合は、その共有コンポーネントを利用している全てのアプリケーションを停止すればよく、プロセスグループの再起動は必要ありません。そのため、その他の動作中のアプリケーションに影響を及ぼすことなく、ライブラリの更新が可能です。
コネクタクラスローダはJCAに準拠したリソースアダプタを読み込むためのクラスローダです。 コネクタクラスローダの親クラスは共有コンポーネントクラスローダです。 EARに含まれていないスタンドアローンのリソースアダプタはコネクタクラスローダでロードされます。EARに含まれているリソースアダプタは、後述のEAR内部コネクタクラスローダでロードされます。 リソースアダプタは他のアプリケーションから利用されるという性質上、コネクタクラスローダはドメイン内で共有されます。
以下の図では、例として二つのリソースアダプタlegacy-ra.rarとmain-frame-ra.rarを配備した状態のコネクタクラスローダの概要図を示します。
図5.9.3-1
最上位のブートストラップクラスローダから最下位のコネクタクラスローダまで、6つのクラスローダが関係しています。
クラスをロードする優先順位は1位のブートストラップクラスローダから始まり、コネクタクラスローダは最後の6位になります。
コネクタクラスローダはlegacy-ra.rarとmain-frame-ra.rarを読み込みますが、これらのファイルに含まれるJarライブラリもロードの対象になります。
スタンドアローンのリソースアダプタは、Java EE 5では、全てのアプリケーションから参照可能でしたが、Java EE 6(JCA1.6)では、アプリケーションの配備記述子やアノテーションなどで指定したリソースアダプタのみが参照可能に変更されました。domain.xmlの以下の設定を変更することで、Java EE 5とJava EE 6のいずれに準拠した動作となるか設定できます。
class-loading-policydomain.xml中の要素<connector-service>の属性class-loading-policyに、"derived"を指定するとJava EE 6に準拠した動作となり、アプリケーションからは指定したリソースアダプタのみが参照可能になります。"global"を指定するとJava EE 5に準拠した動作になり、全てのリソースアダプタがアプリケーションから参照可能になります。デフォルトは、"derived"で、Java EE 6に準拠した動作になります。
class-loading-policyの値をotxadminコマンドで変更するには、以下のコマンドを実行します。(コマンド例は"global"に設定する場合)
otxadmin> set server.connector-service.class-loading-policy=global
設定値を確認するには、以下のコマンドを実行します。
otxadmin> get server.connector-service.class-loading-policy
EJB/WAR/EAR/RARで利用されるクラスローダです。
配備時に指定されたアプリケーション固有のライブラリを読み込みます。
ライブラリは[DOMAIN]/lib/applibsに配置し、配備時には[DOMAIN]/lib/applibsからの相対パスでライブラリを指定します。
アプリケーション固有のライブラリは、他のアプリケーションと共有されますが、配備時に指定したライブラリしか参照できません。
なお、Applibsクラスローダでロードされる jar ファイルのクラスは、Applibsクラスローダでロードされる他の jar ファイルのクラスやリソースを参照することはできません。
otxadminコマンドでは、以下のように指定します。
otxadmin> deploy --libraries [ライブラリのパス] [アーカイブ]
以降のWAR、EJB、EARのクラスローダの解説では、説明の便宜上mylib.jarをアプリケーション固有のライブラリに指定して配備したとします。
例えば、otxadminコマンドを利用した配備では、以下のようにして配備したとします。
otxadmin> deploy --libraries mylib.jar [アーカイブ]
スタンドアロンのWAR(すなわちEAR に含まれていないWAR)のクラスローダの構成を、下の図に示します。
図5.9.5-1
WAR のクラスローダは、Servlet 用のWebApp クラスローダとJSP 用のJSPクラスローダに分かれています。 JSP は実行時に動的にServletに変換されるために、このような構造になっています。 最上位のブートストラップクラスローダから最下位のJSP クラスローダまで、9つのクラスローダが関係しています。
Servlet を読み込むWebAppクラスローダは、/WEB-INF/classesに配置したクラスファイルと/WEB-INF/libに配置したJarライブラリを読み込みます。
一方JSP を読み込むJSPクラスローダは、/WEB-INFおよび/META-INF以外のディレクトリに配置されているJSPを読み込みます。
WebApp クラスローダは、クラスのロード処理を親クラスローダに委譲するタイミングを、以下の2 つから選択できます。
(1) 親クラスローダ優先。まず親クラスローダにクラスのロードを委譲し、見つからなかった場合にWebApp クラスローダでロード。
(2) WebApp クラスローダ優先。まずWebApp クラスローダでクラスのロードを試みて、見つからなかった場合に親クラスローダにクラスのロードを委譲。
「(1)親クラスローダ優先」は他のクラスローダでも採用されている一般的なクラスの探索方法であり、親のクラスローダでロードするクラスを優先的に利用します。(2)はWebApp
クラスローダ特有の探索方法であり、WebApp
クラスローダがロードするクラスを優先的に利用します。すなわち(2)を採用した場合、Servlet
は上位のクラスローダがロードするクラスをWEB-INF/classesまたはWEB-INF/libにあるクラスで置換することができます。
ロード処理の優先順位の制御は、WEB-INF/nec-web.xml中の要素<class-loader>の属性delegateで指定します。
<?xml version="1.0" encoding="UTF-8"?> <nec-web-app> <context-root>myapp</context-root> <class-loader delegate="true"/> </nec-web-app>
属性delegate="true"の場合は、「(1)
親クラスローダ優先」となり、属性delegate="false"の場合は、「(2) WebApp
クラスローダ優先」となります。要素<class-loader>を省略した場合や、WEB-INF/nec-web.xmlそのものを省略した場合の属性delegateのデフォルト値は、Servlet
のバージョンによって異なります。Servlet 2.4 では属性delegate
のデフォルト値は"true"であり、Servlet 2.3
以前では"false"です。
以降では、属性delegateの値別に、クラスのロードの具体的な動作を解説します。
delegate="true"の場合のクラスローダの動作ここでは、属性delegate="true"の場合のクラスローダの動作について説明します。
まずServlet の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。 Servlet の視点では、JSPクラスローダはクラスのロード処理に関与しない点に注意してください。
図5.9.5.2-1
WebApp クラスローダがServlet等のクラスをロードする際、まず親クラスローダであるApplibsクラスローダにクラスのロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはWebAppクラスローダで、優先順位8位になります。
次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。
図5.9.5.2-2
JSPクラスローダはJSP のみをロードする特別なクラスローダです。JSPクラスローダに対してロード要求があった場合、まずJSPクラスローダ自身でJSPのロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダにロード処理を委譲します。 そのためブートストラップクラスローダが優先順位2位です。最も優先順位の低いクラスローダは優先順位9位のWebAppクラスローダです。
delegate="false"の場合のクラスローダの動作ここでは、属性delegate="false"の場合のクラスローダの動作について説明します。
まずServlet の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。 Servlet の視点では、JSPクラスローダは無関係である点に注意してください。
図5.9.5.3-1
WebApp クラスローダがServlet 等のクラスをロードする際、まずWebAppクラスローダ自身でクラスのロードを試みます。 従って、WebApp クラスローダは優先順位1位になります。 WebAppクラスローダでクラスをロードできなかった場合は、親クラスローダであるApplibsクラスローダにクラスのロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位2位となり、Applibsクラスローダは優先順位8位になります。
次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。
図5.9.5.3-2
JSP クラスローダはJSP のみをロードする特別なクラスローダです。 JSPクラスローダに対してロード要求があった場合、まずJSP クラスローダ自身でJSP のロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダは親クラスローダにロード処理を委譲する前に、自身でクラスのロードを試みます。 従って、WebApp クラスローダは優先順位2位になります。 WebAppクラスローダでクラスをロードできなかった場合は、親クラスローダであるApplibsクラスローダにクラスのロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位3位となり、Applibsクラスローダは優先順位9位になります。
スタンドアロンのEJB(すなわちEARに含まれていないEJB)のクラスローダの構成を、以下の図に示します。 以下の図は、例としてbackend-ejb.jarを配備したときのEJB クラスローダの概要図です。
図5.9.6-1
最上位のブートストラップクラスローダから最下位のEJB クラスローダまで、8つのクラスローダが関係しています。 EJBクラスローダを利用してクラスをロードする場合、まず親クラスローダであるApplibsクラスローダにロード処理を委譲します。 Applibsクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはEJBクラスローダで、優先順位8位になります。
EAR はWAR、EJB、RARを含むことのできる、「アプリケーションのとりまとめ」のような役割を担っています。
そのため、クラスローダの構成も、他のアプリケーションと比べると複雑になっています。
ここでは以下のようなEAR(app.ear)を例に挙げ、解説を行います。
app.ear) の構成
(META-INF/application.xml)web-app.warとother-web-app.war)backend-ejb.jar)legacy-ra.rar)lib/common.jarとlib/utilities.jar)/META-INF/nec-web.xml
の属性delegate)
web-app.war はdelegate="true"に設定other-web-app.war
はdelegate="false"に設定Class-Path:
web-app.war は、Class-Path:
lib/common.jar と設定backend-ejb.jar は、Class-Path:
lib/utilities.jar と設定まとめると、app.earは以下のような構成になります。
app.ear META-INF/application.xml web-app.war (delegate="true"、Class-Path: lib/common.jar) other-web-app.war (delegate="false") backend-ejb.jar (Class-Path: lib/utilities.jar) legacy-ra.rar lib/common.jar lib/utilities.jar
app.earを配備した際のクラスローダの構成を以下の図に示します。
図5.9.7.1-1
EAR のクラスローダは、以下のクラスローダから構成されます。
[DOMAIN]/lib/applibs配下の指定したJarをロードするクラスローダです。
Applibsクラスローダの親クラスローダはコネクタクラスローダです。
EAR内のlibディレクトリにあるライブラリをロードするクラスローダです。このライブラリは、EAR内の全てのモジュールから参照可能です。ディレクトリは配備記述子(application.xml)の要素<library-directory>で指定できます(デフォルト値はlib)。EAR Libクラスローダの親クラスローダはApplibsクラスローダです。
EAR内のRARをロードするクラスローダです。EAR内部コネクタクラスローダの親クラスローダはEAR Libクラスローダです。
WebOTX V8では、EAR内のRARもドメイン内で共通のコネクタクラスローダでロードされており、他のアプリケーションからも利用可能でしたが、WebOTX V9ではJava EE 6の仕様に準拠するために、EAR内のRARは他のアプリケーションからは利用できないように変更されました。
EJB をロードするクラスローダです。
EJB クラスローダの親クラスローダはEAR内部コネクタクラスローダです。
EAR内に含まれるEJB の数とは関係なく、必ず1 つだけ存在します。EJB
クラスローダは、EJBだけではなく、マニフェストファイルの属性Class-Pathで指定したライブラリもロードの対象とします。
WAR をロードするクラスローダです。EAR 内に含まれるWAR の数だけ存在します。WebApp クラスローダの親クラスローダはEJB クラスローダです。WebApp クラスローダとJSP クラスローダは対になっており、JSP クラスローダの親クラスローダは、それと対のWebApp クラスローダです。
EAR の中には、WAR やEJB で共通に利用するライブラリを含めることができます。
Java EE 5以降に準拠したEARでは、EAR内のlibというディレクトリにJarを配置してください。
図5.9.7.2-1
J2EE 1.4以前に準拠したEARでは、単にEARに含めるだけではロードの対象にはなりません。
そのライブラリを利用するWAR やEJBのマニフェストファイルの属性Class-Pathにライブラリのパスを記述する必要があります。
ライブラリのパスは、EARファイルのトップディレクトリからの相対パスでなければいけません。
例えば、web-app.warはlib/common.jarを利用するために、web-app.warに次のようなマニフェストファイルを含めます。
Manifest-Version: 1.0 Created-By: 1.5.0_18-b02 (Sun Microsystems Inc.) Class-Path: lib/common.jar
EAR内で共通に利用するライブラリに着目したapp.earのクラスローダの構成図を以下に示します。
J2EE 1.4以前のEARでは、図にある通りマニフェストファイルにライブラリのパスを記述する必要があります。
図5.9.7.2-2
EJBでのマニフェストファイルの属性Class-Pathの利用には副作用がある点に注意してください。
EJBのマニフェストファイルの属性Class-Pathに記述したライブラリはEJBクラスローダでロードされるため、その属性を持たないアプリケーションでも利用可能になります。
例えば、other-web-app.warはマニフェストファイル中に属性Class-Pathを持ちませんが、親クラスローダであるEJBクラスローダがlib/utilities.jarをロードしているため、これらのライブラリを利用することができます。
delegate="true")ここではWEB-INF/nec-web.xmlに<class-loaderdelegate="true"/>を含んでいるweb-app.warについてのクラスローダの動作を説明します。
すなわち、WebAppクラスローダはクラスのロード処理を親クラスローダに優先的に委譲します。
また、もう一つのWARであるother-web-app.warのクラスローダは、クラスのロード処理に関与しない点に注意してください。
まずServlet の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。 Servletの視点では、JSPクラスローダはクラスのロードに関与しません。
図5.9.7.3-1
WebAppクラスローダがServlet等のクラスをロードする際、まず親クラスローダであるEJBクラスローダにクラスのロード処理を委譲します。 EJBクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはWebAppクラスローダで、優先順位11位になります。
次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。
図5.9.7.3-2
JSP クラスローダはJSP のみをロードする特別なクラスローダです。 JSPクラスローダに対してロード要求があった場合、まずJSP クラスローダ自身でJSP のロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダにロード処理を委譲します。 そのためブートストラップクラスローダが優先順位2位となり、WebApp クラスローダは優先順位12位になります。
delegate="false")ここではWEB-INF/nec-web.xmlに<class-loaderdelegate="false"/>を含んでいるother-web-app.warについてのクラスローダの動作を説明します。
すなわち、WebAppクラスローダはクラスのロード処理を優先的に自身で行い、クラスが見つからなかった場合に親クラスローダに処理を委譲します。
また、もう一つのWARであるweb-app.warのクラスローダは、クラスのロード処理に関与しない点に注意してください。
まずServletの視点から解説します。 クラスローダのロード処理順の概要図を以下に示します。 Servlet の視点では、JSPクラスローダはクラスのロードに関与しません。
図5.9.7.4-1
WebApp クラスローダがServlet 等のクラスをロードする際、まずWebAppクラスローダ自身でクラスのロードを試みます。 従って、WebApp クラスローダは優先順位1位になります。 WebAppクラスローダでクラスをロードできなかった場合は、親クラスローダであるEJB クラスローダにクラスのロード処理を委譲します。 EJBクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位2位となり、EJB クラスローダは優先順位11位になります。 EJB クラスローダでもクラスをロードできなかった場合はWebAppクラスローダに処理が戻りますが、WebAppクラスローダは既にロード処理を試みているために何もせず、従ってクラスがロードできなかったという結果になります。
次にJSP の視点から解説します。クラスローダのロード処理順の概要図を以下に示します。
図5.9.7.4-2
JSP クラスローダはJSP のみをロードする特別なクラスローダです。 JSPクラスローダに対してロード要求があった場合、まずJSP クラスローダ自身でJSP のロードを試みます。 従って、JSPクラスローダが優先順位1位になります。 ロード対象がJSP ではない場合、親クラスローダであるWebAppクラスローダにクラスのロード処理を委譲します。 WebAppクラスローダは親クラスローダにロード処理を委譲する前に、自身でクラスのロードを試みます。 従って、WebAppクラスローダは優先順位2位になります。 WebApp クラスローダでクラスをロードできなかった場合は、親クラスローダであるEJBクラスローダにクラスのロード処理を委譲します。 EJBクラスローダを含む上位のクラスローダは、通常どおり先に親クラスローダに処理を委譲します。 そのためブートストラップクラスローダが優先順位3位となり、EJBクラスローダは優先順位12位になります。
ここではEJB の視点からEJB クラスローダの動作を説明します。 EJBクラスローダの動作の概要図を以下に示します。
図5.9.7.5-1
EJBの視点では、WebAppクラスローダとJSPクラスローダはクラスのロード処理に関与しない点に注意してください。 EJBクラスローダを利用してクラスをロードする場合、まず親クラスローダであるEAR内部コネクタクラスローダにロード処理を委譲します。 EAR内部コネクタクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはEJBクラスローダで、優先順位10位になります。
ここではRAR の視点からEAR内部コネクタクラスローダの動作を説明します。EAR内部コネクタクラスローダの動作の概要図を以下に示します。
図5.9.7.6-1
RAR の視点では、EJBクラスローダ、WebApp クラスローダ、JSPクラスローダはクラスのロード処理に関与しない点に注意してください。 EAR内部コネクタクラスローダを利用してクラスをロードする場合、まず親クラスローダであるEAR Libクラスローダにロード処理を委譲します。 EAR Libクラスローダを含む上位のクラスローダも、通常どおり先に親クラスローダに処理を委譲します。 そのため優先順位の最も高いクラスローダはブートストラップクラスローダであり、最も優先順位の低いクラスローダはEAR内部コネクタクラスローダで、優先順位9位になります。
最も一般的な、ライブラリの共有方法です。 配置したライブラリは、WebOTX ASに配備した全てのアプリケーションで利用できます。 ただしライブラリを更新する場合、そのライブラリを利用している全てのアプリケーションが影響を受けるという点に注意する必要があります。 ライブラリの置換を行う場合は、WebOTX AS の再起動が必要になります。
ライブラリを共有せずに、個別にアプリケーションのアーカイブに含めます。 他のアプリケーションに影響を与えることなく利用するライブラリを更新できるメリットがあります。 ただしライブラリを更新するためには、アプリケーションの再配備が必要になります。 さらにアプリケーションの形式がEARの場合は、利用するライブラリをEAR 内で共通とするか、WAR 等で個別に持つかを決定する必要があります。 EJBの呼び出しで引数や戻り値として利用するクラスは、必ずEAR 内で共通のライブラリとして配置する必要があります。
アーカイブに含めずに、配備時に利用するライブラリを指定します。
Applibsクラスローダでロードされます。
使用するライブラリは、[DOMAIN]/lib/applibsに配置してください。
アーカイブを変更する必要がなく、なおかつアプリケーション間で特定のライブラリの別バージョンを使い分ける事ができる点が特徴です。
WebOTX AS Standard/Enterpriseで、プロセスグループ上で動作するアプリケーションで利用可能な方法です。 共有コンポーネントは、プロセスグループ上で動作している全てのアプリケーションで利用可能です。 共有コンポーネントの更新を行なう場合は、その共有コンポーネントを利用している全てのアプリケーションを停止すればよく、プロセスグループの再起動は必要ありません。
ユーザによって配備されたOSGiバンドルがエクスポートするクラスは、パブリックAPIクラスローダから利用することができます。 OSGiバンドルがエクスポートしているクラスは全てのアプリケーションで利用可能です。 OSGiバンドルの更新を行なう場合は、そのOSGiバンドルを利用している全てのアプリケーションを停止すればよく、ドメインの再起動は必要ありません。
配置したライブラリは、WebOTX ASに配備した全てのアプリケーションで利用できます。 拡張クラスローダでライブラリをロードした場合、WebOTX AS自体のライブラリよりも優先してロードされるため、注意が必要です。 拡張クラスローダでロードするJarライブラリを更新するためには、ドメインの再起動が必要になります。
プロセスグループ毎に環境変数CLASSPATHでクラスパスを設定可能であるため、プロセスグループ毎に共有するライブラリを分ける場合に利用できます。 設定変更後は、アプリケーショングループの再起動が必要になります。
JDBC ドライバはWebOTX 本体からアクセスできる必要があります。そのため、JDBC
ドライバは拡張クラスローダか共通クラスローダで読み込むように配置する必要があります。通常は[DOMAIN]/lib/extに配置します。
EJB のリモートメソッドのパフォーマンスを向上させるために、リモートインタフェースを介しての呼び出しがローカル呼び出しとなる場合があります。 その条件は、リモートインタフェースが共通のクラスローダでロードされることです。
この条件を満たすには、主に以下の 2 つの方法があります。
[DOMAIN]/lib に配置する。モジュールを同一の EAR に含めることで、リモートインタフェースが共通のクラスローダである EAR の EJB クラスローダでロードされます。
また、モジュールを別々に配備する場合、リモートインタフェースを含むライブラリを [DOMAIN]/lib に配置することで、リモートインタフェースが共通のクラスローダである共通クラスローダでロードされます。
クラスローダの階層については、 [5.9.1. クラスローダの階層 ] を参照してください。
なお、プロセスグループが異なる場合は、必ずリモート呼び出しになります。