• Global. Remote. Office-free.
  • Mon – Fri: 8:00 AM to 5:00 PM (Hong Kong Time)
English
Los Angeles Branch

Logback in AEM: Deprecated — But Not Always Your Problem

By Vuong Nguyen April 9, 2026 7 min read

In real projects—both AEM On-Premise and AEM as a Cloud Service—deprecated warnings like Logback show up frequently.

Check your AEM SDK version and use the following URL to view the deprecated API list:

https://javadoc.io/doc/com.adobe.aem/aem-sdk-api/<AEM SDK Version>/deprecated-list.html

Report highlights deprecated APIs:

Three things stand out:

  • ch.qos.logback is marked as deprecated
  • It is flagged for removal
  • Several APIs are unsupported in AEM as a Cloud Service

From these points, the next step is:

  • Replace the library
  • Upgrade dependencies
  • Fix the issue immediately

Taking immediate action is often wrong. More factors matter.

Is this warning actually coming from your code — or from the platform itself?

What the Deprecation Warning Actually Means

Deprecated or security warnings reported during local builds or Adobe CI/CD scans map to project dependencies that introduce the issue.

Unsupported dependency versions are replaced with supported versions.

//<site>.all
<dependency>
  <groupId>com.adobe.acs</groupId>
  <artifactId>acs-aem-commons-ui.content</artifactId>
  <version>5.1.2</version>
</dependency>

Only the version changes.

<!-- After -->
<version>6.6.2</version>

Bundle runs with updated version in /system/console/bundles.

Dependencies defined here are part of your implementation and under your control.

You can verify this using Maven:

mvn dependency:tree -Dincludes=com.adobe.acs

If the dependency appears in the result, it is included in your project.

For example, ACS Commons appears in the dependency tree:

[INFO] --- dependency:3.0.0:tree (default-cli) @ flagtick.all ---
[INFO] com.flagtick:flagtick.all:content-package:1.1.0-SNAPSHOT
[INFO] +- com.adobe.acs:acs-aem-commons-ui.content:zip:min:5.1.2:compile
[INFO] \- com.adobe.acs:acs-aem-commons-ui.apps:zip:min:5.1.2:compile

You can reproduce and inspect these warnings by running the build and filtering the output:

mvn clean verify | grep -i deprecated
mvn clean verify | grep -i "acs"

Analyzer output:

[WARNING] [region-deprecated-api] com.adobe.acs:acs-aem-commons-bundle:5.1.2: Usage of deprecated package found : org.apache.sling.commons.json : Usage of this deprecated API is not supported in AEM as a Cloud Service. Deprecated since 2022-12-31 For removal : 2027-12-31 (com.flagtick:flagtick.all:1.1.0-SNAPSHOT|adobe/consulting:acs-aem-commons-ui.apps:5.1.2)
[WARNING] [region-deprecated-api] com.adobe.acs:acs-aem-commons-bundle:5.1.2: Usage of deprecated package found : ch.qos.logback.classic.net : This internal logback API is not supported by AEM as a Cloud Service. Deprecated since 2022-01-27 For removal : 2025-08-31 (com.flagtick:flagtick.all:1.1.0-SNAPSHOT|adobe/consulting:acs-aem-commons-ui.apps:5.1.2)

In this example, ACS Commons appears in your project dependencies, so upgrading it is the correct action.

Logback is a different story.

It does not appear in your dependency tree and comes from AEM runtime, so you cannot fix it in your code.

Where Logback Is Coming From in Your Project

Logback is not part of your project dependencies, and your code does not import it. In AEM, logging is provided at the runtime level rather than within your application.

Open the OSGi bundles console and search for Logback to see how logging is provided and managed by the runtime.

If you don’t see Logback as a standalone bundle in /system/console/bundles, it does not automatically mean:

  • Logback is not available in AEM
  • Logback must appear as a standalone bundle to be used

Instead, it is still available within the AEM runtime, but not as a separate bundle.

Logback may still be provided through another bundle. In AEM, it is typically embedded and exposed via exported packages rather than appearing on its own.

In AEM, Logback is embedded in another bundle (e.g., org.apache.sling.commons.log) and exposed via exported packages, not as a standalone bundle.

You can verify this in AEM as a Cloud Service using the Developer Console: go to Bundles and download the bundle list (cm-publish-bundles.json), then inspect the exported packages or bundle contents.

[{"bundleID":0,"bundleName":"System Bundle","symbolicName":"org.apache.felix.framework","status":"active","location":"System Bundle","version":"7.0.5","description":"This bundle is system specific; it implements various system services.","startLevel":0,"fragmentsAttached":["org.apache.sling.feature.apiregions"],"exportedPackages":[{"name":"java.applet","version":"0.0.0.JavaSE_021"},{"name":"java.awt","version":"0.0.0.JavaSE_021"},{"name":"java.awt.color","version":"0.0.0.JavaSE_021"},{"name":"java.awt.datatransfer","version":"0.0.0.JavaSE_021"},{"name":"java.awt.desktop","version":"0.0.0.JavaSE_021"},...

org.apache.sling.commons.log provides logging and uses SLF4J as its API.

uses:="org.slf4j,org.slf4j.spi"

This bundle embeds Logback as the logging implementation.

This can be verified by inspecting the bundle contents or exported packages, where Logback classes such as ch.qos.logback.classic are available:

org.apache.sling.commons.log
 └── ch/qos/logback/...

The same bundle also exports Logback-related packages so that other modules can use them:

"exportedPackages": [
  "ch.qos.logback.classic",
  "ch.qos.logback.classic.encoder"
]

Logback is provided by the Sling logging bundle and is already available at runtime. It is not intended to be added, replaced, or managed at the project level.

Based on this, you can determine what should be fixed and what should not be changed in your project.

What You Should Fix vs What You Should Not

Deprecated or security warnings reported during local builds or Adobe CI/CD scans map to project dependencies that introduce the issue.

Warnings map to specific project dependencies. For example, com.adobe.acs.commons version is defined in the project and available in repository metadata, as shown below.

Maven Repository contains all versions; build output shows version used or flagged in the project.

[WARNING] [artifact-rules] adobe.consulting:acs-aem-commons-ui.apps:zip:cp2fm-converted:6.6.2: Use at least version 6.11.0 of ACS AEM Commons
[WARNING] [artifact-rules] adobe.consulting:acs-aem-commons-ui.apps:zip:cp2fm-converted:6.6.2: Use at least version 6.11.0 of ACS AEM Commons

Unsupported dependency versions are replaced with supported versions.

<dependency>
    <groupId>com.adobe.acs</groupId>
    <artifactId>acs-aem-commons-bundle</artifactId>
    <version>6.11.0</version>
    <scope>provided</scope>
</dependency>

Bundle runs with updated version in /system/console/bundles.

Dependency upgrades resolve warnings but may also affect related configurations or syntax. Service user mapping configuration is one example of changes across AEM versions:

Reference: https://experienceleague.adobe.com/en/docs/experience-manager-65/content/security/security-service-users

{
  "user.mapping": [
    "flagtick.core:subService=flagtick-service-user"
  ]
}

Updated configuration reflects new syntax requirements.

{
  "user.mapping": [
    "flagtick.core:subService=[flagtick-service-user]"
  ]
}

Upgrading dependencies affects both versions and related configurations; compatibility must be verified to ensure stable application behavior.

Next, logging behavior is reviewed in the context of Logback.

A Simple Checklist for AEM Developers

TODO