We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

Bug suite à un nettoyage de store

Laurent Benoit · on 10/24/14 at 11:41 AM

Bonjour,

Nous avons constaté une perte d'information suite à un nettoyage de store. Plus précisément, certains groupes perdent leur parent.

Notre application intranet est actuellement basée sur JCMS 8.0.2.

Pour vous donner un exemple, nous avons l'arborescence suivante avant nettoyage (avec les ID entre parenthèses) :

arborescence avant nettoyage

Nous faisons ensuite un nettoyage de store avec les paramètres suivants :

  • Du début à la fin du store
  • Tous les espaces de travail
  • Pas d'URIDs à traiter
  • Effacer toutes les opérations portant sur des objets supprimés
  • Fusionner les modifications mineures

Après redémarrage, nous obtenons l'arborescence suivante :

arborescence apres nettoyage

Deux précisions à ce sujet :

  • En décochant "Fusionner les modifications mineures" avant nettoyage de store, le problème ne se produit pas
  • En regardant le store nettoyé, la dernière ligne concernant le groupe devenu orphelin (rectorat - DSI) a pourtant un attribut parentSet="*|com.jalios.jcms.Group/lb_10991", ce qui laisse penser qu'il n'est pas bien pris en compte lors du chargement du store.

Pour reproduire le problème, nous avons déployé une webapp vierge JCMS 8.0.2 et avons ajouté au store toutes les lignes correspondant aux actions menées sur les 4 groupes concernés : Store exemple prêt à nettoyer

Dans le coup, même si nous pouvons relier manuellement les groupes après nettoyage, nous préférons avoir un retour de votre part afin d'éviter de risquer de perdre d'autres informations que nous n'avons pas repérées.

Merci par avance pour toute information pouvant nous aiguiller.

17 pts
Olivier Jaquemet - on 10/24/14 at 2:07 PM
Best answer

Bonjour,

Merci pour la précision de votre signalement de bug, et notamment la mise à disposition du store.xml de reproduction, si tous les retours pouvaient être aussi précis que le votre on gagnerait un temps fou et le produirait grandirait encore plus en qualité !

Il semble en effet s'agir d'un bug que nous avons saisi sous la référence JCMS-4317 

En attendant, vous pouvez contourner ce bug, et malgré tout procéder à un nettoyage du store avec l'option Fusionner les modifications mineures, en ajoutant le CustomCleanFilter suivant dans votre instance de JCMS : 

  public boolean isCleanable(StorableLogEntry entry, Class clazz) { 

    // Check group parent update 
    if (entry.isUpdate() && Group.class.equals(clazz) && attributeMap.containsKey("parentSet")) { 
      return false; 
    } 

  }


Vous pouvez trouver plus d'information sur le développement d'un CleanFilter dans la fiche Catalogue des points de débranchement (hooks) disponibles dans l'API JCMS

#1

Merci pour votre retour rapide et pour cette solution de contournement qui fonctionne parfaitement, je n'avais pas connaissance de ce hook.

Content que la description de ce bug vous convienne, et merci pour votre réponse toute aussi précise et efficace.

Laurent Benoit · on 10/24/14 at 3:14 PM
10 pts
Olivier Dedieu · on 11/5/14 at 12:06 PM

Bonjour,

 

Voici l'explication du problème :

  • Lors d'un nettoyage du store, par défaut, toutes les opérations de mise à jour sont regroupées en une seule (sauf pour celles indiquées comme non nettoyable par les règles de nettoyage).
  • Après un nettoyage, les opérations portants sur des données distinctes peuvent donc être interverties.
  • Après un nettoyage, des cycles temporaires entre groupes peuvent donc apparaitre suite à certaines opérations du store. Ils sont résolus par d'autres opérations postérieures.
  • La méthode group.setParentSet() effectue un nettoyage systèmatique pour éviter les cycles entre les parents.
  • Le bug est donc lié à cette combinaison : cycle temporaire introduit par le nettoyage et nettoyage pour éviter les cycles. Le cycle temporaire est nettoyé ce qui entraine une perte de liaison entre un groupe et son père.

Sur un exemple simple :

<group stamp="c_1000" id="c_1000" op="create" name="G1" parentSet="" />
<group stamp="c_1001" id="c_1001" op="create" name="G2" parentSet="@|c_1000" />
<group stamp="c_1002" id="c_1001" op="update" parentSet="" />
<group stamp="c_1003" id="c_1000" op="update" parentSet="@|c_1001" />
<group stamp="c_1004" id="c_1001" op="update" order="1" />

Après nettoyage on obtient :

<group stamp="c_1000" id="c_1000" op="create" name="G1" parentSet="" />
<group stamp="c_1001" id="c_1001" op="create" name="G2" parentSet="@|c_1000" />
<group stamp="c_1002" id="c_1000" op="update" parentSet="@|c_1001" />    
<group stamp="c_1003" id="c_1001" op="update" order="1" op="update" parentSet="" />

 

La nouvelle opération c_1002 introduit un cycle (qui sera résolu par c_1003). L'appel à setParentSet() provoquera donc la suppression du cycle et la perte de la liaison.

Correction :

Le bug a été corrigé en ajoutant en standard la règle empechant systèmatiquement le nettoyage des opérations portant sur group.parentSet.

 

Un patch pour JCMS 8 SP2 est attaché à l'issue https://issues.jalios.com/browse/JCMS-4317

 

#1

Bonjour,

Merci beaucoup pour ce retour clair et précis. Cela paraît logique... une fois l'explication trouvée. ;)

Et merci pour votre réactivité.

Laurent Benoit · on 11/5/14 at 1:26 PM
2 pts