Qualitätsregeln für benutzerspezifischen Code custom-code-quality-rules

Erfahren Sie mehr über die benutzerspezifischen Regeln für die Code-Qualität von Cloud Manager, die auf Best Practices von Adobe Experience Manager Engineering basieren, um durch gründliche Tests einen hochwertigen Code sicherzustellen. Siehe auch Tests der Codequalität.

Regeln für SonarQube sonarqube-rules

Im folgenden Abschnitt werden die SonarQube-Regeln beschrieben, die von Cloud Manager ausgeführt werden.

Verwenden Sie keine potenziell gefährlichen Funktionen do-not-use-potentially-dangerous-functions

Die Methoden Thread.stop() und Thread.interrupt() können schwer zu reproduzierende Probleme und in einigen Fällen Sicherheitslücken verursachen. Daher sollte deren Verwendung sorgfältig überwacht und validiert werden. Im Allgemeinen ist die Nachrichtenübergabe eine sicherere Möglichkeit, ähnliche Ziele zu erreichen.

Nicht konformer Code non-compliant-code

public class DontDoThis implements Runnable {
  private Thread thread;

  public void start() {
    thread = new Thread(this);
    thread.start();
  }

  public void stop() {
    thread.stop();  // UNSAFE!
  }

  public void run() {
    while (true) {
        somethingWhichTakesAWhileToDo();
    }
  }
}

Konformer Code compliant-code

public class DoThis implements Runnable {
  private Thread thread;
  private boolean keepGoing = true;

  public void start() {
    thread = new Thread(this);
    thread.start();
  }

  public void stop() {
    keepGoing = false;
  }

  public void run() {
    while (this.keepGoing) {
        somethingWhichTakesAWhileToDo();
    }
  }
}

Verwenden Sie keine Formatzeichenfolgen, die extern gesteuert werden können do-not-use-format-strings-which-may-be-externally-controlled

Durch die Verwendung einer Formatzeichenfolge aus einer externen Quelle (z. B. einem Abfrageparameter oder nutzergenerierten Inhalten) kann ein Programm für Denial-of-Service-Angriffe anfällig werden. Es gibt Fälle, in denen eine Formatzeichenfolge von außen gesteuert werden kann, jedoch nur aus vertrauenswürdigen Quellen zulässig ist.

Nicht konformer Code non-compliant-code-1

protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) {
  String messageFormat = request.getParameter("messageFormat");
  request.getResource().getValueMap().put("some property", String.format(messageFormat, "some text"));
  response.sendStatus(HttpServletResponse.SC_OK);
}

HTTP-Anfragen sollten immer Zeitüberschreitungswerte für Sockets und Verbindungen enthalten http-requests-should-always-have-socket-and-connect-timeouts

Bei HTTP-Anfragen in einer Experience Manager-Anwendung ist es wichtig, geeignete Timeouts zu konfigurieren, um unnötigen Thread-Verbrauch zu vermeiden.
Standardmäßig sind sowohl der Java™ HTTP Client (java.net.HttpUrlConnection) als auch der häufig verwendete Apache HTTP Components-Client keine Zeitüberschreitungen vorschreiben. Daher müssen sie manuell konfiguriert werden. Als Best Practice empfiehlt sich, Timeouts auf maximal 60 Sekunden festzulegen.

Nicht konformer Code non-compliant-code-2

@Reference
private HttpClientBuilderFactory httpClientBuilderFactory;

public void dontDoThis() {
  HttpClientBuilder builder = httpClientBuilderFactory.newBuilder();
  HttpClient httpClient = builder.build();

  // do something with the client
}

public void dontDoThisEither() {
  URL url = new URL("http://www.google.com");
  URLConnection urlConnection = url.openConnection();

  BufferedReader in = new BufferedReader(new InputStreamReader(
    urlConnection.getInputStream()));

  String inputLine;
  while ((inputLine = in.readLine()) != null) {
    logger.info(inputLine);
  }

  in.close();
}

Konformer Code compliant-code-1

@Reference
private HttpClientBuilderFactory httpClientBuilderFactory;

public void doThis() {
  HttpClientBuilder builder = httpClientBuilderFactory.newBuilder();
  RequestConfig requestConfig = RequestConfig.custom()
    .setConnectTimeout(5000)
    .setSocketTimeout(5000)
    .build();
  builder.setDefaultRequestConfig(requestConfig);

  HttpClient httpClient = builder.build();

  // do something with the client
}

public void orDoThis () {
  URL url = new URL("http://www.google.com");
  URLConnection urlConnection = url.openConnection();
  urlConnection.setConnectTimeout(5000);
  urlConnection.setReadTimeout(5000);

  BufferedReader in = new BufferedReader(new InputStreamReader(
    urlConnection.getInputStream()));

  String inputLine;
  while ((inputLine = in.readLine()) != null) {
    logger.info(inputLine);
  }

  in.close();
}

ResourceResolver-Objekte immer schließen resourceresolver-objects-should-always-be-closed

ResourceResolver-Objekte, die von ResourceResolverFactory abgerufen werden, verbrauchen Systemressourcen. Obwohl es Möglichkeiten gibt, diese Ressourcen freizugeben, wenn ein ResourceResolver nicht mehr verwendet wird, ist es effizienter, alle offenen ResourceResolver-Objekte explizit durch Aufruf der Methode close() zu schließen.

