Beheben von veralteten Bibliotheksverwendungswarnungen für ch.qos.logback und entfernte APIs in Cloud Manager

Letzte Aktualisierung: 22. Juni 2026

Cloud Manager meldet eine veraltete Bibliotheksnutzung für ch.qos.logback oder andere entfernte APIs während Build-, Code-Qualitäts- oder Bereitstellungsschritten. Diese Warnungen stammen aus veralteten ACS AEM Commons-Versionen, einem falschen Maven-Klassifikator oder Kunden-Code, der direkt auf entfernte APIs verweist. In einigen Fällen stammen Logback-Verweise aus von Adobe verwalteten Plattform-Bundles und erfordern keine Kundenänderungen. Die Identifizierung der genauen Quelle - ACS Commons-Version, nicht übereinstimmende Klassifizierer, Kunden-Code oder Adobe-Laufzeit - bestimmt die richtige Fehlerbehebung.

Beschreibung description

Problem: Cloud Manager kennzeichnet veraltete ch.qos.logback oder hat die API-Nutzung während Build- oder Code-Qualitätsprüfungen entfernt

Beschreibung

Warnhinweise im Cloud Manager Action Center oder Pipeline-Fehler weisen auf eine veraltete Verwendung von ch.qos.logback oder anderen entfernten APIs hin. Diese Warnungen werden in der Build-Phase unter region-deprecated-api- oder configuration-api angezeigt. Die Grundursache variiert: Veraltete ACS AEM Commons-Versionen rufen das Logback transitiv ab, der falsche Maven-Klassifikator wird verwendet, Kunden-Code-Referenzen haben APIs entfernt oder von Adobe verwaltete interne Bundles registrieren das Logback zur Laufzeit, ohne den Build zu beeinflussen.

Umgebung:

Adobe Experience Manager as a Cloud Service (AEMaaCS)
Cloud Manager (Build-, Code-Qualitäts- und Bereitstellungs-Pipelines)
ACS AEM Commons

Problem/Symptome:

Cloud Manager-Build-Protokolle zeigen: Usage of deprecated package found : ch.qos.logback.* : This internal logback API is not supported by AEM as a Cloud Service
Laufzeitprotokolle enthalten Einträge wie ServiceEvent REGISTERED [ ch.qos.logback.core.filter.Filter], auch wenn der Kunden-Code kein Logback verwendet
Die Build-Kompilierung schlägt mit Fehlern im Zusammenhang mit veralteten APIs fehl, z. B. RequestResponseFactory
Code Analyzer meldet Fehler wie Service.ranking is not of type Integer oder Warnungen von groovy-all:2.4.15
JSP-Präcompilerfehler treten nach der Aktualisierung von ACS Commons auf: File tld:http://sling.apache.org/taglibs/sling/1.0 not found

Grundursache:

Veraltete Bibliothekswarnungen treten auf, wenn Cloud Manager die Verwendung von APIs erkennt, deren Entfernung geplant ist. Ältere ACS AEM Commons-Pakete enthalten ch.qos.logback transitiv, und die Verwendung des On-Premise ACS Commons-Klassifikators in AEMaaCS gibt auch Trigger zu dieser Warnung. Ähnliche Fehler treten auf, wenn auf Kunden-Code verwiesen wird, der in Cloud Service als veraltet gekennzeichnet ist (z. B. com.day.cq.contentsync.handler.util.RequestResponseFactory). Logback-Verweise aus von Adobe verwalteten Plattform-Bundles verursachen keine Bereitstellungsblöcke und erfordern keine Kundenaktion.

Wie kann ich bestätigen

Überprüfen Sie die Cloud Manager-Build-Protokolle auf Einträge, die auf die Bundle-Versionen ch.qos.logback.*, groovy-all:2.4.15, com.day.cq.contentsync.handler.util oder ACS Commons verweisen. Wenn auf Protokolle nicht zugegriffen werden kann, laden Sie sie über Cloud Manager > Pipelines > Execution > Logs herunter.
Bestätigen Sie die genaue ACS Commons-Version, indem Sie Zeilen wie com.adobe.acs:acs-aem-commons-bundle:5.2.0 oder Warnungen suchen, die auf das Logback verweisen.

