Logger クラス

定義

[Android.Runtime.Register("java/util/logging/Logger", DoNotGenerateAcw=true)]
public class Logger : Java.Lang.Object

[<Android.Runtime.Register("java/util/logging/Logger", DoNotGenerateAcw=true)>]
type Logger = class
    inherit Object

継承

Object

Object

Logger

属性

RegisterAttribute

注釈

Logger オブジェクトは、特定のシステムまたはアプリケーション コンポーネントのメッセージをログに記録するために使用されます。 ロガーには通常、階層的なドット区切り名前空間を使用して名前が付けられます。 ロガー名は任意の文字列にすることができますが、通常は、java.net や javax.swing など、ログに記録されたコンポーネントのパッケージ名またはクラス名に基づく必要があります。 さらに、Logger 名前空間に格納されていない "匿名" ロガーを作成することもできます。

ロガー オブジェクトは、getLogger ファクトリ メソッドの呼び出しによって取得できます。 これらは、新しいロガーを作成するか、適切な既存のロガーを返します。 ロガーへの厳密な参照が保持されていない場合、ファクトリ メソッドの getLogger 1 つによって返されるロガーはいつでもガベージ コレクションされる可能性があることに注意してください。

ログ メッセージは登録済みの Handler オブジェクトに転送され、コンソール、ファイル、OS ログなど、さまざまな宛先にメッセージを転送できます。

各ロガーは、Logger 名前空間の最も近い既存の先祖である "親" ロガーを追跡します。

各ロガーには、"レベル" が関連付けられています。 これは、このロガーが考慮する最小レベルを反映しています。 ロガーのレベルが設定 nullされている場合、その有効なレベルはその親から継承され、その後、その親から再帰的に取得される可能性があります。

ログ レベルは、LogManager クラスの説明で説明されているように、ログ構成ファイルのプロパティに基づいて構成できます。 ただし、Logger.setLevel メソッドの呼び出しによって動的に変更される場合もあります。 ロガーのレベルが変更された場合、そのレベルを持つ子ロガーは null 親から有効なレベルを継承するため、変更が子ロガーにも影響する可能性があります。

各ログの呼び出しで、ロガーは最初に、ロガーの有効なログ レベルに対して要求レベル (SEVERE や FINE など) の安いチェックを実行します。 要求レベルがログ レベルより低い場合、ログの呼び出しはすぐに返されます。

この初期 (安価な) テストに合格すると、ロガーはログ メッセージを記述する LogRecord を割り当てます。 その後、Filter (存在する場合) を呼び出して、レコードを公開する必要があるかどうかをより詳細に確認します。 それが渡された場合は、LogRecord を出力ハンドラーに発行します。 既定では、ロガーは親のハンドラーにも公開し、ツリーを再帰的に上に発行します。

各ロガーに ResourceBundle 関連付けられている場合があります。 名前 ResourceBundle 、ファクトリ メソッド、 #getLogger(java.lang.String, java.lang.String) または値で指定できます。メソッドを #setResourceBundle(java.util.ResourceBundle) setResourceBundle 使用します。 このバンドルは、ログ メッセージのローカライズに使用されます。 ロガーに独自 ResourceBundle のバンドル名またはリソース バンドル名がない場合は、親からまたはリソース バンドル名を継承 ResourceBundle し、ツリーを再帰的に上に継承します。

ほとんどのロガー出力メソッドは、"msg" 引数を受け取ります。 この msg 引数には、生の値またはローカライズ キーを指定できます。 書式設定中に、ロガーがローカライズ ResourceBundle を持っている (または継承する) 場合、およびメッセージ文字列のマッピングがある場合 ResourceBundle 、メッセージ文字列はローカライズされた値に置き換えられます。 それ以外の場合は、元のメッセージ文字列が使用されます。 通常、フォーマッタは java.text.MessageFormat スタイルの書式設定を使用してパラメーターを書式設定するため、書式指定文字列 "{0}{1}" は 2 つのパラメーターを文字列として書式設定します。

一連のメソッドは、"msg" 引数の代わりに "msgSupplier" を受け取ります。 これらのメソッドは、メッセージが実際に有効なログ レベルに基づいてログに記録される場合にのみ、必要なログ メッセージを構築するために呼び出される関数を受け取ります Supplier<String> 。これにより、不要なメッセージの構築が排除されます。 たとえば、開発者が診断のためにシステムの正常性状態をログに記録し、文字列を受け入れるバージョンを使用する場合、コードは次のようになります。

<code>

               class DiagnosisMessages {
                 static String systemHealthStatus() {
                   // collect system health information
                   ...
                 }
               }
               ...
               logger.log(Level.FINER, DiagnosisMessages.systemHealthStatus());
</code>

上記のコードでは、ログ レベル FINER が無効になっている場合でも、正常性状態が不必要に収集されます。 以下のような仕入先受け入れバージョンでは、ログ レベル FINER が有効になっている場合にのみ状態が収集されます。

