Configurer OSGi

Le framework OSGi est un élément fondamental de la pile technologique d’Adobe Experience Manager (AEM). Il est utilisé pour contrôler les lots composites d’AEM et leur configuration.

OSGi "fournit les primitives normalisées qui permettent de construire des applications à partir de petits composants réutilisables et collaboratifs. Ces composants peuvent être créés dans une application et déployés ».

Cela permet une gestion conviviale des lots car ils peuvent être arrêtés, installés et démarrés individuellement. Les interdépendances sont gérées automatiquement. Chaque composant OSGi (consultez Spécification OSGi) est contenu dans l’un des différents lots.

Vous pouvez gérer les paramètres de configuration de ces lots en effectuant l’une des opérations suivantes :

• en utilisant la variable Console web Adobe CQ
• using fichiers de configuration
• configurant les content-nodes (sling:OsgiConfig) dans le référentiel.

L’une ou l’autre des méthodes peut être utilisée bien qu’il existe des différences subtiles, principalement en relation avec les modes d’exécution :

• Console Web Adobe CQ

  • La console web est l’interface standard pour la configuration OSGi. Il fournit une interface utilisateur pour la modification des différentes propriétés, dans laquelle les valeurs possibles peuvent être sélectionnées à partir de listes prédéfinies.

    De ce fait, il s’agit de la méthode la plus simple à utiliser.

  • Toutes les configurations effectuées avec la console Web sont appliquées immédiatement et s’appliquent à l’instance en cours, quel que soit le mode d’exécution en cours ou toute modification ultérieure du mode d’exécution.

• fichiers de configuration

  • Contient les paramètres définis dans la console web.
  • Peuvent être incluses dans des modules de contenu pour une utilisation sur d’autres instances.

• content-nodes (sling:osgiConfig) du référentiel

  • Nécessite une configuration manuelle à l’aide de CRXDE Lite.
  • En raison des conventions de nommage des nœuds sling:OsgiConfig, vous pouvez lier la configuration à un mode d’exécution spécifique. Vous pouvez même enregistrer des configurations pour plusieurs modes d’exécution dans le même référentiel.
  • Toutes les configurations appropriées sont appliquées immédiatement (selon le mode d’exécution).

Quelle que soit la méthode utilisée, toutes ces méthodes de configuration :

• Assurez-vous que la copie ou la réplication du contenu du référentiel recrée des configurations identiques.
• Permet d’extraire des configurations vers FileVault ou Subversion ; soit pour des raisons de sécurité, soit pour d’autres mises à jour.
• Peuvent être enregistrées dans des packages à utiliser lors de la configuration d’autres instances.
• Permet d’effectuer des déploiements de configuration à l’aide de scripts pour propager les détails de configuration.

Configuration OSGi à l’aide de la console web

Le Console web dans AEM fournit une interface normalisée pour la configuration des lots. Le Configuration est utilisé pour configurer les lots OSGi. Il s’agit donc du mécanisme sous-jacent pour configurer les paramètres système d’AEM.

Toutes les modifications apportées sont immédiatement appliquées à la configuration OSGi appropriée. Aucun redémarrage n’est nécessaire.

Pour mettre à jour une configuration avec la console web :

1. Accédez au Configuration de la console web en effectuant l’une des opérations suivantes :

   • Ouvrant la console web à partir du lien du menu Outil -> Opérations. Après vous être connecté à la console, vous pouvez utiliser le menu déroulant :

     OSGi >

   • L’URL directe ; par exemple :

     http://localhost:4502/system/console/configMgr
     Une liste s’affiche.

2. Sélectionnez le lot que vous souhaitez configurer en :

   • cliquant sur l’icône Modifier correspondant à ce lot ;
   • Cliquez sur le bouton Nom du lot

