Diagnostic Provider Extensible Markup Language
Diagnostic Provider (DP) Extensible Markup Language (XML) 宣言で従うべき規則です。
これらのガイドラインは、Diagnostic Providers (DP) の使用に一貫性を持たせる上で役立ちます。
- すべての Diagnostic Provider 宣言 Extensible Markup Language (XML) ファイルの先頭に、ご使用の DP の文書タイプ定義 (DTD) を組み込みます。
- すべての名前と名前セグメントは、小文字で開始します。 属性名ではラクダ記法 を使用します。 これは、最初を除くすべての名前の最初の文字を大文字にすることです。 例えば、traceCollectionSpec などです。
- 階層はダッシュで示します。 属性名は正規表現であるため、ドットよりもダッシュの方が適しています。 例えば、traceService-traceCollectionSpec などです。
- 属性名のストリングの動的な部分をアスタリスク (*) で示します。
以下に例を示します。
vhosts-.*-webgroups-.*-webapps-.*-listeners-filterInvocationListeners
これは、vhosts-someHost-webgroups-someGroup-webapps-someApp-listeners-filterInvocationListeners に一致します。 - 属性名の数値の動的な部分を [0-9]* で示します。
以下に例を示します。
vhosts-index-[0-9]*
これは、webcontainer-vhosts-index-123 に一致します。 - パフォーマンスに大幅な影響を与えることなく実行できる汎用自己診断テストがある場合は、general と名付けます。
configDump 実装に関するヒント
- configDump には、コンポーネントの環境を定義する際に使用する情報を含める必要があります。
いくつかの例は以下のとおりです。
- Java™ Management Extensions (JMX) で設定される構成データ
- システム・プロパティー、xml ファイル、およびプロパティー・ファイルからの構成
- コードで変更されないハードワイヤードの構成情報 (例えば、リソース・アダプターがインターフェース X を実装するか、静的最終フィールド Y がある場合、これらは構成のある側面を示すことになり、configDump に含めることができます)
- configDump では、以下のような動的に登録される属性を含めないようにする必要があります。
- 登録済みロガーのリスト (これは stateDump に属します)
- アプリケーションのサーブレットのリスト (これは stateDump に属します)
- configDump は、startup および current という 2 つのセクションに分離する必要があります。
- すべての configDump 属性は、startup- または current- で開始する必要があります。
- startup セクションは、起動時にコンポーネントの環境の詳細を示します。 起動 configDump 属性は startup- で開始します。
- current セクションは、configDump の要求時に、コンポーネントの環境の詳細を示します。 現行 configDump 属性は current- で開始します。
configDump のベスト・プラクティス
- 属性の階層を使用するグループ関連属性 (例えば、traceLog に関する 2 つの属性: startup-traceLog-rolloverSize=20、startup-traceLog-maxNumberOfBackupFiles=1)
- 起動属性と同じものを参照する現行属性リストの情報では、現行属性と起動属性の両方の名前が一致している必要があります。
- 起動後に属性を使用しない場合は、起動セクションにのみ表示されます (例えば、起動データが読み込まれるファイル名を含む構成属性)。