Loggen und Debugging

Es sind einige Protokollierungsframeworks für Java verfügbar. Das Protokollieren (loggen) ist der Ausgabe von Meldungen und Fehlern durch stdout und stderr durch System.out.println() aus mehreren Gründen vorzuziehen:

  • Protokollierte Nachrichten sind mit einem Quellnamen versehen um die Zuordnung zu erleichtern.
  • Protokollierte Nachrichten haben einen Relevanz Index, nach dem einfach gefiltert werden kann (z.B. alle unkritischen Nachrichten abschalten)
  • Die verfügbaren Protokollierungsframeworks erlauben es dir Nachrichten von den gewünschten Quellen aus- oder einzublenden.

Sponge benutzt org.slf4j.Logger und nicht java.util.logging.Logger.

Protokollieren eines Plugins

Das Guice Modul nutzt während der Initialisierung der Plugins einen speziellen auf die Plugins ausgerichteten Logger. Dies ermöglicht es eine Anmerkung (@Inject) an ein Feld (englisch field), eine Methode oder einen Constructor anzuhängen um einen Logger, der mit der korrekten Plugin ID vorkonfiguriert ist, zu erhalten.

Bemerkung

Unter Hauptklasse des Plugins sind Informationen verfügbar, wie die Plugin-ID geändert werden kann.

Beispiel - Feld

import com.google.inject.Inject;
import org.slf4j.Logger;

@Inject
private Logger logger;

Beispiel - Methode

private Logger logger;

@Inject
private void setLogger(Logger logger) {
    this.logger = logger;
}

Beispiel - Konstruktor

// For the purpose of this example, "Banana" is the class name

private Logger logger;

@Inject
public Banana(Logger logger) {
    this.logger = logger;
}

Es ist empfohlen die Protokollierung in der Main Klasse des Plugins festzulegen, weil so mit dem Guice Injector ein entsprechendes Objekt beim Laden des Plugins erstellt wird.

Einen Getter für den Logger in derselben Klasse, in der er gesetzt wurde zu erstellen ist ideal, allerdings optional. Ein Beispiel für so einen Getter ist nachfolgend dargestellt.

public Logger getLogger() {
    return logger;
}

Nachrichten ausgeben

Es ist sehr einfach eine Nachricht durch den Logger auszugeben.

Bemerkung

Das folgende Beispiel nimmt an, dass der Getter für den Logger getLogger() genannt wurde, wie es in dem vorherigem Abschnitt gezeigt wurde. Je nach Name des Getter muss das Beispiel abgeändert werden.

getLogger().info("String");
getLogger().debug("String");
getLogger().warn("String");
getLogger().error("String");

Der String ist die Nachricht, die ausgegeben werden soll. Zum Beispiel:

getLogger().warn("This is a warning!");

Manipulating the Logging

Bemerkung

These techniques should only be used in very rare cases such as badly chosen logging defaults in libraries. Add a config option to disable those if you use them.

Some libraries use bad logging practices such as logging on too high a level. In these cases, you have three choices:

  1. Ask the author of that library to adjust their logging standards, as this fixes the problem at its source.

  2. Recommend your users to configure the logging using a log4j2.xml config file. Provide users with the recommended configuration additions.

  3. Configure the logging in your plugin yourself:

    ((org.apache.logging.log4j.core.Logger) LogManager.getLogger("FtpLoggingFilter")).setLevel(Level.WARN);
    

    This configures the log level of the FtpLoggingFilter logger to WARN. This will hide all messages that use a lower log level such as INFO and DEBUG.

    Warnung

    This solution assumes that log4j2 is used as logging framework by the server, however that might not be the case for all/future implementations of the SpongeAPI.

If you have any questions regarding logging you can always ask us on IRC, Discord or the Forums.