3. Une boîte de dialogue s’ouvre. Dans cette dernière, vous pouvez apporter les modifications appropriées, par exemple, définir le Niveau de journal sur INFO :

   

   REMARQUE

   Les mises à jour sont enregistrées dans le référentiel sous la forme de fichiers de configuration. Pour les localiser par la suite (par exemple, pour les inclure dans un package de contenu pour une utilisation dans une autre instance), vous devez prendre note de l’identité persistante (PID).

4. Cliquez sur Enregistrer.

   Les modifications sont immédiatement appliquées à la configuration OSGi correspondante du système en cours d’exécution. Aucun redémarrage n’est requis.

   REMARQUE

   Vous pouvez maintenant localiser le(s) fichier(s) de configuration associé(s) ; à inclure par exemple dans un package de contenu pour une utilisation dans une autre instance.

Configuration OSGi avec les fichiers de configuration

Les modifications de configuration effectuées à l’aide de la console Web sont conservées dans le référentiel en tant que fichiers de configuration (.config) sous :

/apps

Ces fichiers peuvent être inclus dans des packages de contenu et réutilisés dans d’autres instances.

La console web n’indique pas où vos modifications ont été enregistrées dans le référentiel, mais elles peuvent être facilement localisées :

1. Créez le fichier de configuration en d’effectuer une modification initiale dans la console web ;.

2. Ouvrez CRXDE Lite.

3. Dans le Outils menu Requête … .

4. Envoyez une requête de Type SQL afin de rechercher le PID de la configuration que vous avez mise à jour.

   Par exemple, la console de gestion Apache Felix OSGi possède l’identité persistante (PID) :

   org.apache.felix.webconsole.internal.servlet.OsgiManager

   La requête SQL peut donc être :

   select * from nt:base where jcr:path like '/apps/%' and contains(*, 'org.apache.felix.webconsole.internal.servlet.OsgiManager')
   

5. Le noeud du fichier de configuration s’affiche.

   Pour l’exemple ci-dessus :

   /apps/system/config/org.apache.felix.webconsole.internal.servlet.OsgiManager.config

   ATTENTION

   Vous pouvez ouvrir ce fichier pour afficher vos modifications, mais pour éviter les erreurs de saisie, il est recommandé d’effectuer des modifications avec la console.

6. Vous pouvez désormais créer un module de contenu, contenant ce noeud, et l’utiliser selon les besoins sur vos autres instances.

Configuration OSGi dans le référentiel

Outre l’utilisation de la console web, vous pouvez également définir des détails de configuration dans le référentiel. Cela vous permet de configurer facilement les différents modes d’exécution.

Vous réalisez ces configurations en créant des nœuds sling:OsgiConfig dans le référentiel à titre de références dans le système. Ces noeuds reflètent les configurations OSGi et forment une interface utilisateur pour eux. Pour mettre à jour les données de configuration, mettez à jour les propriétés du noeud.

Si vous modifiez les données de configuration dans le référentiel, les modifications sont immédiatement appliquées à la configuration OSGi appropriée comme si les modifications avaient été effectuées à l’aide de la console web, avec les contrôles de validation et de cohérence appropriés. Cela s’applique également à l’action de copie d’une configuration à partir de /libs/ vers /apps/.

Comme le même paramètre de configuration peut être situé à plusieurs endroits, le système :

• recherche tous les nœuds de type sling:OsgiConfig ;
• filtre selon le nom du service ;
• filtre selon le mode d’exécution.

Ajout d’une nouvelle configuration au référentiel

Ce que vous devez savoir

Pour ajouter une nouvelle configuration au référentiel, vous devez connaître les informations suivantes :

1. L’identité persistante (PID) du service.

   Référencez le champ Configurations dans la console Web. Le nom est indiqué entre parenthèses après le nom du lot (ou dans les Informations de configuration vers le bas de la page).

   Par exemple, créez un nœud com.day.cq.wcm.core.impl.VersionManagerImpl. pour configurer le Gestionnaire de versions de gestion de contenu Web d’AEM.

   

2. Si un mode d’exécution spécifique est requis. Créez le dossier :

   • config : pour tous les modes d’exécution.
   • config.author : pour l’environnement de création
   • config.publish : pour l’environnement de publication
   • config.<run-mode> - En fonction des besoins

