test

Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド

第 3 章 コンポーネントのスキーマ

この章では、コンポーネントによって使用される XML スキーマについて説明します。内容は次のとおりです。

特に断りのない限り、この章で説明する属性は、コンポーネントスコープの置換変数を参照できません。

XML スキーマアーキテクチャーの概要は、第 1 章「XML スキーマの概要」を参照してください。

<component> 要素の概要

コンポーネントは、<component> 要素で囲まれます。1 つのコンポーネントのバージョンはすべて、同じ名前とパスを持つ必要があります。この要素の属性は、コンポーネントスコープ置換変数を参照できます。

<component> 要素の属性

<component> 要素には次の属性があります。

installPath 属性と limitToHostSet 属性を除き、component 属性は継承されません。

installPath 属性は継承されます。派生コンポーネントによりオーバーライドすることはできません。しかし、ベースコンポーネントはコンポーネント変数を使用してその値を指定でき、これらの変数の値をオーバーライドできます。

ベースコンポーネントが limitToHostSet を指定しなかった場合だけ、limitToHostSet 属性は継承され、派生コンポーネントでオーバーライドできます。

limitToHostSet 値は、ユーザーによって管理される可変のエンティティーを指定します。このため、ホストセットの関係をプラットフォームと同じように考えることはできません。

platform 属性は継承されません。しかし、派生コンポーネントの platform 属性値は、「ベースコンポーネント」の platform 属性値と同様に、一般的ではありません。派生コンポーネントで platform を指定しない場合は、platform はベースコンポーネントで指定できません (または any として指定する必要があります)。

<component> 要素の子要素

<component> 要素には次の子要素があり、記載順で出現する必要があります。これらの子要素は、独自の子要素や属性 (両方も可能) を持つことができます。

<extends> 要素

<extends> 要素は、<component> 要素のオプションの子要素です。このコンポーネントの派生元であるベースコンポーネントの宣言に使用されます。ベースコンポーネントは最終になることはできません。この要素を使用する場合、この要素は 1 回しか出現できません。

このコンポーネントは、ベースコンポーネントの各種の属性と要素を自動的に継承します。コンポーネントは、継承されたデータの特定の部分を選択的にオーバーライドできます。継承とオーバーライドの許可は、属性または要素の説明内で指定します。

コンポーネントは、その拡張コンポーネントのインスタンスと言えます。また、ベースコンポーネントをインスタンスとするコンポーネントのインスタンスでもあります。

<extends> 要素には 1 つの必須子要素 <type> があり、この子要素はベースコンポーネントを指定します。<type> 要素の使用は、<component> 要素ごとに 1 度だけに限定する必要があります。

<type> 要素

<type> 要素は、このコンポーネントのベースコンポーネント型を指定します。この要素は、<extends>、<componentRefList>、および <componentRef> 要素の子要素です。

<type> 要素には systemName 型の 1 つの必須属性 name があり、これはベース型として機能するシステム型コンポーネントの名前です。指定された型がプラグインにより定義された型である場合、pluginName は pluginName#typeName のように、型名に対する接頭辞である必要があります。

<varList> 要素

<varList> 要素は、<component> 要素のオプションの子要素です。この要素は、このコンポーネントとコンポーネントに含まれる構成リソースが使用するコンポーネントスコープの置換変数のリストを宣言します。この要素を使用する場合、この要素は 1 回しか出現できません。

<varList> 要素には 1 つの必須子要素 <var> があり、この子要素はコンポーネント置換変数を宣言します。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <varList> 要素の内容を継承します。派生コンポーネントが <varList> を宣言する場合、その内容はベースコンポーネントの内容と効果的に結合されます。派生コンポーネントは新しい <var> 要素を宣言することで継承された要素をオーバーライドできますが、ベースコンポーネントによって宣言された要素を削除することはできません。

<var> 要素

<var> 要素は、<component> 要素の子要素である <varlist> 要素の子要素です。<var> 要素はコンポーネント置換変数を宣言します。宣言する置換変数ごとに、変数の名前とそのデフォルト値を指定する必要があります。

デフォルトでは、「派生コンポーネント」はそのベースコンポーネントのすべてのアクセス可能変数 (アクセスモード、修飾子、デフォルト値、プロンプトなど) を継承します。<var> 要素は、<varList> 要素内で 1 回または複数回出現できます。

派生コンポーネントは、ベースコンポーネントから継承されている変数に含まれない名前を使用することで、追加の変数を定義できます。派生コンポーネントは、同じ名前を使用して変数を宣言し直すことにより、継承された非最終変数のプロンプト、デフォルト値、修飾子、アクセスモードなどをオーバーライドできます。変数をオーバーライドする場合は、変数の全コンテンツ (プロンプト、デフォルト値、アクセスモード、修飾子など) を宣言し直す必要があります。デフォルト値は、オーバーライドする変数が非抽象変数である場合にのみ指定できます。アクセスモードは、ベースコンポーネントのモードよりも厳しくすることはできません。

変数をオーバーライドすると、ベースコンポーネント内の参照も含め、その変数に対する参照はすべてオーバーライドされた値に評価されます。

派生コンポーネントを非抽象と宣言する場合、ベースコンポーネントによって宣言された抽象変数は派生コンポーネントによってオーバーライドする必要があります。

<var> 要素の属性

<var> 要素には次の属性があります。

<targetRef> 要素

<targetRef> 要素は、<component> 要素のオプションの子要素です。この要素は、コンポーネントがターゲット設定可能であることを宣言します。「ターゲット設定可能コンポーネント」は、コンポーネントと関連付けられる物理ホストまたは仮想ホストを自動的に作成するコンポーネントです。このホストは、コンポーネントがインストールされる際に作成されます。この要素は、使用する際には、<varList> 要素の直後に 1 回だけ出現できます。この要素は、単純コンポーネントと複合コンポーネントの両方で使用できます。ただし、<varList> 要素を使用できるのは、最上位コンポーネントとしてインストールされているコンポーネントだけです。

<targetRef> 要素には <agent> というオプションの子要素が 1 つあり、この子要素は関連付けられたホストが物理ホストと仮想ホストのどちらであるかを示します。<agent> 要素が存在する場合、ホストは物理ホストです。<agent> 要素の本体は、リモートエージェントの構成を定義します。この要素が存在しない場合、ホストは仮想ホストです (これがデフォルト)。

<targetRef> 要素の属性

<targetRef> 要素には次の属性があります。

<agent> 要素

<agent> 要素は、<targetRef> 要素の子要素です。この要素は、関連付けられたホストが物理ホストであることを示します。この要素はオプションで、1 回しか使用できません。

