Aangepaste regels voor codekwaliteit custom-code-quality-rules

Leer details over de de kwaliteitsregels van de douanecode die door Cloud Manager als deel van worden uitgevoerd codekwaliteit het testen,op beste praktijken van AEM Techniek wordt gebaseerd.

SonarQube-regels sonarqube-rules

In de volgende sectie worden SonarQube-regels beschreven die door Cloud Manager worden uitgevoerd.

Gebruik geen potentieel gevaarlijke functies do-not-use-potentially-dangerous-functions

De methoden Thread.stop() en Thread.interrupt() kunnen problemen veroorzaken die moeilijk te reproduceren zijn, en soms ook beveiligingskwetsbaarheden. Het gebruik ervan moet zorgvuldig worden gecontroleerd en gevalideerd. Over het algemeen is het doorgeven van berichten een veiligere manier om vergelijkbare doelen te bereiken.

Niet-compatibele 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();
    }
  }
}

Compatibele 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();
    }
  }
}

Gebruik geen opmaaktekenreeksen die extern kunnen worden beheerd do-not-use-format-strings-which-may-be-externally-controlled

Het gebruiken van een formaatkoord van een externe bron (zoals een verzoekparameter of user-generated inhoud) kan een toepassing aan ontkenning van de dienstaanvallen blootstellen. Er zijn omstandigheden waarin een indelingstekenreeks extern kan worden beheerd, maar alleen is toegestaan vanuit vertrouwde bronnen.

Niet-compatibele 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-aanvragen moeten altijd een Socket- en Connect-time-out hebben http-requests-should-always-have-socket-and-connect-timeouts

Wanneer het uitvoeren van HTTP- verzoeken van binnen een AEM toepassing, is het kritiek om ervoor te zorgen dat juiste onderbrekingen worden gevormd om onnodige draadconsumptie te vermijden. Jammer genoeg, is het standaardgedrag van zowel de standaardHTTP- Cliënt van Java™, java.net.HttpUrlConnection, als de algemeen gebruikte cliënt van de Componenten van Apache HTTP aan nooit onderbreking, zodat moeten de onderbrekingen uitdrukkelijk worden geplaatst. Als beste praktijken, zouden deze onderbrekingen niet meer dan 60 seconden moeten zijn.

Niet-compatibele 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();
}

Compatibele 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();
}

Objecten ResourceResolver moeten altijd worden gesloten resourceresolver-objects-should-always-be-closed

ResourceResolver -objecten die uit ResourceResolverFactory zijn opgehaald, gebruiken systeembronnen. Hoewel er maatregelen zijn om deze bronnen terug te winnen wanneer een ResourceResolver niet meer in gebruik is, is het efficiënter om geopende ResourceResolver -objecten expliciet te sluiten door de methode close() aan te roepen.

Een veelvoorkomend misverstand is dat ResourceResolver -objecten die zijn gemaakt met een bestaande JCR-sessie, niet expliciet moeten worden gesloten of dat de onderliggende JCR-sessie moet worden gesloten. Dat is niet het geval. Ongeacht hoe een ResourceResolver wordt geopend, moet deze worden gesloten wanneer deze niet meer wordt gebruikt. Aangezien ResourceResolver de interface Closeable implementeert, is het ook mogelijk om de syntaxis try-with-resources te gebruiken in plaats van close() expliciet aan te roepen.

Niet-compatibele 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
}

Compatibele 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
  }
}

Servlet-paden niet gebruiken om Servlets te registreren do-not-use-sling-servlet-paths-to-register-servlets

Zoals die in de het Schuiven documentatiewordt beschreven, bindingen servlets door wegen wordt ontmoedigd. Padgebonden servers kunnen geen standaard JCR-toegangsbesturingselementen gebruiken en vereisen daarom extra beveiligingsstrengheid. In plaats van het gebruiken van weg-gebonden servlets, wordt het geadviseerd om knopen in de bewaarplaats tot stand te brengen en servlets te registreren door middeltype.

Niet-compatibele code non-compliant-code-5

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

Afgehandelde uitzonderingen moeten worden geregistreerd of gegenereerd, niet beide caught-exceptions-should-be-logged-or-thrown-but-not-both

