JEE / Spring by gdufrene

Tomcat

Tomcat est un serveur web fournissant certaines spécifications JEE : Servlet, JSP + expression language, WebSockets.
Tomcat ne peut pas être considéré comme serveur d'applications JEE complet car il n'offre pas l'ensemble des composants définis dans les "profiles" standards. Il manque de nombreuses librairies, qui peuvent toutefois être embarquées par l'application à déployer.
Il manquera par exemple dans tomcat un moteur d'injection (Contexts and Dependency Injection), l'API standard permettant de réaliser des service REST facilement (JAX-RS), la définition de composant java (EJB), la gestion des transactions (JTA), la gestion de la persistance (JPA) ...
Nous embarquerons donc dans notre application web un ensemble de librairies implémentant certaines de ces fonctionnalités comme Spring, Spring-web-mvc ou Hibernate.
Les serveurs d'applications Java EE tels que JBOSS, WebSphere, Glassfish, Oracle Application Server apportent toutes ces librairies (inutile de les embarquer avec l'application) et facilite leur usage.

Pourquoi Tomcat ?
C'est un serveur web java relativement facile à prendre en main, il est très répandu et éprouvé, relativement léger et plutôt performant. Il fournit un ensemble de fonctions suffisantes pour mettre en oeuvre des applications web rapidement.

Lorsque vous décompressez tomcat vous trouverez la hiérarchie de répertoires suivante :

bin : scripts permettant de lancer / arrêter / redémarrer le serveur
conf : fichiers de configuration de tomcat
lib : les librairies dont tomcat a besoin et fournies à toutes les applications déployées.
logs : journal d'accès au serveur, sortie standard (System.out.println), autres fichiers de logs.
temp : fichiers temporaires générés par les applications si elles utilisent la variable d'environnement "java.io.tmpdir"
webapps : c'est ici que se trouvent les applications web déployées (un répertoire par contexte). Lorsque vous y déposez un fichier "war", celui ci est généralement décompressé automatiquement (dépend de la configuration tomcat). Cette décompression a lieu si un nouveau fichier war apparait ou si il est modifié (rechargement de contexte). Si le répertoire est déjà présent au lancement de tomcat, celui-ci n'essait pas de re-décompresser le war à ce moment là.
work : répertoire de "travail" dans lequel tomcat mettra un ensemble de fichiers utile à son fonctionnement. Peut être considéré comme du cache effaçable. On y trouvera par exemple les fichiers java et les classes générées par les fichiers JSP.

Pour lancer tomcat, rendez-vous dans "bin" et exécuter au choix :

startup.sh : lance tomcat en "arrière plan". La sortie standard est visible dans "logs/catalina.out". C'est la manière normale de lancer tomcat sur un serveur. Il peut ensuite être arrêté avec la commande shutdown.sh.
catalina.sh run : lance tomcat dans la console actuellement lancée et affiche les sorties standard à cet endroit. Je vous recommande ce mode lorsque vous développez. Il suffira ce faire [CTRL]+C pour arrêter tomcat.

Votre serveur est maintenant accessible à l'adresse http://localhost:8080/ (ou via n'importe quelle IP exposée par l'une de vos interfaces réseau LAN, WAN, VPN ...).
N'hésitez pas à consulter la documentation de tomcat si nécessaire.

Votre serveur se lance par défaut sur le port 8080, pour deux raisons :

Le port 80 est généralement utilisé par un serveur web plus "classique" comme apache httpd ou nginx
Il est nécessaire d'avoir les droits "root" pour ouvrir un port inférieur à 1024

Il reste évidemment possible de configurer tomcat pour le lancer sur le port 80 au besoin, mais en condition de "production" on place souvent un autre serveur web délivrant les fichiers "statiques" (images, js ...) permettant de décharger tomcat de ces traitements. Le lien pouvant se faire par le module "JK" ou par la mise en place d'un reverse proxy http... ces détails sont au delà de ce cours mais il vous serait utile de vous renseigner par vous-même.