Führen Sie einen vollständigen Maven-Abhängigkeitsbaum aus, um nach widersprüchlichen Versionen zu suchen:

code language-none
`mvn dependency:tree -Dincludes=com.adobe.acs:acs-aem-commons*`

Durchsuchen Sie die kundeneigenen Dateien nach allen direkten Logback-Referenzen:

Windows:

code language-none
`findstr /S /N /I "ch.qos.logback" pom.xml .xml .yml *.yaml`

Lösung resolution

Nicht übereinstimmende ACS Commons-Version oder Klassifizierer (am häufigsten): Sie in Ihrem Projekt die all/pom.xml für die ACS Commons-Abhängigkeit. Stellen Sie sicher, dass <classifier>cloud</classifier> vorhanden ist und die Version mindestens 6.11.0 ist. Der Eintrag sollte wie folgt aussehen:

code language-none
`<groupId>com.adobe.acs</groupId> <artifactId>acs-aem-commons-all</artifactId> <version>6.16.0</version> <classifier>cloud</classifier>`

Wenn widersprüchliche Versionen in der Abhängigkeitsstruktur angezeigt werden, entfernen Sie alle direkten oder transitiven Verweise auf ältere ACS Commons-Builds.

2. Kunden-Code, der auf entfernte APIs verweist: Durchsuchen Sie Ihre Code-Basis nach veralteten Paketen, die in Cloud Manager-Protokollen gekennzeichnet sind. Ersetzen Sie die Verwendung entfernter APIs, z. B. RequestResponseFactory, durch die Sling Builder-APIs (org.apache.sling.api.request.builder.Builders oder SlingUriBuilder). Führen Sie die Cloud Manager-Codescan erneut aus, um zu bestätigen, dass keine veralteten API-Warnungen mehr vorhanden sind.
3. JSP-Präcompilerfehler nach einer ACS Commons-Aktualisierung: Fügen Sie Ihrem ui.apps mit scope=provided:
die Sling JSP-Tag-Bibliotheksabhängigkeit hinzu.

"
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.scripting.jsp.taglib</artifactId>
<version>2.4.0</version>
<scope>Bereitgestellt</scope>
"

Führen Sie die Pipeline erneut aus und bestätigen Sie, dass der tld not found Fehler nicht mehr vorhanden ist.

4. aemanalyser-Konfigurationsfehler in höheren Versionen: Wenn Version 1.6.16 Fehler wie Service.ranking is not of type Integer zurückgibt, wechseln Sie zu Version 1.6.4 oder 1.6.14. Führen Sie die Pipeline erneut aus und bestätigen Sie, dass sie ohne Analyzer-Fehler abgeschlossen ist.
5. groovy-all:2.4.15 als veraltet gekennzeichnet: Ersetzen Sie durch die Orbinson Groovy Console-Variante:

"
<groupId>be.orbinson.aem</groupId>
<artifactId>aem-groovy-console-all</artifactId>
<version>19.0.8</version>
<type>zip</type>
"

Schritt „Code-Qualität bestätigen“ gibt keine groovy-all aus. Wenn die Groovy-Konsole nicht verwendet wird, entfernen Sie sie vollständig.

6. Nur Logback-Verweise aus von Adobe verwalteten Bundles: Wenn in der Code-Qualität keine veralteten Bibliothekswarnungen angezeigt werden und die einzigen Logback-Einträge Laufzeitzeilen sind, z. B. ServiceEvent REGISTERED [ ch.qos.logback.core.filter.Filter] in Protokollen - ohne Warnungen im Build-Schritt - ist keine Aktion erforderlich. Diese stammen aus Adobe Platform-Bundles und blockieren nicht die Bereitstellung.
7. Validieren Starten Sie einen neuen Code-Scan oder eine vollständige Pipeline-Ausführung. Bestätigen Sie, dass Build-Protokolle keine ch.qos.logback Einträge unter region-deprecated-api und keine veralteten API-Warnungen für Kunden-Code oder ACS Commons anzeigen.