In het algemeen, zou een uitzondering precies één keer moeten worden geregistreerd. Het registreren van uitzonderingen kan veelvoudige tijden verwarring veroorzaken aangezien het onduidelijk is hoe vaak een uitzondering voorkwam. Het meest gangbare patroon dat tot dit leidt is het registreren en het werpen van een gevangen uitzondering.

Niet-compatibele code non-compliant-code-6

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

Compatibele 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);
  }
}

Gebruik geen logboekinstructies die direct worden gevolgd door de instructies Throw avoid-having-a-log-statement-immediately-followed-by-a-throw-statement

Een ander gemeenschappelijk patroon te vermijden is een bericht te registreren en dan onmiddellijk een uitzondering te werpen. Dit geeft meestal aan dat het uitzonderingsbericht wordt gedupliceerd in logbestanden.

Niet-compatibele code non-compliant-code-7

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

Compatibele code compliant-code-4

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

Meld u niet aan bij INFO bij het verwerken van GET- of HEAD-verzoeken avoid-logging-at-info-when-handling-get-or-head-requests

In het algemeen, zou het INFO logboekniveau moeten worden gebruikt om belangrijke acties te afbakenen en, door gebrek, AEM wordt gevormd om bij het INFO niveau of boven te registreren. GET- en HEAD-methoden mogen nooit alleen-lezen zijn en vormen dus geen belangrijke acties. Het registreren op het niveau INFO in antwoord op GET of HEAD verzoeken zal waarschijnlijk tot significante logboeklawaai leiden, die het moeilijker maken om nuttige informatie in logboekdossiers te identificeren. Het registreren wanneer de behandeling van GET of HEAD- verzoeken of op de niveaus van de WAARSCHUWING of van de FOUT zou moeten zijn wanneer iets verkeerd is gegaan of op de niveaus DEBUG of van de TRACE als de diepere het oplossen van problemeninformatie nuttig zou zijn.

Niet-compatibele code non-compliant-code-8

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

Compatibele code compliant-code-5

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

Gebruik Exception.getMessage() niet als de eerste parameter van een Logging-instructie do-not-use-exception-getmessage-as-the-first-parameter-of-a-logging-statement

Als beste praktijken, zouden de logboekberichten contextuele informatie over moeten verstrekken waar in de toepassing een uitzondering is voorgekomen. Terwijl de context ook door stapelsporen te gebruiken kan worden bepaald, over het algemeen zal het logboekbericht gemakkelijker zijn te lezen en te begrijpen. Dientengevolge, wanneer het registreren van een uitzondering, is het een slechte praktijk om het bericht van de uitzondering als logboekbericht te gebruiken. Het uitzonderingsbericht bevat wat verkeerd ging terwijl het logboekbericht zou moeten worden gebruikt om een logboeklezer te vertellen wat de toepassing deed toen de uitzondering gebeurde. Het uitzonderingsbericht wordt nog geregistreerd. Door uw eigen bericht te specificeren, zijn de logboeken gemakkelijker te begrijpen.

Niet-compatibele code non-compliant-code-9

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

Compatibele code compliant-code-6

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

Aanmelden bij Vangstblokken moet plaatsvinden op het WAARSCHUWINGSniveau of FOUTniveau logging-in-catch-blocks-should-be-at-the-warn-or-error-level

Zoals de naam al aangeeft, moeten Java™-uitzonderingen altijd in uitzonderlijke omstandigheden worden gebruikt. Dientengevolge, wanneer een uitzondering wordt gevangen, is het belangrijk om ervoor te zorgen dat de logboekberichten op het aangewezen niveau worden geregistreerd: of WARN of FOUT. Dit zorgt ervoor dat die berichten correct in de logboeken verschijnen.

Niet-compatibele code non-compliant-code-10

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

Compatibele code compliant-code-7

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

Stapelsporen niet naar de console afdrukken do-not-print-stack-traces-to-the-console

De context is kritiek wanneer het begrip van logboekberichten. Wanneer u Exception.printStackTrace() gebruikt, wordt alleen de stacktracering uitgevoerd naar de standaardfoutenstream, waardoor alle context verloren gaat. Bovendien kunnen in een multithread-toepassing, zoals AEM, meerdere uitzonderingen parallel met deze methode worden afgedrukt, de stacksporen ervan overlappen, wat tot grote verwarring leidt. De uitzonderingen zouden door het registrerenkader slechts moeten worden geregistreerd.

