第6章

exteNd Directorアプリケーションでのリソースセットの使用

この章では、exteNd Directorリソースセットの目的、内容、およびexteNd Directorアプリケーションに対する設定の影響について説明します。この章の節は次のとおりです。

• アプリケーションでのリソースセットの役割

• リソースセットに配置するもの

• リソースセットへのサブシステムのバインド

• リソースセットの設定

• リソースおよびクラスのダイナミックローディング

• リソースセット変更を報告するイベントの使用

• リソースセットの検証

• MBCS文字を含むXMLファイルの保存

アプリケーションでのリソースセットの役割

exteNd Director 「リソースセット」は、exteNd Directorサブシステムが使用する記述子および他のファイルをまとめ、開発中にダイナミックなロードを提供し、頻繁な再展開を防いでテストを高速化します。それぞれのカスタムWebアプリケーションには、リソースセットを含めることができます。

リソースセットは、アプリケーション定義のリソースとクラスを保持します。 これらのリソースのいくつかは、ルールやポートレット記述子など、サブシステムの機能を使用するためのテンプレートまたは定義です。その他は、ルールとユーザ間のバインドなど、サブシステムがともに機能する方法を指定します。リソースは通常XMLファイルで、Javaクラスを伴うものもあります。

リソースの検索   リソースセットは、リソースセットに配置するもので説明されているとおり、既知のディレクトリ構造にあるアプリケーションのリソースを整理します。

アプリケーションで、リソースへのアクセスは「リソースサーブレット」により処理されます。プライマリ機能は、次のとおりです。

• ドキュメント検出と取得

• Javaクラス検出

• Javaクラスローディング

ダイナミックローディング   リソースセットは、リソースをディスクや展開されたWARから「ダイナミックロード」するように設定できます。設定は、更新されたリソースのバージョンを検索する場所を指定します。リソースサーブレット「バルチャ」はディレクトリの場所を監視し、新しいクラスおよびリソースをロードするタイミングを決定します。ダイナミックローディングを設定するには、リソースおよびクラスのダイナミックローディングを参照してください。

［リソース］タブ   アプリケーションを開発する際、作業するリソースを見つけるには、ナビゲーションペインの［リソース］タブを使用できます。詳細については、を参照してください。

exteNd Directorにリソースセットを含める   exteNd Director EARプロジェクトで、リソースセットはEAR内のアプリケーションWARの一部です。 exteNd Director WARプロジェクトで、リソースセットは、WEB-INF\libディレクトリにJARファイルとして追加されます。 リソースセットはWARプロジェクトに必要ですが、EARプロジェクトには必要ありません。

リソースセットに配置するもの

リソースセットを含むカスタムWebアプリケーションを作成すると、WARはりソースセットサーブレット、およびexteNd Directorアプリケーションに必要なリソースのディレクトリを含むappname_resource.jarと呼ばれるJARファイルを含みます。リソースJARは、カスタムWebアプリケーションのWARのWEB-INF\libディレクトリにあります。

リソースJARは、ポートレット、条件、および作成するアクションのJavaクラスと、アプリケーションメタデータを提供するXML記述子ファイルを含みます。リソースJARは、ユーザが定義するカスタムリソースを含むこともできます。exteNd Directorを使用してさまざまなタイプの新しいリソースを作成すると、exteNd DirectorウィザードはリソースJARの適切なディレクトリにリソースを保存します。

appname_resource.jarに加え、WEB-INF\libに他のJARファイルを追加することもできます。これらの追加JARのリソースは、リソースタイプに対応するサブディレクトリに保存することが必要です。 各JARは、リソースセットの設定ファイルでresourcePathまたはlibPath、あるいはその両方に一覧表示される必要があります。

リソースおよびJavaクラスのサブディレクトリ

次の表は、リソースJARのディレクトリと含むことができるリソースタイプを一覧表示します。ソースレイアウトのプロジェクトを参照すると、［data］ディレクトリの下に次のサブディレクトリがあります

