<memberList> 要素

<memberList> 要素は <plugin> 要素の子で、当該プラグインの一部であるシステムオブジェクトのリストの宣言に使用されます。これらのオブジェクトは、任意の順序で指定できます。

<memberList> 要素には属性がありませんが、次の子要素の中の最低 1 つの要素を含みます。

• <folder> – フォルダの宣言。

• <hostType> – ホスト型の宣言。

• <hostSet> – ホストセットの宣言。

• <hostSearch> – ホスト検索の宣言。

• <component> – コンポーネントの宣言。

• <plan> – プランの宣言。

<folder> 要素

<folder> 要素は <memberList> 要素の子で、プラグインにより参照されるフォルダの宣言に使用されます。

プラグインは、フルパス名の形式で、作成されるフォルダを指定できます。たとえば /a/b/c という例の場合、a および b は内部フォルダで c はリーフフォルダです。当該プラグインはこのリーフフォルダを所有します。admin グループはフォルダ所有者グループとしてリストされ、当該フォルダはプラグインによって所有されていると特定されます。プラグインは、自らが所有するフォルダにのみコンポーネントとプランを作成できます。プラグインが所有するフォルダには、ユーザーはコンポーネント、プランまたはサブフォルダを作成できません。

プラグインの読み込み時に内部フォルダが存在しない場合、内部フォルダが暗黙に作成されます。プラグインは内部フォルダを所有できません。プラグインが作成した内部フォルダの所有者グループは admin グループですが、そのフォルダはプラグインに属しているとは特定されません。内部フォルダが暗黙にプラグインによって所有されるよう、プラグインの作成者が意図した場合、そのようなフォルダを個別に作成する必要があります。上記の例では、まずフォルダ /a が作成され、次にフォルダ /a/b が作成され、さらにフォルダ /a/b/c が作成されます。

所有されている内部フォルダの下位には、所有されていない内部フォルダを作成することはできません。この要件により、プラグインの作成者は、フォルダ階層において所有されているフォルダの間にあるフォルダにコンポーネントやプランを作成できなくなるため、削除のセマンティクスが複雑になります。

ある内部フォルダが存在し、プラグインの読み込み時点では所有されていない場合、その内部フォルダは直接使用されます。内部フォルダが存在し、あるプラグインによって所有されている場合、その内部フォルダは現在のプラグインによって所有されているか、 現在のプラグインが直接依存しているプラグインによって所有されている必要があります。この要件により、複数の協調的なプラグインを、プラグインベンダーによって個別に分配することができます。Java パッケージスタイルの命名規則に従うことで、フォルダを作成する際に、ベンダーはフォルダネームスペースの衝突を回避できます。

<folder> 要素の属性

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

• name – フォルダのパス名。

• description (オプション) – フォルダの説明。

<hostType> 要素

<hostType> 要素は <memberList> 要素の子で、プラグインにより参照されるホスト型の宣言に使用されます。システムでホスト型が作成される際に、ホスト型名には暗黙にプラグイン名の接頭辞が付けられます。

<hostType> 要素の属性

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

• name – ホスト型の名前。name 属性の最大長は 32 文字です。名前の先頭は Unicode 文字またはアンダースコア文字 (_) で、そのあとには Unicode 文字、数字、アンダースコア文字 (_)、ドット ( .) またはダッシュ (-) が続く必要があります。

• description (オプション) – ホスト型の説明。

<varlist> 要素

<hostType> 要素にはオプションの <varlist> 子要素が含まれます。<varlist> 要素は、<hostType> 要素に追加され、あとでホストが構成で使用する変数のリストを指定します。

<varlist> 子要素には、1 つ以上の <var> 子要素が含まれます。<var> 要素は、次の 2 つの必須属性を通じて、<hostType> 要素の変数宣言を行います。

• name – 変数の名前

• default – 変数のデフォルト値

<hostSet> 要素

<hostSet> 要素は <memberList> 要素の子で、プラグインにより参照されるホストセットの宣言に使用されます。プラグインはホストを定義できないため、<hostSet> 要素はホストを含むことができません。プラットフォームホストセットは、システムプラグイン以外のプラグインでは定義できません。システムでホストセットが作成される際に、ホストセット名には暗黙にプラグイン名の接頭辞が付けられます。

