Erreur lors de la regénération des types après deploiement d'un nouveau WAR

Clément Tessier · le 26/01/16 à 09:42

Bonjour,

Je suis en train de tester le script de deploiement fourni par Jalios sur ma plateforme de recette mais j'obtiens des erreurs au redémarrage de tomcat pour chaque type qu'il essai de regénérer. Exemple de l'erreur pour le type PortletLogin :

09:35:05,022 INFO [JCMS] [TypeProcessor] - Type PortletLogin has been updated. Regenerate it.
09:35:05,024 ERROR [JCMS] [TypeProcessor] - java.io.FileNotFoundException: /usr/share/tomcat/webapps/sandbox/WEB-INF/jcmswork/templates_work/_0005fType_0005f$jsp.java (No such file or directory)
java.io.FileNotFoundException: /usr/share/tomcat/webapps/sandbox/WEB-INF/jcmswork/templates_work/_0005fType_0005f$jsp.java (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
at java.io.FileOutputStream.<init>(FileOutputStream.java:110)
at com.jalios.jspengine.compiler.Compiler.compile(Compiler.java:135)
at com.jalios.jspengine.TemplateEngine.render(TemplateEngine.java:121)
at com.jalios.jspengine.TemplateEngine.render(TemplateEngine.java:103)
at com.jalios.jspengine.TemplateEngine.render(TemplateEngine.java:83)
at com.jalios.jspengine.TemplateEngine.render(TemplateEngine.java:170)
at com.jalios.jcms.TypeProcessor.generateTemplate(TypeProcessor.java:1057)
at com.jalios.jcms.TypeProcessor.generateJavaClass(TypeProcessor.java:1043)
at com.jalios.jcms.TypeProcessor.generateTypeClass(TypeProcessor.java:660)
at com.jalios.jcms.TypeProcessor.step2GenerateResources(TypeProcessor.java:497)
at com.jalios.jcms.TypeProcessor.processTypes(TypeProcessor.java:293)
at com.jalios.jcms.Channel.<init>(Channel.java:700)
at com.jalios.jcms.Channel.initialize(Channel.java:931)
at com.jalios.jcms.ChannelInitServlet.init(ChannelInitServlet.java:117)
at com.jalios.jcms.ChannelInitServlet.init(ChannelInitServlet.java:81)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5027)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5314)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1114)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1673)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Avez-vous une idée quant à mon problème ? Merci d'avance. Cordialement,

16 pts
Frédéric Touitou - le 03/02/16 à 10:32
Meilleure réponse

Bonjour,

Ticket de support relatif à ce problème : Ticket 9827 - Packaging d'un nouveau WAR avec migration de version

Et résultats de l'analyse, pour partager avec la communauté : le problème (absence en réalité du répertoire /WEB-INF/jcmswork/, qui est normalement créé automatiquement lors du démarrage, s'il n'est pas trouvé...) était dû au système de droits de l'OS : certains répertoires et fichiers de la webapp appartenaient à "root" (avec des droits de modification très restreints, ce qui en soi est normal), différent de l'utilisateur exécutant tomcat, empêchant donc ce dernier de créer notamment ce fameux sous-répertoire /jcmswork...

10 pts
Olivier Jaquemet · le 27/01/16 à 17:57

Bonjour,

Premièrement, arrêtez JCMS, ensuite supprimer complètement le contenu du répertoire WEB-INF/jcmswork/

Je suppose que vous êtes dans en environnement utilisant un IDE, comme Eclipse, assurez vous que

  • que vous utilisez une JDK (pas une JRE)
  • que le répertoire WEB-INF/classes EST dans le repertoire source du projet (source folder)
  • que le répertoire WEB-INF/classes est utilisé comme destination des fichiers .class compilés par l'IDE (output folder), ce point est primordiale 
  • le répertoire WEB-INF/jcmswork/ n'est PAS dans les sources du projet, cela expliquerait la suppression des fichiers.
  • que les jar du répertoire WEB-INF/lib sont inclus dans le projet

Bon développement.

#3

Merci. Je n'ai pas accès à l'espace de mon client, je peux par contre accéder à l'Espace Partenaires. Pourrais-je obtenir des conseils ici ?

Peut-être que mon problème n'en est réellement pas un si il est évident que la procédure de déploiement standard Jalios ne permet pas de déployer un war JCMS 9 (migré de JCMS 8 à l'aide d'un jumbo patch) dans une webapp existante JCMS 8. Cependant, la procédure ne semble pas fournir de contre indication : https://community.jalios.com/jcms/jx_67249/fr/nouveau-systeme-de-deploiement : Les développeurs modifient la webapp (développements, ajout de modules de nouveautés applicatives, migration de version, ...).

Me confirmez-vous ce point ? Merci.

Clément Tessier · le 28/01/16 à 10:36
#4

Normalement la procédure de déploiement doit vous permettre de passer de 8 à 9.

A ce sujet je vous rappelle 3 ressources pour votre migration :

Si cela ne vous dépanne pas, votre problème est incident qui nécessite une prise en charge de support, suivie, avec une personne du support Jalios affectée à votre problème, ce que cet espace de conversation ne garanti pas.

Vous pouvez demander l'accès à l'espace support de votre client à l'animateur de cet espace ou éventuellement par mail au support Jalios.

Olivier Jaquemet · le 28/01/16 à 10:54
#5

D'accord, merci beaucoup pour votre aide. Je vais continuer d'investiguer et contacter mon client afin que nous puissions au mieux assurer la livraison de demain.

Merci. Cordialement,

Clément Tessier · le 28/01/16 à 10:57
0 pt