Sun N1 Service Provisioning System 5.2 プラグイン開発ガイド

第 2 章プラグインの作成

この章では、プラグインフレームワークを使用して、特定のアプリケーションまたはプラットフォーム用のプロビジョニングソリューションを作成する方法について説明します。この章では、次の情報について説明します。

プラグイン開発環境のインストール

プラグインソリューションの作成に必要なほとんどの要素は、標準の Sun N1 Service Provisioning System ソフトウェアに含まれています。ただし、完全な開発ソリューションを用意するには、いくつかのソフトウェアを追加インストールする必要があります。これらの主なソフトウェアは、Sun N1 Service Provisioning System 5.2 DVD の /plugins/lib/sps-compSDK.jar ファイルと /plugins/lib/plugin-core.jar ファイルに含まれます。

`sps-compSDK.jar` ファイル

sps-compSDK.jar には、N1 SPS の公開 Java API が含まれます。

注 –

sps-compSDK.jar ファイルは、N1 SPS のマスターサーバーではなく、開発システムにインストールします。sps-compSDK.jar ファイルを目的の場所に配置したら、Java ツールでファイルを探せるように、必ず classpath を変更してください。

sps-compSDK.jar ファイルには、プラグイン作成用に次の Java クラスが含まれます。これらのパッケージに含まれるクラスおよびインタフェースについては、『Sun N1 Service Provisioning System 5.2 JavaDoc』を参照してください。

com.sun.n1.sps.client: CLI コマンドを実行し、マスターサーバーに対してクエリーを実行するためのクラスとインタフェースが含まれます
com.sun.n1.sps.model: N1 SPS オブジェクトのバージョン番号、可視性、および ID を特定するためのクラスとインタフェースが含まれます
com.sun.n1.sps.model.category: コンポーネントやプランなどの関連するオブジェクトを、カテゴリにグループ分けするための 3 つのインタフェースが含まれます
com.sun.n1.sps.model.component: コンポーネント情報を定義するためのインタフェースとクラスが含まれます
com.sun.n1.sps.model.difference: プロビジョニングの比較を定義するためのインタフェースとクラスが含まれます
com.sun.n1.sps.model.executor: プランおよび OS のネイティブコマンドを実行するためのインタフェースとクラスが含まれます
com.sun.n1.sps.model.folder: N1 SPS のフォルダを定義するためのインタフェースが含まれます
com.sun.n1.sps.model.host: ホストセット、ホスト ID、ホスト検索、特定のホストで実行されているアプリケーション、特定ホストのアップグレード処理など、ホストの条件を定義するためのインタフェースとクラスが含まれます
com.sun.n1.sps.model.install: ターゲットホストにインストールされているコンポーネントに関する情報を収集するためのインタフェースが含まれます
com.sun.n1.sps.model.plan: N1 SPS のプランを実行するためのインタフェースとクラスが含まれます
Package com.sun.n1.sps.model.plugin: プラグインを定義し、ほかのユーザーがブラウザインタフェースでこれらのプラグインを一覧できるようにするためのインタフェースが含まれます
com.sun.n1.sps.model.resource: リソースを定義するためのインタフェースが含まれます
com.sun.n1.sps.model.rule: 特定の処理の条件と規則を定義するためのインタフェースとクラスが含まれます
com.sun.n1.sps.model.user: ユーザーとグループのアクセス権、ID、および変数を設定するためのインタフェースとクラスが含まれます
com.sun.n1.sps.model.util: ping および traceroute を使用してネットワーク接続の基本的な検証を行うためのインタフェース、クラス、および例外が含まれます
com.sun.n1.util.collections: 一覧およびセットを定義するためのインタフェースが含まれます
com.sun.n1.util.enum: 列挙および列挙型のインタフェース、クラス、および例外が含まれます
com.sun.n1.util.vars: 変数設定のソースを特定するための 1 つのインタフェースが含まれます

`plugin-core.jar` ファイル

plugin-core.jar には、ファイルシステムベースのコンポーネントの一覧クラスとエクスポートクラスを提供する 3 つのパッケージが含まれます。

com.sun.n1.sps.pluginimpl.system

サポートされているプラットフォームを特定する複数の定数が含まれます

com.sun.n1.sps.pluginimpl.system.browse

ファイルシステムベースの一覧機能をサポートするための 5 つのクラスが含まれます

FileDisplay – ファイルシステムのファイルに適切な表示
FilesystemBrowser – ファイルシステムの階層構造ブラウザ
FilesystemBrowserFactory – ファイルシステムを階層構造で表示するのに十分な型を返すファクトリ
FilesystemExtensionFilter – ファイル拡張子に基づいてフィルタを適用する FilesystemFilter
FilesystemFilter – すべてのファイルシステムフィルタの基底クラス

com.sun.n1.sps.pluginimpl.system.export

単純なファイルシステムオブジェクトをエクスポートするための 1 つのクラス FilesystemExporter を提供します

プラグインの作成: プロセスの概要

プラグインソリューションの開発は、環境のニーズ、およびソリューションを適用するアプリケーションまたはプラットフォームによって、単純にも複雑にもなります。Sun N1 Service Provisioning System 環境の次の分野に対するプラグインソリューションを作成できます。

変数および構成テンプレートの操作
ユーザーによるファイルの一覧およびマスターサーバーへのファイルのエクスポートの有効化
execJava 機能を使用した Java アプリケーションの実行
コンポーネントやプランの作成と変更
プラグインのパッケージ化と、プラグイン XML を使用したプラグインのインタフェースの定義

プラグインを作成する大まかな手順は次のとおりです。

プラットフォームまたはアプリケーションの一般的なモデルを開発します。

詳細は、「モデルの開発」を参照してください。
モデルを実装するプランやコンポーネントを作成します。

詳細は、「コンポーネントとプランの作成」を参照してください。
プラグインを簡単に制約できるようにするために、特定のホストタイプ、ホストセット、およびホスト検索を定義します。

詳細は、「プラグインのホストの制限」を参照してください。
Sun N1 Service Provisioning System 内でアプリケーションのインタフェースを定義します。

詳細は、「プラグインへのユーザーインタフェースの定義」を参照してください。
プラン、コンポーネント、リソース、およびインタフェース定義を Java アーカイブ (JAR) ファイルにパッケージ化します。

詳細は、「ソリューションのパッケージ化」を参照してください。
プラグインをテストします。

