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.

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 an SLF4J Logger instance in your own class via the LoggerFactory.

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.Loggerlog 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.

Is your brand starting its Digital Transformation journey? Download Blue Acorn iCi’s B2B Digital Transformation Workbook for key insights and an interactive worksheet.

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 hook 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.

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.

Do you want more content like this delivered directly to your inbox on a monthly basis? Subscribe to our newsletter, Blue Acorn iCi Monthly Digital Digest!

Subscribe to Our Newsletter

Get the latest insights from Blue Acorn iCi