3. Si une Configuration ou une Configuration d’usine est requise.

4. Les paramètres à configurer individuellement, y compris les définitions de paramètres existantes qui devront être recréées.

   Référencez le champ des paramètres individuels dans la console Web. Le nom s’affiche entre parenthèses pour chaque paramètre.

   Par exemple, créez une propriété
   versionmanager.createVersionOnActivation pour configurer Créer une version lors de l’activation.

   

5. Une configuration existe-t-elle déjà dans /libs ? Pour répertorier toutes les configurations de votre instance, utilisez l’outil Requête de CRXDE Lite pour envoyer la requête SQL suivante :

   select * from sling:OsgiConfig

   Si tel est le cas, cette configuration peut être copiée vers /apps/<yourProject>/, puis personnalisé dans le nouvel emplacement.

Création de la configuration dans le référentiel

Pour ajouter réellement la nouvelle configuration au référentiel :

1. Utilisez CRXDE Lite pour accéder à :

   /apps/<yourProject>

2. S’il n’existe pas déjà, créez le dossier config (sling:Folder) :

   • config : applicable à tous les modes d’exécution
   • config.<run-mode> : spécifique à un mode d’exécution

3. Sous ce dossier; créez un nœud :

   • Type : sling:OsgiConfig

   • Nom : l’identité persistante (PID) ;

     par exemple, pour le Gestionnaire de versions de gestion de contenu Web d’AEM, utilisez com.day.cq.wcm.core.impl.VersionManagerImpl.

   REMARQUE

   Lors de la configuration d’usine, ajoutez -<identifier> au nom.

   Comme dans : org.apache.sling.commons.log.LogManager.factory.config-<identifier>

   Où <identifier> est remplacé par du texte libre que vous devez entrer pour l’instance (vous ne pouvez pas omettre cette information) ; par exemple :

   org.apache.sling.commons.log.LogManager.factory.config-MINE

4. Pour chaque paramètre à configurer, créez une propriété sur ce noeud :

   • Nom : le nom du paramètre, comme indiqué dans la console Web ; le nom est indiqué entre parenthèses à la fin de la description du champ. Par exemple, pour Create Version on Activation, utilisez versionmanager.createVersionOnActivation.
   • Type : selon les cas.
   • Valeur : selon les besoins.

   Vous n’avez qu’à créer des propriétés pour les paramètres que vous souhaitez configurer ; d’autres continueront à utiliser les valeurs par défaut telles qu’elles sont définies par AEM.

5. Enregistrez toutes les modifications.

   Les modifications sont appliquées dès que le noeud est mis à jour en redémarrant le service (comme avec les modifications effectuées dans la console web).

Détails de la configuration

Ordre de résolution au démarrage

L’ordre de priorité suivant est utilisé :

1. Nœuds de référentiel sous /apps/*/config..., que ce soit avec le type sling:OsgiConfig ou les fichiers de propriété.

2. Nœuds de référentiel avec le type sling:OsgiConfig sous /libs/*/config.... (définitions prêtes à l’emploi).

3. Tout fichier .config provenant de <*cq-installation-dir*>/crx-quickstart/launchpad/config/.... sur le système de fichiers local.

Cela signifie qu’une configuration générique dans /libs peut être masquée par la configuration spécifique à un projet dans /apps.

Ordre de résolution à l’exécution

Les modifications de configuration effectuées pendant l’exécution du système déclenchent un rechargement avec la configuration modifiée.

L’ordre de priorité suivant s’applique :

1. La modification d’une configuration dans la console web prend effet immédiatement, car elle est prioritaire au moment de l’exécution.
2. La modification d’une configuration dans /apps prend effet immédiatement.
3. La modification d’une configuration dans /libs prend effet immédiatement, à moins qu’elle ne soit masquée par une configuration dans /apps.

Résolution de plusieurs modes d’exécution

