Caverne d'Ali Baba

Les données de configuration du CORE

Avec le FIT on charge des instances avec différents niveaux de configuration. Ces données c'est exactement ce que l'on doit produire dans le cadre d'une intégration pour un client.

Je ne crois pas qu'il existe un générateur qui fabrique directement ce fichier de configuration, mais c'est avec ce contenu que l'on restaure une configuration que l'on aurait pu travailler via la GUI ou l'API.

En fonction du mode de déploiement choisi (voir Test Bed) on aura un ou deux fichiers xml que l'on retrouve dans les données de test sous le chemin suivant:

• <n'importe où>/<racine du projet maven>/core/target/test-classes/domains/MasterContent.xml
• <n'importe où>/<racine du projet maven>/core/target/test-classes/domains/TwoContent.xml

Mais qui seront fournis à l'instance, pour la version docker, via un jar nommé syncope-classes.jar avec une bonne partie de la configuration, et pour la version embedded directement dans la webapp.

Comment ces fichiers sont intégrés et quand ?

Dans les fichiers de propriétés on trouve une première indication:

• persistence.domain[0].key=Master
• persistence.domain[1].key=Two

Si on complète la clé par Content.xml on retrouve nos deux fichiers et l'on constante qu'ils sont associés aux bases des données du CORE. Donc au chargement du CORE il doit y avoir la lecture de ces fichiers.

On pourrait s'autoriser à penser que la classe RuntimeDomainLoader et son paramètre Domain sont impliqués dans cette opération et que tout ça est en rapport avec le support de persistance choisi par l'implémentation.

Regardons le contenu de base de la configuration docker que l'on trouve dans le jar syncope-classes:

Nous avons un seul domaine simpliste avec:

• Le modèle minimal USER et GROUP

• Un schéma minimal avec un seul attribut email et son validateur

• Des classes Java qui apportent des méthodes complémentaires (implémentations) utilisables dans différentes circonstances

• Des tâches de nettoyage

• Des modèles de mail pour le changement de mot de passe et des notifications (?)

• Enfin le modèle d'un rôle interne de Syncope (pour toutes les permissions voir)

Si par comparaison je montre l'un des fichiers de la version embedded (tronqué) on voit vite la différence de richesse, à la fois en terme de règles et configurations mais aussi d'opérations et de traçabilité (on notera la forte influence italienne ;-):