Ein häufiges Missverständnis besteht darin, dass ResourceResolver-Objekte, die mit einer vorhandenen JCR-Sitzung erstellt wurden, nicht explizit geschlossen werden sollten oder dass das Schließen sie betrifft die JCR-Sitzung. Diese Informationen sind falsch. Ein ResourceResolver sollte immer geschlossen werden, wenn er nicht mehr benötigt wird. Da ResourceResolver die Closeable -Schnittstelle implementiert, können Sie auch die try-with-resources -Syntax verwenden, anstatt close() direkt aufzurufen.

Nicht konformer Code non-compliant-code-4

public void dontDoThis(Session session) throws Exception {
  ResourceResolver resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object)session));
  // do some stuff with the resolver
}

Konformer Code compliant-code-2

public void doThis(Session session) throws Exception {
  ResourceResolver resolver = null;
  try {
    resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object)session));
    // do something with the resolver
  } finally {
    if (resolver != null) {
      resolver.close();
    }
  }
}

public void orDoThis(Session session) throws Exception {
  try (ResourceResolver resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object) session))){
    // do something with the resolver
  }
}

Verwenden Sie keine Sling-Servlet-Pfade zum Registrieren von Servlets do-not-use-sling-servlet-paths-to-register-servlets

Wie in der Sling-Dokumentation beschrieben, sollten Servlets nicht über Pfade verknüpft werden. Pfadgebundene Servlets können keine standardmäßigen JCR-Zugriffssteuerungselemente verwenden, sodass besonders strenge Sicherheitsmaßnahmen erforderlich sind. Statt pfadgebundene Servlets zu verwenden, wird empfohlen, Knoten im Repository zu erstellen und Servlets nach Ressourcentyp zu registrieren.

Nicht konformer Code non-compliant-code-5

@Component(property = {
  "sling.servlet.paths=/apps/myco/endpoint"
})
public class DontDoThis extends SlingAllMethodsServlet {
 // implementation
}

Erfasste Ausnahmen sollten entweder protokolliert oder ausgelöst werden, aber nicht beides caught-exceptions-should-be-logged-or-thrown-but-not-both

Im Allgemeinen sollte eine Ausnahme genau einmal protokolliert werden. Das mehrfache Protokollieren von Ausnahmen kann zu Verwirrung führen. Der Grund dafür ist, dass unklar ist, wie oft eine Ausnahme aufgetreten ist. Das häufigste Muster, das zu diesem Effekt führt, ist das Protokollieren und Ausgeben einer gefundenen Ausnahme.

Nicht konformer Code non-compliant-code-6

public void dontDoThis() throws Exception {
  try {
    someOperation();
  } catch (Exception e) {
    logger.error("something went wrong", e);
    throw e;
  }
}

Konformer Code compliant-code-3

public void doThis() {
  try {
    someOperation();
  } catch (Exception e) {
    logger.error("something went wrong", e);
  }
}

public void orDoThis() throws MyCustomException {
  try {
    someOperation();
  } catch (Exception e) {
    throw new MyCustomException(e);
  }
}

Throw-Anweisungen sollten möglichst nicht unmittelbar auf Log-Anweisungen folgen avoid-having-a-log-statement-immediately-followed-by-a-throw-statement

Ein weiteres gängiges Muster, das vermieden werden sollte, ist die Protokollierung einer Nachricht, direkt gefolgt von der Auslösung einer Ausnahme. Dadurch wird die Ausnahmemeldung in Protokolldateien meist doppelt aufgeführt.

Nicht konformer Code non-compliant-code-7

public void dontDoThis() throws Exception {
  logger.error("something went wrong");
  throw new RuntimeException("something went wrong");
}

Konformer Code compliant-code-4

public void doThis() throws Exception {
  throw new RuntimeException("something went wrong");
}

Vermeiden Sie beim Verarbeiten von GET- oder HEAD-Anfragen die Protokollierung bei INFO avoid-logging-at-info-when-handling-get-or-head-requests

Allgemein sollten mit der Protokollebene INFO wichtige Aktionen abgegrenzt werden. Standardmäßig ist Experience Manager so konfiguriert, dass auf der INFO-Ebene oder darüber protokolliert wird. GET- und HEAD-Methoden sollten nur schreibgeschützte Vorgänge sein und stellen daher keine wichtigen Aktionen dar. Eine Protokollierung auf INFO-Ebene als Antwort auf GET- oder HEAD-Anfragen füllt das Protokoll wahrscheinlich mit erheblichen Mengen überflüssiger Informationen, sodass es schwieriger wird, nützliche Informationen in Protokolldateien zu finden. Melden Sie sich beim Umgang mit GET- oder HEAD-Anfragen auf den WARN- oder ERROR-Ebenen an, wenn etwas schief gelaufen ist. Verwenden Sie DEBUG- oder TRACE-Ebenen, wenn detaillierte Informationen zur Fehlerbehebung erforderlich sind.

Nicht konformer Code non-compliant-code-8

public void doGet() throws Exception {
  logger.info("handling a request from the user");
}

Konformer Code compliant-code-5

public void doGet() throws Exception {
  logger.debug("handling a request from the user.");
}

Verwenden Sie nicht Exception.getMessage() als ersten Parameter einer Protokollanweisung do-not-use-exception-getmessage-as-the-first-parameter-of-a-logging-statement

Als Best Practice sollten Protokollmeldungen kontextbezogene Informationen darüber enthalten, wo eine Programmausnahme aufgetreten ist. Obwohl der Kontext auch mit Stacktraces bestimmt werden kann, ist die Protokollmeldung meist besser lesbar und verständlicher. Daher ist es bei der Protokollierung einer Ausnahme nicht empfehlenswert, die Ausnahmemeldung als Protokollmeldung zu verwenden. Die Ausnahmemeldung erklärt, was schiefgelaufen ist, während die Protokollmeldung den Leser darüber informieren sollte, was die Anwendung bei Eintreten der Ausnahme getan hat. Die Ausnahmemeldung wird dennoch protokolliert. Durch die Spezifizierung Ihrer eigenen Nachricht sind die Protokolle leichter verständlich.

