Migration d'un site J2EE totalement impossible

[nicolasga]

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_SAU..&.../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_SAU...jsp?id_offer=15

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

[fabien29200]

Salut à toi !

Déjà une question me vient à l'esprit.

Est-ce un serveur dédié ? Avez-vous accès à la configuration de Tomcat ?

[Amour]

L'hébergeur est censé faire son travail... s'il n'y a pas de résultat vous pouvez porter plainte et demander remboursement etc...

Avant tout, pourquoi pas une bonne mise en demeure ?

[Yangzebul]

L'hébergeur est censé faire son travail... s'il n'y a pas de résultat vous pouvez porter plainte et demander remboursement etc...

Avant tout, pourquoi pas une bonne mise en demeure ?

L'hébergeur fourni une plateforme Java fonctionnelle et répondant à certaines spécifications pré-établies.

Il n'est pas du tout à sa charge d'assurer la MCO des applications que les clients n'arriveraient pas à migrer faute d'un manque de compétence ou d'une incompatibilité avec la plateforme.

Mon conseil : si le prestataire est trop cher, fait jouer la concurrence.

Ce n'est pas en postant sur tous les forums francophones que tu résoudra ton problème, c'est typiquement le genre de geste technique long et complexe impossible à faire sans avoir la main sur l'application.