Skip to content

Logging

The logging system allows you to create and use custom loggers.

Instead of using System.out.println or mixing different logging approaches, all logging should go through a unified system:

  • plugin.getLogger() (Bukkit default)
  • or the Core API LoggerHandler

Internally, the system uses Logback for structured and configurable logging.


When to use?

Use the Core logging system when:

  • you want separate log files per system/feature
  • you need structured debugging or tracking
  • logs should persist independently from the main server log
  • multiple systems should not spam the main console

Use plugin.getLogger() only for:

  • simple plugin lifecycle logs (enable/disable)
  • small debug messages

How to use (Example)

Get the LoggerHandler

LoggerHandler loggerHandler = BukkitCoreLibrary.getLoggerHandler();

Register a logger

Logger logger = loggerHandler.registerLogger("example");

Log messages

logger.info("This is an info message");
logger.warn("Something might be wrong");
logger.error("Something went wrong");

API Overview

Get existing logger

Logger logger = loggerHandler.getLogger("example");

Returns null if no logger is registered.


Get all loggers

Collection<Logger> loggers = loggerHandler.getLoggers();

Get all logger names

Collection<String> names = loggerHandler.getLoggerNames();

Register logger (default)

Logger logger = loggerHandler.registerLogger("name");
  • Uses the same name as directory
  • Most commonly used method

Register logger (custom directory)

Logger logger = loggerHandler.registerLogger("name", "directory");
  • Custom directory for logs
  • Example path: /loggers/directory/logs

Where are the logs stored?

All logs are stored in: /loggers/%name%/logs

Inside the server directory.


Configuration

Each logger has its own config file: /loggers/%name%/config.json

Default behavior

  • Logs are stored for 7 days
  • Logs are NOT printed to the main console

Customize behavior

You can configure:

  • log retention (history duration)
  • console output (enable/disable)

Common pitfalls

Logger already registered

loggerHandler.registerLogger("example"); // throws if already exists

→ Always ensure the logger is only registered once (e.g. on plugin startup)


Null logger

Logger logger = loggerHandler.getLogger("example");

→ May return null, always check before usage


Console spam expectations

→ Core loggers do NOT log to console by default

If you expect console output:

  • enable it in config.json

Naming

  • Logger names are case-insensitive
  • Still use consistent naming (feature-name, system-name)

Summary

  • Use Core logging for structured, persistent logs
  • Keep systems separated via named loggers
  • Configure behavior via config.json
  • Avoid mixing logging systems randomly