この要素を指定しないと、関連付けられるホストは仮想ホストとして作成されます。この要素を使用する場合、関連付けられるホストは物理ホストとして作成され、<agent> 要素が、関連付けられるリモートエージェントの構成を指定します。

この要素は派生コンポーネントによって継承されます。ベースコンポーネントが宣言を行っていない場合にのみ、派生コンポーネントはローカルな <targetRef> 要素を宣言できます。これは、派生コンポーネントが、継承された <targetRef> 要素をオーバーライドできないことを意味します。

<agent> 要素の属性

<agent> 要素には次の属性があります。これらの属性は、コンポーネントスコープの置換変数を参照できます。

<resourceRef> 要素

<targetRef> 要素は、<component> 要素のオプションの子要素です。コンポーネントによって管理されるリソースを指定します。この要素を使用できるのは単純コンポーネントのみです。この要素は、複合コンポーネントのみが使用できる <componentRefList> 要素とは併用できません。この要素およびその子の構成可能属性は、コンポーネント置換変数を参照できます。リソースは、暗黙の PUBLIC アクセスモードを取ります。この要素を使用する場合、この要素は 1 回しか出現できません。

コンポーネントが単純コンポーネントから派生する場合、あるいは <resourceRef> 要素を含む非派生コンポーネントである場合、そのコンポーネントは単純コンポーネントになります。派生コンポーネントが単純コンポーネントから派生している場合、その派生コンポーネントに含めることができるのは <resourceRef> 要素だけです。

<resourceRef> 要素には子要素があり、それらは次の順序で出現する必要があります。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの <resourceRef> 要素を継承します。

派生コンポーネントは、<resourceRef> 要素を宣言し直すことによって、継承された非最終 <resourceRef> 要素の修飾子と <resource> 要素をオーバーライドできます。<resourceRef> 要素がオーバーライドされる際に、<installSpec> 要素は除外されます。これはその内容をオーバーライドすることができないためです。オーバーライドする <resourceRef> が非抽象要素でない場合にだけ、<resource> 要素を指定します。

<resourceRef> がオーバーライドされる際、ベースコンポーネントでの使用も含め、すべてのリソース (<deployResource> および <addResource> を含む) の使用がオーバーライドされた値に決定されます。

派生コンポーネントが非抽象と宣言された場合で、ベースコンポーネントの <resourceRef> 要素が抽象のとき、その派生コンポーネントは <resourceRef> 要素をオーバーライドする必要があります。

<resourceRef> 要素の属性

<resourceRef> 要素には modifier というオプション属性が 1 つあり、その値は modifierEnum 型です。modifier 属性は次のように、リソースのオーバーライド要件を指定します。

この属性を指定しない場合、派生コンポーネントは <resourceRef> をオーバーライドするかどうかを選択できます。

<installSpec> 要素

<installSpec> 要素は <resourceRef> 要素の子要素です。関連付けられたリソースのインストール方法を指定します。この要素は派生コンポーネントによって継承され、オーバーライドできません。しかし、ベースコンポーネントは <installSpec> 属性の値指定にコンポーネント変数を使用でき、これらの変数の値はオーバーライドできます。

<installSpec> 要素の属性

<installSpec> 要素には次の属性があります。これらの属性は、コンポーネントスコープの置換変数を参照できます。

<resource> 要素

<resource> 要素は <resourceRef> 要素の子要素であり、コンポーネントによって配備されるリソースを特定します。

参照されたリソースが構成可能なリソースである場合、包含コンポーネントにアクセス可能な任意のコンポーネントスコープ変数に対する置換変数参照を含むことができます。

<resource> 要素の属性

<resource> 要素には次の属性があります。

<componentRefList> 要素

<componentRefList> 要素は、<component> 要素のオプションの子です。コンポーネントによって参照されるコンポーネントの一覧を指定します。この要素は、<resourceRef> 要素とは併用できません。この要素およびその子の構成可能属性は、コンポーネント置換変数を参照できます。この要素を使用する場合、この要素は 1 回しか出現できません。

コンポーネントが複合コンポーネントから派生する場合、あるいは <resourceRef> 要素を含まない非派生コンポーネントである場合、そのコンポーネントは「複合コンポーネント」になります。「派生コンポーネント」が複合コンポーネントから派生している場合、その派生コンポーネントに含めることができるのは <componentRefList> 要素だけです。

<componentRefList> 要素には、次のオプションの子要素があります。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの <componentRefList> 要素の内容を継承します。派生コンポーネントで <componentRefList> を宣言すると、その内容がベースコンポーネントの内容と効率よく結合されます。派生コンポーネントは、新しい <componentRef> 要素を宣言することで継承された要素をオーバーライドできます。ベースコンポーネントによって宣言された要素を削除することはできません。

派生コンポーネントは、親コンポーネントの <componentRefList> 要素によって宣言されている <type> 要素をオーバーライドできます。このオーバーライドは、<componentRefList> で <type> を宣言し直すことで行われます。この場合、オーバーライドされる型は、オリジナルの型のインスタンスであるか、あるいはオリジナルの型が指定されている必要があります。さらに、すべての参照先コンポーネント (ベースコンポーネントから継承されるものを含む) はオーバーライドされる型のインスタンスでなければなりません。

<componentRefList> 要素の属性

<componentRefList> 要素には 1 つのオプション属性 modifier があり、これはリ ソースのオーバーライド要件を指定します。この属性を指定する場合、値は FINAL でなければなりませんが、これは派生コンポーネントが新しい <componentRef> 要素を宣言できないことを意味します。

この属性を指定しない場合、派生コンポーネントは新しい <componentRef> 要素を追加できます。どちらの場合も、派生コンポーネントは <type> 要素と非最終継承 <componentRef> 要素をオーバーライドできます。ベースコンポーネントの <componentRefList> modifier 属性が FINAL である場合、派生コンポーネントの modifier 属性も FINAL である必要があります。

<componentRefList> 要素の modifier が FINAL である場合、含まれる各 <componentRef> の modifier 属性は必ずしも FINAL ではありません。

<componentRef> 要素

<componentRef> 要素は <componentRefList> 要素の子要素で、当該コンポーネントによって参照されるコンポーネントを指定します。この要素は、暗黙的に PUBLIC アクセスとなります。

<componentRef> 要素には子要素があり、それらは次の順序で出現する必要があります。

デフォルトでは、派生コンポーネントはそのベースコンポーネントのすべてのコンポーネント参照を継承します。

ベースコンポーネントの <componentRefList> 要素が最終要素でない場合、派生コンポーネントはベースコンポーネントから継承されたコンポーネント参照に使用されていない名前を使用して、別のコンポーネント参照を定義できます。