検索内容に対するビューの使用   「ビュー」を使用すると、exteNd Directorプロジェクト内でパーソナライズされた項目リストを表示できます。ビューを使用して、リソースセットでリソースを表示できます。exteNd Directorには、いくつかの事前定義済みビューが付属しています。さらに、exteNd Directorでは、カスタムビューを定義して、目的のプロジェクト項目を表示できます。 exteNd Directorプロジェクトでのビューを使用した項目の検索の詳細については、を参照してください。

リソースセットのプロジェクト

リソースセットのあるカスタムWebアプリケーションは、 ソースレイアウトに表示される少なくとも2つのプロジェクトから構成されます。

• WARプロジェクト

• WARプロジェクトのWEB-INF/libディレクトリのJARプロジェクト

WARプロジェクトのweb.xml記述子は、リソースサーブレットを設定します。JARプロジェクトは、リソースJAR作成に使用されるデータディレクトリとソースディレクトリを持ちます。追加のリソースJARは、作成済みJARとして、または現在のプロジェクトでJARが作成されているプロジェクトとして含めることができます。

リソースセットへのサブシステムのバインド

リソースセットを使用するサブシステムは、次のXMLファイルのエントリによってリソースセットにバインドされます。

• WARのWEB-INF/confディレクトリのresourceset.xml

• サブシステムサービスJARのconfig.xml

resourceset.xmlファイルは、他のモジュールがリソースセットの参照に使用する名前を指定します。この設定の値を編集して、名前を変更できます。

  <settings>
     <name>customwebappname-ResourceSet</name>
     ...
  </settings>

    resourceset.xmlについては、リソースセットの設定を参照してください。

リソースを使用するサブシステムについて、config.xmlファイルは、プロパティのキーと値のペアでリソースセット名を指定することにより、サブシステムを特定のリソースセットにバインドします。Ruleサブシステムのバインドは、次のようになっています。

  <property>
    <key>RuleService/resourceset</key>
    <value>customwebappname-ResourceSet</value>
  </property>

バインドは、次の2種類の方法で編集できます。

• ［環境設定］ツールを使用します(［プロジェクト］>［Directorプロジェクト］>［環境設定］の順に選択)。

      詳細については、を参照してください。

• サブシステムのconfig.xmlを編集します。

ヒント:   設定ファイルを見つけるには、ナビゲーションペインの［リソース］パネルで［表 示］を使用します。つぎのビューを使用します。

• WARプロジェクトのsettings.war.xml(またはEARプロジェクトのsettings.ear.xml)

• WARプロジェクトのconfig.services.by.subsystem.war.xml(またはEARプロジェクトのconfig.services.by.subsystem.ear.xml)

バインドおよびプロジェクトウィザード   リソースセットを含む新しいWebアプリケーションの作成にプロジェクトウィザードを使用すると、ウィザードは新しいリソースセットを指すサブシステムバインドを設定します。リセットするには、これまでに説明した方法を使用します。

リソースセットの設定

リソースセットのあるWebアプリケーションは、2つの設定ファイルを持ちます。

• web.xml

• resourceset.xml

web.xmlについて   web.xml記述子は、WARの標準設定を含みます。リソースセットが使用するサーブレットを定義します。 設定のためのリソースセットは保持しません。

resourceset.xmlについて   resourceset.xml設定ファイルは、リソースの検索方法、有効なJAR、および値を設定する際に使用できる変数を指定する設定を持ちます。

この節の残りの部分では、XMLを示し、resourceset.xmlでできる設定について説明します。リソースセットエディタでは、グラフィカルビューを使用できるため、XMLを直接編集する必要はありません。

    リソースセットエディタの使用方法については、を参照してください。

変数

