Le mauvaise exemple de certains fournisseurs ou développeurs :

Vous l'avez peut être compris en lisant cette documentation, une application Web que l'on dit utilisable sur un serveur de servlet 2.3 doit pouvoir être déployée sur n'importe produit respectant cette norme.

Malheureusement certaines sociétés ou développeurs, par manque d'expérience ou n'ayant pas bien saisi le concept des applications Web, transforment Tomcat en programme propriétaire quasiment impossible à maintenir autrement qu'en passant par eux.

Les conséquences :

• Un serveur Tomcat par application et en général par machine. Alors que Tomcat peut supporter des centaines d'applications dans la même installation et sur le même serveur sans conflits ni complications.


• Vous sortez d'une super formation sur Tomcat, vous avez tout compris. Quelques jours plus tard, vous allez vous lancez dans l'installation de votre première application Web que votre fournisseur viens de livrer. Et là, pas de chance, elle n'a rien à voir avec tous ce que vous venez d'apprendre.


• Le fournisseur vous dit que ce n'est pas grave, que c'est la meilleure façon de développer et que vous n'avez pas le choix. Comme il est gentil, il vous offre de vous vendre pour 3000 Euros de formations spécifiques pour maintenir son application.

Bien sûr, c'est un peu caricatural mais pourtant très proches de ce que j'ai pûs voir en clientèle.

Comment vérifier la conformité d'une application Web :

• Demandez à votre fournisseur, sur quels serveurs de servlets vous pouvez installer son application. Si il répond, uniquement sur Tomcat, sous Winchose, avec Sqqqqql krosoft, changez de fournisseur


• Vérifiez le livrable qui peut être sous forme d'archive ".war" ou de fichiers et répertoires respectant à peut près l'organisation décrite un peu plus haut. Les fichiers WAR s'ouvrent avec Winzip ou unzip.


• Normalement, aucun livrable ne devrait vous obliger à installer de fichiers dans les répertoires propres à tomcat (sauf dans des cas très précis). Les applications s'installent toutes sous le répertoire /usr/local/tomcat/webapps et disposent chacune de leur propre sous-répertoire.

Le déploiement :

Selon le format dans lequel est livré l'application et selon l'environnement, les méthodes diffères.

Le format des livrables :

• 1 - Un fichier .war


• 2 - Une arborescence de répertoire et fichiers


• 3 - Des sources avec un batch de compilation et de déploiement (build.sh, build.xml)

Déploiement d'un fichier War :

Si vous n'avez pas désactivé le déploiement automatique des applications .war dans server.xml, le simple fait de copier l'archive dans le répertoire "webapps" devrait déclencher son installation.

Si c'est une mise à jour, le nouveau contenu devrait remplacer l'ancien. Mais attention ce n'est pas si simple.

Je pourrais vous décrire une cinquantaine façon de déployer chaque application mais je vous conseille la suivante :

• Travaillez sur un Tomcat de test qui contient exactement les mêmes fichiers que celui de production.


• Demandez et lisez les consignes de déploiement livrés par le fournisseur.


• Stopper le serveur avant tout déploiement.


• Supprimez les fichiers java générés par une ancienne version de l'application. Répertoire /usr/local/tomcat/work/Standalone/localhost/examples pour l'application examples.


• Et la suite au prochain épisode car il faut que je revienne sur certains concepts pour bien aborder la question du déploiement.