Déboguer le SDK d’AEM à l’aide de journaux
- S'applique à :
- Experience Manager as a Cloud Service
- Rubriques :
- Outils pour développeurs
Créé pour :
- Débutant
- Intermédiaire
- Développeur
Les journaux du SDK AEM, qu’il s’agisse des fichiers Jar de démarrage rapide locaux du SDK AEM ou des outils du Dispatcher, peuvent fournir des informations clés sur le débogage des applications AEM.
Journaux AEM
Les journaux sont en première ligne pour le débogage des applications AEM, mais dépendent d’une journalisation adéquate dans l’application AEM déployée. Adobe recommande, dans la mesure du possible, de ne pas modifier la configuration de la journalisation pour l’environnement de développement local et l’environnement de développement AEM as a Cloud Service, car cela permet de normaliser la visibilité de la journalisation dans les environnements locaux de démarrage rapide du SDK AEM et de développement AEM as a Cloud Service, ce qui réduit le temps de configuration et de redéploiement.
L’archétype de projet AEM permet de configurer la journalisation au niveau DEBUG pour les packages Java de votre application AEM pour le développement local via la configuration OSGi des journaux Sling, qui se trouve à l’emplacement suivant :
ui.apps/src/main/content/jcr_root/apps/example/config/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json
Elle consigne les informations dans le fichier error.log.
Si la journalisation par défaut n’est pas suffisante pour le développement local, la journalisation ad hoc peut être configurée via la console web de prise en charge des journaux du démarrage rapide local du SDK AEM, à l’emplacement (/system/console/slinglog). Il n’est toutefois pas recommandé que les modifications apportées soient conservées dans Git, sauf si ces mêmes configurations de journal sont également nécessaires dans les environnements de développement AEM as a Cloud Service. Gardez à l’esprit que les modifications effectuées via la console de prise en charge de la journalisation sont conservées directement dans le référentiel de démarrage rapide local du SDK AEM.
Les instructions du journal Java peuvent être visualisées dans le fichier error.log :
$ ~/aem-sdk/author/crx-quickstart/logs/error.log
Souvent, il est utile d’analyser le error.log qui diffuse sa sortie vers le terminal.
- macOS/Linux
$ tail -f ~/aem-sdk/author/crx-quickstart/logs/error.log
- Windows nécessite des applications d’analyse tierces ou l’utilisation d’une commande Get-Content de PowerShell.
Journaux de Dispatcher
Les journaux de Dispatcher sont envoyés vers stdout lorsque bin/docker_run est appelé, mais les journaux peuvent être directement accessibles dans le conteneur Docker.
Accéder aux journaux dans le conteneur Docker
Il est possible d’accéder directement aux journaux de Dispatcher dans le conteneur Docker à l’emplacement /etc/httpd/logs.
$ docker ps
# locate the CONTAINER ID associated with "adobe/aem-ethos/dispatcher-publisher" IMAGE
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
46127c9d7081 adobe/aem-ethos/dispatcher-publish:2.0.23 "/docker_entrypoint.…" 6 seconds ago Up 5 seconds 0.0.0.0:8080->80/tcp wonderful_merkle
$ docker exec -it <CONTAINER ID> /bin/sh
/ #
/ # cd /etc/httpd/logs
/ # ls
dispatcher.log healthcheck_access_log httpd_access.log httpd_error.log
# When finished viewing the logs files, exit the Docker container's shell
/# exit
L’<CONTAINER ID> dans docker exec -it <CONTAINER ID> /bin/sh doit être remplacé par l’ID de conteneur Docker cible répertorié dans la commande docker ps.
Copier les journaux Docker vers le système de fichiers local
Les journaux de Dispatcher peuvent être copiés du conteneur Docker à l’emplacement /etc/httpd/logs vers le système de fichiers local pour inspection à l’aide de votre outil d’analyse de journal préféré. Notez qu’il s’agit d’une copie ponctuelle qui ne fournit pas de mises à jour en temps réel des journaux.
$ docker ps
# locate the CONTAINER ID associated with "adobe/aem-ethos/dispatcher-publisher" IMAGE
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
46127c9d7081 adobe/aem-ethos/dispatcher-publish:2.0.23 "/docker_entrypoint.…" 6 seconds ago Up 5 seconds 0.0.0.0:8080->80/tcp wonderful_merkle
$ docker cp -L <CONTAINER ID>:/etc/httpd/logs logs
$ cd logs
$ ls
dispatcher.log healthcheck_access_log httpd_access.log httpd_error.log
L’<CONTAINER_ID> dans docker cp <CONTAINER_ID>:/var/log/apache2 ./ doit être remplacé par l’ID de conteneur Docker cible répertorié dans la commande docker ps.
Experience Manager
- Vue d’ensemble
- Listes de lecture
- Présentation d’AEM as a Cloud Service
- Experience Hub
- Assistant IA AEM
- Intégrations Experience Cloud
- Technologie sous-jacente
- Edge Delivery Services
- Cloud Manager
- Configuration de l’environnement de développement local
- Développement
- Extensibilité
- Principes de base de développement
- Projets AEM
- Services OSGi
- Avancé
- Environnement de développement rapide
- Éditeur universel
- Documentation JavaDocs de l’API SDK AEM
- Déboguer AEM
- Personnalisation
- API d’AEM
- Diffusion de contenu
- Mise en cache
- Accès à AEM
- Authentification
- Mise en réseau avancée
- Sécurité
- AEM Eventing
- Migration
- Outil de transfert de contenu
- Importation en bloc de ressources
- Transition vers AEM as a Cloud Service
- Cloud Acceleration Manager
- Présentation
- Préparation et Best Practice Analyzer
- Phase dʼimplémentation
- Outils de refactorisation du code
- Modernisateur du référentiel de code
- Convertisseur du Dispatcher
- Index Converter
- Outil de migration des workflows de ressources
- Naviguer dans Cloud Acceleration Manager
- Utiliser Cloud Acceleration Manager
- Fragments de contenu
- Formulaires
- Développer pour Forms as a Cloud Service
- 1 - Prise en main
- 2 - Installer IntelliJ
- 3 - Configurer Git
- 4 - Synchroniser IntelliJ avec AEM
- 5 - Créer un formulaire
- 6 - Gestionnaire d’envoi personnalisé
- 7 – Enregistrer le servlet à l’aide du type de ressource
- 8 – Activer les composants du portail Formulaires
- 9 – Inclure Cloud Services et FDM
- 10 – Configuration cloud basée sur le contexte
- 11 – Transmettre à Cloud Manager
- 12 – Déployer sur l’environnement de développement
- 13 – Mettre à jour l’archétype Maven
- Créer un formulaire adaptatif
- Service d’envoi personnalisé avec formulaire découplé
- Créer un composant de bloc d’adresse
- Créer un composant d’image cliquable
- AEM Forms et Analytics
- Création d’un composant déroulant Pays
- Création de variations de bouton
- Utilisation des onglets verticaux
- Utilisation des services Output et Forms
- Génération de documents dans AEM Forms CS
- Utilisation de l’API Forms Document Services
- Génération de documents à l’aide de l’API par lot
- Manipulation de PDF dans Forms CS
- Stocker les envois de formulaire avec des balises d’index Blob
- Préremplir un formulaire basé sur des composants principaux
- Stockage de portail Azure
- Enregistrer et reprendre le remplissage du formulaire
- Créer un workflow d’analyse
- Acrobat Sign avec AEM Forms
- Intégrer à Microsoft Power Automate
- Intégrer à Microsoft Dynamics
- Intégrer à Salesforce
- Stocker les envois de formulaire sur un lecteur et dans SharePoint
- Développer pour Forms as a Cloud Service
- Extensibilité Assets Compute
- Tutoriels en plusieurs étapes
- Ressources expertes