resourceset.xmlの変数セクションは、静的値ではなく、設定を定義する際に使用できるローカル変数を定義します。 変数を使用して、サブシステムがインストールされアクティブかどうか識別することができます。 また、変数はディレクトリパスにも使用できます。新しく作成されたリソースセットでは、いくつかの変数が定義されます。変数定義は追加することができます。

変数セクションにあるページは、次のXML形式を持ちます。

  <variables>
     <variable key="EARLOCATION" value="C:\DirectorProjects\Test2\Ear" />
     <variable key="WARLOCATION" value="C:\DirectorProjects\Test2\Ear\MyApp" />
     <variable key="ACCESS_DISK" value="true" />
     <variable key="LIBRARY" value="../library" />
     <variable key="WEBINF" value="WEB-INF/lib" />
     <variable key="NEVER" value="0" />
     <variable key="FREQUENT" value="7500" />
     <variable key="INFREQUENT" value="15000" />
  </variables>

注記:   EARLOCATION変数はWARプロジェクトに含まれません。

次の変数が定義されます。

一般設定

リソースセットの一般設定は、検証、ログ、およびダイナミックローディングを有効にする名前とフラグを含みます。

resourceset.xmlの設定セクションは、次の形式を持ちます。

  <settings>
     <name>appname-ResourceSet</name>
     <dynamicClassLoading>true</dynamicClassLoading>
     <validate>false</validate>
     <verbose>false</verbose>
     <vultures>true</vultures>
  </settings>

これらの一般設定は次のとおりです。

リソースのタイプおよび場所 resourcePathとlibPath

resourceset.xmlのpath-entriesセクションは、2つのパスを指定します。resourcePathとlibPath。

resourcePath   resourcePathは、リソースの参照場所をexteNd Directorアプリケーションに通知します。resourcePathに対して指定します。

• ロードするリソースのタイプ。ext要素のセットは、リソースタイプに関連するファイル拡張子を識別します。

• リソースの参照場所。entry要素のセットは、リソースを含むJARおよびディスク場所を識別します。リソースはディスク場所からダイナミックにロードし、変更時に再ロードできます。

libPath   libPathは、Javaクラスの参照場所をアプリケーションに通知します。 リソースセットクラスローダは特定の場所でクラスを探し、前にロードされたクラスをダイナミックにロードして置き換えることができます。libPathに対して指定します。

• 通常のクラスローダを介してロードされるクラス。filter要素のセットは、通常はexteNd DirectorAPIのパッケージである、これらのクラスを含むパッケージを識別します。

• Javaコードを識別するファイル拡張子-通常は.class。

• JARおよびディスク場所でJavaコードを参照する場所。entry要素のセットは、Javaクラスを含むJARおよびディスク場所を識別します。クラスはディスク場所からダイナミックにロードし、変更時に再ロードできます。

注記:   ディスク場所からロードするクラスをEARまたはWARに含むことはできません。ダイナミッククラスローディングを使用する際は、そのクラスを含むプロジェクトを非アクティブにする必要があります。

例   path-entriesセクションは、次のXML形式を持ちます。

  <path-entries>
     <resourcePath>
        <exts>
           <ext active="true">.xml</ext>
           ...
        </exts>
        <entries>
           <entry active="true">$WEBINF$/RuleCA.jar</entry>
           ...
           <entry active="!$vultures$">$WEBINF$/appname-resource.jar</entry>
           <entry active="$vultures$" vultureInterval="$FREQUENT$"
                  recursive="true">$WARKLOCATION$/data</entry>
           ...
        </entries>
     </resourcePath>
  
     <libPath>
        <filters>
           <filter active="true">com.sssw.fw</filter>
           ... 
        </filters>
        <exts>
           <ext active="true">.class</ext>
        </exts>
        <entries>
           <entry active="true">$WEBINF$/CQA.jar</entry>
           ...
           <entry active="!$vultures$">$WEBINF$/appname-resource.jar</entry>
           <entry active="$vultures$" vultureInterval="$FREQUENT$"
                  recursive="true">$WARLOCATION$/build/resource-classes</entry>
           <entry active="!$productionMode$" vultureInterval="$FREQUENT$"
                  recursive="true">$DISKLOCATION$/ResourceSet/WEB-INF/lib</entry>
        </entries>
     </libPath>
  </path-entries>