詳細は、「ソリューションのテスト」を参照してください。

プラグインのディレクトリ構造

プラグインフレームワークを使用してソリューションを開発するときは、ファイルの保存場所に注意する必要があります。ソリューションを JAR ファイルにパッケージ化するときは、ファイルの正確な記録を持っている必要があります。次の一覧に、プラグインに推奨されるディレクトリ構造を示します。

META-INF
components
plans
resources           
gui                  
plugin-descriptor.xml  
readme.txt

META-INF ディレクトリ

プラグインの各要素のマニフェストが含まれます。このディレクトリは、プラグインを JAR ファイルにパッケージ化するときに作成されます。

components ディレクトリ

コンポーネントおよびコンポーネントタイプの XML 定義ファイルを含む一連のサブディレクトリが含まれます。サブディレクトリはプラグイン名の構造に従います。たとえば、プラグイン名が com.sun.solaris の場合、components のサブディレクトリは、com、sun、および solaris になります。実際のコンポーネントの XML ファイルは、components/com/sun/solaris ディレクトリの中にあります。

注 –

components、plans、および resources の各ディレクトリは、特定のプラグインバージョン用のより大きなディレクトリ構造に組み込むこともできます。たとえば、特定のプラグインの version 1.0 と 1.1 を区別するには、ディレクトリ構造 1.0/components/com/sun/solaris/Project.xml と 1.1/components/com/sun/solaris/Project.xml を使用できます。

plans ディレクトリ

実行プランの XML 定義ファイルを含む一連のサブディレクトリが含まれます。サブディレクトリはプラグイン名の構造に従います。たとえば、プラグイン名が com.sun.solaris の場合、plans のサブディレクトリは、com、sun、および solaris になります。実際の実行プランの XML ファイルは、plans/com/sun/solaris ディレクトリの中にあります。

resources ディレクトリ

リソースファイルを含む一連のサブディレクトリが含まれます。サブディレクトリはプラグイン名の構造に従います。たとえば、プラグイン名が com.sun.solaris の場合、resource のサブディレクトリは、com、sun、および solaris になります。実際のリソースファイルは、resources/com/sun/solaris ディレクトリの中にあります。

gui ディレクトリ

ユーザーインタフェース記述子ファイル (pluginUI.xml ) およびユーザーインタフェースに表示する必要があるアイコンのファイルが含まれます。ユーザーインタフェース記述子ファイル内の要素については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 7 章「プラグインユーザーインタフェーススキーマ」を参照してください。

plugin-descriptor.xml ファイル

プラグインを記述する XML ファイルです。プラグイン記述子ファイル内の要素については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 6 章「プラグイン記述子スキーマ」を参照してください。

readme.txt ファイル

プラグイン用にシステムを構成する手順を含むテキストファイルです。

モデルの開発

プラグインソリューションを構築する前に、計画とモデル化の作業が必要です。このとき、次の点を検討します。

このソリューションを使用する環境。たとえば、オペレーティングシステム要件、アプリケーションのバージョン要件などです。
このプラットフォームまたはアプリケーションをプロビジョニングするときに、パス名などの変数値を説明する必要があるかどうか。
このプラットフォームまたはアプリケーションが機能するために、プロビジョニング可能なホストに配備する必要があるファイル。たとえば、構成ファイルです。
このソリューション用に新しいコンポーネントタイプを定義する必要があるか、または既存のコンポーネントタイプを使用できるか。多くの単純なソリューションでは、system#file や system#directory などの既存のコンポーネントタイプを使用できます。ただし、必要な場合は、既存のコンポーネントタイプを拡張する独自のコンポーネントタイプを定義できます。

注 –
system#file や system#directory などのシステムコンポーネントタイプを拡張する場合は、プラグイン記述子ファイルでこのコンポーネントタイプへの依存性を指定する必要があります。
ユーザーがリモートシステムからコンポーネントを一覧し、コンポーネントのインスタンスを作成する必要があるかどうか。
ユーザーが実行できるようにする操作の流れ。

次に、Java^TM 2 Platform, Enterprise Edition (J2EE) を配備する流れに基づいて、モデル化の流れの例を示します。

インフラストラクチャーを配備します。
- インストーラのバイナリを実行してインフラストラクチャーをインストールします。
- ターゲット作成可能コンポーネントをインストールします。
すべてのアプリケーションオブジェクトをコンポーネントとして取得します。たとえば、次のオブジェクトがあります。
- Java アーカイブ (JAR) ファイル、エンタープライズアーカイブ (EAR) ファイル、Web アーカイブ (WAR) ファイル、エンタープライズ Java Beans (EJB) ファイル
- JDBC 接続およびデータソース
次のような環境設定を含む「環境」コンポーネントを作成します。
- Java 仮想マシン (JVM) の設定
- セッション管理の設定
アプリケーションと環境のコンポーネントを設定します。
コンポーネントをターゲット作成可能コンポーネントに配備します。

拡張可能なプラグインの設計

Sun N1 Service Provisioning System ソフトウェアでは、プラグインを拡張できるので、効率よく既存のプラグインに機能を追加し、この新しいプラグインを Sun N1 Service Provisioning System 環境に追加できます。次のような場合に既存のプラグインを拡張できます。

既存のプラグインに含まれない追加のファイルやリソースをプロビジョニングする場合
プラグインで処理するアプリケーションをプロビジョニングするときにステップを追加する場合

既存のプラグインを拡張すると、そのプラグインで使用している XML や Java クラスも拡張されます。ただし、拡張するプラグインが拡張可能である必要があります。プラグインを拡張可能にするには、プラグインの開発時に次の手引きに従います。

ほかのコンポーネントによって拡張可能にするコンポーネントに固有のコンポーネントタイプを作成します。
プラグインの XML で、拡張可能にするプラグイン変数の access 属性の値を public に設定します。
プラグインの XML で、拡張可能にするプラグインの制御ステップの modifer 属性を protected に設定します。

プラグインの拡張方法については、第 3 章「アプリケーション固有のプラグインの拡張」を参照してください。

コンポーネントとプランの作成

企業全体で特定のソリューションを効果的に再現するには、ソリューションの共通の部分を特定するコンポーネント、リソース、およびプランを定義する必要があります。また、これらを配備するプロセスを定義する必要があります。プラン、コンポーネント、およびそれらの管理方法については、『Sun N1 Service Provisioning System 5.2 プランとコンポーネントの開発者ガイド』を参照してください。