派生コンポーネントは、同じ名前を持つコンポーネント参照を宣言し直すことにより、非最終継承コンポーネント参照のコンポーネント参照をオーバーライドできます。コンポーネント参照がオーバーライドされた場合には、コンポーネント参照の全内容を宣言し直す必要があります。オーバーライドする installMode は、オリジナルの参照のものと同じでなければなりません。オーバーライドする <type> 要素は、オリジナルの型のインスタンスでなければなりません。オーバーライドする <argList> 要素は、オリジナルのものと結合されます。詳細は、「<argList> 要素」を参照してください。 <component> 要素は、オーバーライドする参照が非抽象の場合にのみ指定されます。

コンポーネント参照をオーバーライドすると、ベースコンポーネント内のものも含め、そのコンポーネント参照の使用はすべてオーバーライド値に評価されます。

派生コンポーネントを非抽象と宣言する場合、ベースコンポーネントによって宣言された抽象的なコンポーネント参照は、派生コンポーネントによってオーバーライドする必要があります。

<componentRef> 要素の属性

<componentRef> 要素には次の属性があります。

<argList> 要素

<argList> 要素は <componentRef> 要素の子要素で、参照先コンポーネントのインストール時に、そのコンポーネント変数設定として使用される値の一覧を指定します。この <argList> の書式は、<call> ステップの <argList> 子要素と同じです。詳細は、「<call> ステップ」を参照してください。

参照が ABSTRACT の場合、<argList> 要素の各属性は、参照先コンポーネントにおけるコンポーネント変数または宣言された型を指定します。<argList> 要素の属性の値はオーバーライド値で、参照先コンポーネントをインストールする際に名前付きコンポーネント変数に使用されます。

コンポーネント参照が派生コンポーネントによってオーバーライドされる場合、ベースコンポーネントおよび派生コンポーネントの <argList> 要素は、効率よく結合されます。この結合は、ベースコンポーネントの <argList> の内容を参照先コンポーネントに適用してから、派生コンポーネントの <argList> を適用することで行われます。ベースコンポーネント参照の <argList> を処理する場合、考慮されるのはベースコンポーネント参照の宣言された型で定義された変数だけです。

<argList> で指定されていないコンポーネント変数は、インストール時にそれらのデフォルト値を使用します。<argList> が指定されていない場合、参照先コンポーネントがインストールされ、またそのすべての変数のデフォルト値を使用します。<argList> で指定される参照先コンポーネントの変数は、参照元コンポーネントからアクセス可能でなければなりません。また、これらの変数はアクセスモード FINAL ではなく、PUBLIC または PROTECTED で宣言されていなければなりません。

最上位の参照先コンポーネントの場合、<argList> 要素が使用されるのは参照先コンポーネントが参照元コンポーネントによってインストールされている場合だけです。参照先コンポーネントは、ほかの方法でインストールされていることもあります。この場合、<argList> は意味を持ちません。

<component> 要素

<component> 要素は <componentRef> 要素の子要素で、参照先コンポーネントを特定します。この要素の構造は、host 属性が許可されない点を除き、<component> リポジトリコンポーネントターゲッターと同じです。参照先コンポーネントバージョンは、包含コンポーネントの保存時にリポジトリ内に存在する必要があります。

version 属性を指定しないと、version は包含コンポーネントの保存時に存在する参照先コンポーネントの最新バージョンに解決されます。参照先コンポーネントのバージョンが存在しない場合、保存時のエラーが発生します。包含コンポーネントが保存されると、コンポーネントが参照するすべてのコンポーネントのバージョンがロックされます。参照先コンポーネントは、コンテナコンポーネントの新しいバージョンを作成しない限り変更できません。

<installList> 要素

<installList> 要素は <component> 要素の子要素であり、1 つ以上の名前付きインストールステップブロックを含みます。各ブロックは、コンポーネントをインストールする個々の方法を提供します。多くのコンポーネントには、<installSteps> 要素の子としてインストールブロックが 1 つだけ存在します (この節で後述)。

この要素は、非派生コンポーネントの場合は必須で、派生コンポーネントの場合はオプションです。この要素を使用する場合、この要素は 1 回しか出現できません。

インストール環境ごとに異なるステップが必要な場合は、複数のインストールブロックを使用できます。たとえば、EJB アプリケーションをサーバークラスタに配備するインストールブロック、単一の管理対象サーバーに配備する別のインストールブロック、最初のインストール用のインストールブロック、およびアプリケーションをアップグレードするインストールブロックを作成できます。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <installList> 要素の内容を継承します。派生コンポーネントが <installList> を宣言する場合、その内容はベースコンポーネントの内容と効果的に結合されます。派生コンポーネントは新しい <installSteps> 要素を宣言することで継承された要素をオーバーライドできますが、ベースコンポーネントによって宣言された要素を削除することはできません。

<installList> 要素には 1 つの子要素 <installSteps> があり、この子要素は、コンポーネントをインストールするために実行されるステップのシーケンスを一覧表示します。<installSteps> 要素は、1 回または複数回出現することができます。

<installSteps> 要素

<installList> 要素には 1 つの子要素 <installSteps> があり、この子要素は、コンポーネントをインストールするために実行されるステップのシーケンスを一覧表示します。<install> ステップによってこのコンポーネントがインストールされる場合、ここに挙げるステップが順に実行されます。一般に、単純コンポーネントのインストールステップには <deployResource> ステップが含まれます。複合コンポーネントのインストールステップには、参照先コンポーネントをインストールするため、1 つ以上の <install> ステップが含まれます。

<installSteps> 要素の子は、オプションの <paramList> 要素から構成され、そのあとには本体が続きます。本体は、オプションのローカル <varList> 要素から構成されます。ローカル <varList> 要素の後ろには、ゼロ以上の「共有」または「コンポーネントインストールのみ」ステップが続きます。インストールブロックが抽象と宣言されている場合、本体は含められません。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべてのインストールブロックを継承します。

派生コンポーネントは、ベースコンポーネントから継承されたインストールブロックに含まれない名前を使用して別のインストールブロックを定義できます。派生コンポーネントは、同じ名前を使用してブロックを宣言し直すことにより、継承した非最終インストールブロックをオーバーライドできます。ブロックの無効化は名前を使用してしか行えず、パラメータに基づいてオーバーロード(多重定義) することはできません。ブロックをオーバーライドする場合は、ブロックの全内容 (アクセスモード、修飾子、およびパラメータ) を宣言し直す必要があります。本体を指定できるのは、優先するブロックが非抽象の場合だけです。アクセスモードは、ベースコンポーネントのモードよりも厳しくすることはできません。