次の表は、path-entriesセクションの要素を説明します。

  <filter active=\xd3 true\xd3 >com.sssw.fw</filter>

  <ext active=\xd3 true\xd3 >.xml</ext>

  <entry active="true">$WEBINF$/CQA.jar</entry>
  <entry active="true">$WEBINF$/resource.jar</entry> 
  
  <entry active="true" vultureInterval="$FREQUENT$" recursive="true">$WARLOCATION$/data</entry> 
  
  <entry active="true" vultureInterval="$FREQUENT$" recursive="true">$WARLOCATION$build/resource-classes</entry>

エントリ要素での変数の使用

変数セクションでは、EARとWARのディスク場所を含め、いつくかの有用な変数が定義されます。一般設定を変数として使用することもできます。

    一般設定のリストについては、一般設定を参照してください。変数のリストについては、変数を参照してください。resource.xmlをダイナミックに設定可能にするには、必要に応じて追加の変数を定義できます。

編集のヒント   XMLとパスを編集する際、変数または一般設定の名前の前後に$を含めます。リソースセットエディタでボックスを右クリックし、変数リストから選択します。

例   このエントリはリソースセットのresource.jarを参照します。 $WEBINF$は、リソースセットWARのWEB-INF/libディレクトリを指定します。

  <entry active="true">$WEBINF$/resource.jar</entry> 

このエントリは、JavaクラスがコンパイルされるexteNd Directorプロジェクトディレクトリ内のディスク場所を参照します。 バルチャ間隔が設定されました-項目がコンパイルされ、ダイナミックにロードされます。

  <entry active="true" vultureInterval="$FREQUENT$"
   recursive="true">$WARLOCATION$/build/resource-classes</entry>

このエントリは、リソースがWARで保存されるディスク場所を参照します。 サブディレクトリはすべて再帰的に検索されます-リソースは変更されると、ダイナミックにロードされます。

  <entry active="$vultures$" vultureInterval="$FREQUENT$"
   recursive="true">$WARLOCATION$/data</entry>

インデックスのためのディレクトリキー

exteNd Directorは、リソースセットのコンテンツを使用して、ナビゲーションペインの［リソースセット］タブに表示するものを判断します。 関係ビューアおよびリソースセット検索はいずれも、プロジェクトのコンテンツを見る有用な方法を提供し、resourceset.xmlのdirectoriesセクションは、コンテンツを見る方法を定義します。

リソースJARおよびディスク場所のファイルは、常にファイル名でインデックスされます。標準リソースセットディレクトリのそれぞれについて、resourceset.xmlは追加のリソースまたはクラス分類方法を定義できます。追加の検索インデックスを定義することができ、リソースセットのカスタムディレクトリにインデックスを追加することができます。

インデックスと検索は、作業環境を強化する機能です。展開済みのexteNd Directorアプリケーションでは使用されません。

ディレクトリセクションは、次のXML形式を持ちます。

  <directories>
     <directory name="rule-condition-macro" active="true">
        <search key="name" valuebased="true" xpath="/conditionmacro[@name]" active="true" />
     </directory>
     ...
  </directories>

次の表は、ディレクトリセクションに含まれる要素を説明します。

  <directory name="rule-condition-macro" active="true">

  <search key="name" valuebased="true" xpath="/conditionmacro[@name]" active="true" />

リソースおよびクラスのダイナミックローディング

exteNd Directorは、リソースセット内のリソースおよびクラスの「ダイナミックローディング」をサポートします。ダイナミックローディングでは、変更があった場合にプロジェクト全体を展開することなくリソースセット内で変更のテストができるため開発が高速化されます。また、ルールなど特定のリソースタイプに対するダイナミックローディングを有効にすることによって、運用アプリケーションでも制御された変更を可能にします。

