LoggerJSON.Formatter behaviour (logger_json v7.0.3)

View Source

Summary

Types

config()
encoder_opts()
opts()

Callbacks

format(event, config_or_opts)

Formats a log event.

new(opts)

Initializes a new formatter configuration.

Types

config()

@type config() :: term()

encoder_opts()

@type encoder_opts() :: JSON.encoder() | [Jason.encode_opt()] | term()

opts()

@type opts() :: [
  {:encoder_opts, encoder_opts()}
  | {:metadata, :all | {:all_except, [atom()]} | [atom()]}
  | {:redactors, [{module(), term()}]}
  | {atom(), term()}
]

Callbacks

format(event, config_or_opts)

@callback format(event :: :logger.log_event(), config_or_opts :: opts() | config()) ::
  iodata()

Formats a log event.

new(opts)

@callback new(opts :: opts()) :: {module(), config()}

Initializes a new formatter configuration.

Compile‑time vs. Runtime Configuration

This function can’t be used in config.exs because that file is evaluated before your application modules are compiled and loaded, so new/1 isn’t defined yet. You can only call it in config/runtime.exs or from your application code.

If you must set up the formatter in config.exs, use the tuple format: the first element is the module implementing LoggerJSON.Formatter, and the second is the options passed to new/1. For example:

config :logger, :default_handler,

formatter: {LoggerJSON.Formatters.Basic, metadata: [:request_id]}

Note that tuple‑based configs are resolved for each log entry, which can increase logging overhead.