Problème de clone, de temps en temps

Bonjour, Nous travaillons en JCMS 7.0.1.

Bien à vous.

Rudi

Au passage je me permet de vous recommander une structure :

Publication clone = (Publication) pub.getUpdateInstance();
//do something to the clone
ControllerStatus status = clone.checkUpdate(loggedMember);
if (!status.hasFailed()){
  clone.performUpdate(loggedMember);
} else {
  //treat publication failure
  logger.info(status.getMessage(channel.getLanguage()));
}

J'ai pu reproduire votre problème.

Vous avez sans doute remarqué qu'en mémoire il était correct, seule l'écriture dans le store "oubliait" ce paramètre, et donc le problème n'était constatable fonctionnellement qu'au redémarrage du serveur. Ce point est important dans la détection du problème.

Comme je l'avait pré-senti, la différence entre "parcourir" et "déposer un document" est liée à la session d'écriture.
En effet, lorsque vous utilisez "parcourir" la création du document et la modification lors de l'after-write de votre objet sont réalisée dans une même session. Ainsi l'objet Java TreeSet "AuthorizedGroup" est enregistré lors de la création et détecté comme non-modifié lors de la mise à jour puisque l'instance "avant" et l'instance "après" sont identique (même objet java). Le fait de remplacer le TreeSet résous donc ce cas.

Le champ "Category" a l'avantage d'être un tableau et donc il change d'instance à chaque modification, c'est pourquoi il ne pose pas de problème.

De manière générale faire un "deep clone" d'un objet avant sa modification éviterai ce genre de problème, Afin de ne pas pénaliser les performances on ne clone que les objets qu'on modifie, en l’occurrence le TreeSet doit être cloné même si dans la plupart des cas le problème ne se pose pas.

En l'absence de clonage du treeSet, si jamais l'enregistrement était annulé, la modification persisterait en mémoire.

Dans le cas de l'utilisation du "déposer un document", lors de la modification du TreeSet, l'instance "avant" contient 'null' et l'appel à addAuthorizedGroup instancie un TreeSet, la modification du champ est donc détectée. Si à la place je sélectionne un document existant ayant déjà un AuthorizedGroup, on se retrouve à modifier le TreeSet initial et donc aucune modif ne sera enregistrée dans le store mais l'information persistera en mémoire.

Ce problème est justement la raison pour laquelle toute modification d'un objet du store doit toujours passer par un clone.
Pour conclure ici le cas particulier c'était quand ça marchait alors que le code était incorrect, votre contournement était le plus proche du code correct, il faut juste prévoir de récupérer le TreeSet pour le cas où il existerait.

le code correct est donc :

  if (oData instanceof DocumentOffre) {
    FileDocument cloneDocument = (FileDocument)((DocumentOffre)oData).getDocument().getUpdateInstance();
    
    cloneDocument.addCategory(channel.getCategory("n_5006"));
    
    TreeSet<Group> authorizedGroup = new TreeSet<Group>(cloneDocument.getAuthorizedGroupSet());
    authorizedGroup.add(channel.getGroup("c_54552"));
    cloneDocument.setAuthorizedGroupSet(authorizedGroup);
    
    ControllerStatus status = cloneDocument.checkUpdate(channel.getDefaultAdmin());
    if (!status.hasFailed()){  
      cloneDocument.performUpdate(channel.getDefaultAdmin());
    } else {
      logger.info(status.getMessage(channel.getLanguage()));  
    }
  }

J'espère que mes explication sont claire, n'hésitez pas si vous souhaitez plus de précision.

cordialement, Kerdudou Ronan.