ダイナミックロードは、新しいプロジェクトを作成するとき、またはExpress Portalプロジェクトを使用するときにデフォルトで有効になります。ダイナミックローディングが有効なとき、リソースセットの「バルチャ」は変更のディスク場所を監視します。指定された間隔の後にファイルが変更されている場合、バルチャは変更されたリソース項目に関する情報とともにイベントを起動します。そのリソースセットのリスナは、リソース項目を検査して、実行するアクションを決定できます。デフォルトリスナは、変更されたオブジェクトをリソースセットキャッシュからフラッシュするようにプログラムされているため、初めて要求されると新バージョンがロードされます。

    イベントおよびリスナの詳細については、リソースセット変更を報告するイベントの使用を参照してください。

exteNd Directorは、リソースまたはクラス、あるいはその両方をダイナミックにロードできます。resourceset.xmlの設定は、ロードされるものを決定します。各ディスクの場所には、独自のバルチャ設定があります。

注記:   デフォルトでは、リソースセットはダイナミックローディングに設定されます。ダイナミックローディングの機能を理解できるように、ここで必要な設定を説明します。

リソースセットの設定   特定のリソースセットに対してダイナミックローディングを使用するためには、resourceset.xml設定ファイルで次の設定が必要です。

1. settingsセクションで、vultures要素をtrueに設定します。これにより、リソースセットはディスクの場所を調べ、変更を見つけることができます。

2. Javaクラスをダイナミックにロードする場合は、dynamicClassLoading要素をtrueに設定します。その後、［有効/無効］ボタンを使用して、ディスクからダイナミックにロードするクラスのリソースJARプロジェクトを無効にします。

3. ディスク場所の1つまたは複数のentry要素をresourcePathまたはlibPathセクションに追加します。各エントリは、リソースまたはクラスを含むディスク場所を指定します。各エントリ要素に次の属性を設定します。

   • active属性をtrueに設定します。

   • vultureInterval属性をゼロより大きい値に設定します。

   • バルチャがサブディレクトリも検査する必要がある場合は、recursive属性をtrueに設定し、サブディレクトリが省略される場合は、falseに設定します。

    XMLでの表示例については、以下の例を参照してください。

バルチャの機能   resourceset.xmlで、設定セクションのバルチャ要素がtrueに設定されているおり、resourcePathまたはlibPathセクションのエントリが、バルチャ間隔がゼロより大きいディスク場所を指定している場合、exteNd Directorバルチャはそのディスクディレクトリを監視します。バルチャ間隔に達すると、バルチャはディレクトリ内のファイルが修正されたかどうかチェックします。バルチャは新しいファイルもチェックします。削除されたファイルは処理されません。

バルチャはディスク場所で変更されたファイルを見つけると、そのファイルの前のインスタンスをフラッシュし、オブジェクトが次に要求されたときには新バージョンがロードされます。項目がキャッシュにロードされると、次にサーバが起動されるまで、または次にWARが展開されるまで、削除されません。

ダイナミックローディングとクラスローダ   Javaクラスローダは、リソースおよびクラスのダイナミックローディングを無効にします。したがって、EARまたはWARがクラスを含む場合、そのクラスはディスクからダイナミックにロードされることはありません。 クラスをディスクからロードするには、クラスが展開済みアーカイブに含まれていないことを確認します。1つまたは複数のリソースJARをアーカイブから除外するには、リソースセット設定エディタの［サブプロジェクトの有効化/無効化］オプションを使用できます。