派生コンポーネント内の優先ブロックのシグニチャーは、ベースコンポーネントのシグニチャーと互換性がなければなりません。互換性があるということは、ベースブロックが使用できる引数はすべて派生ブロックでも使用できることを意味します。

派生ブロックがベースブロックと互換性があるのは、必須パラメータを新たに宣言せず、親ブロックでオプションパラメータを必須パラメータとして再定義していない場合です。

以下のシグニチャー変更は互換性があると見なされます。

ブロックをオーバーライドすると、ベースコンポーネント内の参照も含め、そのブロックに対する参照はすべてオーバーライドされた値に評価されます。

派生コンポーネントを非抽象と宣言する場合は、ベースコンポーネントによって宣言されているすべての抽象ブロックを、派生コンポーネントによってオーバーライドする必要があります。

<superComponent> ターゲッターを使用するブロックを派生コンポーネントがオーバーライドする場合でも、派生コンポーネント内のブロックは、ベースコンポーネントによって定義されているブロックを明示的に呼び出すことができます。

<installSteps> 要素の属性

<installSteps> 要素には次の属性があります。

<paramList> 要素

<paramList> 要素は、<installSteps>、<uninstallSteps>、<snapshot>、および <control> 要素の子要素です。この要素は、包含要素のステップで使用できるパラメータの一覧を宣言します。パラメータの値は、呼び出し側の <argList> 要素の内容に基づいて呼び出し側によって定義されます。たとえば、<installSteps> ブロック内の <paramList> の場合、パラメータ値は <installSteps> ブロックを呼び出した <install> ステップの <argList> に基づいて定義されます。

包含要素のステップは、次の変数とパラメータを使用できます。

<paramList> パラメータの名前がコンポーネント <varList> 変数と同じ場合は、パラメータの値が使用されます。このような場合、パラメータはコンポーネント変数を「隠蔽」していると言われます。隠蔽は、ローカル変数とパラメータの間では許可されません。これは、それらの名前が個別のものでなければならないためです。

<paramList> 要素には 1 つの必須子要素 <param> があります。この子要素はパラメータ宣言で、名前とデフォルト値が含まれます。定義するパラメータごとに、1 つの<param> 要素を指定します。

<param> 要素

<param> 要素は <paramList> 要素の子要素で、(名前、デフォルト値が含まれる) パラメータを宣言します。デフォルト値が使用されるのは、呼び出し側がこのパラメータの値を明示的に渡さない場合だけです。デフォルト値が指定されず、呼び出し側がこのパラメータの値を明示的に渡さない場合、プランの実行時にプリフライトエラーが発生します。

<param> 要素には次の属性が含まれます。包含しているインストールブロック、アンインストールブロック、または制御ブロックが、プランまたはほかのコンポーネントからではなくユーザーによって直接呼び出される場合に、prompt 属性および displayMode 属性を使用します。

ローカル <varList> 要素

ローカル <varList> 要素は <installSteps>、<uninstallSteps>、<snapshot>、および <control> 要素の子要素です。この要素は、包含要素のステップで使用できる変数の一覧を宣言します。これらの変数の値は宣言時に定義され、再定義は行えません。

包含要素のステップは、次の変数とパラメータを使用できます。

ローカル <varList> 変数の名前がコンポーネント <varList> 変数と同じ場合は、ローカル変数の値が使用されます。このような場合、ローカル変数はコンポーネント変数を「隠蔽」していると言われます。隠蔽は、ローカル変数とパラメータの間では許可されません。これは、それらの名前が個別のものでなければならないためです。

ローカル <varList> 要素には <var> という必須の子要素が 1 つあり、名前およびデフォルト値を含んだローカル変数宣言になっています。複数の <var> 要素を指定できます。

ローカル <var> 要素

ローカル <var> 要素は、ローカル <varList> 要素の必須子要素で、ローカル変数名とその値を宣言するために使用されます。

ローカル <var> 要素には次の属性があります。

<uninstallList> 要素

<uninstallList> 要素は <component> 要素の子要素です。この要素は1 つ以上の名前付き <uninstall> ステップブロックを含み、各ブロックは、コンポーネントをアンインストールする個々の方法を提供します。多くのコンポーネントには、この要素の子としてアンインストールブロックが 1 つだけ存在します。インストール環境ごとに異なるステップが必要な場合は、複数のアンインストールブロックを使用できます。

たとえば、EJB アプリケーションの配備をサーバークラスタから解除するアンインストールブロックや、単一の管理対象サーバーから解除するアンインストールブロックなどが作成できます。アンインストールブロックは、インストールブロックと一対一で対応していることが少なくありません。このような場合には、慣習上同じ名前を使用して対応を示してください。

この要素は、非派生コンポーネントの場合は必須で、派生コンポーネントの場合はオプションです。この要素を使用する場合、この要素は 1 回しか出現できません。

<uninstallList> 要素には、<uninstallSteps> という必須の子要素 1 つがあります。この子要素は、コンポーネントをアンインストールするために実行できるステップを含む、名前付きのアンインストールブロックです。コンポーネントをアンインストールする方法ごとに、<uninstallSteps> 要素を 1 つ指定します。

デフォルトでは、派生コンポーネントはベースコンポーネントのアクセス可能な <uninstallList> 要素の内容を継承します。派生コンポーネントが <uninstallList> を宣言する場合、その内容はベースコンポーネントの内容と効果的に結合されます。派生コンポーネントは新しい <uninstallSteps> 要素を宣言することで継承された要素をオーバーライドできますが、ベースコンポーネントによって宣言された要素を削除することはできません。

<uninstallSteps> 要素

<uninstallSteps> 要素は <uninstallList> 要素の子要素であり、コンポーネントをアンインストールするために実行される一連のステップを示します。<uninstall> ステップによってこのコンポーネントがアンインストールされる場合、この要素に挙げられるステップが順に実行されます。単純コンポーネントの <uninstallSteps> 要素は <undeployResource> ステップを含むことが許可されますが、これは必須ではありません。複合コンポーネントの <uninstallSteps> 要素には、参照先コンポーネントをアンインストールする 1 つ以上の <uninstall> ステップを含むことが許可されますが、これは必須ではありません。

<uninstallSteps> 要素の子は、オプションの <paramList> 要素から構成され、そのあとに本体が続きます。本体は、オプションの <dependantCleanup> ブロックに続く、オプションのローカル <varList> 要素から構成されます。このブロックの後ろには、ゼロ以上の「共有」または「コンポーネントアンインストールのみ」ステップがあります。アンインストールブロックが抽象と宣言されている場合、本体は含められません。