コンポーネントの構築

ソリューション開発の重要な部分はコンポーネントの作成です。Sun N1 Service Provisioning System 環境では、コンポーネントは配備可能なオブジェクトです。コンポーネントに含めることができるオブジェクトの例を次に示します。

ファイルとディレクトリのコレクション
JAR ファイル、EAR ファイルなどのアーカイブファイル
必要なリソースすべてを含む、完全なアプリケーション
構成ファイルやマニュアルなどの特定のアプリケーションリソース

N1 SPS ソフトウェアでは、コンポーネントのバージョンを取得できます。プラグインのコンポーネントを変更し、これらのコンポーネントを N1 SPS 環境にチェックインすると、コンポーネントに新しいバージョン番号が割り当てられます。プラグインを使用してアプリケーションをプロビジョニングするときに、特定の配備に適切なコンポーネントのバージョンを選択できます。

Sun N1 Service Provisioning System のブラウザインタフェースを使用したコンポーネントの作成については、『Sun N1 Service Provisioning System 5.2 プランとコンポーネントの開発者ガイド』の「コンポーネントを作成する」を参照してください。

単純コンポーネントと複合コンポーネント

単純コンポーネントには、ファイル、ディレクトリ、アーカイブファイル、またはアプリケーションなどの単一の物理リソースが含まれます。単純コンポーネントはほかのコンポーネントを参照しません。

複合コンポーネントは、ほかの単純コンポーネントまたは複合コンポーネントを参照するだけです。複合コンポーネントには、直接、物理リソースは含まれません。

例 2–1 単純コンポーネントの XML

次の XML の例は、システムコンポーネントタイプ system#CR Simple Base を拡張して JAR ファイルを含めた単純コンポーネントを示します。コンポーネントの定義に使用する特定の要素や属性については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 3 章「コンポーネントのスキーマ」を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns='http://www.sun.com/schema/SPS' name='plugin-core.jar' 
    version='5.2' description='Jar file implementation of core plugin services' 
    xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' author='system' 
    softwareVendor='Sun Microsystems' path='/system' 
    xsi:schemaLocation='http://www.sun.com/schema/SPScomponent.xsd'>
  <extends>
    <type name='system#CR Simple Base'>
    </type>
  </extends>
  <resourceRef>
    <resource name='/system/plugin-core.jar' version='1.1'>
    </resource>
  </resourceRef>
</component>

変数

コンポーネントまたはプランを作成するときに、コンポーネントの配備時またはプランの実行時に使用する変数を定義できます。多くのコンポーネントタイプには共通の変数が含まれます。たとえば、installPath はコンポーネントのインストール先を定義します。installPath 変数の値は、コンポーネントがホストにインストールされるときに決定します。

共通の変数をいくつか次に示します。

installPath – コンポーネント、プラグイン、またはその他のリソースファイルのインストール先のパス
installName – インストールする項目の名前
installUser – コンポーネント、プラグイン、またはその他のリソースファイルをインストールしたユーザーのログイン名
pluginClasspath – 特定のプラグインに適用するクラスのインストール先のパス

変数は、コンテナコンポーネントの変数など、別の変数を参照できます。たとえば、単純コンポーネントの installPath 変数の値は、その親コンテナコンポーネントの installPath 変数の値にできます。

変数を定義するときに変数の名前とデフォルト値の属性を指定します。デフォルト値は、次の場所から取得できます。

リテラル文字列
ホスト (target キーワードを使用)
別のコンポーネント (component キーワードを使用)
ユーザーのセッション (session キーワードを使用)

これらの属性の使用については、『Sun N1 Service Provisioning System 5.2 プランとコンポーネントの開発者ガイド』の「置換に使用できる変数の種類」を参照してください。

変数は、ブラウザインタフェースを使用して定義するか、または直接 XML ファイルで定義できます。XML ファイルでは、変数は <var> 要素を使用して定義され、<varList> 要素内に追加されます。

例 2–2 XML での変数の定義

次の XML フラグメントでは、複数の変数を定義しています。

<varList>
    <var name='installPath' 
         default=':[target:sys.raDataDir]:[/]systemcomps'>
    </var>
    <var name='pluginClasspath' 
         default=':[installPath]:[/]plugin-core.jar'>
    </var>
    <var name='fileBrowser' 
          default='com.sun.n1.sps.pluginimpl.system.browse.FilesystemBrowserFactory'>
    </var>
    <var name='directoryBrowser' 
          default='com.sun.n1.sps.pluginimpl.system.browse.FilesystemBrowserFactory'>
    </var>
    <var name='symlinkBrowser' 
          default='com.sun.n1.sps.pluginimpl.system.browse.FilesystemBrowserFactory'>
    </var>
</varList>

構成テンプレート

構成テンプレートは、特殊なファイルコンポーネントです。構成テンプレートを使用すると、配備するファイル内でトークン置換を行うことができます。この使用方法の例として、DNS の /etc/resolv.conf ファイルの配備があります。配備の目標は、たとえばファイルで変数置換を使用し、ホストタイプ属性を使用して最も近い DNS サーバーを定義することです。構成テンプレートの例を次に示します。

search :[search_path]
nameserver :[primary_dns]
nameserver :[secondary_dns]

この場合、構成テンプレートによって search_path、 primary_dns、secondary_dns というコンポーネント変数が自動的に作成されます。すると、プランやコンポーネントの制御で変数置換を使用して、適切な値を指定できます。

構成テンプレートの定義方法については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』を参照してください。

コンポーネントタイプの定義

Sun N1 Service Provisioning System 製品には、基本のコンポーネントタイプが多数含まれます。一部の基本コンポーネントタイプには、ファイルやディレクトリなどの項目が含まれます。特定のアプリケーションまたはプラットフォームで使用する特定のコンポーネントタイプを定義することもできます。たとえば、アプリケーションで常に使用する特定のファイルタイプがあるとします。この場合、アプリケーション用に system#CR Simple Base コンポーネントタイプを拡張して、アプリケーションに新しいコンポーネントタイプを定義できます。

コンポーネントタイプの定義は、ほかのコンポーネントの XML ファイルと同様に XML ファイルに保存されます。プラグインを定義するときに、記述子ファイルの <component> 要素で、バッキングコンポーネントのファイルのパスを指定します。<component> 要素の <componentType> 子要素を使用して、名前、説明などの追加情報を指定します。詳細は、例 2–15 を参照してください。