ポートレットなどのexteNd Directorクラスに使用されるヘルパクラスに、ダイナミックローディングを有効にすることができます。ヘルパクラスを修正する場合、クラスはバルチャされ、クラスローダのインスタンスにロードされます。 ただし、ポートレットはクラスローダの前のインスタンスによってロードされている可能性があります。この場合、クラスローダのインスタンスが見つけたクラスの参照を継続します。 したがって、ヘルパクラスを再コンパイルする場合は、ポートレットも再コンパイルすることを確認すると、ポートレットの最新バージョンとそのヘルパクラスを取得します。

例   ページ、ポートレット、およびスタイルをディスクからダイナミックにロードするとします。 XMLファイルは、CドライブのMyProjects\MyEAR\MyApp\dataというディレクトリに保存されています。ポートレットのJavaクラスは、MyProjects\MyEAR\MyApp\build\resource-classesにコンパイルされます。

リソース(ページ、ポートレット記述子、スタイル)の更新されたバージョンをダイナミックにロードするには、resourceset.xmlファイルのresourcePathセクションにデータディレクトリを追加する必要があります。クラスについては、buildディレクトリをlibPathに追加する必要があります。 アーカイブから除外されるように、リソースJARプロジェクトも無効にします(クラスをダイナミックにロードする場合にのみ必要です)。

各パスエントリにバルチャ間隔属性を設定して、バルチャがディスク場所で変更をチェックする頻度を指定します。バルチャ間隔はミリ秒で表されます。

次のXML抜粋がresourceset.xmlに表示されます。

  <resourceset>
  <settings>
    <name>ResourceSet</name> 
    <dynamicClassLoading>true</dynamicClassLoading>
    ...
    <vultures>true</vultures>
  </settings>
  <path-entries>
    <resourcePath>
      ...
      <entries>
        ...
        <entry active="true" vultureInterval="$FREQUENT$"
               recursive="true">$WARLOCATION$/data</entry>
      </entries>
    </resourcePath>
    <libPath>
      ...
      <entries>
        ...
        <entry active="true" vultureInterval="$FREQUENT$"
               recursive="true">$WARLOCATION$/build/resource-classes</entry>
      </entries>
    </libPath>
  </path-entries>
  ...
  </resourceset>

リソースセット変更を報告するイベントの使用

すでに学習したように、リソースセットはリソースおよびクラスをJARとディスクで保持します。これらの場所は、resourcePathおよびlibPathセクションのresourceset.xmlに一覧表示されます。リソースセットのコンテンツは、ディスク場所にファイルを追加または削除したときに変更されます。変更を認識して処置するには、リソースおよびクラスのダイナミックローディングで説明されているとおり、exteNd Directorバルチャを設定することができます。

バルチャは変更に気付くと、UPDATEイベントを起動します。exteNd Director サブシステムは、リソースセットイベントを監視して適切に反応します。

この節では、イベントリスナの設定方法およびイベント処理の実行方法について説明します。

注記:   リソースセットイベントに関するこの情報は、高度なトピックです。標準リスナはすでに設定されています。標準リスナは、唯一の必須機能であるリソースセットキャッシュを提供します。

リスナの操作

設定済みのリスナ

新しいexteNd Directorプロジェクトで、Rule、Workflow、およびSecurityサブシステムは、ブートプロセス中に登録されるリソースセットリスナとともにそれぞれ設定されます。バインドされたリソースセットのイベントを受信します。

これらの各サブシステムは、com.sssw.fw.resource.EboResourceListenerを拡張するcom.sssw.<subsystem>.core.EboResourceListenerと呼ばれるリスナクラスを持ちます。デフォルトリスナはクラスとリソースのキャッシュを処理するため、ほとんどの場合はこれらのリスナを継続して使用します。リスナクラスはいくつでも追加できます。

Binding

現在、サブシステムは一対一の関係で1つのリソースセットにバインドされています。サブシステムに登録するリスナは、バインドされた1つのリソースセットのイベントを取得します。 リソースセットを変更すると、登録されたリスナのstateChanged()メソッドが呼び出されます。

リスナの追加

