Travaux Dirigés 5

Travaux Dirigés 5
L’objectif de ce TD est de vous permettre de construire une fiche de Maintenance ainsi que de
définir les procédures à mettre en place lors d’une maintenance. Dans le but d’automatiser la
gestion de la maintenance, vous construirez une base de données hébergée sur un serveur http
avec des pages de saisies des configurations matérielles et logicielles et des pages de gestion
des incidents.
Exercice 21
Nous abordons maintenant le développement d'applications web dynamiques, c.a.d. des
applications dans lesquelles les pages HTML envoyées à l'utilisateur sont générées par des
programmes. Dans cet exercice vous trouverez un descriptif de manipulation d’Eclipse pour
créer une application web en Java. Ce descriptif utilise comme exemple un formulaire de
personne. Réalisez cet exercice et adaptez le à votre fiche de maintenance.
Création d'un projet web sous Eclipse
Nous allons développer une première application web avec Eclipse/Tomcat. Nous reprenons
une démarche analogue à celle utilisée pour créer une application web sans Eclipse. Eclipse
lancé, nous créons un nouveau projet :
que nous définissons comme un projet web dynamique :
Dans la première page de l'assistant de création, nous précisons le nom du projet [1] et son
emplacement [2] :
Dans la seconde page de l'assistant nous acceptons les valeurs par défaut :
La dernière page de l'assistant nous demande de définir le contexte [3] de l'application :
Une fois l'assistant validé par [Finish], Eclipse se connecte au site [http://java.sun.com] pour
récupérer certains documents qu'il veut mettre en cache afin d'éviter des accès réseau inutiles.
Une demande d'agrément de licence est alors demandée :
On l'accepte. Eclipse crée le projet web. Pour l'afficher, il utilise un environnement, appelé
perspective, différent de celui utilisé pour un projet Java classique :
La perspective associée à un projet web est la perspective J2EE. Nous l'acceptons pour voir...
Le résultat obtenu est le suivant :
La perspective J2EE est en fait inutilement complexe pour les projets web simples. Dans ce
cas, la perspective Java est suffisante. Pour l'obtenir, nous utilisons l'option [Window -> Open
perspective -> Java] :
•
•
•
src : contiendra le code Java des classes de l'application ainsi que les fichiers qui doivent
être dans le Classpath de l'application.
build/classes (non représenté) : contiendra les .class des classes compilées ainsi qu'une
copie de tous les fichiers autres que .java placés dans src. Une application web utilise
fréquemment des fichiers dits fichiers "ressource" qui doivent être dans le Classpath de
l'application, c.a.d. l'ensemble des dossiers qui sont explorés par la JVM lorsque
l'application fait référence à une classe, soit pendant la compilation soit à l'exécution.
Eclipse fait en sorte que le dossier build/classes fasse partie du c web. On place dans le
dossier src les fichiers "ressource" sachant qu'Eclipse les recopiera automatiquement dans
build/classes.
WebContent : contiendra les ressources de l'application web qui n'ont pas à être dans le
dans le Classpath de l'application.
WEB-INF/lib : contiendra les archives .jar dont a besoin l'application web.
•
•
Examinons le contenu du fichier [WEB-INF/web.xml] qui configure l'application [personne] :
Nous avons déjà rencontré de type de configuration lorsque nous avons étudié la création de
pages d'accueil précédemment. Ce fichier ne fait rien d'autre que de définir une série de pages
d'accueil. Nous ne gardons que la première. Le fichier [web.xml] devient le suivant :
Le contenu du fichier XML ci-dessus doit obéir aux règles de syntaxe définies dans le fichier
désigné par l'attribut [xsi:schemaLocation] de la balise d'ouverture <web-app>. Ce fichier est
ici [http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd]. C'est un fichier XML qu'on peut
demander directement avec un navigateur. Si celui-ci est suffisamment récent, il saura
afficher un fichier XML :
Eclipse va chercher à vérifier la validité du document XML à l'aide du fichier .xsd précisé
dans l'attribut [xsi:schemaLocation] de la balise d'ouverture <web-app>. Il va pour cela faire
un accès réseau. Si votre ordinateur est sur un réseau privé, il faut alors indiquer à Eclipse la
machine à utiliser pour sortir du réseau privé, appelée proxy HTTP. Cela se fait avec l'option
[Window -> Preferences -> Internet] :
On coche (1) si on est sur un réseau privé. Dans (2), on indique le nom de la machine qui
supporte le proxy HTTP et dans (3) le port d'écoute de celui-ci. Enfin dans (4), on indique les
machines pour lesquelles il ne faut pas passer par le proxy, des machines qui sont sur le même
réseau privé que la machine avec laquelle on travaille. Nous allons créer maintenant le fichier
[index.html] de la page d'accueil.
Création d'une page d'accueil
Nous cliquons droit sur le dossier [WebContent] puis prenons l'option [New -> Other] :
Nous choisissons le type [HTML] et faisons [Next] ->
Ci-dessus, nous sélectionnons le dossier parent [WebContent] en (1) ou en (2) puis nous
précisons en (3) le nom du fichier à créer. Ceci fait, nous passons à la page suivante de
l'assistant :
1Avec (1), nous pouvons générer un fichier HTML pré-rempli par (2). Si on décoche (1), on
génère un fichier HTML vide. Nous gardons la coche (1) afin de bénéficier d'un squelette de
code. Nous terminons l'assistant par [Finish]. Le fichier [index.html] est alors créé :
avec le contenu suivant :
Nous modifions ce fichier de la façon suivante :
Test de la page d'accueil
Si elle n'est pas présente, faisons apparaître la vue [Servers] avec l'option [Window - > Show
View -> Other -> Servers] puis cliquons droit sur le serveur Tomcat 5.5 :
L'option [Add and Remove Objects] ci-dessus permet d'ajouter / retirer des applications web
au serveur Tomcat :
Les projets web connus d'Eclipse sont présentés en (1). On peut les enregistrer sur le serveur
Tomcat par (2). Les applications web enregistrées auprès du serveur Tomcat apparaissent en
(4). On peut les désenregistrer avec (3). Enregistrons le projet [personne] :
puis terminons l'assistant d'enregistrement par [Finish]. La vue [Servers] montre que le projet
[personne] a été enregistré sur Tomcat :
Maintenant, lançons le serveur Tomcat et le navigateur web d’Eclipse puis demandons l'url
[http://localhost:8080/personne]. Cette url est celle de la racine de l'application web. Aucun
document n'est demandé. Dans ce cas, c'est la page d'accueil de l'application qui est affichée.
Si elle n'existe pas, une erreur est signalée. Ici la page d'accueil existe. C'est le fichier
[index.html] que nous avons créé précédemment. Le résultat doit être conforme ce qui était
attendu. Maintenant, prenons un navigateur externe à Eclipse et demandons la même url.
L'application web [personne] est donc connu également à l'extérieur d'Eclipse.
Création d'un formulaire HTML
Nous créons maintenant un document HTML statique [formulaire.html] dans le dossier
[personne] :
Pour le créer, on suivra la procédure décrite au paragraphe 3.2, page 33. Son contenu sera le
suivant :
Le code HTML ci-dessus correspond au formulaire ci-dessous :
n° type HTML nom code
Sauvegardons le document dans le dossier <personne>/WebContent. Lançons Tomcat si
besoin est. Avec un navigateur demandons l'URL http://localhost:8080/personne/formulaire.html :
L’architecture client/serveur de cette application basique est la suivante :
Le serveur web est entre l'utilisateur et l'application web et n'a pas été représenté ici.
[formulaire.html] est un document statique qui délivre à chaque requête du client le même
contenu. La programmation web vise à générer du contenu adapté à la requête du client. Ce
contenu est alors généré par programme. Une première solution est d'utiliser une page JSP
(Java Server Page) à la place du fichier HTML statique. C'est ce que nous voyons maintenant.
Création d'une page JSP
L'architecture client / serveur précédente est transformée comme suit :
Une page JSP est une forme de page HTML paramétrée. Certains éléments de la page ne
reçoivent leur valeur qu'au moment de l'exécution. Ces valeurs sont calculées par programme.
On a donc une page dynamique : des requêtes successives sur la page peuvent amener des
réponses différentes. Nous appelons ici réponse, la page HTML affichée par le navigateur
client. Au final, c'est toujours un document HTML que reçoit le navigateur. Ce document
HTML est généré par le serveur web à partir de la page JSP. Celle-ci sert de modèle. Ses
éléments dynamiques sont remplacés par leurs valeurs effectives au moment de la génération
du document HTML. Pour créer une page JSP, nous cliquons droit sur le dossier
[WebContent] puis prenons l'option [New -> Other] :
Nous choisissons le type [JSP] et faisons [Next] ->
Ci-dessus, nous sélectionnons le dossier parent [WebContent] en (1) ou en (2) puis nous
précisons en (3) le nom du fichier à créer. Ceci fait, nous passons à la page suivante de
l'assistant :
Avec (1), nous pouvons générer un fichier JSP pré-rempli par (2). Si on décoche (1), on
génère un fichier JSP vide. Nous gardons la coche (1) afin de bénéficier d'un squelette de
code. Nous terminons l'assistant par [Finish]. Le fichier [formulaire.jsp] est alors créé :
avec le contenu suivant :
La ligne 1 indique que nous avons affaire à une page JSP. Nous transformons le texte cidessus de la façon suivante :
Le document initialement statique est maintenant devenu dynamique par introduction de code
Java. Pour ce type de document, nous procèderons toujours comme suit :
• nous mettons du code Java dès le début du document pour récupérer les paramètres
nécessaires au document pour s'afficher. Ceux-ci seront souvent dans l'objet request.
Cet objet représente la requête du client. Celle-ci peut passer au travers de plusieurs
servlets et pages JSP qui ont pu l'enrichir. Ici, elle nous arrivera directement du
navigateur.
• le code HTML se trouve à la suite. Il se contentera le plus souvent d'afficher des
variables calculées auparavant dans le code Java au moyen de balises <%= variable
%>. On notera ici que le signe = est collé au signe %. C'est une cause fréquente
d'erreurs.
Que fait le document dynamique précédent ?
• lignes 6-9 : il récupère dans la requête, deux paramètres appelés [txtNom] et [txtAge]
et met leurs valeurs dans les variables [nom] (ligne 6) et [age] (ligne 8). S'il ne trouve
pas les paramètres, il donne aux variables associées des valeurs par défaut.
• il affiche la valeur des deux variables [nom, age] dans le code HTML qui suit (lignes
25 et 29).
Faisons un premier test. Lançons Tomcat si besoin est, puis avec un navigateur, demandons
l'URL http://localhost:8080/personne/formulaire.jsp. Le document formulaire.jsp a
été appelé sans passage de paramètres. Les valeurs par défaut ont donc été affichées.
Maintenant demandons l'URL
http://localhost:8080/personne/formulaire.jsp?txtNom=martin&txtAge=14 :
Cette fois-ci, nous avons passé au document formulaire.jsp, les paramètres txtNom et
txtAge qu'il attend. Il les a donc affichés. On sait qu'il y a deux méthodes pour passer des
paramètres à un document web : GET et POST. Dans les deux cas, les paramètres passés se
retrouvent dans l'objet prédéfini request. Ici, ils ont été passés par la méthode GET.
Création d'une servlet
Dans la version précédente, la requête du client était traitée par une page JSP. Lors du premier
appel à celle-ci, le serveur web, ici Tomcat, crée une classe Java à partir de cette page et
compile celle-ci. C'est le résultat de cette compilation qui au final traite la requête du client.
La classe générée à partir de la page JSP est une servlet parce qu'elle implémente l'interface
[javax.Servlet]. La requête du client peut être traitée par toute classe implémentant cette
interface. Nous construisons maintenant une telle classe : ServletFormulaire. L'architecture
client / serveur précédente est transformée comme suit :
Avec l'architecture à base de page JSP, le document HTML envoyé au client était généré par
le serveur web à partir de la page JSP qui servait de modèle. Ici le document HTML envoyé
au client sera entièrement généré par la servlet.
Création de la servlet
Sous Eclipse, cliquons droit sur le dossier [src] et prenons l'option de création d'une classe :
puis définissons les caractéristiques de la classe à créer :
Dans (1), on met un nom de paquetage, dans (2) le nom de la classe à créer. Celle-ci doit
dériver de la classe indiquée en (3). Il est inutile de taper soi-même le nom complet de celleci. Le bouton (4) permet l'accès aux classes actuellement dans le Classpath de l'application
web :
En (1) on tape le nom de la classe recherchée. On obtient en (2) les classes du Classpath
dont le nom contient la chaîne tapée en (1). Après validation de l'assistant de création, le
projet web [personne] est modifié de la façon suivante :
La classe [ServletFormulaire] a été créée avec un squelette de code :
La copie d'écran ci-dessus montre qu'Eclipse signale un [warning] sur la ligne déclarant la
classe. Cliquons sur l'icône (lampe) signalant ce [warning] :
Après avoir cliqué sur (1), des solutions pour supprimer le [warning] nous sont proposées
dans (2). La sélection de l'une d'elles provoque l'apparition dans (3) de la modification de
code que son choix va amener. Java 1.5 a amené des modifications au langage Java et ce qui
était correct dans une version antérieure peut désormais faire l'objet de [warnings]. Ceux-ci ne
signalent pas des erreurs qui pourraient empêcher la compilation de la classe. Ils sont là pour
attirer l'attention du développeur sur des points de code qui pourraient être améliorés. Le
[warning] présent indique qu'une classe devrait avoir un numéro de version. Celui-ci est
utilisé pour la sérialisation / désérialisation des objets, c.a.d. lorsqu'un objet Java .class en
mémoire doit être transformé en une suite de bits envoyés séquentiellement dans un flux
d'écriture ou l'inverse lorsqu'un objet Java .class en mémoire doit être créé à partir d'une
suite de bits lus séquentiellement dans un flux de lecture. Tout cela est fort éloigné de nos
préoccupations actuelles. Aussi allons-nous demander au compilateur d'ignorer ce warning en
choisissant la solution [Add @SuppressWarnings ...]. Le code devient alors le suivant :
Il n'y a plus de [warning]. La ligne ajoutée s'appelle une " annotation ", une notion apparue
avec Java 1.5. Nous complèterons ce code ultérieurement.
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
[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. Ainsi, on peut voir que
c'est l'archive [servlet-api.jar] qui contient la classe [javax.servlet.http.HttpServlet].
Configuration de la servlet au prochain TD…