Nicht konformer Code non-compliant-code-9

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error(e.getMessage(), e);
  }
}

Konformer Code compliant-code-6

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

Die Protokollierung in Catch-Blöcken sollte auf WARN- oder ERROR-Ebene erfolgen logging-in-catch-blocks-should-be-at-the-warn-or-error-level

Wie schon der Name sagt, sollten Java™-Ausnahmen immer in Ausnahmefällen verwendet werden. Wenn eine Ausnahme erfasst wird, muss daher sichergestellt sein, dass Protokollmeldungen auf der entsprechenden Ebene – WARN oder ERROR – protokolliert werden. Dadurch wird sichergestellt, dass diese Meldungen in den Protokollen korrekt angezeigt werden.

Nicht konformer Code non-compliant-code-10

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.debug(e.getMessage(), e);
  }
}

Konformer Code compliant-code-7

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

Drucken Sie keine Stacktraces in der Konsole do-not-print-stack-traces-to-the-console

Wie bereits erwähnt, ist Kontext beim Verständnis von Protokollmeldungen äußerst wichtig. Durch Verwendung von Exception.printStackTrace() wird nur der Stacktrace an den Standardfehler-Stream ausgegeben, während der gesamte Kontext verloren geht. Außerdem kann es bei mehrprozessgestützten Anwendungen wie Experience Manager beim parallelen Drucken mehrerer Ausnahmen mit dieser Methode zu einer Überlappung der Stacktraces kommen, was erhebliche Verwirrung verursacht. Ausnahmen sollten daher nur über das Protokollierungs-Framework protokolliert werden.

Nicht konformer Code non-compliant-code-11

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    e.printStackTrace();
  }
}

Konformer Code compliant-code-8

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

Nicht an Standardausgabe oder Standardfehler ausgeben do-not-output-to-standard-output-or-standard-error

Die Anmeldung in Experience Manager sollte immer über das Protokollierungs-Framework (SLF4J) erfolgen. Bei der direkten Ausgabe an die Standardausgabe oder den Standardfehler-Stream gehen die vom Protokollierungs-Framework bereitgestellten Struktur- und Kontextinformationen verloren. Manchmal kann dies zu Leistungsproblemen führen.

Nicht konformer Code non-compliant-code-12

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    System.err.println("Unable to do something");
  }
}

Konformer Code compliant-code-9

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

Vermeiden von fest programmierten Apps und Libs-Pfaden avoid-hardcoded-apps-and-libs-paths

Pfade, die mit /libs und /apps beginnen, sollten im Allgemeinen nicht hartcodiert sein. Diese Pfade werden normalerweise relativ zum Sling-Suchpfad gespeichert, der standardmäßig auf /libs,/apps festgelegt ist. Durch die Angabe des absoluten Pfads können geringfügige Fehler entstehen, die erst später im Projektlebenszyklus deutlich werden.

Nicht konformer Code non-compliant-code-13

public boolean dontDoThis(Resource resource) {
  return resource.isResourceType("/libs/foundation/components/text");
}

Konformer Code compliant-code-10

public void doThis(Resource resource) {
  return resource.isResourceType("foundation/components/text");
}

Sling-Scheduler nicht verwenden sonarqube-sling-scheduler

Verwenden Sie den Sling-Scheduler nicht für Aufgaben, die eine garantierte Ausführung erfordern. Über Sling geplante Vorgänge garantieren die Ausführung und eignen sich besser für Umgebungen mit und ohne Cluster.

Weitere Informationen zum Umgang mit Sling-Vorgängen in Cluster-Umgebungen finden Sie unter Apache Sling-Ereignisse und -Vorgangsverarbeitung.

Keine nicht mehr unterstützten Experience Manager-APIs verwenden sonarqube-aem-deprecated

Die Experience Manager-API-Oberfläche wird ständig geprüft, um APIs zu identifizieren, deren Verwendung nicht mehr empfohlen wird und die deshalb als nicht mehr unterstützt gelten.

In vielen Fällen sind diese APIs unter Verwendung der Standard-Java™-Annotation @Deprecated als veraltet eingestuft und durch squid:CallToDeprecatedMethod gekennzeichnet.

Es gibt jedoch auch Fälle, in denen eine API im Experience Manager-Kontext veraltet ist, in anderen Kontexten jedoch nicht. Diese Regel identifiziert diese zweite Gruppe.

Verwenden Sie in Sling-Modellen keine @Inject-Anmerkung mit @Optional. sonarqube-slingmodels-inject-optional

Das Apache Sling-Projekt rät von der Verwendung der @Inject-Anmerkung im Kontext von Sling-Modellen ab, da dies zu einer schlechten Leistung führen kann, wenn sie mit der DefaultInjectionStrategy.OPTIONAL (entweder auf Feld- oder Klassenebene) verwendet wird. Stattdessen sollten spezifischere Injektionen (wie die Anmerkungen @ValueMapValue oder @OsgiInjector) verwendet werden.

Lesen Sie die Apache Sling-Dokumentation für weitere Informationen über die empfohlenen Anmerkungen und die Gründe, aus denen diese Empfehlung überhaupt ausgesprochen wurde.

Wiederverwenden von HTTPClient-Instanzen sonarqube-reuse-httpclient

