Style barre de menu cassé

Bonjour,

J’ai mis à jour mes environnements hier avec cette version :

Version=4.0.P23
BuiltOn=2019-06-24 12:02 (revision 37bff5123e5689935ee77c91105f31c1cf3a1f5c)

Et sur l’un de mes environnements, le style de la barre de menu est cassé. Il n’y a pas d’erreur dans la console mais j’ai trouvé les warnings suivants dans /ui/logs

2019-06-25 10:11:17,002 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/field.png (No such file or directory)
2019-06-25 10:11:16,999 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/business_object.png (No such file or directory)
2019-06-25 10:11:16,995 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/shared_code.png (No such file or directory)
2019-06-25 10:11:16,994 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/module.png (No such file or directory)
2019-06-25 10:11:16,881 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/system_param.png (No such file or directory)
2019-06-25 10:10:45,844 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/field.png (No such file or directory)
2019-06-25 10:10:45,833 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/business_object.png (No such file or directory)
2019-06-25 10:10:45,826 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/shared_code.png (No such file or directory)
2019-06-25 10:10:45,822 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/module.png (No such file or directory)
2019-06-25 10:10:45,637 WARN [com.simplicite.webapp.WebServicesFactory] SIMPLICITE|http://8251035d95ca:8080||WARN|designer|com.simplicite.webapp.WebServicesFactory|readStaticImage||Event: /usr/local/tomcat/webapps/ROOT/images/icon/title/img/system/system_param.png (No such file or directory)

Screenshot du problème de style :

Pouvez vous préciser comment vous avez effectué cette mise à jour ?
Et sur quel type de déploiement (manuel, container Docker, SIM ?)
Etc.

J’ai une pipeline Gitlabee qui déploie via le container docker simplicite/platform:latest

Ok on est dans du contexte Docker chez Renault. Désolé votre pseudo “gge” ne me parlait pas vraiment… Là j’ai compris qui vous êtes.

Je ne vois pas de raison d’avoir un pb d’update sur une image Docker.

Que disent les logs ?

Voilà les logs qui suivent ma dernière connexion :

2019-06-25 11:40:58,499 INFO [com.simplicite.util.Grant] SIMPLICITE|http://849443890e41:8080||ICORED0001|designer|com.simplicite.util.Grant|init||Info: designer connected using Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36, timeout = 3600s
2019-06-25 11:40:58,482 INFO [Logon] SIMPLICITE|http://849443890e41:8080||SESSION|designer|Logon|login (direct)||Session utilisateur=designer/F207C7EF4E22E657AAC643D25E20678D time=0
2019-06-25 11:40:46,050 INFO [com.simplicite.util.Grant] SIMPLICITE|http://849443890e41:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36, timeout = 3600s
2019-06-25 11:40:46,031 INFO [Logon] SIMPLICITE|http://849443890e41:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/F207C7EF4E22E657AAC643D25E20678D time=0
2019-06-25 11:40:00,099 INFO [com.simplicite.util.CronJob] SIMPLICITE|http://849443890e41:8080||ICORECM005|system|com.simplicite.util.CronJob|run||Result of job ImportXML : No XML file to import.
2019-06-25 11:40:00,079 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|http://849443890e41:8080||INFO|system|com.simplicite.util.engine.CronManager|run||Event: Cron manager is sleeping for 0:04:59...
2019-06-25 11:40:00,079 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|http://849443890e41:8080||INFO|system|com.simplicite.util.engine.CronManager|run||Event: Next cron job: deadlockActivity at Tue Jun 25 11:45:00 CEST 2019
2019-06-25 11:40:00,079 INFO [com.simplicite.util.CronJob] SIMPLICITE|http://849443890e41:8080||ICORECM004|system|com.simplicite.util.CronJob|run||Execute job ImportXML at 2019-06-25 11:40:00
2019-06-25 11:40:00,079 INFO [com.simplicite.util.engine.CronManager] SIMPLICITE|http://849443890e41:8080||INFO|system|com.simplicite.util.engine.CronManager|run||Event: Next cron job: ImportXML at Tue Jun 25 11:45:00 CEST 2019

Non je ne parle pas de d’un vague extrait des logs Simplicité sans contexte…

Je parle des logs complètes de Tomcat et de Simplicité (normalement c’est ce que vous avez sur le stdout du container si on parle bien de nos images Docker standard) et ce depuis le démarrage du container.

Sans cela on ne peut vraiment pas deviner ce qui s’est passé. Des updates de plateforme il y en a des dizaines (pour ne pas dire des centaines) qui s’effectuent sans problème tous les jour, donc ici il y a forcément un truc particulier qu’il convient d’identifier précisément.

Et dans le même ordre d’idée merci de nous indiquer le résultat complet de l’appel sur /health

Je ne peux pas récupérer les logs complets dans l’immédiat, l’accès à la fonction d’export de logs dans Kibana requiert une demande de droits, je ferai suite dès que possible. :)

Ok à suivre, sans les logs initiales on peut rien investiguer…
Envoie moi quand même le /health

Vérifie aussi que le container démarre bien en auto upgrade (c’est le cas par défaut). Les logs nous le confirmeront de toute façon.

Dans CATALINA_OPTS j’ai bien -Dplatform.autoupgrade=true

Et le health complet :

