Apache Log4j Kotlin API

Table of Contents

Usage
Building From Source
Contributing

Log4j Kotlin API is a Kotlin logging facade based on Log4j 2.

Log4j Kotlin API uses Log4j 2.x as its logging backend.

Log4j Kotlin API uses Log4j 2.x as its logging backend by default, but this can also be replaced with compatible libraries (e.g., Logback).

While this library is not required to use Log4j API in Kotlin, it does provide idiomatic Kotlin APIs which are friendlier to use in Kotlin programs than the Java APIs.

Usage

Using the Kotlin API is as simple as mixing in the Logging interface to your class. Example:

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).

API Documentation

See KDocs.

Configuration

Log4j Kotlin API uses Log4j configuration by default.

This supports XML, properties files, and Java-based builders, as well as JSON and YAML with additional dependencies.

Substituting Parameters

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.

For example:

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 '.' 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 as shown above, 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.

Unresolved directive in <stdin> - include::download.adoc[]

Unresolved directive in <stdin> - include::changes.adoc[]

Building From Source

Note	The following information is for developers who wish to modify Log4j Kotlin API or contribute. If your goal is to add logging to your application, then you can use the pre-built binaries instead.

Building

mvn package

Contributing

You have found a bug or you have an idea for a cool new feature? Contributing code is a great way to give something back to the open source community. Before you dig right into the code there are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

Getting Started

Make sure you have a Jira account.
Make sure you have a GitHub account.
If you’re planning to implement a new feature it makes sense to discuss your changes on the dev list first. This way you can make sure you’re not wasting your time on something that isn’t considered to be in Apache Log4j’s scope.
Submit a ticket for your issue, assuming one does not already exist.
Clearly describe the issue including steps to reproduce when it is a bug.
Make sure you fill in the earliest version that you know has the issue.
Fork the repository on GitHub.

Making Changes

Create a topic branch from where you want to base your work (this is usually the master branch).
Make commits of logical units.
Respect the original code style:
Only use spaces for indentation.
Create minimal diffs - disable on save actions like reformat source code or organize imports. If you feel the source code should be reformatted create a separate PR for this change.
Check for unnecessary whitespace with git diff --check before committing.
Make sure your commit messages are in the proper format. Your commit message should contain the key of the Jira issue.
Make sure you have added the necessary tests for your changes.
Run all the tests with sbt "+ test" to assure nothing else was accidentally broken.

Making Trivial Changes

For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA. In this case, it is appropriate to start the first line of a commit with '(doc)' instead of a ticket number.

Submitting Changes

Sign the Contributor License Agreement if you haven’t already.
Push your changes to a topic branch in your fork of the repository.
Submit a pull request to the repository in the apache organization.
Update your Jira ticket and include a link to the pull request in the ticket.