AEM Anwendungen erreichen häufig andere Anwendungen über das HTTP-Protokoll, und der Apache HttpClient ist eine häufig verwendete Bibliothek, um dies zu erreichen. Die Erstellung eines solchen HttpClient-Objekts bringt jedoch einen gewissen Mehraufwand mit sich, sodass diese Objekte so weit wie möglich wiederverwendet werden sollten.

Diese Regel überprüft, ob ein solches HttpClient-Objekt in einer Methode nicht privat, sondern auf Klassenebene global ist, sodass es wiederverwendet werden kann. In diesem Fall sollte das HttpClient-Feld im Konstruktor der Klasse oder der activate()-Methode festgelegt werden (wenn diese Klasse eine OSGi-Komponente/ein OSGi-Dienst ist).

Lesen Sie das Optimierungshandbuch des HttpClient für einige Best Practices für die Verwendung des HttpClient.

Nicht konformer Code non-compliant-code-14

public void doHttpCall() {
  HttpClient httpclient = HttpClients.createDefault();
  // do something with the httpclient
}

Konformer Code compliant-code-11

public class myClass {

  HttpClient httpclient;

  public void doHttpCall() {
    // do something with the httpclient
  }

}

Inhaltsregeln für OakPAL oakpal-rules

Im folgenden Abschnitt werden die von Cloud Manager durchgeführten OakPAL-Prüfungen vorgestellt.

Kunden sollten mit @ProviderType kommentierte Produkt-APIs nicht implementieren oder erweitern product-apis-annotated-with-providertype-should-not-be-implemented-or-extended-by-customers

Die Experience Manager-API enthält Java™-Schnittstellen und -Klassen, die nur für die Verwendung - aber nicht Implementierung - durch benutzerdefinierten Code vorgesehen sind. Beispielsweise sollte nur Experience Manager die Schnittstelle com.day.cq.wcm.api.Page implementieren.

Wenn diesen Schnittstellen neue Methoden hinzugefügt werden, wirken sich diese zusätzlichen Methoden nicht auf vorhandenen Code aus, der diese Schnittstellen verwendet. Daher wird das Hinzufügen neuer Methoden zu diesen Schnittstellen als abwärtskompatibel betrachtet. Wenn jedoch benutzerdefinierter Code eine dieser Schnittstellen implementiert, erzeugt dieser benutzerspezifische Code ein Abwärtskompatibilitätsrisiko für den Kunden.

Schnittstellen und Klassen — wie durch Experience Manager implementiert — werden mit org.osgi.annotation.versioning.ProviderType oder manchmal einer ähnliche Legacy-Anmerkung aQute.bnd.annotation.ProviderType gekennzeichnet. Diese Regel identifiziert Fälle, in denen benutzerdefinierter Code eine solche Schnittstelle implementiert oder eine Klasse erweitert.

Nicht konformer Code non-compliant-code-3

import com.day.cq.wcm.api.Page;

public class DontDoThis implements Page {
// implementation here
}

Benutzerdefinierte Lucene-Oak-Indizes müssen über eine Tika-Konfiguration verfügen oakpal-indextikanode

Mehrere vorkonfigurierte Experience Manager Oak-Indizes enthalten eine Tika-Konfiguration und Anpassungen dieser Indizes müssen eine Tika-Konfiguration enthalten. Diese Regel überprüft auf Anpassungen der Indizes damAssetLucene, lucene und graphqlConfig und löst ein Problem aus, wenn entweder der Knoten tika fehlt oder wenn im Knoten tika ein untergeordneter Knoten mit dem Namen config.xml fehlt.

Weitere Informationen zum Anpassen von Indexdefinitionen finden Sie in der Dokumentation zur Indizierung.

Nicht konformer Code non-compliant-code-indextikanode

+ oak:index
    + damAssetLucene-1-custom
      - async: [async]
      - evaluatePathRestrictions: true
      - includedPaths: /content/dam
      - tags: [visualSimilaritySearch]
      - type: lucene

Konformer Code compliant-code-indextikanode

+ oak:index
    + damAssetLucene-1-custom-2
      - async: [async]
      - evaluatePathRestrictions: true
      - includedPaths: /content/dam
      - tags: [visualSimilaritySearch]
      - type: lucene
      + tika
        + config.xml

Benutzerdefinierte Lucene-Oak-Indizes dürfen nicht synchron sein oakpal-indexasync

Oak-Indizes des Typs lucene muss immer asynchron indiziert werden. Andernfalls kann es zu einer Instabilität des Systems kommen. Weitere Informationen zur Struktur von Lucene-Indizes finden Sie in der Dokumentation zu Oak.

Nicht konformer Code non-compliant-code-indexasync

+ oak:index
    + damAssetLucene-1-custom
      - evaluatePathRestrictions: true
      - includedPaths: /content/dam
      - type: lucene
      - tags: [visualSimilaritySearch]
      + tika
        + config.xml

Konformer Code compliant-code-indexasync

+ oak:index
    + damAssetLucene-1-custom-2
      - async: [async]
      - evaluatePathRestrictions: true
      - includedPaths: /content/dam
      - tags: [visualSimilaritySearch]
      - type: lucene
      + tika
        + config.xml

Benutzerdefinierte DAM-Asset-Lucene-Oak-Indizes sind ordnungsgemäß strukturiert oakpal-damAssetLucene-sanity-check

Damit die Asset-Suche in Experience Manager Assets ordnungsgemäß funktioniert, müssen die Anpassungen des damAssetLucene Oak-Index einem Satz von Richtlinien entsprechen, die für diesen Index spezifisch sind. Diese Regel überprüft, ob die Indexdefinition eine Eigenschaft mit mehreren Werten namens tags aufweisen muss, die den Wert visualSimilaritySearch enthält.

