API and SPI of a no-fluff Java logging facade
- ... because sometimes the wheel should be reinvented.
- As a Java application developer, I want to use a log service API, so that I can choose or switch to use any compliant log service provider, at application deployment time without code change or re-compile.
- As a log service/engine/framework provider, I want to implement a Service Provider Interface (SPI), so that the log service client can opt to use my service implementation, at application deployment time without code change or re-compile.
Java 8 or better, although individual logging service providers may have higher JDK version prerequisite.
public interface Logger {
static Logger instance() {
return LogServiceProviderLocator.INSTANCE.logServiceProvider().logger();
}
default Logger atTrace() {
return this.atLevel(Level.TRACE);
}
default Logger atDebug() {
return this.atLevel(Level.DEBUG);
}
default Logger atInfo() {
return this.atLevel(Level.INFO);
}
default Logger atWarn() {
return this.atLevel(Level.WARN);
}
default Logger atError() {
return this.atLevel(Level.ERROR);
}
Logger atLevel(Level level);
Level getLevel();
boolean isEnabled();
void log(Object message);
default void log(Supplier<?> message) {
log((Object) message);
}
void log(String message, Object... arguments);
default void log(String message, Supplier<?>... arguments) {
log(message, (Object[]) arguments);
}
void log(Throwable throwable);
void log(Throwable throwable, Object message);
default void log(Throwable throwable, Supplier<?> message) {
log(throwable, (Object) message);
}
void log(Throwable throwable, String message, Object... arguments);
default void log(Throwable throwable, String message, Supplier<?>... arguments) {
log(throwable, message, (Object[]) arguments);
}
}public interface LogServiceProvider {
Logger logger();
}Any Logger instance should be thread-safe.
If a Logger instance is obtained via the Logger.instance() static factory method, then the default severity level of
such instance is decided by the service provider implementation. If a Logger instance is obtained via one of
the Logger.at<Level> instance factory methods, then its severity level should be as requested.
The empty curly braces token {} should be the placeholder for message arguments. This is by convention, and does not
syntactically appear in the API or SPI. Both the API user and the Service Provider must honor such convention.
Lazy arguments are those whose runtime type is java.util.function.Supplier. Compared to other types of arguments, lazy
ones have to be treated specially in that the Supplier function must be applied first before the result is used as the
substitution to the argument placeholder. This special handling of lazy arguments is by convention, and not
syntactically enforced by the API or SPI. It allows for the API user to mix up lazy and eager arguments within the same
logging method call.
Install as a compile-scope dependency in Maven or other build tools alike.
class SampleUsage {
static Logger logger = Logger.instance();
@Nested
class plainText {
@Test
void declarationsAndLevels() {
logger.log(
"Logger instance is thread-safe so it can be declared and used as a local, instance, or static variable");
logger.log("Default severity level is decided by the logging provider implementation");
Logger trace = logger.atTrace();
trace.log("Explicit severity level is specified by user i.e. TRACE");
Logger.instance().atTrace().log("Same explicit level TRACE");
logger.atDebug().log("Severity level is DEBUG");
logger.atInfo().log("Severity level is INFO");
trace.atWarn().log("Severity level is WARN, not TRACE");
logger.atError().log("Severity level is ERROR");
Logger.instance()
.atDebug()
.atError()
.atTrace()
.atWarn()
.atInfo()
.log("Not a practical example but the severity level is INFO");
}
}
@Nested
class textWithArguments {
Logger info = logger.atInfo();
@Test
void lazyAndEagerArgumentsCanBeMixed() {
info.log("Message can have any number of arguments of {} type", Object.class.getTypeName());
info.log(
"Lazy arguments, of {} type, whose values may be {} can be mixed with eager arguments of non-Supplier types",
Supplier.class.getTypeName(),
(Supplier) () -> "expensive to compute");
info.atWarn()
.log("The Supplier downcast is mandatory per lambda syntax because arguments are declared as generic Object rather than functional interface");
}
}
@Nested
class supplierMessageAndArguments {
Logger logger = Logger.instance();
@Test
void noDowncastNeededWhenAllMessageOrArgumentsAreSuppliers() {
logger.log(
() ->
"No downcast needed when message or arguments are all of Supplier type, rather than mixed with Object types");
logger.log("Message can have any number of {} type arguments", Supplier.class::getTypeName);
logger.log(
"Lazy arguments of {} type can be used to supply values that may be {}",
Supplier.class::getTypeName,
() -> "expensive to compute");
Exception ex = new Exception("test ex for Suppliers");
logger.log(ex, () -> "Exception log message can be a Supplier");
logger.log(ex, "So can the {}'s {}", () -> "message", () -> "arguments");
}
}
@Nested
class throwable {
@Test
void asTheFirstArgument() {
Exception exception = new Exception("Exception message");
logger.atError().log(exception);
logger.atError().log(exception, "Optional log message");
logger.atInfo()
.log(exception,
"Exception is always the first argument to a logging method. The {} log message and following arguments work the same way {}.",
"optional",
(Supplier) () -> "as usual");
}
}
}Note that elf4j is a logging service facade and specification, rather than the implementation. As such,
- Nothing will be logging out (no-op) unless a properly configured elf4j service provider JAR is discovered at the application start time. The elf4j facade itself only ships with a default no-op logging provider.
-
The elf4j API user can select or change into using any elf4j service provider at deploy time, without application code change or re-compile.
-
The recommended setup is to ensure that only one desired logging provider with its associated JAR(s) be present in the classpath; or, no provider JAR when no-op is desired. In this case, nothing further is needed for elf4j to work.
-
If multiple eligible providers are present in classpath, somehow, then the system property
elf4j.service.provider.fqcnhas to be used to select the desired provider. No-op applies if the specified provider is absent.java -Delf4j.service.provider.fqcn="elf4j.log4j.Log4jLoggerFactory" MyApplicationWith the default no-op logging provider, this system property can also be used to turn OFF all logging services discovered by the elf4j facade:
java -Delf4j.service.provider.fqcn="elf4j.util.NoopLogServiceProvider" MyApplication -
It is considered a setup error to have multiple providers in the classpath without a selection. The elf4j facade falls back to no-op on any setup errors.
To enable an independent logging framework/engine via the elf4j spec, the service provider should follow instructions of Java Service Provider Framework. Namely, the implementation should include
- the provider class implementing
the
LogServiceProviderSPI, the service class implementing theLoggerAPI, and their associated classes as needed - the provider-configuration file, named
elf4j.spi.LogServiceProviderin the resource directoryMETA-INF/services, whose content is the Fully Qualified Name of the SPI provider class implementing theLogServiceProviderSPI interface
- A native elf4j service provider: elf4j-provider
- tinylog provider
- LOG4J provider
- LOGBACK provider
- Java 4 (java.util.logging) provider
- SLF4J provider
- ...
