En esta página se describen las reglas de calidad de código personalizadas ejecutadas por Cloud Manager creadas en función de las prácticas recomendadas de AEM ingeniería.
Las muestras de código que se proporcionan aquí tienen fines ilustrativos. Consulte Conceptos para conocer los conceptos y las reglas de calidad de SonarQube.
La siguiente sección resalta las reglas de SonarQube:
Clave: CQRules:CWE-676
Tipo: Vulnerabilidad
Gravedad: Mayor
Desde: Versión 2018.4.0
Los métodos Thread.stop() y Thread.interrupt() pueden producir problemas difíciles de reproducir y, en algunos casos, vulnerabilidades de seguridad. Su utilización debe ser objeto de un estricto seguimiento y validación. En general, transmitir mensajes es una manera más segura de lograr objetivos similares.
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();
}
}
}
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();
}
}
}
Clave: CQRules:CWE-134
Tipo: Vulnerabilidad
Gravedad: Mayor
Desde: Versión 2018.4.0
El uso de una cadena de formato de una fuente externa (como un parámetro de solicitud o contenido generado por el usuario) puede producir y exponer una aplicación a ataques de denegación de servicio. Hay circunstancias en las que una cadena de formato puede estar controlada externamente, pero solo se permite desde fuentes de confianza.
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);
}
Clave: CQRules:ConnectionTimeoutFacility
Tipo: Error
Gravedad: Crítico
Desde: Versión 2018.6.0
Cuando se ejecutan solicitudes HTTP desde dentro de una aplicación AEM, es fundamental asegurarse de que se han configurado los tiempos de espera adecuados para evitar el consumo innecesario de subprocesos. Desafortunadamente, el comportamiento predeterminado tanto del cliente HTTP predeterminado de Java (java.net.HttpUrlConnection) como del cliente de componentes HTTP Apache que se utiliza habitualmente es no agotar el tiempo de espera, por lo que los tiempos de espera deben establecerse explícitamente. Además, como práctica recomendada, estos tiempos de espera no deben superar los 60 segundos.
@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();
}
@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();
}
Clave: CQBP-84, dependencias CQBP-84
Tipo: Error
Gravedad: Crítico
Desde: Versión 2018.7.0
La API de AEM contiene interfaces y clases de Java que solo están pensadas para utilizarse, pero no para implementarse, mediante código personalizado. Por ejemplo, la interfaz com.day.cq.wcm.api.Page está diseñada para que la implemente solo AEM.
Cuando se añaden nuevos métodos a estas interfaces, esos métodos adicionales no afectan al código existente que utiliza estas interfaces y, como resultado, la adición de nuevos métodos a estas interfaces se considera compatible con versiones anteriores. Sin embargo, si el código personalizado implementa una de estas interfaces, dicho código personalizado ha introducido un riesgo de compatibilidad con versiones anteriores para el cliente.
Las interfaces (y clases) que solo están destinadas a ser implementadas por AEM están anotadas con org.osgi.anottation.versioning.ProviderType (o, en algunos casos, con una anotación heredada similar Qute.bnd.anottation.ProviderType). Esta regla identifica los casos en los que una interfaz de este tipo se implementa (o una clase se amplía) mediante código personalizado.
import com.day.cq.wcm.api.Page;
public class DontDoThis implements Page {
// implementation here
}
Clave: CQRules:CQBP-72
Tipo: Huele de código
Gravedad: Mayor
Desde: Versión 2018.4.0
Los objetos ResourceResolver obtenidos de ResourceResolverFactory consumen recursos del sistema. Aunque existen medidas para recuperar estos recursos cuando ResourceResolver ya no se utiliza, es más eficaz cerrar explícitamente cualquier objeto ResourceResolver abierto llamando al método close().
Una idea errónea relativamente común es que los objetos ResourceResolver creados con una sesión de JCR existente no deben cerrarse explícitamente o que, al hacerlo, se cerrará la sesión de JCR subyacente. Este no es el caso, independientemente de cómo se abra un ResourceResolver, debe cerrarse cuando ya no se utilice. Dado que ResourceResolver implementa la interfaz Closeable, también es posible utilizar la sintaxis try-with-resources en lugar de invocar explícitamente close().
public void dontDoThis(Session session) throws Exception {
ResourceResolver resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object)session));
// do some stuff with the resolver
}
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
}
}
Clave: CQRules:CQBP-75
Tipo: Huele de código
Gravedad: Mayor
Desde: Versión 2018.4.0
Como se describe en la documentación de Sling, se desaconseja enlazar servlets por rutas. Los servlets enlazados a rutas no pueden utilizar controles de acceso de JCR estándar y, como resultado, requieren mayor rigor de seguridad. En lugar de utilizar servlets enlazados a rutas, se recomienda crear nodos en el repositorio y registrar servlets por tipo de recurso.
@Component(property = {
"sling.servlet.paths=/apps/myco/endpoint"
})
public class DontDoThis extends SlingAllMethodsServlet {
// implementation
}
Clave: CQRules:CQBP-44—CatchAndOrLogOrThrow
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
En general, una excepción debe registrarse exactamente una vez. El registro de excepciones varias veces puede causar confusión, ya que no está claro cuántas veces se produjo una excepción. El patrón más común que lleva a esto es registrar y lanzar una excepción capturada.
public void dontDoThis() throws Exception {
try {
someOperation();
} catch (Exception e) {
logger.error("something went wrong", e);
throw e;
}
}
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);
}
}
Clave: CQRules:CQBP-44—ConsecutivamenteLogAndThrow
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
Otro patrón común que hay que evitar es registrar un mensaje y luego emitir inmediatamente una excepción. Esto generalmente indica que el mensaje de excepción terminará duplicado en los archivos de registro.
public void dontDoThis() throws Exception {
logger.error("something went wrong");
throw new RuntimeException("something went wrong");
}
public void doThis() throws Exception {
throw new RuntimeException("something went wrong");
}
Clave: CQRules:CQBP-44—LogInfoInGetOrHeadRequests
Tipo: Huele de código
Gravedad: Menor
En general, el nivel de registro INFO debe utilizarse para demarcar acciones importantes y, de forma predeterminada, AEM está configurado para registrar en el nivel INFO o superior. Los métodos de GET y HEAD sólo deben ser operaciones de sólo lectura y, por tanto, no constituyen acciones importantes. Es probable que el registro en el nivel INFO en respuesta a solicitudes de GET o HEAD cree un ruido de registro significativo, lo que dificulta la identificación de información útil en los archivos de registro. El registro cuando se gestionen solicitudes de GET o HEAD debe estar en los niveles ADVERTENCIA o ERROR cuando algo haya salido mal o en los niveles DEBUG o TRACE si resulta útil disponer de información más detallada sobre la solución de problemas.
Esto no se aplica al registro de tipo access.log para cada solicitud.
public void doGet() throws Exception {
logger.info("handling a request from the user");
}
public void doGet() throws Exception {
logger.debug("handling a request from the user.");
}
Clave: CQRules:CQBP-44—ExceptionGetMessageIsFirstLogParam
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
Como práctica recomendada, los mensajes de registro deben proporcionar información contextual sobre dónde se produjo una excepción en la aplicación. Aunque el contexto también se puede determinar mediante el uso de trazos de pila, en general el mensaje de registro será más fácil de leer y comprender. Como resultado, al registrar una excepción, es una mala práctica utilizar el mensaje de excepción como mensaje de registro: el mensaje de excepción contendrá lo que salió mal, mientras que el mensaje de registro debe utilizarse para indicar a un lector de registro qué estaba haciendo la aplicación cuando se produjo la excepción. Se seguirá registrando el mensaje de excepción; al especificar su propio mensaje, los registros serán más fáciles de entender.
public void dontDoThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
logger.error(e.getMessage(), e);
}
}
public void doThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
logger.error("Unable to do something", e);
}
}
Clave: CQRules:CQBP-44—WrongLogLevelInCatchBlock
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
Como sugiere el nombre, las excepciones de Java siempre deben usarse en circunstancias excepcionales. Como resultado, cuando se detecta una excepción, es importante asegurarse de que los mensajes de registro se registran en el nivel adecuado, ya sea WARN o ERROR. Esto garantiza que esos mensajes aparezcan correctamente en los registros.
public void dontDoThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
logger.debug(e.getMessage(), e);
}
}
public void doThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
logger.error("Unable to do something", e);
}
}
Clave: CQRules:CQBP-44—ExceptionPrintStackTrace
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
Como se ha mencionado anteriormente, el contexto es fundamental para comprender los mensajes de registro. El uso de Exception.printStackTrace() hace que solamente el seguimiento de pila se envíe al flujo de error estándar, perdiendo así todo el contexto. Además, en una aplicación con varios subprocesos, como AEM, si se imprimen varias excepciones mediante este método en paralelo, sus trazos de pila pueden superponerse, lo que produce una confusión significativa. Las excepciones solo se deben registrar a través del módulo de registro.
public void dontDoThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
e.printStackTrace();
}
}
public void doThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
logger.error("Unable to do something", e);
}
}
Clave: CQRules:CQBP-44—LogLevelConsolePrinters
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
El inicio de sesión AEM siempre debe realizarse a través del marco de registro (SLF4J). La salida directa a los flujos de error estándar o de salida estándar pierde la información estructural y contextual proporcionada por el marco de registro y, en algunos casos, puede causar problemas de rendimiento.
public void dontDoThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
System.err.println("Unable to do something");
}
}
public void doThis() {
try {
someMethodThrowingAnException();
} catch (Exception e) {
logger.error("Unable to do something", e);
}
}
Clave: CQRules:CQBP-71
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2018.4.0
En general, las rutas que inicio con /libs y /apps no deben codificarse como no modificables, ya que las rutas a las que hacen referencia se almacenan normalmente como rutas relativas a la ruta de búsqueda Sling (que se establece en /libs,/apps de forma predeterminada). El uso de la ruta absoluta puede introducir defectos sutiles que solo aparecerían más adelante en el ciclo vital del proyecto.
public boolean dontDoThis(Resource resource) {
return resource.isResourceType("/libs/foundation/components/text");
}
public void doThis(Resource resource) {
return resource.isResourceType("foundation/components/text");
}
Clave: CQRules:AMSCORE-554
Tipo: Compatibilidad entre huele y Cloud Service de código
Gravedad: Menor
Desde: Versión 2020.5.0
El Planificador Sling no debe utilizarse para tareas que requieran una ejecución garantizada. Los trabajos programados de Sling garantizan la ejecución y se adaptan mejor a los entornos agrupados y no agrupados.
Consulte Apache Sling Eventing and Job Handling para obtener más información sobre cómo se gestionan los trabajos Sling en entornos agrupados.
Clave: AMSCORE-553
Tipo: Compatibilidad entre huele y Cloud Service de código
Gravedad: Menor
Desde: Versión 2020.5.0
La superficie de la API de AEM está bajo constante revisión para identificar las API para las que se desaconseja el uso y, por lo tanto, se considera obsoleta.
En muchos casos, estas API están en desuso usando la anotación estándar de Java @Deprecated y, como tal, identificadas por squid:CallToDeprecatedMethod
.
Sin embargo, hay casos en los que una API está en desuso en el contexto de la AEM, pero puede que no quede en desuso en otros contextos. Esta regla identifica esta segunda clase.
Debajo de las comprobaciones OakPAL ejecutadas por Cloud Manager.
OakPAL es un marco de trabajo desarrollado por un socio AEM (y ganador de 2019 AEM Rockstar Norteamérica) que valida los paquetes de contenido usando un repositorio Oak independiente.
Clave: BannedPath
Tipo: Error
Gravedad: Bloqueador
Desde: Versión 2019.6.0
Desde hace mucho tiempo, se recomienda que los clientes consideren el árbol de contenido /libs del repositorio de contenido de AEM como de solo lectura. La modificación de nodos y propiedades en /libs crea un riesgo significativo para actualizaciones mayores y menores. Las modificaciones a /libs sólo deben realizarse por Adobe mediante canales oficiales.
Clave: DuplicateOsgiConfigurations
Tipo: Error
Gravedad: Mayor
Desde: Versión 2019.6.0
Un problema común que se produce en proyectos complejos es que el mismo componente OSGi se configura varias veces. Esto crea una ambigüedad en cuanto a la configuración que puede funcionar. Esta regla tiene en cuenta el modo de ejecución, ya que solo identificará problemas en los que el mismo componente se haya configurado varias veces en el mismo modo de ejecución (o combinación de modos de ejecución).
+ projectA
+ config
+ com.day.cq.commons.impl.ExternalizerImpl
+ projectB
+ config
+ com.day.cq.commons.impl.ExternalizerImpl
+ shared-config
+ config
+ com.day.cq.commons.impl.ExternalizerImpl
Clave: ConfigAndInstallMustOnlyContainOsgiNodes
Tipo: Error
Gravedad: Mayor
Desde: Versión 2019.6.0
Por motivos de seguridad, las rutas que contienen /config/ y /install/ sólo pueden leerlas los usuarios administrativos en AEM y solo deben utilizarse para la configuración OSGi y los paquetes OSGi. Colocar otros tipos de contenido bajo rutas que contengan estos segmentos resulta en un comportamiento de aplicación que varía involuntariamente entre usuarios administrativos y no administrativos.
Un problema común es el uso de nodos denominados config
dentro de los cuadros de diálogo de componentes o al especificar la configuración del editor de texto enriquecido para la edición en línea. Para resolver esto, se debe cambiar el nombre del nodo infractor por un nombre compatible. Para la configuración del editor de texto enriquecido, utilice la propiedad configPath
en el nodo cq:inplaceEditing
para especificar la nueva ubicación.
+ cq:editConfig [cq:EditConfig]
+ cq:inplaceEditing [cq:InplaceEditConfig]
+ config [nt:unstructured]
+ rtePlugins [nt:unstructured]
+ cq:editConfig [cq:EditConfig]
+ cq:inplaceEditing [cq:InplaceEditConfig]
./configPath = inplaceEditingConfig (String)
+ inplaceEditingConfig [nt:unstructured]
+ rtePlugins [nt:unstructured]
Clave: PackageOverlaps
Tipo: Error
Gravedad: Mayor
Desde: Versión 2019.6.0
De manera similar a Los paquetes no deben contener configuraciones OSGi de Duplicado, este es un problema común en los proyectos complejos en los que la misma ruta de nodo está escrita por varios paquetes de contenido independientes. Aunque se pueden utilizar dependencias de paquetes de contenido para garantizar un resultado coherente, es mejor evitar las superposiciones por completo.
Clave: ClassicUIAuthoringMode
Tipo: Compatibilidad entre huele y Cloud Service de código
Gravedad: Menor
Desde: Versión 2020.5.0
La configuración OSGi com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl
define el modo de creación predeterminado dentro de AEM. Como la IU clásica ha quedado obsoleta desde AEM 6.4, ahora se generará un problema cuando el modo de creación predeterminado se configure en la IU clásica.
Clave: ComponentWithOnlyClassicUIDialog
Tipo: Compatibilidad entre huele y Cloud Service de código
Gravedad: Menor
Desde: Versión 2020.5.0
AEM Los componentes que tienen un cuadro de diálogo de IU clásica siempre deben tener un cuadro de diálogo de IU táctil correspondiente para ofrecer una experiencia de creación óptima y para ser compatibles con el modelo de implementación de Cloud Service, en el que la IU clásica no es compatible. Esta regla comprueba los siguientes escenarios:
cq:dialog
).cq:design_dialog
).La documentación de AEM Herramientas de modernización proporciona documentación y herramientas para convertir componentes de la IU clásica a la IU táctil. Consulte Herramientas de modernización de AEM para obtener más detalles.
Clave: ImmutableMutableMixedPackage
Tipo: Compatibilidad entre huele y Cloud Service de código
Gravedad: Menor
Desde: Versión 2020.5.0
Para ser compatibles con el modelo de implementación de Cloud Service, los paquetes de contenido individuales deben contener contenido para las áreas inmutables del repositorio (es decir, /apps and /libs, although /libs
no debe ser modificado por el código del cliente y causará una infracción por separado) o el área mutable (es decir, todo lo demás), pero no ambos. Por ejemplo, un paquete que incluye /apps/myco/components/text and /etc/clientlibs/myco
no es compatible con Cloud Service y provocará que se informe de un problema.
Consulte Estructura del proyecto de AEM para obtener más detalles.
Clave: ReverseReplication
Tipo: Compatibilidad entre huele y Cloud Service de código
Gravedad: Menor
Desde: Versión 2020.5.0
La compatibilidad con la replicación inversa no está disponible en implementaciones de Cloud Service, como se describe en Notas de la versión: Eliminación de agentes de replicación.
Los clientes que utilizan replicación inversa deben ponerse en contacto con Adobe para obtener soluciones alternativas.
Clave: ClientlibProxyResource
Tipo: Error
Gravedad: Menor
Desde: Versión 2021.2.0
AEM bibliotecas cliente pueden contener recursos estáticos como imágenes y fuentes. Como se describe en Uso de preprocesadores, al utilizar bibliotecas de cliente proxy, estos recursos estáticos deben estar contenidos en una carpeta secundaria denominada resources para que se haga referencia a ellos de forma efectiva en las instancias de publicación.
+ apps
+ projectA
+ clientlib
- allowProxy=true
+ images
+ myimage.jpg
+ apps
+ projectA
+ clientlib
- allowProxy=true
+ resources
+ myimage.jpg
Clave: CloudServiceIncompatibleWorkflowProcess
Tipo: Error
Gravedad: Mayor
Desde: Versión 2021.2.0
Con el paso a los microservicios de activos para el procesamiento de recursos en AEM Cloud Service, varios procesos de flujo de trabajo que se utilizaron en las versiones in situ y AMS de AEM han pasado a ser innecesarios o no admitidos. La herramienta de migración de aem-cloud-Migration se puede utilizar para actualizar modelos de flujo de trabajo durante AEM migración de Cloud Service.
Clave: StaticTemplateUsage
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
Aunque el uso de plantillas estáticas ha sido muy común en AEM proyectos, se recomienda encarecidamente utilizar plantillas editables, ya que proporcionan la mayor flexibilidad y admiten funciones adicionales que no están presentes en plantillas estáticas. Puede encontrar más información en Plantillas de página - Editable. La migración de plantillas estáticas a editables se puede automatizar en gran medida mediante las Herramientas de modernización de AEM.
Clave: LegacyFoundationComponentUsage
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
Los componentes de base heredados (es decir, los componentes de /libs/foundation
) han quedado obsoletos en varias versiones de AEM en favor de los componentes principales de WCM. El uso de los componentes de base heredados como base para los componentes personalizados (ya sea por superposición o herencia) se desaconseja y debe convertirse al componente principal correspondiente. Esta conversión se puede facilitar mediante las Herramientas de modernización de AEM.
Clave: SupportedRunmode
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service aplica una política de nomenclatura estricta para los nombres de modo de ejecución y un orden estricto para dichos modos de ejecución. La lista de los modos de ejecución admitidos se puede encontrar en Modos de ejecución y cualquier desviación de esto se identificará como un problema.
Clave: OakIndexLocation
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service requiere que las definiciones de índice de búsqueda personalizadas (es decir, nodos de tipo oak:QueryIndexDefinition) sean nodos secundarios directos de /oak:index
. Los índices de otras ubicaciones se deben mover para que sean compatibles con AEM Cloud Service. Puede encontrar más información sobre los índices de búsqueda en Búsqueda de contenido e indización.
Clave: IndexCompatVersion
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service requiere que las definiciones de índice de búsqueda personalizadas (es decir, los nodos del tipo oak:QueryIndexDefinition) tengan la propiedad compatVersion establecida en 2. AEM Cloud Service no admite ningún otro valor. Puede encontrar más información sobre los índices de búsqueda en Búsqueda de contenido e indización.
Clave: IndexDescendantNodeType
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
Es difícil solucionar problemas cuando se produce cuando un nodo de definición de índice de búsqueda personalizado tiene nodos secundarios sin orden. Para evitarlo, se recomienda que todos los nodos descendientes de un nodo oak:QueryIndexDefinition
sean de tipo nt:unestructure.
Clave: IndexRulesNode
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
Un nodo de definición de índice de búsqueda personalizado correctamente definido debe contener un nodo secundario denominado indexRules que, a su vez, debe tener al menos un nodo secundario. Puede encontrar más información en Documentación de Oak.
Clave: IndexName
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service requiere que las definiciones de índice de búsqueda personalizada (es decir, los nodos de tipo oak:QueryIndexDefinition
) deben nombrarse siguiendo un patrón específico descrito en Búsqueda e indexación de contenido.
Clave: IndexType
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service requiere que las definiciones de índice de búsqueda personalizadas (es decir, los nodos de tipo oak:QueryIndexDefinition) tengan una propiedad type con el valor establecido en lucene. La indexación mediante tipos de índice heredados debe actualizarse antes de la migración a AEM Cloud Service. Consulte Búsqueda e indexación de contenido para obtener más información.
Clave: IndexSeedProperty
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service prohíbe que las definiciones de índice de búsqueda personalizadas (es decir, nodos de tipo oak:QueryIndexDefinition
) contengan una propiedad denominada semilla. La indexación con esta propiedad debe actualizarse antes de la migración a AEM Cloud Service. Consulte Búsqueda e indexación de contenido para obtener más información.
Clave: IndexReindexProperty
Tipo: Huele de código
Gravedad: Menor
Desde: Versión 2021.2.0
AEM Cloud Service prohíbe que las definiciones de índice de búsqueda personalizadas (es decir, nodos de tipo oak:QueryIndexDefinition
) contengan una propiedad denominada reindex. La indexación con esta propiedad debe actualizarse antes de la migración a AEM Cloud Service. Consulte Búsqueda e indexación de contenido para obtener más información.