Problemas comunes de los productos

Se necesitan derechos de administrador para implementar un paquete. Si encuentra errores, consulte el archivo de registro de Adobe Experience Manager. Algunas de las razones por las que se produce un error durante la implementación de un paquete son que existen dependencias que no están en Adobe Experience Manager. Otra razón es que puede estar intentando instalar una versión anterior de un paquete instalado. 

Asegúrese de leer el siguiente tema de Adobe Experience Manager: Cómo trabajar con los paquetes.

Para obtener más información sobre cómo crear un paquete que contenga paquetes OSGi, consulte Empaquetado de aplicaciones Adobe CQ que contengan un paquete OSGi.

Si el servidor de Adobe Experience Manager no se está iniciando, el primer paso es comprobar el registro del servidor. Compruebe los archivos error.log, stderr.log, stdout.log (todos los archivos de registro se encuentran en la carpeta CQX.X/crx-quickstart/logs). Un problema podría ser que el sistema tiene poca memoria.

Otras razones son las siguientes:

• Parámetros de JVM no válidos (entonces no verá nada en el archivo error.log)
• Sistema no accesible por el navegador (el puerto sigue siendo reclamado por una instancia en ejecución o por una JVM pausada que no se ha apagado correctamente)
• El clásico: "falta el soporte de autenticación" en el navegador, que provoca un repositorio que no arranca (error.log).
  

Consulte este artículo para obtener más información sobre la solución de problemas Solución de problemas de CQ WCM.

Antes de instalar Adobe Experience Manager, asegúrese de que cumple los requisitos técnicos. Ver Requerimientos técnicos.

Si no puede acceder a la consola felix y encuentra el error org.apache.sling.servlets.resolver.internal.SlingServletResolver Error original nulo, siga estos pasos:

1. cd /crx-quickstart/launchpad/felix
2. grep -H "org.apache.felix.webconsole" . -R
3. Busque org.apache.felix.webconsole-.jar
4. Vaya a ese paquete "cd."
5. Compruebe el archivo bundle.location que debe contener slinginstall:org.apache.felix.webconsole-.jar
6. Abra el archivo bundle.state y cambie el estado a Activo desde Instalado.
7. Reinicie el equipo.

Si Adobe Experience Package Manager no se carga (por ejemplo, si encuentra un error 404 mientras intenta abrirlo), el primer paso es comprobar el registro. Asegúrese de que los nodos JCR requeridos sean correctos. Si estos nodos no están presentes, aparece un error en el archivo de registro. Por ejemplo:

log: 27.06.2014 13:16:53.845 *ERROR* [127.0.0.1 [1402543013788] GET /crx/packmgr/list.jsp?_dc=1402543013769&_charset_=utf-8&includeVersions=true HTTP/1.1] com.day.crx.packmgr.impl.servlets.ListServlet Error while retrieving infos: javax.jcr.RepositoryException: Invalid path:/etc/packages/my_packages/.snapshot/My Packagename

Ver este artículo de la comunidad para más información: AEM Gotchya: No hay paquetes en el Administrador de paquetes.

Compruebe la URL que ve al pasar el puntero del ratón sobre el enlace de paquetes en la pantalla de bienvenida. ¿Muestra http://localhost:4502/crx/packmgr/ o http://localhost:4502/crx/packmgr.html? Si se muestra .html en el enlace, podría tener una regla configurada bajo etc/map que podría estar causando este comportamiento.

Finalmente, compruebe los permisos en "/libs/cq/core/content/welcome/features/packages." Asegúrese de que dispone de todos los niveles de permiso necesarios para que el usuario de Adobe Experience pueda acceder al Administrador de paquetes. Una cuenta no admin necesita los permisos necesarios para instalar un paquete.

Un componente personalizado creado por un desarrollador de Adobe Experience Manager puede consistir en lógica JavaScript de interfaz y lógica Java back-end, normalmente empaquetadas dentro de un paquete OSGi. Al desarrollar un componente personalizado, es una práctica recomendada depurar el componente para asegurarse de que funciona como se espera. Para depurar el componente, establezca un punto de interrupción y siga la lógica de la aplicación. 

La forma de depurar depende de cómo la construya. Consulte el siguiente ejemplo:

Depurar una aplicación CQ5/AEM 6 usando eclipse

Adobe Experience CQ6: depuración de los JSP de AEM con IntelliJ IDEA 12

Esta sección discute los problemas de escalabilidad de AEM. 

Utilice http://localhost:4502/system/console/profiler durante al menos unos minutos durante el período de lentitud o alto uso de la CPU. El resultado le ayuda a determinar qué subprocesos de JVM están consumiendo la mayoría de los ciclos de CPU, y sus paquetes y clases asociadas.

Hay un par de pasos que se pueden seguir:

• comprobación del uso de la CPU
• verificar el número de sesiones
• no eliminar los procesos

Para obtener más información, consulte Analizar procesos lentos y bloqueados.

Los siguientes factores influyen en los problemas de rendimiento en AEM:

• Diseño inapropiado
• Código de aplicación
• Configuración de entrada/salida de disco defectuoso
• Ancho de banda y latencia de la red
• AEM instalado en algunas versiones selectas de Windows 2008 y 2012 donde la gestión de la memoria es un problema

Para obtener más información, consulte Consejos de ajuste del rendimiento | 6.x.