Niet-compatibele code non-compliant-code-11

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

Compatibele code compliant-code-8

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

Niet uitvoeren naar standaardinvoer of standaardfout do-not-output-to-standard-output-or-standard-error

Het registreren in AEM zou altijd door het registrerenkader, SLF4J moeten worden gedaan. De uitvoer rechtstreeks naar de standaarduitvoer of standaardfoutenstromen verliest de structurele en contextuele informatie die door het registrerenkader wordt verstrekt en kan, soms, prestatieskwesties veroorzaken.

Niet-compatibele code non-compliant-code-12

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

Compatibele code compliant-code-9

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

Hardcoded /apps en /libs paden vermijden avoid-hardcoded-apps-and-libs-paths

Doorgaans moeten paden die beginnen met /libs en /apps niet worden gecodeerd als de paden waarnaar ze verwijzen, meestal worden opgeslagen als paden die relatief zijn ten opzichte van het zoekpad met de waarde Schuivend (standaard is dit ingesteld op /libs,/apps ). Het gebruik van het absolute pad kan leiden tot subtiele defecten die pas later in de levenscyclus van het project verschijnen.

Niet-compatibele code non-compliant-code-13

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

Compatibele code compliant-code-10

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

Verkoopplanner mag niet worden gebruikt sonarqube-sling-scheduler

Gebruik Sling Scheduler niet voor taken waarvoor een gegarandeerde uitvoering is vereist. Het verkopen van Geplande Banen garandeert uitvoering en beter geschikt voor zowel gegroepeerde als niet-gegroepeerde milieu's.

Verwijs naar Apache het Sling Event en de documentatie van de Verwerking van de Baanom meer over te leren hoe het Verdelen van Banen in gegroepeerde milieu's wordt behandeld.

Verouderde API's AEM niet mogen worden gebruikt sonarqube-aem-deprecated

Het AEM API-oppervlak wordt voortdurend herzien om te bepalen voor welke API's het gebruik wordt ontmoedigd en dus als afgekeurd wordt beschouwd.

Deze API's zijn vaak verouderd met de standaard Java™- @Deprecated -annotatie en worden dus herkend door squid:CallToDeprecatedMethod .

Er zijn echter gevallen waarin een API in de context van AEM verouderd is, maar in andere contexten niet mag worden vervangen. Deze regel identificeert deze tweede klasse.

Regels voor OakPAL-inhoud oakpal-rules

In de volgende sectie worden de OakPAL-controles beschreven die door Cloud Manager worden uitgevoerd.

Product-API's die zijn voorzien van een annotatie met @ProviderType mogen niet worden geïmplementeerd of uitgebreid door klanten product-apis-annotated-with-providertype-should-not-be-implemented-or-extended-by-customers

De AEM-API bevat Java™-interfaces en -klassen die alleen door aangepaste code moeten worden gebruikt, maar niet geïmplementeerd. De interface com.day.cq.wcm.api.Page wordt bijvoorbeeld alleen geïmplementeerd door AEM.

Wanneer nieuwe methoden aan deze interfaces worden toegevoegd, beïnvloeden deze aanvullende methoden geen bestaande code die deze interfaces gebruikt en daardoor wordt de toevoeging van nieuwe methoden aan deze interfaces beschouwd als compatibel met eerdere versies. Nochtans, als de douanecode één van deze interfaces uitvoert, heeft die douanecode een achterwaarts-verenigbaarheidsrisico voor de klant geïntroduceerd.

Interfaces en klassen die alleen bedoeld zijn om door AEM te worden geïmplementeerd, zijn voorzien van een annotatie org.osgi.annotation.versioning.ProviderType of soms een vergelijkbare oudere annotatie aQute.bnd.annotation.ProviderType . Deze regel identificeert de gevallen waarin een dergelijke interface wordt uitgevoerd of een klasse door douanecode wordt uitgebreid.

Niet-compatibele code non-compliant-code-3

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

public class DontDoThis implements Page {
// implementation here
}