Nicht konformer Code non-compliant-code-damAssetLucene

+ oak:index
    + damAssetLucene-1-custom
      - async: [async, nrt]
      - evaluatePathRestrictions: true
      - includedPaths: /content/dam
      - type: lucene
      + tika
        + config.xml

Konformer Code compliant-code-damAssetLucene

+ oak:index
    + damAssetLucene-1-custom-2
      - async: [async, nrt]
      - evaluatePathRestrictions: true
      - includedPaths: /content/dam
      - tags: [visualSimilaritySearch]
      - type: lucene
      + tika
        + config.xml

Kundenpakete sollten keine Knoten unter libs erstellen oder ändern oakpal-customer-package

Gemäß einer bewährten Best Practice sollte die /libs-Inhaltsstruktur im Experience Manager-Content-Repository von Kunden als schreibgeschützt konfiguriert werden. Das Ändern von Knoten und Eigenschaften unter /libs ist bei großen und kleineren Aktualisierungen mit erheblichen Risiken verbunden. Verwenden Sie Adobe über offizielle Kanäle, um Änderungen an /libs vorzunehmen.

Pakete sollten keine doppelten OSGi-Konfigurationen enthalten oakpal-package-osgi

Ein häufig auftretendes Problem bei komplexen Projekten besteht darin, dass dieselbe OSGi-Komponente mehrfach konfiguriert wurde. Dadurch ist nicht mehr eindeutig, welche Konfiguration gelten soll. Diese Regel beachtet den jeweiligen Ausführungsmodus, da sie nur Probleme erkennt, bei denen dieselbe Komponente mehrmals im gleichen Ausführungsmodus oder in der gleichen Kombination aus Ausführungsmodi konfiguriert ist.

Nicht konformer Code non-compliant-code-osgi

+ apps
  + projectA
    + config
      + com.day.cq.commons.impl.ExternalizerImpl
  + projectB
    + config
      + com.day.cq.commons.impl.ExternalizerImpl

Konformer Code compliant-code-osgi

+ apps
  + shared-config
    + config
      + com.day.cq.commons.impl.ExternalizerImpl

Konfigurations- und Installationsordner sollten nur OSGi-Knoten enthalten oakpal-config-install

Aus Sicherheitsgründen sind Pfade, die /config/ und /install/ enthalten, nur von Benutzenden mit Administratorrechten in Experience Manager lesbar und sollten nur für OSGi-Konfigurationen und OSGi-Bundles verwendet werden. Wenn Sie andere Inhaltstypen in Pfade platzieren, die diese Segmente enthalten, unterscheidet sich das Anwendungsverhalten unbeabsichtigt zwischen Admin- und Nicht-Admin-Benutzern.

Ein häufig auftretendes Problem ist die Verwendung von Knoten mit der Bezeichnung config in Komponentendialogfeldern oder beim Angeben der Rich-Text-Editor-Konfiguration für die Inline-Bearbeitung. Um dieses Problem zu beheben, sollte der fehlerhafte Knoten umbenannt und mit einem kompatiblen Namen versehen werden. Nutzen Sie bei der Rich-Text-Editor-Konfiguration die Eigenschaft configPath im Knoten cq:inplaceEditing, um den neuen Speicherort anzugeben.

Nicht konformer Code non-compliant-code-config-install

+ cq:editConfig [cq:EditConfig]
  + cq:inplaceEditing [cq:InplaceEditConfig]
    + config [nt:unstructured]
      + rtePlugins [nt:unstructured]

Konformer Code compliant-code-config-install

+ cq:editConfig [cq:EditConfig]
  + cq:inplaceEditing [cq:InplaceEditConfig]
    ./configPath = inplaceEditingConfig (String)
    + inplaceEditingConfig [nt:unstructured]
      + rtePlugins [nt:unstructured]

Pakete sollten sich nicht überlappen oakpal-no-overlap

Ähnlich wie bei der Regel Pakete dürfen keine doppelten OSGi-Konfigurationen enthalten ist diese Situation ein häufig auftretendes Problem bei komplexen Projekten, bei denen derselbe Knotenpfad von mehreren separaten Inhaltspaketen in geschrieben wird. Die Verwendung von Abhängigkeiten zwischen Inhaltspaketen kann zwar ein konsistentes Ergebnis gewährleisten, doch ist es besser, Überschneidungen ganz zu vermeiden.

Der standardmäßige Authoring-Modus sollte nicht die klassische Benutzeroberfläche sein oakpal-default-authoring

Die OSGi-Konfiguration com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl definiert den standardmäßigen Authoring-Modus in Experience Manager. Da die klassische Benutzeroberfläche seit Experience Manager 6.4 nicht mehr unterstützt wird, tritt jetzt ein Problem auf, wenn als standardmäßiger Authoring-Modus die klassische Benutzeroberfläche konfiguriert ist.

Komponenten mit Dialogfeldern sollten Dialogfelder für die Touch-Benutzeroberfläche haben oakpal-components-dialogs

Experience Manager-Komponenten mit einem Dialogfeld für die klassische Benutzeroberfläche sollten immer über ein entsprechendes Dialogfeld für die Touch-Benutzeroberfläche verfügen. Beide bieten ein optimales Authoring-Erlebnis, das mit dem Cloud Service-Bereitstellungsmodell kompatibel ist, bei dem die klassische Benutzeroberfläche nicht mehr unterstützt wird. Diese Regel überprüft die folgenden Szenarien:

