Définition d’une configuration basée sur le référentiel pour une instance spécifique uniquement
Cet article décrit une configuration basée sur le référentiel pour une instance spécifique, expliquant comment stocker la configuration dans le référentiel CRX sous la forme de noeuds sling:OsgiConfig dans Adobe Experience Manager.
Description description
Environnement
Adobe Experience Manager
Problème/Symptômes
Cet article définit une configuration basée sur le référentiel pour une instance spécifique.
Résolution resolution
1. Configuration de la console de gestion web Apache Felix
La configuration sur la console de gestion web Apache Felix (http://< host> :< port> /system/console/configMgr) est toujours spécifique à l’instance actuelle.
Vous trouverez une description dans la documentation : https://helpx.adobe.com/fr/experience-manager/6-4/sites/deploying/using/configuring-osgi.html#OSGiConfigurationintheRepository
2. Configuration basée sur le référentiel
Il est également possible de stocker la configuration dans le référentiel CRX en tant que noeuds de type de noeud sling:OsgiConfig.
Pour plus d’informations, voir https://helpx.adobe.com/fr/experience-manager/6-4/sites/deploying/using/configuring-osgi.html#OSGiConfigurationintheRepository
Avec cette méthode, il est possible de partager la configuration entre plusieurs instances.
Le nom de ces noeuds doit être égal à l’identité permanente (PID) de la configuration (par exemple, le nom du service). Si vous observez http://< host> :< port> /system/console/configMgr, ces noms sont répertoriés en tant que propriétés service.pid. Ces noeuds de configuration doivent être des noeuds enfant de type de noeud nt:folder avec un nom commençant par config suivi d’un point. Tous les modes d’exécution auxquels s’applique la configuration sont également séparés par un point.
Exemples : config.author, config.publish, config.author.dev, config.author.foo.dev
Run-Mode
Il est possible de définir les modes d’exécution spécifiques sur lesquels s’exécute une instance spécifique. Par défaut, une instance d’auteur s’exécute sur le mode d’exécution author et une instance de publication s’exécute sur le mode d’exécution publish. Il est possible de définir plusieurs modes d’exécution pour une instance (par exemple, author, foo et dev).
Définissez ces modes d’exécution comme options de VM.
Par exemple, sur la console :
java -Dsling.run.modes=author,foo,dev -Xmx256m -jar aem64-quickstart.jar
ou dans le script de démarrage :
# default JVM options
CQ_JVM_OPTS='-Dsling.run.modes=author,foo,dev'
Les modes d’exécution actuels d’une instance sont visibles à l’adresse http://< host> :< port> /system/console/status-slingsettings
Remarque : Il n’est pas recommandé de modifier ou de supprimer l’auteur et la publication des modes d’exécution par défaut. Au lieu de cela, ajoutez simplement vos modes d’exécution spécifiques à la liste par défaut des modes d’exécution existants.
Remarque : Le même mécanisme fonctionne pour l’installation de lots basée sur le référentiel. Placez les lots sous les noeuds du type de noeud nt:folder avec un nom commençant par install suivi d’un point. Tous les modes d’exécution auxquels s’appliquent les lots sont séparés par un point.
Exemple : Pour disposer d’une configuration de serveur de messagerie SMTP spécifique pour toutes vos instances s’exécutant sur le mode d’exécution foo, créez simplement un noeud avec le nom config.foo et le type de noeud nt:folder dans /apps/we-retail, copiez le noeud /libs/cq/config/com.day.cq.mailer.DefaultMailService vers /apps/we-retail/config.foo et adaptez les propriétés smtp.host.
Exemple : Pour avoir une configuration de Logrotation spécifique, utilisez le package de configuration dans l’article de la base de connaissances Comment faire pivoter request.log et access.log et renommez la configuration de noeud par exemple config.foo si la configuration doit être utilisée pour toutes vos instances s’exécutant uniquement en mode d’exécution foo.