Slf4jLoggingAppender

An Appender that forwards every log4k LoggingEvent to SLF4J — the reverse direction of the log4k-slf4j module.

Use it to adopt log4k inside an existing JVM project that already has an SLF4J backend (Logback, Log4j2, …) configured: everything emitted through the log4k API — including the entry/exit lines the log4k-compiler-plugin generates for @Logged functions — lands in that backend instead of log4k's default console appender. install performs the swap:

Slf4jLoggingAppender.install()

Forwarding uses the SLF4J 2.x fluent API and hands over the raw message pattern together with its arguments: log4k's {} placeholder rules deliberately mirror SLF4J's MessageFormatter, so substitution can be left to the backend, and structured encoders (JSON, logstash, …) keep the individual arguments instead of receiving a pre-flattened string. A Throwable on the event becomes the SLF4J cause, the event's tags are attached as key-value pairs, and when the event is span-correlated the span's traceId/spanId are attached as key-value pairs as well. Events at Level.OFF are dropped, and levels disabled in the backend cost only a no-op builder.

Two gates apply in this setup: log4k's own logger levels decide whether an event is published at all, and the backend's configuration decides whether the forwarded call is written. Keep the log4k side at least as verbose as the backend, so the backend configuration remains the single source of truth.

Because delivery goes through RootLogger's asynchronous queue, the backend observes the forwarding coroutine, not the original call site: caller-location patterns (%class, %line), %thread, and the backend timestamp refer to the moment of forwarding. The original values remain available on the LoggingEvent (thread, timestamp) for custom bridges that need full fidelity. When the event carries a compile-time io.github.smyrgeorge.log4k.SourceLocation (injected by the log4k-compiler-plugin), the real source location survives the bridge as key-value pairs named after logstash-logback-encoder's caller-data fields — caller_file_name / caller_line_number / caller_method_name — so a JSON backend renders it exactly like Logback's own caller data, even though the backend's %class/%line cannot see past the forwarding coroutine.

This appender must never run while SLF4J itself is backed by log4k (the log4k-slf4j provider): every forwarded event would be routed straight back into log4k, endlessly. Construction fails fast with a descriptive error if that binding is detected.