Votre question

Migration d'un site J2EE totalement impossible

Tags :
  • Jsp
  • Programmation
Dernière réponse : dans Programmation
10 Mars 2010 13:57:36

Bonjour à tous,

Je ne suis pas informaticien, mais je vous soumets un problème facheux rencontré lors de la migration du site Internet de la boite que je dirige.

Le site en question a été développé en 2005 par un informaticien freelance, en Java/JSP, puis hébergé chez Althosting. Ce prestataire cessant son activité, un nouvel hébergeur a été choisi : Nétissime.

Le site a donc été transféré sur les serveurs de Nétissime, mais un gros problème technique demeure : les pages .jsp ne sont pas du tout interprêtées. Le support technique (quasiment inexistant) de Nétissime a suggéré de créer un fichier .war et de le transférer sur leurs serveurs via leur inferface Parallels. Un ami informaticien a donc créé le fichier Copie_de_SAUV.war avec Netbeans et JDKquelquechose, et le fichier a été transféré avec succès, avec petite icone verte indiquant que l'application java Copie_de_SAUV.war fonctionne sur le serveur Tomcat de Nétissime.

Mais le back-office demeure toujours non fonctionnel depuis désormais une dizaine de jours, et ce à cause de deux problèmes :

1) La racine du nouveau site "compilé" n'est plus http://www.exemple.com/ mais http://www.exemple.com/Copie_de_SAUV/
Nétissime indique que rien ne peut être fait, et qu'il en est ainsi (magnifique solution au problème). Bien entendu, ce répertoire n'est que virtuel et non accessible via un FTP. Ce qui signifie que si nous souhaitons envoyer un nouveau fichier .jsp tel que clientlink.jsp, par exemple, dans le répertoire /FR, cela n'a aucun intérêt, puisque les .jsp de http://www.exemple.com/FR/clientlink.jsp ne sont pas interprétés, puisque la zone "compilée" est http://www.exemple.com/Copie_de_SAUV/FR/clientlink.jsp qui est une zone virtuelle non accessible par FTP.
Comme cela était le cas avec Althosting, je veux bien entendu pouvoir transférer les fichiers .jsp sur la zone "physique" du FTP, et que ces fichiers soient bien interprétés. Il faut que toute la structure du site soit à la racine, comme cela fut le cas avec Althosting.

2) Autre gros problème : même le répertoire virtuel correctement transféré ne fonctionne pas. Des erreurs 500 font systématiquement leur apparition. Exemples :
http://www.exemple.com/Copie_de_SAUV/FR/clientlink.jsp?...
http://www.exemple.com/Copie_de_SAUV/FR/connect.jsp

Le fait que les fichiers .jsp du site "normal" ne soient pas interprétés, comme vous l'imaginez, est, de son côté, du plus mauvais effet :
http://www.exemple.com/FR/clientlink.jsp?id_offer=15


Mon ami informaticien n'étant pas un spécialiste J2EE, ses compétences s'arrêtent là. L'informaticien ayant développé le back-office en 2005, de son côté, demande une somme déraisonnable pour résoudre le problème. Et me concernant, malgré un diplôme d'ingénieur (non informatique, je précise), mes connaissances de la programmation ne me permettent pas de résoudre le problème...

Bref, je compte sur votre expérience éclairée pour me dépatouiller de cette situation...

Mille mercis à vous !

Nicolas

Autres pages sur : migration site j2ee totalement impossible

10 Mars 2010 16:12:55

Citation :

1) La racine du nouveau site "compilé" n'est plus http://www.apoteosurprise.com/ mais http://www.apoteosurprise.com/Copie_de_SAUV/
Nétissime indique que rien ne peut être fait, et qu'il en est ainsi (magnifique solution au problème).


je suppose que le war est déployé sous tomcat.


si ton war s'appelle machin.war il est déployé dans le répertoire tomcat_home/webapps/machin/


les mecs ne t'ont pas menti, ils n'y peuvent rien.

pour le dépôt des jsp, repackage ton appli (refais un .war) et renvoie le a l'hébergeur. le contenu de ce war devra être ton appli (complete) et pas seulement les nvelles JSP










m
0
l
10 Mars 2010 16:35:27

Merci pour cette réponse, mais comment accéder au répertoire de Tomcat ?
Malheureusement, j'ignore comment un .war peut être packagé...
m
0
l
Contenus similaires
10 Mars 2010 18:04:56


tu package ton war avec netbeans comme l'a fait ton développeur.

honnêtement, je ne pense pas que tu obtienne un accès au répertoire de déploiement de tomcat.

Si tu peux, demande a ton ancien hébergeur de te faire un topo sur son hébergement, ca t'aidera a monter ta nouvelle plateforme.

Sinon le dev freelance d'origine a du te fournir un dossier d'install /exploit non ?


m
0
l
11 Mars 2010 10:30:06

L'ancien hébergeur ferme ses portes, et n'a donc pas forcément envie d'assister ses anciens clients...
Le développeur d'origine a simplement fourni une doc et un .zip contenant les fichiers .java
m
0
l
11 Mars 2010 11:48:15

certes ton ancien hébergeur qui coule n'a peut être pas envie d'aider ses anciens clients mais donner l'archi technique utilisée pour t'héberger, c'est pas la mer a boire.


Dans la doc du dev, il n'y a rien sur le déploiement de l'appli ?
m
0
l
11 Mars 2010 15:26:29

Si, la doc indique que le fichier à utiliser est exemple.jar
Il n'y a donc pas du tout de .war de prévu.
m
0
l
12 Mars 2010 11:48:08

bjr.

sur l'archi technique du serveur il n'y a rien ?

ni sur la méthode de déploiement ?
m
0
l
12 Mars 2010 15:08:57

Non, la doc indique simplement la chose suivante :

Le fait de modifier le fichier exemple.jar entraîne le redéploiement de l'application par le serveur. En
particulier, pour prendre en compte des modifications dans le fichier web.xml, il suffit de recharger le
fichier exemple.jar. La date de création du fichier ayant changé, l'application sera automatiquement
redémarrée par le serveur.
m
0
l
16 Mars 2010 15:58:18

Bonjour

il n'y a pas de description technique du serveur employé ?


m
0
l
Tom's guide dans le monde
  • Allemagne
  • Italie
  • Irlande
  • Royaume Uni
  • Etats Unis
Suivre Tom's Guide
Inscrivez-vous à la Newsletter
  • ajouter à twitter
  • ajouter à facebook
  • ajouter un flux RSS