コンポーネントタイプにバージョンはありません。プラグインで、既存のコンポーネントタイプと同じ名前のコンポーネントタイプを作成しようとすると、名前の衝突を防ぐために、新しいコンポーネントタイプの名前の前にプラグイン名が付加されます。

コンポーネントタイプの作成方法については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の「<componentType> 要素」を参照してください。

プランの作成

プランは、特定のホストで 1 つまたは複数のコンポーネントの管理に使用する一連の命令です。たとえば、プランで 3 つのコンポーネントをインストールして、別のコンポーネントの起動制御を開始することができます。ほとんどの場合、プランを作成するには、XML を編集する必要があります。この規則への唯一の例外は、自動生成プランです。Sun N1 Service Provisioning System ソフトウェアでは、直接実行手続きから構成されるプランを自動的に生成できます。たとえば、1 つのコンポーネントのインストールから構成されるプランを自動生成できます。次に、このプランを直接実行するか、保存してほかの複雑なプランを作成するテンプレートとして使用できます。

N1 SPS ソフトウェアでは、プランのバージョンを取得できます。プラグインのプランを変更し、これらのプランを N1 SPS 環境にチェックインすると、プランに新しいバージョン番号が割り当てられます。プラグインを使用してアプリケーションをプロビジョニングするときに、配備に適切なプランのバージョンを選択できます。

単純プランと複合プラン

単純プランには、一連の配備命令 (ステップ) が含まれます。単純プランは、1 つのホストまたはホストセットで実行します。単純プランでは、インストールやアンインストールなどの共通の手続きを呼び出すことができます。また、条件付きのプログラミング構文も使用できます。

複合プランには、単純プランへの呼び出しが含まれます。複合プランでは、1 つのホストに手続きを適用すると同時に、ほかの手続きを別のホストまたはホストセットに適用できます。

例 2–3 単純プランの XML

単純プランの例を次に示します。このプランには、インストールブロックとアンインストールブロックがあります。プランの定義に使用する特定の要素や属性については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 4 章「プランのスキーマ」を参照してください。

<?xml version="1.0" encoding="UTF-8"?>
<!-- generated by N1 SPS -->
<executionPlan xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 
    name='plugin-core.jar-1096573592002' version='5.12' 
    xsi:schemaLocation='http://www.sun.com/schema/SPSplan.xsd' 
    xmlns='http://www.sun.com/schema/SPS' path='/system/autogen'>
    <simpleSteps>
        <install blockName='default'>
            <component name='plugin-core.jar' path='/system' version='1.1'>
            </component>
        </install>
        <uninstall blockName='default'>
            <installedComponent name='plugin-core.jar' versionOp='=' 
                 version='1.1' path='/system'>
            </installedComponent>
        </uninstall>
    </simpleSteps>
</executionPlan>

例 2–4 複合プランの XML

複合プランの例を次に示します。この例では、3 つのサブプランを呼び出しています。

<executionPlan 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  name="apache-tomcat-uninstall" version="5.2"
  xsi:schemaLocation="http://www.sun.com/schema/SPSplan.xsd"
  xmlns="http://www.sun.com/schema/SPS">
    <compositeSteps>
        <execSubplan planName="mod-jk-uninstall" />
        <execSubplan planName="apache-uninstall" />
        <execSubplan planName="tomcat-uninstall" />
    </compositeSteps>
</executionPlan>

例 2–5 より高度なプランの XML

次の例に、条件に基づいて何を実行するかを決定する、より複雑なプランを示します。

<?xml version="1.0" encoding="UTF-8"?>
<!-- generated by CR -->
<executionPlan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    name="BAM_backout_new_version_NODE-A" version="5.2" 
    xsi:schemaLocation="http://www.sun.com/schema/SPSplan.xsd" 
    xmlns="http://www.sun.com/schema/SPS" path="/plans/uat">
   <paramList>
      <param name="backout_type" prompt="Enter type of backout (all,ear,prop)"></param>
   </paramList>
   <varList>
      <var name="admin_server" default="wusx119"></var>
      <var name="node" default="wust3022"></var>
      <var name="wl_server_name" default="bamC"></var>
      <var name="apphome" default="/opt/uat/ceodomain"></var>
      <var name="prop_args" default="-s wust3022"></var>
      <var name="application_name" default="bam"></var>
      <var name="staging_base" default="/usr/local"></var>
      <var name="user" default="weblogic"></var>
   </varList>
   <simpleSteps limitToHostSet="uat-bam">
      <if>
         <condition>
            <or>
               <equals value2="all" value1=":[backout_type]"></equals>
               <equals value2="prop" value1=":[backout_type]"></equals>
               <equals value2="ear" value1=":[backout_type]"></equals>
            </or>
         </condition>
      <then>
         <call blockName="backout_application">
            <argList application_name=":[application_name]" 
                 staging_base=":[staging_base]" 
                 backout_type=":[backout_type]" 
                 user=":[user]">
            </argList>
            <installedComponent name="deploy_tools" 
                  path="/components/function_library">
             </installedComponent>
         </call>
         <call blockName="wl_stop">
            <argList wl_server_name=":[wl_server_name]" 
                  node=":[node]" apphome=":[apphome]" user=":[user]">
            </argList>
            <installedComponent name="deploy_tools" 
                  path="/components/function_library">
            </installedComponent>
         </call>
         <if>
            <condition>
              <equals value2="all" value1=":[backout_type]"></equals>
            </condition>
         <then>
               <call blockName="clusterdeploy">
                  <argList application_name=":[application_name]" 
                        staging_base=":[staging_base]" node=":[node]" user=":[user]">
                  </argList>
                  <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                  </installedComponent>
               </call>
               <call blockName="deploy_prop">
                  <argList application_name=":[application_name]" 
                        prop_args=":[prop_args]" staging_base=":[staging_base]" 
                        user=":[user]">
                  </argList>
                  <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                     </installedComponent>
                  </call>
                  <call blockName="wl_startjsp">
                     <argList application_name=":[application_name]" 
                        wl_server_name=":[wl_server_name]" 
                        node=":[node]" apphome=":[apphome]" user=":[user]">
                     </argList>
                     <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                     </installedComponent>
                  </call>
               </then>
            </if>
            <if>
               <condition>
                  <equals value2="ear" value1=":[backout_type]"></equals>
               </condition>
               <then>
                  <call blockName="clusterdeploy">
                     <argList application_name=":[application_name]" 
                        staging_base=":[staging_base]" node=":[node]" user=":[user]">
                     </argList>
                     <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                     </installedComponent>
                  </call>
                  <call blockName="wl_startjsp">
                     <argList application_name=":[application_name]" 
                        wl_server_name=":[wl_server_name]" 
                        node=":[node]" apphome=":[apphome]" user=":[user]">
                     </argList>
                     <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                     </installedComponent>
                  </call>
               </then>
            </if>
            <if>
               <condition>
                  <equals value2="prop" value1=":[backout_type]"></equals>
               </condition>
               <then>
                  <call blockName="deploy_prop">
                     <argList application_name=":[application_name]" 
                        prop_args=":[prop_args]" 
                        staging_base=":[staging_base]" user=":[user]">
                     </argList>
                     <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                     </installedComponent>
                  </call>
                  <call blockName="wl_start">
                     <argList application_name=":[application_name]" 
                        wl_server_name=":[wl_server_name]" 
                        node=":[node]" 
                        apphome=":[apphome]" 
                        user=":[user]">
                     </argList>
                     <installedComponent name="deploy_tools" 
                        path="/components/function_library">
                     </installedComponent>
                  </call>
               </then>
            </if>
         </then>
         <else>
            <raise message="Please enter a valid deployment type (all/ear/prop)"></raise>
         </else>
      </if>
   </simpleSteps>