<code>

               logger.log(Level.FINER, DiagnosisMessages::systemHealthStatus);
</code>

ResourceBundle検索時に、ロガーはまず、バンドルが使用して指定されたかどうかを調べます。次に、ファクトリ メソッドを使用#setResourceBundle(java.util.ResourceBundle) setResourceBundleして#getLogger(java.lang.String, java.lang.String) getLoggerリソース バンドル名が指定されたかどうかのみが確認されます。 リソース バンドル名が見つからない ResourceBundle 場合、または見つからない場合は、親ツリーから継承された最も近い ResourceBundle 名前またはリソース バンドル名が使用されます。<br> a ResourceBundle がメソッドを通じて #setResourceBundle(java.util.ResourceBundle) setResourceBundle 継承または指定された場合、それが ResourceBundle 使用されます。 それ以外の場合、ロガーにリソース バンドル名のみが含まれるか継承されている場合、そのリソース バンドル名は、ログ記録時の ResourceBundle 既定のロケールを使用してオブジェクトにマップされます。 <br id="ResourceBundleMapping">リソース バンドル名をオブジェクトに ResourceBundle マッピングする場合、ロガーは最初に Thread の java.lang.Thread#getContextClassLoader() コンテキスト クラス ローダーを使用して、指定されたリソース バンドル名を ResourceBundle. スレッド コンテキスト クラス ローダーの場合は null、代わりに java.lang.ClassLoader#getSystemClassLoader() システム クラス ローダーを試します。 ResourceBundleまだ見つからない場合は、ファクトリ メソッドの最初の呼び出し元のクラス ローダーを#getLogger(java.lang.String, java.lang.String) getLogger使用します。

書式設定 (ローカライズを含む) は、通常フォーマッタを呼び出す出力ハンドラーの役割です。

書式設定は同期的に行う必要はありません。 LogRecord が実際に外部シンクに書き込まれるまで、遅延する可能性があります。

ログ方法は、次><の 5 つの主要なカテゴリにグループ化されています。 <>

ログ レベル、メッセージ文字列、および必要に応じてメッセージ文字列にいくつかのパラメーターを受け取る一連の "log" メソッドがあります。 <李>

"log" メソッドに似た一連の "logp" メソッド ("log precise" の場合) がありますが、明示的なソース クラス名とメソッド名も受け取ります。 <李>

"logp" メソッドのような一連の "logrb" メソッド ("リソース バンドルを含むログ" の場合) がありますが、ログ メッセージのローカライズに使用するために明示的なリソース バンドル オブジェクトも受け取ります。 <李>

メソッド エントリ ("entering" メソッド)、メソッドの戻り値 ("終了" メソッド)、および例外のスロー ("スロー" メソッド) をトレースするための便利なメソッドがあります。 <李>

最後に、開発者が特定のログ レベルで単純な文字列をログに記録するだけの場合に、非常に単純なケースで使用するための便利なメソッドのセットがあります。 これらのメソッドは、標準のレベル名 ("severe"、"warning"、"info"など) の後に名前が付けられ、1 つの引数、メッセージ文字列を受け取ります。 </ul>

明示的なソース名とメソッド名を受け取らないメソッドの場合、ログ 記録フレームワークは、ログ 記録メソッドに呼び出されるクラスとメソッドを決定するための "ベスト エフォート" を行います。 ただし、この自動的に推論される情報はおおよその情報 (またはまったく間違っている可能性があります) のみである可能性があることに注意することが重要です。 仮想マシンは、JITing 時に広範な最適化を実行でき、スタック フレームを完全に削除できるため、呼び出し元のクラスとメソッドを確実に見つけることができなくなります。

Logger のすべてのメソッドは、マルチスレッド セーフです。

<b>サブクラス化情報:</b> LogManager クラスは、名前空間内の任意のポイントに対して名前付きロガーの独自の実装を提供する場合があることに注意してください。 したがって、Logger のサブクラス (新しい LogManager クラスと組み合わせて実装されている場合を除く) は、LogManager クラスから Logger インスタンスを取得するように注意する必要があり、"isLoggable" や "log(LogRecord)" などの操作をそのインスタンスに委任する必要があります。 すべてのログ出力をインターセプトするために、サブクラスは log(LogRecord) メソッドのみをオーバーライドする必要があることに注意してください。 他のすべてのログ メソッドは、この log(LogRecord) メソッドの呼び出しとして実装されます。

1.4 で追加されました。

の Java ドキュメントjava.util.logging.Logger

このページの一部は、Android オープンソース プロジェクトによって作成および共有され、クリエイティブ コモンズ 2.5 属性ライセンスに記載されている条件に従って使用される作業に基づく変更です。

コンストラクター

フィールド

プロパティ

メソッド

明示的なインターフェイスの実装

拡張メソッド

適用対象