次の例に、サンプル <uninstallSteps> 要素の内容を示します。</paramList> 以降が本体を定義しています。

<uninstallSteps name="default">
  <paramList>
     <param name="param1"/>
   </paramList>
  <varList>
    <var name="var1" default="my var 1"/>
  </varList>
  <dependantCleanup>
    <uninstall blockName="default">
        <allDependants name="child2parent"/>
    </unisntall>
  </dependantCleanup>
  <undeployResource/>
</uninstallSteps>

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべてのアンインストールブロックを継承します。アンインストールブロックをオーバーライドするセマンティクスは、インストールブロックをオーバーライドするセマンティクスと同じです。

<uninstallSteps> 要素の属性

<uninstallSteps> 要素には次の属性があります。

<dependantCleanup> 要素

<dependantCleanup> 要素は <uninstallSteps> 要素の子要素です。<dependantCleanup> 要素は、呼び出し側コンポーネントに現在依存しているコンポーネントを削除するために実行される一連のステップを指定します。この要素に属性はなく、包含するアンインストールブロックのスコープ内で許可される任意の数のステップを含むことができます。

この要素を含めると、依存コンポーネントのチェックはブロックの内容の実行が完了するまで延期されます。ブロックの実行が完了したあとも依存コンポーネントが存在する場合は、アンインストールが失敗し、コンポーネントはインストールされたままとなります。依存コンポーネントが残っていない場合、アンインストールが継続されて残りのステップが行われます。

包含コンポーネントがターゲット設定可能である場合、ブロックを使用して、ホストを対象とする関連付けられたコンポーネントにインストールされたコンポーネントを削除できます。このブロックが完了したあとも、関連付けられているホスト上にインストール済みコンポーネントが残っている場合、アンインストールは失敗します。

アンインストールブロックに <dependantCleanup> ブロックを含めないと、依存コンポーネントが存在する場合、アンインストールブロックはただちに停止します。

<dependantCleanup> ブロックは、依存コンポーネントをまとめてアンインストールする目的で、<allDependants> ターゲッターと併用されることがよくあります。

<snapshotList> 要素

<snapshotList> 要素は、<component> 要素のオプションの子要素です。この要素には、1 つ以上の名前付きスナップショットブロックが含まれます。各ブロックは、ターゲットホスト上におけるこのコンポーネントのインストール状態をキャプチャーする個別の方法を提供します。複数のスナップショットブロックを使用してインストール状態のさまざまな情報をキャプチャーできるため、キャプチャーされたインストール状態とコンポーネントの現在の状態を詳しく比較できます。この要素を使用する場合、この要素は 1 回しか出現できません。

この要素には 1 つの必須子要素 <snapshot> があります。これはこのコンポーネントのインストール状態をキャプチャーするために実行できる名前付きスナップショットブロックです。1 つ以上の <snapshot> 要素を使用できます。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <snapshotList> 要素の内容を継承します。派生コンポーネントが <snapshotList> を宣言する場合、その内容はベースコンポーネントの内容と効果的に結合されます。派生コンポーネントは新しい <snapshot> 要素を宣言することで継承された要素をオーバーライドできますが、ベースコンポーネントによって宣言された要素を削除することはできません。

<snapshot> 要素

<snapshot> 要素は <snapshotList> 要素の子要素で、このコンポーネントのインストール状態をキャプチャーするために実行される一連のステップを定義します。<createSnapshot> または <addSnapshot> ステップでこの snapshot ブロックの名前が指定されると、prepare ブロック内のステップが順に実行されます。続いて capture ブロックで指定されたファイルターゲットサーバーのキャプチャー領域でキャプチャーされ、最後に cleanup ブロック内のステップが順に実行されます。

スナップショットブロックは、コンポーネントの現在の状態をそのインストール時の状態と比較するためにも使用されます。具体的には、ターゲットサーバーで prepare ステップが再実行され、続いてインストール時にキャプチャーされたファイルが現在のファイル状態と比較され、cleanup ステップが再実行されます。

<snapshot> 要素には次の子要素があります。

このスナップショットが <createSnapshot> ステップから呼び出される場合は、必要なパラメータをその <paramList> 要素で宣言することはできません。

<varList>、<prepare>、<capture>、および <cleanup> 要素は、集合的にスナップショットの本体を定義します。スナップショットブロックが抽象と宣言される場合、本体は含められません。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべてのスナップショットブロックを継承します。スナップショットブロックをオーバーライドするセマンティクスは、インストールブロックをオーバーライドするセマンティクスと同じです。

派生コンポーネントスナップショットブロックの prepare ブロックからベースコンポーネントスナップショットブロックの prepare ブロックを呼び出す方法はありません。同じことが cleanup についても言えます。この種の呼び出しを行うには、ベースコンポーネントがその <prepare> および <cleanup> ステップを、派生コンポーネントから呼び出し可能な制御ブロックに分解する必要があります。

<snapshot> 要素の属性

この要素には次の属性があります。

<prepare> 要素

<prepare> 要素は <snapshot> 要素の子要素で、ファイルのキャプチャーまたは比較に備えた一連のステップを定義します。これらのステップは、このスナップショットを対象とする <createSnapshot> または <addSnapshot> ステップと、このスナップショットを対象として実行される比較の両方の結果として実行されます。どのような場合も、これらのステップはファイルのキャプチャーまたは比較作業に先立って実行されます。

<prepare> 要素の子は、1 つ以上の <call>、<execNative>、および <transform> ステップから構成されます。ほかのステップは許可されません。包含されるステップは、スナップショットブロックで宣言されたローカルパラメータおよびローカル変数と、隠蔽されていない component 置換変数を参照できます。

<capture> 要素

<capture> 要素は、このスナップショットの一部としてキャプチャーされるファイルとリソースを定義します。キャプチャーは、<prepare> ブロック内のステップが実行されたあとでしか行われません。キャプチャーが完了すると、<cleanup> ブロック内のステップが実行されます。

<capture> 要素の子は、1 つ以上の <addFile>、<addSnapshot>、および <addResource> 要素から構成されます。このブロックに挙げられるファイルとディレクトリは、指定された順にキャプチャーされます。包含される子は、スナップショットブロックで宣言されたローカルパラメータおよびローカル変数と、隠蔽されていない component 置換変数を参照できます。

<addFile> 要素

<addFile> 要素は <capture> 要素の子要素であり、包含するスナップショットの一部としてキャプチャーされるファイルを指定します。

<addFile> 要素の属性