</executionPlan>

プランの生成方法

「Components」ページを表示します。

プランを生成するコンポーネントを選択します。

コンポーネントの詳細を表示します。

「Component Procedures」が表示されていない場合は、表示されるまでページをスクロールダウンします。

プランで使用する手続きを選択します。

「Generate Plan with Checked Procedures」をクリックします。

「Plans」編集ページが表示されます。このページから、XML を変更して例 2–5 に示すような複雑なステップを含めることができます。

プランやコンポーネントでのネイティブコマンドの使用 (`<execNative>` ステップ)

XML の <execNative> ステップを使用すると、プランやコンポーネント内からネイティブコマンドを実行できます。たとえば、プロセスが開始したことを確認するには、<execNative> を使用して UNIX の ps コマンドを呼び出すことができます。<execNative> のスキーマ、属性、および子要素については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の「<execNative> ステップ」を参照してください。

指定したコマンドが <execNative> で実行される前に、コマンドが存在すること、また指定したユーザーがコマンドの実行権を持っていることが Sun N1 Service Provisioning System ソフトウェアによって確認されます。コマンドが存在しないか、実行権がなかった場合は、<execNative> がエラーで終了します。

例 2–6 `<execNative>` を使用した簡単なコマンドの呼び出し

次の <execNative> の例では、UNIX の ps -ef コマンドと同等な動作が実行されます。

<execNative>
    <exec cmd="ps">
        <arg value="-ef" />
    </exec>
</execNative>

例 2–7 `<execNative>` を使用したアプリケーションの起動

次の <execNative> の例では、Web サーバーのインスタンスを開始しています。

<execNative
  dir="/opt/ns/https-admserv"                Set working directory
  userToRunAs="webadmin"                     Equates to "su -webadmin"
  timeout="5">
    <inputText>
        start.sh                             Input parameters to command
    </inputText>
    <exec cmd="sh />                         Command to run
    <successCriteria status="0" />           execNative succeeds only if exit code is "0"
</execNative>

プランやコンポーネントでの Java ベースのオブジェクトの呼び出し (`<execJava>`)

<execJava> メカニズムを使用すると、プランまたはコンポーネントの定義内でのクライアント提供 Java コードのプロセス内実行をエージェント側で有効化できます。<execJava> は <execNative> に似ていますが、Java コードの実行が対象です。

<execJava> 機能は、XML ステップとして、また Java ベースの API として提供されています。XML のスキーマ、属性、および子要素については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の「<execJava> ステップ」を参照してください。execJava API については、「execJava API」を参照してください。ここでは、例も示しています。

XML の <execJava> ステップには必須の属性が 1 つ、省略可能な属性が 2 つあります。

className – ターゲットホストで実行する Java クラスを指定する必須の属性です。
classPath – className 属性で指定するクラスのパスを指定する省略可能な属性です。この属性を使用しなかった場合、リモートエージェントのシステムクラスパスが使用されます。
timeout – タイムアウトになるまでに Java クラスの実行を待つ時間 (秒単位) を指定する省略可能な属性です。

<execJava> メカニズムでは、<argList> 子要素を使用して Java Executor に引数を渡すことができます。

例 2–8 コンポーネントの XML での `<execJava>` の使用

<varList>
   <var name="installPath" default="/opt/util"/>
</varList>
<resourceList defaultInstallPath=":[installPath]">
   <resource resourceName="util/propPrint.jar" installName="propPrint.jar"/>
</resourceList>
   ...
<controlList>
   <control name="showProp"/>
   <paramList>
       <param name="propName">
   </paramList>
   <execJava
       className="com.raplix.util.PropertyPrinterFactory"
       classPath="$[installPath]/propPrint.jar">
       <argList>
           <arg name="propertyName" value=":[propName]"/>
       </argList>
       <successCriteria outputMatches="<undefined>" inverse="true"/>
   </execJava>

例 2–9 プランの XML での `<execJava>` の使用

<executionPlan xmlns="http://www.sun.com/schema/SPS" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.sun.com/schema/SPSplan.xsd" 
   name="execJavaExample" version="5.2">
   <paramList>
       <param name="name"></param>
       <param name="value"></param>
   </paramList>
   <varList>
       <var name="classpath" 
           default=":[target:sys.raDataDir]:[/]systemcomps:[/]plugin-com.sun.sample.jar"/>
   </varList>
   <simpleSteps>
       <execJava className="com.sun.n1.sps.pluginimpl.sample.executor.SampleExecutorFactory"
           classPath=":[classpath]">
           <argList nameParam=":[name]" valueParam=":[value]" />
       </execJava>
   </simpleSteps>
</executionPlan>

条件付き要素