Hay varias maneras de tomar volcados de subprocesos de JVM. Se recomienda tomar más de 1 descarga de subprocesos. Una práctica recomendada es tomar 10 volcados de subprocesos en un intervalo regular (por ej. 1 descarga de subprocesos cada 10 segundos).

Para obtener más información, consulte Adopción de volcados de subprocesos desde JVM.

Estos problemas pueden tener muchas causas.

Una posible causa es que la aplicación de Java, en nuestro caso, CRX/CQ se inicie desde la línea de comandos con la configuración predeterminada de memoria acumulada de Java. Esto significa que el parámetro jvm -Xmx no fue especificado. CRX o CQ necesitan al menos 256 MB de memoria asignada para funcionar. Si este es el problema, empezando por la línea de comandos, asegúrese de que la configuración de la memoria de pila esté establecida.

Para obtener más información, consulte Analizar problemas de memoria.

Usando prof.jsp
Una simple herramienta de perfilado de CPU está incluida en CRX 2.x. Para iniciarla (CRX 2.0 - 2.2), abra:

http://localhost:7402/crx/diagnostic/prof.jsp
A partir de CRX 2.3/CQ5.5, la herramienta se encuentra aquí:

http://localhost:4502/crx/explorer/diagnostic/prof.jsp

y

http://localhost:4502/system/console/profiler

Para obtener más información, consulte Análisis de rendimiento con el generador de perfiles integrado.

Si tu caso de uso requiere que subas un archivo ZIP, AEM lo soporta. Es decir, puede cargar archivos ZIP a DAM de AEM utilizando la interfaz de usuario de AEM Assets. Una vez cargado el archivo ZIP, puede verlo, como se muestra en la siguiente ilustración. 

Si encuentra un error, asegúrese de que está cargando el ZIP utilizando la interfaz de usuario de AEM Assets en: http://localhost:4502/damadmin#/content/dam.

Otra opción que tiene es escribir un componente que le permita subir archivos a DAM de AEM. Vea https://helpx.adobe.com/es/experience-manager/using/uploading-files-aem1.html. 

Si tiene problemas para instalar correcciones de AEM, consulte el siguiente artículo de AEM KB: Correcciones de Adobe Experience Manager 6.0. Si sigue teniendo problemas, abra un ticket de soporte aquí: https://helpx.adobe.com/es/marketing-cloud/experience-manager.html.

Después de instalar un paquete AEM, si no hay contenido en /content, esto significa que el paquete no fue construido correctamente. Típicamente cuando se construye un paquete, se seleccionan los nodos JCR de /content que forma parte del paquete. Consulte al equipo que construyó el paquete. Para obtener información sobre cómo crear un paquete de AEM, consulte Empaquetado de aplicaciones de Adobe Experience Manager 6.

Esta sección trata los siguientes problemas administrativos en AEM.

Los siguientes puntos pueden ser razones para no poder iniciar sesión:

1. Compruebe si la instancia está fuera de sincronización.
2. Si no está sincronizado, siga las instrucciones para la resolución de problemas.
3. Asegúrese de que el nombre de usuario y la contraseña sean correctos.
4. Asegúrese de que el servidor LDAP está respondiendo y funcionando correctamente.
5. Compruebe los registros de cualquier entrada.

Intente instalar el paquete OSGI http://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.jcr.jackrabbit.accessmanager/2.1.0 en la instancia CQ y vea si ayuda.

La actualización de una concatenación no necesariamente hace que las nuevas clases se utilicen inmediatamente, sino que depende de dos factores:

1. Si las clases son de un paquete privado o de un paquete exportado.
   Si las clases proceden de un paquete exportado, independientemente de si están siendo utilizadas o no por otro paquete.
   En cuanto a (1), si las clases provienen de un paquete privado (es decir, no se exporta), entonces las nuevas clases estarán disponibles inmediatamente. Sin embargo, si proceden de un paquete exportado, su visibilidad depende de si otros paquetes están utilizando los paquetes exportados.
2. Si no hay otros paquetes que utilicen los paquetes exportados, las nuevas clases estarán disponibles inmediatamente, ya que la versión antigua de las clases ya no es necesaria. Por otro lado, si otros paquetes están utilizando los paquetes exportados, las nuevas clases no estarán disponibles inmediatamente, ya que la versión antigua sigue siendo necesaria para cualquier paquete dependiente. En este caso, las nuevas clases no estarán disponibles hasta que se llame a PackageAdmin.refreshPackages() (esto puede ser invocado en el comando de Felix usando el comando actualizar).

Hay una excepción parcial a este último caso, que se produce cuando el paquete de exportación no importa también sus propios paquetes exportados (vea ¿Debe un paquete importar sus propios paquetes exportados? abajo para más información. En este caso, las nuevas clases pasan a ser inmediatamente accesibles para el paquete de exportación actualizado, pero no para los paquetes dependientes; los paquetes dependientes siguen viendo la versión antigua de las clases. Esta situación generalmente requiere que se invoque PackageAdmin.refreshPackages() para que los paquetes vuelvan a un estado útil.

Este es el proceso de actualización normal definido por la especificación OSGi. La actualización de un paquete es un proceso de dos pasos, en el que las versiones más antiguas de los paquetes exportados se mantienen hasta que se actualizan explícitamente. Esto se hace para reducir las interrupciones al realizar varias actualizaciones.