Le package de contenu donne une erreur lors du déploiement.

Vous devez disposer des droits d’administrateur pour déployer un package. Si vous rencontrez des erreurs, consultez le fichier journal Adobe Experience Manager. Certaines raisons pour lesquelles une erreur se produit lors du déploiement du package s’il existe des dépendances qui ne figurent pas sur Adobe Experience Manager. Une autre raison consiste à installer une version antérieure d’un package installé. 

Veuillez lire la rubrique suivante Adobe Experience Manager: Comment travailler avec des packages.

Pour savoir comment créer un package contenant des packs OSGi, voir applications Packaging Adobe CQ contenant un pack OSGi

Pourquoi le redémarrage du serveur donne une erreur

Si le serveur Adobe Experience Manager ne démarre pas, la première étape consiste à vérifier le journal du serveur. Vérifiez le dossier error.log, stderr.log, stdout.log (tous les fichiers journaux se trouvent dans le dossier CQX.X/crx-quickstart/logs). Un problème pourrait être causé au fait que le système manque de mémoire.

D'autres raisons sont comme suit:

  • Paramètres JVM non valides (vous ne voyez rien dans le error.log)
  • Système non accessible par le navigateur (le port est toujours réclamé par une occurrence en cours d’exécution ou par une JVM hors justification qui n’a pas été arrêtée correctement)
  • Classique : soutien d'authentification manquant dans le navigateur, qu'un référentiel de départ (erreur.log) cause.

Consultez cet article pour plus d'informations de déblocage CQ WCM de dépannage.

Avant d’installer Adobe Experience Manager, veuillez respecter les conditions techniques requises. Voir les exigences techniques.

Felix Console ne se charge pas

Si vous ne parvenez pas à accéder à la console Felix et rencontrer une erreur «org.apache.sling.servlets.resolver.internal.SlingServletResolver Original error null, » effectuez les actions suivantes:

  1. cd /crx-quickstart/launchpad/felix
  2. grep -H "org.apache.felix.webconsole" . -R
  3. Recherchez org.apache.felix.webconsole-.jar
  4. Accédez à ce pack « cd ».
  5. Assurez-vous que le fichier bundle.location contient slinginstall:org.apache.felix.webconsole-.jar.
  6. Ouvrez le fichier bundle.state et attribuez-lui le statut « actif » dès qu'il est « installé » .
  7. Redémarrez votre système.

Remarque :

Au lieu d’utiliser launchpad, vous pouvez utiliser gogo. Pour plus de détails, veuillez consulter :

https://helpx.adobe.com/fr/experience-manager/kb/cq-5-5--rien-ne-va-plus---i-need-a-text-shell.html

Le gestionnaire de packages ne se charge pas.

Si le gestionnaire de packages d'Adobe Experience ne se charge pas (par exemple, si vous rencontrez une erreur 404 lors de la tentative de l'ouvrir), la première étape consiste à vérifier le journal. Assurez-vous que les nœuds JCR requis sont corrects. Si ces nœuds ne sont pas présents, une erreur s’affiche dans le fichier journal. Par exemple :

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

Consultez cet article de la communauté pour plus d'informations: AEM Gotchya: Aucun package dans le gestionnaire de packages..

Vérifiez l’URL qui s’affiche lorsque vous survolez le lien des packages à l’écran de bienvenue. Affiche-t-il http://localhost:4502/crx/packmgr/ http://localhost:4502/crx/packmgr.html? Si le fichier .html est affiché sur le lien, il est possible que vous ayez une règle configurée etc/map qui pourrait être à l'origine de ce comportement.

Enfin, vérifiez les autorisations dans "/libs/cq/core/content/welcome/features/packages". Assurez-vous qu’il possède tous les niveaux d’autorisation requis pour l’utilisateur Adobe Experience afin d’accéder au Gestionnaire de packages. Un compte non-admin requiert les autorisations nécessaires pour installer un package.

Le composant personnalisé ne fonctionne pas comme prévu

Un composant personnalisé créé par un développeur Adobe Experience Manager peut être constitué de la logique JavaScript et de la logique Java en arrière-plan, généralement assemblée dans un regroupement OSGi. Lors du développement d’un composant personnalisé, il est recommandé de déboguer le composant pour vous assurer qu’il fonctionne comme prévu. Pour déboguer le composant, définissez un point d’arrêt et une étape dans la logique de l’application. 