プランまたはコンポーネント内で <if> 要素を使用して、ステップのブロックを実行する条件を指定できます。従来のプログラミングの if-then-else 構文と同様に、<if> 要素内の文が評価されます。この文が真の場合は、<then> 要素のステップが実行されます。真ではなかった場合は、<else> 要素のステップが実行されます。<else> 要素がなかった場合は、何も処理が行われません。

例 2–10 `<if>` 要素の XML

次の例では、<if> 要素を使用して、ユーザーが配備時にシステムのスナップショットを作成して、ターゲットホストでのコンポーネントのインストール状態を取得するかどうかを決定できるようにしています。

<if>
    <condition>
        <istrue value=:[createSnapshot]"></istrue>
    </condition>
    <then>
        <createSnapshot blockName="default"></createSnapshot>
    </then>
</if>

エラーの処理

XML スキーマには、エラー処理用の一連の要素があります。この一連の要素の親は <try> 要素です。これらの要素は、次のような場合に使用できます。

配備時にエラーを抑制する場合。たとえば、コンポーネントのインストール時にファイルまたはその他のリソースを配備してから再起動する場合、再起動が失敗したときにインストール自体は失敗しません。
別のステップに依存するステップを実行するかどうかを制御する場合。たとえば、useradd と groupadd の両方の機能を実行する場合、groupadd は useradd が正常に終了した場合にのみ実行します。
インストールパスを指定する場合。たとえば、アプリケーションの version 1.1 をインストールする場合、ターゲットホストにそのアプリケーションの version 1.0 があるかどうかによってインストールパスが異なります。

<try> 要素には、ステップのブロックを含めます。これらの手順は、すべてが正常に完了するまで、または 1 つのステップが失敗するまで順番に実行されます。ステップが失敗し、<catch> 要素があった場合、<catch> 要素のステップが、すべて正常に完了するまで、または 1 つのステップが失敗するまで順番に実行されます。<finally> 要素が定義されている場合は、<finally> 要素のステップが、すべて正常に完了するまで、または 1 つのステップが失敗するまで順番に実行されます。これは、<try> 要素と <catch> 要素が正常に完了したかどうかに関係ありません。一般に、<finally> 要素は、クリーンアップ機能の実行やリソースの解放のために使用します。

<raise> 要素は、専用のステップを作成せずに障害の状態を指定するために使用します。<raise> ステップは必ず失敗します。<raise> 要素は単独で使用できますが、通常は <catch> 要素のブロック内で使用します。

例 2–11 `<try>` 要素の XML

次の XML の例では、<try> 要素を使用して、初期インストールを実行するか、アップグレードインストールを実行するかを決定しています。

<installSteps blockName="default">
    <try>
        <block>
            <checkDependency>
                <installedComponent name="foo" version="1.0" />
            </checkDependency>
        </block>
        <catch>
          <raise message="Required component foo is not installed on this system"/> 
        </catch>
    </try>
</installSteps>

プラグインのホストの制限

Sun N1 Service Provisioning System では、特定の条件を満たすホストだけにプラグインの動作を制限できます。ホストの制限は、次の 3 通りのメカニズムで行うことができます。

特定のホストタイプを定義する。ホストタイプは、一連の共通する属性でバインドされたサーバーの基本クラスを定義します。たとえば、Solaris 10 大域ゾーンとみなされるサーバーを指定するホストタイプを定義できます。
ホストセットを定義する。ホストセットは、1 つ以上の共通の属性 (物理的な場所や機能グループなど) を共有するホストを論理的にグループ化したものです。ホストセットを使用すると、セット内の全ホストを簡単にすばやく更新できます。ホストセットを使用してインストールを比較することもできます。
ホスト検索を定義する。ホスト検索は、ホストデータベースから、特定の属性がクエリーと一致するホストの一覧を取得します。ホスト検索を使用して、特定のホストタイプと一致するホストや、特定のアプリケーションが実行されているホストを検索できます。

この 3 通りのホストの制限は、このあとの例に示すように、プラグイン記述子ファイルで定義します。

例 2–12 `plugin-descriptor.xml` ファイルでのホストタイプの定義

次の例では、Solaris コンテナで使用する 2 種類のホストタイプを定義しています。1 つは大域ゾーン用でもう 1 つはローカルゾーン用です。実際の hostType 名にはプラグイン名が付加されます。ユーザーがタイプ com.sun.solaris#global_zone のホストを作成するときは、4 つの属性とそれぞれのデフォルト値を指定します。これに対して、com.sun.solaris#local_zone ホストタイプにはユーザー定義の属性を関連付けません。

<hostType name="global_zone" 
    description="a physical host from which partitioned local zones can be created"> 
  <varList>
    <var name="local_zone_base_path" default="/export/zones"/>
    <var name="local_zone_connection_type" default="RAW"/>
    <var name="local_zone_port" default="1131"/>
    <var name="local_zone_advanced_params" default=" "/>
  </varList>
    </hostType>
    <hostType name="local_zone" 
      description="a physical host that is created out of the larger global_zone"/>

例 2–13 `plugin-descriptor.xml` ファイルでのホストセットの定義

次の例では、大域ゾーンを含むホストセットを定義しています。ホストセットの実際の内容は、参照しているホスト検索の実行時に指定されます。

<hostSet name="global_zones"
     description="Solaris global zones">
<hostSearchRef name="global_zones"/>

例 2–14 `plugin-descriptor.xml` ファイルでのホスト検索の定義

次の例では、すべての大域ゾーンを検索するホスト検索を定義しています。この検索では、次の条件を満たすすべてのホストの結果が返されます。

Solaris 10 オペレーティングシステムを実行している
ホストタイプが com.sun.solaris#global_zone である
リモートエージェントを実行している
仮想ホストではなく物理ホストである

<hostSearch name="global_zones" description="Solaris global zones">
  <criteriaList>
    <criteria name="sys.OS" pattern="SunOS"/>
    <criteria name="sys.OSVersion" pattern="5.10"/>
    <criteria name="sys.hostType" pattern="com.sun.solaris#global_zone"/>
  </criteriaList>
  <appTypeCriteria ra="true"/>
  <physicalCriteria physical="true"/>
</hostSearch>

ユーザーによるファイルの一覧とエクスポートの有効化

Sun N1 Service Provisioning System には、ユーザーが特定のリソースをコンポーネントに含めることができるようにする機能があります。一覧機能は、主に次の 2 つの機能から構成されます。

