|
|
WLDF インスツルメンテーション コンポーネントは、要求 (HTTP リクエストまたは RMI リクエスト) をユニークに識別し、それらの要求がシステムで処理される過程を追跡する手段を提供します。システムに参加するあらゆる要求の特定の特性 (発信元のユーザ、クライアント アドレスなど) を確認し、その要求に診断コンテキストをアタッチするように WLDF をコンフィグレーションすることができます。このコンフィグレーションによって、特定の要求の経過時間などを測定でき、すべての要求がシステムを通過する際にどのように処理されているかを把握することができます。
診断コンテキストは、要求の特性を表す 64 ビットの仕分けベクトルとユニークなコンテキスト ID から構成されます。特定の要求に関連付けられたコンテキスト ID はイベント アーカイブに記録され、以下の処理に使用できます。
以下の節では、診断コンテキストのコンフィグレーションと使用のプロセスについて説明します。
診断コンテキストには、ユニークなコンテキスト ID と 64 ビットの仕分けベクトルが含まれます。仕分けベクトルには、要求に関連付けられた診断コンテキストの特性を識別するために設定されるフラグが含まれます。現在、使用可能な仕分けフラグごとに 32 ビットの仕分けベクトルが 1 つ使用されています (表 11-1 を参照)。
要求の診断コンテキストはその要求がシステムに参加したとき (たとえばクライアントで HTTP リクエストを発行したとき) に作成され、初期化されます。診断コンテキストは、要求がスレッド境界や Java 仮想マシン (Java Virtual Machine : JVM) 境界を越えてもその要求にアタッチされ続けます。診断コンテキストは、要求のライフ サイクル全体を通して存続します。
すべての診断コンテキストは、ドメイン内でユニークなコンテキスト ID によって識別されます。このコンテキスト ID は要求と共に移動するため、特定の要求がシステムで処理される過程でその要求に関連付けられたイベントやログ エントリを特定することができます。
コンテキスト情報は、64 ビットの仕分けベクトルとして要求と共に移動します。それぞれのビットは仕分けの存在を識別するフラグです。各仕分けが要求の 1 つの属性 (発信したユーザ、発信したクライアント IP アドレス、アクセス プロトコルなど) を表します。
特定の属性に対応する仕分けフラグが設定されている場合、その属性が存在することを示しています。フラグが設定されていない場合、その属性が存在しないことを示しています。
IP アドレス 127.0.0.1 から admin@avitek.com 以外のユーザの要求がシステムに参加すると、その要求の仕分けベクトルの ADDR1 フラグが設定されます。ADDR2 仕分けフラグと USER1 仕分けフラグは設定されません。
admin@avitek.com の要求が、127.0.0.1 または 127.0.0.2 以外の IP アドレスからシステムに参加すると、その要求の仕分けベクトルの USER1 フラグが設定されます。ADDR1 仕分けフラグと ADDR2 仕分けフラグは設定されません。
admin@avitek.com の要求が IP アドレス 127.0.0.2 からシステムに参加すると、この要求の仕分けベクトルの USER1 フラグと ADDR2 フラグの両方が設定されます。ADDR1 フラグは設定されません。
診断コンテキストを利用する診断およびモニタ機能では、仕分けベクトルを調査することにより、1 つまたは複数の属性が存在する (すなわち、関連付けられたフラグが設定されている) かどうかを特定することができます。上記の例では、診断モニタをコンフィグレーションすることにより、ADDR1 で仕分けされるすべての要求、つまり IP アドレス 127.0.0.1 から発信されたすべての要求を追跡できます。また、ADDR1 と USER1 の両方で仕分けされるすべての要求、すなわち、IP アドレス 127.0.0.1 のユーザ admin@avitek.com が発行した要求を追跡する診断モニタをコンフィグレーションすることもできます (この場合、127.0.0.1 のその他のユーザからの要求は追跡されません)。
また、仕分けベクトルには THROTTLE 仕分けもあります。この仕分けは、受信する要求に仕分けを設定する頻度を指定するために使用します。この特別な仕分けの詳細については、「THROTTLE 仕分けフラグ」を参照してください。
利用できる仕分けとそれによって表される属性のリストについては、「DyeInjection モニタでサポートされる仕分け」を参照してください。仕分けベクトルをコンフィグレーションおよび使用するプロセスについては、この章の以降の節で説明します。
診断コンテキストは、診断モジュールの一部としてコンフィグレーションされます。診断コンテキストをコンフィグレーションするには、サーバ レベルで DyeInjection モニタを使用します。DyeInjection モニタは標準の診断モニタであるため、その動作を変更することはできません。DyeInjection モニタがコードにウィービングされるジョインポイントは、要求がシステムに参加する可能性のある場所です。
診断アクションによって、各要求が DyeInjection モニタのコンフィグレーションに照らしてチェックされてから、その要求に診断コンテキストが作成されてアタッチされ、仕分けフラグが適切に設定されます。ある要求に対して設定されている仕分けフラグと、下流の診断モニタに対してコンフィグレーションされている仕分けフラグが一致する場合は、その要求に関連付けられたコンテキスト ID を持つイベントがイベント アーカイブに追加されます。したがって、ある要求で USER1 仕分けフラグと ADDR1 仕分けフラグのみが設定されており、USER1 フラグと ADDR1 フラグの両方が設定された (ただし、その他のフラグは設定されていない) 要求を追跡するようにコンフィグレーションされている診断モニタがある場合に、イベントはイベント アーカイブに追加されます。
診断モニタのタイプ、(ジョインポイントを定義する) ポイントカット、および診断アクションについては、「インスツルメンテーションのコンフィグレーション」を参照してください。
ここでは、サーバ スコープの診断モジュールにおけるコンテキストのコンフィグレーションと使用について概説します。
DyeInjection モニタは、WLDF 診断モジュール内でシステム レベルで有効化されている場合、その要求を調査して、仕分けベクトルでコンフィグレーションされている仕分け値のいずれかが要求の属性と一致しているかどうかを確認します。たとえば、その要求の発行元が USER1 または USER2 に関連付けられているユーザかどうか、および ADDR1 または ADDR2 に関連付けられている IP アドレスかどうかが確認されます。DyeInjection モニタは、要求の属性に一致する各仕分け値について、診断コンテキスト内で関連付けられている仕分けビットを設定します。たとえば、DyeInjection モニタが、USER1=weblogic、USER2=admin@avitek.com、ADDR1=127.0.0.1、ADDR2=127.0.0.2 のようにコンフィグレーションされており、要求の発行元が IP アドレス 127.0.0.2 のユーザ weblogic である場合、仕分けベクトル内で USER1 および ADDR2 仕分けビットが設定されます。USER1 と ADDR2) のみが仕分けベクトルに含まれます。USER1 と ADDR2 に関連付けられている実際のユーザ名と IP アドレスは含まれません。 | 注意 : | すべての仕分けベクトルには、暗黙的に PROTOCOL 仕分け群の 1 つも含まれます。これについては、「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」で説明します。 |
USER1 および ADDR2 として設定します。詳細については、「仕分けフィルタを使用するための代理モニタのコンフィグレーション」を参照してください。USER1 フラグと ADDR2 フラグが仕分けベクトルで設定されると、モニタはアクションを実行します。さらに、要求に関連するイベントがイベント アーカイブに書き込まれます。
システムに参加するすべての要求に対して診断コンテキストを作成するには、次の手順に従います。
DyeInjection モニタをコンフィグレーションするには、値を仕分けフラグに割り当てます。利用できる仕分けフラグについては、表 11-1 で説明します。
たとえば、USER1=weblogic、USER2=admin@avitek.com、ADDR1=127.0.0.1、ADDR2=127.0.0.2 などのようにフラグを設定できます。基本的に、モニタする要求の発行元となる 1 人または複数のユーザ、1 つまたは複数の IP アドレスに対して 1 つまたは複数のフラグの値を設定します。
たとえば、IP アドレスが 127.0.0.1 のクライアントから admin@avitek というユーザによって開始されたすべての要求をモニタするには、値 admin@avitek を USER1 に、値 127.0.0.1 を ADDR1 に割り当てます。
Administration Console で仕分けに値を割り当てるには、[DyeInjection の設定] ページの [プロパティ] フィールドに値を入力します。この手順については、Administration Console オンライン ヘルプの「診断システム モジュールの診断モニタのコンフィグレーション」を参照してください。
これらの設定は、診断モジュールの記述子ファイルでは以下のコード リストに示すように表されます。
<wldf-resource>
<name>MyDiagnosticModule</name>
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>DyeInjection</name>
<enabled>true</enabled>
<dye-mask xsi:nil="true"></dye-mask>
<properties>ADDR1=127.0.0.1
USER1=admin@avitek</properties>
</wldf-instrumentation-monitor>
<!-- インスツルメンテーションをコンフィグレーションするための他の要素 -->
<instrumentation>
<!-- この診断モニタをコンフィグレーションするための他の要素 -->
<wldf-resource>
仕分けベクトルで利用できる仕分けについて、以下の表にリストして説明します。
仕分けフラグ USERn、ADDRn、COOKIEn、および CONNECTORn (DyeInjection モニタ) については、明示的に値を設定する必要があります。一方、フラグ PROTOCOL_HTTP、PROTOCOL_IIOP、ROTOCOL_JRMP、PROTOCOL_RMI、PROTOCOL_SOAP、PROTOCOL_SSL、および PROTOCOL_T3 は、WLDF により暗黙的に設定されます。DyeInjection モニタが有効になっていれば、すべての要求に適切なプロトコルの仕分けが挿入されます。たとえば、HTTP によって届いた要求にはすべて仕分け PROTOCOL_HTTP が挿入されます。
THROTTLE 仕分けフラグを使用して、受信する要求のうち仕分けを設定するものの量を制御できます。THROTTLE は他のフラグとは異なる方法でコンフィグレーションされ、WLDF での使用方法も異なります。詳細については、「インスツルメンテーション イベントの量を制御するスロットル機能の使い方」を参照してください。
診断モジュールで DyeInjection モニタが有効になっている場合、受信するすべての要求について診断コンテキストが作成されます。DyeInjection モニタは、診断モジュールでインスツルメンテーションを有効にすると、デフォルトで有効になります。これにより診断コンテキスト ID が利用でき、イベントが関連付けられます。DyeInjection モニタに明示的に設定されているプロパティがない場合でも、ユニークなコンテキスト ID と、暗黙的な PROTOCOL 仕分け群のうち 1 つが指定された仕分けベクトルがすべての要求の診断コンテキストに含まれます。
DyeInjection モニタが無効化されている場合、受信する要求に対して診断コンテキストは作成されません。
| 注意 : | アプリケーション (Web アプリケーションなど) に診断モニタを実装する方法については、「アプリケーションのインスツルメントに必要な手順の概要」を参照してください。 |
DyeInjection モニタを、診断モジュールの代理診断モニタまたはカスタム診断モニタのトリガ条件を制限するメカニズムとして使用できます。このプロセスを仕分けフィルタと呼びます。
それぞれのモニタに仕分けマスクを設定できます。仕分けマスクには DyeInjection モニタから選択された仕分けが指定されます。診断モニタに対して仕分けフィルタが有効になっている場合、マスクで設定された条件に一致する要求でのみ、モニタの診断アクションがトリガされ、診断イベントが生成されます。
図 11-2 に、コンフィグレーションされている診断アクションがトリガされたときに、生成された診断イベントの例を示します。すべてのイベントのコンテキスト ID が同じであることが分かります。これは、これらのイベントが同じ要求に関連していることを示しています。このコンテキスト ID を使用して、要求に関連付けられているログ レコードを問い合わせることができます。要求に関連付けられているユーザ ID と DyeInjection モニタでコンフィグレーションした USER 値は常に同じではありません。要求がシステムで処理される過程で、その要求に関連付けられているユーザが変わることによって、システムで特定の機能を実行することができます (たとえば、ユーザ ID が kernel に変わる場合があります)。
TraceElapsedTimeAction アクションがアタッチされている Servlet_Around_Service アプリケーション スコープの診断モニタを例に考えます。仕分けフィルタを行わない場合、Servlet_Around_Service で処理されるすべての要求が TraceElapsedTimeAction をトリガします。しかし、仕分けフィルタを使用すると、IP アドレス 127.0.0.1 のユーザ admin@avitek.com が発行した要求に対してのみ TraceElapsedTimeAction をトリガすることができます。
DyeInjection モニタで USER1=admin@avitek.com および ADDR1=127.0.0.1 とコンフィグレーションして DyeInjection モニタを有効にします。この手順については、Administration Console オンライン ヘルプの「診断システム モジュールの診断モニタのコンフィグレーション」を参照してください。 Servlet_Before_Service 診断モニタの仕分けフィルタを有効にします。Administration Console で次の手順に従います。 Servlet_Around_Service モニタを追加します。詳細については、Administration Console オンライン ヘルプの「アプリケーションのインスツルメンテーションのコンフィグレーション」を参照してください。Servlet_Around_Service] リンクをクリックし、[Servlet_Around_Service の設定] ページを表示します。TraceElapsedTimeAction] を移動します。 USER1] および [ADDR1] を [使用可能] リストから [選択済み] リストへ移動します。
Administration Console で追加したコンフィグレーションは、アプリケーションの META-INF ディレクトリの weblogic-diagnostics.xml ファイルや DIAG_MODULE.xml ファイルには保持されず、アプリケーションのデプロイメント プランに保存されます。
DIAG_MODULE.xml ファイルを手作業で更新して診断モニタを追加することもできます (コード リスト 11-2 を参照) が、この方法を推奨されません。コンフィグレーションは、実行サーバの Administration Console で変更することをお勧めします。DIAG_MODULE.xml に対して行った変更は、アプリケーションを再デプロイするまで有効になりません。
<wldf-resource>
<name>MyDiagnosticModule</name>
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>DyeInjection</name>
<enabled>true</enabled>
<properties>ADDR1=127.0.0.1 USER1=admin@avitek.com</properties>
</wldf-instrumentation-monitor>
<wldf-instrumentation-monitor>
<name>Servlet_Around_Service</name>
<dye-mask>ADDR1 USER1</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>TraceElapsedTimeAction</action>
</wldf-instrumentation-monitor>
<!-- インスツルメンテーションをコンフィグレーションするための他の要素 -->
</instrumentation>
<!-- 診断モニタをコンフィグレーションするための他の要素 -->
<wldf-resource>
このコンフィグレーションでは、TraceElapsedTimeAction アクションは、IP アドレス 127.0.0.1 のユーザ admin@avitek.com が発行した要求に対してのみ、その Servlet_Around_Service 診断モニタに対してトリガされます。
アクションがトリガされ、イベントがイベント アーカイブに書き込まれるには、診断モニタで有効化されているフラグが要求の仕分けベクトルで設定されているビットと完全に一致する必要があります。たとえば、診断モニタで USER1 フラグと ADDR1 フラグの両方が有効化されており、USER1 フラグのみが要求の仕分けベクトルで設定されている場合、いずれのアクションもトリガされず、いずれのイベントも生成されません。
| 注意 : | 診断モニタをコンフィグレーションする際、同じタイプの複数のフラグを有効化しないでください。たとえば、USER1 フラグと USER2 フラグの両方を有効化しないでください。これは、特定の要求の仕分けベクトルで USER1 フラグと USER2 フラグの両方が設定されない場合があるためです。 |
要求にアタッチされる仕分けベクトルには複数の仕分けを指定でき、代理モニタにアタッチされる仕分けマスクにも複数の仕分けを指定できます。代理モニタの仕分けマスクを使用して、モニタが要求に対してアクションを実行できるようにするには、以下の条件をすべて満たしている必要があります。
図 11-3 では、3 つの診断モニタを持つ診断モジュールを使用した仕分けフィルタの仕組みを示しています。
127.0.0.1 からユーザ guest によって開始された要求がシステムに届きます。ユーザ guest は DyeInjection モニタの USER1 の値に一致しないため、この要求は仕分けベクタ USER1 で仕分けされません。発信元 IP アドレス (127.0.0.1) は DyeInjection モニタで定義された ADDR1 の値に一致するため、要求は仕分けベクタ ADDR1 で仕分けされます。 ADDR1 で仕分け済み) が Servlet コンポーネントに届きます。このコンポーネントでは、診断モニタ Servlet_Around_Service がコード内にウィービングされています (Servlet_Around_Service は特定のサーブレット メソッドまたは JSP メソッドの入り口と出口で、診断アクションをトリガします)。このモニタでは仕分けモニタが有効になっており、仕分けマスクには ADDR1 という値が 1 つ定義されています。Servlet_Around_Service でインスツルメンテーションされているメソッドに要求が入るか出るときに、診断モニタは要求に仕分けベクトル ADDR1 があるかどうかをチェックし、その仕分けベクトルが見つかります。その結果、モニタは診断アクションをトリガします。イベント アーカイブへのデータの書き込みなどの診断イベントが発生します。SessionEJB コンポーネントに届きます。このコンポーネントでは、診断モニタ EJB_Around_SessionEjbBusinessMethods がコード内にウィービングされています (EJB_Around_SessionEjbBusinessMethods は、すべての SessionBean メソッドの入り口と出口で診断アクションをトリガします)。このモニタでは仕分けモニタが有効になっており、仕分けマスクには USER1 という値が 1 つ定義されています。EJB_Around_SessionEjbBusinessMethods でインスツルメンテーションされている SessionBean メソッドに要求が入るか出るときに、診断モニタは要求に仕分けベクトル USER1 があるかどうかをチェックしますが、その仕分けベクトルは見つかりません。したがって、モニタは診断アクションをトリガしないので、診断イベントは発生しません。
スロットル機能を使用すると、診断モジュールのモニタで処理される要求の数を制御できます。スロットル機能は、DyeInjection モニタに定義される THROTTLE 仕分けを使用してコンフィグレーションします。
| 注意 : | USERn および ADDRn 仕分けを使用すると、特定のユーザまたは IP アドレスからの要求を調べることができます。ただし、任意のユーザ トランザクションを調べる手段にはなりません。THROTTLE 仕分けでは、要求のサンプリングによりその機能を提供します。 |
仕分けベクトルの他の仕分けと異なり、THROTTLE 仕分けは 2 つのプロパティを通じてコンフィグレーションされます。
THROTTLE_INTERVAL に、新しく受信される要求に THROTTLE 仕分けが指定されるまでの間隔 (ミリ秒) を設定する。
THROTTLE_INTERVAL が 0 より大きい場合、DyeInjection モニタでは、最後に THROTTLE 仕分けが指定された要求が届いてから少なくとも THROTTLE_INTERVAL のミリ秒数だけ経過した後に受信された要求に対して、その新しい要求の仕分けベクトルにある THROTTLE 仕分けフラグが設定されます。たとえば THROTTLE_INTERVAL=3000 と指定した場合、DyeInjection モニタでは少なくとも 3000 ミリ秒の待機後に、受信した要求に THROTTLE 仕分けが指定されます。
THROTTLE_RATE に、新しく受信される要求に THROTTLE 仕分けが指定される度合い (受信される要求の数で表す) を設定する。
THROTTLE_RATE が 0 より大きい場合、DyeInjection モニタでは、最後に THROTTLE 仕分けが設定された要求以降の要求の数が THROTTLE_RATE と同じになったときに、受信された要求の仕分けベクトルにある THROTTLE 仕分けフラグが設定されます。たとえば、THROTTLE_RATE = 6 と指定した場合、6 要求ごとに THROTTLE 仕分けが指定されます。
THROTTLE_INTERVAL と THROTTLE_RATE は併用できます。いずれかの要求を満たす場合、要求は THROTTLE 仕分けで仕分けされます。
THROTTLE_INTERVAL または THROTTLE_RATE のどちらかに値を割り当てる場合 (両方に割り当てることもどちらにも割り当てないことも可)、THROTTLE 仕分けがコンフィグレーションされます。Administration Console での THROTTLE コンフィグレーションの設定を、以下の図に示します。
コード リスト 11-3 に、結果として診断モジュールの記述子ファイルに記述されるコンフィグレーションを示します。
<wldf-resource>
<name>MyDiagnosticModule</name>
<instrumentation>
<wldf-instrumentation-monitor>
<name>DyeInjection</name>
<properties>
THROTTLE_INTERVAL=3000
THROTTLE_RATE=6
</properties>
</wldf-instrumentation-monitor>
</instrumentation>
<!-- この診断モニタをコンフィグレーションするための他の要素 -->
</wldf-resource>
コード リスト 11-4 に、仕分けマスクに THROTTLE 仕分けが設定されている JDBC_Before_Start_Internal 代理モニタのコンフィグレーションを示します。
<wldf-resource>
<name>MyDiagnosticModule</name>
<instrumentation>
<wldf-instrumentation-monitor>
<name>JDBC_Before_Start_Internal</name>
<enabled>true</enabled>
<dye-mask>THROTTLE</dye-mask>
</wldf-instrumentation-monitor>
</instrumentation>
<!-- この診断モニタをコンフィグレーションするための他の要素 -->
</wldf-resource>
仕分けマスクおよび仕分けフィルタによるメカニズムを使用して、代理モニタおよびカスタム モニタで処理するために渡す要求を、要求のプロパティに基づいて制限できます。「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」で説明したように、要求におけるプロパティの存在は仕分けの存在によって示されます。THROTTLE 仕分けもそうした仕分けの 1 つと見なされるため、THROTTLE も他の仕分けと同様にフィルタできます。
THROTTLE 仕分けが含まれても含まれなくても構いません。仕分けマスクに THROTTLE が含まれる場合、モニタに渡される要求の仕分けベクトルにも THROTTLE が含まれている必要があります。一方、仕分けマスクに THROTTLE が含まれない場合、要求の仕分けベクトルに THROTTLE が含まれているかどうかに関わらず、適格な要求はすべてモニタに渡されます。DyeInjection モニタに THROTTLE プロパティが設定されていない場合、仕分けフィルタもスロットル機能も実行されない。DyeInjection モニタに THROTTLE がコンフィグレーションされている場合、代理モニタでは仕分けマスクが無視されるが、すべての要求について THROTTLE 仕分けの存在がチェックされる。THROTTLE 仕分けの指定された要求のみが代理モニタに渡されて処理されます。したがって、THROTTLE_RATE または THROTTLE_INTERVAL (あるいはその両方) を DyeInjection モニタに設定すると、すべての代理モニタで処理される要求の数が減少します。スロットル機能を利用するために、すべての代理モニタに仕分けマスクをコンフィグレーションする必要はありません。THROTTLE のみの場合、THROTTLE 仕分けが指定されている要求のみが代理モニタに渡される。この動作は、仕分けフィルタが有効でなく DyeInjection モニタに THROTTLE がコンフィグレーションされている場合と同じです。
weblogic.diagnostics.context パッケージを使用すると、アプリケーションから診断コンテキストに制限付きでアクセスできます。
アプリケーションでは一連の weblogic.diagnostics.context.DiagnosticContextHelper API を使用して、以下の関数を実行できます。
DYE_0 から DYE_7 までのフラグについての設定または設定の解除 (これらのフラグ ビットを XML を介して設定する方法はありません。DyeInjection モニタの <properties> をコンフィグレーションすると、アプリケーション固有でないフラグ ビットについて XML を介して設定できますが、仕分けベクトルの DYE_0 から DYE_7 までを設定できるのは setDye() メソッドのみです)。
アプリケーションで DYE_0 から DYE_7 までのフラグのうち 1 つまたは複数を設定した時点以降には、モニタや別のアプリケーションでそれらのフラグをチェックするように仕分けマスクを設定し、そのフラグ (群) がコンテキストの仕分けベクトルに存在する場合にアクションを実行できます。診断コンテキストにペイロードがアタッチされている場合、モニタで実行されるアクションはペイロードに格納されてアーカイブ化され、結果としてアクセサ コンポーネントを通じて利用できるようになります。
コード リスト 11-5 は、診断コンテキストを (暗黙的に) 作成し、コンテキスト ID を出力して、DYE_0 フラグの値をチェックした上で設定する簡単なサンプルです。
package weblogic.diagnostics.examples;
import weblogic.diagnostics.context.DiagnosticContextHelper;
public class DiagnosticContextExample {
public static void main(String args[]) throws Exception {
System.out.println("\nContextId=" +
DiagnosticContextHelper.getContextId());
System.out.println("isDyedWith(DYE_0)=" +
DiagnosticContextHelper.isDyedWith(DiagnosticContextHelper.DYE_0));DiagnosticContextHelper.setDye(DiagnosticContextHelper.DYE_0, true);
System.out.println("isDyedWith(DYE_0)=" +
DiagnosticContextHelper.isDyedWith(DiagnosticContextHelper.DYE_0));
}
}
  
|