Je vous présente mes meilleurs vœux pour cette année 2022.
Quel est le mode opératoire pour installer un jar externe sur une V5.0 via l’instance manager ?
Simplicité version 4.0 patch level P25
Built on 2021-12-25 23:35
Je vous présente mes meilleurs vœux pour cette année 2022.
Quel est le mode opératoire pour installer un jar externe sur une V5.0 via l’instance manager ?
Simplicité version 4.0 patch level P25
Built on 2021-12-25 23:35
Plusieurs possibilités:
<Tomcat root>/webapps/ROOT/WEB-INF/lib
=> dans le cas du SIM ça peut se faire dans les script hooks ad hoc cf. Simplicité® documentation/90-operation/manager en l’occurrence les post-add.sh
et post-upgrade.sh
ATTENTION : quelque soit l’approche, ajouter des JARs n’est pas forcément trivial car il faut avant toute chose s’assurer de leur non incompatibilité avec les JARs déjà embarqués dans la plateforme au risque de rencontrer des pbs totalement incompréhensibles. En particulier il faut éviter comme la peste les JAR “bundles” (= “with-dependencies” dans le vocabulaire Maven) qui sont en fait la concaténation opaque de plusieurs JARs dont certains sont peut être en conflit => bref de quel JAR(s) parle-t-on ? Je pose la question pour faire les vérifications qui s’imposent
C’est un JAR pour faire un client SOAP basé sur un WSDL
Ca ne répond pas à la question
Pour vérifier la non incompatibilité de ce JAR (et de ses éventuelles dépendances) avec les JARs de la plateforme on besoin d’information précises:
Par ailleurs, s’il s’agit d’un JAR du marché qui pourrait potentiellement être réutilisé par d’autres clients, ça peut être intéressant qu’on l’intègre à la plateforme (car dans ce cas il sera maintenu à jour comme les autres JARs de la plateforme)
On a réussi à installer le JAR suite à ta procédure 2.
C’est un JAR “maison” contenant les class client du WSDL. On va vérifier si il n’y a aucun conflit.
Envoie moi en message privé la liste des classes contenues dans ce jar (genre unzip -l malib.jar
)
Je pourrai vérifier précisément vs la liste exhaustive des classes des libs des composants de la plateforme
NB: s’il s’agit d’une lib maison “standalone” la procédure 1 devrait fonctionner, vous l’avez essayée ?
C’est parti en message privé.
On a pas essayé le 1 ;-), on va essayer.
Je vois des libs embedded dans ce JAR qui sont dans des versions différentes de libs embarquées dans Simplicité:
J’ai aussi des inquiétudes sur la lib jaxrcp car il y a actuellement différentes implémentations concurrentes des JAX* et c’est parfois source de conflits subtils…
Il me faudrait le contenu du MANIFES.MF pour voir comment ces libs conflictuelles sont utilisées dans ce JAR (si c’est modularisé c’est isolé dans un classloader à part et ça ne posera à priori pas de pb)
Le MANIFEST :
Maniftest-version:2.0
Class-Path: \src\main\webapp\WEB-INF\lib*
Main-Class: \src\main\java
Ce n’est pas un packaging de type “module”.
Je ne sais pas trop comment le classloader gère le classpath interne de ce JAR mais je pense que l’ordre de chargement des classes risque d’être “aléatoire” avec des conséquences imprévisibles.
A minima il faudrait upgrader (ou retirer) les 2 libs en conflit dans le JAR (cf. les versions - à jour - de ces libs dans Simplicité)
NB: sur Maven central la dernière mise à jour de la lib Axis date de 2006, je ne suis pas sûr que ça soit la meilleure approche pour appeler du SOAP en 2022…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.