Logging macros which delegate to a specific logging implementation, selected
at runtime when the clojure.tools.logging
namespace is first loaded.
Lastest stable release is 1.3.0
CLI/deps.edn
dependency information:
org.clojure/tools.logging {:mvn/version "1.3.0"}
Leiningen:
[org.clojure/tools.logging "1.3.0"]
Maven:
<dependency>
<groupId>org.clojure</groupId>
<artifactId>tools.logging</artifactId>
<version>1.3.0</version>
</dependency>
Logging occurs with the log
macro, or the level-specific convenience macros
(e.g., debug
, debugf
). Only when the specified logging level is enabled will
the message arguments be evaluated and the underlying logging implementation be
invoked. By default, that invocation will occur via an agent when inside a
running STM transaction.
Unless otherwise specified, the current namespace (as identified by *ns*
) will
be used as the "logger name" when interacting with logging implementations. Most
logging implementations allow for varying configuration by logger name.
Note: You should configure your logging implementation to display the logger name that was passed to it. If instead the logging implementation performs stack-inspection you'll see some ugly and unhelpful text in your logs.
You can redirect all java writes of System.out
and System.err
to the log
system by calling log-capture!
. To bind *out*
and *err*
to the log system
invoke with-logs
. In both cases a logger name must be provided in lieu of
using *ns*
.
NOTE: Logging configuration (e.g., setting of logging levels, formatting) is specific to the underlying logging implementation, and is out of scope for this library.
To control which logging implementation is used, set the clojure.tools.logging.factory
system property to the fully-qualified name of a no-arg function that returns an
instance of clojure.tools.logging.impl/LoggerFactory
. There are a number of
factory functions provided in the clojure.tools.logging.impl
namespace.
:jvm-opts ["-Dclojure.tools.logging.factory=clojure.tools.logging.impl/slf4j-factory"]
If the system property is unset, an implementation will be automatically chosen based on whichever of the following implementations is successfully loaded first:
The above approach is problematic given that applications often inadvertently pull in multiple logging implementations as transitive dependencies. As such, it is strongly advised that you set the system property.
A simple Log4j2 configuration:
status = warn
monitorInterval = 5
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %date %level %logger %message%n%throwable
rootLogger.level = info
rootLogger.appenderRef.stdout.ref = STDOUT
Note: The above pattern
explicitly uses %throwable
so that clojure.lang.ExceptionInfo
exceptions
will be printed with their data maps. If either %xThrowable
(the default) or
%rThrowable
is used, the data maps will not be printed.
This is likely because the logging implementation is printing the contents of
Throwable.getMessage()
, which returns just the message arg to ex-info
.
Logging implementations that print the contents of toString()
or use Throwable.printStackTrace(...)
will end up printing the data map.
- Chris Dean
- Phil Hagelberg
- Richard Newman
- Sean Corfield
- Timothy Pratley
Copyright © Rich Hickey, Alex Taggart, and contributors
Licensed under the EPL. (See the file epl.html.)