Klantpakketten mogen geen knooppunten onder /libs maken of wijzigen oakpal-customer-package

Het is al lang een goede gewoonte om de /libs -inhoudsstructuur in de AEM-inhoudsopslagruimte als alleen-lezen te beschouwen voor klanten. Als u knooppunten en eigenschappen wijzigt onder /libs , ontstaat een aanzienlijk risico voor belangrijke en kleine updates. Wijzigingen in /libs worden alleen via officiële Adobe aangebracht.

Pakketten mogen geen dubbele OSGi-configuraties bevatten oakpal-package-osgi

Een gemeenschappelijk probleem dat op complexe projecten voorkomt is waar de zelfde component OSGi veelvoudige tijden wordt gevormd. Dit leidt tot een dubbelzinnigheid over welke configuratie operabel is. Deze regel is "runmode-bewust"in die zin dat het slechts kwesties zal identificeren waar de zelfde component veelvoudige tijden op de zelfde looppaswijze of de combinatie looppaswijzen wordt gevormd.

Niet-compatibele code non-compliant-code-osgi

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

Compatibele code compliant-code-osgi

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

Mappen configureren en installeren mag alleen OSGi-knooppunten bevatten oakpal-config-install

Om veiligheidsredenen zijn paden die /config/ en /install/ bevatten, alleen leesbaar voor gebruikers met administratieve bevoegdheden in AEM en moeten deze paden alleen worden gebruikt voor OSGi-configuraties en OSGi-bundels. Als u andere typen inhoud onder paden plaatst die deze segmenten bevatten, resulteert dit in toepassingsgedrag dat per ongeluk verschilt tussen gebruikers met en zonder beheerdersrechten.

Een veelvoorkomend probleem is het gebruik van knooppunten met de naam config in componentdialoogvensters of wanneer u de configuratie van de rich text editor opgeeft voor inlinebewerking. Om dit op te lossen, zou de beledigende knoop aan een volgzame naam moeten worden anders genoemd. Voor de configuratie van de RTF-editor gebruikt u de eigenschap configPath op het knooppunt cq:inplaceEditing om de nieuwe locatie op te geven.

Niet-compatibele code non-compliant-code-config-install

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

Compatibele code compliant-code-config-install

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

Pakketten mogen elkaar niet overlappen oakpal-no-overlap

Gelijkaardig aan de Pakketten zouden de Dubbele regel van Configuraties niet moeten bevatten OSGi,dit is een gemeenschappelijk probleem op complexe projecten waar de zelfde knoopweg aan door veelvoudige afzonderlijke inhoudspakketten wordt geschreven. Terwijl het gebruiken van inhoudspakketgebiedsdelen kan worden gebruikt om een verenigbaar resultaat te verzekeren, is het beter om overlappingen volledig te vermijden.

Standaardontwerpmodus mag geen klassieke UI zijn oakpal-default-authoring

De configuratie OSGi com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl bepaalt de standaard auteurswijze binnen AEM. Omdat Klassieke UI sinds AEM 6.4 is afgekeurd, wordt een kwestie nu opgeheven wanneer de standaard auteurswijze aan Klassieke UI wordt gevormd.

Componenten met dialoogvensters moeten aanraakinterface-dialoogvensters hebben oakpal-components-dialogs

AEM Componenten die een Klassieke UI dialoog hebben zouden altijd een overeenkomstige dialoog van de Aanraking UI moeten hebben zowel om een optimale auteurservaring te verstrekken als met het de plaatsingsmodel van de Cloud Service compatibel te zijn, waar Klassieke UI niet wordt gesteund. Deze regel verifieert de volgende scenario's:

De documentatie van de Hulpmiddelen van de Modernisering van het AEM verstrekt details en tooling voor hoe te om componenten van Klassieke UI in Aanraakinterface om te zetten. Verwijs naar de documentatie van Hulpmiddelen van de Modernisering van de AEMvoor meer details.

Reverse Replication Agents mogen niet worden gebruikt oakpal-reverse-replication

De steun voor omgekeerde replicatie is niet beschikbaar in de plaatsingen van de Cloud Service, zoals die in worden beschreven de Nota's van de Versie: Verwijdering van de Agenten van de Replicatie.