<addFile> 要素には次の属性が含まれます。

  • path – 必須属性で、ターゲットホストのファイルシステム上のファイルまたはディレクトリのパス名を指定します。この属性は、単純置換変数を参照できます。

  • ownership – オプション属性で、キャプチャーされたファイルの所有権オプションを指定します。

    スナップショットによってキャプチャーされるインストール状態の情報の 1 つに、ファイルおよびディレクトリの所有権があります。この所有権は UNIX のアクセス許可と同じではありません。所有権は、参照カウントの概念により近いと言えます。具体的には、ファイルまたはディレクトリは、1 つ以上のスナップショットによって所有されているものとしてキャプチャーできます。

    ほかのコンポーネントのインストールにより、ファイルの所有者が変更された場合、そのファイルがその初期状態と比較されたときに、この変更が認識され報告されます。この機能により、あるコンポーネントが、別のコンポーネントに関連付けられているファイルを誤って上書きしたために生じた差異を追跡することができます。スナップショットの所有権情報は、所有者テーブルと呼ばれる、ターゲットホスト上のリポジトリ内にキャプチャーされます。

    ownership 属性の値は以下のセマンティクスを持ちます。

    • SET_SELF – ownership 値がこの値に設定された場合、所有者テーブルは関連付けられたファイルまたはディレクトリ用の単一のエントリを含むように更新されます。そのエントリは、実行するインストール済みコンポーネントとスナップショットを所有者としてリストします。また、キャプチャーされたファイルの内容またはディレクトリの内容のキャプチャー領域 ID もリストします。

    • ADD_SELF – ownership がこの値に設定された場合、インストール済みコンポーネントとスナップショットが付加的な所有者として追加され、以前の所有者として既存のキャプチャー領域 ID を共有します。

    • ADD_TEMP – この値は ADD_SELF と似ていますが、新しいキャプチャーが常に作成されてその ID が常に新しいエントリに使用されます (ほかの所有者の ID を共有することはありません)。

    この属性を指定しない場合、デフォルト値は SET_SELF です。

  • filter – boolean 型のオプション属性で、ファイルまたはディレクトリ、あるいはその両方をキャプチャーすべきかを示します。

    path の値がディレクトリである場合、この属性は、ディレクトリ自体、そのディレクトリに含まれるファイル、またはその両方をキャプチャーすべきかを示すために使用されます。path の値がディレクトリでない場合、この属性は無視され、ファイルが直接キャプチャーされます。この属性を指定しない場合、デフォルトの BOTH が使用されます。

    この属性の値には次のものがあります。

    • DIRECTORIES

    • FILES

    • BOTH

  • recursive – オプション属性で、現在のフィルタ設定を使用してサブディレクトリを再帰的にキャプチャーすべきかどうかを示します。

    path の値がディレクトリである場合、この属性は、現在のフィルタ設定を使用してサブディレクトリを再帰的にキャプチャーすべきかどうかを示します。path の値がディレクトリでない場合、この属性は無視され、ファイルが直接キャプチャーされます。デフォルト値は true です。

  • displayName – オプション属性で、このスナップショットエントリがほかのエントリと比較される際に表示に含めるテキスト。

    この属性は、単純置換変数を参照できます。

<addSnapshot> 要素

<addSnapshot> 要素は、外部スナップショットブロックを実行する必要があること、およびその内容をこのスナップショットに追加すべきであることを示します。

<addSnapshot> ステップを使用することは、次のシナリオのすべてと意味的に同じです。

呼び出される側および呼び出し側のスナップショットブロックによって参照されるファイルが重複しないように注意する必要があります。

<capture> 要素には、任意の数の <addSnapshot> ステップを含めることができます。呼び出される側のスナップショット自体には、その <capture> 要素内に任意の数の <addSnapshot> ステップを含められます。

<addSnapshot> コールアウトを使用してファイルをスナップショットに間接的に追加する場合、スナップショットのキャプチャーを開始した最上位のコンポーネントは (<addFile> 命令が入ったコンポーネントとは対照的に) ファイルの所有者と見なされます。同様に、スナップショットで比較が実行される場合、そのスナップショットで起動された最上位コンポーネントの <diff> 要素の <ignore> 指示だけが考慮されます。<addSnapshot> コールアウトの結果として出現したコンポーネントに含まれる <diff> 要素の <ignore> 指示は考慮されません。

<addSnapshot> 要素には、entityName 型の 1 つの必須要素 blockName があります。これは、実行する外部スナップショットブロックの名前です。

<addSnapshot> ステップには次の子要素があります。

<addResource> 要素

<addResource> 要素は、包含するスナップショットの一部としてキャプチャーされるコンポーネントに関連付けられたリソースを指定します。この要素は、単純コンポーネントにしか含めることができません。

この要素は、次に示すように、同等の <addFile> 要素の簡略構文として機能します。

<cleanup> 要素

<cleanup> 要素は <snapshot> 要素の子要素であり、ファイルのキャプチャーまたは比較が完了したあとで実行される一連のステップを定義します。これらのステップは、このスナップショットを対象とする <createSnapshot> または <addSnapshot> ステップと、このスナップショットを対象として実行される比較の両方の結果として実行されます。どのような場合も、これらのステップはすべてのファイルのキャプチャーまたは比較作業のあとに実行されます。cleanup ブロックは、prepare ブロックで作成された一時ファイルを削除するために使用します。

<cleanup> 要素の子は、1 つ以上の<call>、<execNative>、および <transform> ステップから構成されます。ほかのステップは許可されません。包含されるステップは、スナップショットブロックで宣言されたローカルパラメータおよびローカル変数と、隠蔽されていない component 置換変数を参照できます。

<controlList> 要素

<controlList> 要素は、<component> 要素のオプションの子要素です。そのコンポーネントで利用できる制御ブロックをリストします。この要素を使用する場合、この要素は 1 回しか出現できません。

この要素には制御ブロックである必須子要素 <control>があります。複数の <control> 要素を指定できます。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセスが可能な <controlList> 要素の内容を継承します。派生コンポーネントが <controlList> を宣言する場合、その内容はベースコンポーネントの内容と効果的に結合されます。派生コンポーネントは新しい <control> 要素を宣言することで継承された要素をオーバーライドできますが、ベースコンポーネントによって宣言された要素を削除することはできません。

<control> 要素

<control> 要素は、このコンポーネントで利用できる制御ブロックを定義します。制御ブロックは、コンポーネントのインストールが完了したあとで実行できる一連のステップです。たとえば、データベースアプリケーションのコンポーネントに制御ブロックを含め、データベースの「起動」または「停止」を行えます。 <call> ステップは、名前で制御ブロックを呼び出すことができます。この呼び出しにより、制御ブロックステップが順に実行されます。

