Logger Klasse

Definition

[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

Vererbung

Object

Object

Logger

Attribute

RegisterAttribute

Hinweise

Ein Logger-Objekt wird verwendet, um Nachrichten für eine bestimmte System- oder Anwendungskomponente zu protokollieren. Logger werden normalerweise mit einem hierarchischen punkttrennten Namespace benannt. Loggernamen können beliebige Zeichenfolgen sein, aber sie sollten normalerweise auf dem Paketnamen oder klassennamen der protokollierten Komponente basieren, z. B. java.net oder javax.swing. Darüber hinaus ist es möglich, "anonyme" Logger zu erstellen, die nicht im Logger-Namespace gespeichert sind.

Logger-Objekte können durch Aufrufe einer der getLogger-Factorymethoden abgerufen werden. Diese erstellen entweder einen neuen Logger oder geben einen geeigneten vorhandenen Logger zurück. Es ist wichtig zu beachten, dass der von einer der getLogger Factorymethoden zurückgegebene Logger jederzeit garbage collection sein kann, wenn ein starker Verweis auf den Logger nicht aufbewahrt wird.

Die Protokollierung von Nachrichten wird an registrierte Handlerobjekte weitergeleitet, die die Nachrichten an eine Vielzahl von Zielen weiterleiten können, einschließlich Konsolen, Dateien, Betriebssystemprotokolle usw.

Jeder Logger verfolgt einen "übergeordneten" Logger, der sein nächster vorhandener Vorgänger im Logger-Namespace ist.

Jedem Logger ist ein "Level" zugeordnet. Dies spiegelt ein Mindestniveau wider, bei dem sich dieser Logger kümmert. Wenn die Ebene eines Loggers auf null" festgelegt ist, wird die effektive Ebene von seinem übergeordneten Element geerbt, was wiederum rekursiv von seinem übergeordneten Element und so weiter oben die Struktur abruft.

Die Protokollebene kann basierend auf den Eigenschaften aus der Protokollierungskonfigurationsdatei konfiguriert werden, wie in der Beschreibung der LogManager-Klasse beschrieben. Es kann jedoch auch dynamisch durch Aufrufe der Logger.setLevel-Methode geändert werden. Wenn die Ebene eines Loggers geändert wird, kann sich die Änderung auch auf untergeordnete Logger auswirken, da alle untergeordneten Logger, die über die Ebene verfügt null , ihre effektive Ebene von ihrem übergeordneten Element erben.

Bei jedem Protokollierungsaufruf führt der Logger zunächst eine billige Überprüfung der Anforderungsstufe (z. B. SEVERE oder FINE) auf die effektive Protokollebene des Loggers durch. Wenn die Anforderungsebene niedriger als die Protokollebene ist, wird der Protokollierungsaufruf sofort zurückgegeben.

Nachdem sie diesen (billigen) Test bestanden haben, weist der Logger einen LogRecord zu, um die Protokollierungsmeldung zu beschreiben. Anschließend wird ein Filter (sofern vorhanden) aufgerufen, um eine detailliertere Überprüfung zu unternehmen, ob der Datensatz veröffentlicht werden soll. Wenn dies übergeben wird, wird der LogRecord in seinen Ausgabehandlern veröffentlicht. Standardmäßig veröffentlichen Logger auch die Handler ihrer übergeordneten Elemente, rekursiv die Struktur nach oben.

Jeder Logger kann damit ResourceBundle verbunden sein. Die ResourceBundle Angabe kann anhand des Namens, mithilfe der #getLogger(java.lang.String, java.lang.String) Factorymethode oder des Werts mithilfe der #setResourceBundle(java.util.ResourceBundle) setResourceBundle Methode erfolgen. Dieses Bündel wird zum Lokalisieren von Protokollnachrichten verwendet. Wenn ein Logger nicht über einen eigenen ResourceBundle Namen oder einen Ressourcenbundlenamen verfügt, erbt er den ResourceBundle Namen des Ressourcenpakets von seinem übergeordneten Element, rekursiv nach oben in der Struktur.

Die meisten Loggerausgabemethoden verwenden ein "msg"-Argument. Dieses Msg-Argument kann entweder ein Unformatierter Wert oder ein Lokalisierungsschlüssel sein. Wenn der Logger während der Formatierung eine Lokalisierung ResourceBundle hat (oder erbt), und wenn die ResourceBundle Zuordnung für die msg-Zeichenfolge vorhanden ist, wird die msg-Zeichenfolge durch den lokalisierten Wert ersetzt. Andernfalls wird die ursprüngliche msg-Zeichenfolge verwendet. In der Regel verwenden Formatierer java.text.MessageFormat-Formatformatierung zum Formatieren von Parametern. Beispielsweise würde eine Formatzeichenfolge "{0}{1}" zwei Parameter als Zeichenfolgen formatieren.

Eine Reihe von Methoden verwenden alternativ ein "msgSupplier" anstelle eines "msg"-Arguments. Diese Methoden verwenden eine Supplier<String> Funktion, die aufgerufen wird, um die gewünschte Protokollnachricht nur zu erstellen, wenn die Nachricht tatsächlich basierend auf der effektiven Protokollebene protokolliert werden soll, sodass unnötige Nachrichtenerstellung eliminiert wird. Wenn der Entwickler z. B. den Systemintegritätsstatus für die Diagnose protokollieren möchte, würde der Code mit der Zeichenfolgenzusageversion wie folgt aussehen:

<code>

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

Mit dem obigen Code wird der Integritätsstatus unnötig gesammelt, auch wenn die Protokollebene FINER deaktiviert ist. Wenn die Vom Lieferanten akzeptierte Version wie unten angegeben angezeigt wird, wird der Status nur erfasst, wenn die FEINR-Protokollebene aktiviert ist.

<code>

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

Bei der Suche nach einem ResourceBundleLogger wird zunächst geprüft, ob ein Bundle mit #setResourceBundle(java.util.ResourceBundle) setResourceBundleder Factorymethode angegeben wurde, und dann nur, ob ein Ressourcenbundlename über die #getLogger(java.lang.String, java.lang.String) getLogger Factorymethode angegeben wurde. Wenn kein ResourceBundle oder kein Ressourcenbundlename gefunden wird, verwendet es den nächstgelegenen namen oder den Ressourcenbundlenamen, der von der übergeordneten ResourceBundle Struktur geerbt wurde.<br> Wenn eine ResourceBundle über die #setResourceBundle(java.util.ResourceBundle) setResourceBundle Methode geerbt oder angegeben wurde, dann wird dies ResourceBundle verwendet. Andernfalls, wenn der Logger nur einen Ressourcenbundlenamen hat oder geerbt hat, wird dieser Ressourcenbundlename einem ResourceBundle Objekt zugeordnet, wobei das Standardgebietsschema zum Zeitpunkt der Protokollierung verwendet wird. <br id="ResourceBundleMapping">When mapping resource bundle names to ResourceBundle objects, the logger will first try to use the Thread's java.lang.Thread#getContextClassLoader() context class loader to map the given resource bundle name to a ResourceBundle. Wenn das Laden der Threadkontextklasse lautet null, versuchen Sie es stattdessen mit dem Systemklassenladeprogramm "java.lang.ClassLoader#getSystemClassLoader()". Wenn die ResourceBundle Datei immer noch nicht gefunden wird, wird das Klassenladeprogramm des ersten Aufrufers der #getLogger(java.lang.String, java.lang.String) getLogger Factorymethode verwendet.

Die Formatierung (einschließlich Lokalisierung) liegt in der Verantwortung des Ausgabehandlers, der in der Regel einen Formatierer aufruft.

Beachten Sie, dass die Formatierung nicht synchron erfolgen muss. Es kann verzögert werden, bis ein LogRecord tatsächlich in eine externe Spüle geschrieben wird.

Die Protokollierungsmethoden sind in fünf Hauptkategorien gruppiert: <ul><li>

Es gibt eine Reihe von "log"-Methoden, die eine Protokollebene, eine Nachrichtenzeichenfolge und optional einige Parameter für die Nachrichtenzeichenfolge verwenden. <Li>

Es gibt eine Reihe von "logp"-Methoden (für "log precise"), die wie die "log"-Methoden sind, aber auch einen expliziten Quellklassennamen und Methodennamen verwenden. <Li>

Es gibt eine Reihe von "logrb"-Methoden (für "Log with resource bundle"), die wie die "logp"-Methode sind, aber auch ein explizites Ressourcenbundle-Objekt für die Lokalisierung der Protokollmeldung verwenden. <Li>

Es gibt Komfortmethoden für Ablaufverfolgungsmethodeneinträge (die "eingabe"-Methoden), Methodenrückgänge (die "exiting"-Methoden) und Auslösen von Ausnahmen (die "Throwing"-Methoden). <Li>

Schließlich gibt es eine Reihe von Komfortmethoden für die Verwendung in den einfachsten Fällen, wenn ein Entwickler einfach eine einfache Zeichenfolge auf einer bestimmten Protokollebene protokollieren möchte. Diese Methoden werden nach den Standardnamen der Ebene ("schwere", "Warnung", "Info" usw.) benannt und nehmen ein einzelnes Argument, eine Nachrichtenzeichenfolge. </ul>

Für die Methoden, die keinen expliziten Quellnamen und Methodennamen verwenden, führt das Protokollierungsframework einen "besten Aufwand" aus, um zu bestimmen, welche Klasse und Methode in die Protokollierungsmethode aufgerufen wird. Es ist jedoch wichtig zu erkennen, dass diese automatisch abgeleiteten Informationen nur ungefähr (oder sogar ganz falsch sein können!). Virtuelle Computer können umfangreiche Optimierungen durchführen, wenn JITing ausgeführt wird und stapelframes vollständig entfernt werden können, wodurch es unmöglich ist, die aufrufende Klasse und Methode zuverlässig zu finden.

Alle Methoden für Logger sind multithreadsicher.

<b>Subclassing Information:</b> Beachten Sie, dass eine LogManager-Klasse möglicherweise eine eigene Implementierung von benannten Loggers für einen beliebigen Punkt im Namespace bereitstellen kann. Daher sollten alle Unterklassen von Logger (es sei denn, sie werden in Verbindung mit einer neuen LogManager-Klasse implementiert), um eine Logger-Instanz aus der LogManager-Klasse abzurufen und Vorgänge wie "isLoggable" und "log(LogRecord)" an diese Instanz zu delegieren. Beachten Sie, dass Zum Abfangen aller Protokollierungsausgabe unterklassen nur die Log(LogRecord)-Methode außer Kraft setzen müssen. Alle anderen Protokollierungsmethoden werden als Aufrufe dieser LogRecord-Methode implementiert.

In 1.4 hinzugefügt.

Java-Dokumentation für java.util.logging.Logger.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die vom Android Open Source-Projekt erstellt und freigegeben werden und gemäß den in der Creative Commons 2.5 Attribution License beschriebenen Begriffen verwendet werden.

Konstruktoren

Felder

Eigenschaften

Methoden

Explizite Schnittstellenimplementierungen

Erweiterungsmethoden

Gilt für: