3.6 Création d'une servlet
3.6.2 Classpath d'un projet Eclipse
Le Classpath d'une application Java est l'ensemble des dossiers et archives.jar explorées lorsque le compilateur la compile ou lorsque la JVM l'exécute. Ces deux Classpath ne sont pas forcément identiques, certaines classes n'étant utiles qu'à l'exécution et pas à la compilation. Le compilateur Java aussi bien que la JVM ont un argument qui permet de préciser le Classpath de l'application à compiler ou exécuter. De façon plus ou moins transparente pour l'utilisateur, Eclipse assure la construction et le passage de cet argument à la JVM.
Comment peut-on connaître les éléments du Classpath d'un projet Eclipse ? Avec l'option [<projet> / Build Path / Configure Build Path] :
Nous obtenons alors l'assistant de configuration suivant :
L'onglet (1) [Libraries] permet de définir la liste des archives .jar qui font partie du Classpath de l'application. Elles sont donc explorées par la JVM lorsque l'application demande une classe. Les boutons [2] et [3] permettent d'ajouter des archives au
Classpath. Le bouton [2] permet de désigner des archives présentes dans les dossiers des projets gérés par Eclipse alors que le
bouton [3] permet de désigner toute archive du système de fichiers de l'ordinateur. Ci-dessus on voit apparaître trois bibliothèques (Libraries) :
• [JRE System Library] : librairie de base pour les projets Java d'Eclipse :
3
2
1
• [Tomcat v5.5 runtime] : librairie apportée par le serveur Tomcat. Elle comporte les classes nécessaires au développement web. Cette librairie est incluse dans tout projet web d'Eclipse ayant été associé au serveur Tomcat.
C'est l'archive [servlet-api.jar] qui contient la classe [javax.servlet.http.HttpServlet], classe parent de la classe [ServletFormulaire] que nous sommes en train de créer. C'est parce que cette archive est dans le Classpath de l'application qu'elle a pu être proposée comme classe parent dans l'assistant rappelé ci-dessous.
Si ce n'avait pas été le cas, elle ne serait pas apparue dans les propositions de [2]. Si donc dans cet assistant, on veut référencer une classe parent et que celle-ci n'est pas proposée, c'est que, soit on se trompe dans le nom de cette classe, soit l'archive qui la contient n'est pas dans le Classpath de l'application.
• [Web App Libraries] rassemble les archives présentes dans le dossier [WEB-INF/lib] du projet. Ici il est vide :
Les archives du Classpath du projet Eclipse sont présentes dans l'explorateur de projets. Par exemple, pour le projet web [personne] :
L'explorateur de projets nous donne accès au contenu de ces archives :
2
1
Ainsi ci-dessus, on peut voir que c'est l'archive [servlet-api.jar] qui contient la classe [javax.servlet.http.HttpServlet].
3.6.3 Configuration de la servlet
Lectures [ref1] : chapitre 2 : 2.3, 2.3.1, 2.3.2, 2.3.3, 2.3.4Le fichier [WEB-INF/web.xml] sert à configurer l'application web :
Ce fichier, pour le projet [personne] est actuellement le suivant (cf page 32) : 1. <?xml version="1.0" encoding="UTF-8"?>
2. <web-app id="WebApp_ID" version="2.4" 3. xmlns="http://java.sun.com/xml/ns/j2ee"
4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
5. xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web- app_2_4.xsd">
6. <display-name>personne</display-name>
7. <welcome-file-list>
8. <welcome-file>index.html</welcome-file>
9. </welcome-file-list>
10.</web-app>
• l'existence de la servlet [ServletFormulaire] • les URL traitées par cette servlet
• des paramètres d'initialisation de la servlet
Le fichier web.xml de notre application personne sera le suivant : 1. <?xml version="1.0" encoding="UTF-8"?>
2. <web-app id="WebApp_ID" version="2.4" 3. xmlns="http://java.sun.com/xml/ns/j2ee"
4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
5. xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web- app_2_4.xsd">
6. <display-name>personne</display-name>
7. <servlet>
8. <servlet-name>formulairepersonne</servlet-name>
9. <servlet-class>
10. istia.st.servlets.personne.ServletFormulaire
11. </servlet-class>
12. <init-param>
13. <param-name>defaultNom</param-name>
14. <param-value>inconnu</param-value>
15. </init-param>
16. <init-param>
17. <param-name>defaultAge</param-name>
18. <param-value>XXX</param-value>
19. </init-param>
20. </servlet>
21. <servlet-mapping>
22. <servlet-name>formulairepersonne</servlet-name>
23. <url-pattern>/formulaire</url-pattern>
24. </servlet-mapping>
25. <welcome-file-list>
26. <welcome-file>index.html</welcome-file>
27. </welcome-file-list>
28.</web-app>
Les points principaux de ce fichier de configuration sont les suivants :
les lignes 7-24 sont liées à la présence de la servlet [ServletFormulaire]
lignes 7-20 : la configuration d'une servlet se fait entre les balises <servlet> et </servlet>. Une application peut comporter plusieurs servlets et donc autant de sections de configuration <servlet>...</servlet>.
ligne 8 : la balise <servlet-name> fixe un nom à la servlet - peut être quelconque
lignes 9-11 : la balise <servlet-class> donne le nom complet de la classe correspondant à la servlet. Tomcat ira chercher cette classe dans le Classpath du projet web [personne]. Il la trouvera dans [build/classes] :
lignes 12-15 : la balise <init-param> sert à passer des paramètres de configuration à la servlet. Ceux-ci sont généralement lus dans la méthode init de la servlet car les paramètres de configuration de celle-ci doivent être connus dès son premier chargement.
lignes 13-14 : la balise <param-name> fixe le nom du paramètre et <param-value> sa valeur.
les lignes 12-15 définissent un paramètre [defaultNom,"inconnu"] et les lignes 16-19 un paramètre [defaultAge,"XXX"]
lignes 21-24 : la balise <servlet-mapping> sert à associer une servlet (servlet-name) à un modèle d'URL (url- pattern). Ici le modèle est simple. Il dit qu'à chaque fois qu'une URL aura la forme /formulaire, il faudra utiliser la servlet formulairepersonne, c.a.d. la classe [istia.st.servlets.ServletFormulaire] (lignes 8-11). Il n'y a donc qu'une url acceptée par la servlet [formulairepersonne].
3.6.4 Le code de la servlet [ServletFormulaire]
La servlet [ServletFormulaire] aura le code suivant :1. package istia.st.servlets.personne; 2. 3. import java.io.IOException; 4. import java.io.PrintWriter; 5. 6. import javax.servlet.ServletConfig; 7. import javax.servlet.ServletException; 8. import javax.servlet.http.HttpServlet; 9. import javax.servlet.http.HttpServletRequest; 10. import javax.servlet.http.HttpServletResponse; 11.
12. @SuppressWarnings("serial")
13. public class ServletFormulaire extends HttpServlet { 14.
15. // paramètres d'instance
16. private String defaultNom = null; 17. private String defaultAge = null; 18.
19. // init
20. public void init() {
21. // on récupère les paramètres d'initialisation de la servlet 22. ServletConfig config = getServletConfig();
23. defaultNom = config.getInitParameter("defaultNom"); 24. if (defaultNom == null) 25. defaultNom = "NNNNNNNNNNNNNNN"; 26. defaultAge = config.getInitParameter("defaultAge"); 27. if (defaultAge == null) 28. defaultAge = "AAA"; 29. } 30. 31. // GET
32. public void doGet(HttpServletRequest request, HttpServletResponse response) 33. throws IOException, ServletException {
34.
35. // on récupère les paramètres du formulaire 36. String nom = request.getParameter("txtNom"); 37. if (nom == null) {
38. nom = defaultNom;
39. }
40. String age = request.getParameter("txtAge"); 41. if (age == null) {
42. age = defaultAge;
43. }
44. // on affiche le formulaire
45. response.setContentType("text/html"); 46. PrintWriter out = response.getWriter(); 47. out.println( 48. "<html>"+ 49. "<head>"+ 50. "<title>Personne - formulaire</title>"+ 51. "</head>"+ 52. "<body>"+ 53. "<center>"+ 54. "<h2>Personne - formulaire</h2>"+ 55. "<hr>"+
56. "<form action='' method='post'>"+ 57. "<table>"+
58. "<tr>"+
59. "<td>Nom</td>"+
60. "<td><input name='txtNom' value='"+nom+"' type='text' size='20'></td>"+ 61. "</tr>"+
62. "<tr>"+
63. "<td>Age</td>"+
64. "<td><input name='txtAge' value='"+ age +"' type='text' size='3'></td>"+ 65. "</tr>"+
66. "</table>"+ 67. "<table>"+ 68. "<tr>"+
69. "<td><input type='submit' value='Envoyer'></td>"+ 70. "<td><input type='reset' value='Rétablir'></td>"+ 71. "<td><input type='button' value='Effacer'></td>"+ 72. "</tr>"+ 73. "</table>"+ 74. "</form>"+ 75. "</center>"+ 76. "</body>"+ 77. "</html>" 78. ); 79. } 80. 81. // POST
82. public void doPost(HttpServletRequest request, HttpServletResponse response) 83. throws IOException, ServletException {
84. // on passe la main au GET 85. doGet(request, response); 86. }
87. }
A la simple lecture de la servlet, on peut constater qu'elle est beaucoup plus complexe que la page JSP correspondante. C'est une généralité : une servlet n'est pas adaptée pour générer du code HTML. Ce sont les pages JSP qui sont faites pour cela. Nous aurons l'occasion d'y revenir. Explicitons quelques points importants de la servlet ci-dessus :
- lorsqu'une servlet est appelée pour la 1ère fois, sa méthode init (ligne 20) est appelée. C'est le seul cas où elle est appelée.
- si la servlet a été appelée par la méthode HTTP GET, la méthode doGet (ligne 32) est appelée pour traiter la requête du client.
- si la servlet a été appelée par la méthode HTTP POST, la méthode doPost (ligne 82) est appelée pour traiter la requête du client.
La méthode init sert ici à récupérer dans [web.xml] les valeurs des paramètres d'initialisation appelés " defaultNom " et " defaultAge ". La méthode init exécutée au chargement initial de la servlet est le bon endroit pour récupérer le contenu du fichier [web.xml].
• ligne 22 : la configuration [config] du projet web est récupérée. Cet objet reflète le contenu du fichier [WEB- INF/web.xml] de l'application.
• ligne 23 : on récupère dans cette configuration la valeur de type String du paramètre appelé " defaultNom ". Ce paramètre aura pour valeur le nom d'une personne. S'il n'existe pas, on obtiendra la valeur null.
• lignes 24-25 : si le paramètre appelé " defaultNom " n'existe pas, on donne une valeur par défaut à la variable [defaultNom].
• lignes 26-29 : on fait de même pour le paramètre appelé " defaultAge ".
La méthode doPost renvoie à la méthode doGet. Cela signifie que le client pourra envoyer indifféremment ses paramètres par un POST ou un GET.
La méthode doGet :
ligne 32 : la méthode reçoit deux paramètres request et response. request est un objet représentant la totalité de la requête du client. Elle est de type HttpServletRequest qui est une interface. response est de type HttpServletResponse qui est également une interface. L'objet response sert à envoyer une réponse au client.
request.getParameter("param") sert à récupérer dans la requête du client la valeur du paramètre de nom param. Ligne 36, on récupère la valeur du paramètre " txtNom ", ligne 40 celle du paramètre " txtAge ". Si ces paramètres ne sont pas présents dans la requête, on obtient la valeur null comme valeur du paramètre.
lignes 37-39 : si le paramètre " txtNom " n'est pas dans la requête, on affecte à la variable " nom " le nom par défaut " defaultNom " initialisé dans la méthode init. Il est fait de même lignes 41-43 pour l'âge.
ligne 45 : response.setContentType(String) sert à fixer la valeur de l'entête HTTP Content-type. Cet entête indique au client la nature du document qu'il va recevoir. Le type text/html indique un document HTML.
ligne 46 : response.getWriter() sert à obtenir un flux d'écriture vers le client
lignes 47-78 : on écrit le document HTML à envoyer au client dans le flux d'écriture obtenu ligne 46. La compilation de cette servlet va produire un fichier .class dans le dossier [build/classes] du projet [personne] :
Le lecteur est invité à consulter l'aide Java sur les servlets. On pourra pour cela s'aider de Tomcat. Sur la page d'entrée de Tomcat 5, on a un lien [Documentation] :
Ce lien mène à une page que le lecteur est invité à explorer. Le lien sur la documentation des servlets est le suivant :