Die Dokumentation zu den Experience Manager-Modernisierungs-Tools bietet Dokumentation und Tools zum Konvertieren von Komponenten aus der klassischen Benutzeroberfläche in die Touch-Benutzeroberfläche. Weitere Details finden Sie in der Dokumentation zu den Experience Manager-Modernisierungs-Tools.

In Paketen sollten veränderliche und unveränderliche Inhalte nicht gemischt werden oakpal-packages-immutable

Um mit dem Cloud Service-Bereitstellungsmodell kompatibel zu sein, müssen einzelne Inhaltspakete entweder Inhalte für die unveränderlichen Bereiche des Repositorys (d. h. /apps und /libs) oder den veränderlichen Bereich (d. h. alles, was nicht in /apps oder /libs ist) enthalten, aber nicht beides. Beispielsweise ist ein Paket, das sowohl /apps/myco/components/text als auch /etc/clientlibs/myco enthält, nicht mit Cloud Service kompatibel und führt dazu, dass ein Problem gemeldet wird.

Weitere Details finden Sie unter Experience Manager-Projektstruktur.

Verwenden Sie keine Agenten für Rückwärtsreplikation oakpal-reverse-replication

Die Unterstützung für die Rückwärtsreplikation ist in Cloud-Service-Bereitstellungen nicht verfügbar, wie in den Versionshinweisen zu Experience Manager as a Cloud Service beschrieben.

Kunden, die die Rückwärtsreplikation verwenden, sollten sich für alternative Lösungen an Adobe wenden.

In Proxy-fähigen Client-Bibliotheken enthaltene Ressourcen sollten sich in einem Ordner mit dem Namen „resources“ befinden oakpal-resources-proxy

Experience Manager-Client-Bibliotheken können statische Ressourcen wie Bilder und Schriftarten enthalten. Wie im Dokument Verwenden von Präprozessoren beschrieben, müssen diese statischen Ressourcen bei der Verwendung von geproxidierten Client-Bibliotheken in einem untergeordneten Ordner namens resources enthalten sein, damit sie effektiv auf den Veröffentlichungsinstanzen referenziert werden können.

Nicht konformer Code non-compliant-proxy-enabled

+ apps
  + projectA
    + clientlib
      - allowProxy=true
      + images
        + myimage.jpg

Konformer Code compliant-proxy-enabled

+ apps
  + projectA
    + clientlib
      - allowProxy=true
      + resources
        + myimage.jpg

Verwenden von mit Cloud Service inkompatiblen Workflow-Prozessen oakpal-usage-cloud-service

Mit der Umstellung auf Asset-Microservices für die Asset-Verarbeitung in Adobe Experience Manager as a Cloud Service werden jetzt mehrere Workflow-Prozesse, die in On-Premise- und AMS-Versionen verwendet werden, nicht mehr unterstützt. Viele dieser Workflows sind ebenfalls überflüssig geworden.

Mit dem Migrations-Tool im GitHub-Repository für Experience Manager as a Cloud Service-Assets können Workflow-Modelle während der Migration in Experience Manager as a Cloud Service aktualisiert werden.

Es wird empfohlen anstelle von statischen Vorlagen bearbeitbare Vorlagen zu verwenden. oakpal-static-template

Auch wenn die Verwendung statischer Vorlagen in Experience Manager-Projekten früher üblich war, empfiehlt Adobe bearbeitbare Vorlagen zu verwenden, da sie die beste Flexibilität bieten und zusätzliche Funktionen besitzen, die in statischen Vorlagen nicht vorhanden sind. Weitere Informationen finden Sie im Dokument Seitenvorlagen.

Die Migration von statischen zu bearbeitbaren Vorlagen kann mithilfe des Experience Manager-Modernisierungs-Tools weitgehend automatisiert werden.

Die Verwendung veralteter Foundation-Komponenten wird nicht empfohlen oakpal-usage-legacy

Die veralteten Foundation-Komponenten (d. h. Komponenten unter /libs/foundation) werden seit mehreren Versionen von Experience Manager nicht mehr verwendet und wurden durch die Kernkomponenten ersetzt. Von der Verwendung der Foundation-Komponenten als Basis für benutzerdefinierte Komponenten – sei es durch Überlagerung oder Vererbung – wird abgeraten. Sie sollten in die entsprechende Kernkomponente konvertiert werden.

Experience Manager-Modernisierungs-Tools können diese Konvertierung erleichtern.

Verwenden Sie nur unterstützte Ausführungsmodusnamen und -reihenfolgen oakpal-supported-runmodes

Experience Manager as a Cloud Service erzwingt eine strikte Benennungsrichtlinie für Ausführungsmodusnamen und eine strikte Reihenfolge für diese Ausführungsmodi. Die Liste der unterstützten Ausführungsmodi wird im Dokument Bereitstellen auf Experience Manager as a Cloud Service begründet und jede Abweichung von dieser Liste wird als Problem identifiziert.

Knoten für benutzerdefinierte Suchindex-Definitionen müssen direkt untergeordnete Knoten von /oak:index sein oakpal-custom-search

Experience Manager as a Cloud Service verlangt, dass benutzerdefinierte Suchindex-Definitionen (d. h. Knoten vom Typ oak:QueryIndexDefinition) direkt untergeordnete Knoten von /oak:index sein müssen. Indizes in anderen Speicherorten müssen so verschoben werden, dass sie mit Experience Manager as a Cloud Service kompatibel sind. Weitere Informationen zu Suchindizes finden Sie im Dokument Inhaltssuche und -indizierung.

Knoten für benutzerdefinierte Suchindex-Definitionen benötigen eine compatVersion von 2 oakpal-custom-search-compatVersion

