Suite au déploiement de notre application en préproduction, nous avons cette erreur dans la partie backoffice (gestion des modules, des objets). Le déploiement sur notre plateforme d’intégration n’a pas engendré ce genre de probleme.
Pas de logs associés à fournir
Je ne reproduis pas ce pb sur l’environnement sur lequel j’ai déployé une 5-beta enrichie (des plugins commerciaux fullcalendar comme vous le faites) + PostgreSQL 10.11 : https://name.sandbox.simplicite.io
Pas de pb y compris avec un contenu MD sur le modyle:
N’est pas juste un pb de cache navigateur ?
Je requalifie en “support”
PS: la version déployée ici :
Version=5.0.0-beta
BuiltOn=2020-12-21 09:35
Git=prerelease/b993c383ce3f8e05f4b3dbe99fc3a9a6bb5ff4a1
Bonjour,
Cette fonction est récente en V5 pour compiler/afficher du markdown en HTML, et elle est bien existante.
Quelle est votre version exacte ?
En V5 les modules ALM ont été retirés par défaut (votre copie d’écran montre ALMPlan, il y a surement qq chose d’anormal dans votre installation, qui me semble une V4 patchée en V5… ?).
De mémoire vous avez étiez en 4.0 et vous avez migré en 5.0 il y a assez longtemps quand elle était encore en “alpha”, cela explique peut être la présence de ces modules ALM.
Le patch2 de la 5.0 supprime les 2 modules ALM, et pas mal de deprecated V4.
donc ça me semble bien un problème d’upgrade qui s’est mal passé.
NB: Pour forcer un re-application des patches il faut forcer en base (car ce n’est pas modifiable via les couches logiques) la valeur du param système PATCH_LEVEL en mettant “x” ou autre chose de non signifiant à la place du hash, ex:
update m_system set sys_value = `5;P00b;x` where sys_code = 'PATCH_LEVEL';
commit;
Puis faire un stop/start de l’instance.
Et là il faudrait regarder de près les logs pour voir s’il y a des erreurs lors de la suppression des modules ALM (ou ailleurs)
Merci beaucoup pour les informations.
Alors, oui c’est une v4 migré en v5. Je vais de ce pas forcer l’application des patch pour lever les éventuelles erreurs.
Voici la version actuelle:
Simplicité version5.0.0-beta
Built on2020-12-16 22:04
Git infoprerelease/a94bc83b063a3d3337ccf694aebb2dfe0ebbdf48
Je pense que l’application du patch n’arrive pas à aboutir. Voir logs en pj.
log-events-viewer-result.csv (257.1 KB)
Merci
Les 2 patchs s’appliquent bien on voit tous les ALTER passer.
mais tous les delete terminent en exception ce qui n’arrive jamais (je vais revérfier qd même) :
Le reste c’est du warning sans effet.
Il va falloir vérifier que la suppression fonctionne par XML et par la UI sur votre instance.
Droit de suppression en base via le user JDBC… ? Et regarder les logs pour voir la stack java si c’est cassé quelque part = savoir pourquoi ça termine en “out of range” dans le socle.
Est-ce que vous avez toujours le problème de markdown ? qui lui n’est pas sensé se produire car lié au runtime front chargé (pb de cache navigateur qui aurait les tools bootstrap en V4 et le runtime en V5 par exemple).
Oui on a toujours le probleme de markdown. Que puis-je supprimer en xml pour tester ça ?
Effectivement çà peut être une piste, car j’ai eu du mal a importer mes propres modules. J’ai fini par supprimer (du moins j’ai essayé) les modules pour les réimporter mais j’ai l’impression que le processus de suppression n’aboutissait jamais completement. (String index out of range: 0)
Le pb de markdown est la partie visible d’un problème plus grave car si ce n’est pas un pb de cache navigateur, c’est que vous avez une instance bancale qui a des scripts incompatibles :
ui-bundle.js resté en V4 qui ne connait pas markdownToHTMLbootstrap4.js en V5 qui utilise view.markdownToHTML pour les textes en rendering MDAu debugger chrome F12 (onglet console), cliquez sur les scripts ui-bundle (moteur UI) et bootstrap4 (tools pour boostrap 4) pour vérifier les versions (dans l’onglet source), si c’est Simploicité V4 c’est mauvais signe :
Les log tomcat/catalina signalent surement un problème plus bas niveau qui ne remonte pas dans Simplicité qui termine dans un cas non géré (même si le message d’erreur “out of bound” était géré ça indiquerait suppression impossible, bref ne corrigerait rien).
<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
<name>SystemParam</name>
<action>upsert</action>
<data>
<sys_code>TEST_DELETE</sys_code>
<sys_value>xxx</sys_value>
<sys_type>PRV</sys_type>
<sys_desc>Test delete</sys_desc>
<row_module_id.mdl_name>Application</row_module_id.mdl_name>
</data>
</object>
<object>
<name>SystemParam</name>
<action>delete</action>
<data>
<sys_code>TEST_DELETE</sys_code>
</data>
</object>
</simplicite>
En ce qui concerne les ressources tout a l’air en ordre, j’ai bien // UI API - Simplicite 5.P00b sur bootstrap4.js ,ui.js, import.js
Via la UI j’ai bien réussi a créer un paramètre et à le supprimer.
Idem via xml :
2020-12-21 14:11:23,368 INFO [] Start import object SystemParam:
2020-12-21 14:11:23,368 INFO [] Found field sys_code = [TEST_DELETE]
2020-12-21 14:11:23,368 INFO [] Found field sys_value = [xxx]
2020-12-21 14:11:23,368 INFO [] Found field sys_type = [PRV]
2020-12-21 14:11:23,368 INFO [] Found field sys_desc = [Test delete]
2020-12-21 14:11:23,368 INFO [] Found field row_module_id.mdl_name = [Application]
2020-12-21 14:11:23,369 INFO [] New record key row_id
2020-12-21 14:11:23,369 INFO [] Action: INSERT
2020-12-21 14:11:23,401 INFO [] Save ok.
2020-12-21 14:11:23,406 INFO [] Start import object SystemParam:
2020-12-21 14:11:23,406 INFO [] Found field sys_code = [TEST_DELETE]
2020-12-21 14:11:23,407 INFO [] Found internal key row_id = 585
2020-12-21 14:11:23,410 INFO [] Action: delete
2020-12-21 14:11:23,431 INFO [] Delete ok.
Merci,
Essayez de refaire ce test avec le même paramètre mais dans le module “System” avec le user designer. Il faut le paramètre ADMIN_SYSTEM=yes pour le user designer, sinon ça pourrait expliquer ces fonctionnements étranges.
Votre repositiory doit avoir un problème de synchro ou de surcharge de choses spécifiques.
@david un idée ?
ui-bundle.js (573.5 KB) bootstrap4.js (54.8 KB)
Désolé je ne parviens pas à ouvrir les 2 fichiers (à mon avis par sécurité du forum de ne pas charger des JS). Essayez de les envoyer dans un ZIP ou en les renommant en .txt
Si vous trouvez markdownToHTML dans l’un et pas dans l’autre même après un upgrade / reset cache back+front, il faut alors vérifier votre repository GIT ou image docker… pour remonter à l’origine du problème.
Ces 2 fichiers sont accessibles dans le répertoire de la webapp ROOT/scripts/ui/ui-bundle.js et /scripts/ui/extends/bootstrap4.js.
Si ui-bundle.js ne contient pas la fonction markdownToHTML c’est que vous n’êtes pas ou partiellement à jour, et qu’il y a un soucis dans votre chaine d’upgrade.
Sur le pb de “delete”, il nous faut voir les log tomcat au moment de l’incident, mais si les libs ne sont pas bien à jour, on ne peut pas garantir le comportement attendu. Si par la UI ça refontionne, il faut peut être reforcer un upgrade (après avoir vérifié le repository de vos versions).
Peut être avez vous monté des volumes dans la webapp qui fait que quand le container est upgradé avec l’image à jour certains fichiers (classes java ou fichiers JS) ne sont pas bien mis à jour dans le processus ?
Peut être qu’il y a un pb quand vous buildez votre image custom (pour ajouter les plugins Fullcalendar) ?
Etc.
Serait il possible de ne conserver que la base de données et de démarrer un container simplicite/platform:5-beta “out of the box” et sans volumes (à part éventuellement le volume sur le répertoire git)?
Pour mémoire sur mon environnement de test voici le fichier compose que j’utilise:
version: "3"
services:
postgres:
image: postgres:10.11
restart: always
environment:
POSTGRES_USER: "simplicite"
POSTGRES_PASSWORD: "simplicite"
POSTGRES_DB: "simplicite"
volumes:
- data:/var/lib/postgresql/data
simplicite:
build: .
restart: always
environment:
DB_SETUP: "true"
DB_VENDOR: "postgresql"
DB_HOST: postgres
DB_USER: "simplicite"
DB_PASSWORD: "simplicite"
DB_NAME: "simplicite"
DB_WAIT: 100
ports:
- 127.0.0.1:8443:8443
volumes:
- git:/usr/local/tomcat/webapps/ROOT/WEB-INF/git
depends_on:
- postgres
volumes:
data:
git:
Avec le Dockerfile suivant pour le build de l’image custom:
FROM simplicite/platform:5-beta
ADD https://github.com/fullcalendar/fullcalendar-scheduler/releases/download/v4.4.2/fullcalendar-scheduler-4.4.2.zip /tmp/
RUN yum install -y unzip && yum clean all \
&& mkdir /tmp/fullcalendar \
&& unzip /tmp/fullcalendar-scheduler-4.4.2.zip -d /tmp/fullcalendar \
&& mv -f /tmp/fullcalendar/packages-premium/* /usr/local/tomcat/webapps/ROOT/scripts/fullcalendar/v4/ \
&& rm -fr /tmp/fullcalendar*
Je vais regarder dans le git. Quoi qu’il en soit, on n’utilise pas de paramétrage spécifique pour le lancement du container, nous n’utilisons pas de volumes.
ressources.zip (166.5 KB)
Mon point c’est plus de relancer un container en étant absolument sûr qu’il ne reste rien du précédent.
En effet il semble que votre pb soit un pb de classes / libs / JS, … statiques de la webapp (ex: le scripts/ui/ui-bundle.js) pas à jour ce qui ne devrait pas pouvoir arriver en utilisant nos images Docker à moins qu’il y ait quelque chose quelque part qui empêche certains fichiers de se mettre à jour quand on relance un nouveau container à partir d’une nouvelle image, mais je vois vraiment pas quoi typiquement s’il n’y a pas de volumes persistants. explicites ou implicites.
Bonjour,
Jamais vu un tel problème où les sources installées viennent de 2 builds différents. La fonction markdownToHTML est une évolution récente et a bien été poussée en même temps dans nos versions.
Il faut donc trouver la cause du pb d’installation dans vos environnements :
markdownToHTML dans ui-bundle.jsJe note de notre côté 2 choses :
// UI API bundle - Simplicite 5.P00b
qui n’est pas suffisant pour détecter ce déphasage étrange. Sinon il faudra vite passer en release pour que le P0x change à chaque “commit” éditeur.
Par acquis de conscience, je viens de refaire le test de déploiement d’une image Docker simplicite/platform:5-beta + ajout des plugins fullcalendar (cf. une réponse précédente) => la fonction JS markdownToHTML est bien physiquement présente dans le container dans le fichier /usr/local/tomcat/webapps/ROOT/scripts/ui/ui-bundle.js. Je n’en doutais pas car dans mes tests d’hier je n’avais pas reproduit le pb indiqué.
Si ce n’est pas le cas chez vous il y a donc nécessairement une subtilité dans la manière dont vous avez déployé le container qui fait que les fichiers statiques du container ne sont pas les bons à l’arrivée. SI le pb est uniquement sur ce JS ça peut être un “simple” pb de cache navigateur (ou de cache web intermédiaire sur les infras que vous utilisez), s’il y a aussi des pbs sur des composants statiques Java (.class ou .jar) c’est qu’il y a bien un pb de déploiement au niveau du container.
Pour info je vais travailler le packaging pour aller dans le sens de ce qu’indique François = des contrôles de checksums sur les fichiers “clés” de la plateforme pour alerter si on voit que ceux ci ne sont pas ceux attendus.
Et pour rappel il est bien prévu d’avoir une numérotation en 5.x.y avec un y qui change à chaque build sur la branche release. Ici on parle d’une prerelease (beta) qui est, comme la master (alpha), un simple “snapshot” = ici la 5.0.0-SNAPSHOT, donc c’est parfaitement normal qu’on ne touche pas le y à chaque livraison sur cette branche => pour un snapshot c’est la révision Git qui permet de savoir où on en est.
Le fond du pb c’est que les différents pbs très étranges - et donc forcément inquiétants - que vous nous remontez sont essentiellement ce qui nous retient de passer en release la 5.0. On se mord donc la queue sur ce point.
La manière dont on déploie sur nos 3 environnements est la même, ce sont des scripts CDK qui déploient le container sur le service amazon ECS. Les conteneur n’ont que peu de paramètre passés au démarrage, ils concernent uniquement les JAVA_OPTS et les accès BDD. Pas de volume créé.
Cependant, sachant qu’on passe par des tâches ECS, les conteneurs ne sont pas accessibles. Je pense pas que la manière dont on le déploie pose problème dans la mesure ou c’est la même procédure sur les 3 environnements.
Je pense que la piste à explorer est celle des suppressions qui ne sont pas possible lors de la migration. Cependant nous n’avons aucune restriction coté BDD et nous n’avons pas plus de logs que ceux que je vous ai fourni.