リソースセットにリスナを追加するには、2つの方法があります。

• サブシステムのservices.xmlでリスナサービスを設定します。リスナはブートプロセス中に登録されます。

  または

• EboResourceのaddStateChangeListener()メソッドを呼び出して、リスナを登録します。

リスナは、com.sssw.fw.util.EbiStateChangeListenerを実装するクラスです。

起動時のリスナの追加

起動時にリスナを登録するには、サブシステムのservices.xmlファイルにサービス要素を含めます。たとえば、次のXMLはRuleサブシステムにデフォルトリスナを登録します。

  <service>
    <interface>com.sssw.re.core.EboResourceListener</interface> 
    <impl-class>com.sssw.re.core.EboResourceListener</impl-class> 
    <description>RuleService ResourceSet Listener</description> 
    <max-instances>1</max-instances> 
    <startup>A</startup> 
  </service>

impl-class要素は、EbiStateChangeListenerのメソッドを実装するリスナクラスを指定します。リスナサービスについて、通常、インタフェースはクラスと同じです。

起動要素は、自動開始を表すAの値を持ちます-ブートプロセス中に登録されることを意味します。

起動時のタイミングの問題   ブートプロセス中、登録要求が発生したときにターゲットオブジェクトがインスタンス化されない場合があります-したがって、exteNd Directorは、登録要求を記録してターゲットリソースセットがインスタンス化された後にリスナを登録する、遅延登録手順を使用します。登録が発生すると、EboState.REGISTERのステータスでstateChangedイベントが起動されます。

コードのリスナの追加または削除

アプリケーションコードにリスナを追加するには、com.sssw.fw.resource.EboResourceの静的メソッドaddStateChangeListener()を呼び出します。引数は次のとおりです。

• リソースセットの名前

• com.sssw.fw.util.EbiStateChangeListenerを実装するリスナクラス

たとえば、次のコードは、現在のクラスをMyResourcesリソースセットのリスナとして追加します。

  EboResource.addStateChangeListener("MyResources", this);

リスナを削除するには、removeStateChangeListener()メソッドを呼び出します。次のコードは、現在のクラスをMyResourcesリソースセットのリスナとして削除します。

  EboResource.removeStateChangeListener("MyResources", this);

指定するクラスが登録済みリスナではない場合、削除要求は無視されます。

イベントのタイプ

リソースセットイベントは、リソースセットのステータスの変更を報告するstateChangedイベントです。さまざまな状況のステータスコードは、com.sssw.fw.util.EboStateで定義されます。リソースセットは2つのタイプのイベントを生成します。

• EboState.REGISTERED  イベントリスナが登録されている場合に報告されます。

• EboState.UPDATE  リソースセットの監視されたディスク場所の1つで変更が発生した場合に報告されます。

EboResourceEventオブジェクトは、stateChangedイベントに渡されます。 変更されたリソース要素とEboStateステータスコードから構成されます。

イベントの起動   リソースセットのリスナすべてに、stateChangedイベントを起動することもできます。イベントは、独自のアプリケーション固有ステータスコードまたはEboStateコードを使用できます。

次のサンプルコードは、イベントの準備および起動方法を示します。リソースセットはMyResourcesと名付けられています。

  EboResource rs = EboResource.getLoaded( name );
  EboResourceElement rsrcElem = rs.findResourceElement( file );
  EboResourceEvent rsrcEvt = new EboResourceEvent( rsrcElem, MYSTATUSCODE );
  EboResource.fireStateChanged("MyResources", rsrcEvt );

リスナの機能

標準リスナの動作   リソースを使用する各サブシステムは、リソースセットの変更に応答する標準リスナを持ちます。サブシステムのservices.xmlファイルは、リスナの登録を設定します。