Experience Manager as a Cloud Service erfordert, dass die Eigenschaft compatVersion für benutzerdefinierte Suchindex-Definitionen (wie Knoten vom Typ oak:QueryIndexDefinition) auf 2 festgelegt wird. Adobe Experience Manager as a Cloud Service unterstützt keine anderen Werte. Weitere Informationen zu Suchindizes finden Sie unter Inhaltssuche und -indizierung .

Untergeordnete Knoten von benutzerdefinierten Suchindex-Definitionsknoten müssen dem Typ nt:unstructured entsprechen oakpal-descendent-nodes

Schwer behebbare Probleme können auftreten, wenn ein Knoten einer benutzerdefinierten Suchindex-Definition unstrukturierte untergeordnete Knoten enthält. Um diese Situation zu vermeiden, sollten alle untergeordneten Knoten eines oak:QueryIndexDefinition-Knotens dem Typ nt:unstructured sein.

Knoten einer benutzerdefinierten Suchindex-Definition müssen einen untergeordneten Knoten mit dem Namen indexRules enthalten, der wiederum untergeordnete Knoten enthält oakpal-custom-search-index

Ein ordnungsgemäß definierter benutzerdefinierter Suchindex-Definitionsknoten muss einen untergeordneten Knoten namens indexRules enthalten, der wiederum mindestens ein untergeordnetes Element aufweisen muss. Weitere Informationen finden Sie in der Oak-Dokumentation.

Knoten für benutzerdefinierte Suchindex-Definitionen müssen Benennungskonventionen folgen oakpal-custom-search-definitions

Experience Manager as a Cloud Service erfordert, dass benutzerdefinierte Suchindex-Definitionen (d. h. Knoten des Typs oak:QueryIndexDefinition) nach einem bestimmten Muster benannt werden, das im Dokument Inhaltssuche und -indizierung beschrieben wird.

Knoten für benutzerdefinierte Suchindex-Definitionen müssen den Indextyp Lucene verwenden oakpal-index-type-lucene

Experience Manager as a Cloud Service erfordert, dass benutzerdefinierte Suchindex-Definitionen (d. h. Knoten vom Typ oak:QueryIndexDefinition) eine type-Eigenschaft mit dem definierten Wert lucene aufweisen. Die Indizierung mit veralteten Indextypen muss vor der Migration auf Experience Manager as a Cloud Service aktualisiert werden. Weitere Informationen finden Sie unter Inhaltssuche und -indizierung.

Knoten einer benutzerdefinierten Suchindex-Definition dürfen keine Eigenschaft namens „seed“ enthalten oakpal-property-name-seed

Experience Manager as a Cloud Service verbietet es, dass benutzerdefinierte Suchindex-Definitionen (d. h. Knoten vom Typ oak:QueryIndexDefinition) eine Eigenschaft mit dem Namen seed enthalten. Die Indizierung mit dieser Eigenschaft muss vor der Migration auf Experience Manager as a Cloud Service aktualisiert werden. Weitere Informationen finden Sie im Dokument Inhaltssuche und -indizierung.

Knoten für die benutzerdefinierte Suchindex-Definition dürfen keine Eigenschaft namens „reindex“ enthalten oakpal-reindex-property

Experience Manager as a Cloud Service verbietet es, dass benutzerdefinierte Suchindex-Definitionen (d. h. Knoten vom Typ oak:QueryIndexDefinition) eine Eigenschaft mit dem Namen reindex enthalten. Die Indizierung mit dieser Eigenschaft muss vor der Migration auf Experience Manager as a
Cloud Service aktualisiert werden. Weitere Informationen finden Sie im Dokument Inhaltssuche und -indizierung.

Benutzerdefinierte DAM-Asset-Lucene-Knoten dürfen nicht queryPaths angeben oakpal-damAssetLucene-queryPaths

Nicht konformer Code non-compliant-code-damAssetLucene-queryPaths

+ oak:index
    + damAssetLucene-1-custom-1
      - async: [async, nrt]
      - evaluatePathRestrictions: true
      - includedPaths: [/content/dam]
      - queryPaths: [/content/dam]
      - type: lucene
      + tika
        + config.xml

Konformer Code compliant-code-damAssetLucene-queryPaths

+ oak:index
    + damAssetLucene-1-custom-2
      - async: [async, nrt]
      - evaluatePathRestrictions: true
      - includedPaths: [/content/dam]
      - tags: [visualSimilaritySearch]
      - type: lucene
      + tika
        + config.xml

Wenn die Definition des benutzerdefinierten Suchindex compatVersion enthält, muss sie auf 2 gesetzt werden oakpal-compatVersion

Der Indexknoten, der includedPaths angibt, sollte auch queryPaths mit denselben Werten angeben oakpal-included-paths-without-query-paths

Konfigurieren Sie für benutzerdefinierte Indizes includedPaths und queryPaths mit identischen Werten. Wenn einer angegeben ist, muss der andere damit übereinstimmen. Es gibt jedoch einen Sonderfall für Indizes von damAssetLucene, einschließlich der benutzerdefinierten Versionen. Geben Sie für diese Fälle nur includedPaths an.

Indexknoten, die nodeScopeIndex für den generischen Knotentyp angeben, sollten auch includedPaths und queryPaths angeben oakpal-full-text-on-generic-node-type

Wenn Sie die Eigenschaft nodeScopeIndex für einen „generischen“ Knotentyp wie nt:unstructured oder nt:base festlegen, müssen Sie auch die Eigenschaften includedPaths und queryPaths angeben.
Der Knotentyp "nt:base" kann als "generisch"betrachtet werden, da alle Knotentypen von ihm erben. Wenn Sie also nodeScopeIndex auf nt:base festlegen, werden alle Knoten im Repository indexiert. Ebenso wird auch nt:unstructured als „generisch“ betrachtet, da es in Repositorys viele Knoten mit diesem Typ gibt.