Pour les configurations spécifiques au mode d’exécution, plusieurs modes d’exécution peuvent être combinés. Vous pouvez par exemple créer des dossiers de configuration dans le style suivant :

/apps/*/config.<runmode1>.<runmode2>/

Les configurations de ces dossiers sont appliquées si tous les modes d’exécution correspondent à un mode d’exécution défini au démarrage.

Par exemple, si une instance a été démarrée avec les modes d’exécution author,dev,emea, les nœuds de configuration dans /apps/*/config.emea, /apps/*/config.author.dev/ et /apps/*/config.author.emea.dev/ seront appliqués, tandis que les nœuds d’application dans /apps/*/config.author.asean/ et /config/author.dev.emea.noldap/ ne sont pas appliqués.

Si plusieurs configurations correspondant au même PID sont applicables, la configuration comportant le nombre le plus élevé de modes d’exécution correspondants est appliquée.

Par exemple, si une instance a été lancée avec les modes d’exécution author,dev,emea, et les deux /apps/*/config.author/ et /apps/*/config.emea.author/ définir une configuration pour
com.day.cq.wcm.core.impl.VersionManagerImpl, la configuration dans /apps/*/config.emea.author/ sera appliquée.

La granularité de cette règle se trouve au niveau du PID.
Vous ne pouvez pas définir certaines propriétés pour le même PID dans /apps/*/config.author/ et des propriétés plus spécifiques dans /apps/*/config.emea.author/ pour le même PID.
La configuration comportant le nombre le plus élevé de modes d’exécution correspondants est effective pour tout le PID.

Configurations standard

La liste suivante présente une petite sélection des configurations disponibles (dans une installation standard) dans le référentiel :

• Auteur - Filtre de gestion de contenu Web d’AEM :

  libs/wcm/core/config.author/com.day.cq.wcm.core.WCMRequestFilter

• Publication - Filtre de gestion de contenu Web d’AEM :

  libs/wcm/core/config.publish/com.day.cq.wcm.core.WCMRequestFilter

• Publication - Statistiques de page de gestion de contenu Web d’AEM :

  libs/wcm/core/config.publish/com.day.cq.wcm.core.stats.PageViewStatistics

Pour répertorier tous les nœuds de configuration de votre instance, utilisez la fonctionnalité Requête de CRXDE Lite pour envoyer la requête SQL suivante :

select * from sling:OsgiConfig

Persistance de la configuration

• Si vous modifiez une configuration par l’intermédiaire de la console Web, elle est (généralement) enregistrée dans le référentiel :

  /apps/{somewhere}

  • Par défaut, {somewhere} est system/config, la configuration est donc enregistrée sur

    /apps/system/config

  • Cependant, si vous modifiez une configuration qui provient initialement d’un autre emplacement du référentiel : par exemple :

    /libs/foo/config/someconfig

    La configuration mise à jour est ensuite enregistrée à l’emplacement d’origine ; par exemple :

    /apps/foo/config/someconfig

• Les paramètres modifiés par admin sont enregistrés dans les fichiers *.config sous :

     /crx-quickstart/launchpad/config
  

  • Il s’agit de la zone de données privée de l’administrateur de la configuration OSGi qui contient tous les détails de la configuration spécifiés par admin, quel que soit leur mode d’entrée dans le système.

  • Il s’agit d’un détail de mise en oeuvre et vous ne devez jamais modifier directement ce répertoire.

  • Toutefois, il est utile de connaître l’emplacement de ces fichiers de configuration afin que des copies puissent être prises pour la sauvegarde et/ou plusieurs installations :

    • Console de gestion OSGi Apache Felix

      ../crx/org/apache/felix/webconsole/internal/servlet/OsgiManager.config

    • Référentiel client CRX Sling

      ../com/day/crx/sling/client/impl/CRXSlingClientRepository/<pid-nr>.config

Ressources Business.Adobe.com

Content Insights Personalized Communications Embedded Charts Dynamic Forms Content Management Content Management System