[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-06-24 12:02 (revision 37bff5123e5689935ee77c91105f31c1cf3a1f5c)
Encoding=UTF-8
EndpointIP=172.17.0.13
EndpointURL=http://849443890e41:8080
TimeZone=Europe/Paris
SystemDate=2019-06-27 18:23:52

[Application]
ApplicationVersion=0.16
ContextPath=
ContextURL=https://ope.rfs.ope.aws.renault.com
ActiveSessions=3
EnabledUsers=10
TotalUsers=14
LastLoginDate=2019-06-27 18:23:47

[Server]
ServerInfo=Apache Tomcat/9.0.21
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.101-75.76.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9158
DiskUsable=8630
DiskTotal=10015

[JavaVM]
Version=1.8.0_212
Vendor=Oracle Corporation
VMName=OpenJDK 64-Bit Server VM
VMVersion=25.212-b04
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=256629
HeapSize=506944
HeapMaxSize=1773888
TotalFreeSize=1523573

[Cache]
GrantCache=86
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=19
ObjectCacheMax=10000
ObjectCacheRatio=0
ProcessCache=0
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.5.jre7
DBDate=2019-06-27 18:23:52
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-06-27 18:23:52
ElapsedTime=107

Ok rien d’anormal à ce niveau… On verra sans doute des choses dans les logs quand tu les aura

Pour forcer la reapplication des patches P23 - on ne sait jamais - peux tu faire en base un update m_system set sys_value='P22' where sys_code='PATCH_LEVEL' et relancer ton container.

Cela dit les warnings que tu indiques dans ton post initial sont normaux quand on est sur la UI legacy (ce qui ne devrait pas être le cas chez toi). Peux tu me faire une copie d’écran de ce que tu appelles “styles cassés” ?

Le “style cassé” m’empêche de cliquer sur certaines zones donc je suis passé en mode legacy pour effectuer certaines actions, d’où la présence des logs de la UI legacy donc. Je ne peux pas faire d’actions en base pour le moment, à tenter de mon côté.

Pour la copie d’écran, je l’ai jointe à la fin de mon message initial.

OK, juste la UI legacy n’est pas une “UI de secours” c’est avant tout une UI en fin de vie que plus personne ne devrait utiliser (on l’a conservé uniquement pour laisser le temps aux gens de migrer leur vielles applications)

Un pb comme celui que tu indique est sans doute lié à un pb d’upgrade (donc la UI legacy sera autant cassée que la UI responsive, sinon plus). Seule les logs nous en diront sans doute plus…

A tout hasard, peux tu vider le cache de ton navigateur ? On ne sait jamais, typiquement si tu as réutilisé l’URL pour pointer sur différentes instances le navigateur ne s’y retrouve peut être pas…

Bonjour David,

il semble que les bases de données des différents environnements RFS soient un peu en vrac (pas du fait du runtime mais plutôt suite à des manipulations non maîtrisées - je suis passé par là aussi avec la BCSI donc je comprends).

Un point est en cours dans l’équipe en charge de ce référentiel pour résoudre au plus vite l’ensemble des problèmes constatés. Dans ce cadre, nous envisageons une hypothèse (parmi d’autres) de bascule de ces environnements vers MariaDB/MySQL pour repartir “à blanc” sur des bases saines et dans un contexte de mise en œuvre déjà éprouvé (sur BCSI).

NB1: Vois-tu des risques / problèmes / contre-indications qui se poseraient pour le cas particulier de RFS ? (comme par exemple une prise en compte spécifique des séquences PostGRE dans le cadre des calculs de identifiants)

NB2: Dans le cas où la décision de migrer vers MariaDB/PostGRE serait prise, nous envisagerions de migrer l’ensemble de nos environnements référentiels.

Bruno

Je ne vois pas en quoi MySQL/MariaDB serait plus “sain” que PostgreSQL. Au contraire.

MySQL est plus tolérant car moins rigoureux que PostgreSQL.

Il vaut mieux comprendre et corriger les pbs rencontrés plutôt qu’imaginer en atténuer les effets en utilisant une base de données trop tolérante !

Si c’est la seule raison pour basculer sur MySQL c’est une très mauvaise idée. S’il y a d’autres raisons techniques ou stratégiques je veux bien en discuter.

Merci pour ton retour rapide.

Il y a en effet d’autres raisons en discussion avec les équipes techniques concernant les moyens et les marges de manœuvre que nous avons sur les environnements PostGRE mis à notre disposition. La migration vers MariaDB/MySQL n’est qu’une option parmi d’autres. Tes retours et ton expertise sont bien entendu intégrés dans la réflexion.

Concernant l’implémentation actuelle des règles métier de RFS, vois-tu un point particulier qui devrait être considéré ?

Cela fait des mois que je ne sais pas ce qui est implémenté sur les référentiels… C’est plutôt a ceux qui sont en charge de ces implémentations de répondre.

Au niveau socle, exporter son paramétrage et ses données depuis une instance vers une autre ne pose pas de pb. Les row ID techniques seront forcément différents.

De mémoire il faut vous assurer que les identifiants métier unique seront bien préservés à l’import (i.e que le code spécifique de vos objets, qui génère ces identifiants, prévoit bien le cas de l’import).

Le mieux est sans doute de faire des tests préalables. Sur le SIM qu’on vous a mis a disposition vous pouvez créer des instances MariaDB je pense.

Juste pour mon information, c’est quoi les motivations techniques/organisationnelles du changement envisagé de base de données de PostgreSQL vers MySQL ? Au début il semblait que le choix de PostgreSQL était extrêmement important et non discutable… Quelle version de MySQL d’ailleurs ?

Ca ressemble à un nouveau post privé qui n’a plus rien à voir avec son titre…

Je confirme que vous pouvez créer des instances en MariaDB 5.5 (la version actuelle de la distribution Linux CentOS) sur votre SIM.

Si besoin je peux installer un MySQL community 8.0.16 à la place (dans ce cas ne créez pas d’instances MariaDB avant l’installation)