Log4j2 wrapper for Clojure
To use the latest release, add the following to your deps.edn (Clojure CLI)
com.lambdaisland/log4j2 {:mvn/version "0.1.3"}
or add the following to your project.clj (Leiningen)
[com.lambdaisland/log4j2 "0.1.3"]
After many years of Slf4j and Logback, we are starting to shift to Log4j2 for new projects. This micro-library contains a namespace which mimics pedestal.log, and thus can act as a drop-in replacement.
(ns my.ns
(:require
[lambdaisland.log4j2 :as log]))
(log/debug :db/preparing {:query query})
(log/info :application/starting {:port 1234})
(log/warn :config/missing-value {:key k} :message "Configuration value not found, using nil")
(log/error :api-call/failed {:req req} :exception e)
All calls have the same signature, an arbitrary sequence of keys and values.
These become key-values in a Log4j2 MapMessage, and can be logged e.g. to JSON
and fed into structured logging solutions.
A few keys have a special meaning
:exceptionfor throwables:messagefor a human readable message
These will be passed on to Log4j2 in the appropriate fields.
Thank you! This project is made possible thanks to our generous backers. Become a backer on OpenCollective so that we can continue to make log4j2 better.
log4j2 is part of a growing collection of quality Clojure libraries created and maintained by the fine folks at Gaiwan.
Pay it forward by becoming a backer on our OpenCollective, so that we continue to enjoy a thriving Clojure ecosystem.
You can find an overview of all our different projects at lambdaisland/open-source.
We warmly welcome patches to log4j2. Please keep in mind the following:
- adhere to the LambdaIsland Clojure Style Guide
- write patches that solve a problem
- start by stating the problem, then supply a minimal solution
* - by contributing you agree to license your contributions as MPL 2.0
- don't break the contract with downstream consumers
** - don't break the tests
We would very much appreciate it if you also
- update the CHANGELOG and README
- add tests for new functionality
We recommend opening an issue first, before opening a pull request. That way we can make sure we agree what the problem is, and discuss how best to solve it. This is especially true if you add new dependencies, or significantly increase the API surface. In cases like these we need to decide if these changes are in line with the project's goals.
* This goes for features too, a feature needs to solve a problem. State the problem it solves first, only then move on to solving it.
** Projects that have a version that starts with 0. may still see breaking changes, although we also consider the level of community adoption. The more widespread a project is, the less likely we're willing to introduce breakage. See LambdaIsland-flavored Versioning for more info.
Copyright © 2025 Arne Brasseur and Contributors
Licensed under the term of the Mozilla Public License 2.0, see LICENSE.