本書はWebOTX実行環境を運用するための運用操作法について概要や具体的な設定項目や設定方法について記載しています。
このマニュアルはWebOTX Application Server Web Edition、Standard-J Edition、Standard Edition、Enterprise Editionを使って運用環境を構築するシステムエンジニア、日々の運用を行うオペレータを対象としています。
本書ではパス名の表記については特にOSを限定しない限りセパレータはスラッシュ’/’で統一しています。Windows環境においては’\’に置き換えてください。
インストールディレクトリやドメインルートディレクトリなど環境によって値の異なるものについては環境変数を用いて表します。
${env} または $(env)で表しています。
本書中では運用操作に用いるコマンドの詳細についての説明は省略しています。
コマンドの詳細は「運用管理コマンド」、「運用管理コマンドリファレンス」を参照してください。
WebOTX Application Serverは以下に示す8種類のアプリケーションをサポートします。サポートするアプリケーションの種類はWebOTX Application Serverのエディションにより異なります。アプリケーションは種類ごとにアーカイブの形式や拡張子が仕様で定められています。
Java EEのアプリケーションを提供する場合、1つのEARでアプリケーションを組み立てることもできますし、また個別にWARやEJB JARなどを配備してアプリケーションを組み立てても構いません。さらには各アプリケーションを異なるサーバ上に配備することでアプリケーションを分散することができます。
作成したアプリケーションをWebOTX Application Server上で実行する場合、アプリケーションに対して次に示す運用操作を行います。
WebOTX Application Serverに配備するアプリケーションは、エディションにより動作するプロセスが異なります。この章では、配備の観点からアプリケーションが動作するプロセスについての解説を行います。
アプリケーションが動作するプロセスは大きく分けて「エージェントプロセス」と「プロセスグループ」の二種類存在します。この節では、これらの違いについて解説します。
エージェントプロセスとは、WebOTX Application Serverが動作している、コアとなるプロセスのことです。Web EditionとStandard-J EditionとWebOTX SIP Application Server Standard Editionでは、配備したアプリケーションは全てエージェントプロセス上で動作します。これらのエディションでは、配備時には配備先の指定は必要ありません。
Standard EditionとEnterprise Editionでは、配備したアプリケーションはWebOTX Application Serverのコアのプロセスから分離された個別のプロセス上で動作します。このプロセスは多重化することができ、多重化したプロセス群のことを「プロセスグループ」と呼んでいます。
プロセスグループは、更に業務単位にまとめることができます。業務単位でまとめたプロセスグループ群を「アプリケーショングループ」と呼びます。
Standard EditionとEnterprise Editionで以下のアプリケーションを配備する際には、どのアプリケーショングループおよびプロセスグループに対しての配備なのかを指定する必要があります。
この節では、各ツールを使ってアプリケーショングループとプロセスグループを作成する方法を説明します。
運用管理コマンドを利用してアプリケーショングループとプロセスグループを作成する手順を説明します。なお運用管理コマンドの詳細については、運用管理コマンドリファレンスマニュアルの「create-apg」、「create-pg」を参照してください。
プロセスグループを作成する前に、それが属するアプリケーショングループを作成する必要があります。アプリケーショングループを作成するには、次に示すオペレーションcreate-apgを実行します。
otxadmin> create-apg APG名
具体例を挙げると、「myapg」という名前のアプリケーショングループを作成するには、次のようにします。
otxadmin> create-apg myapg
次にプロセスグループを作成します。プロセスグループを作成するには、次に示すオペレーションcreate-pgを実行します。
otxadmin> create-pg --apgroup 所属APG名 --kind 種別 --version [バージョン] PG名
具体例を挙げると、「javaeepg」という名前の、「myapg」というアプリケーショングループに属するJava EE用のプロセスグループを作成するには、次のようにします。
otxadmin> create-pg --apgroup myapg --kind javaee --version 7 javaeepg
別の例を挙げると、「corba」という名前の、「yourapg」というアプリケーショングループに属する、Visual C++ 2005で実装したCORBAアプリケーションのためのプロセスグループを作成するには、次のようにします。
otxadmin> create-pg --apgroup yourapg --kind vc2005 --version 7 corba
統合運用管理ツールを利用して、アプリケーショングループとプロセスグループを作成する手順を説明します。
作成したアプリケーションを配備する前に、アプリケーションを配備可能な形式にパッケージングします。アーカイブ内のディレクトリ構造やファイルの配置方法は、アプリケーションの種類ごとに定められています。この章では、アプリケーションのアーカイブの方法について解説します。
WebアプリケーションアーカイブやEJB JARなどのJava EEのアプリケーションを配備する際には、標準仕様(JSR)に準拠した形式でパッケージングを行う必要があります。パッケージングの形式が標準化されているため、ポータビリティの高いアプリケーションの作成が可能になっています。WebOTX Developerでプロジェクトを作成することにより、パッケージングを自動化することができます。
Java EEの場合とは異なり、CORBAアプリケーションにはパッケージングに関する標準仕様はありません。ここで示すCORBAのパッケージングはWebOTX Application Serverに固有の形式です。
CORBAアプリケーションをパッケージングするためには、最低限次の2つのファイルが必要です。
また、必要であれば次のファイルを準備してください。
| プロパティ | 説明 |
|---|---|
| component.initfunc | コンポーネント初期化ファイル名を指定します。 |
| component.id | コンポーネントIDを指定します。 |
| component.useshareif | 共有コンポーネントのifファイルを利用する場合trueを利用しない場合falseを指定します(既定値:false)。 |
| component.shareif | 共有コンポーネントのifファイルを利用する場合そのifファイル名を指定します。 |
| component.sharedComponentList | 利用する共有コンポーネントのアプリケーション名を記述します。複数ある場合はカンマ「,」で区切ります。 |
| sharedcomponent.allModuleUse | 共有コンポーネントを全てのアプリケーションから利用できるようにします。 |
なお、統合運用管理ツールにはパッケージングされていないCORBAアプリケーションを配備する機能がありますので、CORBAアプリケーションのパッケージングは必須ではありません。
CORBAアプリケーションの形式にはR5形式とR4形式があります。CORBAアプリケーションの形式についての詳細は、「アプリケーション開発ガイド 7.1 WebOTX AS CORBAアプリケーション」を参照してください。
コマンドラインからCORBAアプリケーションをパッケージングするにはmakecpkコマンドを利用します。makecpkの詳細なリファレンスについては運用管理コマンドリファレンスマニュアルの「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 Application Server固有のコンポーネントです。共有コンポーネントをパッケージングするためには、最低限次のファイルが必要です。
また共有コンポーネントがCORBAインタフェースを持つ場合、次のファイルも準備してください。
なお、統合運用管理ツールにはパッケージングされていない共有コンポーネントを配備する機能がありますので、共有コンポーネントのパッケージングは必須ではありません。
コマンドラインから共有コンポーネントをパッケージングするにはmakecpkコマンドを利用します。makecpkの詳細なリファレンスについては運用管理コマンドリファレンスマニュアルの「makecpk」を参照してください。
> makecpk shareap.spk module=shareap.jar
> makecpk shareap.spk module=shareap.jar if=shareap.if
配備とは、作成したアプリケーションをWebOTX Application Serverの管理下におく作業です。また再配備とは、WebOTX Application Serverの管理下にあるアプリケーションを、新しいアプリケーションで置換することです。この章では、配備および再配備について解説します。
WebOTX Application Serverがアプリケーションを管理するために、配備の際にはアプリケーションに名前をつける必要があります。アプリケーションの名前は、WebOTX Application Serverのドメイン内で一意でなければなりません。
アプリケーション名は、デフォルトではアーカイブのファイル名から拡張子を取り除いたものになります。例えば、アーカイブのファイル名が「sample.war」の場合、「sample」というアプリケーション名でWebOTX Application Serverに配備されます。また、配備をサポートする各ツールは、アプリケーション名を明示的に指定する方法を提供しています。
3.1.2 アプリケーショングループとプロセスグループで示したとおり、Standard EditionおよびEnterprise Editionでは、配備の際にアプリケーショングループとプロセスグループの指定が必要な場合があります。
再配備時には、アプリケーショングループとプロセスグループの指定があっても、それらは無視されます。新しいアプリケーションは、古いアプリケーションが配備されていたアプリケーショングループおよびプロセスグループに配備されます。
この節では、Java EEのアプリケーションの配備/再配備について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。
運用管理コマンドのdeployオペレーションを利用してJava EEのアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「deploy」を参照してください。
配備するには、Java EEのアプリケーションのアーカイブを指定してオペレーションdeployを実行します。再配備するには、更に--forceオプションを付加します。またStandard EditionおよびEnterprise Editionの場合は、配備先のアプリケーショングループ名とプロセスグループ名も必要となる場合があります。
otxadmin> deploy [--apgroup APG名] [--pgroup PG名] アーカイブ名
otxadmin> deploy [--apgroup APG名] [--pgroup PG名] --force アーカイブ名
具体例を挙げると、Web Editionにおいてアーカイブ名が「hello.war」であるWebアプリケーションを配備し、その後再配備するには、次のようにします。
otxadmin> deploy hello.war
otxadmin> deploy --force hello.war
別の例を挙げると、Enterprise Editionにおいてアーカイブ名が「sample.jar」であるEJB JARを配備し、その後再配備するには、次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。
otxadmin> deploy --apgroup apg --pgroup pg sample.jar
otxadmin> deploy --force sample.jar
運用管理コマンドのオペレーションdeploydirを利用してJava EEのアプリケーションを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「deploydir」を参照してください。
通常の配備では、アプリケーションをパッケージングし、そのアーカイブを配備します。オペレーションdeploydirを利用すると、パッケージング前のディレクトリ構造そのものを配備することができます。
配備するには、Java EEのアプリケーションが格納されているディレクトリのフルパスを指定してオペレーションdeploydirを実行します。配備対象のディレクトリのフルパスは、WebOTX Application Serverが動作しているホストにおけるフルパスです。アプリケーションをクライアントマシンからサーバマシンへ転送する機能はありません。再配備するには、更に--forceオプションを付加します。またStandard EditionおよびEnterprise Editionの場合は、配備先のアプリケーショングループ名とプロセスグループ名も必要となる場合があります。
otxadmin> deploydir [--apgroup APG名] [--pgroup PG名] ディレクトリのフルパス
otxadmin> deploydir [--apgroup APG名] [--pgroup PG名] --force ディレクトリのフルパス
具体例を挙げると、Web Editionにおいてアプリケーションのディレクトリのフルパスが「C:\hello」であるWebアプリケーションアーカイブを配備し、その後再配備するには、次のようにします。
otxadmin> deploydir C:\hello
otxadmin> deploydir --force C:\hello
別の例を挙げると、Enterprise Editionにおいて、サーバ上でのディレクトリのフルパスが「C:\sample」であるWebアプリケーションを配備し、その後再配備するには次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。
otxadmin> deploydir --apgroup apg --pgroup pg C:\sample
otxadmin> deploydir --force C:\sample
オペレーションdeploydirは、システムの開発効率を上げるために提供しています。そのため本番環境ではdeploydirは利用せずに、deployを利用してください。オペレーションdeploydirは配備するディレクトリの内容を書き換えるため、配備するディレクトリのバックアップを取ってから実行してください。
deploydirでは、JARファイルが解体された状態のディレクトリ配下の中にある配備記述子XMLファイルを直接変更できます。「オートデプロイ」の項で説明した構成情報ファイル「domain.xml」の同じ「das-config」要素内の中にある下記のダイナミックリロードに関する属性が有効になっていると、サーバは自動的に変更を検知し、アプリケーションを再ロードします。
| 属性 | 既定値 | 説明 |
|---|---|---|
| dynamic-reload-enabled | false | trueの場合、「.reload」ファイルのタイムスタンプをチェックし、更新されていればアプリケーションを読み込みなおします。 |
| dynamic-reload-poll-interval-in-seconds | 2 | ダイナミックリロードのポーリング間隔を指定します。単位は秒です。 |
「dynamic-reload-enabled」の設定を「true」に変更します。WebOTXに更新を知らせるために次の操作を行います。
モジュール (WAR、EJB JAR、アプリケーションクライアントJAR):
${INSTANCE_ROOT}/applications/j2ee-modules/<モジュール名>/.reload
統合運用管理ツールを利用して、Java EEのアプリケーションを配備する手順を説明します。
オートデプロイ機能とは、アプリケーションのアーカイブファイルを次のディレクトリにコピーすることで自動的に配備を行う機能です。
${INSTANCE_ROOT}/autodeploy
例えばWindowsでドメインdomain1を利用している場合、「hello.war」というファイル名のアプリケーションをC:\WebOTX\domains\domain1\autodeployにコピーするだけで、自動で配備を実行できます。
配備に成功した場合には、ディレクトリautodeployに、[アーカイブファイル名]_deployedというファイルが作成されます。また配備に失敗した場合は、[アーカイブファイル名]_deployFailedというファイルが作成されます。これらのファイルの存在を確認することで、配備が正常に終了したかどうかを調べることができます。
再配備を行う場合は、再配備するアーカイブをディレクトリautodeployに上書きでコピーしてください。上書きするアーカイブのタイムスタンプは、上書きされるアーカイブのタイムスタンプよりも新しいものである必要があります。古いタイムスタンプのアーカイブで上書きした場合、配備処理は実行されません。
Standard EditionおよびEnterprise Editionでは、配備時にアプリケーショングループとプロセスグループを指定する必要があります。オートデプロイ機能で配備先のアプリケーショングループとプロセスグループを指定するには、ディレクトリautodeployに、プロパティファイルautodeploy.iniを作成し、内容を適切に設定してください。プロパティファイルautodeploy.iniは、java.util.Propertiesが読み込める形式でなければいけません。プロパティファイルautodeploy.iniはドメイン起動時に読み込まれ、その後変更するたびに再読み込みされます。プロパティファイルautodeploy.iniに記述するプロパティの詳細を以下に示します。
| キー | 値の説明 |
|---|---|
| apg | 登録先アプリケーショングループ名。 |
| pg | 登録先プロセスグループ名。 |
オートデプロイ機能の各種設定は、${INSTANCE_ROOT}/config/domain.xmlに記述してあります。このdomain.xmlファイルの要素<das-config>の属性の値を編集することで、設定を変更することができます。domain.xmlの編集はドメインを停止してから行ってください。属性の詳細は以下の通りです。
| 属性 | 既定値 | 説明 |
|---|---|---|
| autodeploy-enabled | false | trueの場合、オートデプロイ機能が有効になります。falseの場合は、オートデプロイ機能は無効になり、動作しません。 |
| autodeploy-poll-interval-in-seconds | 2 | オートデプロイのためのディレクトリを監視する間隔(ポーリング間隔)です。単位は秒です。 |
| autodeploy-dir | autodeploy | オートデプロイのためのディレクトリを設定します。このディレクトリは、絶対パスかドメインのディレクトリからの相対パスです。 |
| autodeploy-verifier-enabled | false | trueの場合、配備を実行する前に、配備記述子の妥当性検証(ベリファイ)を行います。妥当性検証に失敗した場合は、配備は実行しません。falseの場合は、妥当性検証は実行しません。 [注意] この機能はサポートしていません。既定値(false)から変更しないでください。trueに設定するとアプリケーションに問題が無くてもオートデプロイに失敗します。WebOTX SIP Application Server V8.13ではtrueに設定してもオートデプロイ前の妥当性検証は実行されません。 |
| autodeploy-jsp-precompilation-enabled | false | trueの場合、配備中にJSPをコンパイルします。falseの場合、JSPのコンパイルは行いません。この場合はJSPの初回アクセス時に動的にコンパイルを実行します。 |
ここではCORBAアプリケーションの配備について説明します。Standard EditionおよびEnterprise Editionが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オペレーションを実行する際には、配備先のアプリケーショングループ名とプロセスグループ名も指定する必要があります。再配備するには、更に--forceオプションを付加します。
otxadmin> deploy --apgroup APG名 --pgroup PG名 アーカイブ名
otxadmin> deploy --apgroup APG名 --pgroup PG名 --force アーカイブ名
例えば、アーカイブ名が「corba.cpk」であるCORBAアプリケーションを配備し、その後再配備するには、次のようにします。配備先のアプリケーショングループ名をapgで、プロセスグループ名をpgとしています。
otxadmin> deploy --apgroup apg --pgroup pg corba.cpk
otxadmin> deploy --apgroup apg --pgroup pg --force corba.cpk
統合運用管理ツールを利用して、CORBAアプリケーションを配備する手順を説明します。
ここでは、共有コンポーネントの配備について説明します。Standard EditionおよびEnterprise Editionが共有コンポーネントをサポートしています。
運用管理コマンドを利用して共有コンポーネントを配備/再配備する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「deploy」を参照してください。
配備する場合は、共有コンポーネントのアーカイブを指定してdeployオペレーションを実行します。再配備するには、更に--forceオプションを付加します。
otxadmin> deploy アーカイブ名
otxadmin> deploy --force アーカイブ名
具体例を挙げると、アーカイブ名が「shared.spk」である共有コンポーネントを配備し、その後再配備するには、次のようにします。
otxadmin> deploy shared.spk
otxadmin> deploy --force shared.spk
統合運用管理ツールを利用して、共有コンポーネントを配備する手順を説明します。
配備解除とは、WebOTX Application Serverの管理下からアプリケーションを除外することです。この章では配備解除について解説します。
この節では、Java EEのアプリケーションの配備解除について説明します。特に断りがない限り、説明はJava EEのアプリケーションの種類すべてに共通しているものとします。
運用管理コマンドを利用してJava EEのアプリケーションを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
具体例を挙げると、アプリケーション名が「hello」であるアプリケーションを配備解除するには、次のようにします。
otxadmin> undeploy hello
統合運用管理ツールを利用して、Java EEのアプリケーションを配備解除する手順を説明します。
オートデプロイ機能での配備で利用した以下のディレクトリから、該当アーカイブを削除することで、自動的に配備解除が開始します。
${INSTANCE_ROOT}/autodeploy
ここではCORBAアプリケーションの配備解除について説明します。
CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、配備解除を行うための条件が異なります。アプリケーショングループが起動状態で配備解除を行うことを、動的配備解除と呼びます。アプリケーショングループが停止状態で配備解除を行うことを、静的配備解除と呼びます。
R4形式のCORBAアプリケーションの場合、静的配備解除のみをサポートします。配備解除を行うにはそのCORBAアプリケーションが属しているアプリケーショングループを停止してください。アプリケーショングループが起動している場合は配備解除できません。
R5形式のCORBAアプリケーションの場合は、動的配備解除も静的配備解除もサポートしています。ただし、動的配備解除を行う場合は以下の条件を満たす必要があります。
バージョン5のプロセスグループは動的配備解除をサポートしていませんので、アプリケーショングループを停止して静的配備解除を行ってください。またCORBAアプリケーションが停止状態でない場合は、配備解除ができません。CORBAアプリケーションを停止状態にすることで、配備解除を行うことができます。ただし停止状態にする際、現在実行中のオペレーションがエラーになる可能性があります。安全な停止方法については7.2.3 コマンドを利用した開始と停止を参照してください。
運用管理コマンドを利用してCORBAアプリケーションを配備解除する方法について説明します。CORBAアプリケーションを配備解除するための条件については6.2.1 動的配備解除と静的配備解除を参照してください。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
例えば、アプリケーション名が「corba」であるCORBAアプリケーションを配備解除するには、次のようにします。
otxadmin> undeploy corba
ここでは統合運用管理ツールを利用してCORBAアプリケーションを配備解除する手順を説明します。CORBAアプリケーションを配備解除するための条件については6.2.1 動的配備解除と静的配備解除を参照してください。
ここでは、共有コンポーネントの配備解除について説明します。
運用管理コマンドを利用して共有コンポーネントを配備解除する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「undeploy」を参照ください。
配備解除するには、アプリケーション名を指定してundeployオペレーションを実行します。
otxadmin> undeploy アプリケーション名
例えば、アプリケーション名が「shared」である共有コンポーネントを配備解除するには、次のようにします。
otxadmin> undeploy shared
ここでは、統合運用管理ツールを利用して共有コンポーネントを配備解除する手順について説明します。
アプリケーションが開始した状態とは、配備されたアプリケーションが動作しており、クライアントからの要求を受け付けることができる状態です。また、アプリケーションが停止した状態とは、アプリケーションが動作していない状態のことで、クライアントからの要求は受け付けることができませんが、アプリケーションは依然としてWebOTXの管理下にあります。この章ではアプリケーションの開始と停止について解説します。
この節では、Java EEのアプリケーションの開始と停止について説明します。特に断りがない限り、説明はJava EEアプリケーションの種類すべてに共通しているものとします。
運用管理コマンドを利用してJava EEのアプリケーションを開始/停止する方法について説明します。なお、運用管理コマンドの詳細については運用管理コマンドリファレンスマニュアルの「enable」、「disable」を参照してください。
アプリケーションを開始するにはオペレーションenableを、停止するにはオペレーションdisableを実行します。
otxadmin> enable アプリケーション名
otxadmin> disable アプリケーション名
具体例を挙げると、アプリケーション名が「myapp」であるアプリケーションを開始し、その後停止するには、次のようにします。
otxadmin> enable myapp
otxadmin> disable myapp
ここでは統合運用管理ツールを利用して、Java EEアプリケーションを開始/停止する手順を説明します。
まず、アプリケーションの開始から説明します。
次に、アプリケーションの停止の手順について説明します。
ここでは、CORBAアプリケーションの開始と停止について説明します。
CORBAアプリケーションの形式がR4形式なのかR5形式なのかによって、開始/停止の方法が異なります。
R4形式のCORBAアプリケーションの場合、アプリケーション単位の開始/停止はできません。プロセスグループの開始/停止、あるいはアプリケーショングループの開始/停止により、該当CORBAアプリケーションを開始/停止してください。
R5形式のCORBAアプリケーションの場合は、アプリケーション単位の開始/停止をサポートしています。ただし、アプリケーション単位の開始/停止を行う場合は以下の条件を満たす必要があります。
ただし、アプリケーション単位の開始が成功するためには、そのアプリケーションが属しているプロセスグループが開始している必要があります。
バージョン5のプロセスグループはアプリケーション単位の開始/停止をサポートしていませんので、プロセスグループの開始/停止、あるいはアプリケーショングループの開始/停止により、該当CORBAアプリケーションを開始/停止してください。
使用中のCORBAアプリケーションを停止してしまうと、以後はそのCORBAアプリケーションに対する呼び出しは失敗します。安全にCORBAアプリケーションの停止を行うためには、そのCORBAアプリケーションがクライアントから利用されていないか確認する必要があります。CORBAアプリケーションの利用状況ついては、以下の情報が参考になります。
モジュールアイドル時間が十分に長い場合、そのアプリケーションは利用されていないと判断できます。モジュールアイドル時間が-1の時は、オペレーションが実行中であることを示しています。。
統合運用管理ツールを利用する場合、モジュールアイドル時間とモジュールアクティブオブジェクト数は以下の場所で確認できます。
また、運用管理コマンドを利用する場合は、以下のようにします。
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
アプリケーション単位の開始/停止が可能な場合について解説します。アプリケーショングループとプロセスグループの開始/停止の手順については「運用編（TPモニタの運用操作）」を参照してください。
まずCORBAアプリケーションを開始する手順を示します。
次に、CORBAアプリケーションを停止する手順について解説します。
ライフサイクルモジュールについて説明します。
ライフサイクルモジュールとは、WebOTX Application Serverの起動・停止のライフサイクルの状態に合わせ実行されるJavaクラスまたはモジュールであり、ユーザが作成した任意のクラスまたはモジュールをライフサイクルモジュールとすることが可能です。
WebOTX Application Serverではライフサイクルの状態管理のために以下の状態を定義しています。ライフサイクルモジュールはこの状態により管理され、WebOTX Application Serverのライフサイクルに同期した処理を実行します。
| 状態 | 説明 |
|---|---|
| INIT | 初期化処理中であることを表します |
| STARTUP | 起動処理中であることを表します |
| READY | サービス開始処理中であることを表します |
| SHUTDOWN | 停止処理中であることを表します |
| TERMINATION | リソース開放処理中であることを表します |
ライフサイクルモジュールが複数登録されている場合は、各ライフサイクルモジュールは並列に処理されます。たとえば、WebOTX Application Serverが初期化の状態であるとき、全てのライフサイクルモジュールの状態はINITであり、全てのライクサイクルモジュールのINITイベントによる処理が終了するまで、次の状態には移行しません。
ライフサイクルモジュールを登録する場合の流れについて説明します。
登録するコンポーネントとLifecycleListener実装クラスを作成します。登録に必要なファイルは以下のとおりです。
ライフサイクルモジュールをWebOTX Application Serverに登録します。登録は統合運用管理ツールおよび運用管理コマンドで行なうことができます。
ライフサイクルモジュールの設定を変更します。この設定はライフサイクルモジュールの登録時にも行うことができます。登録後に設定の変更が必要な場合に行ってください。変更は統合運用管理ツールおよび運用管理コマンドで行なうことができます。
WebOTX Application Serverへのライフサイクルモジュールの登録にはWebOTX Application Serverとライフサイクルモジュールのインタフェースとして、LifecycleListenerインタフェースを実装したクラスを作成する必要があります。
LifecycleListenerインタフェースはPublicメソッドとしてhandleEventを持ちます。WebOTX Application Serverはこのメソッドを呼び出し、LifecycleListener実装クラスに状態情報を保持したLifecycleEventクラスのオブジェクトを渡します。
LifecycleEventクラスは状態情報として以下のpublicかつstaticなフィールドを持ちます。
| フィールド名 | 説明 |
|---|---|
| INIT_EVENT | ライフサイクルモジュールの初期化処理中であることを表します |
| STARTUP_EVENT | ライフサイクルモジュールの起動処理中であることを表します |
| READY_EVENT | ライフサイクルモジュールのサービス開始処理中であることを表します |
| SHUTDOWN_EVENT | ライフサイクルモジュールの停止処理中であることを表します |
| TERMINATION_EVENT | ライフサイクルモジュールのリソース開放処理中であることを表します |
LifecycleListener実装クラスでは、この状態情報に応じた処理を実装する必要があります。
LifecycleListener実装クラスの実装方法については「APIリファレンスマニュアル」の「6.ライフサイクル・リスナ」を参照してください。
統合運用管理ツールよりライフサイクルモジュールの登録・登録削除および一覧を取得する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。
| LifecycleListener実装クラス名 | sample.SampleLifecycleModule |
|---|---|
| モジュールとLifecycleListener実装クラスを含むjarファイル名 | sample.jar |
| jarファイル配置位置 | Cドライブ直下 |
| ライフサイクルモジュールの登録名 | Sample |
| アプリケーショングループ名 | apg |
| プロセスグループ名 | pg |
以下の手順で登録します。なお、ここではライフサイクルモジュール名に加え、クラスパスと必須入力項目であるクラス名のみ指定しています。必要に応じて他の設定項目を入力して実行してください。
Standard EditionおよびEnterprise Editionにおいて、ライフサイクルモジュールをプロセスグループ上で動作させる場合は、追加で以下の作業も必要になります。
ドメインからライフサイクルモジュールを登録削除する手順を示します。Standard Edition またはEnterprise Editionで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからライフサイクルモジュールを登録削除する必要がある点に注意してください。
次に、プロセスグループからライフサイクルモジュールを登録削除する手順を示します。
まず、ドメインに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。
次に、プロセスグループに登録されたライフサイクルモジュールの一覧を取得する手順を以下に示します。こちらはStandard EditionおよびEnterprise Editionでサポートしています。
運用管理コマンドよりライフサイクルモジュールコンポーネントの登録および登録削除する方法について説明します。なお、ここでは以下の条件でライフサイクルモジュールの登録を行っています。
| LifecycleListener実装クラス名 | sample.SampleLifecycleModule |
|---|---|
| モジュールとLifecycleListener実装クラスを含むjarファイル名 | sample.jar |
| jarファイル配置位置 | Cドライブ直下 |
| ライフサイクルモジュールの登録名 | Sample |
| アプリケーショングループ名 | apg |
| プロセスグループ名 | pg |
ライフサイクルモジュールをドメインに登録するには、登録するコンポーネントとライフサイクルモジュールの初期設定情報を指定して、create-lifecycle-moduleコマンドを実行します。なお、ここではコマンドのオプションとしてclasspathと必須オプションであるclassnameのみ指定しています。必要に応じて他のオプションを指定して実行してください。
otxadmin> create-lifecycle-module -classname sample.SampleLifecycleModuleClass -classpath C:/Sample.jar Sample
Standard EditionおよびEnterprise Editionにおいて、ライフサイクルモジュールをプロセスグループに登録するには、登録するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を指定して、add-pg-lifecycle-moduleコマンドを実行します。
otxadmin> add-pg-lifecycle-module -apgroup apg pgroup pg Sample
ライフサイクルモジュールをドメインから登録削除するには、登録削除するライフサイクルモジュール名を指定して、delete-lifecycle-moduleコマンドを実行します。ただし、Standard Edition またはEnterprise Editionをお使いで、登録削除対象のライフサイクルモジュールをプロセスグループへも登録している場合は、先にプロセスグループからの登録削除を行う必要があります。
otxadmin> delete-lifecycle-module Sample
Standard EditionおよびEnterprise Editionにおいて、ライフサイクルモジュールをプロセスグループから登録削除するには、登録削除するライフサイクルモジュール名、アプリケーショングループ名、プロセスグループ名を指定して、remove-pg-lifecycle-moduleを実行します。
otxadmin> remove-pg-lifecycle-module -apgroup apg -pgroup pg Sample
ドメインに登録されたライフサイクルモジュールの一覧を取得するには、list-lifecycle-modulesコマンドをオプション指定なしで実行します。
otxadmin> list-lifecycle-modules
Standard EditionおよびEnterprise Editionにおいて、プロセスグループに登録されたライフサイクルモジュールの一覧を取得するには、オプションで一覧を取得したいプロセスグループのアプリケーショングループ名、プロセスグループ名を指定し、list-lifecycle-modulesコマンドを実行します。
otxadmin> list-lifecycle-modules -apgroup apg -pgroup pg
ライフサイクルモジュールはJMX仕様に基づき、WebOTX Application Server内で管理対象オブジェクト(Managed Object: MO)として登録され、管理されます。
登録されたライフサイクルモジュールは統合運用管理ツールまたは運用管理コマンドからその設定を変更することが可能です。ただし設定の変更を反映させるには、そのライフサイクルモジュールの登録先(ドメイン又はプロセスグループ)を再起動する必要があります。
ライフサイクルモジュールの設定項目についての一覧を以下に示します。なお、MOの詳細については運用編「MO定義リファレンス」を参照してください。また、設定方法については運用編「統合運用管理ツール」、運用編「運用管理コマンド」を参照してください。
| 属性名 | 値 | 統合運用管理ツールでの表記 | Dotted Name | 説明 |
|---|---|---|---|---|
| name | 文字列 | ライフサイクルモジュール名 | server.applications.lifecycle-module.ライフサイクルモジュール名.name | ライフサイクルモジュール名です。ここで指定した名前でライフサイクルモジュールをドメインに登録します。ただし、文字列にスペースを混入させることはできません。 |
| class-name | 文字列 | ライフサイクルモジュールクラス名 | server.applications.lifecycle-module.ライフサイクルモジュール名.class-name | LifecycelLisner実装クラスのクラス名を、パッケージ名を含めて指定します。 |
| 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を取得・設定するにはツール上のライフサイクルモジュールの右クリックから「プロパティ一覧の取得」または「プロパティの設定」を実行してください。
なお、コマンドから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 Application Serverでは複数プロセスグループ上でライフサイクルモジュールの機能を提供するため、各プロセスグループ上からはドメインに登録されたライフサイクルモジュールの情報を参照し、設定情報を取得しています。したがって、ドメインに登録された情報への参照の有効・無効を設定することで、プロセスグループごとにライフサイクルモジュールの有効・無効を設定することができます。
以下の図はドメイン上のライフサイクルモジュールの情報を各プロセスグループから参照する場合のイメージです。ただし、ここでは各プロセスグループを表すのにアプリケーショングループ名とプロセスグループ名を-(ハイフン)でつないだサーバ名で表しています。
参照の有効・無効設定を行うには、運用管理コマンドから以下の手順で変更します。
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.iniファイルで以下の指定をします。
| methodid=all | 全てのリモートメソッドに対して割り当てる |
|---|---|
| methodid=limit | ビジネスメソッドのみ割り当てる (既定値) |
| methodid=none | 割り当てない |
WebOTXサーバのクラスローダについて理解しておくことは、開発者や運用者がアプリケーション共通で使うJARアーカイブやアプリケーション・モジュールのためのリソース・ファイルを、どの位置に配置すべきかを決める際に重要な助けとなります。
Java VMでは、クラスローダはJavaアプリケーションの起動の時や実行中に、動的にクラス間の依存を解決するために必要な特定のJavaクラスファイルをロードします。
この章では、Java EEアプリケーションが動作するときのクラスローダについて説明します。
WebOTX上でJava EEアプリケーションが動作する時のクラスローダ構造について説明します。
下の図はクラスローダの親子関係を表しています。矢印は親子関係を表します。
各クラスローダの説明を以下に示します。
システムクラスローダより下のクラスローダはWebOTXが提供するクラスローダとなります。
| クラスローダ | 説明 |
|---|---|
| ブートストラップクラスローダ | JDKのクラスとドメインのlib/ext下に置かれたjarまたはzipファイルをロードするクラスローダです。 |
| システムクラスローダ | WebOTXのシステムライブラリ、classpath-prefix, server-classpath, classpath-suffixで指定されたライブラリをロードするクラスローダです。 |
| ドメイン共通クラスローダ | ドメインのlibディレクトリに置かれたjarまたはzipファイルとlib/classes下に置かれたクラスファイルをロードするクラスローダです。 |
| 共有コンポーネントクラスローダ | ドメインに配備された共有コンポーネントに含まれるクラスをロードするクラスローダです。Standard/Enterprise EditionのEJB, CORBA Javaコンポーネントでのみ使用可能です。インストール時にWebコンテナの動作モードをマルチプロセスモードで選択した場合はWebモジュールからも使用できます。共有コンポーネントを配備解除することにより動的にクラスをアンロードすることが可能です。 |
| コネクタクラスローダ | ドメインに配備されたリソースアダプタに含まれるクラスをロードするクラスローダです。 |
| EJBクラスローダ | Java EEアプリケーションまたはEJBモジュールに含まれるクラスをロードするクラスローダです。 |
| Webコンテナクラスローダ | Java EEアプリケーションまたはWebモジュールに含まれるクラスをロードするクラスローダ)。 |
| JSPエンジンクラスローダ | コンパイルされたJSPのクラスをロードするクラスローダです。 |
Webアプリケーションでは、クラスローダの親子関係ににより、つぎのような動作をします。上位のクラスローダでロードされたクラスからは下位のクラスローダでロードされたクラスは参照することができません。逆に、下位のクラスローダでロードされたクラスからは、上位のクラスローダでロードされたクラスは参照することができます。
J2SEでは一般的にクラスローダはロードする際に委譲モデルを使用します。委譲モデルでは、クラスローダが個々のクラスやリソースのロード要求を受けた場合、まずは要求を親のクラスローダに委譲し、親のクラスローダが要求されたクラスやリソースを見つけられなかった場合だけ自分のリポジトリから検索するように動作します。
WebOTXの提供するクラスローダも基本的には委譲モデルで動作します。例外として、Webコンテナクラスローダは、Servletのバージョンが2.3以前の場合、デフォルトでは委譲モデルを採用しません。これはServlet仕様バージョン 2.3の9.6節での勧告に基づくものです（ただしJREの基本クラスについてはオーバライドできません）。
委譲モデルを使用するかどうかはWARファイルに含まれるnec-web.xmlで定義されているclass-loader要素のdelegateの値で設定することができます。 この設定を変更することで、クラスをロードする際の優先順位が変わります。同じ名前のライブラリがある場合、優先順位が高いほうのクラスローダによりロードされます。
同じ名前のライブラリがある場合、Webアプリケーション側(WEB-INF/lib)よりも、WebOTXのシステムライブリやドメインのlibディレクトリなどに配置したライブラリを優先して読み込みます。 WebOTXに含まれるライブラリと重なっている場合、delegate=trueに設定することで問題を回避することができます。
同じ名前のライブラリがある場合、Webアプリケーション側(WEB-INF/lib)に配置したライブラリを優先して読み込みます。
ドメインに配備された複数のアプリケーションで共通に参照されるクラスの配置方法について説明します。
各アプリケーションをロードするクラスローダは配備されたEARファイル、またはモジュール単位で別々となります。つまりあるアプリケーションのアーカイブファイルに含まれるクラスから他のアプリケーションに含まれるクラス、リソースを参照することはできません。
各種ユーティリティ・クラスや複数のアプリケーションから共通に使用したいJavaライブラリを配置するには以下の方法があります。
システムクラスローダを使用する場合は、コンテナがJava VMを起動するときのクラスパスで参照するJavaライブラリの配置場所を指定します。
server.java-config.classpath-suffix属性の設定で行ないます。classpath-prefixでも設定可能ですが、WebOTXの起動で必要なクラスパスよりも前に参照されるため、.classpath-suffixでの設定を推奨します。
アプリケーションが配備されたプロセスグループの環境変数CLASSPATHの設定で行ないます
変更した場合はプロセスを再起動する必要があります。
共通に参照するクラス、リソースがjarまたはzipファイルにアーカイブされている場合はそのファイルを${INSTANCE_ROOT}/libディレクトリに配置します。アーカイブされていない場合はそのファイルを${INSTANCE_ROOT}/classesディレクトリにそのクラス、リソースのパッケージ名をディレクトリ構造に反映させた形で配置します。変更した場合はプロセスを再起動する必要があります。
共有コンポーネントに含まれるクラスはプロセスグループ上で動作するEJB, Web,CORBAアプリケーションから参照することができます。各アプリケーションに対して参照する共有コンポーネントを設定する必要があります。共有コンポーネントの追加、変更を行なう場合、参照する全てのEJB, Web, CORBA Javaアプリケーションの閉塞を行なった後、共有コンポーネントを配備すればよく、プロセスを再起動する必要はありません。
共通に参照するクラス、リソースのjarまたはzipアーカイブを${INSTANCE_ROOT}/lib/extディレクトリに配置します。ここに配置されたクラスは、ブートストラップクラスを拡張するもので、ブートストラップクラスローダと同等のクラスローダでロードされます。このためドメイン内の全てのクラスを参照することができます。ただしWebOTXのシステムライブラリより先にクラス検索が行なわれるため、例えばJava EEのAPIクラスなどのWebOTXのシステムライブラリに含まれるクラスを含むライブラリを配置すると、クラスロードの依存関係が変わり、エージェントが起動できなくなる可能性があります。変更した場合はプロセスを再起動する必要があります。
これはドメインに配備された全アプリケーションでなく、特定のアプリケーションからライブラリを参照するための方法です。参照する全てのアプリケーションでこの操作を行なう必要があります。
参照するクラスが別のアプリケーションである場合、参照先アプリケーションが配備されるときに生成されるクライアントJarを参照元アプリケーションに含めます。単なるユーティリティである場合はそれをjarファイルにアーカイブしてアプリケーションに含めます。
参照元がEJBアプリケーションである場合、そのEJB JARファイルのマニフェストファイルのClass-Pathエントリで参照先のjarファイルをEJB JARファイルからの相対パスで記述します。
参照元がWebアプリケーションである場合、EJBと同様にマニフェストファイルのClass-Pathエントリで指定するか、WEB-INF/lib下にjarファイルを格納します。
変更した場合はアプリケーションの再配備が必要となります。プロセスを再起動する必要はありません。
Java EEアプリケーションの構成と使用するWebOTXのエディションごとの共通クラスの可能な配置方法を以下に示します。
| アプリケーションの構成 | Web Edition | Standard-J Edition | Standard/Enterprise Edition |
|---|---|---|---|
| Webアプリケーションのみ |
|
|
|
| EJBアプリケーションのみ | - |
|
|
| Web + EJBアプリケーション | - |
|
|
共有コンポーネントはStandard/Enterprise EdtionのEJB, CORBA Javaアプリケーションのみから参照可能であるため、Webアプリケーションからも参照したい場合は別の方法で配置する必要があります。ただしWebコンテナの動作モードをマルチプロセスモードでインストールした場合はWebアプリケーションからも参照可能です。
システムクラスローダと共通クラスローダはどちらの方法を採用しても動作にはあまり違いがありません。共通クラスローダの方がファイルを配置するだけで手順が簡単ですのでこちらの方を推奨します。
Java拡張パッケージ機能は全てのケースにおいて有効ですが、ブートストラップクラスへの追加はWebOTXの動作に影響する可能性があるため、必要最小限のものだけを配置することを強く推奨します。
JDBCドライバのクラスは通常、共通で参照されるライブラリとして配置しますが、他のライブラリとは異なる点があります。
JDKのjava.sql.DriverManagerクラスはドライバをロードするときに、呼び出し元のクラスローダでJDBCドライバをロードしようとします。WebOTXのJDBCデータソースを使用する場合、呼び出し元はWebOTXシステムクラスに含まれるJDBCデータソースの実装クラスとなります。
つまりWebOTXのJDBCデータソースを使用してJDBCアクセスする場合、WebOTXシステムクラスをロードしたクラスローダでJDBCドライバがロードされます。このため、JDBCドライバはシステムクラスローダまたはJava拡張パッケージとして配置する必要があります。
参照するライブラリは正しく配置されているにもかかわらず、アプリケーションのロード、または実行時に共通クラスのロード、または実行を行なったときにjava.lang.NoClassDefFoundErrorが発生することがあります。これは通常、共通ライブラリからアプリケーション内のクラスを参照していることが原因です。
共通クラスはアプリケーションをロードするクラスローダよりも親のクラスローダとなります。親のクラスローダでロードしたクラスから、子のクラスローダでロードしたクラスを参照することはできません。
よくある例としては、共通クラスで定義したメソッドにインタフェースや抽象クラスを引数として渡している場合、その実装クラスがアプリケーション側にしか存在しないとメソッド実行時にエラーが発生します。この場合は実装クラスも共通クラスローダでロードする必要があります。
通常アプリケーションで必要なクラス、例えばWebアプリケーションにおけるサーブレット実装クラス、EJBアプリケーションにおけるホーム、リモートインタフェース、EJB実装クラスなどはアプリケーションのアーカイブファイル内に配置され、アプリケーション固有のクラスローダでロードされます。これらクラスを共通クラスに配置し、配備するファイルには配備記述子だけを含めて配備することも可能です。例えば複数のEJBアプリケーションで同じインタフェースクラスを使用する場合、インタフェースクラスのみをjarにアーカイブして共通クラスとして配置し、各アプリケーションにはインタフェースファイルを含めずに配備することでインタフェースクラスを一元管理することができます。ただし、インタフェースを変更した場合は全アプリケーションに影響があり、多くの場合ドメイン再起動が必要となります。