La migration de 5.3.71 vers 6.0.12 ne pose pas de problème en supprimant tout les script rhino de la table m_script_usage et l’applicatif tourne correctement aucun problème. Néanmoins si j’essaye de faire la même chose en passant de la 5.3.76 vers la 6.2.15 en java 21 je rencontre d’énorme problème.
Globalement l’applicatif ce lance correctement néanmoins aucune donné n’est accessible, c’est à dire que tout les menus s’affiche correctement mais que toute les listes sont vides alors qu’en bdd il y a de la donnée. Avec comme message d’erreur pour tout les objet non natifs simplicité :
WARN|designer|com.simplicite.util.engine.ObjectLoader|getClone||Evénement: Unable to clone the object MonObjet: read it from repository (slow access)
java.lang.NullPointerException: Cannot invoke "com.simplicite.util.ObjectDB.setData(com.simplicite.util.engine.ObjectData)" because "o" is null
De plus en designer je n’ai plus aucun bouton pour pouvoir créer des éléments dans ces listes.
Sans plus d’informations c’est difficile de vous aider…
A minima il faudrait nous fournir l’intégralité des logs correspondant au démarrage d’upgrade (i.e. le 1er démarrage suite à la mise à jour de la webapp). Le warning que vous fournissez n’est sans doute qu’un symptôme final d’un problème se situant en amont, peut être pendant la phase d’upgrade.
A chaque release nous testons des migrations “usine” de 5.3 à jour vers 6.2 à jour et n’avons pas connaissance de problèmes particuliers. Quelle est la base de donnée (type et version) que vous utilisez ? Je demande pour qu’on refasse un test dans les conditions les plus proches des votres.
NB: la v6 n’a pas forcément besoin d’une JVM 21, c’est mieux mais une JVM 17 peut aussi faire l’affaire, ce qui n’est plus supporté à partir de la 6.2 c’est une JVM 11 (cf. les breaking chnages de la release note 6.2)
Est-ce que votre code spécifique compile en 6.2 (par exemple, certaines méthodes Java Simplicité qui étaient déjà deprecated en v5 ont été progressivement lors des versions mineure successives de la v6) et avec un JDK 21 (au niveau Java certaines choses ont aussi été changées entre 11 et 21) ?
Ca peut se tester en démarrant une instance vierge 6.2 et en y important vos modules ou en faisant la manip en dehors de Simplicité en modifiant le pom.xml de vos modules pour les faire référencer la 6.2 et en faisant des mvn clean compile (ou l’équivalent dans un IDE Java) etc. Si vous nous fournissez vos modules nous pouvons faire cette analyse pour vous si ce que je décris n’est pas possible ou trop compliqué sur vos environnements de dev.
Comme indiqué dans ma réponse précédente une JVM 21 ne pose aucun pb à Simplicité v6, c’est d’ailleurs bien notre recommandation (et ce qu’on livre dans nos images Docker v6 par défaut) même si une JVM 17 reste possible en 6.2. Je dis juste de vérifier que ça ne pose pas de problème à votre code spécifique s’il a été écrit dans le cadre d’une JVM 11 ou 17
La version actuelle de Tomcat 9 est la 9.0.108, c’est celle que nous utilisons (notamment dans nos images Docker). Je ne vois aucune raison que cela pose problème à Simplicité v5 ou v6 ou à votre code spécifique d’utiliser une version plus ancienne de Tomcat 9 mais il y a eu de nombreuses vulnérabilités corrigées (cf. Apache Tomcat® - Apache Tomcat 9 vulnerabilities), il serait donc souhaitable de vous mettre à jour quoi qu’il en soit (attention: restez bien sur un Tomcat 9, les Tomcat 10 et 11 ne sont pas compatibles avec les v5 et v6 de Simplicité, pour information la future Simplicité v7 sera, elle, incompatible avec Tomcat 9 et 10 et nécessitera donc Tomcat 11)
Nous allons faire un test d’ugrade “usine” v5 (5.3 à jour) vers v6 (6.2 à jour) sur un PostgreSQL 15.5 pour vérifier que cela se passe correctement (nous testons avec un PostgreSQL à jour donc actuellement 17.6) et nous vous tiendront au courant.
Je vous laisse vérifier votre code sur une 6.2 vierge, tenez nous au courant de ce que vous constatez.
PS: lors de votre procédure d’upgrade vous assurez vous bien de supprimer préalablement tout ficher de cache sérialisé residuel ? (ex: WEB-INF/cache/core.ser), si vous utilisez nos scripts de démarrage (ceux utilisés notamment dans nos images Docker) c’est fait
Nous n’avons constaté aucun problème ni pendant le processus d’upgrade ni sur le fonctionnement de l’instance une fois upgradée. La version de PostgreSQL que vous utilisez n’est donc à priori pas en cause non plus.
Il va donc bien falloir creuser plutôt du coté de vos modules (en particulier au niveau de votre code spécifique) et/ou de la manière dont votre instance est déployée et/ou de la manière dont vous réalisez l’upgrade.
Suite à la fourniture fourniture de la log d’import de votre module sur une instance 6.2 vierge, je vois à la fin ceci:
2025-09-04 16:47:52,807 INFO [] Start import object Script:
2025-09-04 16:47:52,807 INFO [] Found field scr_code = [SngPublipostage]
2025-09-04 16:47:52,807 INFO [] Found field scr_file = path src/com/simplicite/commons/ScenarioNG/SngPublipostage.java
2025-09-04 16:47:52,807 INFO [] Found field scr_type = [JSR]
2025-09-04 16:47:52,807 INFO [] Found field row_module_id.mdl_name = [ScenarioNG]
2025-09-04 16:47:52,807 INFO [] New record key row_id
2025-09-04 16:47:52,807 INFO [] Action: INSERT
2025-09-04 16:47:52,820 INFO [] Save ok.
2025-09-04 16:47:52,829 INFO [] Error during XML processing: java.lang.NullPointerException: Cannot invoke "com.simplicite.util.integration.TagXML.setObject(com.simplicite.util.integration.ObjectXML)" because "tag" is null
Pourriez vous nous fournir le fichier module que vous importez ou en tout cas les blocs XML correspondant aux traces ci-dessus = le bloc du code partagé SngPublipostage et le suivant ?
Sinon pouvez vous nous indiquer comment exactement vous effectuez cet import de module:
quel format source utilisez vous : fichier XML ? fichier ZIP ? fichier JSON ? fichier tar.gz ? répo Git ?
quelle méthode d’import: via un importspec au démarrage ? via curl sur I/O ? via Git ? manuellement via la UI (dans ce cas UI merci de nous indiquer exactement votre mode opératoire)
Votre procédure d’upgrade macro me semble correcte mais idéalement il faudrait y ajouter la mise à jour systématique de Tomcat 9 entre 2) et 3)
Arrêt du service Tomcat
Changement de la version Java
Changement du template Simplicité 5.3.x par Simplicité 6.2.x
Démarrage du service Tomcat
Votre processus d’import de module manuel via la UI semble OK aussi.
Nous avons pu récupérer votre fichier ZIP de module; nous allons faire le test d’import et regarder ce qu’il se passe.
Est-ce que les erreurs d’import que vous constatez se produisent (et sont identiques) uniquement en upgrade de l’instance existante (donc sur PostgreSQL) ou aussi sur l’instance vierge avec base de données embedded (donc sur HSQLDB, pas une H2 mais ça ne change rien)
Indépendamment des tests d’import/upgrade que je n’ai malheureusement pas encore eu le temps de faire, j’ai fait le test de compilation de votre module en 6.2 et il y a bien des points à revoir:
et faire un mvn -U clean compile ou son équivalent dans un IDE Java.
Si vous n’avez pas accès à internet et donc pas aux repos Maven publics vous pouvez aussi faire pointer l’URL du repo Maven sur le /maven d’une instance 6.2 interne
déploiement d’une instance 5.3 à jour (5.3.76) sur PostgreSQL 15.5
désactivation des tâches cron de type “GC” :
import du module ScenarioNG via la UI (upload du ZIP + import)
upgrade en 6.2 à jour (6.2.15)
réactivation des tâches cron désactivées
NB: Le 2) est plus “sûr” lorsqu’on traite des imports de module volumineux (donc longs à importer) ou des upgrades logs (comme ici où on applique successivement les patches système de la 6.0, 61 et 6.2)
L’import du 3) s’est déroulé (en ~3min) sans erreur, si ce n’est une cardinalité mal écrite 0.n au lieu de 0,n => à corriger mais sans conséquence car par défaut la valeur prise en compte est 0,n.
L’upgrade du 4) s’est lui aussi déroulé (en ~7min) sans problème et à l’arrivée l’instance fonctionne (au sens de la plateforme):
Attention: il y a bien les problèmes de compatibilité v5-v6 dans votre code spécifique indiqués dans mon post précédent qu’il faut corriger afin qu’il compile en v6
Les upgrades de version majeure ont toujours des subtilités liées au sens de l’histoire (= aux déprécations incontournables, aux changements de socle technique, etc.), c’est pour cela que nous incitons nos clients et partenaires à ne pas attendre “trop longtemps”. Passer de v5 à v6 aurait été sans doute un peu plus fluide en 6.0 ou 6.1, le passage de 6.0 à 6.1 puis 6.2 étant unitairement plus fluide aussi.