一覧 – ユーザーは、リモートエージェントマシンでフィルタを適用した任意のツリー表示のオブジェクト階層内を移動し、そのツリー内のオブジェクトを選択できます。
エクスポート – ユーザーは、選択したオブジェクトまたはオブジェクトの集合を、可能な場合は変更された形式でマスターサーバーにチェックインできます。

たとえば、ユーザーがファイルシステム内を移動し、ファイルを選択し、コンポーネントを使用してファイルをチェックインできるようにできます。

一覧とエクスポートの機能は、com.sun.n1.sps.plugin.browse と com.sun.n1.sps.plugin.export パッケージで提供されます。詳細は、「コンポーネント API」を参照してください。

一覧とエクスポート: プロセス概要

外部からは、一覧とエクスポートのプロセスは、次のようになります。

ユーザーがコンポーネントを作成するコンポーネントタイプを選択します。選択したタイプのバッキングコンポーネントに exporterClassName が定義されている場合は、一覧とエクスポート用のユーザーインタフェースが起動します。
プロビジョニングソフトウェアで、BrowserInfo クラス内のブラウザ情報がすべて取得されます。この情報を取得するために、ソフトウェアで ComponentExporter インタフェースの getAvailableBrowsers メソッドが呼び出されます。
プロビジョニングソフトウェアで BrowserFactory の情報が BrowserInfo から取得され、BrowserFactory がインスタンス化されます。ここから、プロビジョニングソフトウェアで Browser オブジェクトが取得されます。
Browser オブジェクトから、ソフトウェアで Browser の getNode() メソッドを呼び出して root ノードが検索されます。
ユーザーがノードを選択し、続いてチェックインプロセスを行うと、プロビジョニングソフトウェアで ComponentExporter クラスの constructComponent メソッドが呼び出され、このメソッドによってリソースがエクスポートされ、チェックインされます。

プラグイン開発の観点から見たより詳細なプロセスは次のようになります。

コンポーネントタイプのバッキングコンポーネントが exporterClassName というコンポーネント変数を定義します。exporterClassName の値は、com.sun.n1.sps.plugin.export.ComponentExporter を実装するクラスです。
ComponentExporter クラスのメソッド getAvailableBrowsers が BrowserInfo オブジェクトの配列を返します。これらの BrowserInfo オブジェクトは、ブラウザに関する次の情報を持っています。
- システムサービスの名前
- 上記のシステムサービス内の変数 name。この変数の値は BrowserFactory クラスです。
- 上記のシステムサービス内の変数 name。この変数の値は、ブラウザのクラスパスです。
- クラスパスにシステムサービスを使用しない場合に、実際のクラスパス。
BrowserFactory クラスには、Browser インタフェースを実装するブラウザを取得するメソッドがあります。
Browser のメソッド getNode(...) がツリーのノードを検索します。引数が null だった場合、 getNode(...) は root ノードを返します。
ComponentExporter クラスには、コンポーネントを作成するメソッドが別にあります。このメソッドは、実際の一覧の終了後に使用されます。constructComponent メソッドには ComponentMonitor が渡され、これを使用して選択されたリソースがエクスポートされ、コンポーネントの一部としてマスターサーバーにチェックインされます。

一覧機能

階層ツリー機能全体を実装するクラスは BrowserNode です。この機能は主に次の 4 つの分野に分かれます。

ノードのすべての子を表示
ノードの親を表示
ノードがリーフノードかどうかを指定
ノードに関連するその他の説明やプロパティを表示

プラグイン用のブラウザの実装に使用するクラスやメソッドについては、「一覧機能」を参照してください。

エクスポート機能

ユーザーがファイルを一覧したあと、マスターサーバーにエクスポートできるようにするクラスは ComponentExporter です。プラグイン用のエクスポート機能の実装に使用するクラスやメソッドについては、「エクスポート機能」を参照してください。

プラグインの定義

ほかのユーザーがソリューションを使用できるようにするには、プラン、コンポーネント、およびコンポーネントタイプの定義をプラグインにラップします。プラグインを定義するには、 <plugin> 要素とその子を使用する XML ファイルを作成します。<plugin> 要素については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 6 章「プラグイン記述子スキーマ」を参照してください。

例 2–15 プラグイン記述子ファイルの例

次の記述子ファイルの例は、Solaris ゾーンのプラグイン用です。

<?xml version="1.0" encoding="UTF-8"?>
<plugin name="com.sun.solaris"
   description="Solaris plugin"   version="1.0"
   vendor="Sun Microsystems Inc"
   xmlns="http://www.sun.com/schema/SPS"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.sun.com/schema/SPSplugin.xsd"
   schemaVersion="5.1">
   <gui jarPath="gui/pluginUI.xml"/>
   <memberList>
       <folder name="/com/sun/solaris" description="Solaris plugin folder"/>
       <hostType name="global_zone"
            description="a physical host from which partitioned local zones can be created">
          <varList>
            <var name="local_zone_base_path" default="/export/zones"/>
            <var name="local_zone_connection_type" default="RAW"/>
            <var name="local_zone_port" default="1131"/>
            <var name="local_zone_advanced_params" default=" "/>
         </varList>       </hostType>
       <hostType name="local_zone" 
            description="a physical host that is created out of the larger global_zone"/> 
       <hostSearch name="global_zones" description="Solaris global zones">
         <criteriaList>
            <criteria name="sys.OS" pattern="SunOS"/>
            <criteria name="sys.OSVersion" pattern="5.10"/>
            <criteria name="sys.hostType" pattern="com.sun.solaris#global_zone"/>
         </criteriaList>
         <appTypeCriteria ra="true"/>
         <physicalCriteria physical="true"/>
       </hostSearch>
       <hostSet name="global_zones" description="Solaris global zones">
         <hostSearchRef name="global_zones"/>
       </hostSet>
       <component jarPath="fiji/components/com/sun/solaris/zone_util.tar.xml">
         <resource jarPath="fiji/resources/com/sun/solaris/zone_util.tar"
             name="/com/sun/solaris/zone_util.tar"/>
       </component>
       <component jarPath="fiji/components/com/sun/solaris/N1GridContainer.xml" 
         majorVersion="true">
       </component>
       <component jarPath="fiji/components/com/sun/solaris/ZoneSS.xml">
         <systemService name="zoneSS"
           description="the Solaris zone system service"/>
       </component>   </memberList>
</plugin>

プラグインへのユーザーインタフェースの定義