リソースセットのバルチャがオンであり、ディスク場所で変更が発生したことにバルチャが気付いた場合、バルチャはリスナのstateChangedイベントを起動し、変更されたオブジェクトへの参照を含むEboResourceEventオブジェクトを渡します。 リスナコードは、変更されたオブジェクトがそのサブシステムに関連しているかどうか見つけます-関連している場合、サブシステムの内部キャッシュからリソースの旧バージョンをフラッシュします。

注記:   リソースのダイナミックローディングを保持するためには、標準リスナの設定を変更しないでください。

独自のリスナの書き込み   リスナクラスは、クラスcom.sssw.fw.resource.EboResourceListenerを実装する必要があります。唯一のメソッドは、引数type EboResourceEventを持つstateChanged()です。次のサンプルコードはこれをチェックし、イベントオブジェクトからリソース要素を取得して、適切なアクションを実行します。

stateChangedメソッドは、次のようになります。

  public void stateChanged(EboEvent eo)
  {
    if (eo instanceof EboResourceEvent)
    {
      EboResourceEvent evt = (EboResourceEvent) eo;
      if (evt.getState() == EboState.REGISTERED)
      {
        ... // Code to respond to getting registered, if any
      }
      if (evt.getState() == EboState.UPDATE)
      {
        EboResourceElement elem = evt.getResourceElement();
        if (elem != null )
        {
           if (elem.getDirectoryName().startsWith("rule")
           {
  	 	         ... // Do something for a rule resource element
           }
        }
      }
    }
  }

リソースセットの検証

リソースセットをインスタンス化すると、exteNd Directorは検証クラスを実行して、リソースセットをチェックします。

注記:   リソースセットの検証は高度なトピックです。resourceset.xmlで検証を有効にし、それ以上の操作は必要とせずにデフォルト検証を使用できます。

デフォルト検証は、次のものがあるかチェックします。

• resourcePathとlibPathのすべてのアイテム

• ポートレット記述子で参照されるすべてのポートレットクラス

リソースセットの検証設定がtrueの場合、ブートプロセス中にリソースセットがインスタンス化されると、exteNd Directorはリソースセットで見つけたすべての検証クラスを実行します。特定の順序なしに呼び出されます。

独自の検証クラスの書き込み   アプリケーションでチェックを必要とするものをチェックするには、独自の検証クラスを書き込むことができます。これらのクラスは、リソースセットJARのどこにでも保存できます。

検証クラスは、com.sssw.fw.resource.api.EbiValidatorインタフェースを実装する必要があります。インタフェースは1つのメソッドを含みます。

  public void validate( com.sssw.fw.resource.EboResource resource ) throws Exception;

検証クラスが例外をスローする場合、exteNd Directorはコンソールにスタックトレースを表示して、次の検証クラスに進みます。例外は、検証プロセスを停止させたり、exteNd Directorアプリケーションの実行を妨げたりしません。コンソールの情報がアプリケーションの問題を示している可能性がある点に注意することだけが必要です。それ以上のアクションを実行するかどうかは、ユーザが決定します。

検証テストの実行   exteNd Directorでは、展開前にリソースセット検証を実行できます。

1. リソースセットのWEB-INF/libディレクトリで、resourceset.xmlを見つけて開きます。

2. エディタのグラフィカルビューで、［一般］タブを選択します。

3. ［検証］ボタンをクリックします。

   検証クラスからの出力がエディタ出力ウィンドウに表示されます。

MBCS文字を含むXMLファイルの保存

拡張ASCIIまたはマルチバイト文字セット(MBCS)の文字を含むXMLファイルをリソースセットに保存する場合、これらのファイルには、ロケールの正しいエンコードを指定するXMLヘッダを追加する必要があります。 たとえば、コンピュータのロケールがフランスの場合、エンコードはISO8859-1です。この場合は、リソースセットに保存される各XMLファイルに、次のヘッダを追加することが必要です。

  <?xml version="1.0" encoding="ISO8859_1" ?>

このヘッダがない場合、データはXMLパーサによって正しく渡されません。

Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...