Using the Logger

Complete guide to using the Logger class for plugin logging. Learn about all log levels, configuration options, multiline support, and best practices for logging in your plugins.

The zAPI Logger class provides a powerful and flexible logging system for your plugin with support for different log levels, multiline messages, debug mode, custom prefixes, and automatic formatting.

Table of Contents

Overview

The Logger class wraps Bukkit's component logger system with additional features:

  • Multiple log levels: info, warn, error, debug, trace

  • Custom prefixes: Brand your log messages

  • Debug mode: Toggle detailed logging on/off

  • Multiline support: Automatically handles text blocks and multiline strings

  • MiniMessage formatting: Use colors and formatting in logs

  • Exception handling: Proper throwable logging with stack traces

Getting Started

Using the Default zAPI Logger

zAPI provides a default logger that's already configured:

Creating a Custom Logger for Your Plugin

It's recommended to create your own logger with a custom prefix:

Constructor Options

Log Levels

The Logger class provides five logging levels, each serving a specific purpose:

info() - General Information

Use for normal operational messages that highlight the progress of the application.

When to use:

  • Plugin initialization/shutdown

  • Feature activation

  • Successful operations

  • General status updates

Output format:

warn() - Warning Messages

Use for potentially harmful situations that don't prevent the application from functioning.

When to use:

  • Deprecated API usage

  • Recoverable errors

  • Configuration issues with fallbacks

  • Missing optional dependencies

  • Performance concerns

Output format:

error() - Error Messages

Use for error events that might still allow the application to continue running.

When to use:

  • Failed operations that affect functionality

  • Database errors

  • File I/O errors

  • Critical feature failures

  • API errors

Output format:

With exception:

debug() - Debug Information

Use for detailed information useful during development and troubleshooting. Only displayed when debug mode is enabled.

When to use:

  • Variable values during execution

  • Method entry/exit points

  • Cache operations

  • Algorithm steps

  • Performance metrics

  • Troubleshooting information

Output format (only when debug mode is enabled):

Note: Debug messages use INFO level internally but are only shown when setDebugMode(true) is called.

trace() - Trace Information

Use for very detailed information, typically only interesting when diagnosing problems.

When to use:

  • Method entry/exit in critical paths

  • Detailed variable state

  • Low-level system operations

  • Rare troubleshooting scenarios

Output format:

Configuration

Setting a Custom Prefix

You can change the prefix at any time:

Getting the Current Prefix

circle-check

Debug Mode

Debug mode controls whether debug() messages are displayed:

Example usage:

Advanced Features

Multiline Messages

The Logger automatically handles multiline strings correctly:

Output:

Using MiniMessage Formatting

The logger supports MiniMessage formatting in messages:

Exception Logging with Debug Mode

When debug mode is enabled, exceptions include full stack traces:

When debug mode is disabled, only the last line includes the exception:

Conditional Logging

Best Practices

1. Use Appropriate Log Levels

2. Create a Logger Manager

3. Use Debug Mode Appropriately

4. Include Context in Messages

5. Don't Log Sensitive Information

6. Use Exceptions Properly

7. Avoid Excessive Logging

8. Structure Messages Consistently

Complete Examples

Example 1: Plugin Initialization with Detailed Logging

Example 2: Feature Manager with Logging

Example 3: Configuration Validator with Detailed Logging

Common Patterns

Pattern 1: Startup Sequence

Pattern 2: Error Recovery

Pattern 3: Performance Monitoring

See Also

Last updated

Was this helpful?