Logging
This document aims to give you an overview of how you can write events of your application with the standard logging frameworks and how the SAP Cloud SDK integrates with that. There are three parts to this document:
- How the SAP Cloud SDK integrates with logging frameworks
- How to create log entries
- How to configure those entries
To better differentiate between different kinds of logging we will call the type of logs that are usually only relevant for developers to understand why the system behaves the way it did (for example during debugging) as Application Logging. Other types of logs might be kept due to legislative requirements (audit trails or audit logging) or be part of the terms and conditions (business logging). This document describes how to write and configure Applications Logs.
Logging Overview
For creating log entries the SAP Cloud SDK relies on the popular Simple Logging Facade for Java (SLF4J). It serves as an interface to a variety of different logging frameworks (e.g. Logback, log4j).
That means there are two components involved:
-
The SLF4J API
The API is used to get a logger instance and create log entries:
Logger logger = LoggerFactory.getLogger(DummyClass.class);
logger.debug("message"); -
A logging framework which provides the implementation of that API
The framework is then responsible for writing such messages according to a configuration. Which configuration options are available, depends on the framework. Typically, one can configure a log level (Error, Warn, Debug, etc.) and the format of messages.
The SAP Cloud SDK itself only relies upon the SLF4J API, not on any specific logging framework. This is good practice because otherwise all consumers would be forced to use the same logging framework that the SAP Cloud SDK comes with, rendering the SAP Cloud SDK unusable for many use cases.
That means that you have to provide a logging framework in your application. Otherwise, you will not see any log entries the SAP Cloud SDK attempts to put out.
In case your project is based on one of the SAP Cloud SDK archetypes you will already have Logback set up as the logging provider.
Providing a Logging Framework
To provide a logging framework, you have to add it to the dependency tree. Which artifacts are to be added exactly, depends on the framework.
To take Logback
as an example:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>latest-logback-version</version>
<scope>runtime</scope>
</dependency>
Also, you might have to provide some sort of configuration file.
For our example of Logback, we need a logback.xml
within the main/resources
directory of our application.
When running on the SAP BTP, Cloud Foundry environment using the SAP Java build pack the logging implementation is provided at runtime by the container. This means, if you only run the application on Cloud Foundry you don't need to provide any implementation. Still, oftentimes logging is also important for local deployment and testing. For that providing, an implementation is required.
Writing Log Messages
To start writing your log entries you also need to specify a dependency to the SLF4J API: org.slf4j:slf4j-api
.
Depending on the chosen logging-implementation, you might not need to specify the SLF4J API, but it's in general best practice to not rely on transitive dependencies and therefore reference the SLF4J API anyway.
Simple SLF4J Usage
Having these prerequisites out of the way, you can now start logging:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class DummyClass {
private static final Logger logger = LoggerFactory.getLogger(
DummyClass.class
);
public void doSomething() {
logger.trace("doSomething was called");
}
}
What do you see in this example?
- In the first line inside the class a new logger is created (once per class), with the class object as a reference. This class name will then be logged alongside the message in the logs.
- Inside the
doSomething
method this logger is now used to log the fact that the given method was called. The method you use for that depends on the level at which you want to see the message. Other options besidestrace
aredebug
,info
,warn
, anderror
.
As you can see, no reference to the actual logging implementation can be found in the code. This is the benefit of using SLF4J as a logging facade. This allows you to change the logging implementation without any changes to your application code.