<hostSet> 要素には次の 2 つのオプションの子要素が含まれます。

• <hostSetRef>

• <hostSearchRef>

<hostSet> 要素の属性

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

• name – ホストセットの名前。name 属性の最大長は 32 文字です。名前の先頭は Unicode 文字またはアンダースコア文字 (_) で、そのあとには Unicode 文字、数字、アンダースコア文字 (_)、ドット ( .) またはダッシュ (-) が続く必要があります。

• description (オプション) – ホストセットの説明。

• unsupported (オプション) – true である場合、ホストセットはサポートされません。デフォルトは false です。

<hostSetRef> 要素

<hostSetRef> 要素は <hostSet> 要素の子で、サブホストセットを指定します。このホストセットは、当該フラグイン、または当該プラグインが直接依存するプラグインで、事前に定義されている必要があります。別のプラグインで定義されたホストセットへの参照は、com.foo.other#hostSetName のように、そのプラグイン名を含む必要があります。修飾されていない参照は、当該プラグインにより作成されたオブジェクトと見なされます。

<hostSetRef> 要素の属性

<hostSetRef> 要素には 1 つの属性 name があります。この属性はホストセット参照の名前を指定します。name 属性にはオプションの pluginName があり、最大長は 64文字です。 このあとには、# 区切り文字と、最大長が 32 文字の hostEntityName が続きます。

<hostSearchRef> 要素

<hostSearchRef> 要素は <hostSet> 要素の子で、サブホストの検索を指定します。このホスト検索は、当該プラグイン、または当該プラグインが直接依存するプラグインで、事前に定義されている必要があります。別のプラグインで定義されたホスト検索への参照は、com.foo.other#hostSearchName のように、そのプラグイン名を含む必要があります。修飾されていない参照は、当該プラグインにより作成されたオブジェクトと見なされます。

<hostSearchRef> 要素の属性

<hostSearchRef> 要素には 1 つの属性 name があります。この属性はホスト検索参照の名前を指定します。name 属性にはオプションの pluginName があり、最大長は 64文字です。 このあとには、# 区切り文字と、最大長が 32 文字の hostEntityName が続きます。

<hostSearch> 要素

プラグイン <hostSearch> 要素は <memberList> 要素の子で、プラグインにより参照されるホスト検索の宣言に使用されます。システムでホスト検索が作成される際に、ホスト検索名には暗黙にプラグイン名の接頭辞が付けられます。

<hostSearch> 属性には、次の子要素の少なくとも 1 つが含まれます。

• <criteriaList>

• <appTypeCriteria>

• <physicalCriteria>

---

注 –

<criteriaList>、<appTypeCriteria>、および <physicalCriteria> 要素はいずれもオプションですが、これら 3 つのいずれかを指定する必要があります。

---

<hostSearch> 要素の属性

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

• name – ホスト検索の名前。name 属性の最大長は 32 文字です。名前の先頭は Unicode 文字またはアンダースコア文字 (_) で、そのあとには Unicode 文字、数字、アンダースコア文字 (_)、ドット ( .) またはダッシュ (-) が続く必要があります。

• description (オプション) – ホスト検索の説明

<criteriaList> 要素

<criteriaList> 要素は <hostSearch> 要素の子で、<hostSearch> 要素に追加する基準のリストを指定します。<appTypeCriteria> と <physicalCriteria> が指定されていない場合は、<criteriaList> 要素を指定する必要があります。

<criteriaList> 要素には 1 つ以上の <criteria> 要素が含まれます。<criteria> 要素は、名前、一致型、パターンを含む、検索基準を指定します。

<criteriaList> 要素の属性

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

• name – 照合するホスト変数の名前。

• pattern – 照合するパターン。

• match – 基準の一致型。有効な値は、EQUALS または CONTAINS です。デフォルトは EQUALS です。

<appTypeCriteria> 要素

<appTypeCriteria> 要素は <hostSearch> 要素の子で、<hostSearch> 要素に追加するアプリケーション型の基準のリストを指定します。<appTypeCriteria> 要素の引数は属性として表現され、その順序は重要ではありません。値が false であるか、要素が空または未指定である場合、検索実行時にこの基準は無視されます。<criteriaList> および <physicalCriteria> が指定されていない場合、<appTypeCriteria> 要素を指定する必要があります。