Nicht konformer Code non-compliant-code-full-text-on-generic-node-type

+ oak:index/acme.someIndex-custom-1
  - async: [async, nrt]
  - evaluatePathRestrictions: true
  - tags: [visualSimilaritySearch]
  - type: lucene
    + indexRules
      - jcr:primaryType: nt:unstructured
      + nt:base
        - jcr:primaryType: nt:unstructured
        + properties
          + acme.someIndex-custom-1
            - nodeScopeIndex: true

Konformer Code compliant-code-full-text-on-generic-node-type

+ oak:index/acme.someIndex-custom-1
  - async: [async, nrt]
  - evaluatePathRestrictions: true
  - tags: [visualSimilaritySearch]
  - type: lucene
  - includedPaths: ["/content/dam/"]
  - queryPaths: ["/content/dam/"]
    + indexRules
      - jcr:primaryType: nt:unstructured
      + nt:base
        - jcr:primaryType: nt:unstructured
        + properties
          + acme.someIndex-custom-1
            - nodeScopeIndex: true

Die Eigenschaft queryLimitReads der Abfrage-Engine sollte nicht überschrieben werden. oakpal-query-limit-reads

Das Überschreiben des Standardwerts kann dazu führen, dass Seitenaufrufe zu langsam erfolgen, insbesondere wenn mehr Inhalt hinzugefügt wird.

Mehrere aktive Versionen desselben Index oakpal-multiple-active-versions

Nicht konformer Code non-compliant-code-multiple-active-versions

+ oak:index
  + damAssetLucene-1-custom-1
    ...
  + damAssetLucene-1-custom-2
    ...
  + damAssetLucene-1-custom-3
    ...

Konformer Code compliant-code-multiple-active-versions

+ damAssetLucene-1-custom-3
    ...

Der Name vollständig benutzerdefinierter Indexdefinitionen sollte den offiziellen Richtlinien entsprechen. oakpal-fully-custom-index-name

Das erwartete Muster für vollständig benutzerdefinierte Indexnamen lautet: [prefix].[indexName]-custom-[version]. Weitere Informationen finden Sie im Dokument Inhaltssuche und -indizierung.

Dieselbe Eigenschaft mit unterschiedlichen analysierten Werten in derselben Indexdefinition oakpal-same-property-different-analyzed-values

Nicht konformer Code non-compliant-code-same-property-different-analyzed-values

+ indexRules
  + dam:Asset
    + properties
      + status
        - name: status
        - analyzed: true
  + dam:cfVariationNode
    + properties
      + status
        - name: status

Konformer Code compliant-code-same-property-different-analyzed-values

Beispiel:

+ indexRules
  + dam:Asset
    + properties
      + status
        - name: status
        - analyzed: true
  + dam:cfVariationNode
    + properties
      + status
        - name: status
        - analyzed: true

Beispiel:

+ indexRules
  + dam:Asset
    + properties
      + status
        - name: status
  + dam:cfVariationNode
    + properties
      + status
        - name: status
        - analyzed: true

Wenn die analysierte Eigenschaft nicht explizit festgelegt ist, lautet der Standardwert false.

Tags-Eigenschaft tags-property

Achten Sie bei bestimmten Indizes darauf, die Tags-Eigenschaft und die aktuellen Werte beizubehalten. Das Hinzufügen neuer Werte zur Tags-Eigenschaft ist zwar zulässig, das Löschen vorhandener Werte (oder der Eigenschaft insgesamt) kann jedoch zu unerwarteten Ergebnissen führen.

Indexdefinitionsknoten dürfen nicht im Inhaltspaket der Benutzeroberfläche bereitgestellt werden oakpal-ui-content-package

AEM Cloud Service verbietet die Bereitstellung benutzerdefinierter Suchindex-Definitionen (Knoten vom Typ oak:QueryIndexDefinition) im Inhaltspaket der Benutzeroberfläche.

Benutzerdefinierte Volltext-Indexdefinition des Typs damAssetLucene muss korrekt mit dem Präfix 'damAssetLucene' versehen werden oakpal-dam-asset-lucene

AEM Cloud Service verbietet es, benutzerdefinierte Volltext-Indexdefinitionen des Typs damAssetLucene mit anderen Präfixen als damAssetLucene zu versehen.

Indexdefinitionsknoten dürfen keine Eigenschaften mit demselben Namen enthalten oakpal-index-property-name

AEM Cloud Service verbietet es, dass benutzerdefinierte Suchindex-Definitionen (d. h. Knoten des Typs oak:QueryIndexDefinition) Eigenschaften mit demselben Namen enthalten.

Das Anpassen bestimmter vorkonfigurierter Indexdefinitionen ist verboten oakpal-customizing-ootb-index

AEM Cloud Service verbietet unbefugte Änderungen der folgenden vorkonfigurierten Indizes:

Die Konfiguration der Tokenizer in Analyzern sollte mit dem Namen 'tokenizer' erstellt werden oakpal-tokenizer

AEM Cloud Service verbietet die Erstellung von Tokenizern mit falschen Namen in Analyzern. Tokenizer sollten immer als tokenizer definiert werden.

Die Konfiguration von Indexdefinitionen darf keine Leerzeichen enthalten oakpal-indexing-definitions-spaces

AEM Cloud Service verbietet die Erstellung von Indexdefinitionen, die Eigenschaften mit Leerzeichen enthalten.