TP d’applications web
Introduction aux servlets

On suppose que vous avez créé un projet web maven lors de la manip 2. Que vous l’ayez créé via Netbeans ou en ligne de commande, il comprend une hiérarchie de répertoires standardisée (accessible dans Netbeans via l’onglet « Files »). Certains répertoires peuvent ne pas être encore créés. Les répertoires sont :

• src contient tout le code source, les fichiers de configuration etc. :
  • src/main/java contient le code java, organisé dans une hiérarchie de répertoires correspondant aux paquetages, comme habituellement en java ;
  • src/main/webapp contient :
    • les pages web HTML et JSP qui seront accessibles directement par une URL correspondant à leur chemin d’accès ;
    • un dossier WEB-INF où placer des fichiers HTML et JSP qui ne seront pas accessibles directement par une URL ;
    • un dossier META-INF contenant le fichier de configuration principal context.xml.
• target contient tous les fichiers générés lors de la compilation (et peut être supprimé pour tout nettoyer si nécessaire).

Création d’un squelette java de servlet

On souhaite maintenant créer un servlet répondant à une certaine URL. Notre application, une fois déployée sur le serveur, possédera une URL racine, appelée context path, définie dans le fichier de configuration context.xml (un « context » est une application tournant sur le serveur). Par défaut il s’agit du nom du projet.

Lors du déploiement de l’application sur le serveur tomcat, celui-ci devra être informé des URL associées à chaque servlet afin de pouvoir gérer correctement les requêtes. Un servlet donné peut répondre à une ou plusieurs URL relatives au context path. Ces URL sont définies dans une annotation Java par des URL patterns.

Une annotation java est une ligne dans le code source java commençant par le caractère @ et contenant des métadonnées qui apparaîtront dans le fichier compilé .class ; ces métadonnées seront lues par tomcat lors du déploiement.

Les URL patterns suivent une syntaxe où / représente la racine de l’application et non du serveur : attention à ne pas confondre avec les liens hypertexte où / représente toujours la racine du serveur. Ainsi si vous indiquez comme pattern /first le servlet répondra à http://localhost:8080/nomduprojet/first par exemple.

Avec netbeans :

Cliquez à droite sur votre projet web dans netbeans et choisissez new puis servlet. Choisissez comme nom par exemple MonPremierServlet (ce sera le nom de la classe java créée) ; il faut également choisir un nom de paquetage (il s’agit d’un paquetage java standard). Vous devez indiquer ensuite quelle(s) URL ce servlet gérera, dans le champ URL Pattern(s). Ne cochez pas la case demandant à créer web.xml (ce fichier est une alternative aux annotations Java, et ici nous utilisons les annotations).

Netbeans génère alors un squelette pour votre classe servlet. Vous pouvez constater que cette classe hérite directement de HttpServlet et qu’une implémentation standard des deux méthodes principales doGet et doPost est proposée. Cette implémentation consiste à rediriger dans les deux cas vers une méthode processRequest de façon à traiter de la même manière les requêtes GET et POST. Vous pouvez voir que processRequest agit sur l’objet HttpServletResponse fourni par tomcat et fait deux choses : elle indique le type de contenu qu’elle va renvoyer avec setContentType puis envoie du code HTML ligne par ligne sur le flot de sortie de la réponse. L’effet est d’envoyer ce texte en réponse à la requête du client.

Vous pouvez tout de suite (re)déployer votre projet sur le serveur tomcat (flèche verte). Cependant vous pouvez voir que netbeans ouvre par défaut firefox sur l’URL racine de l’application, ce qui correspond à la page index.html. Pour vérifier que le servlet fonctionne, il faut tester son URL : http://localhost:8080/nomduprojet/first

N.B. : Après redéploiement, pensez toujours à rafraîchir la page dans le navigateur (netbeans rouvre la page dans firefox mais celui-ci a tendance à afficher la version en cache). Par ailleurs, si le redéploiement échoue ou si des comportements bizarres apparaissent, pensez à faire clean and build dans netbeans plutôt qu’un simple build. C’est notamment nécessaire si vous avez déplacé ou renommé certains fichiers .java, afin de supprimer les .class correspondant à l’ancien nom ou emplacement.

À la main

Vous pouvez aussi utiliser un autre IDE que Netbeans pour générer un squelette automatiquement (mais ce squelette sera probablement différent). Vous pouvez aussi vous inspirer de ceci (à créer dans le répertoire correspondant au nom de paquetage voulu) :

package lepackage; import javax.servlet.*; import javax.servlet.annotation.WebServlet; import javax.servlet.http.*; @WebServlet(urlPatterns = {"/first", "/second"}) // ici il répond à 2 URL public class MonServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { // à compléter } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { // à compléter } }

Traitement de données de formulaire

On souhaite avec ce servlet traiter des données de formulaire envoyées par la méthode POST. La méthode doGet ne sert donc à rien : supprimez-la de la classe, recompilez, redéployez et constatez que l’URL du servlet renvoie maintenant une erreur 405 si on la tape dans la barre d’adresse — car c’est une requête GET que le navigateur envoie dans ce cas.

Modifiez maintenant la page index.html pour y ajouter un formulaire ayant un champ texte et un bouton soumettre et qui renvoie les données saisies en POST vers le servlet.

Écrivez ensuite pour le servlet une méthode doPost qui récupère le contenu de ce champ texte et renvoie une page HTML contenant juste ce texte dans un paragraphe. Les données de formulaire sont placées par tomcat dans l’objet HttpServletRequest et accessibles par la méthode getParameter("nom du champ") (voir la javadoc).

Codage des caractères : Les données de formulaire peuvent contenir des caractères accentués et plusieurs codages différents sont utilisés sur le Web. Pour que tout se passe bien, il faut s’assurer que le même codage soit utilisé en écriture (par le navigateur) qu’en lecture (via l’objet HttpServletRequest). Le codage qu'on demande au navigateur d’utiliser est spécifié par l’attribut accept-charset de l’élément form. Le codage utilisé par l’objet HttpServletRequest est spécifié par sa méthode setCharacterEncoding. Le plus sûr est de spécifier "UTF-8" dans les deux cas.

Vous pouvez également envoyer les données de formulaire sur la sortie standard (System.out). Demandez à votre voisin d’accéder à votre page d’accueil et d’entrer un message, et vérifiez que ce message s’affiche dans la console dans netbeans. Ce qu’affiche netbeans se trouve dans le fichier log/catalina.out dans le répertoire de Tomcat (Remarque : la sortie standard ne devrait être utilisée que pour du débuggage.)