<control> 要素の子は、オプションの <paramList> 要素とそれに続く本体から構成されます。この本体は、オプションのローカル <varList> 要素と、それに続くゼロ個以上の「共通」ステップから構成されます。詳細は、「共有ステップ」を参照してください。制御ブロックが抽象と宣言されている場合、本体は含められません。

デフォルトでは、派生コンポーネントはそのベースコンポーネントの、アクセス可能なすべての制御ブロックを継承します。制御ブロックをオーバーライドするセマンティクスは、インストールブロックをオーバーライドするセマンティクスと同じです。

<control> 要素の属性

<control> 要素には次の属性があります。

<diff> 要素

<diff> 要素は、<component> 要素のオプションの子です。この要素は、このコンポーネントで比較を実行する際に比較エンジンによって使用される命令のリストを含みます。この要素を使用する場合、この要素は 1 回しか出現できません。

<diff> 要素には 1 つの必須子要素である <ignore> があります。この要素は、比較の際に無視するディレクトリパスを指定します。<ignore> 要素は、1 回または複数回使用することができます。

派生コンポーネントは、ベースコンポーネントによって宣言されたすべての無視命令を自動的に継承します。また、それ自体の <diff> 要素内で無視命令をさらに宣言することもできます。継承された命令を削除することはできません。

<ignore> 要素

<ignore> 要素は <diff> 要素の子要素であり、比較でこのコンポーネントを使用する場合に無視するファイル名パスのパターンを指定します。この要素は、一般に、インストールされたアプリケーションによって作成されるファイルとディレクトリ (ログファイルなど) に使用されます。この要素の構成可能属性は、コンポーネント置換変数を参照できます。

<ignore> 要素には1 つの必須属性 path があります。これは、無視するファイル名パスに一致する glob スタイルのパターンです (例: /logs/*.log) 。この属性は、コンポーネントスコープの置換変数を参照できます。

コンポーネントのインストール専用のステップ

この節では、コンポーネントのインストールブロック内でしか使用できないステップを示します。

<deployResource> ステップを除くすべてのステップは、単純コンポーネントと複合コンポーネントの両方で使用できます。<deployResource> は、単純コンポーネントだけで使用できます。

<createDependency> ステップ

このステップは、ほかのコンポーネントに対する現在のコンポーネントの永続的な依存性を作成します。このステップは、その実行時にまず指定された基準に一致するインストール済みコンポーネントが存在しないかチェックします。そのようなコンポーネントが存在しない場合、このステップは失敗します (<checkDependency> ステップの場合とまったく同じ)。一致するコンポーネントが見つかると、一致したコンポーネント (「依存先」) と呼び出しコンポーネント (「依存元」) の間に永続的な依存性が作成されます。

複数のインストール済みコンポーネントが基準に一致する場合 (インストールパスを指定しないとこのような状況となり得る) は、最新のものが依存先として使用されます。永続的なコンポーネントは、ステップで指定される名前で作成されます。 この名前は、インストールブロックで作成されるすべての依存性間で一意のものでなければなりません。

作成された永続的な依存性は、依存コンポーネントがアンインストールされるまで持続します。永続的な依存性を作成したあと、後続のステップで依存コンポーネントのインストールが停止する場合、依存性はこの停止時にただちに削除されます。

個々のコンポーネントは、<createDependency> ステップをコンポーネントごとに実行することにより任意の数のコンポーネントに依存できます。 <createDependency> ステップは、インストールブロックの最初のステップとして出現し、依存性が満たされない場合、実際の処理が行われる前にインストールが失敗するようになっている必要があります。

<createDependency> ステップには 1 つの必須子要素があり、この要素が依存先コンポーネントを特定します。その子要素はインストール済みコンポーネントターゲッターです。詳細は、「インストール済みコンポーネントターゲッター」を参照してください。

<createDependency> ステップの属性

<createDependency> ステップには identifier 型の 1 つの必須属性 name があり、これは作成する依存性の名前です。この名前は、現在のコンポーネントによって作成されるすべての依存性の間で一意のものでなければなりません。

<createDependency> ステップのアンインストールについて

コンポーネントのアンインストールは、そのコンポーネントに対して依存するインストール済みコンポーネントが存在する場合は行えません。コンポーネントのアンインストールブロックが検出された場合で、そのコンポーネントを依存先とする 1 つ以上の永続的な依存性が存在するときは、アンインストールはただちに停止します。

しかし、コンポーネント A によってコンポーネント B のアンインストールが進行している場合、A によって作成された B に対する依存性が B のアンインストールを防止することはなく、この依存性は B が正常にアンインストールされた時点で暗黙に削除されます。

依存先コンポーネントは、<dependantCleanup> ブロックを使用してその依存元をアンインストールするアクションを指定できます。

<createDependency> ステップの再インストールについて

同じホストとインストールパス上にインストールされた同じバージョンツリー内に既存コンポーネントが存在する場合、コンポーネントのインストールは、再インストールと見なされます。コンポーネントの再インストールが行えるのは、その新しいコンポーネントがオリジナルコンポーネントのすべての依存元に適合する場合だけです。コンポーネントは常に同じバージョンのコンポーネントで再インストールできます。ただし、永続的な依存性を作成した <createDependency> ステップ内で指定した制約に、新しいバージョンが適合する場合には、異なるバージョンで再インストールすることもできます。

コンポーネントの単純インストールブロックが検出された場合は、インストールによって既存のインストールが上書きされるかどうかを、N1 SPS が判別します。上書きされる場合、N1 SPS は、既存のコンポーネントを依存先としている永続的な依存性をすべて検出し、インストールされる新しいコンポーネントについても依存性の制約が適合するかを検証し直します。適合しないものがある場合、新しいコンポーネントのインストールは失敗し、オリジナルコンポーネントがインストールされたままとなります。

すべて適合する場合、新しいコンポーネントがそのインストールを正常に完了した時点で、そのコンポーネントがすべての永続的な依存性の新しい依存先となります。オリジナルのコンポーネントはアンインストールされたと見なされ、そのコンポーネントの依存元であったすべての永続的な依存性が削除されます。つまり、新しいコンポーネントは必要に応じて依存性を作成し直す必要があります。

<createDependency> ステップの命名規則

依存性の名前は、xxx 2yyy という形式に従います。xxx は依存元コンポーネントの名前、yyy は依存先コンポーネントの名前を示します。

たとえば、WebLogic で管理されたサーバーが、管理サーバーに対して server2domain という依存性を持ち、その包含クラスタに対して server2cluster という依存性を持つ例が考えられます。この慣例は依存関係の状態を自己記録として表現するのに便利であり、特定のコンポーネントの依存先関係と依存元関係の両方を示すことができます。

<createSnapshot> ステップ

このステップは、インストール中のコンポーネントの現在のインストール状態のスナップショットを作成します。インストールブロックには、任意の数の <createSnapshot> ステップを指定できます。

<createSnapshot> ステップでは引数の引き渡しがサポートされないため、名前付きスナップショットブロックでは必須パラメータを宣言できません。引数の引き渡しがサポートされないのは、この機能をサポートすると生成されたスナップショットに対してあとで比較が行われる際に引数の収集と引き渡しのサポートも必要となるためです。

複合コンポーネントに対して行われる比較には、そのコンポーネントにより直接作成されるすべてのスナップショットが含まれます。またこのような比較には、入れ子になったすべてのコンポーネント参照の再帰的なインストールによって作成されたスナップショットのツリー一式も含まれます。しかし、最上位のコンポーネント参照に関連付けられたスナップショットは考慮されません。そのため、<addSnapshot> キャプチャー命令を使用して、複合コンポーネントのスナップショット内にそのようなスナップショットを明示的に含める必要があります。

また、入れ子になったコンポーネントは相互に依存していることがあり、このような場合にはそれらのコンポーネントがすべてインストールされるまでスナップショットのキャプチャーを延期する必要があります。相互依存の関係にある例として、ディレクトリを配備する入れ子コンポーネントと、そのディレクトリにファイルを配備する入れ子コンポーネントが挙げられます。このような相互依存の場合、包含コンポーネントは、インストール中にスナップショットを作成しないように入れ子コンポーネントに指示する、パラメータの引き渡しまたは特殊なインストールブロックを使用して、入れ子コンポーネントをインストールする必要があります。その後、<addSnapshot> 命令を使用して、包含コンポーネントのスナップショットブロックに、入れ子コンポーネントの適切なスナップショットを含めるようにします。

<createSnapshot> ステップの属性

<createSnapshot> ステップには entityName 型の1 つの必須属性 blockName があり、これはコンポーネント内で実行するスナップショットブロックの名前です。

<install> ステップ

このステップは、ターゲットホストにコンポーネントをインストールします。このステップを使用すると、対象コンポーネントの指定されたインストールブロックのステップが実行されます。

このステップの構文は、単純プランの <install> ステップ用に指定されるものと同じです (「<install> ステップ」を参照)。ただし、コンポーネントのターゲッターは省略できます。その場合は、<thisComponent> が想定されます。

コンポーネント内で使用される場合、このステップは同一コンポーネント内のほかのインストールブロックの呼び出しに使用されます。この場合、一番外側のインストールブロックがその実行を完了するまで、コンポーネントのインストールが完了したとは見なされません。また、ほかのローカルインストールブロックの呼び出し対象がほかのホストに変更された場合でも、コンポーネントは最初のインストールステップの対象となったホストにインストールされたとしか見なされません。

このステップは、参照先コンポーネントをインストールする目的で複合コンポーネント内でも使用できます。参照先コンポーネントは、包含コンポーネントのインストール先以外のホストにもインストールできます。包含コンポーネントのインストールが失敗する場合、この失敗以前にインストールが正常に行われている入れ子になった参照先コンポーネントはすべて、アンインストールブロックを実行することなく暗黙にアンインストールされます。しかし、失敗以前にインストールが正常に行われた最上位の参照先コンポーネントはインストールされたままとなります。

<deployResource> ステップ

このステップは、包含コンポーネントのリソースを配備します。このステップは、単純コンポーネントのインストールブロックでのみ使用可能です。属性または子要素はありません。

deployMode=ADD_TO が包含している各ファイルをコピーし、ディレクトリ構造を維持する、ディレクトリ型リソースです。また、必要に応じて新しいディレクトリが作成されます。既存のディレクトリの構造と内容は (リソース内容のコピーを除き) 変化しません。 個々のファイルアクセス許可と所有権は、適宜更新されます。

配備前に既存ディレクトリが再帰的に削除されることを除き、deployMode=REPLACE が deployMode=ADD_TO と同様に扱われる、ディレクトリ型リソースです。

ほかのリソースはすべてコピーされ、続いてアクセス許可と所有権が適宜更新されます。構成可能としてチェックインされたリソースには、コピーされる前に変数置換が行われます。 構成可能リソースは、リソースが宣言されているコンポーネントにアクセス可能な任意の変数を参照できます。

コンポーネントのアンインストール専用のステップ

この節では、コンポーネントのアンインストールブロック内でだけ使用できる <uninstall> ステップと <undeployResource> ステップを説明します。

<uninstall> ステップ

このステップは、ターゲットホストからコンポーネントをアンインストールするために使用され、任意のコンポーネントのアンインストールブロックで使用できます。このステップを使用することで、対象コンポーネントの指定されたアンインストールブロックのステップが実行されます。

このステップの構文は、単純プランの <uninstall> 用に指定されるものと同じです。ただし、コンポーネントのターゲッターは省略できます。その場合は、<thisComponent> が想定されます。

コンポーネント内で使用される場合、このステップは同一コンポーネント内のほかの既存アンインストールブロックの呼び出しに使用されます。この場合、一番外側のアンインストールブロックがその実行を完了するまで、コンポーネントはアンインストールされません。また、ほかのローカルアンインストールブロックの呼び出し対象がほかのホストに変更された場合でも、コンポーネントは当初アンインストールステップの対象となったホストでのみアンインストールされます。

このステップは、参照先コンポーネントをアンインストールする目的で、複合コンポーネント内でも使用できます。 複合コンポーネントがアンインストールされる場合、入れ子になったその参照先コンポーネントのうち明示的にアンインストールされなかったものはすべて、アンインストールブロックを実行することなくシステムによって暗黙にアンインストールされます。しかし、明示的にアンインストールされなかった最上位の参照先コンポーネントはインストールされたままとなります。

<undeployResource> ステップ

このステップは、包含コンポーネントからリソースを削除するために使用されます。このステップは単純コンポーネントのアンインストールブロックでのみ使用可能で、また属性も子要素もありません。

deployMode=ADD_TO のファイルは削除されますがサブディレクトリは残る、ディレクトリ型リソースです。

deployMode=REPLACE のディレクトリ全体とその内容が削除される、ディレクトリ型リソースです。

ほかのリソースはどれも単純ファイルとして扱われ、削除されます。

リソースは、コンポーネントのインストール時に初めから配備されたかどうかにかかわらず削除されます。コンポーネントが、<deployResource> ステップを含まないインストールブロックを使用してインストールされた場合でも、<undeployResource> ステップによって、初めからコンポーネントによってインストールされたかのように、リソースが削除されます。