ほかのユーザーに提供する、または環境全体に配布するソリューションを作成するときの主な作業のひとつに、Sun N1 Service Provisioning System ブラウザインタフェース内にソリューションのインタフェースを定義することがあります。インタフェースを定義するには、<pluginUI> 要素とその子を使用する XML ファイルを作成します。<pluginUI> 要素については、『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 7 章「プラグインユーザーインタフェーススキーマ」を参照してください。

例 2–16 プラグインのインタフェースファイルの例

次のプラグインのインタフェースファイル pluginUI.xml の例は、Solaris ゾーンのプラグイン用です。

<?xml version="1.0" encoding="UTF-8"?>
<pluginUI menuItem="Solaris"   xmlns="http://www.sun.com/schema/SPS"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.sun.com/schema/SPS pluginUI.xsd"
   schemaVersion="5.2">
   <icon jarPath="gui/solaris.gif"/>
   <customPage name="Solaris"> 
    <section title="Solaris specific tasks"
       description="create and manage Solaris specific components...">
       <entry title="Solaris Zones" description="create and manage zones">
         <action text="list" toolTip="list of installed zones">
           <compWhereInstalled path="/com/sun/solaris" name="N1GridContainer"/>
         </action>
         <action text="create and manage" toolTip="create and manage zones">
           <compDetails path="/com/sun/solaris" name="N1GridContainer" />
         </action>
       </entry>
     </section>
   </customPage>
</pluginUI>

ソリューションのパッケージ化

ほかのユーザーがソリューションを使用できるようにするには、またソリューションを環境内に簡単に配布するには、ソリューションを Java アーカイブ (JAR) ファイルにパッケージ化します。JAR ファイルの内容および内容を解釈するための命令は、JAR ファイルの最上位ディレクトリにある plugin-descriptor.xml ファイルに記述します。このファイルは署名することもできます。プラグイン記述子の構文は、2001 年 5 月 2 日付けの W3C 勧告 (http://www.w3.org/TR/2001/xmlschema-0-20010502/) に従った XML スキーマを使用して指定されています。このスキーマを妥当性検査パーサーとともに使用して、プラグインの構文の妥当性を検査できます。プラグイン記述子ファイルについては、「プラグインの定義」を参照してください。

JAR ファイルを作成するには、JAR ユーティリティーを使用します。JAR ユーティリティーで使用するオプションは、 UNIX の標準の tar ユーティリティーと似ています。

JAR ファイルを作成するには、すべてのプラグインファイルを含むルートディレクトリから次のコマンドを実行します。jar cf jarfile inputfiles

各オプションの意味は次のとおりです。

c オプションによって、jarfile という新しいアーカイブが作成されます。このアーカイブには、inputfiles で指定するファイルやディレクトリが格納されます。
f jarfile オプションでは、作成するファイルの名前を指定します。
inputfiles では、JAR ファイルに含めるファイルやディレクトリを指定します。ファイル名やディレクトリ名を空白で区切って指定するか、アスタリスク (*) 記号を使用して現在のディレクトリ内のすべてのファイルを指定できます。ディレクトリはすべて再帰的に処理されます。

例 2–17 サブディレクトリを含む JAR ファイルの作成

サブディレクトリがある場合は、次のコマンド例のように 1 つの JAR ファイルに結合できます。

% jar cvf myplugin.jar *
added manifest
ignoring entry META-INF/
ignoring entry META-INF/MANIFEST.MF
adding: components/(in = 0) (out= 0)(stored 0%)
adding: components/com/(in = 0) (out= 0)(stored 0%)
adding: components/com/sun/(in = 0) (out= 0)(stored 0%)
adding: components/com/sun/myplugin/(in = 0) (out= 0)(stored 0%)
adding: components/com/sun/myplugin/mycomponent.xml(in = 6224) (out= 1182)(deflated 81%)
adding: components/com/sun/myplugin/myothercomponent.xml(in = 1291) (out= 507)(deflated 60%)
adding: components/com/sun/myplugin/mycomponenttype.xml(in = 940) (out= 470)(deflated 50%)
adding: resources/(in = 0) (out= 0)(stored 0%)
adding: resources/com/(in = 0) (out= 0)(stored 0%)
adding: resources/com/sun/(in = 0) (out= 0)(stored 0%)
adding: resources/com/sun/solaris/(in = 0) (out= 0)(stored 0%)
adding: resources/com/sun/solaris/zone_util.tar(in = 20480) (out= 4232)(deflated 79%)
adding: gui/(in = 0) (out= 0)(stored 0%)
adding: gui/pluginUI.xml(in = 861) (out= 407)(deflated 52%)
adding: gui/solaris.gif(in = 1622) (out= 1627)(deflated 0%)
adding: plugin-descriptor.xml(in = 1990) (out= 707)(deflated 64%)
%

JAR ファイル内のファイルを確認するには、次のコマンドを使用します。

% jar tf mypluin.jar
META-INF/MANIFEST.MF
fiji/
fiji/components/
fiji/components/com/
fiji/components/com/sun/
fiji/components/com/sun/solaris/
fiji/components/com/sun/solaris/N1GridContainer.xml
fiji/components/com/sun/solaris/ZoneSS.xml
fiji/components/com/sun/solaris/zone_util.tar.xml
fiji/resources/
fiji/resources/com/
fiji/resources/com/sun/
fiji/resources/com/sun/solaris/
fiji/resources/com/sun/solaris/zone_util.tar
gui/
gui/pluginUI.xml
gui/solaris.gif
plugin-descriptor.xml

ソリューションのテスト

ソリューションを環境全体で、またはほかのユーザーが使用できるようにする前に、ソリューションをテストする必要があります。次のような点をテストします。

XML パーサーを使用して plugin.xsd スキーマに対する plugin-descriptor.xml ファイルの妥当性検査を行います。
XML パーサーを使用して pluginUI.xsd スキーマに対する pluginUI.xml ファイルの妥当性検査を行います。
使用する Java コードを正常に構築でき、コードが正常に機能することを確認します。
完成したプラグインを Sun N1 Service Provisioning System 製品にインポートします。エラーがないことを確認します。カスタマイズしたユーザーインタフェースがある場合は、インタフェースが正常に描画され、またカスタマイズしたページ上のリンクがすべて正常に機能することを確認します。
インポートが正常に完了したあとにプラグインを削除できることを確認します。

第 2 章 プラグインの作成