Résoudre les échecs de déploiement d’AEM Cloud Manager causés par des erreurs de composant OSGi personnalisé

Dernière mise à jour : 1 septembre 2026

Cet article décrit comment dépanner et résoudre les échecs du pipeline de déploiement dans Adobe Experience Manager (AEM) Cloud Manager lorsque les composants OSGi personnalisés ne parviennent pas à s’instancier, ce qui entraîne des environnements instables et des messages de journal peu clairs.

Description description

Environnement

Adobe Experience Manager (AEM) as a Cloud Service, déployé via les pipelines de Cloud Manager

Symptômes

Les pipelines de déploiement échouent et les nouveaux déploiements n’atteignent pas un état stable.
Les instances d’application redémarrent fréquemment et ne sont pas prêtes.
Les contrôles d’intégrité échouent, y compris le contrôle Chemins requis (par exemple : /libs/granite/security/currentuser.json renvoie HTTP 503) et Composants requis (personnalisés) qui signale les composants non satisfaits.
Les journaux affichent les composants OSGi personnalisés qui ne s’instancient pas, avec des erreurs telles que :
- javax.jcr.nodetype.NoTelNodeTypeException : le client de type de nœud n’existe pas
- Constructeur avec 0 argument introuvable pour l’authentification personnalisée ou les composants de l’initialiseur de référentiel

Cause

Les composants OSGi personnalisés ne peuvent pas être instanciés en raison de descripteurs de composants incompatibles, de types de nœuds JCR manquants ou de configurations d’usine incorrectes. Cela entraîne des échecs de service fondamentaux et empêche le déploiement réussi.

Résolution resolution

Suivez les étapes ci-dessous pour résoudre le problème :

Consultez le code des composants OSGi personnalisés, tels que les initialiseurs de référentiel et les lots d’authentification.
Assurez-vous que tous les types de nœuds JCR référencés (par exemple : client) existent avant l’exécution de la logique de création de dossier dans votre code personnalisé.
Vérifiez les descripteurs de composant OSGi pour vous assurer qu’ils correspondent aux signatures de constructeur dans les classes compilées.
Vérifiez que les configurations d’usine des composants d’authentification personnalisés (tels que ProviderConfigImpl, ProviderConfigServiceManagerImpl, OAuthManagerImpl) sont correctes et n’ont pas été nouvellement introduites ou modifiées dans le dernier déploiement.
Validez la configuration du contrôle de l’intégrité :
- Recherchez la configuration OSGi pour le contrôle d’intégrité Composants requis (personnalisés) (généralement une configuration d’usine pour les org.apache.felix.hc.generalchecks.ComponentsCheck, balisés personnalisés).
- Vérifiez que la liste des composants requis inclut les composants personnalisés affectés.
- Utiliser l’interface utilisateur tactile IU tactile d’AEM ( Outils > Opérations > contrôle de l’intégrité) pour consulter le statut et les messages actuels du contrôle de l’intégrité personnalisé.
Après avoir corrigé les problèmes identifiés, redéployez les lots affectés et vérifiez que l’environnement atteint un état prêt stable et que tous les contrôles d’intégrité réussissent.

recommendation-more-help

experience-cloud-kcs-help-kbarticles