4 Ways Sling Logging Makes You a Better Developer

Logging is a critical component of developing stable and secure applications. When used correctly, logs can provide insight into application topics like security, performance, debugging, and more. In Adobe Experience Manager (AEM), you can leverage Sling Logging to diagnose salient issues, like slow loading times and component or page load failures. If you are familiar with Log4j or Simple Logging Facade for Java (SLF4J), your experience will accelerate your understanding of Sling Logging within AEM.

Here are four tips that show the usefulness and flexibility of Sling Logging:

1. Acquiring and Using a Logger Instance
AEM includes the org.apache.sling.commons.log bundle with an implementation of SLF4J. The SLF4J framework allows you to interact with the logging system in AEM. You can easily acquire a SLF4J Logger instance in your own class via the LoggerFactory:

Which will produce output similar to the following in the logs/error.log file:

2. Using the Groovy SLF4J Annotation
If you are developing with Groovy, you can use the @Slf4j annotation to automatically set up an org.slf4j.Logger log object. You won’t have to manually set up a Logger from the LoggerFactory and your fully qualified class name will already be associated with the log object. Ultimately, this will give you the same type of Logger instance as the previous example, but with less boilerplate code involved.

Here is an example:
Which will produce output similar to the following in the logs/error.log file:

3. AEM Logs Default Output File
You might be wondering why the previous examples info and error log events both output to the logs/error.log file and what configuration controls this. There is a Sling Log Support configuration page where loggers can be created and edited with the following properties:

• Log Level: The broadest log level the logger will respond to.
• Additive: Controls whether logged events are forwarded to parent loggers.
• Log File: Relative path to a file where log statements will be appended.
• Logger: An identifier/label for the logger.

Any Logger instance that you create that has no existing logger configuration will be interpreted as a child of the default ROOT logger. All logging statements produced by the child logger will be forwarded to the parent logger, using its configuration instead. The ROOT logger outputs to logs/error.log by default, so this is why your Logger instance statements end up in logs/error.log.

You might notice the other loggers that exist on your instance by default, like log.history. This logger tracks when AEM users view or modify pages and assets and outputs these events to logs/history.log.

If you wanted to look into this logger and append log statements to logs/history.log, you would want to specify the logger identifier log.history when grabbing a Logger instance from the LoggerFactory.

Here is an example:
Which will produce output similar to the following in the logs/history.log file:

4. Log Tail Endpoint
The Sling Log Support page in the AEM Web Console reveals another useful feature for viewing logs remotely.

You will need to provide request parameters to specify what log contents you want to see:

• name: URL encoded relative path to the desired log file. Example: %2Flogs%2Ferror.log
• tail: Number of lines to display, starting at the end of the file.
• grep: Option to filter out the results.

This endpoint produces static output, so you will be viewing the end of the log file at the time of the request. More log statements might have been added after your request, so you would need to refresh the browser window to see them.

Please note that we are accessing /system/console, which will be restricted generally on public-facing instances for security purposes.

These tips should help you better understand the logging capabilities Sling offers in AEM. I hope they inspire you to start logging or expand the scope of any logging you might already have.