Log4j Kotlin API

Log4j Kotlin API provides a Kotlin-friendly interface to log against the Log4j API. The minimum requirements are Java 8 and Kotlin 1.6.21.

This is just a logging API. Your application still needs to have a logging backend (e.g., Log4j) configured.

Dependencies

You need to have the org.apache.logging.log4j:log4j-api-kotlin dependency in your classpath:

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-api-kotlin</artifactId>
  <version>1.5.0-SNAPSHOT</version>
</dependency>

Java module name and OSGi Bundle-SymbolicName are set to org.apache.logging.log4j.api.kotlin.

Usage

You can start using the wrapper by extending from the provided Logging interface:

import org.apache.logging.log4j.kotlin.Logging

class MyClass: BaseClass, Logging {

  fun doStuff() {
    logger.info("Doing stuff")
  }

  fun doStuffWithUser(user: User) {
    logger.info { "Doing stuff with ${user.name}." }
  }

}

The Logging interface can also be mixed into object declarations, including companions. This is generally preferable over the previous approach as there is a single logger created for every instance of the class.

import org.apache.logging.log4j.kotlin.Logging

class MyClass: BaseClass {

  companion object : Logging

  // ...

}

Alternatively, a more traditional style can be used to instantiate a logger instance:

import org.apache.logging.log4j.kotlin

class MyClass: BaseClass {

  val logger = logger()

  // ...

}

The function logger() is an extension function on the Any type (or more specifically, any type T that extends Any).

Beginning in version 1.3.0, an extension property is also available on classes:

import org.apache.logging.log4j.kotlin.logger

class MyClass: BaseClass {

  fun doStuff() {
    logger.info("Hello, world!")
  }

}

Also added in version 1.3.0, the ThreadContext API has two facade objects provided: ContextMap and ContextStack.

import org.apache.logging.log4j.kotlin.ContextMap
import org.apache.logging.log4j.kotlin.ContextStack

ContextMap["key"] = "value"
assert(ContextMap["key"] == "value")
assert("key" in ContextMap)

ContextMap += "anotherKey" to "anotherValue"
ContextMap -= "key"

ContextStack.push("message")
assert(!ContextStack.empty)
assert(ContextStack.depth == 1)
val message = ContextStack.peek()
assert(message == ContextStack.pop())
assert(ContextStack.empty)

A CoroutineThreadContext context element is provided to integrate logging context with coroutines.

We provide convenience functions loggingContext and additionalLoggingContext to create instances of CoroutineThreadContext with the appropriate context data. The result of these functions can be passed directly to coroutine builders to set the context for the coroutine.

To set the context, ignoring any context currently in scope:

launch(loggingContext(mapOf("myKey" to "myValue"), listOf("test"))) {
  assertEquals("myValue", ContextMap["myKey"])
  assertEquals("test", ContextStack.peek())
}

Or to preserve the existing context and add additional logging context:

launch(additionalLoggingContext(mapOf("myKey" to "myValue"), listOf("test"))) {
  assertEquals("myValue", ContextMap["myKey"])
  assertEquals("test", ContextStack.peek())
}

Alternatively, to change the context without launching a new coroutine, the withLoggingContext and withAdditionalLoggingContext functions are provided:

withAdditionalLoggingContext(mapOf("myKey" to "myValue"), listOf("test")) {
  assertEquals("myValue", ContextMap["myKey"])
  assertEquals("test", ContextStack.peek())
}

These functions are shorthand for withContext(loggingContext(…)) or withContext(additionalLoggingContext(…)).

Parameter substitution

Unlike Java, Kotlin provides native functionality for string templates. However, using a string template still incurs the message construction cost if the logger level is not enabled. To avoid this, prefer passing a lambda which won’t be evaluated until necessary:

logger.debug { "Logging in user ${user.name} with birthday ${user.calcBirthday()}" }

Logger names

Most logging implementations use a hierarchical scheme for matching logger names with logging configuration.

In this scheme the logger name hierarchy is represented by . (dot) characters in the logger name, in a fashion very similar to the hierarchy used for Java/Kotlin package names. The Logger property added by the Logging interface follows this convention: the interface ensures the Logger is automatically named according to the class it is being used in.

The value returned when calling the logger() extension method depends on the receiver of the extension. When called within an object, the receiver is this and therefore the logger will again be named according to the class it is being used in. However, a logger named via another class can be obtained as well:

import org.apache.logging.log4j.kotlin

class MyClass: BaseClass {

  val logger = SomeOtherClass.logger()

  // ...

}

Explicitly Named Loggers

An explicitly-named logger may be obtained via the logger function that takes a name parameter:

import org.apache.logging.log4j.kotlin

class MyClass: BaseClass {

  val logger = logger("MyCustomLoggerName")

  // ...

}

This is also needed in scopes that do not have a this object, such as top-level functions.