この章では、N1 Service Provisioning System software コンポーネントの XML スキーマについて説明します。
プロビジョニングソフトウェア の XML スキーマアーキテクチャーについての概要は、第 1 章「N1 Service Provisioning System Software XML スキーマの概要」を参照してください。
以下の表の「構成可能」列は、個々の属性に置換変数参照が「:[varName]」という形式で含まれるかどうかを示します。 変数置換の詳細は、第 16 章を参照してください。
コンポーネント全体は、<component> 要素で囲まれます。 1 つのコンポーネントのバージョンはすべて、同じ名前とパスを持つ必要があります。 この要素の構成可能属性は、component 置換変数を参照できます。
名前 |
型 |
必須 |
構成可能 |
description |
---|---|---|---|---|
xmlns |
文字列 |
はい |
不可 |
必要な値: http://www.sun.com/schema/SPS |
xmlns:xsi |
文字列 |
はい |
不可 |
必要な値: http://www.w3.org/2001/ XML Schema-instance |
xsi:schema Location |
文字列 |
いいえ |
不可 |
推奨値: http://www.sun.com/schema/SPS component.xsd |
access |
次の 1 つ: PUBLIC PATH |
いいえ |
不可 |
当該コンポーネントのアクセスモード (詳細は下記) デフォルトは PUBLIC |
modifier |
modifierEnum |
いいえ |
不可 |
当該コンポーネントの修飾子 (詳細は下記) |
name |
entityName |
はい |
不可 |
コンポーネントの名前 |
path |
pathName |
いいえ |
不可 |
コンポーネントの絶対パス。 指定しないと、デフォルトでルートパス「/」が使用される |
description |
文字列 |
いいえ |
不可 |
コンポーネントの説明 |
label |
文字列 |
いいえ |
不可 |
コンポーネントの概要 |
software Vendor |
文字列 |
いいえ |
不可 |
当該コンポーネントでモデル化されたソフトウェアアプリケーションのベンダー |
author |
文字列 |
いいえ |
不可 |
当該コンポーネントの作成者 |
version |
schemaVersion |
はい |
不可 |
使用されているコンポーネントスキーマのバージョン。 現在許可されている値は 4.0 のみ |
platform |
文字列 |
いいえ |
不可 |
当該コンポーネントのインストール先として有効な物理的対象と見なされるホストを含むホストセットの名前 (詳細は下記) |
limitToHostSet |
文字列 |
いいえ |
不可 |
当該コンポーネントの有効な対象と見なされるホストを含むホストセットの名前 (詳細は下記) |
installPath |
文字列 |
はい 1 |
可能 |
当該コンポーネントのインストール時に使用されるパス。 単純コンポーネントの場合、この値はリソースをインストールするルートディレクトリにも相当する。 注: 当該コンポーネントのインスタンスがインストールされる際に、パスは共通書式で保存される |
1 非派生コンポーネントにしか認められません。
<component> 要素の「access」属性は、コンポーネントのアクセス可能性を指定するもので、値は PATH と PUBLIC に限定されます。 デフォルトは PUBLIC です。
access が PATH の場合、そのコンポーネントを参照できるのはそのコンポーネントと同じパス内に存在するほかのコンポーネントだけです。 クライアントが当該コンポーネントを直接インストールすることはできず、入れ子になった参照を使用してほかのコンポーネントに当該コンポーネントを含めるしかありません。 access 属性が PUBLIC の場合、このような制限は適用されません。
<component> 要素の「modifier」属性は、コンポーネントの優先指定要件を指定します。
ABSTRACT の場合、コンポーネントはインストールできず、 ほかのコンポーネントを拡張するためのベースコンポーネントとしてのみ機能します。 抽象的な子要素を宣言できるのは抽象コンポーネントだけです。
FINAL の場合、コンポーネントをほかのコンポーネントで拡張することはできません。
省略された場合は、コンポーネントの拡張とインストールが行えます。
<component> 要素の「platform」属性は、当該コンポーネントのインストール先として有効な物理的対象と見なされるホストを含むホストセットの名前を指定します。 この属性を指定しないと、サポートされているプラットフォーム上に存在する RA を含むすべてのホストが有効な物理的対象と見なされます。 この属性を指定する場合は、当該コンポーネントをインストールするプランの物理的対象が、指定されたホストセットに含まれるホストのサブセットでなければなりません。 指定されたホストセットに含まれないホストが物理的対象に存在する場合、これはプラン実行時エラーです。 既存のホストセットに対応しない名前を指定するのも、プラン実行時エラーです。 ここで説明しているプラン実行時エラーは、プリフライトエラーとして報告されます。
<component> 要素の「limitToHostSet」属性は、このプランの有効な対象と見なされるホストを含むホストセットの名前を指定します。 この属性を指定しないと、すべてのホストが有効な対象と見なされます。 この属性を指定する場合、クライアントが指定する対象は、指定されたホストセットに含まれるホストのサブセットでなければなりません。 指定されたホストセットに含まれないホストが対象内に存在する場合、プラン実行時エラーです。 既存のホストセットに対応しない名前を指定するのも、プラン実行時エラーです。 ここで説明するプラン実行時エラーは、プリフライトエラーとして報告されます。
platform 属性と limitToHostSet 属性では、2 つの大きな違いがあります。 1 つ目の違いは、platform は事前定義されたプラットフォームホストセットの 1 つを指定するのに対し、limitToHostSet はユーザー定義のホストセットを指定することです。 したがって、カスタムホストセットに基づいてインストールを制限することを望む場合、クライアントは「imitToHostSet」を使用する必要があります。 2 つ目の違いは、コンポーネントの対象を仮想ホストにした場合、limitToHostSet のテストはその仮想ホストに照らして行われるのに対し、platform のテストはその仮想ホストのルート物理ホストに照らして行われることです。 したがって、limitToHostSet を設定し platform は設定しないという方法をとることで、異なる物理プラットフォーム上に存在する特定の仮想ホスト (複数) にコンポーネントをインストールできます (WebLogic アプリケーションはこの方法を採用)。 platform を設定し limitToHostSet は設定しないようにすると、指定するプラットフォームを持つ物理ホストをルート (親) とする任意のホスト上にコンポーネントをインストールできます。 platform、limitToHostSet とも設定すると、両方の範囲を制約できます。
installPath と limitToHostSet を除き、component 属性は継承されません。
installPath 属性は継承され、派生コンポーネントにより無効にはなりません。 しかし、ベースコンポーネントはコンポーネント変数を使用してその値を指定でき、これらの変数の値を無効にできます。
limitToHostSet 属性も継承され、ベースコンポーネントが limitToHostSet を指定しなかった場合だけ派生コンポーネントで無効にできます。 limitToHostSet 値は、クライアントによって管理される可変のエンティティを指定します。このため、ホストセットの関係をプラットフォームと同じように論じることはできません。
platform 属性は継承されません。 しかし、派生コンポーネントの platform 値はベースコンポーネントの platform 値同様一般的ではありません。 派生コンポーネントで platform を指定しない場合は、ベースコンポーネントでも指定しないようにするか、あるいは「any」として指定する必要があります。
名前 |
数 |
説明 |
---|---|---|
extends |
0 または 1 |
当該コンポーネントの派生元であるベースコンポーネント |
varList |
0 または 1 |
当該コンポーネントが使用する置換変数と、当該コンポーネントに含まれる構成リソースの一覧 |
resourceRef |
0 または 1 |
当該単純コンポーネントによって管理されるリソース。 <componentRefList> との併用は不可 |
component RefList |
0 または 1 |
当該複合コンポーネントによって参照されるコンポーネントの一覧。 <resourceRef> との併用は不可 |
installList |
0 または 1 1 |
インストール手順ブロックの一覧。各手順ブロックは、当該コンポーネントをインストールするさまざまな方法を定義する |
uninstallList |
0 または 1 1 |
アンインストール手順ブロックのリスト。各手順ブロックは、当該コンポーネントをアンインストールするさまざまな方法を定義する |
snapshotList |
0 または 1 |
スナップショットブロックのリスト。各スナップショットブロックは、当該コンポーネントのインストール状態を取り入れるさまざまな方法を定義する |
controlList |
0 または 1 |
当該コンポーネントで利用できる制御の一覧 |
diff |
0 または 1 |
当該コンポーネントから派生したコンポーネントに対して比較を実行する際に差分エンジンによって使用される命令の一覧 |
1 非派生コンポーネントで必要です。
<extends> 要素は <component> 要素の子であり、当該コンポーネントの派生元であるベースコンポーネントの宣言に使用されます。 ベースコンポーネントは最終でない場合があります。
当該コンポーネントは、ベースコンポーネントの各種の属性と要素を自動的に継承します。 コンポーネントは、継承されたデータの特定の部分を選択的に無効にできます。 継承と優先指定の許可は、当の属性または要素の説明内で指定します。
コンポーネントは、その拡張コンポーネントのインスタンスと言えます。 また、ベースコンポーネントをインスタンスとするコンポーネントのインスタンスでもあります。
名前 |
数 |
説明 |
---|---|---|
type |
1 |
ベースコンポーネントを指定する |
<type> 要素は <extends>、<componentRefList>、および <componentRef> 要素の子であり、ベースコンポーネントの型を指定します。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
systemName |
はい |
不可 |
ベース型として機能するシステム型コンポーネントの名前 |
component <varList> 要素は <component> 要素の子であり、当該コンポーネントと当該コンポーネントに含まれる構成リソースが使用するコンポーネントスコープの置換変数のリストを宣言するために使用されます。
名前 |
数 |
説明 |
---|---|---|
var |
1 つ以上 |
component 置換変数 (名前、デフォルト値など) の宣言 |
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <varList> 要素コンテンツを継承します。 派生コンポーネントが <varList> を宣言する場合、そのコンテンツはベースコンポーネントのコンテンツと完全に結合されます。 派生コンポーネントは新しい <var> 要素を宣言することで継承された要素を無効にできますが、ベースコンポーネントによって宣言された要素を削除することはできません。
component <var> 要素は component <varList> 要素の子であり、component 置換変数 (名前、デフォルト値など) を宣言するために使用されます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
access |
access Enum |
いいえ |
不可 |
変数のアクセスモード (詳細は下記)。 デフォルトは PUBLIC |
modifier |
modifier Enum |
いいえ |
不可 |
変数の修飾子 (詳細は下記) |
name |
identifier |
はい |
不可 |
置換変数の名前。 この名前は、包含する <varList> 内のほかの置換変数すべてにおいて一意でなければならない |
default |
文字列 |
はい 1 |
可能 |
置換変数のデフォルト値。これには、ほかの置換変数、対象ホスト属性、インストールされているコンポーネント変数などに対する参照を含めることができる |
1 抽象的な変数には含めることができません。
<var> 要素の「access」属性は、変数のアクセス可能性を指定します。
PUBLIC の場合、アクセスはまったく制限されません。
PROTECTED の場合、アクセスは同じパス内の派生コンポーネントとエンティティに制限されます。
PATH の場合、アクセスは同じパス内のエンティティに制限されます。
PRIVATE の場合、アクセスは当該コンポーネントに制限されます。
<var> 要素の「modifier」属性は、変数の優先指定要件を指定します。
ABSTRACT の場合、変数の default 属性は省略されます。このため、この属性は 非抽象派生コンポーネントによって指定する必要があります。 変数を抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 抽象変数は専用には設定できません。 非抽象変数は、デフォルト値を宣言する必要があります。
FINAL の場合、変数を派生コンポーネントによって無効にすることはできません。
指定しない場合、派生コンポーネントは変数を無効にするかどうかを選択できます。
デフォルトでは、派生コンポーネントはそのベースコンポーネントのすべてのアクセス可能変数 (アクセスモード、修飾子、デフォルト値など) を継承します。
派生コンポーネントは、ベースコンポーネントから継承された変数に含まれない名前を使用して別の変数を定義できます。 派生コンポーネントは、同じ名前を使用して変数を宣言し直すことにより、継承された非最終変数のデフォルト値、修飾子、アクセスモードなどを無効にできます。 変数を無効にする場合は、変数の全コンテンツ (デフォルト値、アクセスモード、修飾子など) を宣言し直す必要があります。 デフォルト値は、優先する変数が非抽象である場合にかぎって指定できます。 アクセスモードは、ベースコンポーネントよりも厳しくすることはできません。
変数を無効にすると、ベースコンポーネント内のものを含め、その変数に対するすべての参照は無効にされた値となります。
派生コンポーネントを非抽象と宣言する場合、ベースコンポーネントによって宣言された抽象変数は派生コンポーネントによって無効にする必要があります。
<resourceRef> 要素は <component> 要素の子であり、当該コンポーネントによって管理されるリソースを指定します。 この要素は、<componentRefList> 要素と併用はできません。 この要素およびその子の構成可能属性は、component 置換変数を参照できます。
リソースは、暗黙の PUBLIC アクセスモードとなります。
コンポーネントが単純コンポーネントから派生する場合、あるいは <resourceRef> 要素を含む非派生コンポーネントである場合、そのコンポーネントは単純コンポーネントと見なされます。 派生コンポーネントが単純コンポーネントから派生している場合、その派生コンポーネントに含めることができるのは <resourceRef> 要素だけです。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
modifier |
modifierEnum |
いいえ |
不可 |
リソースの修飾子 (詳細は下記) |
<resourceRef> 要素の「modifier」属性は、リソースの優先指定要件を指定します。
ABSTRACT の場合、resourceRef <resource> 要素は省略されます。このため、この要素は非抽象派生コンポーネントによって指定する必要があります。 ResourceRefs を抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 非抽象 resourceRefs は、<resource> 要素を宣言する必要があります。
FINAL の場合、派生コンポーネントで resourceRef を無効にすることはできません。
指定しない場合、派生コンポーネントは resourceRef を無効にするかどうかを選択できます。
名前 |
数 |
説明 |
---|---|---|
installSpec |
1 1 |
リソースのインストール方法を指定する |
resource |
1 2 |
関連付けられたリソースを特定する |
1 非派生コンポーネントにしか認められません。 2 抽象的なリソースには含めることができません。
デフォルトでは、派生コンポーネントはそのベースコンポーネントの <resourceRef> 要素を継承します。
派生コンポーネントは、<resourceRef> 要素を宣言し直すことによって、継承された非最終 <resourceRef> 要素の修飾子と <resource> 要素を無効にできます。 <resourceRef> 要素が無効にされる際に、<installSpec> 要素は除外されます。これはそのコンテンツが無効にされないためです。 <resource> 要素が指定されるのは、優先する <resourceRef> が抽象でない場合だけです。
<resourceRef> が無効にされる際に、ベースコンポーネント内の使用も含め、リソースの使用 (<deployResource>、 <addResource> など) はすべて無効にされた値に解決処理されます。
派生コンポーネントが非抽象と宣言された場合で、ベースコンポーネントの <resourceRef> 要素が抽象のとき、その派生コンポーネントは <resourceRef> 要素を無効にする必要があります。
<installSpec> 要素は <resourceRef> 要素の子であり、関連付けられたリソースのインストール方法を指定するために使用されます。
この要素は派生コンポーネントによって継承され、無効にできません。 しかし、ベースコンポーネントは <installSpec> 属性の値指定にコンポーネント変数を使用でき、これらの変数の値は無効にできます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
文字列 |
はい |
可能 |
リソースのインストール時にリソースに使用する名前 |
path |
文字列 |
いいえ |
可能 |
リソースのインストール先となるディレクトリのパス。 相対ディレクトリは、包含コンポーネントの installPath 属性に相対的であると見なされる。 指定しないと、デフォルトで component installPath 属性が使用される |
permissions |
文字列 |
いいえ |
可能 |
インストール時に当該リソースに割り当てるアクセス権。書式は、UNIX chmod コマンドで定義されているように 3 桁の 8 進数を使用する。 最初の桁はファイルの所有者のアクセス権、2 つ目の桁はそのファイルのグループに含まれるほかのユーザーのアクセス権、3 つ目はその他のユーザーのアクセス権。 各桁は、希望するアクセス権 (1: 実行、2: 書き込み、4: 読み取り) の合計。 したがって、「777」と指定するとファイルに対する読み取り、書き込み、および実行のアクセス権をすべてのユーザーに与えることになる。 指定しないと、リソースはデフォルトのアクセス権でインストールされる |
ユーザー |
文字列 |
いいえ |
可能 |
インストール時に当該リソースの所有者として割り当てるユーザー。 指定しないと、使用するユーザーはプラン実行機能 (plan executor) によって決定される |
group |
文字列 |
いいえ |
可能 |
インストール時に当該リソースに割り当てるグループ。 指定しないと、使用するグループはプラン実行機能によって決定される |
deploy Mode |
次の 1 つ: ADD_TO または、 REPLACE |
いいえ |
可能 |
関連付けられたディレクトリリソースの配備方法を指定する。 ADD_TO は、対象ディレクトリ内の任意の既存ファイルにディレクトリコンテンツが追加されることを意味する。 REPLACE は、対象ディレクトリ内のすべての既存ファイルがディレクトリコンテンツによって置き換えられることを意味する。 指定しない場合、デフォルトで REPLACE が使用される。 非ディレクトリリソースの場合、この属性は無視される |
diffDeploy |
ブール型 |
いいえ |
可能 |
リソースを差分配備モードで配備すべきかかどうかを指定する。 指定しない場合、デフォルトで false が使用される。 差分配備モードを有効にした場合、それまでに配備されたことがないリソースだけが配備される |
<resource> 要素は <resourceRef> 要素の子であり、 当該コンポーネントによって配備されるリソースを特定するために使用されます。
参照されたリソースが構成可能なリソースである場合、包含コンポーネントにアクセス可能な任意のコンポーネントスコープ変数に対する置換変数参照を含むことができます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
文字列 |
はい |
不可 |
リソースマネージャによって管理されるリソースの完全なパス名 |
version |
version |
はい |
不可 |
リソースマネージャによって管理されるリソースのバージョン |
<componentRefList> 要素は <component> 要素の子であり、当該コンポーネントによって参照されるコンポーネントの一覧を指定します。 この要素は、<resourceRef> 要素と併用はできません。 この要素およびその子の構成可能属性は、component 置換変数を参照できます。
コンポーネントが複合コンポーネントから派生する場合、あるいは <resourceRef> 要素を含まない非派生コンポーネントである場合、そのコンポーネントは複合コンポーネントと見なされます。 派生コンポーネントが複合コンポーネントから派生している場合、その派生コンポーネントに含めることができるのは <componentRefList> 要素だけです。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
modifier |
FINAL |
いいえ |
不可 |
リストの修飾子 (詳細は下記) |
<componentRefList> 要素の「modifier」属性は、リストの優先指定要件を指定します。 指定する場合、値は FINAL でなければなりません。
FINAL の場合、派生コンポーネントは新しい <componentRef> 要素を宣言できません。
指定しない場合、派生コンポーネントは新しい <componentRef> 要素を追加できます。
どちらの場合も、派生コンソールは <type> 要素と非最終継承 <componentRef> 要素を無効にできます。 ベースコンポーネントの componentRefList 修飾子が最終である場合、派生コンポーネントの componentRefList 修飾子も最終である必要があります。
<componentRefList> 要素の最終修飾子は、含まれる各 <componentRef> も最終 であることを意味するわけではありません。
名前 |
数 |
説明 |
---|---|---|
type |
0 または 1 |
すべての参照先コンポーネントがインスタンスとなるべき型を指定する。 指定しないと、参照先コンポーネントは任意の型になる |
componentRef |
0 以上 |
コンポーネント参照 |
デフォルトでは、派生コンポーネントはそのベースコンポーネントの <componentRefList> 要素コンテンツを継承します。 派生コンポーネントが <componentRefList> を宣言する場合、そのコンテンツはベースコンポーネントのコンテンツと完全に結合されます。 派生コンポーネントは、新しい <componentRef> 要素を宣言することで継承された要素を無効にできますが、ベースコンポーネントによって宣言された要素を削除することはできません。
派生コンポーネントは、その <componentRefList> 内の <type> を宣言し直すことによって、親コンポーネントの <componentRefList> によって宣言されている <type> 要素を無効にできます。 この場合、無効にされる型は本来の型のインスタンスであるか、あるいは本来の型が指定されていない状態でなければなりません。 さらに、すべての参照先コンポーネント (ベースコンポーネントから継承されるものを含め) は無効にされる型のインスタンスでなければなりません。
<componentRef> 要素は <componentRefList> 要素の子であり、当該コンポーネントによって参照されるコンポーネントを指定します。
componentRefs は、暗黙に PUBLIC アクセスモードとなります。
<componentRef> 要素の「modifier」属性は、コンポーネント参照の優先指定要件を指定します。
ABSTRACT の場合、コンポーネント参照の <component> 要素は省略されます。このため、この要素は非抽象派生コンポーネントによって指定する必要があります。 コンポーネント参照を抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 非抽象コンポーネント参照は、<component> 要素を宣言する必要があります。
FINAL の場合、コンポーネント参照は派生コンポーネントによって無効にできません。
指定しない場合、派生コンポーネントはコンポーネント参照を無効にするかどうかを選択できます。
<componentRef> 要素の「installMode」属性は、参照先コンポーネントをインストールして対象化する方法を指定します。 参照先コンポーネントが TOPLEVEL としてインストールされている場合、1 つのプランで直接インストールされたかのように、ほかの任意のコンポーネントがそのコンポーネントを使用できます。 しかし、参照先コンポーネントが NESTED としてインストールされている場合、そのインストールの範囲は参照元コンポーネントのインストール範囲に暗黙に限定され、そのサービスも参照元コンポーネントでしか利用できません。
論理的に、入れ子になった参照先コンポーネントは参照元コンポーネントが要求する細かな機能単位を定義しますが、ほかのコンポーネントに役立つことはありません。 一方、最上位の参照先コンポーネントは参照元コンポーネントが使用するサービスを定義しますが、ほかのコンポーネントもこのサービスを使用することもできます。
入れ子になった参照先コンポーネントの有効期間は、参照元コンポーネントの有効期間と暗黙に同じになります。 入れ子になった参照先コンポーネントのインストールは参照元コンポーネントのインストールの最中にしか行えず、参照元コンポーネントがアンインストールされる際に暗黙にアンインストールされます。 これに対し、最上位の参照先コンポーネントの有効期間が参照元コンポーネントの有効期間と同じになることはありません。 最上位の参照先コンポーネントは、参照元コンポーネントのインストール時に参照元コンポーネントによってインストールすることも、あるいはほかの方法であらかじめインストールしておくか、あとからインストールすることもできます。 参照元コンポーネントがアンインストールされる場合、明示的に参照元コンポーネントによってアンインストールされないかぎり最上位の参照先コンポーネントはインストールされたままとなります。 また、ほかのコンポーネントも参照先コンポーネントをアンインストールできます。
名前 |
数 |
説明 |
---|---|---|
type |
0 または 1 |
当該参照先コンポーネントがインスタンスとなるべき型を指定する。 これは、包含する <componentRefList> によって指定される型のインスタンスでなければならない。 指定しないと、包含する <componentRefList> によって指定された型が使用される |
argList |
0 または 1 |
参照先コンポーネントのインストール時にそれらのコンポーネント変数設定として使用される値の一覧。 |
component |
1 1 |
参照先コンポーネント |
1 抽象 componentRefs には含めることができません。
デフォルトでは、派生コンポーネントはそのベースコンポーネントのすべてのコンポーネント参照を継承します。
ベースコンポーネントの <componentRefList> 要素が最終でない場合、派生コンポーネントはベースコンポーネントから継承されたコンポーネント参照に使用されていない名前を使用して、別のコンポーネント参照を定義できます。
派生コンポーネントは、同じ名前を使用してコンポーネント参照を宣言し直すことにより、非最終継承コンポーネント参照のコンポーネント参照を無効にできます。 コンポーネント参照が無効にされた場合には、コンポーネント参照の全コンテンツを宣言し直す必要があります。 優先する installMode は、本来の参照のものと同じでなければなりません。 優先する <type> 要素は、本来の型のインスタンスでなければなりません。 優先する <argList> 要素は、本来のものと結合されます (詳細は以下)。 <component> 要素は、優先する参照が非抽象の場合にかぎって指定されます。
コンポーネント参照を無効にすると、ベースコンポーネント内のものも含め、そのコンポーネント参照の使用はすべて無効にされた値に評価されます。
派生コンポーネントを非抽象と宣言する場合、ベースコンポーネントによって宣言された抽象的なコンポーネント参照は派生コンポーネントによって無効にする必要があります。
<componentRef> 要素の <argList> 子要素は、参照先コンポーネントのインストール時にそのコンポーネント変数設定として使用される値の一覧を指定します。 <argList> の書式は、<call> 手順の <argList> 子要素の書式と同じです。 <argList> 要素の各属性は、参照先コンポーネントにおけるコンポーネント変数または宣言された型 (参照が ABSTRACT の場合) を指定します。 <argList> 属性の値は、参照先コンポーネントのインストール時に、指定されたコンポーネント変数に使用される優先指定値です。
コンポーネント参照が派生コンポーネントによって無効にされる場合、ベースコンポーネントおよび派生コンポーネントの <argList> は、まずベースコンポーネントの <argList> のコンテンツを参照先コンポーネントに適用し、続いて派生コンポーネントの <argList> を適用することによって効率良く結合できます。 ベースコンポーネント参照の <argList> を処理する場合、考慮されるのはベースコンポーネント参照の宣言された型で定義された変数だけです。
<argList> で指定されていないコンポーネント変数は、インストール時にそれらのデフォルト値を使用します。 <argList> がまったく指定されていない場合、参照先コンポーネントはその変数のデフォルト値を使用してインストールされます。 <argList> で指定される参照先コンポーネントの変数は、参照元コンポーネントからアクセス可能でなければなりません。 また、これらの変数はアクセスモード FINAL ではなく、PUBLIC または PROTECTED で宣言されていなければなりません。
最上位の参照先コンポーネントの場合、<argList> 要素が使用されるのは参照先コンポーネントが参照元コンポーネントによってインストールされている場合だけです。 参照先コンポーネントがほかの方法でインストールされていることもあります。この場合、<argList> は意味を持ちません。
<componentRef> 要素の <component> 子要素は、参照先コンポーネントを特定します。 この子要素の構造は、「host」属性が許可されない点を除き、<component> リポジトリコンポーネントターゲッターと同じです。 参照先コンポーネントバージョンは、包含コンポーネントの保存時にリポジトリ内に存在する必要があります。
「version」属性を指定しないと、version は包含コンポーネントの保存時に存在する参照先コンポーネントの最新バージョンに解決処理されます。 参照先コンポーネントのバージョンがまったく存在しない場合、保存時のエラーです。 包含コンポーネントが一度保存されると、当該コンポーネントが参照するすべてのコンポーネントのバージョンがロックされます。それらのバージョンは、包含コンポーネントの新しいバージョンを作成しないかぎり変更できません。
<installList> 要素は <component> 要素の子であり、1 つ以上の名前付きインストール手順ブロックを含みます。各ブロックは、当該コンポーネントをインストールする個々の方法を示します。 多くのコンポーネントは、この要素の子として 1 つのインストールブロックしか持ちません。
インストール環境ごとに異なる手順が必要な場合は、複数のインストールブロックを使用できます。 たとえば、サーバークラスタに EBJ アプリケーションを配備する手順と単一の管理対象サーバーに配備する手順、初めてインストールする場合の手順とアプリケーションをアップグレードする場合の手順などが考えられます。
名前 |
数 |
説明 |
---|---|---|
installSteps |
1 つ以上 |
当該コンポーネントをインストールするために実行できる手順を含む名前付きのインストールブロック |
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能な <installList> 要素コンテンツを継承します。 派生コンポーネントが <installList> を宣言する場合、そのコンテンツはベースコンポーネントのコンテンツと完全に結合されます。 派生コンポーネントは新しい <installSteps> 要素を宣言することで継承された要素を無効にできますが、ベースコンポーネントによって宣言された要素を削除することはできません。
<installSteps> 要素は <installList> 要素の子であり、当該コンポーネントをインストールするために実行される一連の手順を示します。 <install> 手順によって当該コンポーネントがインストールされる場合、ここに挙げる手順が順に実行されます。 一般に、参照先コンポーネントをインストールするために、単純コンポーネントのインストール手順には <deployResource> 手順が含まれ、複合コンポーネントのインストール手順には 1 つ以上の <install> 手順が含まれます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
access |
accessEnum |
いいえ |
不可 |
インストールブロックのアクセスモード (詳細は下記)。 デフォルトは PUBLIC |
modifier |
ModifierEnum |
いいえ |
不可 |
インストールブロックの修飾子 (詳細は下記) |
name |
entityName |
はい |
不可 |
インストールブロックの名前。 この名前は、包含している <installList> 内のすべてのインストールブロックの中で一意である必要がある |
description |
文字列 |
いいえ |
不可 |
インストールブロックの説明。 ドキュメント化に便利 |
<installSteps> 要素の「access」属性は、インストールブロックのアクセス可能性を指定します。
PUBLIC の場合、アクセスはまったく制限されません。
PROTECTED の場合、アクセスは同じパス内の派生コンポーネントとエンティティに制限されます。
PATH の場合、アクセスは同じパス内のエンティティに制限されます。
PRIVATE の場合、アクセスは当該コンポーネントに制限されます。
直接実行できるのは PUBLIC ブロックだけです。
<installSteps> 要素の「modifier」属性は、インストールブロックの優先指定要件を指定します。
ABSTRACT の場合、ブロックに本体を含めることはできません。 本体は、非抽象派生コンポーネントによって指定する必要があります。 インストールブロックを抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 抽象ブロックは専用にはできません。 非抽象ブロックの場合、本体を宣言する必要があります。
FINAL の場合、インストールブロックを派生コンポーネントによって無効にすることはできません。
指定しない場合、派生コンポーネントはブロックを無効にするかどうかを選択できます。
<installSteps> 要素の子は、オプションの <paramList> 要素とそれに続く本体から構成されます。この本体は、オプションの local <varList> 要素とそれに続くゼロ個以上の「共通」手順または「コンポーネントのインストール専用」手順から構成されます。 インストールブロックが抽象と宣言されている場合、本体は含められません。
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべてのインストールブロックを継承します。
派生コンポーネントは、ベースコンポーネントから継承されたインストールブロックに含まれない名前を使用して別のインストールブロックを定義できます。 派生コンポーネントは、同じ名前を使用してブロックを宣言し直すことにより、継承された非最終インストールブロックを無効にできます。 ブロックの無効は名前を使用してしか行えず、パラメタに基づいてオーバーロード (多重定義) することはできません。 ブロックを無効にする場合は、ブロックの全コンテンツ (アクセスモード、修飾子、パラメタ、および本体) を宣言し直す必要があります。 本体を指定できるのは、優先するブロックが非抽象の場合だけです。 アクセスモードは、ベースコンポーネントよりも厳しくすることはできません。
派生コンポーネント内のブロックを優先するシグニチャーは、ベースコンポーネントのシグニチャーと互換性がなければなりません。 互換性があるということは、ベースブロックが使用できる引数はすべて派生ブロックでも使用できることを意味します。
派生ブロックは、次の条件が満たされる場合にベースブロックと互換性があります。
必須パラメタを新たに宣言していない
親ブロックで省略可能なパラメタを必須パラメタとして再定義していない
以下のシグニチャー変更は互換性があると見なされます。
パラメタ (必須パラメタまたは省略可能パラメタ) の削除
必須パラメタを省略可能に変更する
省略可能パラメタの追加
ブロックを無効にすると、ベースコンポーネント内の参照も含め、そのブロックに対する参照はすべて無効にされた値に評価されます。
派生コンポーネントを非抽象と宣言する場合は、ベースコンポーネントによって宣言されているすべての抽象ブロックを派生コンポーネントによって無効にする必要があります。
派生コンポーネント内のブロックは、<superComponent> ターゲッターを使用してブロックを無効にする場合でも、ベースコンポーネントによって定義されているブロックを明示的に呼び出すことができます。
<paramList> 要素は <installSteps>、<uninstallSteps>、<snapshot>、および <control> 要素の子であり、包含要素の手順で使用できるパラメタの一覧を宣言するために使用されます。 パラメタの値は、呼び出し側の <argList> 要素のコンテンツに基づいて呼び出し側によって定義されます。 たとえば、<installSteps> ブロック内の <paramList> の場合、パラメタ値は <installSteps> ブロックを呼び出した <install> 手順の <argList> に基づいて定義されます。
包含要素の手順は、包含コンポーネントの local <varList> 要素で宣言されたローカルスコープ変数、<paramList> 要素で宣言されたパラメタ、および component <varList> 要素で宣言されたコンポーネントスコープ変数を使用できます。 <paramList> パラメタの名前が component <varList> 変数と同じである場合、パラメタの値が使用されます。 これは、パラメタによるコンポーネント変数の「隠蔽」です。 隠蔽は、ローカル変数とパラメタの間では許可されません。これは、それらの名前が個別のものでなければならないためです。
名前 |
数 |
説明 |
---|---|---|
param |
1 つ以上 |
パラメタ (名前、デフォルト値など) の宣言 |
<param> 要素は <paramList> 要素の子であり、パラメタ (名前、デフォルト値など) の宣言に使用されます。 デフォルト値が使用されるのは、呼び出し側がこのパラメタの値を明示的に渡さない場合だけです。 デフォルト値が指定されず、呼び出し側がこのパラメタの値を明示的に渡さない場合、プランの実行時にプリフライトエラーが発生します。
param 要素には、オプションの prompt および displayMode 属性が含まれます。これらの属性は、包含しているインストールブロック、アンインストールブロック、または制御ブロックがプランまたはほかのコンポーネントからではなくクライアントによって直接呼び出される場合に使用されます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
identifier |
はい |
不可 |
パラメタの名前。 この名前は、包含要素によって宣言されているすべてのローカル変数とパラメタにおいて一意のものでなければならない |
prompt |
文字列 |
いいえ |
不可 |
パラメタの値を求める際に表示する UI テキスト。 指定しないと、デフォルトで名前が使用される |
default |
文字列 |
いいえ |
可能 |
パラメタのデフォルト値。これには、コンポーネント変数、対象ホスト属性、およびインストール済みのコンポーネント変数を含めることができるが、ほかのパラメタを含めることはできない |
display Mode |
次の 1 つ: PASSWORD CLEAR BOOLEAN |
いいえ |
不可 |
パラメタの表示モード 指定しないと、デフォルトで CLEAR が使用される PASSWORD を指定すると、クライアントが入力した値が隠される (非表示、*** への置換など) BOOLEAN を指定すると、チェックボックスを使用してパラメタの入力が行われる あるいは、CLEAR または BOOLEAN を指定した場合に、入力時に値を表示するようにすると安全 |
local <varList> 要素は <installSteps>、<uninstallSteps>、<snapshot>、および <control> 要素の子であり、包含要素の手順に使用できる変数の一覧を宣言するために使用されます。 これらの変数の値は宣言時に定義され、再定義は行えません。
包含要素の手順は、包含コンポーネントの local <varList> 要素で宣言されたローカルスコープ変数、<paramList> 要素で宣言されたパラメタ、および component <varList> 要素で宣言されたコンポーネントスコープ変数を使用できます。 local <varList> 変数の名前が component <varList> 変数と同じである場合、ローカル変数の値が使用されます。 これは、ローカル変数によるコンポーネント変数の「隠蔽」です。 隠蔽は、ローカル変数とパラメタの間では許可されません。これは、それらの名前が個別のものでなければならないためです。
名前 |
数 |
説明 |
---|---|---|
var |
1 つ以上 |
ローカル変数 (名前、デフォルト値など) の宣言 |
local <var> 要素は local <varList> 要素の子であり、ローカル変数 (名前や値など) を宣言するために使用されます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
identifier |
はい |
不可 |
ローカル変数の名前。 この名前は、包含要素によって宣言されているすべてのローカル変数とパラメタにおいて一意のものでなければならない |
default |
文字列 |
はい |
可能 |
ローカル変数のデフォルト値。これには、先に宣言されているほかのローカル変数に対する参照、パラメタ、コンポーネント変数、対象ホスト属性、インストール済みのコンポーネント変数などを含めることができる |
<uninstallList> 要素は <component> 要素の子であり、1 つ以上の名前付きアンインストール手順ブロックを含みます。各ブロックは、当該コンポーネントをアンインストールする個々の方法を示します。 多くのコンポーネントには、この要素の子としてアンインストールブロックが1 つだけ存在します。 インストール環境ごとに異なる手順が必要な場合は、複数のアンインストールブロックを使用できます。 たとえば、EBJ アプリケーションの配備をサーバークラスタから解除する手順と、単一の管理対象サーバーから解除する手順などがあります。 アンインストールブロックは、インストールブロックと一対一で対応していることが少なくありません。このような場合には、慣習上同じ名前を使用して対応を示してください。
名前 |
数 |
説明 |
---|---|---|
uninstallSteps |
1 つ以上 |
当該コンポーネントをアンインストールするために実行できる手順を含む名前付きのアンインストールブロック |
デフォルトでは、派生コンポーネントはベースコンポーネントのアクセス可能な <uninstallList> 要素コンテンツを継承します。 派生コンポーネントが <uninstallList> を宣言する場合、そのコンテンツはベースコンポーネントのコンテンツと完全に結合されます。 派生コンポーネントは新しい <uninstallSteps> 要素を宣言することで継承された要素を無効にできますが、ベースコンポーネントによって宣言された要素を削除することはできません。
<uninstallSteps> 要素は <uninstallList> 要素の子であり、当該コンポーネントをアンインストールするために実行される一連の手順を示します。 <uninstall> 手順によって当該コンポーネントがアンインストールされる場合、ここに挙げられる手順が順に実行されます。 一般に、参照先コンポーネントをアンインストールするために、単純コンポーネントのアンインストール手順には <undeployResource> 手順が含まれ、複合コンポーネントのアンインストール手順には 1 つ以上の <uninstall> 手順が含まれます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
access |
accessEnum |
いいえ |
不可 |
アンインストールブロックのアクセスモード (詳細は下記)。 デフォルトは PUBLIC |
modifier |
modifierEnum |
いいえ |
不可 |
アンインストールブロックの修飾子 (詳細は下記) |
name |
entityName |
はい |
不可 |
アンインストールブロックの名前。 この名前は、包含している <uninstallList> 内のすべてのアンインストールブロックの中で一意である必要がある |
description |
文字列 |
いいえ |
不可 |
アンインストールブロックの説明。 ドキュメント化に便利 |
<uninstallList> 要素の「access」属性は、アンインストールブロックのアクセス可能性を指定します。
PUBLIC の場合、アクセスはまったく制限されません。
PROTECTED の場合、アクセスは同じパス内の派生コンポーネントとエンティティに制限されます。
PATH の場合、アクセスは同じパス内のエンティティに制限されます。
PRIVATE の場合、アクセスは当該コンポーネントに制限されます。
直接実行できるのは PUBLIC ブロックだけです。
<uninstallSteps> 要素の「modifier」属性は、アンインストールブロックの優先指定要件を指定します。
ABSTRACT の場合、ブロックに本体を含めることはできません。 本体は、非抽象派生コンポーネントによって指定する必要があります。 アンインストールブロックを抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 抽象ブロックは専用にはできません。 非抽象ブロックの場合、本体を宣言する必要があります。
FINAL の場合、アンインストールブロックを派生コンポーネントによって無効にすることはできません。
指定しない場合、派生コンポーネントはブロックを無効にするかどうかを選択できます。
<uninstallSteps> 要素の子は、オプションの <paramList> 要素とそれに続く本体から構成されます。この本体は、オプションの local <varList> 要素と、それに続くオプションの <dependantCleanup> ブロックおよびゼロ個以上の「共通」手順または「コンポーネントのアンインストール専用」手順から構成されます。 アンインストールブロックが抽象と宣言されている場合、本体は含められません。
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべてのアンインストールブロックを継承します。 アンインストールブロックを優先する意味論は、インストールブロックを無効にする意味論と同じです。
<dependantCleanup> 要素は <uninstallSteps> 要素の子で、呼び出し側コンポーネントに現在依存しているコンポーネントを削除するために実行される手順を指定します。 この要素に属性はなく、包含するアンインストールブロックのスコープ内に許可される任意の数の手順を含むことができます。 この要素を含めると、依存コンポーネントのチェックはブロックのコンテンツの実行が完了するまで延期されます。 ブロックの実行が完了したあとも依存コンポーネントが存在する場合は、アンインストールが失敗し、コンポーネントはインストールされたままとなります。 依存コンポーネントが残っていない場合、アンインストールが継続されて残りの手順が行われます。
アンインストールブロックに <dependantCleanup> ブロックを含めないと、依存コンポーネントが存在した場合、アンインストールブロックはただちに停止します。
<dependantCleanup> ブロックは、依存コンポーネントをまとめてアンインストールする目的で、しばしば <allDependants> ターゲッターと併用されます。
<snapshotList> 要素は <component> 要素の子で、1 つ以上の名前付きスナップショットブロックが含まれます。各ブロックには、対象ホスト上における当該コンポーネントのインストール状態をキャプチャする個別の方法が指定されます。 複数のスナップショットブロックを使用してインストール状態のさまざまな情報をキャプチャできるため、キャプチャされたインストール状態とコンポーネントの現在の状態の相違を詳しく調べることができます。
名前 |
数 |
説明 |
---|---|---|
snapshot |
1 つ以上 |
当該コンポーネントのインストール状態をキャプチャするために実行できる名前付きスナップショットブロック |
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <snapshotList> 要素コンテンツを継承します。 派生コンポーネントが <snapshotList> を宣言する場合、そのコンテンツはベースコンポーネントのコンテンツと完全に結合されます。 派生コンポーネントは新しい <snapshot> 要素を宣言することで継承された要素を無効にできますが、ベースコンポーネントによって宣言された要素を削除することはできません。
<snapshot> 要素は <snapshotList> 要素の子で、当該コンポーネントのインストール状態をキャプチャするために実行される一連の手順を定義します。 <createSnapshot> または <addSnapshot> 手順がこのスナップショットブロックを指定する場合、<prepare> ブロック内の手順が順に実行され、続いて <capture> ブロックで指定されたファイルが対象マシンのキャプチャ領域で キャプチャされ、最後に <cleanup> ブロック内の手順が順に実行されます。
スナップショットブロックは、コンポーネントの現在の状態をそのインストール時の状態と比較するためにも使用されます。 具体的には、対象マシンで <prepare> 手順が再実行され、続いてインストール時にキャプチャされたファイルが現在のファイル状態と比較され、<cleanup> 手順が再実行されます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
entityName |
はい |
不可 |
スナップショットブロックの名前。 この名前は、包含している <snapshotList> 内のすべてのスナップショットブロックの中で一意である必要がある |
description |
文字列 |
いいえ |
不可 |
スナップショットブロックの説明。 ドキュメント化に便利 |
<snapshot> 要素の「access」属性は、スナップショットブロックのアクセス可能性を指定します。
PUBLIC の場合、アクセスはまったく制限されません。
PROTECTED の場合、アクセスは同じパス内の派生コンポーネントとエンティティに制限されます。
PATH の場合、アクセスは同じパス内のエンティティに制限されます。
PRIVATE の場合、アクセスは当該コンポーネントに制限されます。
<snapshot> 要素 の「modifier」属性 は、スナップショットブロックの優先指定要件を指定します。
ABSTRACT の場合、ブロックに本体を含めることはできません。 本体は、非抽象派生コンポーネントによって指定する必要があります。 スナップショットブロックを抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 抽象ブロックは専用にはできません。 非抽象ブロックの場合、本体を宣言する必要があります。
FINAL の場合、スナップショットブロックを派生コンポーネントによって無効にすることはできません。
指定しない場合、派生コンポーネントはブロックを無効にするかどうかを選択できます。
名前 |
数 |
説明 |
---|---|---|
paramList |
0 または 1 |
当該スナップショットの prepare、capture、および cleanup の各ブロック内で使用するためのパラメタの一覧 |
varList |
0 または 1 |
当該スナップショットの prepare、capture、および cleanup の各ブロック内で使用するためのローカル変数の一覧 |
prepare |
0 または 1 |
ファイルのキャプチャまたは比較に備えて実行される手順を含む |
capture |
0 または 1 |
当該スナップショットの一部としてキャプチャされるファイルおよびディレクトリの一覧を含む |
cleanup |
0 または 1 |
キャプチャまたは比較の完了後に実行される手順を含む |
当該スナップショットが <createSnapshot> 手順から呼び出される場合は、必要なパラメタをその <paramList> 要素で宣言することはできません。
varList、prepare、capture、および cleanup 要素は、集合的にスナップショットの本体を定義します。 スナップショットブロックが抽象と宣言される場合、本体は含められません。
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべてのスナップショットブロックを継承します。 スナップショットブロックを優先する意味論は、インストールブロックを優先する意味論と同じです。
派生コンポーネントスナップショットブロックの prepare ブロックからベースコンポーネントスナップショットブロックの prepare ブロックを呼び出す方法はありません。 同じことが cleanup についても言えます。 このためには、ベースコンポーネントはその prepare/cleanup 手順を派生コンポーネントによって呼び出される可能性のある制御ブロックに含める必要があります。
<prepare> 要素は <snapshot> 要素の子であり、ファイルのキャプチャまたは比較に備えて実行される一連の手順を定義します。 これらの手順は、当該スナップショットを対象とする <createSnapshot> または <addSnapshot> 手順の結果として、かつ当該スナップショットを対象とする比較作業として実行されます。 どのような場合も、これらの手順はファイルのキャプチャまたは比較作業に先立って実行されます。
<prepare> 要素の子は、1 つ以上の <call>、<execNative>、または <transform> 手順から構成されます。 ほかの手順は許可されません。 包含される手順は、スナップショットブロックで宣言されたローカルパラメタおよびローカル変数と、隠蔽されていない component 置換変数を参照できます。
<capture> 要素は <snapshot> 要素の子であり、当該スナップショットの一部としてキャプチャされるファイルとリソースを定義します。 キャプチャは、<prepare> ブロック内の手順が実行されたあとしか発生しません。キャプチャが完了すると、<cleanup> ブロック内の手順が実行されます。
<capture> 要素の子は、1 つ以上の <addFile>、<addSnapshot>、または <addResource> 要素から構成されます。 このブロックに挙げられるファイルとディレクトリは、指定された順にキャプチャされます。 包含される子は、スナップショットブロックで宣言されたローカルパラメタおよびローカル変数と、隠蔽されていない component 置換変数を参照できます。
<addFile> 要素 は <capture> 要素 の子であり、包含するスナップショットの一部としてキャプチャされるファイルを指定します。
値には、マルチバイトの文字列を使用できます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
path |
文字列 |
はい |
可能 |
対象ホストのファイルシステム上のファイルまたはディレクトリのパス名 |
ownership |
次の 1 つ: SET_SELF ADD_SELF ADD_TEMP |
いいえ |
不可 |
キャプチャされたファイルの所有権オプション (詳細は下記) |
filter |
次の 1 つ: DIRECTORIES FILES BOTH |
いいえ |
不可 |
パス名がディレクトリを指している場合、この属性はディレクトリ自体、そのディレクトリに含まれるファイル、またはそれらの両方のどれをキャプチャすべきかを示す。 指定しないと、デフォルトで BOTH が使用される。 パス名がディレクトリでない場合、この属性は無視され、ファイルが直接キャプチャされる |
recursive |
ブール型 |
いいえ |
不可 |
パス名がディレクトリを指している場合、この属性は現在のフィルタ設定を使用してサブディレクトリを再帰的にキャプチャすべきかどうかを示すために使用される。 指定しないと、デフォルトで true が使用される。 パス名がディレクトリでない場合、この属性は無視され、ファイルが直接キャプチャされる |
displayName |
文字列 |
いいえ |
可能 |
当該スナップショットエントリがほかのエントリと比較される際に表示に含めるテキスト |
<addFile> 要素の「ownership」属性は、キャプチャされるファイルの所有権オプションを指定します。 指定しないと、デフォルトで SET_SELF が使用されます。
スナップショットによってキャプチャされるインストール状態の情報の 1 つに、ファイルおよびディレクトリの所有権があります。 これは UNIX のアクセス権と同じではなく、参照カウントという概念に密着したものです。 具体的には、ファイルまたはディレクトリは 1 つ以上のスナップショットによって所有されているものとしてキャプチャできます。 ほかのコンポーネントインストールの結果としてファイルの所有者があとで変わる場合には、そのファイルがその初期状態と比較される際にこのことが確認され、報告されます。 これにより、 1 つのコンポーネントが別のコンポーネントに関連付けられたファイルを意図せずに上書きすることから生ずる差異の追跡がスムーズに行われます。 スナップショットの所有権情報は、所有者テーブルとして知られる、対象ホスト上のリポジトリ内にキャプチャされます。
ownership 属性の値は以下の意味論を持ちます。
ownership 値が SET_SELF の場合、所有者テーブルは関連付けられたファイルまたはディレクトリ用の単一のエントリを含むように更新されます。 そのエントリは、実行するインストール済みコンポーネントとスナップショットを所有者としてリストします。 また、キャプチャされたファイルコンテンツまたはディレクトリコンテンツのキャプチャ領域 ID もリストします。
ownership 値が ADD_SELF の場合、インストール済みコンポーネントとスナップショットを付加的な所有者として追加し、以前の所有者として既存のキャプチャ領域 ID を共有させる必要があります。
ownership 値 ADD_TEMP は ADD_SELF と似ていますが、新しいキャプチャが常に作成されてその ID が常に新しいエントリに使用されます (ほかの所有者のものを共有することはない)。
<addSnapshot> 要素は <capture> 要素の子であり、外部スナップショットを実行してそのコンテンツを当該スナップショットに追加すべきであることを示します。
<addSnapshot> 手順の使用は、<addSnapshot> 手順の代わりに、呼び出されたスナップショットの prepare 手順を呼び出し側スナップショットの prepare ブロックの最後に追加し、呼び出されたスナップショットの cleanup 手順を呼び出し側スナップショットの cleanup ブロックの先頭に追加し、呼び出されたスナップショットの capture 手順を呼び出し側スナップショットの capture ブロックに追加するのと意味的に同じです。 したがって、呼び出される側および呼び出し側のスナップショットブロックによって参照されるファイルが重複しないように注意する必要があります。
<capture> 要素には任意の数の <addSnapshot> 手順を指定でき、呼び出される側のスナップショットはその <capture> 要素に任意の数の <addSnapshot> 手順を含むことができます。
<addSnapshot> コールアウトを使用してファイルをスナップショットに間接的に追加する場合、スナップショットのキャプチャを開始した最上位のコンポーネントは (<addFile> 命令が入ったコンポーネントとは対照的に) ファイルの所有者と見なされます。 同様に、スナップショットに対して diff が実行される場合は、スナップショットを開始した最上位コンポーネントの diff 無視命令だけが考慮されます。 <addSnapshot> コールアウトの結果として出現したコンポーネントに含まれる diff 無視命令は考慮されません。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
blockName |
文字列 |
はい |
不可 |
実行する外部スナップショットブロックの名前 |
名前 |
数 |
説明 |
argList |
0 または 1 |
スナップショットブロックに渡す引数の一覧 |
installed component targeter |
0 または 1 |
スナップショットブロックに含まれるコンポーネントを特定する。 指定しないと、<thisComponent> が使用される |
<addResource> 要素は <capture> 要素の子であり、包含するスナップショットの一部としてキャプチャされるコンポーネントに関連付けられたリソースを指定します。 この要素は、単純コンポーネントにしか含めることができません。
この要素は、次に示すように、同等の <addFile> 要素の簡略構文として機能します。
関連付けられたリソースが deployMode ADD_TO のディレクトリリソースである場合、<addResource> は <addFile path="path of deployed directory" filter="FILES" displayName=" resourceSourcePath"/> と同義です。
関連付けられたリソースが deployMode REPLACE のディレクトリリソースである場合、<addResource> は <addFile path="path of deployed directory" displayName="resourceSourcePath"/> と同義です。
これらのどちらでもない場合、関連付けられたリソースはファイルベースのリソースであり、<addResource> は <addFile path="path of deployed file" displayName=" resourceSourcePath"/> に同義である。
<cleanup> 要素は <snapshot> 要素の子であり、ファイルのキャプチャまたは比較が完了したあとで実行される一連の手順を定義します。 これらの手順は、当該スナップショットを対象とする <createSnapshot> または <addSnapshot> 手順の結果として、かつ当該スナップショットを対象とする比較作業として実行されます。 どのような場合も、これらの手順はすべてのファイルのキャプチャまたは比較作業のあとに実行されます。 cleanup ブロックは、一般に、prepare ブロックで作成された一時ファイルを削除するために使用されます。
<cleanup> 要素の子は、1 つ以上の <call>、<execNative>、または <transform> 手順から構成されます。 ほかの手順は許可されません。 包含される手順は、スナップショットブロックで宣言されたローカルパラメタおよびローカル変数と、隠蔽されていない component 置換変数を参照できます。
<controlList> 要素は <component> 要素の子であり、当該コンポーネントで利用できる制御ブロックをリストします。
名前 |
数 |
説明 |
control |
1 つ以上 |
制御ブロックの 1 つ |
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <controlList> 要素コンテンツを継承します。 派生コンポーネントが <controllList> を宣言する場合、そのコンテンツはベースコンポーネントのコンテンツと完全に結合されます。 派生コンポーネントは新しい <control> 要素を宣言することで継承された要素を無効にできますが、ベースコンポーネントによって宣言された要素を削除することはできません。
<control> 要素は <controlList> 要素の子であり、当該コンポーネントで利用できる制御ブロックを定義します。 control ブロックは、当該コンポーネントのインストールが完了したあとで実行できる一連の手順です。 たとえば、データベースアプリケーションのコンポーネントに control ブロックを含め、データベースの「起動」または「停止」を行えます。 <call> 手順は、名前で control ブロックを呼び出すことができます。この呼び出しにより、control ブロック手順が順に実行されます。
名前 |
型 |
必須 |
構成可能 |
説明 |
access |
accessEnum |
いいえ |
不可 |
制御ブロックのアクセスモード (詳細は下記)。 デフォルトは PUBLIC |
modifier |
modifierEnum |
いいえ |
不可 |
制御 ブロックの修飾子 (詳細は下記) |
name |
entityName |
はい |
不可 |
制御ブロックの名前。 これは、制御を実行するために <call> 手順から参照される |
description |
文字列 |
いいえ |
不可 |
制御ブロックの説明 |
<control> 要素の「access」属性は、制御ブロックのアクセス可能性を指定します。
PUBLIC の場合、アクセスはまったく制限されません。
PROTECTED の場合、アクセスは同じパス内の派生コンポーネントとエンティティに制限されます。
PATH の場合、アクセスは同じパス内のエンティティに制限されます。
PRIVATE の場合、アクセスは当該コンポーネントに制限されます。
直接実行できるのは PUBLIC ブロックだけです。
<control> 要素 の「modifier」属性 は、制御ブロックの優先指定要件を指定します。
ABSTRACT の場合、ブロックに本体を含めることはできません。 本体は、非抽象派生コンポーネントによって指定する必要があります。 制御ブロックを抽象と宣言できるのは、コンポーネントも抽象と宣言されている場合だけです。 抽象ブロックは専用にはできません。 非抽象ブロックの場合、本体を宣言する必要があります。
FINAL の場合、制御ブロックを派生コンポーネントによって無効にすることはできません。
指定しない場合、派生コンポーネントはブロックを無効にするかどうかを選択できます。
<control> 要素の子は、オプションの <paramList> 要素とそれに続く本体から構成されます。この本体は、オプションの local <varList> 要素と 、それに続くゼロ個以上の「共通」手順から構成されます。 制御ブロックが抽象と宣言されている場合、本体は含められません。
デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべての制御ブロックを継承します。 制御ブロックを優先する意味論は、インストールブロックを優先する意味論と同じです。
<diff> 要素は <component> 要素の子であり、当該コンポーネントから派生したコンポーネントで比較を実行する際に差分エンジンによって使用される命令のリストを含みます。
名前 |
数 |
説明 |
ignore |
1 つ以上 |
比較の際に無視するディレクトリパス |
派生コンポーネントは、ベースコンポーネントによって宣言されたすべての差異無視命令を自動的に継承します。 また、それ自体の <diff> 要素内で無視命令をさらに宣言することもできます。 継承された命令を削除することはできません。
<ignore> 要素は <diff> 要素の子であり、比較で当該コンポーネントを使用する場合に無視するファイル名パスのパターンを指定します。 この要素は、一般に、インストールされたアプリケーションによって作成されるファイルとディレクトリ (ログファイルなど) に使用されます。 この要素の構成可能属性は、component 置換変数を参照できます。
名前 |
型 |
必須 |
構成可能 |
説明 |
path |
文字列 |
はい |
可能 |
無視するファイル名パスに一致する Glob スタイルのパターン。 例: "/logs/*.log” |
この節では、特定のインストール済みコンポーネントを包含手順 (制御サービスコールなど) の対象として特定する要素を示します。 対象となるすべての手順ですべてのターゲッターを使用できるわけではありません。 各ターゲッターは、それ自体が使用できる手順を指定します。 次の表は、対象となる各種の手順で使用できるターゲッターの概要を示しています。
ターゲッター |
アンインストール |
呼び出し |
依存性チェック |
依存性の作成 |
スナップショットの追加 |
---|---|---|---|---|---|
installedComponent |
はい |
はい |
はい |
はい |
はい |
systemService |
はい |
はい |
はい |
はい |
はい |
systemType |
はい |
はい |
はい |
はい |
はい |
thisComponent 1 |
はい |
はい |
なし |
なし |
はい |
superComponent 1 |
はい |
はい |
なし |
なし |
はい |
nestedRef 2 |
はい |
はい |
はい |
なし |
はい |
allNestedRefs 2 |
はい |
はい |
なし |
なし |
はい |
toplevelRef 2 |
はい |
はい |
はい |
はい |
はい |
dependee 1 |
はい |
はい |
なし |
なし |
はい |
allDependants 1 |
はい |
はい |
なし |
なし |
はい |
1 コンポーネント内に出現する手順にしか使用できません。
2 複合コンポーネント内に出現する手順にしか使用できません。
<systemService> 要素は、<checkDependency>、<createDependency>、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 <systemService> 要素は、現在の物理ホストにインストールされていると想定される特定のシステムサービスコンポーネントを特定します。
<systemService> ターゲッターを使用すると、暗黙に現在のホストのルート物理ホストに対象が変更されます。 別のホスト上のシステムサービスを対象とする必要がある場合は、<retarget> 手順を使用する必要があります。 この手順を使用しないかぎり、<systemService> ターゲッター内で新しいホストを指定することはできません。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
entityName |
はい |
不可 |
インストール済みコンポーネントの名前 |
path |
pathReference |
いいえ |
不可 |
コンポーネントのパス。 指定しないと、包含するエンティティのパスが使用される |
version |
version |
いいえ |
不可 |
インストール済みコンポーネントのバージョン。 指定しないと、任意のバージョンのもっとも新しいインストール済みコンポーネントが使用される |
versionOp |
次の 1 つ: "=” ">=” ">” |
いいえ |
不可 |
version 属性を対象ホスト上にインストールされたコンポーネントのバージョンと比較する際に使用する演算子を指定する。 該当するインストール済みコンポーネントが複数存在する場合、最新のインストール済みコンポーネントが使用される。 指定しないと、デフォルトで ">=" が使用される。 version を指定しないと無視される |
only Compat |
ブール型 |
いいえ |
不可 |
true の場合、指定されたバージョンを持つコンポーネントと呼び出し互換性のあるコンポーネントだけを照合する必要があることを示す。 true の場合、指定されたバージョンのコンポーネントが存在しなければならない。 指定しないと、デフォルトで「false」が使用される。 バージョンを指定しないと無視される |
installPath |
文字列 |
いいえ |
可能 |
インストール済みコンポーネントのインストールパス。 指定しないと、任意のパスの一番新しいインストール済みコンポーネントが使用される。 この値は、コンポーネントの解決処理の前に共通書式に変換される |
host |
文字列 |
いいえ |
可能 |
コンポーネントがインストールされているホスト。 デフォルトは現在のホスト。 詳細は、<retarget> 手順の host 属性を参照 |
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
systemName |
はい |
不可 |
システムサービスコンポーネントの名前 |
<systemType> 要素は、<checkDependency>、<createDependency>、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、対象ホスト上にインストールされていると想定される特定の型のインスタンスであるコンポーネントを特定します。 指定した基準に複数のインストール済みコンポーネントが一致する場合、一番最近インストールされたコンポーネントが使用されます。
<installedComponent> 要素は、<checkDependency>、<createDependency>、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、対象ホスト上にインストールされていると想定される特定のインストール済みコンポーネントインスタンスを特定します。
このターゲッターは指定されたコンポーネントを直接照合するもので、指定されたコンポーネントの派生インスタンスの照合には使用できません。 特定の型から派生したコンポーネントを対象とする場合は、<systemType> ターゲッターを使用してください。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
systemName |
はい |
不可 |
システム型コンポーネントの名前 |
installPath |
文字列 |
いいえ |
可能 |
希望するコンポーネントのインストールパス。 この値は、コンポーネントの解決処理の前に共通書式に変換される |
host |
文字列 |
いいえ |
可能 |
コンポーネントがインストールされているホスト。 デフォルトは現在のホスト。 詳細は、<retarget> 手順の host 属性を参照 |
<thisComponent> 要素は、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、手順を含むコンポーネントを手順の対象として使用する必要があることを指定します。 このターゲッターを使用できるのは、コンポーネント内に含まれる手順だけです。 この要素に属性はありません。
リストされた手順にコンポーネントターゲッター要素が含まれない場合、デフォルトで <thisComponent> が使用されます。
<superComponent> 要素は、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、手順を含むコンポーネントのベースコンポーネントを手順の対象として使用する必要があることを示します。 このターゲッターを使用できるのは、派生コンポーネント内に含まれる手順だけです。 この要素に属性はありません。
このターゲッターは、派生コンポーネントが無効にする場合でも、常にベースコンポーネントによる該当手順の定義にバインドします。
<nestedRef> 要素は、<checkDependency>、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、現在の複合コンポーネントによって宣言または継承が行われた、入れ子になったコンポーネント参照を特定します。 このターゲッターを使用できるのは、複合コンポーネント内の手順だけです。
この際、指定されたコンポーネント参照が呼び出し側コンポーネントによってすでにインストールされていると想定され、インストールされていない場合はエラーが生成されます。 入れ子になったコンポーネント参照が現在の対象ホスト以外のホストにインストールされた場合は、<nestedRef> ターゲッターを使用することで関連付けられている手順の対象がそのホストに暗黙に変更されます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
identifier |
はい |
不可 |
当該コンポーネント内の入れ子になったコンポーネント参照の名前 |
<allNestedRefs> 要素は、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、現在の複合コンポーネントによって宣言または継承が行われた、入れ子になったコンポーネント参照をすべて特定します。 このターゲッターを使用できるのは、複合コンポーネント内の手順だけです。
このターゲッターは、任意の数のコンポーネントを特定できるという意味で特殊です。 コンポーネントがまったく特定されない場合、手順はノーオペレーション (空命令) となります。 このターゲッターが複数のコンポーネントを特定する場合、特定されるコンポーネントごとに <nestedRef> ターゲッターを使用する個別の手順が存在するかのように、手順が意味的に展開されます。 手順は同時にではなく連続的に実行され、手順の順序は手順型に応じて変化します (詳細は後述)。 コンポーネントの 1 つに対して手順を実行しエラーが生じる場合は、その手順は一致するほかのコンポーネントに対しては実行されません。
<call> または <addSnapshot> 手順のターゲッターとして使用される場合、ターゲッターは当該コンポーネントによって現在インストールされている、入れ子になったすべてのコンポーネント参照をインストールの順に照合します。
<uninstall> 手順のターゲッターとして使用される場合、ターゲッターは当該コンポーネントによって現在インストールされている、入れ子になったすべてのコンポーネント参照をインストールの逆順に照合します。
<toplevelRef> 要素は、<checkDependency>、<createDependency>、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、現在の複合コンポーネントによって宣言または継承が行われた最上位のコンポーネント参照を特定します。 このターゲッターを使用できるのは、複合コンポーネント内の手順だけです。
このターゲッターは、「name」、「path」、および「version」属性が参照先コンポーネントに基づいて事前定義されることを除き、意味的に <installedComponent> ターゲッターと同じです。
<dependee> 要素は、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、呼び出し側コンポーネントによってその依存性 (<createDependency> で作成される) が宣言されたインストール済みコンポーネントを特定します。 このターゲッターを使用できるのは、コンポーネント内の手順だけです。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
Identifier |
はい |
不可 |
当該コンポーネントによって作成される依存性の名前 |
<allDependants> 要素は、<call>、<uninstall>、および <addSnapshot> 手順のターゲッターとして使用できます。 この要素は、呼び出し側コンポーネントに対して依存性 (<createDependency> で作成) を宣言してあるインストール済みコンポーネントを特定します。 このターゲッターを使用できるのは、コンポーネント内の手順だけです。
このターゲッターは、包含する手順を、一致するすべてのコンポーネントにマップさせるという点で addNestedRefsターゲッターと似た機能を持ちます。 依存コンポーネントに対するマップの順序は指定されません。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
Identifier |
はい |
不可 |
ほかのコンポーネントによって当該コンポーネントに対して作成される依存性の名前 |
この節では、マスターサーバーリポジトリに包含手順 (install など) の対象として存在する特定のコンポーネントを指定する要素を示します。 対象となるすべての手順ですべてのターゲッターを使用できるわけではありません。 各ターゲッターは、それ自体が使用できる手順を指定します。 次の表は、対象となる各種の手順で使用できるリポジトリターゲッターの概要を示しています。
ターゲッター |
インストール |
---|---|
component 1 |
可 |
thisComponent 2 |
可 |
superComponent 2 |
可 |
nestedRef 3 |
可 |
allNestedRefs 3 |
可 |
toplevelRef 3 |
可 |
1 は、単純プランで出現する手順にしか使用できません。2 は、コンポーネント内に出現する手順にしか使用できません。3 は、複合コンポーネントに出現する手順にしか使用できません。
<component> 要素は、<install> 手順のターゲッターとして使用できます。 この要素は、CR リポジトリに存在すると想定される特定のコンポーネントを特定します。 このターゲッターを使用できるのは、単純プラン内に含まれる手順だけです。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
entityName |
はい |
不可 |
コンポーネントの名前 |
path |
pathReference |
いいえ |
不可 |
コンポーネントのパス。 指定しないと、包含するエンティティのパスが使用される |
version |
version |
いいえ |
不可 |
コンポーネントのバージョン。 指定しないと、最新のコンポーネントが使用される |
host |
文字列 |
いいえ |
可能 |
コンポーネントをインストールすべきホスト。 デフォルトは現在のホスト。 詳細は、<retarget> 手順の host 属性を参照 |
<thisComponent> 要素は、<install> 手順のターゲッターとして使用できます。 この要素は、手順を含むコンポーネントを手順の対象として使用する必要があることを指定します。 このターゲッターを使用できるのは、コンポーネント内に含まれる手順だけです。 この要素に属性はありません。
リストされた手順にコンポーネントターゲッター要素が含まれない場合、デフォルトで <thisComponent> が使用されます。
<superComponent> 要素は、<install> 手順のターゲッターとして使用できます。 この要素は、手順を含むコンポーネントのベースコンポーネントを手順の対象として使用する必要があることを示します。 このターゲッターを使用できるのは、派生コンポーネント内に含まれる手順だけです。 この要素に属性はありません。
このターゲッターは、派生コンポーネントが無効にする場合でも、常にベースコンポーネントによる該当手順の定義にバインドします。
<nestedRef> 要素は、<install> 手順のターゲッターとして使用できます。 この要素は、現在の複合コンポーネントによって宣言または継承が行われた、入れ子になったコンポーネント参照を特定します。 このターゲッターを使用できるのは、複合コンポーネント内の手順だけです。
この際、指定されたコンポーネント参照が呼び出し側コンポーネントによってまだインストールされていないと想定され、インストールされている場合はエラーが生成されます。 入れ子になった参照先コンポーネントが別のホストにインストールされる場合は、<retarget> 手順を使用する必要があります。 この手順を使用しないかぎり、<nestedRef> ターゲッター内で新しいホストを指定することはできません。 特定の包含コンポーネントについて、入れ子になったコンポーネント参照を複数のホストにインストールすることはできません。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
Identifier |
はい |
不可 |
当該コンポーネント内の入れ子になったコンポーネント参照の名前 |
<allNestedRefs> 要素は、<install> 手順のターゲッターとして使用できます。 この要素は、現在の複合コンポーネントによって宣言または継承が行われた、入れ子になったコンポーネント参照をすべて特定します。 このターゲッターを使用できるのは、複合コンポーネント内の手順だけです。
このターゲッターは、任意の数のコンポーネントを特定できるという意味で特殊です。 コンポーネントがまったく特定されない場合、手順はノーオペレーション (空命令) となります。 このターゲッターが複数のコンポーネントを特定する場合、特定されるコンポーネントごとに <nestedRef> ターゲッターを使用する個別の手順が存在するかのように、手順が意味的に展開されます。 手順は同時にではなく連続的に実行され、手順の順序は手順型に応じて変化します (詳細は後述)。 コンポーネントの 1 つに対して手順を実行しエラーが生じる場合は、その手順は一致するほかのコンポーネントに対しては実行されません。
<install> 手順のターゲッターとして使用される場合、ターゲッターは当該コンポーネントによって宣言されている、入れ子になったすべてのコンポーネント参照をその宣言順に照合します。
<toplevelRef> 要素は、<install> 手順のターゲッターとして使用できます。 この要素は、現在の複合コンポーネントによって宣言または継承が行われた最上位のコンポーネント参照を特定します。 このターゲッターを使用できるのは、複合コンポーネント内の手順だけです。
このターゲッターは、「name」、「path」、および「version」属性が参照先コンポーネントに基づいて事前定義されることを除き、意味的に <component> ターゲッターと同じです。 最上位コンポーネント参照は、任意の数のホストに任意の回数だけインストールできます。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
Identifier |
はい |
不可 |
当該コンポーネント内の最上位コンポーネント参照の名前 |
host |
文字列 |
いいえ |
可能 |
参照先コンポーネントがインストールされるホスト。 デフォルトは現在のホスト。 詳細は、<retarget> 手順の host 属性を参照 |
この節では、コンポーネント (単純コンポーネントまたは複合コンポーネント) のインストールブロック内でしか使用できない手順を示します。
これは、ほかのコンポーネントに対する現在のコンポーネントの永続的な依存性を作成するために使用される手順です。 この手順は、その実行時にまず指定された基準に一致するインストール済みコンポーネントが存在しないかチェックし、そのようなコンポーネントが存在しない場合は停止します (この動作は <checkDependency> 手順に同じ)。 一致するコンポーネントが見つかると、一致したコンポーネント (dependee、依存先コンポーネント) と呼び出しコンポーネント (dependant、依存元コンポーネント) 間に永続的な依存性が作成されます。 複数のインストール済みコンポーネントが基準に一致する場合 (インストールパスを指定しないとこのような状況となり得る) は、最新のものが依存先として使用されます。 永続的なコンポーネントは、手順で指定される名前で作成されます。 この名前は、インストールブロックで作成されるすべての依存性間で一意のものでなければなりません。
作成された永続的な依存性は、依存コンポーネントがアンインストールされるまで持続します。 永続的な依存性を作成したあとで後続の手順で依存コンポーネントのインストールが停止する場合、依存性はこの停止時にただちに削除されます。
個々のコンポーネントは、<createDependency> 手順をほかのコンポーネントごとに実行することにより任意の数のコンポーネントに依存できます。 依存性が満たされない場合に実際の処理を行う前にインストールが停止するように、createDependency 手順をインストールブロックの最初の手順として指定することを推奨します (必須ではありません)。
名前 |
型 |
必須 |
構成可能 |
説明 |
---|---|---|---|---|
name |
Identifier |
はい |
不可 |
作成する依存性の名前。 これは、現在のコンポーネントによって作成されるすべての依存性の間で一意のものでなければならない |
名前 |
数 |
説明 |
installed component targeter |
1 |
依存先コンポーネント (dependee) を特定する |
コンポーネントのアンインストールは、そのコンポーネントに対して依存するインストール済みコンポーネントが存在する場合行えません。 コンポーネントのアンインストールブロックが検出された場合で、そのコンポーネントを依存先とする 1 つ以上の永続的な依存性が存在するときは、アンインストールはただちに停止します。 しかし、コンポーネント A によってコンポーネント B のアンインストールが進行している場合、A によって作成された B に対する依存性が B のアンインストールを防止することはなく、この依存性は B が正常にアンインストールされた時点で暗黙に削除されます。
依存先コンポーネントは、<dependantCleanup> ブロックを使用してその依存元 (dependant) をアンインストールするアクションを指定できます。
同じホストとインストールパス上にインストールされた同じバージョンツリー内に既存コンポーネントが検出される場合、コンポーネントインストールは、再インストールと見なされます。 コンポーネントの再インストールが行えるのは、その新しいコンポーネントが本来のコンポーネントのすべての依存元に適合する場合だけです。 コンポーネントは常に同じバージョンコンポーネントで再インストールできますが、異なるバージョンで再インストールができるのは永続的なコンポーネントを作成した <createDependency> 手順内で指定された制約に新しいバージョンも適合する場合だけです。
コンポーネントの単純インストールブロックが検出される場合は、インストールによって既存のインストールが上書きされるか確認する必要があります。 上書きされる場合は、既存のコンポーネントを依存先としている永続的な依存性をすべて検出し、インストールされる新しいコンポーネントについても依存性の制約が適合するかを検証し直します。 適合しないものがある場合、新しいコンポーネントのインストールは失敗し、本来のコンポーネントがインストールされたままとなります。 すべて適合する場合、新しいコンポーネントがそのインストールを正常に完了した時点で、当該コンポーネントがすべての永続的な依存性の新しい依存先となります。 新しいコンポーネントのインストールが正常に完了した時点で本来のコンポーネントはアンインストールされると見なされ、そのコンポーネントの依存元であったすべての永続的な依存関係が削除されます。 つまり、新しいコンポーネントは必要に応じて依存性を作成し直す必要があります。
依存性の名前は、慣例的に「xxx2yyy」という表記で付けられます。xxx は依存元コンポーネントの名前、yyy は依存先コンポーネントの名前を示します。 たとえば、管理対象サーバー WebLogic はその管理サーバーに対して「server2domain」という依存性を持ち、その包含クラスタに対して「server2cluster」という依存性を持つ例が考えられます。 この慣例は依存関係の状態を自己記録として表現するのに便利であり、特定のコンポーネントの依存先関係と依存元関係の両方を示すことができます。
これは、インストール中のコンポーネントの現在のインストール状態のスナップショットを作成するための手順です。 インストールブロックには、任意の数の <createSnapshot> 手順を含めることができます。
createSnapshot 手順は引数の引き渡しをサポートしないため、必要なパラメタを指定されたスナップショットブロックで宣言することはできません。 引数の引き渡しがサポートされないのは、この機能をサポートすると生成されたスナップショットに対してあとで比較が行われる際に引数の収集と引き渡しのサポートも必要となるためです。
複合コンポーネントに対して比較が行われる場合には、入れ子になったすべてのコンポーネント参照の再帰的なインストールによって作成されたスナップショットのツリー一式に加えて、そのコンポーネントによって直接作成されたスナップショットもすべて含まれます。 しかし、最上位のコンポーネント参照に関連付けられたスナップショットは考慮されず、必要に応じて <addSnapshot> キャプチャ命令を使用して複合コンポーネントのスナップショット内に明示的に含める必要があります。
また、入れ子になったコンポーネントは相互に依存していることがあり、このような場合にはそれらのコンポーネントがすべてインストールされるまでスナップショットのキャプチャを延期する必要があることにも注意してください。 相互依存の関係にある例として、ディレクトリを配備する入れ子コンポーネントと、そのディレクトリにファイルを配備する入れ子コンポーネントが挙げられます。 このような場合には、包含コンポーネントでインストール中にスナップショットを作成しないように入れ子コンポーネントに指示するパラメタ引き渡しまたは特殊なインストールブロックを使用して入れ子コンポーネントをインストールし、続いて、包含コンポーネントのスナップショットブロックで <addSnapshot> 命令を使用して入れ子コンポーネントの適切なスナップショットを含めることを推奨します。
名前 |
型 |
必須 |
構成可能 |
説明 |
blockName |
entityName |
はい |
不可 |
当該コンポーネント内で実行するスナップショットブロックの名前 |
これは、対象ホストにコンポーネントをインストールするための手順です。 この手順を使用すると、対象コンポーネントの指定されたインストールブロックの手順が実行されます。
この手順の構文は、コンポーネントターゲッターを省略できる (ターゲッターを省略すると <thisComponent> が指定されたと想定される) 点を除き単純プラン <install> 手順で指定する場合と同じです。
コンポーネント内で使用される場合、この手順は同一コンポーネント内のほかの既存インストールブロックの呼び出しにしばしば使用されます。 この場合、一番外側のインストールブロックがその実行を完了するまで、コンポーネントのインストールが完了したとは見なされません。 また、ほかのローカルインストールブロックの呼び出し対象がほかのホストに変更された場合でも、コンポーネントは最初のインストール手順の対象となったホストにインストールされたとしか見なされません。
この手順は、参照先コンポーネントをインストールする目的で複合コンポーネント内でも使用できます。 参照先コンポーネントは、包含コンポーネントのインストール先以外のホストにもインストールできます。 包含コンポーネントのインストールが失敗する場合、この失敗以前にインストールが正常に行われている入れ子になった参照先コンポーネントはすべて、アンインストールブロックを実行することなく暗黙にアンインストールされます。 しかし、失敗以前にインストールが正常に行われた最上位の参照先コンポーネントはインストールされたままとなります。
この節では、単純コンポーネントのインストールブロック内でだけ使用できる手順を示します。
これは、包含コンポーネントのリソースの配備に使用される手順です。 この手順には属性も子要素もありません。
deployMode が ADD_TO であるディレクトリ型リソースは、必要に応じてそれらが包含している各ファイルをコピーし、ディレクトリ構造の維持と新しいディレクトリの作成を行います。 既存のディレクトリの構造とコンテンツは (リソースコンテンツのコピーを除き) 変化しません。 個々のファイルアクセス権と所有権は、適宜更新されます。
deployMode が REPLACE であるディレクトリ型リソースは、配備前に既存ディレクトリが再帰的に削除されることを除き、deployMode ADD_TO と同様に扱われます。
ほかのリソースはすべてコピーされ、続いてアクセス権と所有権が適宜更新されます。 構成可能としてチェックインされたリソースは、コピーされる前に変数置換が行われます。 構成可能リソースは、リソースが宣言されているコンポーネントにアクセス可能な任意の変数を参照できます。
この節では、コンポーネントのアンインストールブロック内でだけ使用できる手順を示します。
これは、対象ホストからコンポーネントをアンインストールするための手順です。 この手順を使用することで、対象コンポーネントの指定されたアンインストールブロックの手順が実行されます。
この手順の構文は、コンポーネントターゲッターを省略できる (ターゲッターを省略すると <thisComponent> が指定されたと想定される) 点を除き単純プラン <uninstall> 手順で指定する場合と同じです。
コンポーネント内においては、この手順は同一コンポーネント内のほかの既存アンインストールブロックの呼び出しにしばしば使用されます。 この場合、一番外側のアンインストールブロックがその実行を完了するまで、コンポーネントのアンインストールが完了したとは見なされません。 また、ほかのローカルアンインストールブロックの呼び出し対象がほかのホストに変更された場合でも、コンポーネントは当初アンインストール手順の対象となったホストからアンインストールされたとしか見なされません。
この手順は、参照先コンポーネントをアンインストールする目的で複合コンポーネント内でも使用できます。 複合コンポーネントがアンインストールされる場合、入れ子になったその参照先コンポーネントのうち明示的にアンインストールされなかったものはすべて、アンインストールブロックを実行することなくシステムによって暗黙にアンインストールされます。 しかし、明示的にアンインストールされなかった最上位の参照先コンポーネントはインストールされたままとなります。
この節では、単純コンポーネントのアンインストールブロック内でだけ使用できる手順を示します。
この手順には属性も子要素もありません。 これは、包含コンポーネントのリソースの削除に使用される手順です。
deployMode が ADD_TO であるディレクトリ型リソースの場合、それらのファイルは削除されますがディレクトリは残ります。 deployMode が REPLACE であるディレクトリ型リソースの場合、ディレクトリ全体が削除されます。
ほかのリソースはどれも単純ファイルとして扱われ、削除されます。
リソースは、当該コンポーネントのインストール時に初めから配備されたかどうかにかかわらず削除されます。 つまり、<deployResource> 手順を含まないインストールブロックを使用して当該コンポーネントがインストールされた場合でも、<undeployResource> 手順によってリソースはコンポーネントによって初めからインストールされていたかのように削除されます。