<appTypeCriteria> 要素の属性

<appTypeCriteria> 要素には次の 3 つのオプション属性があります。

• ms – true である場合、ホスト検索で MasterServer アプリケーション型を照合します。デフォルトは false です。

• ld – true である場合、ホスト検索で LocalDistributor アプリケーション型を照合します。デフォルトは false です。

• ra – true である場合、ホスト検索で RemoteAgent アプリケーション型を照合します。デフォルトは false です。

<physicalCriteria> 要素

<physicalCriteria> 要素は <hostSearch> 要素の子で、<hostSearch> 要素に追加する物理型の基準のリストを指定します。<physicalCriteria> 要素の引数は属性として表現され、その順序は重要ではありません。値が false であるか、要素が空または未指定である場合、検索実行時にこの基準は無視されます。<criteriaList> および <appTypeCriteria> が指定されていない場合、<physicalCriteria> 要素を指定する必要があります。

<physicalCriteria> 要素の属性

<physicalCriteria> 要素には次の 2 つのオプション属性があります。

• physical – true である場合、ホスト検索で物理ホスト型を照合します。デフォルトは false です。

• virtual – true である場合、ホスト検索で仮想ホスト型を照合します。デフォルトは false です。

<component> 要素

<component> 要素は <memberList> 要素の子で、プラグイン JAR ファイルでコンポーネントを宣言するために使用されます。このコンポーネントにより参照されるすべてのオブジェクトは、当該プラグイン、または当該プラグインが直接依存するプラグインで、事前に定義されている必要があります。

<component> 要素には次の 3 つのオプションの子要素が含まれます。

• <systemService>

• <componentType>

• <resource>

<component> 要素の属性

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

• jarPath – コンポーネント XML ファイルの位置で、プラグイン JAR のルートに相対的です (先頭の / または . 文字は使用できません)。コンポーネント XML の書式は、プランおよびコンポーネント言語の仕様により指定されます。詳細は、第 3 章「コンポーネントのスキーマ」を参照してください。

• majorVersion (オプション) – コンポーネントを新しいメジャーバージョンとしてチェックインするかどうかを決定する属性。デフォルトは false です。

<systemService> 要素

<systemService> 要素は <component> 要素の子で、包含コンポーネントにより返されるシステムサービスの宣言に使用されます。この要素は <componentType> 要素とは併用できません。<systemService> 要素が <component> 要素で使用されている場合、コンポーネントが読み込まれ、そのコンポーネントを参照する <systemServiceRef> が作成されます。システムでシステムサービスが作成される際に、システムサービス名にはプラグイン名の接頭辞が付けられます。

<systemService> 要素の属性

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

• name – システムサービスの名前

  名前の最大長は 64 文字です。名前は文字またはアンダースコアで始まる必要があり、そのあとには任意の文字、数字、またはアンダースコア (_)、ピリオド (.)、プラス記号 (+)、マイナス記号 (-)、および空白 ( ) などの特殊文字が続きます。Unicode 文字および数字が使用できます。

• description (オプション) – システムサービスの説明

<componentType> 要素

<componentType> 要素は <component> 要素の子で、包含コンポーネントにより返されるコンポーネント型の宣言に使用されます。<componentType> 要素は <systemService> 要素とは併用できません。<componentType> 要素が <component> 要素で使用されている場合、コンポーネントが読み込まれ、そのコンポーネントにより返されるコンポーネント型が作成されます。システムでコンポーネント型が作成される際に、コンポーネント型名にはプラグイン名の接頭辞が付けられます。

コンポーネント型は、プラグインによりグループ化され、これらのグルーピング内でのコンポーネント型の順序により順序付けられます。グルーピングは、プラグインの順序に従って順序付けられます。特定のプラグイン内では、コンポーネント型により定義された個々のグループ名の下で、コンポーネント型がインデントされます。

<componentType> 要素の属性

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

• name – コンポーネント型の名前。

  名前の最大長は 64 文字です。名前は文字またはアンダースコアで始まる必要があり、そのあとには任意の文字、数字、または (アンダースコア (_)、ピリオド (.)、プラス記号 (+)、マイナス記号 (-)、および空白 ( ) などの) 特殊文字が続きます。Unicode 文字および数字が使用できます。