De klanten die omgekeerde replicatie gebruiken zouden Adobe voor alternatieve oplossingen moeten contacteren.

De middelen in volmacht-Toegelaten Bibliotheken van de Cliënt zouden in een Omslag moeten zijn genoemde middelen oakpal-resources-proxy

AEM clientbibliotheken kunnen statische bronnen bevatten, zoals afbeeldingen en lettertypen. Zoals beschreven in Gebruikend cliënt-Kant de documentatie van Bibliotheken,wanneer het gebruiken van pro-xied cliëntbibliotheken moeten deze statische middelen in een kindomslag genoemd resources worden bevat om effectief op te worden van verwijzingen voorzien te publiceren instanties.

Niet-compatibele code non-compliant-proxy-enabled

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

Compatibele code compliant-proxy-enabled

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

Gebruik van Cloud Service niet-compatibele workflowprocessen oakpal-usage-cloud-service

Met de overstap naar Asset micro-services voor de verwerking van bedrijfsmiddelen op AEM Cloud Service zijn verschillende workflowprocessen die werden gebruikt in on-premise en AMS-versies van AEM niet ondersteund of onnodig geworden.

Het migratiehulpmiddel in de as a Cloud Service GitHub bewaarplaats van AEM Assetskan worden gebruikt om werkschemamodellen tijdens migratie aan AEM as a Cloud Service bij te werken.

Het gebruik van statische sjablonen wordt ontmoedigd ten gunste van bewerkbare sjablonen oakpal-static-template

Terwijl het gebruik van statische malplaatjes in AEM Projecten historisch algemeen is geweest, worden de editable malplaatjes hoogst geadviseerd aangezien zij de meeste flexibiliteit verstrekken en extra eigenschappen steunen die niet in statische malplaatjes aanwezig zijn. Meer informatie kan in de Malplaatjes van de Pagina worden gevonden - editable documentatie.

De migratie van statisch aan editable malplaatjes kan grotendeels worden geautomatiseerd gebruikend AEM Moderniseringshulpmiddelen.

Het gebruik van verouderde elementcomponenten wordt ontmoedigd oakpal-usage-legacy

De oudere Componenten van de Stichting (d.w.z. componenten onder /libs/foundation) zijn afgekeurd voor verscheidene AEM versies ten gunste van de Componenten van de Kern. Het gebruik van de oudere Foundation Components als de basis voor aangepaste componenten, door bedekking of overerving, wordt afgeraden en moet worden omgezet in de corresponderende kerncomponent.

Deze omzetting kan door worden vergemakkelijkt AEM Moderniseringshulpmiddelen.

De de definitieknoden van de indexdefinitie van het Onderzoek van de douane moeten directe kinderen van /eikel zijn:index oakpal-custom-search

AEM Cloud Service vereist dat definities van aangepaste zoekindexen (d.w.z. knooppunten van het type oak:QueryIndexDefinition) directe onderliggende knooppunten van /oak:index zijn. Indexen op andere locaties moeten worden verplaatst om compatibel te zijn met AEM Cloud Service. Meer informatie over onderzoeksindexen kan in het Onderzoek van de Inhoud en het Indexeren documentatie worden gevonden.

Knooppunten voor definitie van aangepaste zoekindex moeten een compatVersion van 2 hebben oakpal-custom-search-compatVersion

AEM Cloud Service vereist dat in definities van aangepaste zoekindexen (bijvoorbeeld knooppunten van het type oak:QueryIndexDefinition ) de eigenschap compatVersion is ingesteld op 2 . Een andere waarde wordt niet ondersteund door AEM Cloud Service. Meer informatie over onderzoeksindexen kan in het Onderzoek van de Inhoud en het Indexeren documentatie worden gevonden.

De afstammende knopen van de Definitie van de Index van het Onderzoek van het Douane moeten van type zijn:niet gestructureerd oakpal-descendent-nodes

Problemen met moeilijk op te lossen problemen kunnen optreden wanneer een definitieknoopknooppunt van een aangepaste zoekindex niet-geordende onderliggende knooppunten bevat. Om deze te voorkomen, wordt aangeraden dat alle afstammende knooppunten van een knooppunt oak:QueryIndexDefinition van het type nt:unstructured zijn.

