Simplicité ne peut pas surcharger le fonctionnement nominal de Java. Monter à chaud des librairies ou des classes re-compilées n’est pas toujours possibles (car n’a strictement rien de basique comme vous le sous-entendez) sans redémarrage de la JVM, ça n’a strictement rien à voir Simplicité, c’est valable pour toute webapp, tout OS, tout système. Il a fallu 10 ans de R&D pour y arriver, certes tout n’est pas encore idéal, mais on repousse les limites chaque jour du low-code.
Vos sessions travaillent sur le class-loader qui connait ces classes sinon vous auriez le même problème.
Java a ses avantages (compilé/rapide/debugable) et ses contraintes (attention aux choses qui ne sont pas placées dans le heap comme des static = pas de GC…).
Tout comme Rhino (hook java-scripté) qui n’est pas compilé (donc aucun problème de class-loading) mais interprété (moins rapide, pas facile à debugger).
Personne ne rencontre vos problèmes donc non, nous n’avons pas d’avertissement particulier à donner dans un cas d’usage “standard” des hooks en Java.
Vous êtes dans un cas inconnu que nous essayons de comprendre et ce forum ne permettra visiblement pas de le résoudre sans logs, ni code source. Là par contre c’est basique.
Bonne nouvelle pour le NDA, je vous fourni le code dès que j’ai le go de mon coté.
Pour en revenir au sujet, pour moi le meilleur moyen d’éviter ce problème est d’éviter d’utiliser une plateforme de développement pour 4-5 développeurs. Cependant on est bloqués dans la mesure ou on ne peut pas travailler localement en utilisant git a cause du merge de xml.
Pourriez vous nous notifier quand la fonctionnalité EXPORT_MODULE_EXPLODED sera testée et éprouvée ?
Notamment si on souhaite faire du remote debug en Java, il faut nécessairement être seul sur son environnement.
Le besoin de “diff+merge” est bien prioritaire et en cours, sachant que là encore il n’y a pas d’état de l’art pour comparer/merger un modèle relationnel avec un autre (c’est le même pb que de vouloir comparer une base de données avec une autre, aucun SGBD n’a de solution miracle). La bonne pratique est souvent organisationnelle pour splitter correctement les taches pour éviter un merge parfois impossible ou trop complexe à la fin.
@david travaille toujours sur la comparaison de modules éclatés sous forme de fichiers arborescents que GIT aime bien comparer/merger nativement.
De mon côté, je travaille sur un sujet corolaire pour rendre générique ce besoin de comparaison sur la UI depuis un arbre (Treeview Simplicité) qui s’affichera dans un écran splitté en 2 avec drag&drop de l’un vers l’autre. Le besoin sous-jacent est le diff graphique, la recopie de branche… d’un objet métier quelconque sur lui-même (voir donc d’un Module dans 2 versions différentes ou dans 2 bases différentes, ou de comparaison de contrat/clauses, ou de fusion partielle de 2 organisations…).
Sinon le mode d’export éclaté sera éprouvé quand des gens s’en serviront et remonteront d’éventuels problèmes. Sur ce sujet vous êtes en pointe.
De notre coté les tests qu’on a fait sont concluants pour des exports/imports de modules “simples” (genre la démo); c’est donc comme je l’ai dit utilisable moyennant de sécuriser le process en faisant des exports XML classiques en // de temps en temps. Surtout les premiers temps.
C’est uniquement quand ce mécanisme aura été confronté à la vraie vie et ses cas plus aux limites qu’il sortira du domaine des features “expérimentales”.
Pour mémoire la page de diff de module UI (accessible notamment depuis la page de gestion Git du module) ne fonctionne pas encore dans ce mode mais ce mode d’export rend de toute façon cette page relativement sans intéret.
J’ai dû l’indiquer sur l’autre POST, mais après avoir installé vos modules sur un environnement local :
le pb de ClassNotFound sur votre classe PlatformHooks se produisait bien sur une version 5.1 (latest = master en cours dev où PlatformHooksInterface a évolué),
en revanche aucun soucis sur une 5.0 (beta en cours de release)
On a ajouté un wrapper pour garantir la compatibilité ascendante de l’interface en 5.1. Je pense que c’est le bug originel dans les stacktraces qui en entraine d’autres imprévisibles.
@wchoumi
Etes vous sûr que les “logs.log” envoyés proviennent d’une instance en 5.0 ?
Cette instance de formation a dû passer d’une 5.0 à une 5.1 (et/ou réciproquement) à un moment donné, enfin un upgrade à du faire quelque chose du genre. Je ne vois pas d’autres explications à cette classe PlatformHooksInterface qui n’est plus dans le package où elle était avant.
L’erreur était peut être chez nous dans nos images distribuées à un moment donné quand on a créé la branche 5.1.
En tous cas, il faut essayer de forcer une mise à jour et voir si votre instance se met à jour correctement.
Car l’erreur de classe PlatformHooksInterface correspond à une erreur d’un moteur 5.1 et non 5.0.
Le correctif en 5.1 arrivera ce soir, mais rien en 5.0 puisque cette erreur ne s’y produit pas.