La méthode de débogage dépend de la manière dont vous la construisez. Voir les liens suivants:

Déboguez une application CQ5/AEM 6 à l'aide d'éclipse

Adobe experience CQ 6 - Débogage AEM JSP avec IntelliJ IDEA 12

Problèmes de flexibilité AEM

Cette section traite des problèmes de flexibilité AEM. 

Pourquoi les instances ne répondent-elles pas aux requêtes et sont-elles coincées ?

Utilisez http://localhost:4502/system/console/profiler pendant au moins quelques minutes au cours de la période de la lenteur ou utilisation de l'unité centrale élevée. La sortie vous aide à déterminer quelles tâches JVM consomment le plus de cycles de CPU, ainsi que leurs contenus et classes associées.

Il y a deux étapes qui peuvent être suivies:

  • Vérifier l’utilisation du processeur
  • Vérifier le nombre de sessions
  • Ne pas supprimer les processus

Pour plus d'informations, rendez-vous à la section Analyse des processus lents et bloqués.

Pourquoi l'exécution de l'instance d'auteur est-elle très lente?

Les facteurs suivants influencent les problèmes de performances dans AEM:

  • Conception inadéquate
  • Code d’application
  • Configuration incorrecte du disque I/O
  • Bande passante réseau et temps de latence
  • AEM installé sur certaines fenêtres sélectionnées des versions 2008 et 2012, où la gestion de la mémoire est un problème

Pour plus d'informations, voir Conseils sur optimisation de performance | 6.x.
 

Comment vérifier la lenteur des décharges de fil pour les performances lentes?

Il existe plusieurs façons de générer des décharges de fils d’une JVM. Il est vivement recommandé de générer plusieurs décharges de fils. Il est conseillé de prendre 10 décharges de fil à intervalles réguliers (par exemple. 1 décharge de fil toutes les 10 secondes).

Pour plus d'informations, voir Comment prendre des décharges de fil d'un JVM.

Pourquoi l’instance est-elle mise hors de l’espace du tas ?

Ces problèmes peuvent avoir de nombreuses causes.

Une cause possible est que l’application Java, dans notre cas, CRX / CQ a démarré à partir de la ligne de commande avec les paramètres de mémoire de Java par défaut. Cela signifie que le paramètre jvm -Xmx n’a pas été spécifié. Le CRX ou CQ nécessite au moins 256 Mo de tas allouée pour fonctionner. Si tel est le cas, commencez à partir de la ligne de commande et assurez vous que les paramètres de mémoire du tas sont définis.

Pour plus d'informations, se rendre à la section Analyse des problèmes de mémoire

Comment exécuter le profileur CRX et est-il nécessaire de l’exécuter au cours de la lenteur?

Utilisez prof.jsp
Un simple outil de profilage CPU est inclus dans CRX 2.x. Pour démarrer (CRX 2.0 - 2.2), ouvrez:

http://localhost:7402/crx/diagnostic/prof.jsp
depuis CRX 2.3 / CQ 5,5 l'outil est disponible ici :

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

et

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

Pour plus d'informations, voir Analyse de performance à l'aide du profileur intégré.

Pourquoi est-ce que je reçois l'erreur : fichier non valide pendant le téléchargement des fichiers ZIP

Si votre cas d’utilisation nécessite un fichier ZIP, AEM prend en charge cette opération. En d’autres termes, vous pouvez télécharger des fichiers ZIP vers AEM DAM à l’aide de l’interface utilisateur des actifs. Une fois le fichier ZIP téléchargé, vous pouvez l’afficher, comme démontré dans l’illustration suivante. 

 

zipic

Si vous rencontrez une erreur, assurez-vous que vous téléchargez le ZIP à l'aide de l'interface utilisateur des actifs AEM à l'adresse suivante : http://localhost:4502/damadmin#/content/dam.

Une autre option que vous avez consiste à écrire un composant vous permet de télécharger des fichiers dans AEM DAM. Voir le site https://helpx.adobe.com/fr/experience-manager/using/uploading-files-aem1.html. 