Knooppunten voor aangepaste zoekindexdefinitie moeten een onderliggende node met de naam indexRules bevatten die onderliggende items bevat oakpal-custom-search-index

Een correct gedefinieerd definitieknoopknooppunt van een aangepaste zoekindex moet een onderliggend knooppunt met de naam indexRules bevatten, dat op zijn beurt minstens één onderliggend knooppunt moet hebben. Meer informatie kan in de documentatie van Oak worden gevonden.

Knooppunten voor aangepaste zoekindexdefinitie moeten naamgevingsconventies volgen oakpal-custom-search-definitions

AEM Cloud Service vereist dat de definities van de douaneonderzoeksindex (namelijk knopen van type oak:QueryIndexDefinition) na een specifiek patroon moeten worden genoemd dat op wordt beschreven Inhoud Onderzoek en het Indexeren.

De de definitieknoden van de Definitie van de Index van het Onderzoek van de Douane moeten de winst van het Type van Index gebruiken oakpal-index-type-lucene

AEM Cloud Service vereist dat definities van aangepaste zoekindexen (d.w.z. knooppunten van het type oak:QueryIndexDefinition) de eigenschap type hebben met de waarde ingesteld op lucene . Indexering met oudere indextypen moet worden bijgewerkt voordat u naar AEM Cloud Service gaat. Zie het Onderzoek van de Inhoud en het Indexeren documentatievoor meer informatie.

De definitieknooppunten van de index van het Onderzoek van de douane moeten geen bezit genoemd zaad bevatten oakpal-property-name-seed

AEM Cloud Service staat definities van aangepaste zoekindexen (dat wil zeggen knooppunten van het type oak:QueryIndexDefinition ) niet toe om een eigenschap met de naam seed te bevatten. Indexering met deze eigenschap moet worden bijgewerkt voordat u naar AEM Cloud Service gaat. Zie het Onderzoek van de Inhoud en het Indexeren documentatievoor meer informatie.

De definitieknooppunten van de aangepaste zoekindex mogen geen eigenschap met de naam redex bevatten oakpal-reindex-property

AEM Cloud Service staat definities van aangepaste zoekindexen (dat wil zeggen knooppunten van het type oak:QueryIndexDefinition ) niet toe om een eigenschap met de naam reindex te bevatten. Indexering met deze eigenschap moet worden bijgewerkt voordat u naar AEM Cloud Service gaat. Zie het Onderzoek van de Inhoud en het Indexeren documentatievoor meer informatie.

De knooppunten van de indexdefinitie moeten niet in het inhoudspakket worden opgesteld UI oakpal-ui-content-package

AEM Cloud Service staat toe dat definities van aangepaste zoekindexen (knooppunten van het type oak:QueryIndexDefinition ) niet worden geïmplementeerd in het pakket met UI-inhoud.

Aangepaste full-text indexdefinitie van type damAssetLucene moet correct worden voorgefixeerd met 'damAssetLucene' oakpal-dam-asset-lucene

AEM Cloud Service staat toe dat aangepaste full-text indexdefinities van het type damAssetLucene worden voorafgegaan door andere items dan damAssetLucene .

De knooppunten van de indexdefinitie mogen geen eigenschappen met dezelfde naam bevatten oakpal-index-property-name

AEM Cloud Service staat definities van aangepaste zoekindexen (knooppunten van het type oak:QueryIndexDefinition ) niet toe om eigenschappen met dezelfde naam te bevatten

Het aanpassen van bepaalde OTB-indexdefinities is verboden oakpal-customizing-ootb-index

AEM Cloud Service staat ongeoorloofde wijzigingen van de volgende OOTB-indexen niet toe:

De conkenizers in de analysatoren moeten worden geconfigureerd met de naam 'tokenizer'. oakpal-tokenizer

AEM Cloud Service verbiedt het maken van kenizers met onjuiste namen in analysatoren. Tokenizers moeten altijd als tokenizer worden gedefinieerd.

Dispatcher Optimization Tool dispatcher-optimization-tool-rules

In de volgende sectie worden de door Cloud Manager uitgevoerde controles van het Dispatcher Optimization Tool (DOT) weergegeven. Volg de verbindingen voor elke controle voor zijn definitie en details GitHub.