• description (オプション) – コンポーネント型の説明。

• group – 当該コンポーネントがコンポーネント型の階層の一部である場合の、コンポーネント型のグループ名。

  グループ名は、コンポーネント型名と同じ要件に従います。また、グループは hidden として宣言できます。このように宣言すると、「component list 」ページのコンポーネント型のドロップダウンリストでは型が表示されません。

• order – ブラウザインタフェースのコンポーネント型のドロップダウンリストで、当該コンポーネント型を配置する場所を特定する番号です。

  order は、最大 18 文字です。Unicode 文字および数字のほかに、ASCII キーボードで入力できるすべての文字が使用できます。order によって、特定のプラグイン内で定義されているすべての型を順序付けられる必要があります。

• indentLevel – 0 から 10 までの番号で、ブラウザインタフェースのコンポーネント型の階層で当該コンポーネント型をインデントするレベルを特定します。

<resource> 要素

<resource> 要素は <component> 要素の子であり、JAR ファイル内でのリソースファイルの名前と位置を指定します。リソースは、常に単純ファイル型のリソースとしてチェックインされます。<resource> 要素を含むコンポーネントは、その <resourceRef> 要素が <resource> 要素により作成されたリソースを参照する、単純コンポーネントである必要があります。

<resource> 要素の属性

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

• jarPath – プラグイン JAR ファイルのルートに相対的な、リソースファイルの位置。先頭の / または . 文字は使用できません。ディレクトリ型リソースの場合、このパスはディレクトリであると見なされ、/ で終わると想定されています。このディレクトリ内のすべてが、当該リソースのコンテンツを定義します。

• majorVersion (オプション) – 当該リソースを新しいメジャーバージョンとしてチェックインするかどうかを決定する属性。デフォルトは false です。

• name (オプション) – リソースの名前である属性。指定されていない場合、名前のデフォルトは (相対として指定されている場合は絶対に変換される) 絶対 jarPath になります。

• config (オプション) – 当該リソースが構成テンプレートであるかどうかを指定する属性。デフォルトは false です。

• type (オプション) – 当該リソースがファイルとディレクトリのどちらであるかを指定する属性。ファイルリソースには FILE を使用します。ディレクトリリソースには DIRECTORY を使用します。デフォルトは FILE です。

• checkInMode (オプション) – ディレクトリ型リソースを置換するか、追加するかを指定する属性。当該リソースのチェックインにより既存のバージョンを置換する必要がある場合は、REPLACE を使用します。チェックインを当該リソースに追加する必要がある場合は、ADD_TO を使用します。デフォルトは REPLACE です。この属性は、DIRECTORY の「型」を持つリソースにのみ適用されます。

• descriptorPath (オプション) – プラグイン JAR ファイルのルートに相対的な、リソース記述子ファイルへのパスを指定する属性。先頭の / または . 文字は使用できません。リソース記述子ファイルの形式は、第 5 章「リソース記述子スキーマ」で説明されている、リソース記述子スキーマに従います。

  リソース記述子ファイルが指定されていない場合、N1 SPS Master Server のデフォルトのファイルシステム設定からアクセス権の情報が使用されます。この場合、所有者とグループは格納されません。これは、記述子から省略された設定にも当てはまります (リソース内のファイルのエントリが存在しない場合、またはエントリが部分的である場合)。

<plan> 要素

<plan> 要素は <memberList> 要素の子で、プラグイン JAR でプランを宣言するために使用されます。このプランにより参照されるすべてのオブジェクトは、当該プラグイン、または当該プラグインが直接依存するプラグインで、事前に定義されている必要があります。

<plan> 要素の属性

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

• jarPath – プラグイン JAR ファイルのルートに相対的な、プラン XML の位置。先頭の / または . 文字は使用できません。プラン XML の書式は、プランおよびコンポーネント言語の仕様により指定されます。詳細は、第 4 章「プランのスキーマ」を参照してください。

• majorVersion (オプション) – 当該プランを新しいメジャーバージョンとしてチェックインするかどうかを決定する属性。デフォルトは false です。