Pourquoi le package hotfix est en train d'échouer/ erreur lors de l'installation du package hotfix? (Échec de Hotfix)

Si vous avez des problèmes d'installation pour le hotfix AEM, référez-vous à l'article AEM KB suivant : Hotfixes Adobe Experience Manager 6,0. Si vous rencontrez toujours des problèmes, veuillez ouvrir un ticket d'assistance ici : https://helpx.adobe.com/fr/marketing-cloud/experience-manager.html.

 

Pourquoi il n'existe aucun nœud de contenu après l'installation du package ?

Une fois que vous avez installé un package AEM et s'il n'y a pas de contenu sous /content, cela signifie que le package n'a pas été créé correctement. En règle générale, lorsque vous créez un package, sélectionnez les nœuds JCR sous /content qui fait partie du package. Consultez l’équipe qui a créé le package. Pour plus d'informations sur la façon de créer un package AEM, voir Applications de Packaging Adobe Experience Manager 6

Problèmes administratifs dans AEM

Cette section décrit les problèmes administratifs suivants dans AEM.

Pourquoi suis-je incapable d'ouvrir une session /authentifier l'auteur principal ou l'auteur secondaire dans un environnement des amas?

Les points suivants peuvent être utiles pour ne pas pouvoir se connecter :

  1. Vérifiez si l’occurrence est hors synchronisation.
  2. Si vous ne synchronisez pas, veuillez suivre le dépannage de la synchronisation.
  3. Assurez-vous que le nom d’utilisateur et le mot de passe sont corrects.
  4. Assurez-vous que le serveur LDAP répond et fonctionne correctement.
  5. Vérifier les journaux pour toutes les entrées.

Pourquoi il y a une erreur appelé « Impossible de résoudre le chemin du contenu » ?

Essayez d'installer le package OSGi http://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.jcr.jackrabbit.accessmanager/2.1.0 dans une instance CQ et voir si le problème est résolu.

Pourquoi le statut d'acheminement n’est-il pas actualisé/modifié dans Felix Console ?

La mise à jour d’un pack ne provoque pas nécessairement l’utilisation des nouvelles classes, elle dépend de deux facteurs :

  1. Si les classes proviennent d’un package privé ou d’un package exporté.
    Si les classes sont dans un package exporté, si elles ne sont pas utilisées par un autre pack.
    A propos (1) si les classes proviennent d'un package privé (en d'autres termes, il n'est pas exporté), alors les nouvelles classes deviendront disponibles immédiatement. Toutefois, si elles proviennent d’un package exporté, leur visibilité varie selon que d’autres packs utilisent les packages exportés.
  2. Si aucun autre pack n’utilise les packages exportés, les nouvelles classes deviendront disponibles immédiatement puisque l’ancienne version des classes n’est plus nécessaire. D’autre part, si d’autres packs utilisent les packages exportés, les nouvelles classes ne seront pas disponibles immédiatement puisque l’ancienne version est encore requise par les packs dépendants. Dans ce cas, les nouvelles classes ne seront pas rendues accessibles jusqu’à ce que la méthode PackageAdmin.refreshPackages() soit appelée (ceci peut être appelée dans le shell Felix à l’aide de la commande Actualiser).

Il existe une exception partielle à ce dernier cas. Il se produit lorsque le pack d’exportation n’importe pas ses propres packages exportés (voir « Un pack devrait-il importer ses propres packages exportés ? » Ci-dessous pour plus d’informations sur ce commonique. Dans ce cas, les nouvelles classes deviennent immédiatement accessibles au lot d’exportation mis à jour, mais pas aux lots dépendants. Les packs dépendants continuent à voir l’ancienne version des classes. Cette situation nécessite généralement la méthode PackageAdmin.refreshPackages() pour faire revenir les packs à un état utile.

Il s’agit du processus normal de mise à jour tel que défini par la spécification OSGi. La mise à jour d’un pack est un processus en deux étapes, où les anciennes versions des packages exportés sont conservées jusqu’à ce qu’elles soient explicitement actualisées. Cela permet de réduire l’interruption lors de plusieurs mises à jour.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne