Java EE Guide De Développement D'applications Web En
User Manual:
Open the PDF directly: View PDF .Page Count: 507
Java EE
Guide de développement d'applications web en Java
Jérôme LAFOSSE
Résumé
Ce livre sur le développement d’applications web en Java s’adresse à tout développeur qui souhaite disposer de tous les détails des différentes
étapes de réalisation d’une application web : l’analyse, la modélisation, le codage, la mise en production, les tests et la maintenance.
Le livre suit une démarche progressive et s’appuie sur une étude de cas d’un développement d’une boutique de vente en ligne. Il est découpé en
sept chapitres progressifs qui peuvent également être étudiés de manière autonome.
Le premier chapitre présente le langage Java, explique les règles de nommage et les bonnes pratiques à adopter lors des développements de
projets Java EE. Le chapitre 2 est consacré à la mise en place du serveur Java EE de référence, Tomcat, sous Windows et Linux. Les chapitres 3
et 4 explorent en détail les servlets et les JavaServer Page (JSP), en application avec l’étude de cas et le modèle MVC. Le chapitre 5 présente les
bases de données en Java EE et détaille la mise en place de JDBC et des technologies associées. Le chapitre 6 concerne le développement
Java EE à l’aide d’un framework. En accord avec les standards actuels en entreprise, Struts a été utilisé pour ce livre. Cependant les explications
sont valables pour d’autres frameworks Java (description des outils proposés par un framework Java tant en terme de validation de données que
d’approche MVC II).
Enfin, le dernier chapitre est consacré aux techniques avancées Java EE et permet de déployer un véritable projet sur un serveur en production à
partir d’un nom de domaine.
Le code lié à l’étude de cas traitée dans le livre est en téléchargement sur cette page.
L’auteur propose à ses lecteurs un lieu d’échanges via le site www.gdawj.com qui apporte également un certain nombre d’éléments
complémentaires (FAQ, outils, application déployée...).
L'auteur
Ingénieur en informatique et diplômé du CNAM, Jérôme Lafosse intervient comme consultant, concepteur et formateur sur les technologies
Java. Spécialiste des technologies web, il travaille à promouvoir les outils et solutions Open Source pour le développement de projets
Internet. Il enseigne également la plate-forme Java Entreprise Edition et la conception de projets Web en Licence et Master. Son expérience
pédagogique s'allie à ses compétences techniques et offrent au lecteur un guide réellement opérationnel sur le développement
d'applications web en Java.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI
© ENI Editions - All rigths reserved
- 1-
Avantpropos
La réalisation de sites Web passe par différentes étapes : l’analyse, la modélisation, le codage, la mise en production,
les tests et la maintenance. Toutes ces phases de conception sont longues, complexes et doivent être maîtrisées en
détail pour mener à bien les projets Internet. Pour ce type de projet, différents langages de programmation sont
utilisés comme PHP, Ruby, Perl, .NET ou Java. Java est reconnu actuellement comme l’un des meilleurs langages de
programmation objet pour la réalisation de projets Internet complexes avec son API spécifique, Java EE.
Ce guide détaillé suit une démarche progressive et vous aidera à créer des applications Web complexes et
fonctionnelles. Tous les concepts de la création d’un projet professionnel sont abordés dans ce livre, de la prise en
main du langage, à l’installation de l’environnement, à la configuration d’un serveur Web Java jusqu’à la création et la
mise en production d’un projet. Cet ouvrage permet de percevoir le développement d’applications Web en Java dans
sa globalité.
Mon objectif est de fournir un guide complet de développement d’applications Web en Java sur les deux principaux
environnements de développement que sont Windows et Linux, sans faire l’impasse sur une partie du cycle de
développement. Il s’agit d’explications et de conseils concrets, illustrés par une étude de cas réaliste de boutique de
vente en ligne.
Les lecteurs sont d’ailleurs invités à échanger via le site www.gdawj.com, véritable complément du livre puisqu’il
propose un exemple de l’application déployée, un forum de questions, des outils complémentaires pour le
développement d’applications web,etc.
© ENI Editions - All rigths reserved
- 1-
Organisation du guide
Le guide est divisé en sept chapitres spécifiques et autonomes :
●
Le chapitre 1 (Objectifs et spécifications de Java EE) présente le langage Java, les règles de nommage ainsi
que l’installation de l’environnement de développement.
●
Le chapitre 2 (Le serveur d’applications ApacheTomcat) est consacré à la mise en place du serveur Java de
référence, Tomcat.
●
Le chapitre 3 (Les JavaServer Page) aborde la programmation de Servlets avec les classes, objets et
méthodes.
●
Le chapitre 4 (Les Servlets) explore en détail le développement de pages Web au travers des pages JSP.
●
Le chapitre 5 (Java et les bases de données) présente les bases de données en Java ainsi que les solutions
techniques et les outils adaptés à la persistance des données.
●
Le chapitre 6 (Framework Java EE) est consacré à l’étude d’un framework de développement Java nommé
Struts.
●
Le chapitre 7 (Techniques avancées) est dédié aux techniques avancées en développement Java EE.
© ENI Editions - All rigths reserved
- 1-
À qui s’adresse ce guide ?
Que vous ayez peu de connaissances en développement Web ou que vous soyez un expert Java EE, ce guide a pour
objectif de vous présenter en détail et de façon exhaustive, toutes les étapes de réalisation d’applications Internet à
partir d’un projet concret mais facilement portable. Au cours de mes études et de mon parcours professionnel, j’ai
étudié les langages du Web, l’installation d’un serveur Java, la mise en œ uvre d’un framework, les bases de données
pour Internet, les Servlets/JSP et le développement de projets mais aucun ouvrage ne regroupait tous ces aspects de
conception et certaines parties importantes n’étaient pas détaillées, comme s’il manquait quelques clés essentielles qui
ne s’acquièrent qu’avec l’expérience. La démarche pédagogique de ce guide est de ne pas faire l’impasse sur des
points essentiels d’un projet Web comme le déploiement sur un serveur en production avec un nom de domaine, la
mise en place d’un pool de connexion sur une base de données quelconque ou encore la configuration complète d’un
serveur Java. L’ouvrage utilise pour cela une mise en page adaptée afin de mettre en valeur les concepts essentiels à
partir de schémas, graphiques, etc.
© ENI Editions - All rigths reserved
- 1-
Les conventions
1. Les conventions du guide, de Java, de codage et les règles de nommage
Dans le cycle de vie d’un produit logiciel, la phase de maintenance représente la majeure partie du temps (environ 80
%). De même, un logiciel est rarement développé par une seule et même personne. C’est une équipe entière qui
réalise le projet de développement avec tous les avantages mais aussi toutes les contraintes que cela implique.
La réussite d’un projet dépend beaucoup de l’homogénéité dans le codage. Cette étape essentielle passe par la mise
en œ uvre de conventions strictes respectées par toute l’équipe impliquée dans le projet. La plupart des outils de
développement (IDE) proposent des fonctionnalités pour permettre cette homogénéité mais il existe des règles que
seuls les développeurs doivent appliquer. Le fait de vouloir à tout prix avoir un code esthétique et de faible
complexité peut être un frein aux performances. À l’inverse, la course à la performance peut découler sur un code peu
lisible. Il revient donc aux développeurs de trouver le bon équilibre entre les conventions et les contraintes du projet
(projet axé sur la performance, projet OpenSource...).
2. Les conventions du guide
Tout au long de ce guide seront utilisées des conventions pour la rédaction des explications, les parties de code, les
rappels et les résumés. Les explications seront rédigées sous format textuel et graphique avec un maximum de
clarté. Les parties de code seront bien différenciées par la police de caractères et seront encadrées. Les schémas
viendront appuyer une explication et permettront d’expliquer sous forme graphique une convention, un choix, une
spécification ou un exemple.
3. Les conventions de codage
Des conventions de codage sont utilisées tout au long de ce document. Par défaut, les conventions de codage pour la
plupart des projets OpenSource suivent ces instructions. Par exemple, si la parenthèse { est après la condition if, le
code n’est pas correct.
Tous les blocs de code doivent commencer par une nouvelle ligne.
public class MaClasse
{
public void maMethode()
{
if (xxx)
{
}
}
}
Chaque conditionnelle contient les parenthèses ouvrantes et fermantes.
//Correct
if (expression)
{
//le code
}
//Incorrect
if (expression)
//le code
Une indentation se trouve après chaque instruction. Les noms des fonctions et des paramètres, ne doivent pas avoir
de préfixe, commencent par une minuscule et chaque partie de mot est en majuscule.
public class MaClasse
{
private String maChaine;
public void maMethode(String monParametre)
{
}
© ENI Editions - All rigths reserved
- 1-
}
La version de l’application (du code) est précisée dans chaque fichier d’extension .java.
@version 2.8
Le nom de l’auteur est précisé.
@author jeromelafosse
Chaque importation de paquetage (paquet) Java est pleinement qualifiée.
//Correct
import java.util.Date;
import java.net.HttpURLConnection;
//Incorrect
import java.util.*;
import java.net.*;
4. Les conventions Java
Pour utiliser efficacement le langage de programmation Java, il existe plusieurs conventions à connaître et à
appliquer. Les instructions Java se terminent par un pointvirgule. Les instructions Java utilisent des accolades { }
pour indiquer le début et la fin du corps. Un corps peut contenir plusieurs instructions.
La présentation avec les accolades alignées sur la même colonne que le premier caractère de l’instruction Java sera
utilisée. Cette présentation ajoute des lignes de code, mais elle est plus facile à lire. Il est important de mettre en
retrait (espace ou tabulation) les instructions Java qui comportent un corps. Il est également nécessaire de toujours
utiliser la même mise en retrait du code.
Java recourt comme tout langage à plusieurs motsclés, c’estàdire des mots réservés exclusivement au langage. Il
ne sera donc pas possible d’utiliser ces motsclés comme noms ou valeurs de variables.
Voici une liste non exhaustive de ces motsclés : abstract, boolean, break, case, catch, char, class, continue, do, double,
else, extends, false, final, finally, float, for, if, import, instanceof, int, interface, new, null, package, private, protected, public,
return, static, super, switch, this, true, try, void, while...
Le code doit être succinct, cela facilite la maintenance et la lisibilité de l’ensemble. Il vaut mieux découper parfois des
méthodes et ajouter des commentaires. Les recommandations doivent être appliquées sur l’intégralité du projet et
non avec parcimonie. Si les règles sont plus ou moins appliquées, si le code change d’un fichier à l’autre, la
compréhension sera difficile. L’application uniforme des règles est un gage de maintenabilité.
Fichiers
Les noms des fichiers sources portent l’extension .java et le code (bytecode) généré porte l’extension .class. Les
fichiers de propriétés portent l’extension .properties (langues, traductions...) et les fichiers de configuration
l’extension .xml. Le fichier de construction du projet porte le nom build.xml (Ant) et le fichier de description du projet
est appelé README.
Un projet de développement utilise plusieurs répertoires. Il est généralement composé du répertoire /src qui contient
les sources, du répertoire /build qui contient les classes compilées, /docs qui contient la documentation du projet
et /log qui contient les traces d’exécutions et d’erreurs du projet.
Souvent, pour un projet minime, seuls les répertoires /src, /build et /docs sont utilisés.
Les classes doivent être regroupées en packages (paquetages ou paquets).
Sources
Il est recommandé de ne pas dépasser 2000 lignes de code par fichier. Si tel est le cas, il est important d’optimiser le
code, de vérifier s’il n’existe pas de redondance et de découper les fonctionnalités en plusieurs classes (boîte à outils
par exemple).
Formatage
Il faut configurer l’éditeur pour que la tabulation écrive huit caractères espace (configuration par défaut). L’entrée
dans un bloc impose l’ajout d’une indentation. Des blocs de même niveau doivent débuter sur la même colonne, c’est
àdire avoir la même indentation. Les lignes blanches doivent être utilisées pour séparer des portions de code et les
méthodes. Les espaces peuvent être utilisés en quantité mais sous certaines conditions. Le caractère espace est
- 2-
© ENI Editions - All rigths reserved
proscrit avant les pointsvirgules, avant les crochets des tableaux et entre une variable et les opérateurs de pré/post
incrément. Par contre, l’espace est autorisé après les virgules, avant et après les accolades, avant et après chaque
opérateur, après les mots réservés du langage et entre le nom d’une méthode et la parenthèse de ses paramètres.
//Correct
maMethode (a, b, c, d);
for (i = 0; i < 100; i++) {
++count;
(MaClasse)maVariable.get(i);
//Incorrect
MaMethode (a,b,c,d);
++ count;
(MaClasse) maVariable.get(i);
Nommage
Les noms utilisés doivent être explicites, c’estàdire que le nom doit expliquer le contenu de l’objet, le rôle de la
méthode... Les acronymes qui apparaissent dans les noms doivent être passés en minuscules (sauf la première lettre
du premier mot). Il est conseillé de mettre les identifiants en langue anglaise pour des projets internationaux.
Package/Paquetage
Les noms des paquetages doivent être en minuscules. Ces noms doivent être pleinement qualifiés (comme une URL)
et reprennent le nom du projet, l’URL du site... En général, la technique consiste à retourner l’URL du projet.
Exemple : monprojet.com devient : com.monprojet.monpaquet
//Correct
package com.monprojet.monpaquet;
//Incorrect
package Com.MonProjet.MonPaquet;
Classes et interfaces
Les noms des classes doivent être en minuscules, hormis les initiales des mots qui les composent.
//Correct
class MaClasseFavorite;
//Incorrect
class maclassefavorite;
class maClassefavorite;
Méthodes
Les noms des méthodes doivent être en minuscules hormis les initiales des mots qui composent les mots (sauf la
première lettre).
//Correct
public void maMethodeFavorite() {
//Incorrect
public void mamethodefavorite() {
Les accesseurs directs (getters et setters) des attributs d’une classe doivent être préfixés d’un get pour la lecture de
l’attribut et d’un set pour l’écriture. Le préfixe is doit être utilisé pour les méthodes qui retournent un booléen.
//Correct
public int getNiveau() {
public void setNiveau(int niveau) {
public boolean isVisible() {
//Incorrect
public int recupererLeNiveau() {
public void ecrireLeNiveau(int niveau) {
public boolean estIlVisible() {
Nous pouvons également utiliser d’autres mots pour les recherches, les suppressions, les ajouts, la fermeture de
connexions... (find, delete, add, close...).
© ENI Editions - All rigths reserved
- 3-
Attributs, variables et paramètres
Les attributs des classes , les variables ainsi que les paramètres des méthodes doivent être en minuscules hormis les
initiales des mots qui les composent (sauf le premier). Les variables de boucle doivent porter une seule lettre : i, j, k...
Les signes dollars ($) et soulignement (_) sont proscrits.
//Correct
Voiture prochaineVoiture = voitures.get(this.id + 1);
float laTaille = 145.5;
//Incorrect
Voiture a = voitures.get(this.id + 1);
float la_Taille = 145.5;
Les collections doivent être nommées au pluriel.
//Correct
Vector comptes;
Collection banques;
Object[] mesObjets;
//Incorrect
Vector compte;
Collection banque;
Object[] monObjet;
Constantes
Les noms des constantes doivent être écrits entièrement en majuscules. Le séparateur de mot est le caractère de
soulignement (underscore).
//Correct
static final
//Incorrect
static final
static final
static final
int LOG_CONSOLE = 1;
int LOGCONSOLE = 1;
int console_Log = 1;
int Console_LOG = 1;
Commentaires
Les commentaires sont essentiels dans un code source. Ils permettent de documenter le projet à l’intérieur même du
code source en vue de la génération de la documentation via l’outil JavaDoc. Il existe en Java deux types de
commentaires :
●
les commentaires monoligne qui permettent de désactiver tout ce qui apparaît sur la même ligne // ;
●
les commentaires multilignes qui permettent de désactiver tout le code qui se trouve entre les deux
délimiteurs /* */.
Il est important de réserver les commentaires multilignes aux blocs utiles à la JavaDoc et à l’inactivation de portions
de code. Les commentaires monoligne permettent de commenter le reste, à savoir, toute information de
documentation interne aux lignes de code.
/*
* La classe MaClasse permet telles fonctionnalités…
*/
public class MaClasse() {
// Recuperer un objet de la collection
monFichier = (Fichier)fichiers.get((int)item.getIdFichier());
Déclarations
Les variables doivent être déclarées ligne par ligne. L’initialisation doit se faire lors de la déclaration lorsque cela est
possible. Les variables doivent être déclarées au plus tôt dans un bloc de code. Les noms des méthodes sont accolés
à la parenthèse ouvrante listant leurs paramètres. Aucun espace ne doit y être inséré.
//Correct
int niveau = 10;
void maMethode() {
- 4-
© ENI Editions - All rigths reserved
//Incorrect
int niveau;
niveau = 10;
void maMethode () {
Ordre
L’ordre de déclaration des entités du code source doit être le suivant (qui est plus ou moins naturel) :
●
Les attributs de la classe (1> statiques, 2>publiques, 3>protégés, 4> privés).
●
Les méthodes de la classe (1>statiques, 2>publiques, 3>protégées, 4>privées).
Instructions
Une ligne de code ne peut contenir qu’une seule instruction.
//Correct
count++;
i--;
println("Bonjour");
//Incorrect
count++; i--; println("Bonjour");
© ENI Editions - All rigths reserved
- 5-
Définitions de J2EE/Java EE
De nombreuses possibilités existent pour réaliser des applications Internet depuis plusieurs années. Des langages ont
été créés, des architectures et des environnements de travail ont été conçus pour répondre aux besoins et faciliter la
tâche des développeurs. Sun (le concepteur de Java) a donc mis en place un ensemble de technologies pour réaliser
des applications Web. Ces technologies sont regroupées sous le nom J2EE (Java 2 Entreprise Edition), désormais Java
EE.
Depuis la version 5, le chiffre 2 a disparu pour faciliter la compréhension de la version et ne pas mélanger le
chiffre 2 avec le numéro de version.
La plateforme Java EE s’appuie entièrement sur le langage Java. Java EE est donc une norme, qui permet à des
développeurs, entreprises et SSII de développer leur propre application qui implémente en totalité ou partiellement les
spécifications de SUN. En simplifiant, il est possible de représenter Java EE comme un ensemble de spécifications d’API,
une architecture, une méthode de packaging et de déploiement d’applications et la gestion d’applications déployées sur
un serveur compatible Java.
Une API est un ensemble de librairies ou bibliothèques de fonctions destinées à être utilisées par les
programmeurs dans leurs applications.
Java Entreprise Edition est destiné aux gros (très gros) systèmes d’entreprises. Les librairies utilisées fonctionnent
difficilement sur un simple PC et requièrent une puissance beaucoup plus importante (notamment au niveau de la
mémoire).
Java Entreprise Edition est apparue à la fin des années 90. Cette évolution apporte au langage Java une plateforme
logicielle robuste et complète pour le développement. La plateforme Java EE a souvent été remise en cause, mal
utilisée et mal comprise. Des outils OpenSource sont venus la concurrencer. Ces remarques et la concurrence ont permis
à Sun d’améliorer son produit et d’éditer des versions de plus en plus abouties. Java EE ne remplace en aucun cas J2SE.
Au contraire, J2SE est la base de Java EE qui est plus complet et qui est axé sur le Web. La plateforme J2SE offre des
outils de développement d’applications client/serveur, applications graphiques fenêtrées et Applets.
La plateforme J2SE est composée des éléments suivants :
●
La machine virtuelle Java (JVM) : permet d’exécuter des applications Java. Elle constitue une passerelle et
permet une portabilité entre les architectures (Windows, Linux, Mac...).
●
La bibliothèque de classes Java : un ensemble de composants logiciels prêt à l’emploi.
●
Les outils de développement : le compilateur javac , un interpréteur Java nommé java, le générateur de
documentation javadoc, la console de supervisation Jconsole... La plateforme Java EE est une extension de la
plateforme J2SE. Elle permet un développement d’applications qui vont s’exécuter sur un serveur d’applications.
Les applications seront utilisées par des clients légers (comme des navigateurs Web) ou bien des applications
lourdes (IHM). La dernière version stable de Java EE est la version Java EE 5.0 et fonctionne avec le JDK 5.0 et
6.0.
1. Pourquoi choisir Java EE
Il existe actuellement beaucoup d’autres platesformes de développement qui sont basées sur d’autres langages (C#,
PHP5, .NET...). Les principaux avantages d’utiliser Java EE (et donc Java) sont la portabilité, l’indépendance, la sécurité
et la multitude de librairies proposées.
Le développement d’applications d’entreprise nécessite la mise en œ uvre d’une infrastructure importante. Beaucoup
de fonctionnalités sont utilisées et développées, le but étant de produire des applications sûres, robustes et faciles à
maintenir. Certains services sont d’ailleurs récurrents comme : l’accès aux bases de données, l’envoi de mails, les
transactions, la gestion de fichiers, la gestion d’images, le téléchargement, le chargement ou upload, la supervision du
système...
C’est pour cela que l’architecture Java EE est intéressante car tous les éléments fondamentaux sont déjà en place.
Pas besoin de concevoir une architecture , des librairies et des outils spécialement adaptés. Cela nécessiterait un
temps et un investissement considérables.
Enfin, la plateforme Java EE est basée sur des spécifications, ce qui signifie que les projets sont portables sur
n’importe quel serveur d’applications conforme (Tomcat, JBoss, WebSphere...) à ces spécifications. Cette
implémentation est gratuite et permet de bénéficier de la totalité de l’API sans investissement. La plateforme Java EE
est la plus riche des platesformes Java et offre un environnement standard de développement et d’exécution
d’applications d’entreprise multitiers.
© ENI Editions - All rigths reserved
- 1-
Le fait que Java EE soit standardisé a contribué à son adoption par de très nombreux éditeurs de logiciels/outils
informatique. Ces éditeurs associés à Sun Microsystems font partie du JCP (Java Community Process). Le Java
Community Process regroupe les entreprises suivantes : Sun, IBM, Oracle, Borland, Nokia, Sony, la fondation Apache,
ObjectWeb... L’objectif du JCP est de définir les spécifications des technologies basées sur Java.
Chaque demande de modification est appelée une JSR (Java Specification Request).
2. L’API Java EE (JDBC, Servlets, JSP)
La plateforme Java EE est composée de plusieurs API (ensemble de libraires et services). Java EE fait intervenir trois
types de composants logiciels (Servlets, JSP, EJB).
a. Les Servlets
L’API Servlet fournit les éléments nécessaires à la conception de composants Web dynamiques avec le langage Java.
Les Servlets sont des composants logiciels entièrement écrits en Java. Les Servlets effectuent des traitements côté
serveur en réponse aux requêtes des clients distants. Une Servlet est chargée en mémoire lors de son premier
appel. De même, il n’existe qu’une seule instance d’une Servlet en mémoire, le serveur utilise alors un thread global
pour traiter les demandes émises par les clients.
Cycle de vie d’une Servlet
Une Servlet est une classe Java. Cette classe doit être chargée puis interprétée par une machine virtuelle Java (celle
du serveur d’applications). La Servlet est alors prête à recevoir des requêtes et à renvoyer des réponses. Lorsque
l’application ou le serveur s’arrête, la Servlet est détruite, puis son instance est nettoyée par le ramassemiettes de
la machine virtuelle.
Les Servlets permettent de développer des pages dynamiques, dont le contenu est créé à la volée sur demande.
C’est le cas par exemple, lorsqu’un client souhaite obtenir la liste des articles d’une boutique pour une plage de prix.
Les pages HTML sont alors générées dynamiquement en fonction de critères spécifiques (prix, dates, recherches...).
Une Servlet est un composant Java qui implémente l’interface javax.servlet.Servlet. Cette interface permet de gérer
les requêtes du client, dirigées vers la Servlet en question. Le serveur reçoit une demande adressée à une Servlet
sous la forme d’une requête HTTP. Il transmet alors la requête à la Servlet concernée par le traitement puis renvoie
la réponse fournie par celleci au client. La Servlet est gérée par le conteneur de Servlets Java EE. Lorsque le serveur
Web reçoit la requête du client, il charge la Servlet (si elle n’est pas encore chargée) et invoque l’interface
javax.servlet.Servlet afin de satisfaire la requête.
- 2-
© ENI Editions - All rigths reserved
Ce type de programmation est très proche du développement CGI mais offre les outils pour gérer les cookies,
sessions, accès aux bases de données et autres avec une excellente portabilité.
Exemple de Servlet simple :
public class PremiereServlet extends HttpServlet
{
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, java.io.IOException
{
}
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, java.io.IOException
{
doGet(request, response);
}
}
b. Les JSP (Java Server Page)
L’API JSP permet de développer des pages Web dynamiques rapidement à partir d’un squelette HTML et de données
incluses directement dans chaque page. Les JSP permettent d’insérer des bouts de code Java (scriptlets)
directement dans le code HTML.
Du point de vue de la structure, une JSP est très proche d’une page PHP ou bien ASP. Une page JSP est un fichier qui
porte l’extension .jsp ou .jspf (pour les fragments de code).
Lors de la création de Servlets, le but est de construire des composants capables de produire un service
(essentiellement du code HTML). Toutefois, ce principe est parfois complexe pour des personnes qui ne sont pas
habituées à la programmation objet et au code 100% Java. C’est pour ces raisons que les développeurs de chez
SUN ont inventé JSP.
La page JSP est transformée en classe Java puis compilée en Servlet par le serveur d’applications. Ce traitement est
réalisé par le serveur d’applications au premier appel de la page et à chaque fois que cette page est modifiée par un
programmeur.
C’est cette étape qui nécessite un serveur d’applications Java EE, un compilateur Java et qui par conséquent
nécessite pour la majorité l’installation de Java avec un JDK plutôt qu’un JRE.
Cycle de vie d’une JSP
© ENI Editions - All rigths reserved
- 3-
Le résultat de la compilation (essentiellement du code HTML) est renvoyé au client. Cette technologie est simple,
légère et rapide. Les développeurs de pages JSP peuvent ainsi mélanger du contenu statique et du contenu
dynamique.
<%
System.out.println("Ma première Servlet");
out.println("Ma première Servlet");
%>
Il est donc possible d’avoir des équipes de développement séparées avec une personne spécialiste de HTML/XHTML
et du design et un programmeur Java qui réalise les scriptlets. Les JSP sont exécutées sous la forme de Servlets,
elles disposent donc des mêmes fonctionnalités que cellesci et peuvent ainsi manipuler les sessions, les bases de
données, les mails...
- 4-
© ENI Editions - All rigths reserved
c. LES EJB (Entreprise Java Bean)
Les EJB sont des composants métier distribués, c’estàdire qu’ils sont invocables par le réseau. Un composant EJB
est une classe qui possède des attributs et méthodes pour mettre en application la logique métier. L’API EJB fournit
un ensemble de services (persistance, transaction...) de gestion de composants. Il existe plusieurs (trois) types
d’EJB : les beans sessions, les beans entités et les beans contrôlés par message.
●
EJB session : il permet de maintenir des informations sur les clients et les traitements qu’ils réalisent.
●
EJB entité : c’est un composant persistant, son état est sauvegardé dans une base de données.
●
EJB piloté par message : les EJB message sont semblables aux EJB session mais sont invoqués différemment
(par le biais de Java Message Service).
La mise en place d’EJB nécessite l’utilisation d’un serveur d’applications capable de gérer ces EJB.
Actuellement, les serveurs GlassFish, JBoss et Jonas existent dans le domaine du libre. Le serveur Tomcat ne
permet pas d’utiliser les EJB.
Il existe ensuite au sein de Java EE, la plateforme de Services avec JDBC, JNI, JavaMail, JTA, RMI, JAAS et XML.
JDBC (Java DataBase Connectivity)
L’API JDBC permet de faciliter l’obtention de connexions JDBC vers des sources de données (essentiellement des
bases de données, mais également annuaire...). L’API fournit les librairies pour se connecter aux bases de données
et pour la gestion des transactions.
JNDI (Java Naming and Directory Interface)
L’API JNDI permet d’accéder à des services de nommage ou d’annuaire (LDAP par exemple). Cette API est par
exemple utilisée pour se connecter à une source de données pour des accès à la base de données ou la gestion des
accès (associée aux Realms). JNDI permet d’implémenter un service de nommage. L’ensemble des ressources que le
serveur d’applications met à disposition via ces API de services, doit être enregistré avec un nom logique unique,
permettant aux applications de rechercher cette ressource dans le serveur.
JavaMail
L’API JavaMail fournit des fonctionnalités de gestion de courrier électronique (transfert, type de contenu, pièces
jointes...). JavaMail permet la création et l’envoi de messages électroniques via Java. Cette API permet de manipuler
les protocoles de messagerie Internet comme POP, IMAP, SMTP. JavaMail n’est pas un serveur de courrier mais plutôt
un outil qui permet d’interagir avec ce type de serveur.
JPA (Java Persistance API)
Les entités Beans ont été développées pour le modèle de persistance en Java EE. Ce modèle de composants avait
de nombreux détracteurs. Pour apporter des solutions à ce problème, de nouvelles spécifications, des outils de
mapping objet/relationnel comme TopLink et Hibernate ont été développés. Java EE apporte donc un nouveau
modèle de persistance nommé JPA. JPA s’appuie sur JDBC pour communiquer avec la base de données mais permet
d’éviter de manipuler directement les fonctionnalités de JDBC et le langage SQL.
3. Les autres API
Parmi les autres API Java EE, il faut citer :
JMS (Java Message Service) permet d’accéder à un service de messages pour une gestion asynchrone des composants.
Le composant appelant poste un message (en arrièreplan) à destination d’une file d’attente de messages hébergés
par le serveur d’applications puis continue son traitement sans attendre.
RMI (Remote Method Invocation) permet de concevoir des applications distribuées en Java. RMI permet l’appel de
fonctionnalités à distance par le biais de la communication réseau.
JTA (Java Transaction API) permet de mettre en place une gestion des transactions dans des applications distribuées
(commit, rollback...). Le principe des transactions est de considérer un ensemble d’opérations comme une seule. Ce
type de service est obligatoire pour des traitements bancaire. Par exemple, une application bancaire qui permet de
réaliser des virements entre deux comptes va d’abord débiter le premier compte et ensuite créditer le second compte.
Si le débit puis le crédit aboutissent sans problème, alors la transaction est validée. JDBC permet de gérer les
transactions sur une base de données locale mais si les données sont réparties, il faudra alors utiliser les transactions
JTA. JTA permet en effet de gérer les transactions distribuées qui font intervenir différentes bases de données.
© ENI Editions - All rigths reserved
- 5-
JCA (J2EE Connector Architecture) : ce connecteur permet à Java EE d’utiliser des gros systèmes tels que les
mainframes.
JAAS (Java Authentication and Autorisation Service) est un mécanisme de sécurité géré par le serveur d’applications.
XML n’est pas véritablement une API Java mais il est très utilisé pour la mise en place et la configuration des
applications. De même, XML est la base d’un nouveau mode de communication entre les applications qui est appelé
Web Service. Par exemple, JAXP (Java API for XML Parsing) analyse des fichiers ou données XML, JAXRPC (Java API for
XML based RPC) utilise des Web Services et JAXB (Java API for XML Binding) permet de générer des classes Java à partir
de schémas XML ou inversement.
Actuellement, la version de Java EE est 5.0 associée à l’API Servlet 2.5, et à l’API JSP 2.1 (et à ApacheTomcat 5.X6.X).
- 6-
© ENI Editions - All rigths reserved
Encodage des applications Java
1. Présentation
Les ordinateurs travaillent avec des bits ou suites d’octets (un octet=8 bits). Les chaînes de caractères, entiers, réels
sont donc codées sous forme d’octets. Les ordinateurs utilisent donc un procédé qui consiste à transformer les
chaînes de caractères en octets, associé à une technique afin de relire les chaînes d’origine. C’est ce procédé qui est
appelé encodage.
Il existe plusieurs encodages qui utilisent plus ou moins le même nombre d’octets, donc de caractères disponibles
comme ISO88591, ASCII, UTF8... L’encodage UTF8 est le plus pratique pour échanger des textes constitués de
caractères UNICODE (standard du consortium Unicode). Ce consortium a pour but de répertorier tous les caractères
utilisés dans les différentes langues et d’associer à chacun un code noté sous forme hexadécimal. L’encodage UTF8
est compatible avec l’encodage ASCII ce qui est très pratique lors des développements informatiques.
Lors des développements d’applications Java et/ou Java EE, il n’est pas rare de constater de nombreux problèmes
d’encodage des applications tant au niveau des messages présents dans un navigateur, que des fichiers de
propriétés d’une application ou encore de l’encodage des caractères saisis au clavier. La mise en œ uvre d’une
application Java nécessite donc la gestion de plusieurs paramètres. La difficulté est qu’il ne faut pas en oublier un
seul sous peine de constater l’affichage de ’’hiéroglyphes’’ à la place du caractère souhaité.
2. Les fichiers
La première contrainte à vérifier est que tous les fichiers (HTML, JSP, JSPF, XML, XSLT...) de l’application développée
soient dans l’encodage souhaité. Pour cela, la plupart des IDE peuvent se paramétrer afin de sélectionner
l’encodage. Avec Eclipse, nous pouvons sélectionner l’encodage dans le menu Fenêtre Préférences Editeurs
Codage du fichier texte et Types de contenu.
3. Les pages JSP et JSPF
Il est nécessaire de déclarer dans chaque page JSP ou JSPF d’entête l’encodage utilisé. Pour cela, il faut utiliser la
directive JSP adaptée.
Config. de l’encodage des pages JSP
*.jsp
UTF-8
4. Les pages HTML/XHTML
Il est également important de prévenir le navigateur client de l’encodage qu’il doit utiliser pour afficher la page
HTML/XHTML. Cette directive est précisée avec la balise meta et le paramètre content.
encodingfilter
application.filters.EncodingFilter
encoding
UTF-8
encodingfilter
/*
L’encodage peut aussi être géré au sein d’une Servlet générique. Chaque Servlet du projet devra alors ensuite
hériter de cette Servlet.
package application.servlets;
import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public abstract class EncodingServlet extends HttpServlet {
public static final String ENCODING = "encoding";
private String encoding;
public void init(ServletConfig servletConfig)throws ServletException
{
this.encoding = servletConfig.getInitParameter(ENCODING);
}
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException, ServletException
{
req.setCharacterEncoding(encoding);
resp.setContentType("text/html;charset="+encoding);
}
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws IOException, ServletException
{
request.setCharacterEncoding(encoding);
response.setContentType("text/html;charset="+encoding);
}
}
7. Encodage de la JVM
Il est important d’exécuter la JVM dans l’encodage voulu. Le traitement des chaînes de caractères doit être le même
que le reste de l’application. C’est au lancement de la JVM, donc au lancement du serveur Java EE, que l’encodage est
spécifié à l’aide de l’argument : -Dfile.encoding=UTF-8
Avec Tomcat, cet argument est spécifié dans le fichier de lancement du serveur, catalina.sh.
JAVA_OPTS="$JAVA_OPTS "-Dfile.encoding=utf-8"
Il est parfois également nécessaire de vérifier l’encodage des URL de l’application. Avec Tomcat, cet encodage est
déclaré explicitement via l’attribut URIEncoding sur le connecteur Coyote. Voici la ligne du fichier server.xml concerné :
© ENI Editions - All rigths reserved
- 3-
#/etc/init.d/tomcat stop
#/etc/init.d/tomcat start
En fait, la partie administration de Tomcat est une application/webapp fournie sous forme de fichiers .tar
ou .gz. La seule différence avec les autres webapps est que le projet n’est pas livré sous la forme d’une
archive .war directement déployable. Il faut donc copier les fichiers de configuration au bon endroit.
Pour éviter certains problèmes au démarrage du serveur, il est nécessaire d’éditer le
fichier /usr/local/tomcat/conf/server.xml et de mettre en commentaire la ligne suivante qui est appelée APR
pour Apache Portable Runtime et qui empêche parfois Tomcat de fonctionner correctement :
5. Augmenter la mémoire allouée à Tomcat
Tomcat est développé en langage Java et comme tout programme qui utilise ce langage, il est assez gourmand en
terme de mémoire. Il est donc parfois nécessaire d’augmenter la mémoire allouée à Tomcat afin qu’il puisse compiler
plus rapidement les pages et répondre au plus vite aux requêtes clients (même en phase de développement un
serveur rapide est plus souple).
Sous Windows
- 4-
© ENI Editions - All rigths reserved
Sous Windows, la mémoire allouée à Tomcat peut être paramétrée avec la console de gestion située dans le systray.
Il faut ouvrir l’onglet Java et paramétrer les champs Initial memory pool et Maximum memory pool. Pour l’utilisation
de ce guide et de ses exemples, 200 Mo seront alloués à Tomcat.
Une autre solution pour la gestion de la mémoire allouée à Tomcat est d’utiliser Eclipse et l’onglet Windows
Preferences. Dans la partie réservée à Tomcat, il est possible de préciser la mémoire initiale (Xms) et la mémoire
maxi (Xmx). Dans cet exemple, 200 Mo sont alloués à Tomcat. Il est important de ne pas allouer trop de mémoire par
rapport aux possibilités de la machine afin d’éviter des blocages lors de déploiements/codages.
Sous Linux
Pour augmenter la mémoire allouée à Tomcat sous Linux, il est nécessaire d’éditer le fichier de
configuration /usr/local/tomcat/bin/catalina.sh et d’ajouter la ligne suivante en début de fichier. Dans cet exemple, 2 Go
de RAM sont alloués à Tomcat pour un serveur en production.
JAVA_OPTS="-Xms2048m -Xmx2048m"
© ENI Editions - All rigths reserved
- 5-
Coupler Tomcat et le serveur Web Apache
1. Présentation
Si nous ne souhaitons pas installer un serveur en production, cette partie est alors facultative. En effet, elle ne permet
pas d’améliorer l’environnement de développement mais elle est recommandée pour un déploiement sur un serveur en
production.
Dans une architecture en production, il est recommandé d’utiliser un serveur Web en frontal d’un serveur
d’applications. Ces recommandations sont également appliquées dans le cas de l’utilisation d’un conteneur Web
comme Tomcat. L’utilisation d’un serveur Web en frontal est nécessaire pour des raisons de performance, de sécurité
et de configurabilité.
●
Performance : le moteur HTTP de Tomcat est beaucoup plus lent que le moteur HTTP d’un serveur Web dédié
à cette tâche. Le serveur Web permet de délivrer les contenus statiques comme les pages HTML, le code
JavaScript, les images du site, les feuilles de style... Tomcat sera utilisé alors pour servir uniquement les
contenus dynamiques en Java.
●
Sécurité : le serveur Web est utilisé en frontal et isole le conteneur Web d’Internet. Le conteneur est alors au
plus près des données et il est moins sollicité pour des services simples.
●
Configurabilité : un serveur Web comme Apache dispose d’une plus grande palette de services (point de vue
HTP) que Tomcat (.htaccess, gestion des droits, urlrewriting, alias, annuaire...).
2. Un connecteur pour l’intégration du serveur Web
L’intégration d’un serveur Tomcat avec un serveur Web se fait au travers d’un connecteur configuré au sein de Tomcat
et d’une extension ajoutée au serveur Web. Un connecteur Tomcat est une classe Java qui supporte un protocole
réseau spécifique et propriétaire. La librairie d’extension du serveur Web est chargée dynamiquement par le serveur
Web lors de son démarrage et permet un dialogue entre les deux serveurs. Plusieurs connecteurs existent comme le
module mod_jserv pour le serveur JServ et le module mod_webapp pour Tomcat 4.X. Ces modules sont désormais
abandonnés au profit du connecteur JK.
Le connecteur JK utilise le protocole AJP (Apache JServ Protocol) dans sa version 1.3 (AJP13). Ce connecteur est plus
performant mais il offre également le support de plusieurs systèmes d’exploitation, de plusieurs serveurs Web
(Apache, IIS, Lotus Domini) et du protocole HTTPS. Ce connecteur est aujourd’hui la référence pour le couplage d’un
serveur d’applications avec un serveur Web.
a. Fonctionnement
Le connecteur JK utilise donc le protocole AJP13 et nécessite l’installation du module mod_jk pour fonctionner avec
Apache. Le connecteur JK permet ainsi d’utiliser le serveur Web en frontal et de déléguer certaines tâches au serveur
Tomcat.
Les requêtes des clients sont envoyées au serveur Web Apache qui retourne alors directement les contenus
statiques comme les images, JavaScript, pages HTML, ... Pour les requêtes avec du contenu dynamique, le module
mod_jk du serveur Web est alors sollicité et délègue certaines tâches au serveur d’applications Tomcat.
La configuration de Tomcat avec un serveur Web utilise la notion de worker ou travailleur. Un travailleur est lié à une
instance de serveur Tomcat. Un travailleur est caractérisé par un nom d’hôte ou une adresse IP et un numéro de
port (comme une socket/prise). Le travailleur AJP13 représente une instance de Tomcat en fonctionnement et il est
utilisé comme plugin pour le serveur Apache. Le module mod_jk agit alors comme un routeur de requêtes vers le
serveur Tomcat.
© ENI Editions - All rigths reserved
- 1-
b. Installation du module mod_jk
L’extension d’Apache qui supporte le connecteur JK est le module mod_jk. Ce module est livré sous forme de binaires
(ou code source).
Le module mod_jk fonctionne sur le port 8009 de Tomcat. Par défaut, le fichier de configuration de Tomcat
server.xml propose un connecteur AJP13 qui fonctionne sur le port 8009 :
ServerName monserveur.com
#les parties statiques de mon application sont gérées par Apache
Alias /images /usr/local/tomcat/webapps/monapplication/images
Alias /css /usr/local/tomcat/webapps/monapplication/css
DocumentRoot /usr/local/tomcat/webapps/monapplication
#les requêtes ne sont transmises à Tomcat que pour les servlets et JSP
JkMount worker1
JkMount worker1
#pages d’accueil autorisées
DirectoryIndex index.html index.htm index.jsp
Vous remarquez que le serveur sera capable de définir la page index.jsp comme page d’accueil de l’application. De
même, tous les contenus autres que les Servlets (extension .do) et les JSP (extension .jsp) seront traités par le
serveur Web qui est plus approprié.
La directive JkMount est très importante car c’est elle qui permet au serveur Apache d’accéder aux applications
Tomcat. Elle permet en effet, de spécifier un travailleur pour l’accès au contexte. Il y aura donc une redirection de
requêtes utilisateur à destination du travailleur. La directive JkUnMount permet de réaliser l’inverse et donc de ne
pas rediriger les requêtes utilisateurs à destination de ressources particulières.
Exemple :
JkUnMount /usr/local/tomcat/webapps/monapplication/mesimages/*.gif
D’autres directives d’Apache sont utilisables avec le mod_jk. JkAutoAlias permet de réaliser un alias du répertoire de
Tomcat sur le répertoire de données Apache, JkLogStampFormat permet de gérer le format de la date dans le fichier
journal du module, JkExtractSSL permet de transmettre les informations SSL vers le serveur Tomcat (état on par
défaut)...
d. Créer le fichier de configuration du travailleur
Une fois le fichier de configuration d’Apache modifié, il faut ensuite créer le fichier de configuration du travailleur
indiqué par la directive JkWorkersFile dans le fichier d’Apache. Ce fichier permet de gérer la communication entre le
serveur Web et le serveur Tomcat. Le fichier utilisé nommé workers.properties porte l’extension .properties qui est un
format très utilisé avec les technologies Java. Ces fichiers sont composés d’un ensemble de paires clé/valeur.
La syntaxe pour le fichier workers.properties est la suivante :
worker..=
La syntaxe de notre fichier est la suivante :
workers.tomcat_home=/usr/local/tomcat
workers.java_home=$(JAVA_HOME)
ps=/
#liste des travailleurs (il serait possible de placer plusieurs travailleurs
séparés par des virgules)
workers.list=worker1
#protocole de worker1
workers.worker1.type=ajp13
#nom d’hote pour worker1
workers.worker1.host=localhost
#port du connecteur JK pour worker1
workers.worker1.port=8009
#le facteur de charge
workers.worker1.lbfactor=50
#nombre de connexions AJP maintenues dans le cache
workers.worker1.cachesize=10
#temps pendant lequel la connexion est maintenue dans le cache
workers.worker1.cache_timeout=600
#ne pas couper les connexions inactives
workers.worker1.socket_keepalive=1
© ENI Editions - All rigths reserved
- 3-
#temps d’expiration lors de la communication entre Apache et Tomcat
workers.worker1.socket_timeout=300
Ce fichier est créé dans le répertoire local d’Apache à savoir : /etc/apache/workers.properties conformément à la
directive JkWorkersFile. Les paramètres de configuration du fichier workers.properties sont, entre autres :
●
worker.list : permet de spécifier une liste de travailleurs séparés par des virgules.
●
type : permet de spécifier le type de travailleur.
●
host : permet de spécifier le nom d’hôte ou adresse IP du serveur Tomcat à contacter pour le travail.
●
port : indique le numéro de port du connecteur JK.
●
socket_timeout : indique le temps d’expiration de la communication entre Apache et Tomcat. Si le serveur
Tomcat ne répond pas dans le délai indiqué, mod_jk génère une erreur et recommence.
●
retries : positionne le nombre de tentatives de connexions vers Tomcat en cas de non réponse de ce dernier
(3 par défaut).
●
socket_keepalive : permet d’éviter que le firewall coupe les connexions inactives (défaut 0).
●
recycle_timeout : indique le nombre de secondes audelà duquel le serveur coupe une connexion AJP en cas
d’inactivité (défaut 0, bonne moyenne 300).
●
cachesize : précise le nombre de connexions AJP maintenues en cache.
●
cache_timeout : permet de spécifier combien de temps une connexion doit être maintenue dans le cache
avant d’être fermée par mod_jk afin de réduire le nombre de processeurs de requêtes actifs sur le serveur
Tomcat (défaut 0).
●
lbfactor : permet de gérer le facteur de charge d’un travailleur dans le cas où la répartition de la charge est
mise en œ uvre par mod_jk. Cette valeur permet de préciser quel pourcentage de requêtes l’instance Tomcat
sera amenée à traiter (défaut 1).
Une fois la configuration du connecteur JK terminée, il faut redémarrer les deux serveurs et tester l’accès à une
Servlet ou une JSP pour notre hôte précédemment défini (http://monserveur.com/index.jsp).
Pour cela, sous Windows, il est possible d’éditer le fichier C:\WINDOWS\system32\drivers\etc\hosts et d’ajouter le
nom de l’hôte virtuel.
127.0.0.1
127.0.0.1
localhost
monserveur.com
Sous Linux, nous pouvons réaliser la même opération en éditant le fichier /etc/hosts.
127.0.0.1
127.0.0.1
localhost
monserveur.com
Désormais, lorsque l’url suivante : http://monserveur.com sera appelée dans un navigateur, c’est la machine locale
(127.0.0.1) qui répondra aux requêtes du client.
#/etc/init.d/apache restart
#/etc/init.d/tomcat stop
#/etc/init.d/tomcat start
Si la page .jsp est affichée, l’installation est correcte. En effet, c’est l’hôte virtuel du serveur Web Apache qui est
précisé par le nom de domaine (http://monserveur.com) et le fichier .jsp est exécuté par Tomcat par le biais du
connecteur.
En cas de problème lors du test du connecteur, les fichiers journaux d’Apache et de mod_jk peuvent nous
aider en indiquant les raisons des dysfonctionnements.
- 4-
© ENI Editions - All rigths reserved
© ENI Editions - All rigths reserved
- 5-
Architecture et configuration de Tomcat
Le serveur d’applications Tomcat utilise une architecture spécifique (spécifique aux projets Java EE) qu’il est nécessaire
de bien maîtriser. Tomcat est livré préconfiguré, il est possible de l’utiliser comme cela sans avoir à modifier les fichiers
de configuration, mais lors des développements et de la mise en production des applications, il sera nécessaire de bien
contrôler l’administration du serveur.
1. Les composants de Tomcat
Tomcat est constitué d’un ensemble de composants dédiés à l’exécution d’un service particulier et précis. Les
composants de Tomcat sont appelés des conteneurs (parce qu’ils contiennent eux aussi des composants). Il existe
actuellement cinq types de conteneurs : Server, Service, Engine, Host et Context.
Tous ces conteneurs sont représentés dans le fichier de configuration du serveur server.xml qui est le principal fichier
de configuration de Tomcat. Chaque conteneur est représenté par une balise XML en suivant une structure
arborescente adaptée en conséquence.
2. Arborescence du serveur
La structure des fichiers au sein du répertoire d’installation est présentée dans cette image.
© ENI Editions - All rigths reserved
- 1-
Parmi les répertoires présents, certains sont dédiés à la configuration du serveur et sont donc difficilement
modifiables, d’autres peuvent être modifiés suivant les développements.
Le répertoire /bin contient tous les scripts et fichiers indispensables au bon fonctionnement de Tomcat. Ces
exécutables contiennent des scripts shell et des fichiers batch qui permettent de démarrer et d’arrêter le serveur sur
les différentes platesformes prises en charge. Les fichiers d’extension .bat sont utilisés sous Windows et les
fichiers .sh sont utilisés sous Linux.
Le répertoire /lib est le répertoire partagé de Tomcat. La totalité de son contenu est accessible à toutes les
applications Web déployées sur le serveur. Les ressources placées dans ce répertoire peuvent être livrées au
format .class et donc copiées dans le répertoire /lib/classes ou sous forme de fichiers .jar. Ce répertoire /lib sera très
souvent utilisé pour placer le pilote JDBC de la base de données utilisée. Par exemple, lors du déploiement d’un
projet, la librairie mysqlconnectorjava3.1.11bin.jar sera copiée dans le répertoire /lib et sera donc utilisable par
toutes nos classes du projet (ce qui est valable pour les librairies mail.jar, xalan.jar...). Dans le cas où plusieurs
applications Web ont toutes besoin d’une même bibliothèque, il peut être plus judicieux de copier cette bibliothèque
dans ce répertoire plutôt que dans chacune des applications.
Le répertoire /conf contient tous les fichiers de configuration de Tomcat avec les quatre fichiers importants que sont
server.xml, tomcatusers.xml, web.xml et catalina.policy.
Le répertoire /logs contient tous les fichiers journaux du serveur Tomcat. Il est important de préciser que les fichiers
journaux sont automatiquement remplacés tous les jours à minuit, et contiennent dans leur intitulé la date au format
anglais. Il existe trois principaux types de fichiers journaux : les fichiers relatifs au serveur, les fichiers relatifs aux
applications et aux noms d’hôtes.
Le répertoire /temp est un répertoire temporaire pour les applications non déployées.
Le répertoire /webapps est le répertoire par défaut d’installation des applications Java EE. Il contient par défaut des
applications d’exemples ainsi que l’application tomcatdocs qui fournit la documentation du serveur. Il est tout à fait
possible de référencer des applications Web qui ne se trouvent pas dans le répertoire /webapps. Dans ce cas, il faut
préciser le répertoire de l’application de façon précise dans le fichier de configuration server.xml.
Le répertoire /work est utilisé pour le traitement des pages JSP et leur transformation en classes Java. Toutes les
Servlets générées à partir de pages JSP seront stockées dans ce répertoire. Chaque application possède alors son
propre sousrépertoire (ex : work/Catalina/localhost/monapplication) en suivant l’arborescence suivante :
work/// où , et représentent le nom des conteneurs Engine, Host
et Context dans lesquels cette application est installée. Ce répertoire sera d’une grande utilité lors du débuggage de
pages JSP. Le code transformé sera en effet accessible. De même, il sera parfois nécessaire de supprimer le contenu
de ce répertoire pour notre hôte lorsque l’on voudra regénérer toutes les pages JSP.
- 2-
© ENI Editions - All rigths reserved
Rappels XML
Les fichiers de configuration de Tomcat sont écrits avec le langage XML. Il est donc important de présenter la syntaxe et
les balises de ce langage afin de configurer correctement le serveur d’applications. XML (eXtended Markup Language)
dérive du langage SGML (Standard Generalized Markup Language) développé dans les années 80. SGML est un langage
très complexe à apprendre et à utiliser. Une version plus simple de ce langage a été proposée pour la présentation de
document Web : le HTML (HyperText Markup Language).
HTML
HTML est aujourd’hui le standard pour le développement Web. Il commence à être remplacé progressivement par le
XHTML (eXtend Hypertext Markup Language) qui est assez similaire mais qui respecte les normes XML. HTML est ’’un
langage’’ de description, il est lié à une DTD (Document Type Definition) qui permet de vérifier la syntaxe du langage.
XML
XML utilise la simplicité du HTML avec la souplesse de SGML. Le point commun le plus important entre SGML et XML est
l’utilisation d’une DTD ou d’un schéma. Cette association n’est pas obligatoire et un fichier XML peut très bien se suffire
à luimême.
Dans un document XML, la mise en forme des données est complètement séparée des données. Les données (le
contenu) sont séparées de l’apparence (le contenant). Il sera donc possible de fournir plusieurs types de sorties pour
un même fichier de données (image, fichier HTML, fichier XML, fichier PDF...).
Les langages SGML, HTML/XHTML et XML sont en fait composés de balises qui peuvent être comparées à des mots du
langage français. Par contre, il y a des règles à respecter pour l’utilisation de ces mots dans un document, ces règles
sont appelées : grammaires.
XML permet de séparer le fond de la forme. Cela signifie qu’un document XML ne comporte que des données. Ainsi, pour
produire un document HTML à partir d’un fichier XML, il est nécessaire de créer au moins deux fichiers, le premier pour
les données et le second pour la mise en forme de ces données. Un troisième fichier peut parfois être utilisé, c’est une
DTD ou un schéma permettant de définir les balises et la grammaire utilisées.
Bien formé
Un document XML bien formé est un document XML qui respecte certaines règles.
●
Le document doit commencer par une déclaration XML (prologue) .
●
Il ne doit exister qu’une seule balise racine.
donnée1
donnée2
...
●
Les valeurs des attributs doivent être impérativement encadrées par des guillemets simples ou doubles.
●
Toute balise ouverte doit être fermée.
donnée
●
Une balise vide doit être obligatoirement fermée.
donnée
© ENI Editions - All rigths reserved
- 1-
●
Les noms des balises doivent commencer par une lettre ou ’’_’’, les autres caractères peuvent être des chiffres,
des lettres, ’’_’’, ’’.’’ ou ’’’’.
<_balise attribut28=’valeur’/>
●
Les noms des balises et des attributs doivent conserver une casse identique.
Les infiltrés
17.99
125
Le cercle rouge
14
120
Psychose
22
155
Dans cet exemple, le prologue est indiqué par la première ligne du document , il précise que le document est un fichier XML utilisant l’encodage ISO88591 (caractères standards du clavier).
Dans le prologue, l’attribut version précise la version XML utilisée dans le document. L’attribut encoding permet de définir
le jeu de caractères utilisé. Pour la France, le jeu de caractères standard est ISO88591. Pour faire des pages en
international (Japonais, Anglais, Français...), il faut utiliser l’encodage Unicode UTF8. Un troisième attribut optionnel
nommé standalone permet de préciser si oui ou non le fichier XML est lié à une DTD externe pour vérifier sa syntaxe.
●
- 2-
sans utilisation d’une DTD :
© ENI Editions - All rigths reserved
●
avec utilisation d’une DTD :
L’élément est l’élément racine du document. Il est luimême constitué de trois éléments . Dans chacun des
éléments de cet exemple vous retrouvez un élément , et . L’élément possède un attribut
nommé langue.
Cette vue représente le code XML de la page précédente ouvert avec un navigateur
Une DTD peut être associée à ce document et permet alors de définir la structure du document.
Les infiltrés
17.99
125
Le cercle rouge
14
120
Psychose
22
155
© ENI Editions - All rigths reserved
- 3-
Lors de la déclaration d’une DTD, il faut préciser l’élément racine ( dans l’exemple) et le nom du fichier qui
contient la grammaire du document (dvd.dtd dans l’exemple). Bien que facultative, une DTD permet de simplement
vérifier la validité d’un document XML. Dans un document XML, les commentaires sont utilisés comme dans un document
HTML avec la syntaxe suivante .
Explications
L’élément racine est la base du document XML. Il doit être unique et englobe tous les autres éléments. Il
s’ouvre juste après le prologue et se ferme à la fin du document. Les autres éléments forment la structure du document.
Ce sont donc les branches et les feuilles de l’arborescence. Les éléments contenants sont appelés élément parent et les
autres éléments imbriqués élément enfant. Les éléments peuvent contenir un ou plusieurs attributs. Chaque élément ne
peut contenir qu’une fois le même attribut. Un attribut est composé d’un nom et d’une valeur. Un attribut ne peut être
présent que dans une balise ouvrante d’un élément (et pas dans la fermante).
Certains caractères ont un sens particulier en XML, il est nécessaire de trouver un remplaçant quand il faut insérer ces
caractères dans le document. Il faut alors avoir recours aux entités. Les caractères réservés en XML sont les suivants :
Caractère
Entité
&
& ;
<
< ;
>
> ;
’’
" ;
’
&aquot ;
Pour les lettres accentuées, il faudra parfois utiliser les entités numériques du type &#numero; (où numero est une
valeur décimale). Par exemple, le caractère codé é peut être remplacé par é;.
Syntaxe d’une DTD
Dans l’exemple précédent, le fichier est correctement affiché dans un navigateur. Le document est valide et bien formé,
il peut désormais être utilisé.
Les infiltrés
17.99
125
Le cercle rouge
14
120
Psychose
22
155
Rien ne nous empêche de ne plus avoir de prix et de durée pour chaque dvd. La structure du document est correcte du
point de vue des balises mais la grammaire ne l’est pas. C’est là qu’intervient la DTD (fichier dvd.dtd cidessous) qui
permet de définir la syntaxe que le document XML devra respecter.
Exemple 1 :
- 4-
© ENI Editions - All rigths reserved
Exemple 2 :
Les infiltrés
Le cercle rouge
Psychose
Le fichier XML est associé à cette DTD. Il devra donc respecter la grammaire suivante : la balise racine doit être ,
la balise racine est composée de balises et chaque balise contient une balise , et .
La balise contient deux attributs optionnels type et langue. L’attribut type ne peut contenir que les valeurs
’thriller, policier, horreur et théâtre’. La balise langue contient par défaut la valeur ’fr’.
Le mot clé SYSTEM dans le fichier XML indique que le fichier DTD se trouve sur l’ordinateur local et qu’il est disponible en
accès privé uniquement. Le mot clé PUBLIC indique qu’une ressource est disponible pour tous (accès public) sur un
serveur Web distant.
Les éléments
Une déclaration d’élément est de la forme :
nom est le nom de l’élément et type_element est le type auquel l’élément est associé. Un élément peut être de type
texte, vide (EMPTY), séquence ou choix d’éléments. Dans ces deux derniers cas, la liste des éléments enfants est
indiquée.
Un élément texte est précisé par #PCDATA.
Un élément vide utilise le mot clé EMPTY.
Dans le document XML, l’élément vide sera représenté par : Mon Titre
Ma page
Une application déployée avec Tomcat
DisplaySource
DisplaySource
display source of sample jsp pages
org.displaytag.sample.DisplaySourceServlet
DisplaySource
*.source
css
text/css
index.jsp
index.html
404
/404.jsp
Nous remarquons que ce fichier de configuration d’une application Tomcat doit être conforme à la DTD PUBLIC de Sun
Microsystems
().
Dans un éditeur tel que Eclipse, la syntaxe du fichier de configuration sera donc vérifiée en temps réel grâce à une
connexion Internet. Par exemple, il n’est pas possible de placer les balises après les balises ce qui est très utile et permet d’augmenter la fiabilité du projet.
© ENI Editions - All rigths reserved
- 7-
Les fichiers de configuration Tomcat
Le fichier server.xml
Le principal fichier de configuration du serveur Tomcat s’appelle server.xml et se trouve dans le répertoire /conf du
serveur. Il fournit à Tomcat tous les paramètres nécessaires pour le fonctionnement, les ports à écouter, les hôtes
virtuels, les instances de processeur HTTP et les classes à utiliser pour gérer les connexions entrantes. Ce fichier est
au format XML et possède une balise de déclaration XML (prologue) mais il n’est lié à aucun fichier de validation DTD ou
schéma. Ce fichier est donc bien formé mais non valide. Comme tout fichier XML, le langage est sensible à la casse et le
fichier server.xml doit utiliser des balises commençant par une majuscule suivie de lettres en minuscules. Lors du
démarrage, Tomcat vérifie la syntaxe des éléments déclarés dans ce fichier. Tomcat comprend un processus principal, le
serveur qui contient luimême plusieurs souscomposants qui sont utilisés pour traiter les requêtes.
L’élément est la racine du fichier server.xml. Il représente l’instance de serveur Tomcat. Cet élément utilise
trois attributs et contient tous les autres éléments qui contrôlent le serveur. Le premier attribut facultatif est
className. Cet attribut correspond à la classe à utiliser en tant que serveur Tomcat. Tomcat utilise généralement
l’implémentation par défaut. Les deux autres attributs sont port et shutdown. Ils contrôlent le service pour écouter les
commandes d’arrêt du serveur.
© ENI Editions - All rigths reserved
- 1-
L’élément regroupe les éléments qui permettent la connectivité au serveur ainsi que le moteur d’exécution
de Tomcat. Le seul attribut obligatoire de cette balise est name. Cet attribut permet d’affecter un nom au service qui
s’affiche dans les fichiers journaux. Le nom par défaut de cet attribut est Catalina.
L’élément permet de gérer les threads (sousprocessus) à l’intérieur de la machine virtuelle Java. Chaque
thread est dédié au traitement d’une requête client et à l’envoi de sa réponse. Pour éviter les créations et
suppressions inutiles de threads, Tomcat 6.X utilise un mécanisme nommé pool de threads. Plutôt que de détruire un
thread après traitement d’une requête client, celuici est recyclé. Le pool de threads est dimensionné avec une valeur
initiale qui permet de définir combien de threads doivent être créés dedans et le nombre maximum de threads. Ces
deux paramètres sont respectivement configurés à partir des attributs minSpareThreads et maxThreads de l’élément
.
L’élément : cet élément fils de la balise permet d’implémenter la couche transport des requêtes
clients vers le moteur de Servlets Tomcat (Catalina). Depuis la version 5.0 de Tomcat, il existe deux types de
connecteurs selon le protocole, à savoir HTTP et AJP. Le choix de transiter par l’un ou l’autre des protocoles se fait avec
l’attribut protocol. L’attribut port permet d’indiquer le port à l’écoute du connecteur. Par défaut, Tomcat utilise le port
8080 pour le HTTP et le port 8009 pour le connecteur AJP. L’attribut address permet de spécifier une adresse IP
particulière pour écouter les connexions entrantes. Enfin, l’attribut secure permet de définir un connecteur HTTPS.
L’élément est chargé de répartir toutes les requêtes. C’est le moteur de Servlets Catalina de Tomcat. Une
application est obligatoirement associée à un élément . Les deux attributs obligatoires de cet élément sont
name et defaultHost. L’attribut name permet d’identifier le moteur de Servlets et l’attribut defaultHost permet de définir
lequel des éléments de la configuration va recevoir les requêtes en cas de non correspondance de nom d’hôte
(hôte par défaut).
L’élément : le conteneur permet de configurer les attributs à associer à un hôte unique. La possibilité
de configurer une seule machine pour servir plusieurs hôtes offre une souplesse considérable. L’hébergement virtuel
est une technique utilisée par les serveurs HTTP, permettant d’héberger plusieurs sites distincts à une même adresse
IP. Par exemple, lorsqu’un client saisit l’adresse : http://www.monsite.com/accueil.html, la requête suivante est
envoyée
GET /accueil.html HTTP/1.1
Host : www.monsite.com
Le système DNS va permettre au navigateur de trouver l’adresse IP du serveur Web à contacter et la requête sera
envoyée au serveur indiqué. Un autre site http://www.monentreprise.com peut être hébergé sur la même machine et
donc posséder la même adresse IP. C’est dans ce cas précis que l’élément est utilisé pour identifier de façon
unique et précise le site. Donc autant d’hôtes que nécessaire peuvent être configurés dans un serveur Tomcat et c’est
l’attribut name qui permet de préciser le nom d’hôte.
Si un client accède au serveur directement par l’adresse IP, le serveur sera alors dans l’incapacité de résoudre le nom
d’hôte. L’attribut de configuration defaultHost de l’élément permet donc de définir l’hôte qui sera contacté
dans ce cas précis.
Il peut être intéressant de mapper plusieurs noms de domaine sur un contenu unique. Par exemple, les sites
www.monentreprise.com et monentreprise.com peuvent être utilisés avec le même hôte. Dans ce cas, les noms d’hôtes
doivent retourner un contenu identique, il faut alors utiliser l’élément à l’intérieur du conteneur .
...
monentreprise.com
...
L’autre attribut obligatoire est appBase. Il permet de spécifier le répertoire racine dans lequel sont stockées les
applications accessibles via cet hôte. La valeur par défaut est webapps et correspond au répertoire /webapps de
Tomcat.
Les autres attributs de configuration permettent de gérer le déploiement des applications. Entre autres, l’attribut
autoDeploy permet d’indiquer à Tomcat si les applications déposées dans le répertoire des webapps (indiqué donc par
appBase) doivent être automatiquement déployées sans redémarrage du serveur pour un hôte. Par défaut la valeur est
autoDeploy=’’true’’ ce qui est très intéressant pour un serveur en développement, mais il oblige Tomcat à surveiller en
permanence le contenu de ce répertoire. Ce procédé est très coûteux en terme de ressources sur un serveur en
production.
L’attribut liveDeploy indique qu’un nouveau projet déposé dans le répertoire /webapps doit être rechargé
automatiquement au niveau du projet et pas d’un hôte.
L’attribut deployOnStartup rend disponible toutes les applications au démarrage de Tomcat, ce qui est évidemment la
valeur par défaut.
- 2-
© ENI Editions - All rigths reserved
L’attribut unpackWARs permet de décompresser les fichiers d’archives WAR ce qui est le cas par défaut.
L’attribut deployXML permet d’autoriser le déploiement des applications via les fichiers de contexte XML.
Enfin, le répertoire workDir permet de spécifier un répertoire de travail pour les applications. Les classes des Servlets et
des JSP seront générées dans ce répertoire. Chaque application possède son propre sousrépertoire. Par défaut, ce
répertoire est placé de cette façon : /work/Catalina/nom_hôte.
L’élément qui est une balise fille de l’élément permet de déployer une application Web dans Tomcat.
Un contexte permet de relier une URL à une application Web.
Cet élément est utilisé pour déclarer explicitement une application, il peut être utilisé dans le fichier server.xml ou bien
dans les fichiers de contexte XML, c’est cette dernière méthode qui est préconisée avec Tomcat 6.X. La balise
possède deux attributs obligatoires afin de préciser le répertoire qui contient l’application et l’URL pour
accéder à cette application.
L’attribut docBase permet de faire référence au répertoire des données de l’application ou bien directement au fichier
WAR de l’application.
L’attribut path permet d’indiquer le chemin de contexte de cette application Web. Ce chemin commence toujours par le
caractère /, chaque application doit posséder une valeur unique de cet attribut. L’attribut facultatif reloadable permet
d’activer une surveillance des répertoires /WEBINF/lib et /WEBINF/classes de l’application.
Chaque modification apportée au contenu de ces répertoires sera automatiquement prise en compte par Tomcat qui
rechargera alors automatiquement l’application. Il est préférable d’utiliser l’outil manager du serveur d’applications pour
recharger les classes et ainsi éviter un gaspillage inutile des ressources.
L’attribut facultatif workDir permet de spécifier le répertoire de travail pour l’application. Si cet attribut est spécifié dans
l’hôte, il surcharge alors celui défini dans l’élément .
L’attribut facultatif cookie permet d’indiquer si le serveur utilise les cookies pour gérer les sessions utilisateurs. La
valeur par défaut est true.
Tomcat utilise un contexte par défaut qui est mis en œ uvre dans le fichier /conf/context.xml.
L’élément : la plateforme Java EE définit un mécanisme standard basé sur la notion de rôles pour la gestion
des authentifications dans les applications Web. Un peut être défini en tant qu’élément enfant des balises
, ou . Suivant le placement, l’authentification sera appliquée à tout le moteur de Servlets, à
un hôte particulier ou à une application.
monsite.com
mesites.com
© ENI Editions - All rigths reserved
- 3-
L’élément définit un chargeur de classe Java. Le rôle de cet élément est de charger les classes Java d’une
application Web. Le serveur charge les classes contenues dans le répertoire /WEBINF/classes de l’application, les
classes contenues dans les fichiers JAR présents dans le répertoire /WEBINF/lib et les classes rendues accessibles aux
applications par le moteur de Servlets.
L’élément permet de configurer le gestionnaire de session pour une application Web spécifique. Par défaut,
un conteneur Web Java EE stocke les informations de session utilisateur dans la Machine Virtuelle Java. En plus d’être
stockées en mémoire, les sessions utilisateurs sont sauvegardées soit dans une base de données soit dans un fichier
par la classe d’implémentation org.apache.catalina.session.PersistentManager.
L’élément représente un composant sous forme d’une classe Java. Cet élément peut être considéré comme un
filtre de requêtes. Voici les différentes valeurs possibles pour l’attribut className et le type de filtre associé :
●
org.apache.catalina.valves.AccessLogValve : génère un fichier journal des accès au serveur.
●
org.apache.catalina.valves.JDBCAccessLogValve : génère un fichier journal des accès à une base de données.
●
org.apache.catalina.valves.RemoteAddrValve : applique une restriction d’accès en fonction des adresses IP des
clients.
●
org.apache.catalina.valves.RemoteHostValve : applique une restriction d’accès en fonction des noms de machines
des clients.
●
org.apache.catalina.valves.RequestDumperValve : génère un fichier journal des requêtes des clients.
●
org.apache.catalina.authenticator.SingleSignOn : permet une authentification unique entre plusieurs applications.
Il est important de noter que nous pouvons implémenter votre propre filtre en écrivant une classe Java sur le modèle
de celles déjà fournies.
Exemple :
Avec JDBCAccessLogValve, le code suivant peut être inséré dans le fichier de configuration server.xml.
...
L’attribut connectionURL permet de spécifier la base de données et les coordonnées de connexion à la base de
données.
L’attribut driverName permet de spécifier le pilote JDBC d’accès à la base de données. Celuici devra bien sûr être
installé dans le répertoire /lib de Tomcat.
L’attribut tableName permet de préciser le nom de la table qui va recevoir les données des journaux.
L’attribut resolveHosts permet de remplacer l’adresse IP du client par le nom de machine.
Enfin, l’attribut pattern permet de définir le format d’entrée des fichiers journaux.
La base de données doit avoir la syntaxe suivante :
CREATE DATABASE "stattomcat";
USE "stattomcat";
CREATE TABLE "log" (
"id" INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
"remoteHost" CHAR(15) NOT NULL DEFAULT "",
"user" CHAR(15),
"timestamp" TIMESTAMP NOT NULL DEFAULT 0,
"virtualHost" VARCHAR(64) NOT NULL DEFAULT "",
"method" VARCHAR(8) NOT NULL DEFAULT "",
"query" VARCHAR(255) NOT NULL DEFAULT "",
- 4-
© ENI Editions - All rigths reserved
"status" INTEGER UNSIGNED NOT NULL DEFAULT 0,
"bytes" INTEGER UNSIGNED NOT NULL DEFAULT 0,
"referer" VARCHAR(128),
"userAgent" VARCHAR(128),
PRIMARY KEY("id")
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
L’élément permet de définir un écouteur d’événements sur les éléments , ou .
Cet élément ne dispose que d’un seul attribut obligatoire nommé className qui est la classe Java qui implémente
l’écouteur. Tomcat possède par défaut deux écouteurs définis sur l’élément . Ces écouteurs permettent la
supervision globale du serveur ainsi que des ressources JNDI. Les objets MBeans de supervision sont définis et utilisés
par l’API Java JMX (Java Management Extension) que nous verrons dans ce chapitre.
Parmi les autres fichiers de configuration de Tomcat, il existe les fichiers tomcatusers.xml, catalina.policy et web.xml.
Ces fichiers sont présents dans le répertoire /conf de Tomcat. Les fichiers tomcatusers.xml et catalina.policy sont
utilisés pour la sécurité du serveur et le fichier web.xml définit les applications Web déployées sur le serveur.
© ENI Editions - All rigths reserved
- 5-
Le fichier de configuration des applications
Le fichier web.xml
Le fichier web.xml est un autre fichier de configuration. Un fichier web.xml est un descripteur de déploiement
d’applications Web Java EE. Le fichier /conf/web.xml de Tomcat définit les paramètres de configuration utilisés par
toutes les applications Web installées sauf, si les applications fournissent leur propre fichier de configuration web.xml.
Par la suite, toutes les applications déployées utiliseront leur propre fichier web.xml.
Ce fichier de configuration commence par la déclaration de Servlets qui sont spécifiques à Tomcat. La Servlet par défaut
de Tomcat est définie avec la classe DefaultServlet et son attribut listings qui permet d’autoriser ou non l’indexation.
La
Servlet
InvokerServlet
permet
de
déclencher
http://serveur/application/servlet/nomdelaclasseservlet.
des
Servlets
directement
avec
des
URL
La troisième Servlet est JspServlet et permet de transformer des pages JSP en Servlet.
Les sections suivantes de ce fichier de configuration concernent les paramètres Java EE : par exemple, le temps
d’expiration des sessions, les types MIME des entêtes HTTP, les pages d’accueil (ex: index.html, index.jsp...).
© ENI Editions - All rigths reserved
- 1-
Le fichier de configuration des utilisateurs
Le fichier tomcatusers.xml
Ce fichier est utilisé pour les authentifications de Tomcat. Tomcat utilise le système d’authentification basé sur une
connexion JNDI. Ce gestionnaire d’authentification est associé au fichier tomcatusers.xml contenant les associations
identifiant, mot de passe et rôle. La partie manager et administration de Tomcat utilise ce fichier d’authentification.
La déclaration de ce système d’authentification se retrouve dans le fichier de configuration du serveur /conf/server.xml.
Voici le contenu de ce fichier qui se trouve dans le répertoire : /conf/tomcatusers.xml.
Nous remarquons la définition des rôles et des utilisateurs avec leur mot de passe.
L’application manager de Tomcat n’est accessible que par les utilisateurs qui possèdent le rôle manager, déclaré dans
ce fichier. Il sera possible de modifier ce fichier pour réaliser une authentification qui repose sur une base de données
ou un annuaire.
© ENI Editions - All rigths reserved
- 1-
Le fichier de configuration de la sécurité
Le fichier catalina.policy
Le gestionnaire de sécurité de la machine virtuelle Java est appelé SecurityManager et permet d’assurer la sécurité des
applications exécutées sur le système. Par l’intermédiaire de ce gestionnaire, il est possible de régler l’accès aux
ressources que le programme Java peut utiliser. Par défaut, Tomcat est exécuté sans le gestionnaire de sécurité
SecurityManager. Les applications déployées sur le serveur peuvent donc lire, écrire et supprimer des fichiers, lancer
des programmes et des commandes système, ouvrir des flux à travers le réseau, gérer la machine virtuelle, voire
l’arrêter...
Pour lancer Tomcat en mode sécurisé, il faut utiliser l’option security sur le script de démarrage (startup.bat ou
startup.sh).
Dans ce cas précis, tout ce qui n’est pas explicitement précisé dans le fichier catalina.policy est interdit.
© ENI Editions - All rigths reserved
- 1-
Arborescence d’un projet Tomcat
Une application Web est un ensemble de ressources qui participent au fonctionnement de l’application. Une application
est constituée de plusieurs éléments :
●
Le composant serveur dynamique : Servlets et JSP.
●
Les librairies de classes Java utilitaires.
●
Les éléments Web statiques : pages HTML, images, feuilles de style, JavaScript...
●
Les composants clients dynamiques : Applets, JWS, JavaBean.
●
Un descripteur de déploiement et de configuration de l’application Web sous la forme d’un (ou plusieurs) fichier
(s) de configuration au format XML : web.xml.
Les spécifications de l’API Servlet indiquent l’organisation des dossiers et fichiers à respecter pour déployer une
application Web. L’application est configurée par le fichier XML : /monapplicationweb/WEBINF/web.xml.
L’arborescence de l’application Web est la suivante :
Le dossier nommé dans l’exemple monapplicationweb représente la racine de l’application Web. N’importe quel nom peut
lui être donné, en général c’est le nom de l’application (ex : facturation, boutique...). Une fois en production ce dossier
est public, nous retrouvons donc les fichiers HTML, JavaScript...
Le dossier METAINF contient le fichier manifest.mf qui est généré par l’archiveur jar.exe lorsqu’une archive du projet est
réalisée pour le déployer. Ce fichier permet de stocker des informations concernant l’archive comme sa version, le
contenu, la version du compilateur...
Exemple :
Manifest-Version: 1.0
Created-By: 1.5.0_04 (Sun Microsystems Inc.)
Le dossier WEBINF représente la partie privée de l’application Web. Il contient le fichier web.xml qui représente le
descripteur de déploiement.
Le sousdossier /classes du dossier WEBINF contient les fichiers .class (compilés) de l’application (Servlets, JavaBean,
classes utilitaires...).
Le sousdossier /src du dossier WEBINF contient les fichiers .java (sources) de l’application (Servlets, JavaBean, classes
utilitaires...).
Le sousdossier /lib du dossier WEBINF peut contenir des librairies .jar utiles au fonctionnement de l’application Web.
Par exemple, la librairie de gestion d’emails, les librairies de Struts, les librairies de manipulation de code XML, des
fichiers .dtd et .tld...
Le sousdossier /ressources du dossier WEBINF contient les fichiers de configuration pour les applications : par exemple
les traductions, les fichiers de gestion de Log4J...
Une application Web utilise fréquemment des fichiers ressources qui doivent être placés dans la même
arborescence que les classes, c’estàdire dans le répertoire /WEBINF/classes. Cependant, ces fichiers
ressources seront placés plutôt dans le dossier /WEBINF/src sachant qu’Eclipse recopie automatiquement les fichiers
de ce répertoire vers le répertoire /WEBINF/classes. En effet, lors du rafraîchissement et de la compilation complète
des pages, Eclipse vide le répertoire /WEBINF/classes ce qui est contraignant.
Une application Web est accessible par défaut à l’adresse : http://nomhote:port/webapp/
© ENI Editions - All rigths reserved
- 1-
Ce second exemple présente une application Java EE plus complexe avec :
●
le répertoire /admin pour l’administration,
●
le répertoire /css pour les feuilles de style,
●
le répertoire pour les /images et pour les /javascript,
●
le répertoire /jsp qui contient les JSP non compilées,
●
le répertoire /work qui contient les JSP compilées,
●
le répertoire /logs qui permet de stocker les fichiers journaux Log4J.
Bien sûr, il n’est pas nécessaire de connaître par cœ ur les noms des fichiers, répertoires et l’organisation de
l’arborescence pour développer une application Java EE. Des outils de développement évolués comme Eclipse génèrent
automatiquement l’arborescence à la suite de la création d’un projet Tomcat/Java EE.
1. Le descripteur de déploiement web.xml
Le fichier web.xml contient des informations qui permettent de définir l’environnement d’exécution de l’application
Internet et de lier les composants entre eux. Le fichier permet de définir les relations entre les URL et les Servlets/JSP,
la page d’accueil, la page d’erreur, les contraintes de sécurité, les authentifications, les ressources pour accéder aux
données... Chaque application Web possède son propre fichier de configuration web.xml placé dans le
répertoire /WEBINF de l’application. Ce fichier est appelé le descripteur de déploiement de l’application ou webapp.
Un des avantages de l’utilisation d’un fichier au format XML est le caractère autodescriptif de ce langage. Le fichier
web.xml commence par déclarer l’encodage et le type de grammaire utilisée pour vérifier sa syntaxe (DOCTYPE ou
schéma XML). Le fichier repose sur une DTD, il est donc important de respecter la syntaxe et l’ordre des balises. En
réalité, une application simple n’a pas besoin de ce descripteur car le fichier web.xml du serveur peut suffire mais c’est
une bonne habitude que de toujours définir un fichier de déploiement avec une application.
Tomcat possède un descripteur de déploiement par défaut qui est utilisé pour les applications et qui est placé dans le
répertoire /conf.
Le descripteur de déploiement permet de décrire les éléments suivants :
- 2-
●
les paramètres d’initialisation des Servlets ;
●
les variables globales ;
●
la session de l’application ;
●
les liens entre les URI (Uniform Resource Identifier) et les Servlets ;
●
les classes de gestion des événements ;
© ENI Editions - All rigths reserved
●
les déclarations des filtres ;
●
les liens entre les types MIME et les applications correspondantes ;
●
les pages d’accueil par défaut ;
●
les liens entre les codes d’erreur HTTP et les pages d’erreur ;
●
les ressources telles que JDBC, JNDI...
●
les ressources EJB.
L’élément racine du descripteur de déploiement est la balise . Tous les autres éléments seront donc des
enfants de cette balise. Voici cidessous la liste exhaustive ordonnée des balises du fichier de déploiement web.xml.
L’élément permet de spécifier le chemin vers une icône qui permet de représenter l’application Web pour des
outils de gestion d’applications.
L’élément : ce nœ ud permet d’assigner un nom à l’application Web. Ce nom peut être utilisé par un
outil de gestion d’applications.
L’élément : ce nœ ud permet de décrire l’application de manière textuelle.
L’élément est une balise vide qui permet de distribuer l’application sur plusieurs serveurs (exemple :
cluster de serveurs Tomcat).
L’élément : ce nœ ud permet de définir des paramètres qui seront valables pour l’application. Les
informations seront passées sous forme d’une paire nomvaleur dans la ServletConfig et donc accessibles depuis des
Servlets et pages JSP. Ce principe est très souvent utilisé pour définir des chemins, des fichiers de configuration, des
identifiants... Un paramètre peut aussi être passé à une Servlet précise (et non à toutes comme avec ) en utilisant le nœ ud des Servlets.
L’élément permet de définir une classe de filtre qui sera applicable avant l’exécution de la Servlet. Le principe
de fonctionnement est similaire aux classes Tomcat Valve. Un filtre peut permettre par exemple d’écrire un fichier XSL
pour répondre à un contenu XML si la requête se termine par .xml ou en HTML si elle se termine par .html.
L’élément : ce nœ ud permet d’associer un filtre à une Servlet spécifique ou à une URL. Les filtres sont
mappés en respectant l’ordre dans lequel ils apparaissent dans le descripteur de déploiement.
L’élément permet de définir un écouteur qui sera appelé suite à un événement particulier.
L’élément permet de définir une Servlet et les attributs. La Servlet sera définie par son nom et sa classe.
L’élément : ce nœ ud permet de mapper un modèle d’URI vers un nom de Servlet défini dans un
nœ ud .
L’élément permet de définir la session de l’application Web avec entre autres le délai d’expiration en
minutes des sessions de l’application.
L’élément : ce nœ ud mappe une extension au type MIME. C’est une association entre les fichiers
publics et des types MIME.
L’élément : ce nœ ud permet de spécifier le ou les fichiers (par ordre de priorité) qui doivent être
servis à partir d’un répertoire lorsque seul le nom du répertoire est spécifié (ex : index.html, index.jsp).
L’élément permet de définir une page d’erreur qui servira en cas de renvoi d’un code erroné suite à une
exception.
L’élément permet de définir l’emplacement des bibliothèques de balises. Le nœ ud mappe un modèle d’URI
vers un fichier de descripteur de bibliothèques de balises.
L’élément : ce nœ ud configure une ressource externe qui peut être utilisée par la Servlet.
L’élément : ce nœ ud configure également une ressource externe qui peut être utilisée par la Servlet.
L’élément permet de configurer la méthode d’authentification et le nom du Realm à utiliser pour
l’application.
L’élément : ce nœ ud définit le nom d’une ressource accessible grâce à l’interface JNDI.
L’élément permet de déclarer une référence distante à un Entreprise JavaBean.
L’élément permet de déclarer une référence locale à un Entreprise JavaBean.
© ENI Editions - All rigths reserved
- 3-
2. Déployer un premier projet
Afin de mettre en application les explications de ce guide, nous allons déployer une première application simple. La
configuration des applications Web déployées au sein du serveur Tomcat se fait à l’aide du fichier /conf/server.xml ou
d’un fichier spécifique par application présent dans /conf/Catalina/localhost/monapplication.xml.
a. Projet simple manuellement
Ces fichiers peuvent être créés à la main car la structure est assez simple mais nous allons dans un premier temps
utiliser l’outil manager de Tomcat qui permet de déployer une application avec une interface Web.
Le lien Tomcat Manager ouvre une fenêtre d’authentification. Les informations de connexion correspondent aux
données insérées lors de l’installation du serveur.
Nous obtenons une page qui liste toutes les applications actuellement déployées sur le serveur.
Pour déployer une nouvelle application, il faut utiliser l’interface en précisant les informations pour le déploiement. La
première partie permet de préciser le contexte (chemin d’accès à l’application par URL). Le second paramètre
optionnel permet d’indiquer le fichier XML pour la configuration de l’application. Le dernier paramètre correspond au
répertoire (ou au fichier .war) qui contient l’application. Si nous utilisons un répertoire, celuici doit d’abord être créé
avant le déploiement de l’application et il doit respecter l’arborescence Java EE (répertoire WEBINF...). Si nous ne
précisons pas de fichier de configuration XML, le projet sera déployé dans le répertoire /webapps de Tomcat et sera
donc directement accessible sans fichier de configuration.
Nous utilisons l’application monapplication1 qui est un simple projet Java EE avec l’arborescence habituelle (/WEB
INF, /WEBINF/classes, /WEBINF/lib, /WEBINF/src) et un simple fichier JSP, index.jsp qui affiche juste le nom de
l’application en HTML et en Java.
monapplication1
<% out.println("mon application1 en Java"); %>
- 4-
© ENI Editions - All rigths reserved
Nous cliquons sur Deploy.
Le déploiement a eu pour effet d’ajouter une copie complète du projet dans le répertoire des webapps de
Tomcat /webapps. Donc, il n’y a pas d’insertion de la configuration dans le fichier server.xml ni de création d’un fichier
particulier pour le contexte (/conf/Catalina/localhost) car tous les fichiers déployés dans le répertoire des webapps du
serveur sont automatiquement exploitables.
Le projet a été copié dans le répertoire des /webapps ce qui signifie que désormais, les fichiers devront être modifiés
dans ce répertoire /webapps/monapplication1.
Notre application est alors accessible à l’adresse suivante : http://localhost:8080/monapplication1/
b. Projet simple avec Eclipse
Pour créer un projet Tomcat avec Eclipse, nous allons utiliser la commande File New Project.
Avant de pouvoir utiliser Tomcat avec Eclipse, il est nécessaire d’installer le plugin Sysdeo comme précisé au
chapitre Objectifs et spécifications de Java EE de ce guide.
© ENI Editions - All rigths reserved
- 5-
L’item Projet Tomcat permet de créer un projet Tomcat sans avoir à écrire le déploiement dans le fichier de
configuration de Tomcat (server.xml) ou un fichier particulier (/conf/Catalina/localhost/) et il permet également de créer
automatiquement l’arborescence du projet.
La seconde page nous demande de définir un nom pour le projet Eclipse. Nous précisons le répertoire sur le disque
(ce répertoire vide doit être créé avant le déploiement) qui recevra le projet Eclipse et l’intégralité de ses fichiers.
- 6-
© ENI Editions - All rigths reserved
Lors de cette dernière étape, nous
http://localhost:8080/monapplication2.
indiquons
le
nom
du
contexte
qui
sera
accessible
à
l’adresse :
Eclipse a alors automatiquement créé l’arborescence nécessaire au projet dans le répertoire sélectionné avec
location.
De même, un fichier nommé monapplication2.xml a été créé par Eclipse dans le répertoire /conf/Catalina/localhost.
monapplication3
<% out.println("mon application3 en Java"); %>
Si nous testons maintenant l’application monapplication3, nous remarquons que celleci n’est pas accessible à
l’adresse suivante : http://localhost:8080/monapplication3/.
En effet, le projet Eclipse monapplication3 existe et il a été inséré dans le fichier /conf/server.xml en fin de fichier.
...
© ENI Editions - All rigths reserved
- 9-
Le problème, c’est que les applications déclarées dans ce fichier nécessitent un redémarrage du serveur. Après cette
action, la connexion à l’adresse suivante : http://localhost:8080/monapplication3/ est opérationnelle.
Nous avons vu plusieurs manières de déployer un projet Java EE avec Tomcat. Nous remarquons rapidement que
l’utilisation d’un fichier spécifique par contexte (/conf/Catalina/localhost) est beaucoup plus souple que la déclaration
dans le fichier de configuration du serveur : server.xml.
En effet, nous n’avons pas besoin de relancer le serveur, de lire tout le fichier server.xml pour la gestion d’une
application et nous obtenons un meilleur découpage...
Pour la suite, nous utiliserons la déclaration des applications avec un fichier par application (/conf/Catalina/localhost).
Supprimer un projet
L’opération de suppression d’un projet avec Eclipse est très simple, il suffit de faire un clic droit sur le nom du projet
et de valider l’action delete. Eclipse demande alors si la déclaration du projet doit être supprimée et également le
répertoire des fichiers sources associés.
3. Déployer un projet Java EE avec un fichier war
Lors de la mise en production d’un projet, un fichier d’empaquetage .war est utilisé pour le déploiement. Dans les gros
projets, ce fichier est créé avec l’outil ANT que nous verrons dans un prochain chapitre. La totalité de l’application Web
est alors contenue dans un fichier portant l’extension .war pour Web ARchive. Ce fichier d’empaquetage est destiné au
déploiement de l’application Web au sein du serveur d’applications. Par la suite, c’est le conteneur du serveur
d’applications qui s’occupe de la mise en œ uvre de l’application.
L’outil jar.exe du JDK Java permet de créer l’application Web au format WAR. Pour l’utilisation de cet outil de
déploiement, nous allons réaliser une copie du répertoire monapplication1 sous le nom monapplicationwar. Ensuite,
nous allons juste changer le contenu de la page index.jsp en indiquant le nom du nouveau projet.
monapplicationwar
<% out.println("monapplicationwar en Java"); %>
Désormais, nous possédons une application complète et utilisable. Pour réaliser la création du fichier .war, nous
ouvrons une console de commande et nous nous plaçons dans le répertoire de l’application afin de respecter
l’organisation des fichiers au sein de l’archive. Ensuite, nous lançons la commande jar (à partir du chemin complet si la
variable d’environnement n’a pas été précisée).
- 10 -
© ENI Editions - All rigths reserved
Le paramètre cvf permet de créer le fichier MANIFEST.MF qui donnera des informations sur la version de l’application, la
version de Java... Un fichier nommé monapplicationwar.war est alors créé.
Pour déployer ce projet, il ne reste plus qu’à déposer ce fichier dans le répertoire /webapps de n’importe quel serveur
compatible Java EE. Comme indiqué précédemment, toutes les applications du répertoire /webapps d’une application
sont automatiquement déployées. Il faut remarquer l’intérêt de développer avec un langage comme Java qui est
portable, plus besoin de se soucier de l’environnement d’exécution final si le standard WAR est respecté.
Nous réalisons juste une copie de notre archive dans le répertoire /webapps de Tomcat. Nous patientons quelques
instants et le serveur déploie automatiquement la nouvelle application en décompressant l’archive dans son
répertoire /webapps. La trace du serveur dans ce cas précis est d’ailleurs observable :
La nouvelle application est déployée, le résultat est visible avec l’interface manager de Tomcat. Il est alors possible
d’accéder directement à l’application sans déclaration dans le serveur d’applications.
© ENI Editions - All rigths reserved
- 11 -
Analyse, monitoring et supervision
1. Présentation
Le système de journalisation de Tomcat et de Java est très complexe et évolué. Tomcat utilise la bibliothèque Jakarta
commonslogging. Cette bibliothèque fait partie du projet Jakarta de la fondation Apache. Le projet contient un
ensemble de bibliothèques de développement Java très variées. La librairie commonslogging est semblable à la
bibliothèque Log4J et permet la journalisation tout comme l’API java.util.logging de Java.
Le fichier de journalisation de Tomcat utilise le fichier de configuration /conf/logging.properties. C’est le principal fichier
de configuration pour le serveur mais chaque application déployée peut fournir son propre fichier loggin.properties dans
son répertoire /WEBINF/classes.
La machine virtuelle de Java est responsable de la réservation de l’espace mémoire nécessaire à l’application. Au
démarrage de l’application, celleci réserve de la mémoire auprès du système d’exploitation. Si l’application nécessite
plus de mémoire que cette valeur limite, alors la machine virtuelle s’arrête en déclenchant l’erreur
java.lang.OutOfMemoryError. Cette erreur est très fréquente en Java et doit donc être évitée au maximum.
Il est donc extrêmement important de mesurer et surveiller la consommation mémoire du serveur dans la machine
virtuelle pour anticiper ce problème. La configuration de la machine virtuelle peut être visualisée par le biais du
manager à cette adresse : http://localhost:8080/manager/status.
On retrouve la quantité de mémoire disponible (Free Memory) dans la machine virtuelle, la mémoire utilisable (Total
Memory) et la mémoire maximum allouable auprès du système (Max Memory).
2. Tester la montée en charge
Nous réaliserons par la suite des tests de montée en charge avec l’outil JMeter. Il est également possible de visualiser
le nombre de connexions JDBC disponibles à un instant précis, le nombre de threads occupés, la mémoire consommée,
les classes chargées...
Java Management Extensions JMX est une API Java conçue pour la supervision des applications. JMX est intégrée à
partir de la plateforme Java 1.5. Actuellement, JMX est le standard pour le développement des outils de supervision et
d’administration dans les technologies Java.
Dans une machine virtuelle Java, il est possible d’associer aux différents objets Java des composants qui permettent
d’obtenir des informations sur l’exécution et le traitement des objets. Ces composants sont appelés des MBeans. Ces
MBeans sont accessibles via l’élément central, le serveur MBeans qui est capable d’utiliser des protocoles variés pour
la connexion d’outils de supervision.
Donc les données des MBeans peuvent être accédées grâce à un client JMX en local ou bien à distance. Tomcat crée
des MBeans dynamiquement pendant son exécution, lorsque des applications déployées fonctionnent sur le serveur.
Les MBeans dynamiques de Tomcat sont créés grâce aux éléments de configuration appelés présents dans
le fichier server.xml.
Les informations JMX sont disponibles à partir du manager à l’URL http://localhost:8080/manager/jmxproxy/. Il est
ainsi possible d’obtenir des informations sur les connecteurs, les threads, les classes...
© ENI Editions - All rigths reserved
- 1-
Il est possible d’utiliser des filtres et par exemple d’afficher uniquement les informations sur les objets MBean de type
ThreadPool http://localhost:8080/manager/jmxproxy/?qry=Catalina:type=ThreadPool,*.
3. JConsole et MC4J, des consoles JMX
L’ergonomie offerte par le manager de Tomcat est limitée et il est assez difficile de comprendre les paramètres en
temps réel. Il existe ainsi plusieurs outils évolués qui permettent d’afficher des rapports détaillés.
a. JConsole
Pour pouvoir obtenir des statistiques en temps réel, il faut utiliser un client lourd JMX. Le logiciel JConsole développé
par Sun et livré en standard avec le JDK 1.6 permet d’utiliser JMX. Son utilisation est assez simple et permet la
création de graphiques en temps réel. Si JConsole est lancé par défaut sans rien indiquer (/jdk/bin/jconsole), nous
obtenons des informations sur la machine virtuelle Java installée sur le poste local. Les données ne sont pas
’’correctes’’ car elles ne concernent pas uniquement la machine virtuelle de Tomcat. Pour cela, il est nécessaire de
configurer Tomcat avec un connecteur en lui passant des options au démarrage (port pour se connecter au serveur
Mbean...). De même, il est important de sécuriser cette connexion par identifiant et mot de passe afin d’éviter à des
- 2-
© ENI Editions - All rigths reserved
hôtes distants de se connecter à notre machine.
Sous Windows
Avant de pouvoir connecter Tomcat à JConsole, il faut configurer la machine virtuelle Java du serveur pour autoriser
l’accès distant de son connecteur. Pour cela, il est nécessaire d’ajouter des options à la machine virtuelle via le script
de démarrage de Tomcat. Pour cela, il est nécessaire de configurer la sécurité d’accès au connecteur.
Sécurité
La configuration de la sécurité démarre par la création des fichiers jmxremote.access et jmxremote.password. Il existe
plusieurs possibilités pour la mise en place de ces fichiers. Ces fichiers peuvent être utilisés dans le répertoire /conf
du serveur Tomcat ou dans le répertoire /jdk/jre/lib/management de l’installation du JDK Java (c’est cette seconde
option qui est utilisée dans ce guide).
Le fichier jmxremote.access permet d’indiquer les noms d’utilisateurs autorisés à utiliser le connecteur ainsi que les
permissions sur le connecteur.
Le fichier jmxremote.password contient les mots de passe associés aux utilisateurs.
Le répertoire /jdk/jre/lib/management contient des fichiers d’exemples qui peuvent être renommés pour l’utilisateur.
Nous allons copier et renommer le fichier jmxremote.password.template en jmxremote.password. Nous ajoutons
ensuite notre utilisateur en fin de fichier.
# Following are two commented-out entries. The "measureRole" role has
# password "QED". The "controlRole" role has password "R&D".
#
# monitorRole QED
# controlRole
R&D
moniteurjava monmotdepasse
Nous pourrons donc utiliser cet utilisateur avec son mot de passe pour se connecter au serveur MBean mais pour le
moment, nous ne pourrons rien faire car l’utilisateur ne possède aucun droit. Le fichier jmxremote.access permet de
définir les droits en fonction des utilisateurs du fichier jmxremote.password.
Nous éditons donc ce fichier et ajoutons la ligne suivante :
# Default access control entries:
# o The "monitorRole" role has readonly access.
# o The "controlRole" role has readwrite access.
monitorRole
readonly
controlRole
readwrite
moniteurjava readwrite
L’option readwrite permet d’indiquer qu’il sera possible de réaliser des opérations de lecture sur les objets MBean
mais aussi d’écriture ce qui est important par exemple pour vider à distance le garbage collector de la machine
virtuelle. Il faut désormais démarrer la machine virtuelle de Tomcat avec un connecteur activé en passant des options
au démarrage. Pour cela si le serveur Tomcat est installé avec une archive, le fichier /bin/catalina.bat peut être
modifié.
Par contre, si le serveur Tomcat a été installé en mode service, c’estàdire avec l’installation pour Windows, ce fichier
n’est pas présent. Il faut dans ce cas ajouter des paramètres dans la console Tomcat ou dans Eclipse pour le
démarrage de Tomcat.
-Dcom.sun.management.jmxremote.port=8364
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=
E:\jdk1.6\jre\lib\management\jmxremote.password
-Dcom.sun.management.jmxremote.access.file=
E:\jdk1.6\jre\lib\management\jmxremote.access
-Dcom.sun.management.jmxremote.ssl=false
© ENI Editions - All rigths reserved
- 3-
Si le serveur est lancé, alors l’erreur suivante est obtenue dans la console d’Eclipse.
Cette erreur indique que le propriétaire du fichier doit être l’utilisateur qui démarre le serveur.
Sous Windows XP, dans le menu Outils, il faut choisir Options des dossiers, puis dans la fenêtre cliquer sur l’onglet
Affichage et décocher Utiliser le partage de fichiers simple. Cette action permet de gérer la sécurité sur les
fichiers.
Il faut ensuite réaliser un clic droit sur le fichier jmxremote.password puis sélectionner l’onglet Sécurité et cliquer sur
le bouton Paramètres avancés. Il faut alors sélectionner l’onglet Autorisations et décocher la case Hérite de l’objet
parent les entrées...
Une boîte de dialogue apparaît alors, il faut répondre Copier à la question posée.
Ensuite, dans la partie Autorisations, il faut supprimer tous les utilisateurs autorisés et sélectionner l’utilisateur
Administrateur du système qui a les droits sur la machine virtuelle Java.
- 4-
© ENI Editions - All rigths reserved
Nous ne devons nous retrouver qu’avec notre utilisateur autorisé.
Le serveur Tomcat peut être lancé, le message d’erreur disparaît. Désormais si nous lançons l’outil JConsole, nous
pourrons toujours nous connecter en local mais également à la partie des objets MBean qui contrôlent Tomcat.
Pour cela, il faut utiliser nos informations de connexion.
© ENI Editions - All rigths reserved
- 5-
Le champ Remote Process correspond à l’adresse locale de la machine et au port MBeans. Les champs Username et
Password correspondent aux informations de connexion du fichier jmxremote.password.
Dans ce cas de figure, les indications sont correctes et conformes à celles indiquées par le manager de Tomcat. Des
informations précises sur les applications déployées par le serveur sont obtenues. Dans le premier onglet, il y a un
résumé pratique avec les Threads exécutés, la consommation de la mémoire et les classes chargées. Le deuxième
onglet permet d’afficher des informations sur la consommation mémoire ce qui est indispensable lors de
développement de gros projets afin de vérifier si les connexions JDBC ne sont pas fermées, si des classes ou
Servlets consomment trop de mémoire... Les derniers onglets permettent d’avoir des informations sur les Threads,
classes, objets MBean et la machine virtuelle.
- 6-
© ENI Editions - All rigths reserved
Nous voyons ici un fonctionnement conforme de la mémoire avec les parties chargement et déchargement.
Sous Linux
Sous Linux l’installation est pratiquement identique. Nous éditons le fichier /usr/local/tomcat/bin/catalina.sh qui
permet de démarrer Tomcat. Nous ajoutons alors uniquement les deux lignes suivantes en milieu de fichier vers la
ligne 260 qui est relative à la variable JAVA_OPTS et qui correspond au démarrage.
-Dcom.sun.management.jmxremote.port=8364
-Dcom.sun.management.jmxremote.ssl=false
Nous procédons ensuite comme sous Windows et nous copions le fichier d’exemple jmxremote.password.template en
jmxremote.password.
#cp /usr/local/jdk/jre/lib/management/jmxremote.password.template
/usr/local/jdk/jre/lib/management/jmxremote.password
Nous modifions les droits sur ce fichier.
#chmod 744 jmxremote.password
Comme sous Windows, nous ajoutons notre utilisateur JMX au fichier jmxremote.password.
#
#
#
#
#
Following are two commented-out entries. The "measureRole" role has
password "QED". The "controlRole" role has password "R&D".
monitorRole
controlRole
QED
R&D
moniteurjava monmotdepasse
Pour la gestion des droits sur le fichier, c’est plus simple que sous Windows, il suffit de positionner les droits suivants
sur le fichier.
#chmod 600 jmxremote.password
© ENI Editions - All rigths reserved
- 7-
Ensuite, ce qui est important c’est que l’utilisateur qui lance la JVM soit le propriétaire de ce fichier.
#chown tomcat:tomcat jmxremote.password
Désormais, nous allons déclarer nos droits avec le fichier jmxremote.access.
# o The "monitorRole" role has readonly access.
# o The "controlRole" role has readwrite access.
monitorRole
readonly
controlRole
readwrite
moniteurjava readwrite
L’application de supervision et le connecteur sont désormais opérationnels. Il est donc possible d’utiliser une
interface distante pour se connecter au serveur et obtenir des informations de supervision.
b. MC4J
MC4J est une application JMX encore plus puissante que JConsole. Ce logiciel libre simple d’utilisation est
téléchargeable à l’adresse suivante : http://mc4j.org.
Ce logiciel est orienté vers la supervision des serveurs d’applications Java EE. MC4J est par exemple compatible avec
Tomcat, JBoss, Weblogic, WebSphere... Il est également disponible pour la majorité des systèmes d’exploitation avec
une version pour Windows, Linux et Mac OS X. Après le téléchargement et l’installation du logiciel, il peut être lancé
depuis la machine locale ou n’importe quelle machine distante capable d’accéder à la machine locale.
Après le démarrage de MC4J, il faut configurer une connexion au serveur Tomcat en choisissant Create Server
Connection dans le menu Management de l’interface graphique. En premier, le type de serveur auquel se connecter
doit être indiqué. Il faut ensuite donner un nom à notre connexion et le numéro de port pour la connexion. Ensuite, si
la sécurité est activée sur le serveur d’applications, il faut saisir les informations d’authentification.
- 8-
© ENI Editions - All rigths reserved
Lors de la deuxième étape, l’assistant demande de préciser le répertoire d’installation de Tomcat. Dans le cas où
MC4J et le serveur Tomcat à superviser sont sur des machines différentes, il faudra tout de même installer une
version de Tomcat en local (avec une version identique du serveur à superviser) car MC4J utilise les classes de
Tomcat pour la supervision.
Une fois la connexion établie, l’écran principal de la console MC4J apparaît avec la liste des MBeans du serveur. Le
temps de chargement peut parfois être assez long en fonction de la connexion réseau et de la taille du projet à
superviser. Beaucoup d’informations utiles pour la supervision du projet sont alors affichées comme les classes
chargées en mémoire, les connexions JDBC, les requêtes des clients.
Avec un outil comme MC4J, il est désormais assez facile de suivre l’évolution en temps réel des ressources internes
du serveur pendant un test de montée en charge ou le développement de celuici. Cet outil est également très
pratique sur un serveur en production, il fait partie des logiciels indispensables d’un administrateur de serveur Java
EE.
© ENI Editions - All rigths reserved
- 9-
4. JMeter et les tests de montée en charge
Après avoir correctement configuré le serveur et les outils de supervision, il est essentiel d’installer un outil pour tester
la montée en charge du serveur. Il est important d’utiliser ces outils lors de développement Java EE afin de simuler la
- 10 -
© ENI Editions - All rigths reserved
charge et d’en mesurer l’impact et les conséquences afin de valider les choix de développement, les pages de code...
Par exemple, lors du développement d’une application Java EE de gestion et de traitement d’images, il sera nécessaire
de bien vérifier que lors de l’appel par 100 utilisateurs en simultané, le serveur peut répondre dans un délai
raisonnable, que l’application ne va pas saturer la mémoire allouée au serveur... De même, lors d’un choix de
conception sur un composant de programmation, l’outil de test pourra nous permettre de valider les librairies, logiciels
ou architectures (ex : JDBC ou Hibernate). Il existe plusieurs outils sur le marché pour les tests de montée en charge,
tels que l’outil LoadRunner de Mercury et le logiciel libre Apache JMeter.
Apache JMeter
JMeter est un outil écrit en Java et développé par la fondation Apache. JMeter peut générer des tests sur les serveurs
Web HTTP et HTTPS, des bases de données avec JDBC, des annuaires et des serveurs FTP. JMeter fournit enfin un
ensemble d’outils pour collecter et mesurer les résultats des tests. Du point de vue de la programmation, il pourra
analyser plusieurs types de ressources comme des fichiers Java, des Servlets et pages JSP. Apache JMeter est 100 %
Java, il requiert donc juste une machine virtuelle Java pour fonctionner et lancer les tests.
JMeter peut être installé sur la même machine que le serveur d’applications, mais afin de ne pas fausser les
tests, il vaut mieux éviter d’exécuter JMeter et Tomcat sur les mêmes machines.
L’installation de JMeter est simple, il faut télécharger les fichiers binaires de JMeter sur le site
http://jakarta.apache.org/jmeter. Il y a une archive au format .zip pour Windows et .gz pour Linux. L’installation
nécessite simplement la décompression de l’archive dans un répertoire du système. Il est bien sûr indispensable
d’avoir installé au préalable un JRE ou JDK correctement avec la variable d’environnement JAVA_HOME paramétrée.
Pour lancer JMeter, il faut utiliser le script /bin/jmeter.bat ou l’exécutable /bin/jmeter.exe sous Windows et la
commande /bin/jmeter sous Linux.
Il est possible d’ajouter des librairies à JMeter pour tester des connexions JDBC par exemple. Pour cela, il
suffit de copier la librairie dans le répertoire /lib et /lib/ext de JMeter.
Si JMeter détecte une erreur, celleci sera écrite dans le fichier de log appelé /log/jmeter.log. Ce fichier est créé au
lancement de l’application. Le fichier de configuration de JMeter pour SSL, proxy et utilisateurs
est /bin/jmeter.properties.
Utilisation
Au démarrage de l’interface, le plan de tests (Test Plan) et le plan de travail (WorkBench) sont affichés. Un plan de test
permet de décrire la série de tests à exécuter par JMeter. Pour ajouter ou supprimer un plan de tests, il faut faire un
clic droit dans l’explorateur. Il est également possible de charger des éléments de tests présents dans un fichier. Un
plan de tests est sauvegardé au format JMX. Un plan de travail contient les éléments qui ne sont pas utilisés par le
plan de tests, il s’agit d’un espace de stockage temporaire.
Avant de commencer l’écriture d’un plan de tests, il est nécessaire de configurer le serveur et les ressources dans des
conditions qui soient le plus proche possible d’un environnement en production. Il faut donc paramétrer correctement
la mémoire allouée, le serveur Tomcat, les connecteurs aux bases de données...
Un plan de tests consiste à tester la montée en charge du serveur en simulant des accès distants.
Il existe plusieurs étapes essentielles pour la construction d’un plan de test :
●
Définir le groupe de threads qui simulent le nombre de requêtes en direction du serveur. Un thread est en fait
un utilisateur potentiel qui navigue sur le site en production.
●
Écrire la configuration du serveur en précisant le nom de la machine en production, le port à utiliser, le
protocole...
●
Écrire les requêtes HTTP à invoquer par les utilisateurs.
●
Ajouter un ou plusieurs composants de mesure JMeter qui va (ou vont) analyser et traiter les réponses sur la
charge.
●
Enregistrer le plan de tests et le lancer.
Créer un plan de tests
La première étape consiste à créer les utilisateurs (Threads) qui vont envoyer des requêtes au serveur. Nous allons
créer par exemple 5 utilisateurs qui vont envoyer des requêtes à 2 pages du site, 2 fois de suite. Il y aura donc au
© ENI Editions - All rigths reserved
- 11 -
total : 5 utilisateurs * 2 pages * 2 appels = 20 requêtes.
Utilisateur
Il faut ajouter un groupe d’utilisateurs (ThreadGroup) à notre plan de tests.
Nous faisons un clic droit sur le plan de tests et l’action Ajouter Groupe de Thread.
L’écran affiché permet de configurer le nombre de Threads ainsi que l’intervalle de temps pendant lequel ils seront
démarrés. La propriété Nombre de Threads (Number of Thread) correspond au nombre d’utilisateurs, dans notre
exemple : 5. La propriété Période de chauffe (RamUp) définit le nombre de secondes entre le déclenchement de
chaque utilisateur. En positionnant à 0, JMeter va démarrer tous les utilisateurs en même temps et donc simuler des
accès simultanés au serveur d’applications. Enfin, la propriété Compteur de Boucle (LoopCount) permet d’indiquer le
nombre de boucles à effectuer sur le serveur. Nous positionnons cette propriété à 2 pour effectuer 2 répétitions. Il est
aussi possible de rejouer cette séquence à l’infini en cochant la case appropriée.
Configuration du serveur
La seconde étape consiste à préciser le serveur d’applications qui sera utilisé pour les tests.
Il faut d’abord sélectionner le groupe de Thread dans le plan de tests. Puis après un clic droit sur cet élément, les
choix Ajouter (Add) Elément de Configuration Requête HTTP Request par défaut sont sélectionnés.
- 12 -
© ENI Editions - All rigths reserved
Les valeurs à préciser sont le protocole utilisé, le nom de domaine du serveur ou son adresse IP et le numéro de port
de celuici. Des paramètres aux requêtes peuvent être également ajoutés. Dans ce cas, ils seront transmis avec
toutes les requêtes en direction du serveur.
Écrire les requêtes utilisateurs
Lors de cette troisième étape, il est temps d’écrire les requêtes HTTP, l’objectif étant de simuler la navigation d’un
utilisateur sur le site en production.
D’après notre plan de tests, il faut utiliser deux requêtes HTTP. La première pour la page d’accueil du site
http://127.0.0.1:8080/index.jsp et la seconde vers une page d’aide http://127.0.0.1:8080/aide.jsp.
JMeter va donc envoyer les requêtes dans l’ordre où elles apparaissent dans l’arbre.
Pour ajouter une page, il faut faire un clic droit sur notre groupe de Threads dans notre plan de travail et ajouter une
requête HTTP.
© ENI Editions - All rigths reserved
- 13 -
La configuration du serveur a été réalisée précédemment, il n’y a donc que très peu d’éléments à renseigner. Les
éléments indispensables sont la méthode HTTP à utiliser (GET ou POST ) ainsi que le nom et le chemin de la ressource.
Nous donnons un nom explicite à notre requête (page d’accueil) et nous positionnons le chemin d’accès à la page (/
étant donné que c’est la racine du site).
Nous réalisons ensuite la même opération pour notre seconde page/requête.
Ajouter un écouteur/composant de mesure
Lors de cette étape, il faut ajouter un ou plusieurs écouteurs pour analyser les tests. Pour ajouter un moniteur de
résultats, nous réalisons un clic droit sur le groupe de Thread dans notre plan de tests et nous ajoutons par exemple
un écouteur graphique. Nous précisons alors un fichier de sauvegarde pour les résultats en utilisant le bouton
Parcourir. Le fichier de sortie est au format .jtl.
- 14 -
© ENI Editions - All rigths reserved
Enregistrer et lancer le plan de tests
L’enregistrement du plan de tests n’est pas obligatoire mais conseillé. Pour sauvegarder un plan de tests, il faut
sélectionner l’item Enregistrer du menu et préciser un nom de fichier .jmx.
Pour lancer l’exécution du plan de tests, il faut utiliser le menu Démarrer (Run). JMeter indique alors avec un petit carré
vert lumineux en haut à droite de la fenêtre principale l’exécution des tests. Le rectangle repasse en gris quand les
tests sont arrêtés. Après avoir sélectionné Stop, le rectangle vert reste allumé jusqu’à la fermeture de tous les
Threads.
Il est possible d’ouvrir le même plan de tests avec plusieurs fenêtres d’analyse sans problème. Il est également
possible d’utiliser des boucles infinies pour simuler des accès en temps réel sur une plus grande période.
Les résultats d’analyse peuvent être de toute sorte comme des graphiques, des tableaux de données, des arbres...
JMeter est un outil très puissant qui permet d’analyser en temps réel la montée en charge d’un serveur. Les résultats
graphiques, textuels et sous forme d’arbres sont très précieux en phases de développement et de production.
© ENI Editions - All rigths reserved
- 15 -
ApacheTomcat et SSL/HTTPS
1. Présentation
Le serveur Tomcat propose dans sa configuration par défaut un connecteur HTTPS préconfiguré. La configuration est
en commentaire dans le fichier principal server.xml. Il est donc très simple d’activer ce connecteur en réactivant cette
ligne et en utilisant des clés de cryptage conformes.
Le connecteur HTTPS de Tomcat utilise l’élément de configuration avec le port SSL indiqué (8443). Cet
élément possède les mêmes attributs que les autres connecteurs mais également les attributs keystoreFile (chemin
de stockage des clés), keystorePass (mot de passe du fichier de stockage des clés), sslProtocol (le protocole utilisé par
HTTPS), clientAuth (certificat client obligatoire ou non), truststoreFile (fichier de validation des certificats clients),
truststorePass (le mot de passe du fichier des certificats clients).
Voici la configuration que l’on peut utiliser avec un certificat autosigné.
DocumentRoot /usr/local/tomcat/webapps/monprojet
ServerName monprojet.com
ServerAlias *.monprojet.com
CustomLog /var/log/apache/monprojet-access_log combined
Port 443
SSLRequireSSL
SSLEnable
Alias /javascript /usr/local/tomcat/webapps/monprojet/javascript
JkUnMount /javascript/* worker1
JkAutoAlias /usr/local/tomcat/webapps/monprojet/
AllowOverride None
deny from all
AllowOverride None
deny from all
JkMount worker1
JkMount worker1
DirectoryIndex index.html index.htm index.php index.jsp
...
SSLEnable
© ENI Editions - All rigths reserved
- 1-
...
SSLCertificateFile /etc/apache-ssl/cles/monprojet.cert
SSLCertificateKeyFile /etc/apache-ssl/cles/monprojet.key
2. En résumé
Ce chapitre a présenté le serveur d’applications ApacheTomcat. La première partie a concerné l’installation de
Tomcat, la réalisation d’un script de gestion du serveur et la présentation des fichiers journaux.
Dans un deuxième temps, le guide a introduit la mise en place de la partie administration et la gestion de la mémoire
allouée au serveur.
La troisième partie plus technique, a précisé comment coupler Tomcat avec le serveur Web Apache.
L’architecture de Tomcat avec l’arborescence et les fichiers de configuration au format XML ont été également
détaillés.
Puis un bref rappel XML a été évoqué afin de pouvoir manipuler les fichiers de configuration du serveur Java EE. Cette
étape a été suivie d’une présentation de l’arborescence d’un projet/webapp Tomcat avec l’introduction du descripteur
de déploiement web.xml et le déploiement d’un premier projet simple.
L’avantdernière partie a concerné la supervision, le monitoring du serveur et de ses applications déployées. L’outil
JMX intégré à Tomcat et les outils de manipulation JConsole et MC4J ont été détaillés, suivis de la mise en œ uvre de
JMeter pour les tests de montée en charge.
Enfin la dernière partie a été axée sur la mise en œ uvre de Tomcat avec l’utilisation du protocole HTTPS.
- 2-
© ENI Editions - All rigths reserved
Qu’estce qu’une JavaServer Page ?
1. Présentation
Une page JSP est une page HTML qui peut contenir du code Java. D’un point de vue technique, il est possible de faire
la même chose avec une page JSP qu’avec une Servlet. La différence est essentiellement au niveau de la structure.
Une page JSP est un squelette de page HTML qui contient des morceaux de code Java permettant de réaliser des
traitements dynamiques ou d’intégrer des données. Une Servlet est à l’inverse, plutôt composée de code Java et
parfois de portions de code HTML pour la gestion de l’affichage.
La technologie JSP permet l’utilisation et la création de
étendre les possibilités de développement. Le mécanisme
des données de la logique métier, contrôlant la valeur
compilées par le moteur JASPER pour devenir des Servlets
balises JSP (taglib) qui ajoutent des fonctionnalités pour
JSP permet de séparer la logique contrôlant la présentation
des données. D’un point de vue technique, les JSP sont
Java.
Il existe également des actions JSP (balises XML) qui appellent des fonctions afin de rendre un service spécifique :
inclusion de page, redirection...
Le principe de fonctionnement est très proche des langages PHP et ASP mais à l’inverse de ces mécanismes, JSP
compile le code au lieu de l’interpréter à chaque fois, ce qui soulage la charge de traitement du serveur.
2. Introduction
Les pages JSP sont exécutées par le serveur d’applications pour répondre aux requêtes des clients. Les JSP ont
plusieurs fonctionnalités :
●
la création de sites Web dynamiques (pages Web dynamiques) ;
●
le travail avec des bases de données ;
●
l’amélioration de la sécurité (le code est exécuté par le serveur et donc non accessible par les clients).
●
l’utilisation des JavaBeans (simplicité du code, manipulation d’objets simples...) ;
●
l’utilisation de balises personnalisées (taglib).
Avec ce modèle de programmation, il est plus aisé de scinder le développement d’une application Web : le graphiste
s’occupe de la partie présentation HTML et le développeur s’occupe de la partie logique avec les traitements et l’accès
aux données.
Côté serveur, une page JSP est interprétée une seule fois, soit lors du premier appel, soit lors du lancement du
conteneur Web. En fait, le conteneur Web crée une Servlet à partir de la page JSP. La Servlet est ensuite compilée,
chargée en mémoire (s’il n’y a pas d’erreur) et mise en service pour répondre aux requêtes clients.
Il existe une Servlet système dans le conteneur Java EE qui est configurée pour traiter les ressources concernant les
fichiers portant l’extension .jsp et .jspf (javax.servlet.jsp et javax.servlet.jsp.tagext) .
3. JASPER
Les JSP sont compilées par le compilateur JASPER (il en existe d’autres) pour devenir des Servlets JAVA. Tomcat
intègre un moteur de Servlets appelé CATALINA. JASPER génère une Servlet source Java (fichier .java) qui est à son
tour compilée par CATALINA pour devenir une Servlet exécutable (fichier .class). La syntaxe propre à Java est
encadrée par des balises <% et %>, ce qui explique au compilateur JASPER que le reste du code doit être traité
comme du langage HTML.
4. Cycle de vie d’une Servlet
Une JSP est composée de texte brut contenant du code HTML et du code Java. Lors du premier appel de la page par
un utilisateur distant, la page JSP est traduite en une Servlet Java par l’intermédiaire du parseur JSP contenu dans le
serveur Java EE.
© ENI Editions - All rigths reserved
- 1-
Le compilateur va ensuite traduire ce fichier Java généré, en un fichier .class, et ce nouveau fichier .class est alors
exécuté par la machine virtuelle.
La transformation de la page .jsp en Servlet .class n’est effectuée qu’une seule fois, lors du premier appel de la page.
C’est pour cela, que le premier chargement de la page est beaucoup plus long que les suivants, qui ne nécessitent
pas cette étape. Les utilisateurs suivants n’auront pas ce temps d’attente puisque la page est déjà compilée et
chargée en mémoire. En cas de modification de la page, celleci est à nouveau compilée et mise à jour
automatiquement.
Le cycle d’une page JSP comporte quatre phases :
●
Chargement et instanciation : le serveur localise la classe Java correspondant à la page JSP et la charge
dans la machine virtuelle.
●
Initialisation : la page JSP est initialisée selon le principe d’une Servlet.
●
Traitement des requêtes clients : la page répond aux requêtes des clients. Aucun code Java n’est envoyé
aux clients.
●
Fin du cycle : toutes les requêtes sont traitées et terminées, les instances de la classe sont détruites.
Lorsqu’un client envoie une requête à une page JSP, le serveur transmet celleci au conteneur de JSP et celuici
détermine la classe d’implémentation qui devra la traiter.
- 2-
© ENI Editions - All rigths reserved
Une page JSP est en fait une Servlet ce qui signifie que tout ce qui est utilisable pour une Servlet (cookies, sessions,
context...) peut être également mis en œ uvre dans les pages JSP.
Pour résumer, les développeurs et concepteurs graphique utilisent la technologie JSP pour développer rapidement
des pages Web dynamiques au contenu riche. Les pages JSP peuvent être créées facilement et entretenues car elles
sont basées sur du code HTML et XML. Toute la puissance de Java est alors cachée derrière les pages JSP.
© ENI Editions - All rigths reserved
- 3-
Déclarations, commentaires et scriptlets
1. Présentation
Une page JSP porte l’extension .jsp et doit être accessible avec un navigateur dans l’arborescence du serveur Java EE.
Les pages sont placées dans le répertoire de l’application (webapp) à partir de la racine ou dans un répertoire
spécifique (/jsp, /vues, /vues/articles/...). Les pages JSP sont conçues pour avoir un comportement dynamique et elles
sont chargées de répondre aux requêtes envoyées par les clients. C’est le code Java inséré dans le code HTML qui
permet ce comportement dynamique.
2. Les éléments JSP
Nous avons besoin, comme pour d’autres langages de scripts (ex : PHP), d’indiquer au serveur où commence et
s’arrête le code HTML et le code Java. Pour cela, la spécification JSP définit des balises qui peuvent être employées
pour délimiter le code. Ces balises permettent de définir trois catégories d’éléments :
●
Les directives : informations sur la page.
●
Les scripts : placement du code dans la page.
●
Les actions : inclusion de code basé sur des balises dans la page courante.
3. Les directives
Les directives sont des éléments qui permettent de préciser des informations relatives à la page. Il existe les trois
directives suivantes : page, include et taglib. Les directives JSP commencent par <%@ et se terminent par %>. Les
directives sont parfois appelées directives de moteur JSP. Elles fournissent des instructions et des paramètres qui
déterminent la façon dont une page JSP est traitée. Par contre, une directive n’affecte que la page JSP qui la contient.
Chaque directive a des attributs auxquels peuvent être affectées des valeurs spécifiques. L’instruction de directive
inclut le nom de la directive, suivi de l’attribut et des paires de valeurs dont l’utilisation est souhaitée.
La directive page
L’élément directive de page permet de définir les attributs de la page JSP, comme les importations de classes ou
paquetages, la page invoquée en cas d’erreur, le type de contenu... La directive page peut être définie plusieurs fois
dans un même document. Il est recommandé de toujours placer cette directive en tout début de document pour une
question de logique et de lisibilité.
Nous pouvons développer une page d’erreur générique pour le projet betaboutique. Cette page est placée dans un
répertoire nommé /vues afin de bien séparer les éléments de traitements (Servlets) des éléments d’affichage (JSP).
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
ERREURS
<%
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
%>
Les erreurs suivantes se sont produites
<%
for(int i=0;i"+(String)erreurs.get(i)+"");
}
© ENI Editions - All rigths reserved
- 1-
%>
Il faut remarquer la définition de la directive page qui permet à la première ligne, par l’intermédiaire de ses attributs,
d’indiquer le langage utilisé, le type mime et l’encodage.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
L’attribut language permet de préciser le langage utilisé, Java dans tous les cas. L’attribut contentType indique le type
MIME utilisé par la page JSP. L’attribut pageEncoding indique le type d’encodage de caractère utilisé dans la JSP pour la
réponse HTTP. Il existe plusieurs autres attributs comme errorPage qui permet de spécifier la page JSP à afficher en cas
d’erreur. L’attribut info permet de faire une description de la JSP et peut être récupéré par l’instruction getServletInfo().
L’attribut session permet par exemple d’indiquer si le contexte de session HTTP est accessible ou non dans la JSP.
Il est possible de modifier la première ligne de cette page et l’attribut contentType pour afficher du texte brut.
<%@ page language="java" contentType="text/plain;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
Il y a également sur la seconde ligne du fichier un autre exemple d’utilisation de la directive page avec l’importation de
la classe Java ArrayList pour la manipulation d’une collection d’objets.
<%@ page import="java.util.ArrayList" %>
De cette manière, les objets ArrayList, ainsi que toutes les fonctions de cette classe, pourront être manipulés et
utilisés.
La directive include
Nous pouvons également modifier légèrement notre page d’erreur pour utiliser le second type de directive, à savoir la
directive include. Dans notre exemple, une page HTML statique est utilisée pour inclure un message descriptif en début
de la JSP. Une autre page JSP pourra bien entendu être incluse sans problème.
Le projet betaboutique utilise une Servlet d’authentification nommée ServletAuthentification qui permet de vérifier la
syntaxe de l’identifiant et du mot de passe. En cas d’erreur, les données sont transférées à la page JSP erreurs.jsp.
Cette page est chargée d’afficher les raisons de l’échec de l’authentification. Voici le code de cette page avec l’inclusion
d’une page d’entête au format HTML.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
<%@ include file="enteteerreurs.html" %>
ERREURS
<%
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
%>
Les erreurs suivantes se sont produites
<%
for(int i=0;i"+(String)erreurs.get(i)+"");
}
%>
Si aucune directive n’est utilisée dans une page JSP, le moteur JSP du serveur Web utilisera ses propres
paramètres par défaut. Par exemple, si la directive page avec l’attribut contentType est omise, le moteur JSP
- 2-
© ENI Editions - All rigths reserved
affichera automatiquement les informations comme une page WEB (contentType=’’text/html’’).
Chaque page JSP compilée est transformée en une Servlet placée dans le répertoire /work/org/apache/jsp. Pour cette
page nommée erreurs.jsp, la Servlet générée est présente sous le nom : /work/org/apache/jsp/erreurs_jsp.jsp. Son
code compilé est présent dans le fichier : /work/org/apache/jsp/erreurs_jsp.class.
Voici le code de la JSP transformée en Servlet par le moteur JSP :
package org.apache.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import java.util.ArrayList;
public final class erreurs_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {
private static java.util.List _jspx_dependants;
static {
_jspx_dependants = new java.util.ArrayList(1);
_jspx_dependants.add("/enteteerreurs.html");
}
public Object getDependants() {
return _jspx_dependants;
}
public void _jspService(HttpServletRequest request,
HttpServletResponse response)
throws java.io.IOException, ServletException {
JspFactory _jspxFactory = null;
PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;
PageContext _jspx_page_context = null;
try {
_jspxFactory = JspFactory.getDefaultFactory();
response.setContentType("text/html; charset=ISO-8859-1");
pageContext = _jspxFactory.getPageContext(this, request,
response, null, true, 8192, true);
_jspx_page_context = pageContext;
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
out.write(’\r’);
out.write(’\n’);
out.write("ERREURS SUR LA PAGE ERREURS \n");
out.write("\n");
out.write("\r\n");
out.write("\r\n");
out.write(’\n’);
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
out.write("\r\n");
out.write("Les erreurs suivantes se sont
© ENI Editions - All rigths reserved
- 3-
produites \r\n");
out.write("\r\n");
out.write("\t");
//commentaire monoligne
/* commentaire multilignes */
for(int i=0;i");
out.print( this.miseEnFormeMessage((String)erreurs.get(i)) );
out.write("\r\n");
out.write("\t");
}
out.write("\r\n");
out.write(" \n");
out.write("\n");
out.write("\r\n");
} catch (Throwable t) {
if (!(t instanceof SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t);
}
} finally {
if (_jspxFactory != null)
_jspxFactory.releasePageContext(_jspx_page_context);
}
}
}
La directive taglib
Le dernier type de directive JSP est l’utilisation de librairies externes personnalisées, par le biais de la directive taglib
(<%@ taglib ...%>), que nous utiliserons dans le chapitre dédié à cette technologie.
4. Les scripts
Les scripts sont des éléments qui permettent de placer le code Java dans les pages JSP. Il existe trois types de
scripts :
●
Les déclarations : pour déclarer et/ou initialiser une variable.
●
Les scriptlets : pour contenir les instructions Java.
●
Les expressions : pour renvoyer des informations aux utilisateurs.
Il peut y avoir une partie de script, du code HTML, puis de nouveau du script dans une même page à condition que
chaque morceau de script soit bien entouré par les balises Java.
a. Les déclarations
Une déclaration est employée pour introduire et éventuellement initialiser une variable ou une méthode Java, comme
dans un programme. Une déclaration permet de définir un bloc pour les variables globales ainsi que pour des
méthodes qui pourront ensuite être utilisées dans le reste du document JSP. Ce principe est très pratique pour
l’utilisation de méthodes, car en Java tout est objet, et donc nécessite la déclaration de classes. Cependant, cette
technique autorise la simple utilisation de méthodes sans classe et objet.
Pour créer une déclaration, il faut placer le code entre le délimiteur d’ouverture <%! et le délimiteur de fermeture %
>. Les déclarations peuvent être placées à n’importe quel endroit dans une page JSP, mais il est préférable comme
pour les directives, de les placer en début de fichier.
Nous allons modifier notre page d’erreur JSP afin d’ajouter une méthode qui permet d’insérer la balise HTML de
couleur rouge pour les messages d’erreurs.
- 4-
© ENI Editions - All rigths reserved
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ include file="enteteerreurs.html" %>
<%@ page import="java.util.ArrayList" %>
<%!
//retourner le message en couleur rouge
private String miseEnFormeMessage(String message)
{
return ""+message+" ";
}
%>
ERREURS
<%
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
%>
Les erreurs suivantes se sont produites
<%
for(int i=0;i"+this.miseEnFormeMessage((String)
erreurs.get(i))+"");
}
%>
b. Les scriptlets
Les scriptlets contiennent des instructions Java. Une scriptlet est un bloc de code incorporé dans une page. Le code
écrit dans une scriptlet est en Java. De même, les scriptlets peuvent contenir n’importe quel code Java valide. Une
page contenant une scriptlet est souvent appelée un modèle. Pour ajouter une scriptlet à une page, il faut placer le
code entre le délimiteur d’ouverture <% et le délimiteur de fermeture %>.
À l’intérieur d’une scriptlet l’objet out peut être utilisé avec la méthode print (ou println) pour générer du contenu
texte à destination du client. Les visiteurs qui invoquent la page JSP ne pourront pas voir le code Java contenu dans
cette page même s’ils affichent le code source de la page avec leur navigateur Web, ce dernier ne contenant que la
sortie générée après traitement.
La partie de code présente dans la page d’erreur précédente correspond à une scriptlet.
<%
for(int i=0;i"+this.miseEnFormeMessage((String)
erreurs.get(i))+"");
}
%>
Le code d’une scriptlet ressemble beaucoup à l’élément déclaration des scripts, cependant il existe plusieurs
différences entre les deux syntaxes :
●
Les scriptlets ne peuvent être employées pour définir des méthodes. Seules les déclarations permettent
cela.
●
Les variables déclarées dans une déclaration sont des variables d’instance (donc accessibles dans toutes les
scriptlets de la page).
© ENI Editions - All rigths reserved
- 5-
●
Les variables déclarées dans une scriptlet sont locales (donc visibles uniquement à l’intérieur du bloc dans
lequel elles sont définies).
c. Les expressions
Les expressions sont utilisées pour renvoyer au client les valeurs d’expressions Java. Elles permettent en effet de
générer une sortie sur une page JSP. Souvent, les expressions sont utilisées comme raccourcis pour simplifier le
code. Par exemple, le code out.println(...) peut être remplacé par l’expression <%= %>. Le serveur Java EE traite le
code contenu dans l’expression et convertit le résultat en une chaîne.
Une expression ne peut pas s’achever par un point virgule. Si un point virgule est utilisé dans une expression, une
erreur se produira. En effet, l’expression suivante <%= exp > est convertie par le compilateur en la scriptlet suivante
<% out.println(exp); %>.
Une expression peut contenir un appel de méthode, une instruction ou autre. Nous allons modifier notre page
d’erreur du projet betaboutique afin d’utiliser une expression à la place de l’objet out.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ include file="enteteerreurs.html" %>
<%@ page import="java.util.ArrayList" %>
<%!
//retourner le message en couleur rouge
private String miseEnFormeMessage(String message)
{
return ""+message+" ";
}
%>
ERREURS
<%
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
%>
Les erreurs suivantes se sont produites
<%
for(int i=0;i
<%= this.miseEnFormeMessage((String)erreurs.get(i))%>
}
%>
d. Les commentaires
L’ajout de commentaires permet de clarifier le code HTML et JSP. Il est possible d’utiliser des commentaires HTML
dans les pages JSP. Ces commentaires apparaissent dans la page renvoyée au navigateur client. Ils sont alors de la
forme suivante : .
Ce commentaire n’apparaît pas dans la page du client mais peut être visualisé dans le source HTML avec l’outil du
navigateur. Il existe également la possibilité d’ajouter des commentaires dans le code JSP en utilisant les balises
suivantes : <% un commentaire JSP qui ne sera pas renvoyé au client %>.
L’ensemble des informations et du code placé entre les balises de commentaire JSP sera supprimé avant le
traitement de la page JSP sur le serveur Web et ne sera pas renvoyé au client.
Par contre, un commentaire JSP est de la même forme qu’un commentaire HTML, il ne doit pas se placer dans du code
Java (une scriptlet). Les scriptlets sont codées en langage Java, les commentaires Java sont donc appliqués. On
retrouve les types monoligne // et multilignes /* */.
- 6-
© ENI Editions - All rigths reserved
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
COMMENTAIRES
<%-- un commentaire JSP qui ne sera pas renvoyé au client --%>
<%
//commentaire monoligne
/* commentaire multilignes */
%>
e. Les actions
Les actions dans une page JSP sont écrites sous la forme d’éléments XML et permettent de condenser en une seule
ligne un traitement qui serait plus long à écrire à l’aide d’un script Java. Il existe deux types d’actions :
●
Les actions standards.
●
Les actions personnalisées.
Les actions standards sont définies par la spécification JSP (d’où le nom standard) et sont les actions de base,
accessibles à toutes les pages JSP, car définies dans l’API Java EE. Les éléments XML correspondant, commencent
tous par le préfixe jsp. Les actions personnalisées viennent enrichir les actions standards en offrant d’autres
possibilités. Ces librairies sont déclarées par la directive taglib vue précédemment (<%@ taglib prefix=’’...’’ uri=’’...’’ %
>). Pour le moment nous allons étudier les librairies standards avant d’aborder par la suite les librairies
personnalisées.
La spécification JSP définit les actions standards suivantes :
●
●
●
●
●
●
●
, ,
●
●
●
●
, ,
Ces actions standards sont certainement les plus importantes. Elles permettent de créer ou d’importer un JavaBean
© ENI Editions - All rigths reserved
- 7-
dans la page et de le manipuler. L’action BIENVENUE
<%
Client client=(Client)request.getAttribute("client");
if(client==null)
{
client.setIdentifiant("");
client.setMotdepasse("");
}
%>
Bienvenue client : <%= client.getIdentifiant() %>
<%= client.getMotdepasse() %>
Nous remarquons que la dernière partie du code, qui correspond à la page bienvenue.jsp, permet de récupérer l’objet
client dans la portée request, de vérifier sa présence (client==null) et d’afficher ses informations. Ce code est un peu
lourd à utiliser et nécessite beaucoup de tests. Comme l’objet client est un JavaBean, nous pouvons utiliser les
actions standards JSP pour le manipuler. Nous allons modifier notre code afin d’utiliser ce principe.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
Bienvenue client :
Nous remarquons que le code est beaucoup plus simple et ’’propre’’. Le JavaBean est utilisé dans sa portée et ses
accesseurs Bienvenue client : ");
out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString
((((betaboutique.javabean.Client)_jspx_page_context.findAttribute
("client")).getIdentifiant())));
out.write(’ ’);
out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString
((((betaboutique.javabean.Client)_jspx_page_context.findAttribute
("client")).getMotdepasse())));
out.write(" \n");
out.write("\n");
...
Comment cela fonctionnetil ?
La classe Client, qui est située dans le paquetage betaboutique.javabean, est instanciée. Nous utilisons un objet
JavaBean nommé client qui est stocké dans la portée request. Le test qui permet de savoir si l’objet n’est pas null,
n’est plus obligatoire avec l’action . La Servlet réalise ellemême le test de façon transparente. Nous
pouvons, dans notre exemple, accéder au JavaBean car dans notre Servlet l’objet a été passé avec une portée
request. Le code est le suivant :
...
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
//déclencher la Servlet qui permet de gérer la partie Modèle de l’application
request.setAttribute("client",client);
getServletContext().getRequestDispatcher(urlBienvenue).forward
(request, response);
...
Maintenant modifions la portée de notre JavaBean de cette façon :
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
Bienvenue client :
- 10 -
© ENI Editions - All rigths reserved
Notre code JavaBean client sera alors accessible dans les autres pages JSP de la session de cet utilisateur. Si la
portée utilisée est de type application, l’objet sera alors visible par toutes les pages du site quel que soit l’utilisateur
connecté. Enfin, si la portée est page, l’objet pourra être utilisé uniquement dans la page. Dès que l’utilisateur quitte
la page courante, l’objet JavaBean est alors détruit.
Nous pouvons modifier notre Servlet afin de manipuler un objet client dans la session de l’utilisateur.
...
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
//déclencher la Servlet qui permet de gérer la partie Modèle de l’application
HttpSession session=request.getSession();
session.setAttribute("client",client);
getServletContext().getRequestDispatcher(urlBienvenue).forward
(request, response);
...
L’objet client est désormais stocké dans une portée session. Si nous utilisons le code du dernier exemple exécuté,
voici le résultat :
Le JavaBean a une portée request et ne peut donc pas lire un JavaBean de portée session. Il est possible de modifier
la portée de notre JavaBean et d’actualiser notre page.
...
Bienvenue client :
...
Le JavaBean est désormais accessible. Il possède une portée session ; il peut donc être accédé dans d’autres pages
du site (ex : sessionjavabean.jsp).
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
Bienvenue client avec la session :
© ENI Editions - All rigths reserved
- 11 -
Pour résumer, le code suivant :
Authentification BetaBoutique
Authentification - Client
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
Bienvenue client :
- 12 -
© ENI Editions - All rigths reserved
Si un des attributs n’est pas renseigné dans la requête, l’action Bienvenue client :
Est équivalent au code suivant :
Bienvenue client :<%= client.getIdentifiant() %>
Nous remarquons que cette technique très puissante permet à un intégrateur Web de réaliser du code et d’utiliser
un langage objet dynamique simplement, sans être un développeur Java confirmé. Cette action .
Cette action permet de réaliser une redirection et donc de transférer le contrôle à une autre page.
La syntaxe est la suivante :
.
Cette action permet de donner le contrôle à la page JSP courante, puis lorsque cette page est terminée, à une autre
page indiquée par cette balise. Cet élément permet d’inclure le contenu d’une ressource Web statique ou dynamique
(dans ce cas après son traitement) dans le contenu de la réponse HTTP de la page JSP retournée.
La syntaxe est la suivante :
.
Il ne faut pas confondre la directive include (<%@ include file=’’mapage.jsp’’ %>) et l’action
emailAdministrateur
admin@betaboutique.fr
Par contre, si l’objet implicite config est utilisé pour accéder à ces attributs cela ne fonctionne pas. L’objet implicite
config permet de manipuler les informations de l’environnement, soit la déclaration suivante :
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
Voici un exemple de code de la page bienvenueformulaire.jsp du projet betaboutique afin de bien comprendre la
distinction entre l’objet application et l’objet config.
<%
//afficher les informations avec les objets implicites
out.println("Contactez le Webmestre :
"+application.getInitParameter("emailAdministrateur")+"
configjsp
/bienvenueformulaire.jsp
adressewebmestre
2 rue du haut Dole
configjsp
/configjsp
...
- 2-
© ENI Editions - All rigths reserved
Cet exemple montre clairement que l’objet implicite application correspond à l’application déployée et que l’objet config
correspond à une partie spécifique de l’environnement de l’application.
L’objet exception
L’objet implicite exception est utilisé pour gérer les erreurs qui pourraient se produire lors du traitement de la page
JSP. Cet objet est accessible dans une page d’erreur déclarée dans le fichier de configuration par les balises :
java.lang.Throwable
/erreur.jsp
...
...
<%@page isErrorPage="true" %>
<%= exception.printStackTrace(); %>
...
L’objet out
L’objet implicite out permet de référencer le flux de sortie des données. Il permet d’envoyer du texte en direction de
l’utilisateur Web. Contrairement aux Servlets, il est accessible directement et évite le bloc de code suivant :
//flux de sortie
PrintWriter out=response.getWriter();
L’objet page
L’objet implicite page permet de référencer l’instance courante de la Servlet obtenue après compilation de la JSP. Cet
objet est synonyme du motclé this et n’est pas très utilisé en programmation JSP.
© ENI Editions - All rigths reserved
- 3-
Premières JSP simples
1. Présentation
Nous allons intégrer des premières JSP simples pour la mise en page de la boutique BetaBoutique. Les pages JSP
utilisées pour de la mise en page, sont appelées des fragments, en référence à des morceaux de carrelage dans le
monde du bâtiment.
Les fragments de pages en JSP possèdent l’extension .jspf. Pour le développement de ce projet, il est utile de créer
une seconde application avec Eclipse (ex : betaboutiquefin) afin de pouvoir faire des essais (tester les exemples du
guide) avec l’application betaboutique et d’utiliser une autre version finale de la boutique.
L’application betaboutiquefin possède à cette étape du guide l’arborescence suivante :
Le répertoire /vues contient les pages .jsp et .jspf qui seront utilisées pour l’affichage.
Le répertoire /img contient toutes les images du projet.
Le répertoire /css contient les feuilles de style du projet.
Le répertoire /javascript contient les librairies JavaScript utilisées pour les contrôles, effets, autocomplétion...
Le répertoire /admin contient les pages et répertoires pour la partie administration.
Cette application contient le code définitif mais pas les exemples et tests que nous réalisons.
Le fichier de configuration de l’application est le suivant :
index.jsp
Pour le moment le fichier de configuration de l’application (web.xml) est simple et indique la page d’accueil à utiliser
lors de l’appel du site (projet). De cette façon, en utilisant l’URL suivante : http://localhost:8080/betaboutiquefin/,
c’est la page index.jsp qui sera appelée.
La page index.jsp est très simple, elle possède deux directives d’inclusion afin d’utiliser une page fragment pour l’en
tête du site et une autre pour le pied de page.
© ENI Editions - All rigths reserved
- 1-
<%@ include file="vues/outils/entete.jspf" %>
<%@ include file="vues/outils/piedpage.jspf" %>
Le code utilisé pour la mise en page est donc présent dans les deux pages suivantes /vues/outils/entete.jspf
et /vues/outils/piedpage.jspf.
Lors de l’utilisation d’inclusions, il faut faire très attention aux chemins des images, librairies, feuilles de style et
scripts JavaScript. En effet, dans notre exemple c’est la page index.jsp qui est appelée, notre chemin sera donc relatif
à cette page. Dans ce cas, au sein de la page /vues/outils/entete.jspf, il faudra utiliser le répertoire /img directement
sans remonter dans l’arborescence (ex : ../../img).
Voici un exemple d’utilisation de la feuille de style et du chemin précisé :
BetaBoutique
<%@ include file="navigation.jspf" %>
,
BetaBoutique est une boutique de et par la
société BetaBoutique SARL au Capital
10 000 Euros n° siret 111 222 333 444 555
Nous avons vu comment utiliser des pages JSP simples ainsi que les fragments .jspf. La page obtenue à cette étape
du projet est présentée cidessous. Le code de la page index.jsp est le suivant :
<%@ include file="vues/outils/entete.jspf" %>
<%@ include file="vues/outils/piedpage.jspf" %>
- 4-
© ENI Editions - All rigths reserved
Nous remarquons que chaque page du site devra utiliser l’inclusion de la page d’entête entete.jspf et de la page de
pied de page piedpage.jspf.
Cette technique est utilisée par tous les développeurs Web avec tous les langages de programmation. Par contre,
Java EE offre une possibilité très souple qui permet de configurer un entête et un pied de page directement
applicables à toutes les pages du site par l’intermédiaire du fichier de configuration de l’application (web.xml).
Pour appliquer notre entête et notre pied de page à toutes les pages du site, nous allons ajouter les directives
et
. Cette technique nécessite le remplacement de la grammaire XML par un schéma
pour le fichier web.xml.
index.jsp
*.jsp
include-prelude>/vues/outils/entete.jspf
/vues/outils/piedpage.jspf
Nous allons désormais traiter lors de la prochaine partie les exceptions et erreurs en JSP.
© ENI Editions - All rigths reserved
- 5-
Gérer les exceptions et erreurs en JSP
1. Présentation
L’écriture du code dans un langage informatique doit également prévoir la gestion de diverses erreurs qui ne
manqueront pas de survenir. Nous avons déjà abordé la gestion des erreurs et des exceptions lors des premiers
exemples de ce chapitre. Nous avons déjà rencontré des bogues lors de nos développements. Parfois, les réponses à
ces bogues sont affichées de manière peu sympathique sous la forme de trace ou stack trace.
Les applications Web Java peuvent traiter les exceptions de différentes façons. La manière la plus courante de traiter
les exceptions en Java est d’utiliser les blocs try...catch ou la directive throws.
En Java, un programme déclenche (throws) une exception ou une erreur lorsqu’un dysfonctionnement détourne le
programme de son exécution normale. La liste des exceptions est recensée dans la documentation javadoc de la
classe Exception. http://java.sun.com/j2se/1.3/docs/api/java/lang/Exception.html
Cependant, nous avons besoin d’un moyen permettant de traiter des exceptions imprévues. Nous disposons pour
cela en JSP de deux solutions :
●
La directive page.
●
Le descripteur de déploiement de l’application (le fichier web.xml).
2. La directive page
La directive page possède un attribut nommé errorPage. Si une exception se produit et qu’elle n’est pas interceptée
par notre programme, c’estàdire non traitée dans notre code, la page indiquée est alors retournée par le serveur. Si
l’attribut errorPage commence par la barre oblique (slash), c’est que l’adresse de la page cible est exprimée
relativement à la racine du répertoire de l’application Web. Lors de la définition de la page d’erreur, l’attribut
isErrorPage doit avoir la valeur true.
Nous allons utiliser notre application betaboutique et modifier la page bienvenue.jsp afin de déclencher volontairement
des exceptions. Nous allons appeler la page erreursexception.jsp qui permet d’afficher des informations sur l’exception
qui vient de se déclencher.
<%@ page isErrorPage="true" %>
Erreurs
Exception
Description de l’exception : <%= exception.toString() %>
Message de l’exception : <%= exception.getMessage() %>
Pour déclencher une première exception nous allons tenter de convertir une chaîne de caractères en entier. Le code
JSP est correct mais son exécution aura pour conséquence de déclencher une exception de type
java.lang.NumberFormatException.
<%@ page errorPage="erreursexception.jsp" %>
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
<%
//declaration d’une chaine de caracteres
© ENI Editions - All rigths reserved
- 1-
String chaine="machaine";
Integer chaineentier=new Integer(chaine);
%>
Le message nous indique qu’il s’agit d’une erreur interne à la Servlet. La cause est affichée avec la trace de pile
(stack trace). Cet affichage de trace de pile est déclenché en réponse à la première exception trouvée et renvoyée
par la méthode exception.printStackTrace().
Il faut bien faire la différence entre une erreur de compilation qui empêche la transformation par le moteur de JSP de
la page en Servlet et une erreur d’exécution. Les erreurs d’exécution surviennent pendant l’accès à la page par le
visiteur. Ces erreurs sont causées par un problème dans la page JSP (bien compilée) ou bien dans le code qui est
appelé par la page, comme un JavaBean par exemple ou une inclusion.
Lors du développement d’applications, il est important de suivre les conseils suivants pour corriger les problèmes :
●
Il faut commencer par lire le message affiché sur la page d’erreur.
●
Si le message affiché ne nous permet pas de corriger le problème, il faut analyser le fichier .java.
●
Si vraiment dans les cas extrêmes, l’erreur n’est pas trouvée, il faut compiler la Servlet pour voir la trace
affichée.
La directive page est donc très utile pour désigner une page d’erreur à afficher en cas de problème. Cependant,
l’inconvénient de cette méthode est que la même page d’erreur est renvoyée quelle que soit l’exception rencontrée.
3. Le descripteur de déploiement (web.xml)
Le descripteur de déploiement permet de désigner des gestionnaires d’erreurs pour toute l’application. Il est ainsi
possible d’avoir des pages d’erreur différentes, en fonction du type d’exception, mais aussi des erreurs relatives au
serveur (ex : page non trouvée, problème du serveur...). Il est possible de définir des pages d’erreur pour les
exceptions Java et pour les erreurs HTTP.
La définition des pages d’erreur vient immédiatement après l’élément
du fichier web.xml
conformément à la DTD.
Nous allons définir une page en cas d’erreur 404 (page non trouvée sur le serveur) dans le fichier web.xml.
404
/404.html
La définition d’une page d’erreur pour une exception Java est identique à celle des erreurs HTTP. Le nom de la classe
de l’exception Java et la page d’erreur associée sont indiquées. Dans notre cas, la page affichée en cas de problème
de conversion sera /erreurconversion.html.
Pour tester cette technique, nous allons modifier notre page bienvenue.jsp et enlever la directive de la page d’erreur.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
- 2-
© ENI Editions - All rigths reserved
BIENVENUE
<%
//declaration d’une chaine de caracteres
String chaine="machaine";
Integer chaineentier=new Integer(chaine);
%>
Nous allons déclencher cette page avant de paramétrer le fichier web.xml et donc de générer une erreur d’exécution.
La trace affichée sans traitement est présentée cidessous :
Une astuce de programmation consiste à déclencher volontairement l’erreur et à observer la trace. Dans notre
exemple, il est visible que l’exception est de type : java.lang.NumberFormatException.
Nous allons donc définir notre exception pour l’erreur de conversion en indiquant la classe précisée.
java.lang.NumberFormatException
/erreurconversion.html
Nous avons modifié le fichier de configuration de l’application, il faut donc recharger l’application pour que nos
modifications soient prises en compte. Nous déclenchons à nouveau la page bienvenue.jsp et nous observons que la
page d’erreur adaptée est alors affichée. Cette technique est donc beaucoup plus puissante que l’utilisation de la
directive page propre aux JSP.
Une page d’erreur indiquée dans une page JSP a la priorité sur celles indiquées par le descripteur de
déploiement.
Nous pouvons donc, avec cette technique gérer plusieurs exceptions Java et erreurs HTTP. La priorité correspond à
l’importance de la portée de l’exception, dans le descripteur de déploiement. Nous allons modifier le descripteur de
déploiement de la façon suivante :
java.lang.Throwable
/erreurglobale.html
java.lang.NumberFormatException
© ENI Editions - All rigths reserved
- 3-
/erreurconversion.html
404
/404.html
Nous avons ajouté le traitement de l’exception java.lang.Throwable qui correspond à toutes les exceptions générées
en Java. Autrement dit, dès qu’une exception sera déclenchée (erreur de conversion, calcul, problème de fermeture
d’une source de données ou autre) la page erreurglobale.html sera appelée. Nous pouvons recharger l’application et
déclencher la page bienvenue.jsp pour voir le résultat.
Nous remarquons que la page possède une erreur qui déclenche une exception de conversion mais que c’est la page
d’erreur globale qui est affichée. En effet, les erreurs sont attrapées par ordre de priorité dans le fichier de définition
de l’application (web.xml). Comme l’exception java.lang.Throwable est plus générale que l’exception
java.lang.NumberFormatException c’est bien la page erreurglobale.html qui est affichée.
Pour un serveur en production, il faudra juste gérer l’exception générale (java.lang.Throwable) avec une page d’erreur.
L’idéal serait bien entendu une page d’erreur adaptée à la plupart des erreurs rencontrées.
Par contre, lors de l’étape de développement il est important de ne pas mettre une page statique HTML associée à
l’exception générale java.lang.Throwable car nous n’aurons aucune trace à l’écran en cas d’erreur ce qui est très
contraignant pour les débogages.
- 4-
© ENI Editions - All rigths reserved
Bibliothèque de tags JSTL
1. Présentation
Il existe de nombreuses librairies de tags (utilisables à partir de balises XML) proposées pour la technologie JSP Java.
Une bibliothèque de balises est composée de grammaires XML (fichier .tld) et de classes d’implémentation des
fonctionnalités.
Les responsables Java EE se sont aperçus que de nombreux développeurs dépensaient beaucoup d’énergie pour
créer de nouvelles balises répondant souvent aux mêmes besoins. Ces actions avaient des syntaxes et des noms
différents mais accomplissaient pratiquement la même chose. Le but de JSTL (Java server page Standard Tag Library) est
de standardiser un certain nombre d’actions. JSTL est donc un ensemble de tags personnalisés développés sous la
JSR 052 permettant de réaliser des opérations de structure (conditions, itérations...), gérer les langues, exécuter des
requêtes SQL et utiliser le langage XML.
JSTL est actuellement le standard pour l’utilisation de tags, mais il existe de nombreuses autres librairies :
●
La librairie de tags Struts : manipulation de JavaBean, HTML, conditions...
(http://struts.apache.org/1.x/strutstaglib/index.html)
●
La librairie Displaytag : gestion de l’affichage de tableaux HTML, XML, Excel...
(http://displaytag.sourceforge.net/11/)
●
La librairie Image taglib : gestion des opérations sur des images.
(http://jakarta.apache.org/taglibs/sandbox/doc/imagedoc/index.html)
●
La librairie Upload taglib : gestion du chargement ascendant de fichiers.
(http://www.servletsuite.com/servlets/uptag.htm)
●
La librairie Ajax Upload taglib : gestion du chargement ascendant de fichiers avec la technologie Ajax.
(http://www.servletsuite.com/servlets/ajaxuploadtag.htm)
2. Utilisation
La mise en place d’une librairie de tags JSP nécessite le chargement de l’archive d’implémentation au format .jar dans
le projet et l’association URI/TLD dans le descripteur de déploiement web.xml.
Pour utiliser une librairie de tag, il est nécessaire de procéder de la façon suivante :
●
La première étape consiste à télécharger l’archive au format .jar qui contient l’implémentation des balises. Puis
il faut copier cette archive dans le répertoire des librairies, à savoir /WEBINF/lib. Il faut aussi copier tous les
fichiers .tld (qui sont les grammaires XML des balises) dans le répertoire /WEBINF/tld ou /WEBINF/tlds (à
créer).
●
La deuxième étape consiste à créer l’association entre la librairie de tags et notre projet dans le descripteur
de déploiement (web.xml), par le biais d’une déclaration et d’une URI.
●
La dernière étape consiste à ajouter la directive <%@ taglib.../> dans chaque page JSP devant utiliser la
librairie.
Les fichiers .jar contiennent le code Java pour l’utilisation des balises. Par contre, les fichiers .tld contiennent la
grammaire des balises utilisables avec les archives .jar. Ainsi, la déclaration de ces grammaires nous permet
de bien utiliser les balises et de bénéficier de messages d’erreurs efficaces lors des utilisations (nombre de
paramètres pour la balise, syntaxe des paramètres...).
© ENI Editions - All rigths reserved
- 1-
Dans un premier temps nous allons utiliser la bibliothèque de tags standard Java EE JSTL.
JSTL possède quatre bibliothèques de tags :
●
Fonctions de base avec c.tld et l’URI http://java.sun.com/jstl/core
●
Fonctions de traitement XML avec x.tld et l’URI http://java.sun/com/jstl/xml
●
Fonctions d’internationalisation (langues) avec fmt.tld et l’URI http://java.sun.com/jstl/fmt
●
Fonctions de traitement SQL avec sql.tld et l’URI http://java.sun.com/jstl/sql
3. Implémentation
Pour utiliser JSTL, il faut copier les librairies jstl.jar et standard.jar dans notre répertoire de librairies /WEBINF/lib. Ces
archives sont disponibles sur Internet sur le site Java. Dans un second temps, nous allons copier les fichiers .tld
(grammaires des balises) dans un répertoire nommé /WEBINF/tld que nous allons créer.
L’arborescence de notre projet doit avoir la structure suivante :
Il reste alors une dernière étape après le chargement des librairies .jar et la mise en place des grammaires .tld, c’est la
déclaration des bibliothèques à utiliser dans le descripteur de déploiement du projet (web.xml).
Nous plaçons le code suivant en fin de fichier web.xml après les balises
.
...
/WEB-INF/tld/c.tld
/WEB-INF/tld/c.tld
/WEB-INF/tld/x.tld
/WEB-INF/tld/x.tld
/WEB-INF/tld/sql.tld
/WEB-INF/tld/sql.tld
...
La balise
nous indique une URI pleinement qualifiée qui sera par la suite utilisée dans notre directive <%
@taglib/> des pages JSP. Dans notre cas, la valeur utilisée est le chemin vers la librairie c.tld, mais nous pourrions
utiliser n’importe quelle URI pleinement qualifiée. Voici un autre exemple d’URI :
...
http://java.sun.com/jstl/core
/WEB-INF/tld/c.tld
http://java.sun.com/jstl/xml
/WEB-INF/tld/x.tld
http://java.sun.com/jstl/sql
- 2-
© ENI Editions - All rigths reserved
/WEB-INF/tld/sql.tld
...
La seconde balise
permet de préciser le chemin vers la grammaire des librairies que nous venons
d’installer. Dans la configuration précédente, nous avons donc paramétré les librairies c.tld, x.tld et sql.tld.
Désormais il ne reste plus qu’à déclarer nos balises de tags dans chaque page JSP qui souhaite les utiliser. Cette
opération simple est réalisée par l’intermédiaire de la directive <%@ taglib.../>. Il faut préciser le préfixe des balises et
le chemin pleinement qualifié identique à celui renseigné dans le descripteur de déploiement : <%@ taglib uri="/WEB
INF/tld/c.tld" prefix="c" %>.
4. Utilisation de bibliothèques
a. La bibliothèque core
Nous allons utiliser la bibliothèque core : c.tld. Cette bibliothèque regroupe les actions fondamentales. Pour cela,
nous utilisons notre page bienvenue.jsp et nous allons définir les directives pour l’utilisation de nos bibliothèques.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
BIENVENUE
Nos bibliothèques de balises sont désormais définies, nous pouvons utiliser de nouvelles balises XML très puissantes
pour nos développements.
●
Le tag set permet de stocker une variable dans une portée particulière (page, request, session ou application).
●
Le tag out permet d’afficher la valeur d’une variable, ce tag est équivalent à <%= ...%>.
●
Le tag remove permet de supprimer une variable.
●
Le tag catch permet de gérer les exceptions.
●
Le tag if est utilisé pour réaliser une condition.
●
Le tag choose est utilisé pour des cas mutuellement exclusifs (équivalent du switch).
●
Le tag foreach est utilisé pour réaliser des itérations.
●
Le tag forTokens est utilisé pour découper une chaîne selon un ou plusieurs séparateurs.
●
Le tag import permet d’accéder à une ressource via son URL pour l’inclure ou l’utiliser dans la page JSP.
●
Le tag redirect permet de réaliser une redirection vers une nouvelle URL.
Grâce à l’utilisation de grammaires XML (fichiers .tld pour les taglibs), Eclipse sait gérer l’autocomplétion des
balises et les erreurs de déclaration.
© ENI Editions - All rigths reserved
- 3-
Voici un exemple d’utilisation de la bibliothèque core.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
BIENVENUE
Une conditionnelle opérationnelle
Une conditionnelle non affichée
b. La bibliothèque XML
Dans un second temps, nous allons utiliser la bibliothèque xml : x.tld.
Pour cela, nous allons créer une nouvelle page xmltaglib.jsp et définir la directive pour utiliser nos nouvelles balises.
Cette bibliothèque très puissante permet de manipuler des données en provenance d’un contenu XML (document ou
contenu généré à la volée par programmation). Nous allons créer une structure de fichier XML dans notre page
xmltaglib.jsp.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
XML
Taxi 4
taxi4.png
Le choc
choc.png
Mort un dimanche de pluie
muDd32D3.png
- 4-
© ENI Editions - All rigths reserved
Cette page affiche le contenu complet XML sous la forme d’un flux textuel. En effet, la variable nommée xml stocke le
contenu du code XML et la balise
permet de l’afficher. Le tag parse permet d’analyser le document et de
stocker le résultat dans une variable qui pourra être exploitée par la JSP. Le tag set est équivalent au tag set de la
bibliothèque core. Il permet d’évaluer l’expression fournie dans l’attribut select et de stocker le résultat dans une
variable. Le tag out est équivalent au tag out de la bibliothèque core. Il permet d’envoyer le résultat dans le flux de
sortie. L’attribut select permet de préciser le chemin XPath de l’arbre XML. Le tag if est équivalent au tag if de la
bibliothèque core à la différence qu’il évalue une expression XPath. Le tag choose est équivalent au tag choose de la
bibliothèque core à la différence qu’il utilise une expression XPath. Le tag forEach est équivalent au tag forEach de la
bibliothèque core. Il permet de réaliser des boucles sur des nœ uds.
Le tag transform permet d’appliquer une transformation XSLT (eXtensible Stylesheet Language Transformations) à un
document XML. L’attribut xsl permet de spécifier la feuille de styles XSL à utiliser.
Le tag transform est introduit dans le cadre du projet betaboutique afin de réaliser une transformation XSLT sur le
document XML qui contient la liste des DVD. Le code précédent permet d’afficher sous forme textuelle le contenu du
document XML.
Nous allons donc séparer les données de la mise en page en utilisant la technique suivante :
Un premier document au format XML (ou contenu XML généré à la volée) contient uniquement des métadonnées et
ne s’occupe en aucun cas de la présentation. Son contenu peut avoir la structure suivante :
Taxi 4
taxi4.png
Le choc
choc.png
Mort un dimanche de pluie
muDd32D3.png
Un second document (présent en dur sur le serveur) est composé de balises XML/XPath et HTML, il permet de lire les
données du fichier XML et de gérer la mise en forme de ces données. Il s’occupe uniquement d’opérations simples
(conditions, boucles) et de la mise en page. Ce document est une feuille de styles XSLT au format .xsl.
Voici un exemple de son contenu pour l’affichage des DVD :
© ENI Editions - All rigths reserved
- 5-
BETABOUTIQUE
Liste des DVD
Nous avons donc désormais nos données XML, notre fichier de mise en forme .xsl, il ne nous reste plus qu’à utiliser
notre page JSP qui permet par l’intermédiaire de la balise
de transformer le tout en document
HTML.
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
XML
Taxi 4
taxi4.png
Le choc
choc.png
Mort un dimanche de pluie
muDd32D3.png
- 6-
© ENI Editions - All rigths reserved
La composition des deux fichiers une fois la transformation réalisée donne un document au format HTML. Cette
technique très puissante permet de complètement séparer la partie données de la partie présentation. Le document
résultant dans notre cas est un fichier au format HTML, mais nous aurions pu générer des documents PDF, des
images SVG, des pages 3D VRML... Bien entendu, par la suite, le contenu XML des données sera généré de façon
dynamique avec une page JSP ou une Servlet. Les données seront lues dans une source de données de type fichier
ou base de données, la feuille de style sera adaptée en conséquence pour l’affichage et la balise
permettra de générer à la volée la page HTML (ou n’importe quel autre format compatible).
c. La bibliothèque I18n
Nous allons mettre en place la bibliothèque I18n : fmt.tld. Cette bibliothèque regroupe les actions pour la gestion de
l’internationalisation. L’internationalisation en programmation et développement consiste à gérer les langues et donc
à proposer des pages multilingues. Le terme I18n est standardisé pour l’internationalisation et correspond aux 18
caractères qui composent le mot internationalisation entre le i et le n.
En programmation la langue est présentée avec une locale. Une locale est composée de deux paramètres : la
première partie lang et la seconde partie country séparées par le caractère underscore. Par exemple :
●
le français France est représenté par : fr_FR.
●
le français canadien est représenté par : fr_CA
●
l’anglais américain est représenté par : en_US
Pour manipuler la bibliothèque de langue, nous ajoutons sa définition dans le fichier de configuration de l’application
(web.xml).
...
/WEB-INF/tld/fmt.tld
/WEB-INF/tld/fmt.tld
...
Nous ajoutons également la déclaration avec la directive adaptée dans notre page JSP, qui utilise cette bibliothèque
de tags.
<%@ taglib uri="/WEB-INF/tld/fmt.tld" prefix="fmt" %>
Pour la mise en œ uvre de la localisation des messages en Java, il faut utiliser un ensemble de fichiers appelés bundle
en anglais. Il faut définir un fichier par langue/locale. Chaque fichier possède un préfixe commun appelé basename et
doit avoir l’extension .properties. Les fichiers pour des langues particulières doivent avoir le même préfixe suivi d’un
caractère underscore et du code langue. Pour être accessibles, ces fichiers doivent être inclus dans le classpath, ils
© ENI Editions - All rigths reserved
- 7-
doivent donc être placés dans le répertoire /WEBINF/classes.
Ce répertoire est fréquemment effacé par Eclipse lors du développement, lors des mises à jour du projet (compilation
des fichiers...). Nos fichiers de langues seront donc effacés à chaque fois. Le plus simple est alors de déposer les
fichiers de langues dans un répertoire nommé /WEBINF/src/ressources car celuici sera copié automatiquement (et à
chaque modification) dans le répertoire /WEBINF/classes.
Pour la mise en œ uvre de l’internationalisation, nous allons créer un répertoire ressources dans l’arborescence /WEB
INF/src et deux fichiers. Le premier fichier nommé betaboutique.properties correspond aux données de la langue par
défaut (français dans notre cas) et le fichier betaboutique_en.properties correspond aux données en anglais. Nous
utilisons également un fichier pour le français nommé betaboutique_fr.properties. Voici l’arborescence au final :
Un fichier de langue contient des paires de valeurs composées d’une clé unique et de sa valeur associée.
Exemple :
dvd.webmestre=Merci de contacter webmestre@betaboutique.com
Voici les deux fichiers que nous allons définir. Cet exemple regroupe seulement deux traductions, mais nous pouvons
indiquer autant de traductions que souhaitées.
Fichier : betaboutique.properties
#gestion des dvd
dvd.accueil=Bienvenue sur la page des DVD
dvd.webmestre=Merci de contacter webmestre@betaboutique.com
Fichier : betaboutique_en.properties
#gestion des dvd en anglais
dvd.accueil=Welcome in the DVD page
dvd.webmestre=Please contact webmestre@betaboutique.com
La technique d’internationalisation abordée dans ce chapitre est valable pour toute la programmation Java
et sera utilisée de la même façon avec des Servlets, Struts, des applications JWS ou des Applets.
- 8-
●
Le tag setBundle permet de localiser/paramétrer le bundle utilisé par défaut.
●
Le tag message permet de localiser un message en fonction de sa langue et de l’afficher.
●
Le tag setLocale permet de positionner une locale (changer de langue).
●
Le tag formatNumber permet de formater un nombre en fonction de la locale.
●
Le tag parseNumber permet des conversions.
●
Le tag formatDate permet de formater la date selon la locale.
●
Le tag setTimeZone permet de stocker le fuseau horaire dans une variable.
© ENI Editions - All rigths reserved
●
Le tag timeZone permet de préciser le fuseau horaire à utiliser dans le corps de la page.
Avant de tester ces fonctionnalités, nous allons mettre notre navigateur en français. Pour cela, avec Firefox nous
utilisons le menu Outils Options Avancé Langues Choisir et nous laissons uniquement les langues Français[fr]
et Français/France [frfr]. Pour la prise en compte de ces opérations, il faut fermer le navigateur et ouvrir une nouvelle
fenêtre.
Pour mettre en application l’internationalisation, nous allons créer une page JSP nommée i18n.jsp et utiliser le code
cidessous :
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
<%@ taglib uri="/WEB-INF/tld/fmt.tld" prefix="fmt" %>
I18n
Si aucun couple de valeur n’est trouvé pour la clé fournie, le tag renvoie alors ???xxx??? où xxx représente le nom de
la clé, comme pour le cas : dvd.retour.
Notre page est correctement affichée en français (langue par défaut dans le navigateur). Nous allons paramétrer
notre navigateur en anglais selon le même principe que précédemment et relancer le navigateur.
© ENI Editions - All rigths reserved
- 9-
La page est automatiquement traduite dans la langue sélectionnée.
Cette technique de programmation très utile permet de proposer des sites multilingues. Par la suite, nous pourrons
proposer un service basé sur une Servlet qui permet de changer la locale à la volée avec des liens HTML. Nous
pouvons également modifier une locale avec les taglibs JSP de cette façon (après avoir positionné le navigateur en
français) :
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
<%@ taglib uri="/WEB-INF/tld/fmt.tld" prefix="fmt" %>
I18n
- 10 -
© ENI Editions - All rigths reserved
d. La bibliothèque DataBase
Cette bibliothèque SQL facilite l’accès et la manipulation de bases de données. Elle permet entre autres de créer une
connexion vers une base de données, de réaliser des requêtes de sélection, d’encapsuler plusieurs requêtes dans
une transaction ou de réaliser des mises à jour. Ces balises sont très pratiques pour des sites qui nécessitent un
développement rapide. Par contre, elles sont peu utilisées dans les projets qui séparent la partie Vue de la partie
Modèle/Accès aux données. En utilisant de telles balises, en effet le code HTML, le code de traitement et l’accès aux
données sont mélangés dans la même page JSP.
L’exemple suivant nommé sql.jsp permet de se connecter à la base de données betaboutique et de lister la totalité
des enregistrements de la table categorie afin de générer le menu principal de navigation. Le tag permet de créer un
lien vers la base de données à partir d’une connexion simple ou d’un pool de connexion JDBC.
Ce code utilise une connexion JDBC vers une base de données MySQL. Il est donc nécessaire de copier le pilote
MySQL approprié dans le répertoire /WEBINF/lib de l’application ou /common/lib du serveur Tomcat ou /lib du serveur
Tomcat 6.X.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/sql.tld" prefix="sql" %>
SQL
Dans le cas d’un pool de connexion JDBC, c’est le tag
qui change. Le nom de notre connexion
JNDI est précisé en paramètre.
Cette bibliothèque de tag permet également de gérer des paramètres dans les requêtes, les transactions, les
rollbacks...
© ENI Editions - All rigths reserved
- 11 -
Bibliothèque de balises personnalisées
1. Présentation
Nous avons étudié les balises/taglibs proposées par Java, des communautés diverses et des développeurs. Parfois,
pour les besoins d’un projet ou par habitude de développement nous avons besoin d’une bibliothèque de balises qui
n’existe pas encore ou qui ne fournit par les services souhaités (balises pour la pagination, le cryptage de données, la
transformation de chaînes de caractères). Nous pouvons alors développer notre propre bibliothèque de balises
personnalisées en suivant le principe du standard JSTL et de ses taglibs.
De cette façon, nos pages JSP ne contiendront aucun code Java. En fait, il ne s’agit pas vraiment de supprimer le code
Java mais plutôt de le masquer de façon qu’il soit invisible pour les graphistes/concepteurs des pages.
Nous avons utilisé plusieurs balises JSP standards comme
,
... Ces balises répondent
à des besoins courants et sont utilisées par tous les programmeurs JSP. Les bibliothèques de balises servent à
répondre à des besoins particuliers pour nos applications. De même, lorsqu’un programmeur a conçu une bibliothèque
de balises, les développeurs peuvent ensuite s’en servir dans leurs pages JSP sans connaître le détail de leur
implémentation. Ces balises dynamiques s’utilisent de la même manière que les balises HTML, le partage des tâches
entre programmeurs et concepteurs de l’interface devient beaucoup plus clair.
2. Actions personnalisées
Le terme action personnalisée fait référence à une balise dans une page JSP. Les actions personnalisées sont
employées dans des pages JSP comme des balises ordinaires. Elles sont identifiées par un préfixe et un nom :
. Le préfixe permet d’éviter des conflits de noms entre les balises des différentes bibliothèques. Ce
préfixe est choisi par le développeur. Le préfixe est suivi du nom de l’action, également choisi par le développeur de la
bibliothèque. Les actions peuvent être vides (juste la présence de la balise) mais peuvent également posséder un
corps. Enfin, les actions peuvent avoir des attributs qui spécifient les détails de leur comportement.
3. Mise en place
La première étape dans la création d’une balise personnalisée consiste à créer le fichier de classe gestionnaire de
balises. Ce gestionnaire de balises stocke les méthodes qui lancent des actions spécifiques lorsque les balises
personnalisées sont traitées. Cette classe Java chargée d’implémenter le comportement de l’action doit respecter les
spécifications d’un JavaBean et implémenter une des interfaces d’extension de balises.
Il existe plusieurs interfaces pour la gestion des actions :
●
Tag et BodyTag : pour les actions simples avec ou sans corps.
●
IterationTag : pour gérer les itérations plus facilement.
●
SimpleTag et JspFragmentTag : pour encapsuler le contenu du corps de l’action dans un objet.
Les gestionnaires de balises simples
L’interface SimpleTag et la classe SimpleTagSupport permettent d’implémenter tous les gestionnaires de balises JSP 2.0,
avec ou sans itération et évaluation du corps. Pour utiliser une action personnalisée, il suffit de créer une classe qui
étend la classe de base SimpleTagSupport et redéfinir les méthodes nécessaires pour produire le comportement
souhaité.
Dans la majorité des cas, la méthode doTag() est suffisante. Cette méthode gère l’intégralité du comportement de
l’action (sans se soucier du début de la balise, du corps et de la fin). Un gestionnaire de balises doit importer les
paquetages javax.servlet.jsp et javax.servlet.jsp.tagext.
Un gestionnaire de balises simple doit avoir une méthode doStartTag() qui contient le code exécuté. Cette méthode
doit être déclarée en accès public afin d’être accessible en dehors du gestionnaire de balises. La méthode doStartTag()
doit retourner une valeur pour indiquer que la balise renvoie quelque chose ou la valeur SKIP_BODY pour sauter cette
étape.
Afin de mettre en place notre bibliothèque de balises, nous allons commencer par créer un nouveau paquetage
nommé taglib et placer la classe suivante dans ce paquet.
package taglib;
© ENI Editions - All rigths reserved
- 1-
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.tagext.*;
public class SimpleTag extends TagSupport {
public int doStartTag()throws JspException
{
return SKIP_BODY;
}
}
La classe du gestionnaire de balises est créée, nous pouvons utiliser l’objet PageContext pour gérer le flux de sortie et
envoyer des données à la page utilisatrice. La méthode getOut() de cet objet permet d’envoyer des informations au
client. Cette méthode peut générer une exception qu’il est donc nécessaire de traiter.
package taglib;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspTagException;
import javax.servlet.jsp.tagext.*;
public class SimpleTag extends TagSupport {
public int doStartTag()throws JspException
{
try
{
pageContext.getOut().print("Webmestre : info@betaboutique.com");
}
catch(Exception e)
{
throw new JspTagException(e.getMessage());
}
return SKIP_BODY;
}
}
4. Mise en place d’un fichier de description
Les fichiers de définition des bibliothèques portent l’extension .tld comme par exemple c.tld, x.tld ou fmt.tld. Ces fichiers
qui sont des grammaires XML, sont placés dans le répertoire /WEBINF/tld de l’application courante.
Une fois le gestionnaire créé avec une classe Java adaptée, nous devons créer le fichier de description au format XML.
Le fichier commence par un entête XML qui contient des informations sur le fichier avec le prologue et la grammaire
utilisée. Nous commençons par créer le fichier suivant : /WEBINF/tld/betaboutique.tld.
- 2-
●
Les balises
et
1.0
2.0
Une premiere balise pour le Webmestre
webmestre
taglib.SimpleTag
5. Configuration de la librairie dans le descripteur web.xml
Nous avons créé le code du gestionnaire de balises ainsi que sa grammaire associée, nous devons maintenant réaliser
la dernière étape qui consiste à paramétrer le descripteur de déploiement (web.xml) avec la balise
/WEB-INF/tld/betaboutique.tld
/WEB-INF/tld/betaboutique.tld
...
6. Utilisation d’une librairie personnalisée
Nous avons suivi les trois étapes nécessaires à la mise en place d’une bibliothèque de balises personnalisées, à
savoir :
●
la création de la classe Java pour le gestionnaire de balises ;
●
le codage du fichier de description des balises au format XML ;
●
la configuration du fichier web.xml.
Nous pouvons maintenant utiliser notre bibliothèque avec la directive <%@ taglib .../> et l’URI correspondante dans
une page JSP. Nous allons reprendre notre page bienvenue.jsp du projet betaboutique pour mettre en œ uvre la
librairie.
La directive taglib emploie l’attribut uri pour spécifier un identifiant relatif au fichier de description des balises. Cet
identifiant doit être le même que celui spécifié dans le fichier web.xml. Il faut également préciser un préfixe pour
référencer la bibliothèque de balises qui contient l’information sur la balise personnalisée. Chaque bibliothèque de
© ENI Editions - All rigths reserved
- 3-
balises a besoin d’un préfixe différent pour éviter des conflits d’actions.
Pour utiliser une balise personnalisée dans une page JSP, nous devons saisir le préfixe et le nom de l’action que nous
avons affectés dans le fichier de description, séparés par un symbole deux points. Les balises simples qui ne
contiennent pas de corps ou d’information entre la balise de début et de fin peuvent être réduites à une seule balise.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld" prefix="bb" %>
BIENVENUE
Webmestre :
info@betaboutique.com ");
}
else
{
pageContext.getOut().print("Webmestre :
info@betaboutique.com");
}
}
catch(Exception e)
- 4-
© ENI Editions - All rigths reserved
{
throw new JspTagException(e.getMessage());
}
return SKIP_BODY;
}
//action a la fermeture du tag
public int doEndTag()
{
try
{
JspWriter out=pageContext.getOut();
out.print(" dans le fichier de description. Le
nom de l’attribut est précisé à l’aide de la balise . Le nom donné à cette balise est sensible à la casse et doit
être le même que celui utilisé dans les pages JSP. La balise suivante indique si l’attribut est indispensable
lors de son utilisation dans une page JSP. Si la valeur utilisée est false, cet attribut sera optionnel. Si sa valeur est
true, l’attribut devra être obligatoirement utilisé, sinon la page JSP provoquera une erreur.
Voici le nouveau contenu du fichier betaboutique.tld.
1.0
2.0
Une premiere balise pour le Webmestre
webmestre
taglib.SimpleTag
mailto
true
Si désormais nous utilisons notre page bienvenue.jsp avec le code suivant, la page nous indique que d’après la
grammaire de la bibliothèque l’attribut mailto est obligatoire.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld" prefix="bb" %>
BIENVENUE
© ENI Editions - All rigths reserved
- 5-
BIENVENUE
true dans le fichier de description autorise la valeur de
l’attribut à être affectée durant l’exécution du code JSP.
8. Gestionnaire de balises et gestion du corps des balises
Le corps d’une balise est l’information comprise entre les balises de début et de fin. Le corps de la balise peut être
constitué de texte ou de code JSP. Un gestionnaire de balises peut donc être créé pour utiliser l’information contenue
dans le corps de la balise personnalisée.
La méthode doStartTag() est toujours utilisée, mais pour une balise avec corps, cette méthode doit retourner la valeur
EVAL_BODY_INCLUDE, pour que le serveur Web traite l’information contenue dans le corps de la balise. Le
gestionnaire de balises doit également inclure une méthode doEndTag() lors du traitement du corps. Cette méthode
contient pour rappel, le code à exécuter après le traitement du corps.
La méthode doEndTag() doit retourner une valeur pour indiquer si le reste de la page JSP doit être traité ou non. Dans
la plupart des cas, la valeur retournée est EVAL_PAGE pour indiquer que le reste de la page doit être traité par le
serveur. Pour que le reste de la page ne soit pas traité, il faut utiliser la valeur SKIP_PAGE (pour les sessions par
exemple).
package taglib;
import
import
import
import
import
public
java.io.IOException;
javax.servlet.jsp.JspException;
javax.servlet.jsp.JspTagException;
javax.servlet.jsp.JspWriter;
javax.servlet.jsp.tagext.*;
class SimpleTag extends TagSupport {
//lien en mailto ou pas
- 6-
© ENI Editions - All rigths reserved
private boolean mailto=false;
//action
public int doStartTag()throws JspException
{
try
{
if(mailto)
{
pageContext.getOut().print("");
}
else
{
pageContext.getOut().print("Webmestre : ");
}
}
catch(Exception e)
{
throw new JspTagException(e.getMessage());
}
return EVAL_BODY_INCLUDE;
}
//action a la fermeture du tag
public int doEndTag()
{
try
{
JspWriter out=pageContext.getOut();
if(mailto)
{
pageContext.getOut().print(" ");
}
out.print(" et . Si aucun type de contenu n’est spécifié, il prendra
la valeur précisée par défaut. Une bonne habitude est d’utiliser le terme JSP pour préciser le type de contenu.
Il est conseillé de toujours inclure la balise au sein du fichier de description. Dans le cas d’une
balise vide il faudra utiliser empty . Si par contre, des instructions dynamiques
autre que du code JSP sont utilisées, il faut insérer la définition suivante : tagdependent.
Nous pouvons désormais utiliser notre balise avec un corps, avec le fichier de définition suivant :
© ENI Editions - All rigths reserved
- 7-
1.0
2.0
Une premiere balise pour le Webmestre
webmestre
taglib.SimpleTag
JSP
mailto
true
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld" prefix="bb" %>
BIENVENUE
contact@betaboutique.com
info@betaboutique.com
9. Gestionnaire de balises et gestion du contenu du corps
Le principe de l’exemple précédent est très intéressant mais il nous empêche de manipuler le contenu du corps de la
balise (adresse email dans notre cas). Pour manipuler le corps d’une balise, le gestionnaire de balises doit dériver de
la classe BodyTagSupport. La classe BodyTagSupport dérive ellemême de la classe TagSupport et contient des méthodes
permettant ce type de traitement.
Il faut créer une méthode doAfterBody() pour traiter le corps d’une balise. Dans cette méthode, l’objet BodyContent
permet de stocker des informations sur le corps reçu. La méthode getString() permet de récupérer le corps de la balise
sous la forme d’une chaîne de caractères qui peut alors être manipulée. Enfin, la méthode getEnclosingWriter() de
l’objet BodyContent permet de retourner le résultat à la page JSP.
Le code suivant permet de traiter le corps passé avec la balise et de le mettre en majuscule.
package taglib;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspTagException;
import javax.servlet.jsp.tagext.*;
public class SimpleTag extends BodyTagSupport {
//lien en mailto ou pas
private boolean mailto=false;
//action
public int doAfterBody()throws JspException
{
try
{
BodyContent bodycontent=this.getBodyContent();
String bodytext=bodycontent.getString();
if(mailto)
{
bodycontent.getEnclosingWriter().print(""+bodytext.toUpperCase()+"
- 8-
© ENI Editions - All rigths reserved
BIENVENUE
contact@betaboutique.com
info@betaboutique.com
<%= new java.util.Date() %>
Cette technique très puissante est couramment utilisée pour accéder à une base de données, manipuler des images,
réaliser du formatage (résumés, remplacement de caractères...) ou envoyer un email automatique.
Une fois que la librairie est terminée, c’estàdire que l’implémentation du code est réalisée et que la grammaire .tld
est déclarée, nous pouvons empaqueter la totalité de la librairie dans une archive au format .jar. Nous allons illustrer
par un nouvel exemple la lecture de paramètre dans le fichier de configuration de l’application web.xml. Cette
technique est utilisée pour réaliser des liens vers des ressources comme les feuilles de style CSS ou les fichiers
JavaScript.
urlApplication
http://192.168.0.1:8080/betaboutique/
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
© ENI Editions - All rigths reserved
- 9-
TAGLIB
<%
String parametre=pageContext.getServletContext().getInitParameter
("urlApplication");
if(parametre!=null)
{
out.println(parametre);
}
%>
Cette technique est très lourde à mettre en place et peu adaptée. Nous allons développer une taglib simple
permettant de réaliser ce type de code avec une seule balise. Nous commençons par créer une nouvelle classe
nommée Configuration dans le paquetage betaboutique.taglib.
package betaboutique.taglib;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspTagException;
import javax.servlet.jsp.tagext.*;
@SuppressWarnings("serial")
public class Configuration extends TagSupport
{
private String attribut;
public int doStartTag() throws JspException
{
try
{
/* afficher le paramètre contenu dans le contexte
de l’application */
pageContext.getOut().print(pageContext.getServlet
Context().getInitParameter(attribut));
}
catch (Exception e)
{
throw new JspTagException(e.getMessage());
}
return SKIP_BODY;
}
public int doEndTag()
{
return SKIP_BODY;
}
public void setAttribut(String attribut)
{
this.attribut = attribut;
}
}
Ensuite, nous procédons à la définition de la grammaire avec le fichier configuration.tld dans le répertoire /WEBINF/tld.
1.0
2.0
Opérations sur les parametres
config
betaboutique.taglib.Configuration
JSP
- 10 -
© ENI Editions - All rigths reserved
attribut
true
Il ne reste maintenant plus que la dernière étape de la configuration, à savoir la déclaration de la librairie dans le
fichier de gestion de l’application web.xml.
urlApplication
http://192.168.0.1:8080/betaboutique/
/WEB-INF/tld/configuration.tld
/WEB-INF/tld/configuration.tld
L’exemple précédent peut maintenant être remplacé par le code simple suivant :
<%@ taglib uri="/WEB-INF/tld/configuration.tld" prefix="conf" %>
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
TAGLIB
Authentification BetaBoutique
Authentification - Client
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
request.setAttribute("client",client);
getServletContext().getRequestDispatcher
(urlBienvenue).forward(request, response);
}
}
- 2-
© ENI Editions - All rigths reserved
...
La page de bienvenue accède au JavaBean client de façon simple et intuitive.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
BIENVENUE
Bienvenue client :
Pour rappel, la balise BIENVENUE
Bienvenue client :
Lire le JavaBean dans la session
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
Bienvenue client avec la session :
- 4-
© ENI Editions - All rigths reserved
L’instruction ... n’est exécuté que si le
JavaBean n’existe pas. Si un JavaBean convient, le code est ignoré.
Dans l’exemple suivant, si le JavaBean n’existe pas, il utilise d’autres valeurs pour l’identifiant et le mot de passe. Dans le cas
contraire, ce code n’est pas exécuté.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
BIENVENUE
Bienvenue client :
Lire le JavaBean dans la
session
3. Librairies de gestion des JavaBeans
© ENI Editions - All rigths reserved
- 5-
Les JavaBeans étant très utilisés dans le monde de la programmation Java, plusieurs sociétés et organismes ont développé
des librairies spécifiques de leur gestion et manipulation.
Nous
allons
utiliser
la
librairie
commonsbeansutils
développée
par
la
communauté
Apache
(http://commons.apache.org/beanutils/). Cette librairie très pratique, est désormais intégrée en standard dans de très
nombreux outils compatibles Java EE comme le framework Struts.
Le modèle (ou pattern en anglais) JavaBean est utilisé en standard, mais il manque parfois des méthodes aux librairies de
base Java pour manipuler ces objets. Cette adresse fournit tous les composants nécessaires à l’utilisation de la librairie
proposée par la communauté Apache :
(http://commons.apache.org/downloads/download_beanutils.cgi).
La documentation de l’API est présente à cette adresse :
(http://commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/packagesummary.html#package_description)
Après avoir téléchargé la librairie au format adapté, nous pouvons copier les archives .jar dans le répertoire /WEBINF/lib de
notre projet et renseigner le classpath Java. L’arborescence de notre projet est alors la suivante :
Pour insérer les nouvelles librairies dans le projet/classpath, il faut utiliser le menu Project Properties Java Build Path
Add External JARs et ajouter les librairies.
Nous allons aborder la manipulation des JavaBeans avec la librairie commonbeans et une nouvelle Servlet nommée
ServletCommonBean. Cette Servlet sera utilisée pour manipuler le JavaBean client inséré dans la session par la Servlet
d’authentification. Le JavaBean client est plus compliqué et possède désormais un attribut adresse qui est luimême un
objet.
package betaboutique.javabean;
public class Client implements java.io.Serializable {
private String identifiant=null;
- 6-
© ENI Editions - All rigths reserved
private String motdepasse=null;
private Adresse adresse=new Adresse();
//Constructeur par défaut (sans paramètre)
public Client()
{
}
public String getIdentifiant() {
return identifiant;
}
public void setIdentifiant(String identifiant) {
this.identifiant = identifiant;
}
public String getMotdepasse() {
return motdepasse;
}
public void setMotdepasse(String motdepasse) {
this.motdepasse = motdepasse;
}
public Adresse getAdresse() {
return adresse;
}
public void setAdresse(Adresse adresse) {
this.adresse = adresse;
}
}
package betaboutique.javabean;
public class Adresse implements java.io.Serializable {
private String adresse=null;
private String rue=null;
//Constructeur par défaut (sans paramètre)
public Adresse()
{
}
public String getAdresse() {
return adresse;
}
public void setAdresse(String adresse) {
this.adresse = adresse;
}
public String getRue() {
return rue;
}
public void setRue(String rue) {
this.rue = rue;
}
}
Nous allons réaliser une authentification par le biais de la Servlet adaptée qui va stocker un objet JavaBean client dans la
session et nous rediriger sur la page de bienvenue. Sur cette page de retour, nous allons utiliser un lien HTML pour
déclencher notre nouvelle Servlet de manipulation du JavaBean présent dans la session.
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
© ENI Editions - All rigths reserved
- 7-
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
Adresse adresseclient=new Adresse();
adresseclient.setAdresse("39800 POLIGNY");
adresseclient.setRue("2 rue du haut");
client.setAdresse(adresseclient);
HttpSession session=request.getSession();
session.setAttribute("client",client);
session.setAttribute("identifiantutilisateur", "un
autre identifiant envoyé avec la requête");
getServletContext().getRequestDispatcher
(urlBienvenue).forward(request, response);
}
}
...
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld" prefix="bb" %>
BIENVENUE
Bienvenue client :
Utiliser la librairie commonbean
package betaboutique.servlets.client;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.commons.beanutils.PropertyUtils;
import betaboutique.javabean.Client;
@SuppressWarnings("serial")
public class ServletCommonBean extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer la session
HttpSession session=request.getSession();
//créer un JavaBean client
Client client=new Client();
//récupérer notre JavaBean dans la session
client=(Client)session.getAttribute("client");
//afficher l’identifiant du client
System.out.println("identifiant : "+client.getIdentifiant());
- 8-
© ENI Editions - All rigths reserved
//afficher les infos du client avec commonbean
try
{
System.out.println("identifiant commonbean :
"+PropertyUtils.getSimpleProperty(client,"identifiant"));
//changer une propriété du JavaBean à la volée
PropertyUtils.setSimpleProperty(client,
"identifiant","ma nouvelle valeur");
System.out.println("identifiant commonbean :
"+PropertyUtils.getSimpleProperty(client,"identifiant"));
//lire une propriété objet du JavaBean
System.out.println("adresse commonbean :
"+PropertyUtils.getNestedProperty(client,"adresse.rue"));
}
catch(Exception e)
{
System.out.println("Erreur de lecture");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
La classe PropertyUtils a été utilisée car elle permet de manipuler des JavaBeans en programmation Java (donc dans une
Servlet ou page JSP). Il est possible d’accéder à l’objet ainsi qu’à l’ensemble de ses propriétés.
La classe PropertyUtils permet de manipuler un JavaBean existant (instancié à partir d’une classe JavaBean). La classe
DynaBean permet de manipuler des JavaBeans créés à partir d’une classe ou des JavaBeans créés à la volée, sans avoir une
classe correspondante. Par exemple, toutes les données d’un formulaire HTML pour l’inscription d’une personne seront
stockées dans un DynaBean et manipulées comme un JavaBean. La classe WrapDynaBean permet de réaliser la
transformation d’un JavaBean vers un DynaBean.
Nous allons modifier notre classe pour créer un objet DynaBean à partir d’un JavaBean et afficher ses valeurs.
package betaboutique.servlets.client;
import
import
import
import
import
import
import
import
import
import
java.io.IOException;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
javax.servlet.http.HttpSession;
org.apache.commons.beanutils.DynaBean;
org.apache.commons.beanutils.WrapDynaBean;
betaboutique.javabean.Adresse;
betaboutique.javabean.Client;
@SuppressWarnings("serial")
public class ServletCommonBean extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer la session
HttpSession session=request.getSession();
//créer un JavaBean client
Client client=new Client();
//récupérer notre JavaBean dans la session
client=(Client)session.getAttribute("client");
try
{
//transformer l’objet client JavaBean en DynaBean
DynaBean dynaBeanclientcopie = new WrapDynaBean(client);
//lecture de ses valeurs
System.out.println("dynaclient recopié identifiant :
"+dynaBeanclientcopie.get("identifiant"));
Adresse adresse=(Adresse)(dynaBeanclientcopie.get("adresse"));
© ENI Editions - All rigths reserved
- 9-
System.out.println("dynaclient recopié adresse :
"+adresse.getRue());
}
catch(Exception e)
{
System.out.println("Erreur de lecture");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
La classe LazyDynaBean permet de créer directement des DynaBeans, afin de les manipuler par la suite dans nos pages et de
bénéficier de la puissance de ces objets.
package betaboutique.servlets.client;
import
import
import
import
import
import
import
java.io.IOException;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
org.apache.commons.beanutils.DynaBean;
org.apache.commons.beanutils.LazyDynaBean;
@SuppressWarnings("serial")
public class ServletCommonBean extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try
{
//créer un dynabean dynamiquement
DynaBean dynaBeanclient = new LazyDynaBean();
dynaBeanclient.set("age","12 ans");
dynaBeanclient.set("profession","vendeur");
System.out.println("dynaclient créé :
"+dynaBeanclient.get("age"));
System.out.println("dynaclient créé :
"+dynaBeanclient.get("profession"));
}
catch(Exception e)
{
System.out.println("Erreur de lecture");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Une autre classe très utile de manipulation des JavaBeans est la classe BeanUtils. Nous allons utiliser cette classe avec un
formulaire HTML simple. Le formulaire nommé : article.html permet de saisir le nom de l’article, sa référence et son prix.
Authentification BetaBoutique
- 10 -
© ENI Editions - All rigths reserved
Article
Cette page va déclencher la Servlet ServletArticle qui permet de renseigner directement un JavaBean article et d’aller sur une
page d’affichage de l’article (article.jsp).
...
servletarticle
betaboutique.servlets.client.ServletArticle
...
servletarticle
/article
...
package betaboutique.servlets.client;
import java.io.IOException;
import java.util.Enumeration;
import java.util.HashMap;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.beanutils.BeanUtils;
import betaboutique.javabean.Article;
@SuppressWarnings("serial")
public class ServletArticle extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//attention, pas de contrôle sur les saisies !
//création d’un JavaBean article
Article article=new Article();
//création d’une collection
HashMap map = new HashMap();
Enumeration names = request.getParameterNames();
while (names.hasMoreElements())
{
// chaque paramètre de la requête est mis dans une collection
String name = (String) names.nextElement();
map.put(name,request.getParameterValues(name));
© ENI Editions - All rigths reserved
- 11 -
}
try
{
//insérer toutes nos données dans le Bean
article en une seule étape
BeanUtils.populate(article, map);
//appeler la page d’affichage de l’article,
insérer l’article dans une base ou autre...
System.out.println("Article : "+article.getNomarticle());
//l’objet JavaBean article est mis dans la requête
request.setAttribute("article", article);
//redirection sur la page d’affichage
getServletContext().getRequestDispatcher
("/article.jsp").forward(request, response);
}
catch(Exception e)
{
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld" prefix="bb" %>
FICHE ARTICLE
ARTICLE acteurs=new ArrayList();
//Constructeur par défaut (sans paramètre)
public Article()
{
}
public String getNomarticle() {
return nomarticle;
}
public void setNomarticle(String nomarticle) {
this.nomarticle = nomarticle;
}
public float getPrixarticle() {
return prixarticle;
}
public void setPrixarticle(float prixarticle) {
this.prixarticle = prixarticle;
}
public String getRefarticle() {
return refarticle;
}
public void setRefarticle(String refarticle) {
this.refarticle = refarticle;
}
public ArrayList getActeurs() {
return acteurs;
}
public void setActeurs(ArrayList acteurs) {
this.acteurs = acteurs;
}
}
Le formulaire HTML permet de saisir les articles avec des champs Authentification BetaBoutique
Article
La Servlet est un peu plus complexe et permet de recomposer la collection des acteurs et de la stocker dans le JavaBean. La
page d’affichage permet de parcourir la collection contenue dans le Bean.
package betaboutique.servlets.client;
import
import
import
import
import
import
import
import
import
import
java.io.IOException;
java.util.ArrayList;
java.util.Enumeration;
java.util.HashMap;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
org.apache.commons.beanutils.BeanUtils;
betaboutique.javabean.Article;
@SuppressWarnings("serial")
public class ServletArticle extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//création d’un JavaBean article
Article article=new Article();
//liste des acteurs
ArrayList acteurs=new ArrayList();
//création d’une collection
HashMap map = new HashMap();
Enumeration names = request.getParameterNames();
while (names.hasMoreElements())
{
//chaque paramètre de la requête est mis dans une collection
String name = (String) names.nextElement();
//premier acteur
if(name.equals("acteur1"))
{
acteurs.add((String)request.getParameter(name));
}
//second acteur
else if(name.equals("acteur2"))
{
acteurs.add((String)request.getParameter(name));
}
//paramètre habituel
else
{
map.put(name,request.getParameterValues(name));
}
}
- 14 -
© ENI Editions - All rigths reserved
//fin de la boucle, mettre la liste des acteurs dans le JavaBean
map.put("acteurs",acteurs);
try
{
//insérer toutes nos données dans le Bean
article en une seule étape
BeanUtils.populate(article, map);
//l’objet JavaBean article est mis dans la requête
request.setAttribute("article", article);
//redirection sur la page d’affichage
getServletContext().getRequestDispatcher
("/article.jsp").forward(request, response);
}
catch(Exception e)
{
System.out.println("Erreur dans la Servlet ServletArticle");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld"
prefix="bb" %>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
FICHE ARTICLE
ARTICLE acteurs=new ArrayList();
//création d’une collection
HashMap map = new HashMap();
Enumeration names = request.getParameterNames();
while (names.hasMoreElements())
{
//chaque paramètre de la requête est mis dans une collection
String name = (String) names.nextElement();
//premier acteur
if(name.equals("acteur1"))
{
acteurs.add((String)request.getParameter(name));
}
//second acteur
else if(name.equals("acteur2"))
{
acteurs.add((String)request.getParameter(name));
}
//paramètre habituel
else
{
- 16 -
© ENI Editions - All rigths reserved
map.put(name,request.getParameterValues(name));
}
}
//fin de la boucle, mettre la liste des acteurs
dans le JavaBean map.put("acteurs",acteurs);
try
{
//insérer toutes nos données dans le Bean
article en une seule étape
BeanUtils.populate(article, map);
try
{
//sérialiser notre objet article dans un
fichier binaire nommé article.dat
ObjectOutputStream f=new ObjectOutputStream(new
FileOutputStream("C:\\article.dat"));
//écriture
f.writeObject(article);
f.flush();
f.close();
}
catch(Exception e)
{
System.out.println("Erreur dans la Servlet ServletArticle");
}
}
catch(Exception e)
{
System.out.println("Erreur dans la Servlet ServletArticle");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
b. Désérialiser un objet
La classe ObjectInputStream permet de lire un flux sérialisé en entrée et donc de désérialiser un objet depuis un flux. La
désérialisation permet de lire un objet (ou plusieurs) et de créer de nouvelles instances de cet objet à partir de l’état de
celui sauvegardé. La méthode readObject() retourne une référence de type Object. Il y aura donc juste à réaliser un
transtypage (cast) de l’objet pour l’utiliser.
Nous allons créer une page JSP nommée deserialisationarticle.jsp qui permet de lire le JavaBean et de l’afficher en direct.
Cette page sera appelée directement et sera fonctionnelle tant que l’objet sérialisé article.dat sera présent sur le disque de
la machine.
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ page import="java.io.ObjectInputStream" %>
<%@ page import="java.io.FileInputStream" %>
<%@ page import="betaboutique.javabean.Article" %>
FICHE ARTICLE
<%
//lecture de l’objet sérialisé
ObjectInputStream f = new ObjectInputStream(new
FileInputStream("C:\\article.dat"));
© ENI Editions - All rigths reserved
- 17 -
Article articleserialise = (Article) f.readObject();
%>
ARTICLE FICHE ARTICLE
<%
//lecture de l’objet sérialisé
XMLDecoder e = new XMLDecoder(new BufferedInputStream(new
FileInputStream("C:\\article.xml")));
Article articleserialise = (Article) e.readObject();
%>
ARTICLE FICHE ARTICLE
<%
//lecture de l’objet sérialisé
XStream xstream = new XStream(new DomDriver());
FileInputStream fis = new FileInputStream(new File
("C:\\article.xml"));
Article articleserialise =null;
try
{
articleserialise = (Article) xstream.fromXML(fis);
}
catch(Exception e)
{
}
%>
ARTICLE
<%= buffer %>
BETABOUTIQUE
FICHE ARTICLE
Titre : Référence : Prix : Acteur(s) :
tr>Nom
xsl:for-each select="/betaboutique.javabean.Article/
acteurs/string">
#eaeaea
© ENI Editions - All rigths reserved
- 23 -
La page JSP de transformation du contenu XML en contenu HTML est la suivante :
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="com.thoughtworks.xstream.XStream" %>
<%@ page import="com.thoughtworks.xstream.io.xml.DomDriver" %>
<%@ page import="betaboutique.javabean.Article" %>
<%@ taglib uri="/WEB-INF/tld/c.tld" prefix="c" %>
<%@ taglib uri="/WEB-INF/tld/x.tld" prefix="x" %>
<%
String buffer=null;
Article article=(Article)request.getAttribute("article");
if(article!=null)
{
//instanciation d’un objet xstream
XStream xstream = new XStream(new DomDriver());
//stocker le flux XML dans un buffer
buffer=xstream.toXML(article);
}
%>
<%= buffer %>
Authentification BetaBoutique
Authentification - Client
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
© ENI Editions - All rigths reserved
- 1-
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
//insérer le JavaBean dans la requête
request.setAttribute("client", client);
//redirection simple
response.sendRedirect("bienvenue.jsp");
}
}
...
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
BIENVENUE
Bienvenue client :
Dans cet exemple, la page bienvenue.jsp ne peut pas afficher le JavaBean client. En effet, l’action
response.sendRedirect(’’bienvenue.jsp’’) réalise une redirection forcée et perd les données présentes dans la requête.
Cette technique permet de vider, la totalité de la requête et donc d’éviter par exemple de réaliser plusieurs
insertions d’un même article dans un panier en cas de rafraîchissement de la page par l’utilisateur.
Avec cette méthode, il est quand même possible de forcer le passage de paramètre uniquement en GET avec les
appels HTTP. Voici un second exemple avec le passage d’un message dans la redirection forcée.
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//créer un JavaBean client
client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
//insérer le JavaBean dans la requête
request.setAttribute("client", client);
//redirection simple
response.sendRedirect("bienvenue.jsp?message=bienvenue");
}
}
...
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/tld/betaboutique.tld" prefix="bb" %>
- 2-
© ENI Editions - All rigths reserved
BIENVENUE
Bienvenue client :
<% out.println("Message : "+request.getParameter("message"))
; %>
Pour réaliser des transferts de contrôle entre une Servlet et une page JSP sans perdre les données, nous devons
utiliser le RequestDispatcher. Cette classe permet de positionner des attributs dans la requête (session, context...) et
de les lire dans une page JSP appelée.
La Servlet précédente est modifiée avec l’utilisation de la classe RequestDispatcher.
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
//insérer le JavaBean dans la requête
request.setAttribute("client", client);
//redirection simple
getServletContext().getRequestDispatcher("/bienvenue.jsp?
message=bienvenue").forward(request, response);
}
}
...
Il est possible d’améliorer l’exemple précédent en passant le paramètre message dans la requête et non dans le nom
de la page. Par contre, dans ce cas, il faut modifier la page bienvenue.jsp afin d’utiliser la méthode getAttribute(...) et
non getParameter(...).
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//créer un JavaBean client
Client client=new Client();
client.setIdentifiant(identifiant);
client.setMotdepasse(motdepasse);
//insérer le JavaBean dans la requête
request.setAttribute("client", client);
//insérer le message dans la requête
request.setAttribute("message", "bienvenue sur le site");
© ENI Editions - All rigths reserved
- 3-
//redirection simple
getServletContext().getRequestDispatcher
("/bienvenue.jsp").forward(request, response);
}
}
...
b. Transfert du contrôle d’une page JSP à une Servlet
Lors du développement d’une application, il est très fréquent qu’une page JSP transfère le contrôle à une Servlet
avec des informations associées.
Pour réaliser cette opération, il faut utiliser la directive . Cette directive permet
également de passer des paramètres à la Servlet avec la directive
Bien que cette technique soit très simple d’utilisation, elle n’est pas très souvent utilisée étant donné que dans la
plupart des cas c’est l’utilisateur luimême qui déclenche, par l’intermédiaire d’un lien ou d’un formulaire HTML, la
Servlet appelée par la page JSP.
c. Transfert du contrôle d’une page JSP à une autre page JSP
Une page JSP peut donner le contrôle à une autre page JSP en utilisant deux méthodes :
●
En utilisant la directive Authentification BetaBoutique
Authentification - Client
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="betaboutique.javabean.Client" %>
BIENVENUE
Bienvenue client :
<%
out.println("Identifiant : "+request.getParameter("identifiant")+"REPERTOIRE
<%
//nom du fichier présent sur le disque dur
String nomFichier="C:"+java.io.File.separatorChar+"article.xml";
//instancier un objet file
File file=new File(nomFichier);
//présence du fichier sur le disque
if(file.exists() && file.isFile())
{
out.println("Le fichier "+nomFichier+" existe sur le systèmeREPERTOIRE
<%
//nom du fichier présent sur le disque dur
String nomFichier="C:"+java.io.File.separatorChar+"unzipped";
//instancier un fichier
File fichier=new File(nomFichier);
//listing du répertoire
File[] listing=fichier.listFiles();
//afficher l’arborescence
out.println("");
for(int i=0;i"+listing[i]+"");
}
out.println(" ");
//créer un répertoire nommé essai dans nomFichier
File nouveauRepertoire=new File(nomFichier+java.io.File.
separatorChar+"essai");
nouveauRepertoire.mkdir();
//afficher la liste des racines
File[] listeRacine=File.listRoots();
out.println("");
for(int i=0;i"+listeRacine[i]+"");
}
out.println(" ");
%>
3. Travailler avec les fichiers
Nous allons créer une page JSP nommée fichier.jsp avec un ensemble de commandes pour gérer les fichiers en Java.
Les opérations de base seront utilisées, avec l’écriture de données et la lecture d’informations.
La première étape consiste à créer un objet de type File, qui servira à spécifier le chemin et le nom du fichier que nous
souhaitons lire. Ensuite, un objet de type FileReader utilisant l’objet de type File, doit être créé.
La lecture des informations en provenance d’un fichier sera meilleure si les informations sont stockées au fur et à
mesure dans un tampon. La méthode readLine() de l’objet BufferedReader permet de lire une ligne dans un fichier avec
le caractère de rupture indiquant une nouvelle ligne.
<%@ page language="java" contentType="text/html;
- 2-
© ENI Editions - All rigths reserved
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.io.File" %>
<%@ page import="java.io.FileReader" %>
<%@ page import="java.io.BufferedReader" %>
FICHIER
<%
//nom du fichier présent sur le disque dur
String nomFichier="C:"+java.io.File.separatorChar+"article.xml";
//instancier un objet file
File file=new File(nomFichier);
//instancier un file reader
FileReader filereader=new FileReader(file);
//instancier un buffer
BufferedReader buffreader=new BufferedReader(filereader);
//lecture du contenu du fichier
String ligne=null;
while((ligne=buffreader.readLine())!=null)
{
out.println("Ligne : "+ligne+"MaServlet1 en GET ");
out.println("");
out.flush();
out.close();
}
}
Cette Servlet génère un warning The serializable class MaServlet1 does not declare a static final serialVersionUID field of
© ENI Editions - All rigths reserved
- 5-
type long. En effet, une classe sérialisable (comme les JavaBeans) utilise un attribut serialVersionUID qui permet
d’affecter un numéro de version à la classe. Ce numéro doit être changé et mis à jour lorsque un champ sérialisable
(non transient) est ajouté ou supprimé de la classe. C’est donc au développeur de gérer ce numéro de version, mais si
ce numéro est absent, le compilateur génèrera un numéro automatiquement. Le champ serialVersionUID est utilisé lors
de la désérialisation, afin de vérifier que les versions des classes Java sont correctes. Il est donc conseillé de gérer le
champ serialVersionUID pour les classes sérialisables et de changer cette valeur lors d’un changement sur les champs
de la classe. Pour définir l’attribut serialVersionUID, après la définition de la classe, le code suivant est utilisé :
private static final long serialVersionUID=1L;
Ce numéro (1L) n’a pas d’importance mais par convention, on utilise 1L, 2L... Sa valeur n’a pas d’importance du
moment qu’elle est mise à jour lors de changements sur les champs sérialisables. Java 5.0/6.0 a introduit de nombreux
warnings qui sont des avertissements mais qui n’empêchent pas l’exécution du code. Il est possible d’utiliser la
notation suivante @SuppressWarning afin de supprimer un warning spécifique. Ainsi les warnings de version peuvent
être supprimés avec cette syntaxe (attention, il n’y a pas de point virgule en fin d’instruction).
@SuppressWarnings("serial")
public class ServletAuthentification extends HttpServlet...}
Il est également possible de cacher un warning sur une méthode avant la déclaration de celleci, mais il est important
de limiter au maximum la portée de l’annotation @SuppressWarnings. En effet, devant une méthode, la portée concerne
la méthode ellemême mais devant une classe, elle concerne la totalité de cette dernière.
Cette première Servlet est compilée automatiquement par Eclipse (Projet Build Automatically). Elle est déployée
dans le répertoire : /WEBINF/classes/betaboutique/servlets/exemples/MaServlet1.class.
Nous pouvons créer une page HTML simple (nommée maservlet1.html) avec un lien hypertexte pour déclencher cette
Servlet. Le code suivant est placé à la racine de l’application (dans le répertoire du projet betaboutique).
MaServlet1
Invoquer la Servlet MaServlet1
a. Comment effectuer le lien entre la Servlet et l’URL?
Le fichier web.xml permet de paramétrer les Servlets de l’application. Chaque Servlet de l’application doit être décrite
dans le fichier web.xml et le lien de la Servlet avec l’URL y figure également.
La déclaration d’une Servlet se fait dans l’élément XML :
●
est le nom interne de la Servlet, il l’identifie de façon unique.
●
est la classe Java associée à la Servlet (notre classe Java).
Le lien entre l’URL/URI et la Servlet s’effectue grâce à l’élément :
●
est le nom interne donné à la Servlet qui doit être identique à celui indiqué dans l’élément
.
●
est l’URL permettant de faire le lien avec la Servlet.
servletmaservlet1
betaboutique.servlets.exemples.MaServlet1
- 6-
© ENI Editions - All rigths reserved
servletmaservlet1
/maservlet1
À chaque Servlet doit correspondre un élément dans le fichier de configuration web.xml sinon, la Servlet
n’existera pas pour le serveur d’applications. Le fichier /WEBINF/web.xml n’est pas créé par défaut par Eclipse. Nous
pouvons le créer à partir d’un ancien projet qui fonctionne en réalisant un simple copier/coller ou avec les
commandes suivantes d’Eclipse : clic droit sur le répertoire /WEBINF, New Other XML.
Désormais
si
nous
tapons
l’adresse
suivante
dans
le
navigateur :
http://localhost:8080/betaboutique/maservlet1.html, nous pouvons accéder à la page HTML qui va déclencher la
Servlet par l’intermédiaire d’un lien. Nous pouvons également déclencher directement la Servlet à cette adresse :
http://localhost:8080/betaboutique/maservlet1.
Ceci ne peut fonctionner que si le mapping de la Servlet avec l’URL a été correctement effectué dans le fichier
web.xml.
b. Comment cela fonctionnetil ?
Ce fonctionnement est très puissant et permet ainsi de déclencher des Servlets suivant des modèles d’URL. Dans
l’exemple précédant l’appel à une URL du type : http://localhost:8080/betaboutique/maservlet1 déclenche la Servlet
de nom servletmaservlet1 qui est liée au fichier MaServlet1.class.
Il est possible, par exemple, de modifier ce fonctionnement en déclenchant la Servlet suite à l’appel d’une ’’fausse’’
page nommée maservlet1html.html.
...
servletmaservlet1
/maservlet1html.html
...
Attention, il est important de bien recharger le serveur après chaque modification du fichier de configuration
web.xml avec le manager de Tomcat par exemple : http://localhost:8080/manager/html/.
Ce mécanisme très puissant est utilisé par les serveurs du monde entier. Ce système peut être amélioré en
précisant que toutes les URL qui se terminent par exemple par .spsf déclencheront notre Servlet. Ceci pourra être
utilisé pour un service particulier de l’application (télécharger le catalogue, une fiche article en PDF...).
...
servletmaservlet1
*.spsf
...
© ENI Editions - All rigths reserved
- 7-
c. L’objet response
Dans l’exemple de la Servlet précédente, l’objet response permet d’envoyer des données au navigateur client. Cet
objet permet d’envoyer la réponse au format TEXT, HTML, XML, sous forme de tableau d’octets... L’exemple
précédent utilise un entête de réponse au format HTML response.setContentType(’’text/html’’). Voici ciaprès quatre
exemples différents.
Le premier permet de renvoyer au navigateur un contenu au format HTML.
package betaboutique.servlets.exemples;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MaServlet1 extends HttpServlet
{
public void doGet(HttpServletRequest req, HttpServletResponse
res)throws ServletException, IOException
{
res.setContentType("text/html");
PrintWriter out=res.getWriter();
out.println("");
out.println("MaServlet1 en GET ");
out.println("");
out.flush();
out.close();
}
}
Le second exemple permet de renvoyer un contenu au format XML.
package betaboutique.servlets.exemples;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MaServlet1 extends HttpServlet
{
public void doGet(HttpServletRequest req, HttpServletResponse
res)throws ServletException, IOException
{
res.setContentType("text/xml");
PrintWriter out=res.getWriter();
out.println("");
out.println("");
out.println("Garde à vue ");
out.println(" ");
- 8-
© ENI Editions - All rigths reserved
out.flush();
out.close();
}
}
Le troisième permet de renvoyer un contenu dynamique sous la forme d’un flux d’octets (une image dans ce cas).
package betaboutique.servlets.exemples;
import java.awt.Graphics2D;
import java.awt.Image;
import java.awt.image.BufferedImage;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import javax.imageio.ImageIO;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.swing.ImageIcon;
public class MaServlet1 extends HttpServlet
{
public void doGet(HttpServletRequest req, HttpServletResponse
res)throws ServletException, IOException
{
//acquerir l’image si elle existe
Image image=null;
File source=new File("E:\\PROJETWEB\\betaboutique\\monimage.png");
if(source.exists())
{
//acquisition de l’image
java.awt.Toolkit toolkit=java.awt.Toolkit.getDefaultToolkit();
image=toolkit.getImage("E:\\PROJETWEB\\
betaboutique\\monimage.png");
//transformer l’image en BufferedImage
image=new ImageIcon(image).getImage();
BufferedImage bufferedImage=newBufferedImage(image.getWidth(null),
image.getHeight(null),BufferedImage.TYPE_INT_RGB);
Graphics2D g2=bufferedImage.createGraphics();
g2.drawImage(image,0,0,null);
g2.dispose();
//sortie de l’image dans le navigateur
response.reset();
response.setContentType("image/png");
response.setHeader("Pragma","no-cache");
response.setHeader("Cache-Control","no-cache");
response.setDateHeader("Expires",0);
response.setHeader("Content-Disposition","filename=\"monimage\"");
ByteArrayOutputStream fluxout=new ByteArrayOutputStream();
try
{
ImageIO.write(bufferedImage,"png",fluxout);
fluxout.writeTo(response.getOutputStream());
fluxout.close();
}
catch(Exception e){}
finally
{
if(fluxout!=null) fluxout.close();
if(bufferedImage!=null)bufferedImage=null;
}
}
else{
System.out.println("Image non trouvée sur le disque dur");
}
}
}
© ENI Editions - All rigths reserved
- 9-
Enfin, le dernier exemple permet de forcer un téléchargement et d’envoyer un fichier du serveur vers le client.
package betaboutique.servlets.exemples;
import
import
import
import
import
import
import
import
import
java.io.BufferedInputStream;
java.io.File;
java.io.FileInputStream;
java.io.IOException;
javax.servlet.ServletException;
javax.servlet.ServletOutputStream;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
public class MaServlet1 extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
response.setContentType("application/download");
response.setHeader("Content-Disposition",
"attachment;filename=\"monimage.png\"");
ServletOutputStream out=response.getOutputStream();
File file=null;
BufferedInputStream from=null;
try
{
file=new File("E:\\PROJETWEB\\betaboutique\\monimage.png");
response.setContentLength((int) file.length());
int bufferSize=64 * 1024;
try
{
from=new BufferedInputStream(new FileInputStream(file),
bufferSize * 2);
byte[] bufferFile = new byte[bufferSize];
for (int i=0; ;i++)
{
int len=from.read(bufferFile);
if (len < 0) break;
out.write(bufferFile, 0, len);
}
out.flush();
}
finally
{
try {from.close();}catch (Exception e){}
try {out.close();}catch (Exception e){}
}
- 10 -
© ENI Editions - All rigths reserved
}
catch (Exception e)
{
return;
}
}
}
d. L’objet request
L’objet request est également très puissant et permet de gérer les données envoyées avec la requête à la Servlet.
Par exemple les paramètres utilisateur (getParameter(...)) et les paramètres à valeurs multiples comme les champs
(getParameterValues(...)) peuvent être récupérés. La méthode getParameterNames(...) retourne
une énumération des noms des paramètres de la requête. La méthode getParameterMap(...) retourne une
énumération de tous les paramètres stockés dans un objet de type Map (collection).
e. La méthode doPost()
La méthode doPost(...) d’une Servlet est invoquée principalement lors de l’envoi de données saisies dans un
formulaire HTML (validation par un bouton de type submit par exemple). Pour résumer, le développeur doit coder le
plus souvent deux méthodes importantes qui sont doGet(...) et doPost(...).
Il est judicieux que l’une de ces méthodes (par exemple doPost(...)) appelle l’autre pour que la Servlet fonctionne
correctement avec la plupart des cas d’utilisation.
package betaboutique.servlets.exemples;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MaServlet1 extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
© ENI Editions - All rigths reserved
- 11 -
{
PrintWriter out=response.getWriter();
out.println("Invocation de la MaServlet1 en GET ou POST");
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
- 12 -
© ENI Editions - All rigths reserved
Servlet authentification
1. Gérer l’authentification client
Nous allons mettre en application l’utilisation de Servlets pour le projet BetaBoutique. Pour cela, nous allons créer la
Servlet et les pages associées pour le service d’authentification client. Dans un premier temps, un seul client pourra
s’authentifier par identifiant et mot de passe avec une vérification des données dans la Servlet. Pour cela, nous
commençons par créer un nouveau paquetage betaboutique.servlets.client.
Sous Eclipse, il est facile d’insérer une Servlet sans écrire tout le code nécessaire pour les méthodes HTTP. Le
développeur doit juste surcharger les méthodes doGet(...) et doPost(...).
Nous faisons un clic droit sur le paquetage concerné (betaboutique.servlets.client), nous sélectionnons les étapes New
Other.
Nous sélectionnons alors l’onglet Web puis Servlet afin de créer notre nouvelle Servlet dans le paquetage adapté.
© ENI Editions - All rigths reserved
- 1-
Nous pouvons également créer une nouvelle Servlet simplement en utilisant les étapes suivantes : clic droit sur le
paquetage concerné, New class.
Comme indiqué dans la maquette du projet BetaBoutique, pour l’authentification, l’utilisateur doit saisir son
identifiant/login et son mot de passe. Pour cela nous allons utiliser un formulaire HTML simple (authentification.html) qui
va invoquer la Servlet d’authentification (ServletAuthentification).
Une nouvelle page HTML peut être insérée à la racine, New Other Web HTML.
Authentification BetaBoutique
Authentification - Client
Désormais, il faut réaliser le mapping dans le fichier de configuration
action=’’authentificationclient’’...> déclenche notre Servlet : ServletAuthentification.
pour
que
l’appel
"+
""+
""
);
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Cette page est désormais totalement dynamique. Un message peut éventuellement être affiché en fonction de
l’authentification (échec ou succès) et les saisies de l’utilisateur sont conservées dans les champs du formulaire.
Toutefois, nous remarquons immédiatement que la Servlet est mal adaptée pour générer du code HTML. Le
fonctionnement était beaucoup plus simple et clair avec une page HTML pour le déclenchement et une Servlet pour la
logique applicative.
Par la suite, c’est là qu’interviendront les pages JSP.
- 6-
●
Les pages d’appels et de réponses seront des documents dynamiques JSP.
●
La logique de traitement des requêtes sera assurée par des Servlets.
© ENI Editions - All rigths reserved
Interface ServletConfig
1. Présentation
L’objet de type javax.servlet.ServletConfig représente les informations de configuration d’une Servlet au sein d’une
application Web.
Le conteneur Web va créer un objet de type javax.servlet.ServletConfig pour chaque élément déclaré dans le
fichier de configuration de l’application web.xml.
Pour déclarer une Servlet dans le fichier de configuration web.xml, nous retrouvons le nom de la Servlet, la classe Java
associée ainsi qu’une éventuelle/optionnelle liste de paramètres de la forme nom/valeur. Ces informations de
configuration peuvent ensuite être récupérées par la Servlet de préférence dans la méthode init(...).
Le fichier de configuration peut avoir zéro ou plusieurs éléments par Servlet. Chaque élément correspond à un paramètre représenté par une paire nom/valeur avec et .
Nous allons modifier notre précédente Servlet pour définir l’identifiant et le mot de passe dans le fichier de
configuration plutôt que dans la Servlet ellemême.
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
defautMotDePasse
monmotdepasse
servletauthentification
/authentificationclient
2. Initialisation d’une Servlet
Après son chargement en mémoire, le conteneur Web passe en phase d’initialisation de la Servlet et la méthode init
(...) est invoquée. La méthode init(...) est très souvent surchargée pour récupérer des informations de configuration,
charger des ressources utiles à la Servlet... L’interface ServletConfig permet ensuite de manipuler les paramètres du
fichier de configuration de l’application web.xml. La méthode getInitParameter(...) permet de récupérer la chaîne de
caractères associée à un paramètre dans le fichier de configuration (ou la valeur null si le paramètre n’existe pas).
La méthode getInitParameterNames() permet de récupérer sous la forme d’une énumération l’ensemble des
paramètres déclarés dans le fichier de configuration.
La méthode getServletName() permet de récupérer le nom de la Servlet déclarée au sein du descripteur de
déploiement.
L’exemple suivant est une amélioration de la Servlet d’authentification afin de lire l’identifiant et le mot de passe dans
le fichier de configuration pour perfectionner la maintenabilité de l’ensemble.
package betaboutique.servlets.client;
import java.io.IOException;
import java.io.PrintWriter;
© ENI Editions - All rigths reserved
- 1-
import
import
import
import
import
javax.servlet.ServletConfig;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
public void init()
{
//récupération des paramètres d’initialisation
de la Servlet dans le fichier web.xml
ServletConfig config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupération de l’identifiant/login dans la requête
String identifiant=request.getParameter("identifiant");
//récupération du mot de passe dans la requête
String motdepasse=request.getParameter("motdepasse");
//flux de sortie
PrintWriter out=response.getWriter();
//pas d’identifiant
if(identifiant==null)
{
out.println("Authentification incorrecte !");
}
//pas de mot de passe
if(motdepasse==null)
{
out.println("Authentification incorrecte !");
}
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
out.println("Authentification correcte,
bienvenue : "+identifiant);
}
else
{
out.println("Authentification incorrecte, mauvaise
saisie des informations !");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
- 2-
© ENI Editions - All rigths reserved
Interface ServletContext
1. Présentation
La précédente interface ServletConfig est très intéressante pour gérer des paramètres qui sont propres à une Servlet
comme un mot de passe, une clé de cryptage ou un chemin vers un fichier du disque dur.
À l’inverse de l’objet javax.servlet.ServletConfig qui représente les informations de configuration d’une Servlet au sein
d’une application Web, un objet de type javax.servlet.ServletContext représente les informations de configuration d’une
application Web totale. Chaque Servlet de la même application Web aura donc accès à ces paramètres.
Une autre propriété très importante de l’objet javax.servlet.ServletContext est qu’il peut également interagir avec le
conteneur Web de l’application. Il y aura donc un accès en lecture mais aussi un autre accès en écriture dans le fichier
de configuration. Le but étant alors de créer, lire et supprimer des attributs de façon dynamique, ce qui permet alors le
partage de ressources entre Servlets d’une même application Web.
2. Utilisation
Un objet de type javax.servlet.ServletContext est obtenu en invoquant directement la méthode getServletContext() dans
les méthodes des Servlets (objet servlet).
De la même manière que la déclaration spécifique de paramètre par Servlet, il est possible de déclarer des paramètres
globaux pour toute l’application. Par exemple, il est possible de déclarer l’adresse email du Webmestre, de
l’administrateur, une URL complète, une adresse IP fixe, un répertoire, une base de données, le pilote JDBC... Des
objets pour des pools de connexions et des objets partagés peuvent être aussi déclarés.
L’élément , racine du fichier de configuration web.xml, peut contenir zéro ou plusieurs éléments qui permettent de déclarer des paramètres de l’application Web. Chaque élément
correspond à un paramètre représenté par une paire nom/valeur avec les éléments et .
Pour notre projet Betaboutique, nous allons ajouter l’email de l’administrateur à contacter lors de l’authentification.
emailAdministrateur
admin@betaboutique.fr
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
defautMotDePasse
monmotdepasse
servletauthentification
/authentificationclient
3. Récupérer des paramètres
Pour récupérer les paramètres présents dans le fichier de configuration, il existe plusieurs méthodes. La première
méthode getInitParameter(param) permet de récupérer une chaîne de caractères contenant la valeur d’un paramètre
© ENI Editions - All rigths reserved
- 1-
ou null si le paramètre n’existe pas. La seconde méthode getInitParameterNames() permet de retourner l’énumération
de l’ensemble des paramètres déclarés dans le fichier de configuration.
La Servlet d’authentification est modifiée afin d’afficher l’email de l’administrateur du site en cas d’erreur. Il faut
remarquer l’utilisation de l’objet de type javax.servlet.ServletContext.
package betaboutique.servlets.client;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
String emailadministrateur=null;
public void init()
{
//récupération des paramètres d’initialisation
de la Servlet dans le fichier web.xml
config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
//récupérer l’email de l’administrateur
ServletContext servletContext=getServletContext();
emailadministrateur=servletContext.getInitParameter
("emailAdministrateur");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupération de l’identifiant/login dans la requête
String identifiant=request.getParameter("identifiant");
//récupération du mot de passe dans la requête
String motdepasse=request.getParameter("motdepasse");
//flux de sortie
PrintWriter out=response.getWriter();
//pas d’identifiant
if(identifiant==null)
{
out.println("Authentification incorrecte !");
}
//pas de mot de passe
if(motdepasse==null)
{
.println("Authentification incorrecte !");
}
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
out.println("Authentification correcte,
bienvenue : "+identifiant);
}
else
{
out.println("Authentification incorrecte, mauvaise
saisie des informations !");
out.println("Veuillez contacter : "+emailadministrateur);
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
- 2-
© ENI Editions - All rigths reserved
}}
4. Ajouter des paramètres
L’avantage de l’utilisation de l’interface ServletContext est la possibilité d’ajouter des attributs à la volée de manière
logicielle (en programmation). Le contexte est accessible par l’ensemble des Servlets/JSP de l’application Web et peut
donc stocker, récupérer et détruire des attributs. Contrairement à l’interface ServletConfig, des objets divers peuvent
être gérés et pas seulement des chaînes de caractères.
Ce procédé très utile permet par exemple de déclarer au lancement de l’application un objet pour la connexion à la
base de données et de le stocker à la volée dans le fichier de configuration comme variable globale. La connexion sera
alors disponible pour l’ensemble des classes Java EE (Servlets et JSP). Ces attributs sont des paires clé/valeur, la clé
étant une chaîne de caractères et la valeur étant un objet de n’importe quel type.
Les attributs d’une application Web sont donc des variables globales appelées également variables d’application des
éléments participants à son fonctionnement et qui peuvent être partagées simultanément par plusieurs Servlets et
pages JSP.
La méthode setAttribute(nom, objet) est utilisée pour positionner un attribut qui sera visible dans toute l’application
(portée application). Si le nom de l’attribut existe déjà, la valeur existante est remplacée par la nouvelle.
La méthode getAttribute(nom) est utilisée pour récupérer la valeur d’un attribut de type quelconque dans l’application
ou la valeur null si l’attribut n’existe pas.
La méthode getAttributesNames() permet de récupérer le nom de tous les attributs actuellement stockés dans le
contexte de l’application Web.
Enfin, la méthode removeAttribute(nom) permet la suppression de l’attribut indiqué dans le contexte de l’application.
5. Mise en application
Afin de mettre en application l’interface ServletContext, nous allons créer une classe JavaBean Client afin de gérer un
objet client suite à une authentification correcte. L’objet client sera alors enregistré dans le contexte de l’application et
lu par une seconde Servlet (ServletLectureAuthentification).
Pour cela nous allons créer un nouveau paquetage appelé betaboutique.javabean.
Ce paquetage permet de stocker toutes les classes POJO (Plain Old Java Object, utilisé pour faire référence à des
classes simples composées d’accesseurs).
L’acronyme POJO est utilisé pour faire référence à la simplicité d’utilisation d’un objet Java en comparaison
avec la lourdeur d’utilisation d’un composant EJB (Entreprise Java Bean). Les JavaBeans (à ne pas confondre
avec les EJB) sont des composants logiciels simples réutilisables et manipulables. Pour être une classe JavaBean,
celleci devra respecter certaines conventions pour son utilisation, sa réutilisation et sa connexion JavaBean : la
classe doit être sérialisable (pour les sauvegardes et lectures), la classe doit avoir un constructeur par défaut (sans
argument), les propriétés des méthodes doivent être accessibles via des méthodes (accesseurs). La seule
différence réelle entre un POJO et un JavaBean est la possibilité de gérer des événements pour les JavaBeans.
package betaboutique.javabean;
public class Client implements java.io.Serializable {
private String identifiant=null;
private String motdepasse=null;
//Constructeur par défaut (sans paramètre)
public Client() {
}
public String getIdentifiant() {
return identifiant;
}
public void setIdentifiant(String identifiant) {
this.identifiant = identifiant;
}
public String getMotdepasse() {
return motdepasse;
}
© ENI Editions - All rigths reserved
- 3-
public void setMotdepasse(String motdepasse) {
this.motdepasse = motdepasse;
}
}
Le nouveau code de la Servlet permet de sauvegarder l’objet client correctement authentifié dans le contexte de
l’application.
package betaboutique.servlets.client;
import
import
import
import
import
import
import
import
import
java.io.IOException;
java.io.PrintWriter;
javax.servlet.ServletConfig;
javax.servlet.ServletContext;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
betaboutique.javabean.Client;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
String emailadministrateur=null;
public void init()
{
//récupérer les paramètres d’initialisation
de la Servlet dans le fichier web.xml
ServletConfig config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
//récupérer l’email de l’administrateur
ServletContext servletContext=getServletContext();
emailadministrateur=servletContext.getInitParameter
("emailAdministrateur");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
out.println("Authentification correcte,
bienvenue : "+identifiant);
//créer l’objet JavaBean Client
Client client1=new Client();
client1.setIdentifiant(identifiant);
client1.setMotdepasse(motdepasse);
//sauvegarder l’objet client dans le contexte de l’application
ServletContext servletContext=getServletContext();
servletContext.setAttribute("client1", client1);
}
...
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
- 4-
© ENI Editions - All rigths reserved
Après
avoir
appelé
la
Servlet
ServletAuthentification
http://localhost:8080/betaboutique/authentificationclient, nous pouvons
respectant le code et la configuration du fichier web.xml.
par
le
déclencher la
biais
Servlet
de
l’URL
cidessous en
Nous remarquons alors que notre objet client1 stocké dans la variable globale est accessible pour toute l’application.
Lors du redémarrage (ou de l’arrêt) du serveur, le contexte sera détruit ainsi que les objets présents dans ce
contexte.
emailAdministrateur
admin@betaboutique.fr
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
defautMotDePasse
monmotdepasse
servletlectureauthentification
betaboutique.servlets.client.ServletLecture
Authentification
servletauthentification
/authentificationclient
servletlectureauthentification
/lectureauthentificationclient
package betaboutique.servlets.client;
import
import
import
import
import
import
import
import
java.io.IOException;
java.io.PrintWriter;
javax.servlet.ServletContext;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
betaboutique.javabean.Client;
public class ServletLectureAuthentification extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//flux de sortie
PrintWriter out=response.getWriter();
//lecture de l’objet dans le contexte de l’application
ServletContext servletContext=getServletContext();
Client client1=(Client)servletContext.getAttribute("client1");
if(client1!=null)
{
© ENI Editions - All rigths reserved
- 5-
out.println("Le client dans le contexte est : ");
out.println("identifiant : "+client1.getIdentifiant());
out.println("mot de passe : "+client1.getMotdepasse());
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
- 6-
© ENI Editions - All rigths reserved
Traitement des requêtes
1. Présentation
Les
méthodes
doGet(...)
et
doPost(...)
possèdent
en
premier
paramètre
un
objet
de
type
javax.servlet.http.HttpServletRequest. Cet objet est créé par le conteneur Web juste avant le déclenchement d’une
des méthodes et correspond à la requête du client. Il existe de nombreuses méthodes dédiées au traitement des
requêtes utilisateurs comme la récupération de paramètres, la gestion des flux...
a. Récupérer des paramètres transmis par le client
Les paramètres permettent à la Servlet de réaliser les traitements adaptés. La méthode getParameter(nom) permet
de récupérer sous la forme d’une chaîne de caractères la valeur d’un paramètre nommé passé en argument. Si le
paramètre n’existe pas, la valeur null est retournée.
...
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer l’identifiant/login dans la requête
String identifiant=request.getParameter("identifiant");
...
La méthode getParameterNames() permet de récupérer sous la forme d’une énumération l’ensemble des noms des
paramètres contenus dans la requête.
...
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
Enumeration enume=request.getParameterNames();
while(enume.hasMoreElements())
{
String nomParametre=(String)enume.nextElement();
String valeurParametre=request.getParameter(nomParametre);
out.println("parametre : nom="+nomParametre+" - valeur :
"+valeurParametre);
}
...
La méthode getParameterValues(nom) permet de récupérer sous la forme d’un tableau de chaînes de caractères un
ensemble de valeurs ou la valeur null si le paramètre n’existe pas. Cette méthode est utilisée pour les listes
multiples ou les cases à cocher . La méthode getParameterMap() permet de récupérer sous la
forme d’un objet de type Map l’ensemble des paramètres contenus dans la requête.
b. Gérer les attributs du contexte de la requête
L’objet request permet de créer un attribut dans la requête. Si l’attribut existe déjà, la valeur existante est
remplacée par la nouvelle. Cette technique est très utilisée pour envoyer des paramètres à une page dynamique
pour par exemple l’affichage des erreurs, des messages de succès, du numéro d’enregistrement dans la base de
données... La méthode setAttribute(nom,objet) permet de créer un attribut dans le contexte de la requête. La
méthode getAttribute(nom) permet de récupérer la valeur d’un attribut dans le contexte de la requête. La méthode
getAttributeNames() permet de récupérer le nom de tous les attributs actuellement stockés dans le contexte de la
requête sous la forme d’une énumération. La méthode removeAttribute(nom) permet de supprimer un attribut du
contexte de la requête.
c. Récupérer des informations sur l’URL de la requête
Il existe plusieurs méthodes qui permettent d’obtenir des informations sur l’URL de la requête HTTP comme : le
protocole utilisé, les paramètres passés, le chemin vers la Servlet...
La méthode getScheme() permet de retourner le nom du protocole utilisé HTTP, HTTPS ou FTP .
Ex : http://localhost:8080/betaboutique/authentificationclient dans ce cas retourne : http
© ENI Editions - All rigths reserved
- 1-
La méthode getContextePath() permet de retourner sous la forme d’une chaîne de caractères la partie de l’URL qui
correspond au nom du contexte de l’application.
Ex : http://localhost:8080/betaboutique/authentificationclient dans ce cas retourne : /betaboutique.
La méthode getMethod() retourne le nom de la méthode HTTP utilisée (GET, POST, DELETE...).
Ex : http://localhost:8080/betaboutique/authentificationclient dans ce cas retourne : GET avec un lien.
La méthode getQueryString() retourne la chaîne de requête contenue dans l’URL après le chemin de la ressource
invoquée ou la valeur null s’il n’en existe pas.
Ex : http://localhost:8080/betaboutique/authentificationclient?param1= 1¶m2= 2
param1=1¶m2=2
dans
ce
cas
retourne :
La méthode getRequestUrl() retourne la partie de l’URL contenue entre le nom du protocole (http dans ce cas) et la
chaîne de requête.
Ex : http://localhost:8080/betaboutique/authentificationclient?param1= 1¶m2= 2
http://localhost:8080/betaboutique/authentificationclient.
dans
ce
cas
retourne :
d. Récupérer des informations sur le client
Il existe également plusieurs méthodes pour obtenir des informations sur le client qui a émis la requête HTTP. La
méthode getRemoteAddr() permet d’obtenir l’adresse IP du client. La méthode getRemoteHost() permet d’obtenir le
nom complet du client. La méthode getRemoteUser() retourne le nom de l’utilisateur qui a envoyé la requête.
e. Récupérer des informations sur le serveur
Les deux méthodes suivantes sont très utilisées pour renseigner des URL ’’en dur’’ ; dans le cas de redirection,
d’invocation de méthodes avec chemin complet... Ces deux méthodes permettent de construire la base de l’URL
d’invocation des ressources.
La méthode getServerName() retourne le nom d’hôte du serveur.
Ex : http://localhost:8080/betaboutique/authentificationclient?param1= 1¶m2= 2
localhost.
dans
ce
cas
retourne :
La méthode getServerPort() retourne le numéro du port d’écoute du serveur.
Ex : http://localhost:8080/betaboutique/authentificationclient?param1=1¶m2=2 dans ce cas retourne : 8080
- 2-
© ENI Editions - All rigths reserved
Traitement des réponses
Le
deuxième
paramètre
des
méthodes
doGet(...)
et
doPost(...)
est
un
objet
de
type
javax.servlet.http.HttpServletResponse. Cet objet est créé par le conteneur Web avant l’invocation de ces méthodes et
correspond à la réponse qui sera retournée au client.
Type et taille du contenu de la réponse
Il est possible d’indiquer le type MIME de la réponse HTTP ainsi que la taille des données contenues dans le corps de la
réponse. La méthode setContentType(type) permet de spécifier le contenu du corps de la réponse (text/html, text/plain,
text/xml, application/pdf...). La méthode setContentLength(taille) permet de spécifier la taille du contenu de la réponse
HTTP.
Gérer le flux de sortie
L’interface javax.servlet.ServletResponse définit deux méthodes et objets qui permettent d’écrire dans le contenu de la
réponse HTTP. La méthode getOutputStream() permet d’écrire des données au format binaire dans le corps de la
réponse. Il est conseillé de valider l’envoi de la réponse avec la méthode flush(). La méthode getWriter() permet d’écrire
des données au format texte dans le corps de la réponse. Comme pour la méthode getOutputStream(), il est conseillé
d’utiliser la méthode flush() pour valider l’envoi de la réponse.
Encoder les URL
Il est parfois nécessaire d’encoder les URL afin d’inclure l’identifiant de session pour la navigation par état (session),
pour conserver des accents sur les paramètres, pour l’encodage de la langue dans les paramètres... La méthode
encodeURL(url) permet d’encoder l’URL passée en paramètre en incluant l’identifiant de session. La méthode
encodeRedirectURL(url) permet d’encoder l’URL passée en paramètre en incluant l’identifiant de session mais avec
l’utilisation de la méthode sendRedirect(...).
Redirection d’URL et états HTTP
La technique suivante est très utilisée en développement et permet d’envoyer au navigateur du client un ordre de
redirection sur une autre ressource de l’application (ou non). L’URL de la ressource est passée en paramètre et peut
être relative ou absolue. Nous allons utiliser cette méthode dans notre Servlet d’authentification afin de rediriger
l’utilisateur sur la page HTML suivante en cas de succès.
Authentification
Utilisateur correctement authentifié
package betaboutique.servlets.client;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
String emailadministrateur=null;
public void init()
{
//récupérer les paramètres d’initialisation
de la Servlet dans le fichier web.xml
© ENI Editions - All rigths reserved
- 1-
ServletConfig config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
//récupérer l’email de l’administrateur
ServletContext servletContext=getServletContext();
emailadministrateur=servletContext.getInitParameter
("emailAdministrateur");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer l’identifiant/login dans la requête
String identifiant=request.getParameter("identifiant");
//récupérer le mot de passe dans la requête
String motdepasse=request.getParameter("motdepasse");
//flux de sortie
PrintWriter out=response.getWriter();
//pas d’identifiant
if(identifiant==null)
{
out.println("Authentification incorrecte !");
}
//pas de mot de passe
if(motdepasse==null)
{
out.println("Authentification incorrecte !");
}
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
//redirection vers la page de succès
response.sendRedirect("authentificationcorrecte.html");
}
else
{
out.println("Authentification incorrecte, mauvaise
saisie des informations !");
out.println("Veuillez contacter : "+emailadministrateur);
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
La méthode sendStatus(statut) permet d’appliquer un code d’état à la réponse HTTP quand il n’y a pas d’erreur comme
par exemple OK(200), CONTINUE(100)...
La méthode sendError(...) permet d’envoyer un code d’erreur HTTP au client comme par exemple NOT FOUND(404),
SERVICE UNVAILABLE(503)...
- 2-
© ENI Editions - All rigths reserved
Synchronisation des traitements
Une Servlet fonctionne dans un environnement multitâches. À chaque requête reçue par une Servlet, le conteneur Web
va créer un thread qui va exécuter la méthode de service (doGet(...) ou doPost(...)).
Ce principe de fonctionnement peut parfois poser des problèmes si la méthode de service travaille avec des variables
de la Servlet. Chaque thread peut modifier la valeur de ces variables. L’interface javax.servlet.SingleThreadModel permet
d’isoler le fonctionnement de chaque thread. Le conteneur Web prend en charge le fait qu’une instance de la Servlet
ne peut être exécutée que par un seul thread à la fois.
Ex : déclaration d’une Servlet qui implémente l’interface SingleThreadModel
import javax.servlet.SingleThreadModel;
public class ServletAuthentification extends HttpServlet
implements SingleThreadModel{...}
Même si cette solution est fréquemment recommandée, c’est un mauvais conseil. D’ailleurs, avec le compilateur JDK6.0,
la méthode est ’’barrée’’ et donc notée comme dépréciée. L’interface SingleThreadModel ne fait que signaler au
conteneur qu’un seul thread doit être autorisé pour la Servlet à un instant donné. Ceci ne garantit pas que la Servlet
soit protégée contre les accès concurrents. Des variables statiques par exemple sont partagées par toutes les
instances d’une classe. Une raison supplémentaire de ne pas utiliser l’interface SingleThreadModel est que cette option
ne tient pas la charge. Le nombre de Servlets que peut créer le conteneur est limité. Il est bien moins coûteux de créer
un nouveau thread qu’un nouvel objet pour la Servlet.
L’utilisation de la synchronisation peut convenir pour des exemples simples mais dans une application réelle, cette
solution est inefficace. Le temps de réponse augmente alors proportionnellement avec le nombre de requêtes.
La synchronisation des méthodes doGet(...) et doPost(...) est également une mauvaise idée. La méthode service()
appelle systématiquement une de ces deux méthodes, le résultat est donc le même que dans le cas de la
synchronisation de la méthode service().
Pour résumer, il est parfois nécessaire de synchroniser des portions de code (comme lors d’utilisation de threads dans
des IHM) pour gérer les accès concurrents. Il faut cependant veiller à ce que la synchronisation concerne le plus petit
bloc possible (méthode synchronized(object)). La réduction du nombre d’instructions synchronisées augmente la vitesse
d’exécution du code.
Il reste cependant un point délicat, l’accès concurrentiel aux données. Soit par exemple deux clients souhaitant
s’enregistrer par l’intermédiaire d’un formulaire HTML. Ils envoient leurs données en même temps à destination d’une
Servlet dont le rôle est le traitement des données et l’enregistrement dans la table des clients. Que se passetil si
deux instances de la Servlet effectuent le même traitement en même temps ?
Dans le cas d’une clé sans autoincrément, il y aura une erreur de doublon de l’id d’enregistrement. Un seul des deux
clients sera donc enregistré dans la base de données des clients.
Ce problème sera géré par la suite par un mode transactionnel d’accès aux données (propre au système de stockage)
qui est plus puissant que la synchronisation de Servlet.
© ENI Editions - All rigths reserved
- 1-
État des clients
Le protocole HTTP est sans état. La technologie utilise un mode déconnecté (connexion pour la requête en cours puis
déconnexion). Chaque requête est considérée comme provenant d’un client différent à chaque fois.
Il est important dans une application Web de pouvoir suivre la navigation du client sur le site et de garder certaines
informations qui permettent de l’identifier de manière unique et fiable.
Pour notre projet betaboutique, nous devons pouvoir garder les articles du client déposés dans son panier afin de
retrouver son contenu à tout moment. Sans gestion de cookie et/ou session , tout client qui envoie une requête est
considéré comme un nouveau client.
1. Les cookies
Un cookie est un élément de données qui peut être envoyé par le serveur à destination du navigateur client. Le
cookie est stocké soit en mémoire (expiration rapide) soit sur le système de fichiers du client (expiration longue).
L’avantage réside dans le fait qu’à chaque connexion du client, le navigateur transmet également le cookie (ou les
cookies) que notre serveur a précédemment déposé(s). Il existe cependant un inconvénient majeur. L’utilisateur peut
configurer son navigateur pour refuser les cookies ou les supprimer directement manuellement. Un cookie est
composé d’une paire nom/valeur et de plusieurs propriétés pour renseigner le domaine, la durée de vie, la sécurité...
L’API Servlet fournit la classe javax.servlet.http.Cookie qui permet de manipuler les cookies en Java. Le constructeur
Cookie(nom,valeur) permet de créer un cookie. La méthode getName() permet de récupérer le nom d’un cookie.
La méthode getValue() permet de récupérer la valeur du cookie alors que la méthode setValue(valeur) permet de
spécifier une valeur à un cookie.
Les méthodes getDomaine() et setDomaine(valeur) permettent de gérer le domaine lié au cookie.
Les méthodes getPath() et setPath(valeur) permettent de gérer le contexte de l’application Web.
Les méthodes getMaxAge() et setMaxAge(valeur) permettent de gérer la durée de vie d’un cookie.
Les méthodes getSecure() et setSecure(valeur) permettent de gérer la sécurité d’un cookie (http ou https).
Les méthodes getComment() et setComment(valeur) permettent de gérer les commentaires associés à un cookie.
Les méthodes getVersion() et setVersion(valeur) permettent de gérer les versions des cookies.
a. Envoyer des cookies dans la réponse
Nous allons modifier notre Servlet d’authentification afin d’envoyer un cookie en cas de succès d’authentification.
...
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
//envoyer un cookie au client
Cookie cookie1=new Cookie("cookie1","authentification correcte !");
response.addCookie(cookie1);
//redirection vers la page de succès
response.sendRedirect("authentificationcorrecte.html");
}
...
b. Récupérer des cookies dans la requête
Nous allons créer une nouvelle Servlet appelée ServletLectureCookies qui permet de lire les cookies. L’interface
javax.servlet.http.HttpServletRequest définit une méthode qui permet de récupérer sous la forme d’un tableau la liste
des cookies pour un domaine. Cette méthode retourne null si aucun cookie n’a été envoyé. Nous pouvons donc
tester la Servlet et la gestion des cookies en réalisant une authentification correcte et en appelant ensuite la page :
http://localhost:8080/betaboutique/lecturecookies.
package betaboutique.servlets.client;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServlet;
© ENI Editions - All rigths reserved
- 1-
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletLectureCookies extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//lire les cookies du domaine
Cookie[] cookies=request.getCookies();
if(cookies!=null)
{
for(int i=0;i
60
...
Attention, pour rappel, il est important de bien respecter l’ordre des balises dans le fichier web.xml. Les
balises relatives aux sessions sont placées après les tags .
a. Obtenir une session
L’interface javax.servlet.http.HttpServletRequest définit deux méthodes qui permettent d’obtenir une session HTTP.
La méthode getSession() retourne la session courante et la méthode getSession(param) retourne une nouvelle
session si la requête ne contient pas déjà de session.
b. Travailler avec une session
L’interface javax.servlet.http.HttpSession définit plusieurs méthodes pour manipuler les sessions. La méthode
setAttribute(nom,objet) permet de stocker un attribut dans le contexte de la session HTTP. Si le nom de l’attribut
existe déjà, la valeur existante est remplacée par la nouvelle.
La méthode getAttribute(nom) permet de récupérer dans le contexte de la session la valeur d’un attribut ou null si
l’attribut n’existe pas. La méthode removeAttribute(nom) permet de supprimer un attribut dans le contexte de la
session. La méthode isNew() permet de savoir si la session est nouvelle ou non. Une session est nouvelle tant qu’il
n’y a pas eu d’accès. La méthode invalidate() permet de détruire immédiatement la session courante et l’ensemble
de ses attributs. La méthode getId() permet de retourner l’identifiant de la session HTTP.
Nous allons modifier notre Servlet d’authentification pour ajouter dans la session les informations de l’utilisateur et
créer une nouvelle Servlet (ServletLectureSession) pour lire le contenu des informations de la session.
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
//session
© ENI Editions - All rigths reserved
- 3-
HttpSession session=request.getSession();
//si pas de session, destruction et création d’une nouvelle
if(!session.isNew())
{
session.invalidate();
session=request.getSession();
}
//stocker les paramètres de l’utilisateur dans la session
session.setAttribute("identifiant", identifiant);
session.setAttribute("motdepasse", motdepasse);
//redirection vers la page de succès
response.sendRedirect("authentificationcorrecte.html");
}
...
...
servletlecturesession
betaboutique.servlets.client.Servlet
LectureSession
servletlecturesession
/lecturesession
...
Nous pouvons désormais déclencher l’URL suivante après une authentification correcte afin de lire les données
enregistrées dans la session. http://localhost:8080/betaboutique/lecturesession.
package betaboutique.servlets.client;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
public class ServletLectureSession extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//lire les informations de la session
HttpSession session=request.getSession();
if(session==null)
{
System.out.println("Pas de session");
}
else
{
System.out.println("Identifiant :
"+session.getAttribute("identifiant"));
System.out.println("Mot de passe :
"+session.getAttribute("motdepasse"));
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
- 4-
© ENI Editions - All rigths reserved
c. Sessions et réécriture d’URL
Par défaut le mécanisme de sessions utilisateurs utilise un cookie pour identifier l’utilisateur courant. Lorsqu’une
session est créée sur le serveur, celuici envoie dans la réponse HTTP un cookie avec l’ID du fichier (de la session)
créé sur le serveur. Ensuite, à chaque requête envoyée par le client, le cookie est inclus, permettant au serveur de
lier la session à un utilisateur précis.
Si l’utilisateur interdit les cookies, la session ne fonctionnera pas car le serveur ne pourra pas récupérer l’ID de la
session courante. Il faut donc utiliser une alternative au cookie : la réécriture d’URL.
La technique de réécriture d’URL n’est pas toujours utilisée. Ce procédé est lourd à gérer et impose du
travail supplémentaire aux développeurs. Dans la majorité des projets, seule la gestion de session par
cookie est utilisée.
Le principe de réécriture consiste à ajouter un paramètre dont la valeur correspond à l’ID de session HTTP du client
sur chaque URL (les formulaires HTML, les liens hypertextes, les redirections). Pour cela il est nécessaire d’utiliser les
fonctions d’encodage des URL. L’interface javax.servlet.http.HttpServlet.Response définit deux méthodes qui
permettent d’encoder des URL afin que le serveur puisse les écrire correctement. La méthode encodeURL(url) permet
d’encoder l’URL passée en paramètre en incluant l’identifiant de session si cela est nécessaire. Cette méthode
permet d’ajouter l’identifiant de session au cas où le navigateur ne supporte pas ou n’autorise pas les cookies. La
méthode encodeRedirectURL(url) est identique et permet la mise en forme lors de redirections avec la méthode
sendRedirect(...).
Nous allons modifier notre Servlet d’authentification afin de réaliser un affichage HTML avec un lien vers la Servlet de
lecture en conservant l’ID de session dans l’URL.
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
//session
HttpSession session=request.getSession();
//si pas de session, destruction et création d’une nouvelle
if(!session.isNew())
{
session.invalidate();
session=request.getSession();
}
//stocker les paramètres de l’utilisateur dans la session
session.setAttribute("identifiant", identifiant);
session.setAttribute("motdepasse", motdepasse);
//lien HTML avec ID session
response.setContentType("text/html");
out.println("");
}
...
Le serveur d’application détecte automatiquement si le navigateur accepte ou non les cookies. Si le navigateur
autorise les cookies, le lien ne sera pas encodé. Par contre, si les cookies sont désactivés (avec la barre de
développement
Firefox
par
exemple),
le
lien
est
encodé
avec
l’ID
de
la
session.
http://localhost:8080/betaboutique/lecturesession;jsessionid=0C7DD398A9367555D0D4A15F32B5
© ENI Editions - All rigths reserved
- 5-
Les filtres
1. Présentation
Les filtres permettent de donner à une application une structure modulaire. Ils permettent d’encapsuler différentes
tâches qui peuvent être indispensables pour traiter des requêtes. La principale fonction d’une Servlet est de recevoir
les requêtes et de répondre aux clients concernés. Par contre, il est très souvent nécessaire de réaliser une fonction
identique pour chaque Servlet en rapport avec les requêtes et réponses HTTP.
Par exemple, nous voulons stocker dans une base de données pour des statistiques chaque accès à des Servlets du
serveur ou router (transporter) un paramètre dans toutes les requêtes sans être obligé d’écrire le code pour chaque
Servlet. L’interface Filter apparue avec l’API Servlet 2.3 permet de résoudre ce type de problème.
Les filtres permettent ainsi de traiter :
●
Les requêtes qui viennent des clients avant qu’elles ne soient traitées par les Servlets.
●
Les réponses venant des Servlets avant qu’elles ne soient envoyées aux clients.
Il est possible par exemple de :
●
décrypter des requêtes envoyées aux Servlets, traiter les données avec les Servlets et crypter les réponses
pour les clients ;
●
gérer l’authentification des clients ;
●
convertir des formats d’images, appliquer des transformations XSLT sur des données XML...
2. Utilisation
Pour utiliser un filtre il est nécessaire de réaliser deux opérations. La première consiste à écrire une classe qui
implémente l’interface Filter. La seconde consiste à modifier le descripteur de déploiement (fichier web.xml) de
l’application pour indiquer au conteneur d’utiliser le filtre.
Nous allons utiliser un filtre pour tracer nos actions au sein de notre application betaboutique.
Lorsqu’un filtre est créé, le conteneur appelle sa méthode init(...). Dans cette méthode, nous pouvons accéder aux
paramètres d’initialisation avec l’interface FilterConfig. Lors du traitement de la requête, le conteneur appelle la
méthode doFilter(...). Avant de détruire le filtre, le conteneur appelle sa méthode destroy(...).
Lorsque le filtre appelle chain.doFilter(), le filtre suivant dans la chaîne est exécuté. Le code placé avant chain.doFilter()
est exécuté avant le traitement de la Servlet. Toute modification que le filtre doit apporter avant l’exécution de la
requête doit être effectuée avant cet appel. Le code placé après cet appel est exécuté après le traitement de la
Servlet. Il est tout à fait possible de chaîner les filtres et d’utiliser un filtre par traitement spécifique.
Le schéma suivant présente le fonctionnement d’un filtre avant et après traitement par la Servlet invoquée.
© ENI Editions - All rigths reserved
- 1-
a. La déclaration du filtre
Le descripteur de déploiement est utilisé pour indiquer le (ou les) filtre(s) qu’il doit appeler pour chaque Servlet ou
URL de l’application. Le premier élément permet de déclarer la classe associée au filtre. Cet élément doit être
placé en début de fichier de configuration après la déclaration des variables globales au contexte ().
Dans notre cas, nous définissons un filtre qui sera associé à la classe FiltreJournalisation permettant de gérer les
accès aux pages du site.
...
filtrejournalisation
betaboutique.boiteoutils.FiltreJournalisation
...
Le second élément nécessaire est . Il permet comme pour les Servlets de gérer le mapping
(relations) entre un nom et une Servlet ou une URL. Par exemple, ici le filtre est appliqué uniquement à la Servlet
servletauthentification.
...
filtrejournalisation
betaboutique.boiteoutils.FiltreJournalisation
filtrejournalisation
servletauthentification
...
Pour ce second exemple, le filtre est appliqué pour l’accès à toutes les URL de l’application.
...
filtrejournalisation
betaboutique.boiteoutils.FiltreJournalisation
filtrejournalisation
/*
...
Le code suivant correspond au filtre betaboutique.boiteoutils.FiltreJournalisation et permet d’afficher les informations
de journalisation avant et après exécution des pages. Nous pouvons tester le fonctionnement avec l’accès à
n’importe quelle URL de l’application étant donné que le paramètre est positionné pour tout écouter
(/*).
- 2-
© ENI Editions - All rigths reserved
package betaboutique.boiteoutils;
import
import
import
import
import
import
javax.servlet.Filter;
javax.servlet.FilterChain;
javax.servlet.FilterConfig;
javax.servlet.ServletContext;
javax.servlet.ServletRequest;
javax.servlet.ServletResponse;
public class FiltreJournalisation implements Filter{
private FilterConfig filterConfig=null;
// action d’initialisation du filtre
public void init(FilterConfig filterConfig)
{
this.filterConfig=filterConfig;
System.out.println("Initialisation du filtre :
"+this.filterConfig.getFilterName());
}
//action déclenchée lors du traitement d’une requete
public void doFilter(ServletRequest request,
ServletResponse response, FilterChain chain)
{
//traitement de la requête avant la Servlet
System.out.println("----------- REQUETE -----------");
System.out.println("Encodage : "+request.getCharacterEncoding());
System.out.println("Type de contenu : "+request.getContentType());
System.out.println("Taille du contenu : "+request.getContentLength());
System.out.println("Nom machine distante : "+request.getRemoteHost());
System.out.println("Adresse IP machine distante :
"+request.getRemoteAddr());
try
{
//déclencher la servlet appropriée
chain.doFilter(request, response);
}
catch(Exception e)
{
//erreur dans le filtre
System.out.println("Erreur dans le filtre FiltreJournalisation");
}
//traitement de la requête avant la Servlet
System.out.println("----------- REPONSE -----------");
System.out.println("Encodage : "+response.getCharacterEncoding());
System.out.println("Type de contenu : "+response.getContentType());
//exemple d’écriture dans le fichier de log de l’application
ServletContext context=this.filterConfig.getServletContext();
context.log("Encodage de la réponse :
"+response.getCharacterEncoding());
}
//action qui permet de détruire le filtre
public void destroy()
{
System.out.println("Destruction du filtre :
"+this.filterConfig.getFilterName());
}
//fin de la classe
}
© ENI Editions - All rigths reserved
- 3-
- 4-
© ENI Editions - All rigths reserved
Interface RequestDispatcher
1. Présentation
La plupart du temps, la programmation de Servlets consiste à récupérer des données en paramètre, à traiter ces
données et à renvoyer une réponse adaptée au client.
Nous avons utilisé précédemment la méthode sendRedirect(...) de l’objet response qui permet de rediriger l’utilisateur
vers une page précise. Par contre, cette redirection ne permet pas d’envoyer des données directement dans le corps
du message (sauf en passant des paramètres à l’URL. Ex : response.sendRedirect(’’mapage.jsp?param=1’’)).
Un objet de type javax.servlet.RequestDispatcher est créé par le conteneur Web pour chaque application et agit
comme un routeur de requêtes et réponses HTTP. Un objet de type javax.servlet.RequestDispatcher est donc utilisé
pour :
●
effectuer un traitement continu vers une autre ressource Web ;
●
inclure le contenu d’une autre ressource Web dans la réponse HTTP.
Cette interface est la base de l’architecture MVC (Modèle, Vue, Contrôleur) que nous verrons plus tard. La syntaxe de
la méthode getRequestDispatcher(chemin) doit commencer par un signe / qui permet de faire référence au contexte de
l’application Web courante. Ce chemin est complété ensuite vers la ressource statique (HTML, XML, PDF...) ou
dynamique (page JSP, une autre Servlet...). Une fois l’objet javax.servlet.RequestDispatcher obtenu, il est possible
d’invoquer la méthode qui permet de déléguer le traitement de la requête HTTP à la ressource ou la méthode
permettant d’inclure du contenu dans la réponse HTTP.
a. Déléguer et transmettre
La délégation consiste à transmettre la requête HTTP courante à une autre ressource Web qui sera chargée de son
traitement et qui peut également transmettre la requête à une autre ressource. Pour cela, la méthode forward(...)
permet de transmettre le contenu complet de la requête (donc avec les paramètres) vers une autre page.
b. Inclure des données
L’inclusion consiste à incorporer le contenu d’une autre ressource Web dans la réponse HTTP qui sera envoyée au
client. Cette inclusion peut être utilisée pour l’entête ou le pied de page du site en HTML par exemple (ou en JSP s’il
y a du contenu dynamique). Pour cela, la méthode include(...) permet de réaliser cette opération.
2. Utilisation
Nous allons modifier notre application d’authentification pour le projet betaboutique. Dans un premier temps
l’utilisateur saisit son identifiant et son mot de passe dans une page HTML simple (authentification.html). Si
l’authentification est incorrecte ou s’il y a un problème de saisie, l’utilisateur est redirigé vers une page dynamique
d’erreur en JSP (le langage JSP sera présenté au chapitre suivant). Si l’authentification est correcte, l’utilisateur est
redirigé vers une page dynamique JSP lui indiquant la bienvenue sur la boutique.
a. Explications
L’application proposée est plus complexe que précédemment. La page HTML statique authentification.html permet
de déclencher la Servlet ServletAuthentification par le biais de l’URL authentificationclient.
Cette Servlet vérifie la syntaxe de l’identifiant et du mot de passe de façon plus précise avec la valeur null, le test
de présence et une expression régulière pour la syntaxe. En cas d’erreur, une collection est renseignée puis
retournée vers la page JSP dynamique qui affiche simplement le contenu de cette collection comprenant sous forme
de chaînes de caractères la liste des erreurs rencontrées.
Le déclenchement de la fonction forward(...) de l’objet javax.servlet.RequestDispatcher entraîne une redirection (un
return) et donc le code suivant cette instruction n’est pas exécuté.
En cas de succès de l’authentification, les attributs identifiant et motdepasse sont passés à la requête qui déclenche
le routage vers la page dynamique de bienvenue (bienvenue.jsp). Celleci va afficher les informations du client. La
Servlet dépose donc deux paramètres dans la requête à l’aide de la méthode setAttribute(...) et passe le contrôle à
© ENI Editions - All rigths reserved
- 1-
la page bienvenue.jsp. La page dynamique bienvenue.jsp récupère les attributs dont elle a besoin pour afficher
l’identifiant et le mot de passe de l’utilisateur correctement authentifié.
emailAdministrateur
admin@betaboutique.fr
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
defautMotDePasse
monmotdepasse
servletauthentification
/authentificationclient
package betaboutique.servlets.client;
import
import
import
import
import
import
import
java.io.IOException;
java.util.ArrayList;
javax.servlet.ServletConfig;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
public void init()
{
//récupérer les paramètres d’initialisation
de la Servlet dans le fichier web.xml
ServletConfig config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer l’identifiant/login dans la requête
String identifiant=request.getParameter("identifiant");
//récupérer le mot de passe dans la requête
String motdepasse=request.getParameter("motdepasse");
//déclaration d’une liste/collection d’erreurs
ArrayList erreursParametres=new ArrayList();
- 2-
© ENI Editions - All rigths reserved
//pas d’identifiant
if(identifiant==null)
{
erreursParametres.add("Le paramètre [identifiant] est null");
}
//identifiant vide
if(identifiant.equals(""))
{
erreursParametres.add("Le paramètre [identifiant] est vide");
}
//identifiant inférieur à 5 caractères
if(!identifiant.matches("^[0-9a-zA-Z]{5,}$"))
{
erreursParametres.add("Le paramètre [identifiant]
doit avoir au moins 5 caractères");
}
//pas de mot de passe
if(motdepasse==null)
{
erreursParametres.add("Le paramètre [mot de passe] est null");
}
//mot de passe vide
if(motdepasse.equals(""))
{
erreursParametres.add("Le paramètre [mot de passe] est vide");
}
//motdepasse inférieur à 5 caractères
if(!motdepasse.matches("^[0-9a-zA-Z]{5,}$"))
{
erreursParametres.add("Le paramètre [mot de passe]
doit avoir au moins 5 caractères");
}
//en cas d’erreur, redirection avec le RequestDispatcher
vers la page d’erreur dynamique
if(erreursParametres.size()>0)
{
request.setAttribute("erreurs",erreursParametres);
getServletContext().getRequestDispatcher
("/erreurs.jsp").forward(request, response);
}
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
//injecter dans la requête nos paramètres pour
qu’elle puisse les traiter
request.setAttribute("identifiant",identifiant);
request.setAttribute("motdepasse",motdepasse);
//authentification correcte, redirection
vers la page de bienvenue
getServletContext().getRequestDispatcher
("/bienvenue.jsp").forward(request, response);
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
ERREURS
<%
ArrayList erreurs=(ArrayList)request.getAttribute("erreurs");
%>
Les erreurs suivantes se sont produites
<%
for(int i=0;i"+(String)erreurs.get(i)+"");
}
%>
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
BIENVENUE
<%
String identifiant=(String)request.getAttribute("identifiant");
if(identifiant==null)
{
identifiant="inconnu";
}
String motdepasse=(String)request.getAttribute("motdepasse");
if(motdepasse==null)
{
motdepasse="inconnu";
}
%>
Bienvenue client : <%= identifiant %> <%= motdepasse %>
- 4-
© ENI Editions - All rigths reserved
Le fonctionnement est plus clair désormais. Une Servlet contient la logique applicative pour le traitement et délègue
à une ou plusieurs pages dynamiques (JSP, PHP...) la mise en forme des données (police, images, styles). Ceci est la
base de la programmation MVC (Modèle Vue Contrôleur) qui repose sur le Design Pattern ou modèle MVC.
© ENI Editions - All rigths reserved
- 5-
Introduction au modèle MVC
1. Présentation
Dans les exemples précédents du projet betaboutique, les requêtes HTTP sont gérées par des composants Web qui
reçoivent les requêtes, créent les réponses et les retournent aux clients. Il y a donc un seul composant responsable
de la logique d’affichage, de la logique métier et de la logique de persistance. Il existe une autre architecture appelée
MVC ou Modèle Vue Contrôleur qui permet de séparer clairement les trois activités des composants impliqués.
Dans l’architecture précédente, l’affichage et la manipulation des données sont mélangés dans un seul composant
Servlet. Cela peut largement convenir pour un service spécifique, non évolutif et simple, mais cela devient un problème
quand le système se développe. Cette architecture conduit à placer du code Java et du code HTML dans les Servlets
ou JSP.
Il existe plusieurs solutions à ce problème. La plus simple correspond à l’apparition des pages JSP et consiste à créer
des fichiers d’entête, de pied de page, de traitement... et d’inclure le tout dans une page générale.
L’architecture MVC sépare la logique métier de l’affichage. Dans ce modèle, un composant est chargé de recevoir les
requêtes (Servlets), un autre traite les données (Classes) et un troisième gère l’affichage (JSP). Si l’interfaçage entre
ces trois composants est clairement défini, il devient plus simple de modifier un composant sans toucher aux deux
autres.
●
Modèle : le modèle englobe la logique métier et les données sur lesquelles il opère. Toute classe Java qui
manipule les données peut jouer le rôle du modèle et de nombreuses applications Web utilisent uniquement
des Servlets ordinaires (ou des classes avec JDBC pour manipuler les bases de données).
●
Vue : dès que la requête courante est traitée, la logique de présentation est réalisée par une vue spécifique.
●
Contrôleur : le composant (ou les composants) contrôleur reçoi(ven)t les requêtes des clients, les traite(nt) et
les transmet(tent) aux composants chargés de traiter les données. Les Servlets sont les composants dont la
structure est la plus adaptée. Une Servlet est conçue pour recevoir les requêtes des clients et leur retourner
une réponse, ce qui est précisément le rôle du contrôleur.
Dans une application comme le projet betaboutique, la logique en MVC est la suivante :
Le client émet des requêtes au serveur. Chaque action précise correspond à une Servlet qui redirige les requêtes vers
une page JSP adéquate, ou réalise un traitement, ou accède à des données et dans ce cas, déclenche une autre
Servlet qui sera chargée de répondre à la demande de l’utilisateur courant.
Le schéma suivant présente une structure de type MVC avec l’utilisation de Servlets et pages JSP.
Pour le moment, nous n’utilisons pas de partie modèle car nous ne manipulons pas de données persistantes comme
des enregistrements d’une base de données ou des fichiers.
Notre modèle MVC sera donc limité aux parties : clients, Contrôleur/Action avec les Servlets et Affichage/Vue avec les
JSP.
Les Servlets qui jouent le rôle de contrôleur dans une application MVC doivent disposer d’un moyen pour transmettre
les requêtes aux composants chargés de l’affichage. Ce moyen est fourni par l’objet RequestDispatcher. Ce composant
permet de faire suivre une requête d’un composant vers un autre.
Un objet RequestDispatcher peut être obtenu avec la méthode getServletContext(). À partir de cet objet, il est possible
d’obtenir un RequestDispatcher à l’aide des méthodes suivantes : getNamedDispatcher(nom) ou getRequestDispatcher
(chemin).
La méthode getRequestDispatcher(...) fonctionne avec un chemin qui commence par la barre oblique et qui est relatif au
contexte de l’application. La méthode getNamedDispatcher(...) correspond et doit être identique à un sousélément
© ENI Editions - All rigths reserved
- 1-
d’un élément du descripteur de déploiement web.xml.
2. Utilisation
Nous allons modifier notre service d’authentification afin de respecter le standard MVC.
a. Les spécifications
Le client utilise une page statique ou dynamique pour s’authentifier (authentification.html). Cette page déclenche le
contrôleur qui est la Servlet : ServletAuthentification. Le contrôleur réalise un traitement simple (vérification de
l’authentification) et réalise le routage de la réponse vers la page bienvenue.jsp ou vers la page d’erreur erreurs.jsp
qui sont les vues.
Tout le routage (chemins) est paramétré dans le fichier de configuration de l’application afin de faciliter la
maintenance et l’évolutivité du projet.
...
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
defautMotDePasse
monmotdepasse
urlAuthentification
/authentification.html
urlErreurs
/erreurs.jsp
urlBienvenue
/bienvenue.jsp
...
Les routes ou chemins sont définis par des paramètres de la Servlet, cela permet de changer leurs noms sans avoir
à recompiler l’application.
package betaboutique.servlets.client;
import
import
import
import
import
import
import
java.io.IOException;
java.util.ArrayList;
javax.servlet.ServletConfig;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
//routes
String urlAuthentification=null;
String urlErreurs=null;
- 2-
© ENI Editions - All rigths reserved
String urlBienvenue=null;
public void init()
{
//récupérer les paramètres d’initialisation
de la Servlet dans le fichier web.xml
ServletConfig config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
//récupérer les routes
urlAuthentification=(String)config.getInitParameter
("urlAuthentification");
urlErreurs=(String)config.getInitParameter("urlErreurs");
urlBienvenue=(String)config.getInitParameter("urlBienvenue");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer l’identifiant/login dans la requête
String identifiant=request.getParameter("identifiant");
//récupérer le mot de passe dans la requête
String motdepasse=request.getParameter("motdepasse");
//déclaration d’une liste/collection d’erreurs
ArrayList erreursParametres=new ArrayList();
//pas d’identifiant, retour sur la page d’authentification
if(identifiant==null)
{
if(urlAuthentification==null)
{
throw new ServletException("Le paramètre
[urlAuthentification] n’a pas été initialisé");
}
else
{
getServletContext().getRequestDispatcher(urlAuthentification).forward
(request, response);
}
return;
}
//identifiant vide
if(identifiant.equals(""))
{
erreursParametres.add("Le paramètre [identifiant] est vide");
}
//identifiant inférieur à 5 caractères
if(!identifiant.matches("^[0-9a-zA-Z]{5,}$"))
{
erreursParametres.add("Le paramètre [identifiant]
doit avoir au moins 5 caractères");
}
//pas de mot de passe
if(motdepasse==null)
{
if(urlAuthentification==null)
{
throw new ServletException("Le paramètre
[urlAuthentification] n’a pas été initialisé");
}
else
{
getServletContext().getRequestDispatcher(urlAuthentification).forward
(request, response);
}
return;
© ENI Editions - All rigths reserved
- 3-
}
//mot de passe vide
if(motdepasse.equals(""))
{
erreursParametres.add("Le paramètre [mot de passe]
est vide");
}
//motdepasse inférieur à 5 caractères
if(!motdepasse.matches("^[0-9a-zA-Z]{5,}$"))
{
erreursParametres.add("Le paramètre [mot de passe]
doit avoir au moins 5 caractères");
}
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//injecter dans la requête nos paramètres
pour qu’elle puisse les traiter
request.setAttribute("identifiant",identifiant);
request.setAttribute("motdepasse",motdepasse);
//authentification correcte, redirection vers
la page de bienvenue
getServletContext().getRequestDispatcher(urlBienvenue).forward
(request, response);
}
}
//authentification incorrecte
else
{
erreursParametres.add("Les coordonnées de
l’utilisateur sont incorrectes");
}
//en cas d’erreur, redirection avec le
RequestDispatcher vers la page d’erreur dynamique
if(erreursParametres.size()>0)
{
if(urlErreurs==null)
{
throw new ServletException("Le paramètre
[urlErreurs] n’a pas été initialisé");
}
else
{
request.setAttribute("erreurs",erreursParametres);
getServletContext().getRequestDispatcher(urlErreurs).forward
(request, response);
}
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Désormais, nous pouvons appeler directement la page : http://localhost:8080/betaboutique/authentificationclient.
- 4-
© ENI Editions - All rigths reserved
Le mot de passe et l’identifiant ne sont pas présents dans la requête, le contrôleur va rediriger l’utilisateur vers la
page : urlAuthentification.
...
//pas d’identifiant, retour sur la page d’authentification
if(identifiant==null)
{
if(urlAuthentification==null)
{
throw new ServletException("Le paramètre
[urlAuthentification] n’a pas été initialisé");
}
else
{
getServletContext().getRequestDispatcher(urlAuthentification).forward
(request, response);
}
return;
}
...
Si l’utilisateur réalise une mauvaise authentification suite à une erreur de saisie ou de syntaxe ou des coordonnées
incorrectes, il est alors redirigé vers la page d’erreur (vue) adaptée.
...
//en cas d’erreur, redirection avec le RequestDispatcher vers
la page d’erreur dynamique
if(erreursParametres.size()>0)
{
if(urlErreurs==null)
{
throw new ServletException("Le paramètre
[urlErreurs] n’a pas été initialisé");
}
else
{
request.setAttribute("erreurs",erreursParametres);
getServletContext().getRequestDispatcher
(urlErreurs).forward(request, response);
}
}
...
Si l’utilisateur réalise une authentification correcte, il est redirigé vers la page de bienvenue.
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//injecter dans la requête nos paramètres
pour qu’elle puisse les traiter
request.setAttribute("identifiant",identifiant);
request.setAttribute("motdepasse",motdepasse);
//authentification correcte, redirection vers
la page de bienvenue
getServletContext().getRequestDispatcher(urlBienvenue).forward
(request, response);
}
}
© ENI Editions - All rigths reserved
- 5-
...
Nous pouvons essayer de tester notre application avec tous les cas, notamment avec une mauvaise page de
routage afin de déclencher volontairement l’exception.
Notre architecture est plus complexe mais respecte le modèle MVC. La logique de traitement (vérification de
l’authentification) est réalisée par une Servlet. Le contrôleur qui réalise le routage est également réalisé par une
Servlet et l’affichage des données est exclusivement réservé à des pages JSP (code HTML, CSS, JavaScript...).
Nous allons réaliser une dernière modification afin de mettre en œ uvre l’architecture MVC au complet avec la partie
Modèle. Le modèle permet de gérer la persistance des données, dans notre cas, la Servlet contrôleur
ServletAuthentification va déclencher une autre Servlet nommée ServletAuthentificationModele qui va sauvegarder le
client dans la session.
Dans un système évolué, le modèle utilise une base de données avec la technologie JDBC, des fichiers
sérialisés ou un framework de persistance comme Hibernate ou JPA.
emailAdministrateur
admin@betaboutique.fr
servletauthentification
betaboutique.servlets.client.Servlet
Authentification
defautIdentifiant
monidentifiant
defautMotDePasse
monmotdepasse
urlAuthentification
/authentification.html
urlErreurs
/erreurs.jsp
urlBienvenue
/bienvenue.jsp
urlAuthentificationModele
/authentificationclientmodele
- 6-
© ENI Editions - All rigths reserved
servletauthentificationmodele
betaboutique.servlets.client.Servlet
AuthentificationModele
bienvenuesession
/bienvenuesession.jsp
servletauthentification
/authentificationclient
servletauthentificationmodele
/authentificationclientmodele
package betaboutique.servlets.client;
import
import
import
import
import
import
import
java.io.IOException;
java.util.ArrayList;
javax.servlet.ServletConfig;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
public class ServletAuthentification extends HttpServlet {
//variables de classe
String ident=null;
String mdp=null;
//routes
String urlAuthentification=null;
String urlErreurs=null;
String urlBienvenue=null;
String urlAuthentificationModele=null;
public void init()
{
//récupérer les paramètres d’initialisation
de la Servlet dans le fichier web.xml
ServletConfig config=getServletConfig();
ident=(String)config.getInitParameter("defautIdentifiant");
mdp=(String)config.getInitParameter("defautMotDePasse");
//récupérer les routes
urlAuthentification=(String)config.getInitParameter
("urlAuthentification");
urlErreurs=(String)config.getInitParameter("urlErreurs");
urlBienvenue=(String)config.getInitParameter("urlBienvenue");
urlAuthentificationModele=(String)config.getInitParameter
("urlAuthentificationModele");
}
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
© ENI Editions - All rigths reserved
- 7-
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//déclencher la Servlet qui permet de gérer
la partie Modèle de l’application
request.setAttribute("identifiant",identifiant);
request.setAttribute("motdepasse",motdepasse);
getServletContext().getRequestDispatcher
(urlAuthentificationModele).forward(request, response);
}
}
...
//authentification incorrecte
}
package betaboutique.servlets.client;
import
import
import
import
import
import
java.io.IOException;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
javax.servlet.http.HttpSession;
public class ServletAuthentificationModele extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//écrire les informations dans la session
HttpSession session=request.getSession();
session.setAttribute("identifiant",
request.getAttribute("identifiant"));
session.setAttribute("motdepasse",
request.getAttribute("motdepasse"));
//redirection vers la page d’affichage du contenu
de la session (avec un appel par nom par exemple)
getServletContext().getNamedDispatcher("bienvenuesession").forward
(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
BIENVENUE SESSION
<%
String identifiant=(String)session.getAttribute("identifiant");
if(identifiant==null)
{
identifiant="inconnu";
}
- 8-
© ENI Editions - All rigths reserved
String motdepasse=(String)session.getAttribute("motdepasse");
if(motdepasse==null)
{
motdepasse="inconnu";
}
%>
Bienvenue client :
Par la suite, les classes de gestion du modèle seront regroupées dans un même paquetage appelé modele.
© ENI Editions - All rigths reserved
- 9-
Gestion des exceptions, erreurs et page d’accueil
1. Gestion des exceptions
La gestion des exceptions en Java est très évoluée et permet d’éviter des réponses erronées lors de calculs, de
traitements particuliers... Si par exemple dans une Servlet traitant les saisies d’un formulaire, l’utilisateur saisit une
chaîne de caractères à la place d’un entier, le constructeur de la classe Integer(...) lancera alors une exception.
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
String num=request.getParameter("nombre");
Integer i=new Integer(num);
}
Parfois l’utilisateur voit s’afficher en résultat la trace de l’exception dans le navigateur ou n’obtient aucune réponse.
Dans tous les cas, l’application est défectueuse. Dans une application professionnelle, il est nécessaire d’effectuer
des contrôles côté client et côté serveur. Parfois les contrôles côté client (en JavaScript) ne sont pas utilisés mais les
contrôles côté serveur sont obligatoires.
Pour traiter les erreurs de conversions, de calculs, d’accès à des variables ou fichiers, le bloc d’instructions try catch
est utilisé, il permet d’isoler une partie de code sensible.
Le problème est que si une instruction déclenche une exception, aucun message pour l’utilisateur n’est prévu. La
solution peut être de placer des instructions d’affichage dans le bloc catch pour retourner une réponse spécifique en
cas d’erreur.
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try
{
String num=request.getParameter("nombre");
Integer i=new Integer(num);
}
catch(Exception e)
{
System.out.println("Exception");
}
}
2. Gestions des pages d’erreurs
Avec Java EE il existe une façon plus robuste de définir les pages d’erreurs. Par exemple, pour le cas précédent, une
page Web indiquant un problème de format (Ex : Entrez uniquement des chiffres) pourrait être créée. Il est ensuite
possible de configurer l’application toujours par l’intermédiaire de son fichier de gestion web.xml. Pour cela, il suffit
d’utiliser l’élément avec l’exception associée.
Les exceptions sont placées après la gestion des sessions et des mappings de Servlets dans le fichier de
configuration web.xml.
...
java.lang.NumberFormatException
/erreurchiffre.html
...
Il peut être également très intéressant ’’d’attraper’’ toutes les erreurs sans en gérer à chaque fois le type. Chaque
exception levée (conversion, calculs...) déclenchera alors la même page.
...
© ENI Editions - All rigths reserved
- 1-
java.lang.Throwable
/erreurglobale.html
...
Nous pouvons vérifier cette utilisation avec notre application d’authentification en modifiant un des paramètres du
fichier web.xml pour déclencher l’exception suivante :
...
...
java.lang.Throwable
/erreurglobale.html
Erreur BetaBoutique
Erreur : une erreur est survenue, recommencez votre
opération !
...
//vérifier l’égalité des valeurs
if( (identifiant!=null && identifiant.equals(ident))
&& (motdepasse!=null && motdepasse.equals(mdp)) )
{
if(urlBienvenue==null)
{
throw new ServletException("Le paramètre
[urlBienvenue] n’a pas été initialisé");
}
else
{
//déclencher la Servlet qui permet de gérer la
partie Modèle de l’application
request.setAttribute("identifiant",identifiant);
request.setAttribute("motdepasse",motdepasse);
getServletContext().getRequestDispatcher
(urlAuthentificationModele).forward(request, response);
}
}
//authentification incorrecte
else
{
erreursParametres.add("Les coordonnées de
l’utilisateur sont incorrectes");
}
...
S’il y a une authentification correcte, la page de bienvenue est demandée mais mal orthographiée par erreur pour le
développement de l’application, l’exception ServletException est déclenchée et provoque l’affichage de la page
d’erreur générale. Pour l’utilisateur c’est totalement transparent. Par contre, l’exception est affichée dans la console
système.
De la même façon, il est possible de spécifier des pages à afficher pour les codes d’erreur HTTP, par exemple gérer les
erreurs 404 (page non trouvée et inexistante sur le serveur).
Pour cela, nous ajoutons le code suivant dans notre fichier de configuration web.xml, nous créons une page HTML
- 2-
© ENI Editions - All rigths reserved
d’erreur
404
(ex:
404.html)
et
nous
déclenchons
(ex : http://localhost:8080/betaboutique/unepage).
une
URL
inexistante
sur
notre
serveur
...
404
/404.html
...
Erreur BetaBoutique
Erreur : cette page n’est pas disponible !
Cette technique très puissante permet de gérer tous les codes d’erreur HTTP qui sont consultables à cette adresse :
http://www.w3.org/Protocols/rfc2616/rfc2616sec10.html. Dans une application en production, les erreurs 404 (page
non trouvée) et 500 (erreur interne du serveur) doivent systématiquement être traitées. Le but est de toujours
fournir au client une page lisible et correctement mise en forme.
3. Gestion de la page d’accueil
Lorsque nous visitons des sites au moyen d’un navigateur, nous précisons uniquement le nom de domaine pour
accéder à la page d’accueil. Dans notre cas si nous précisons l’URL suivante qui correspond au contexte, aucune page
n’est affichée (erreur 404) (http://localhost:8080/betaboutique/).
Il existe des balises particulières du fichier de configuration qui permettent de gérer le contexte de l’application quand
il n’y a pas d’indication de document particulier. Ces documents associés sont appelés des welcome files. En règle
générale, les serveurs Web sont positionnés avec les pages suivantes : index.html, index.php, index.jsp... Nous allons
modifier notre fichier de déploiement pour afficher le formulaire d’authentification lors de l’arrivée sur le site.
L’élément doit être placé entre la définition des sessions et les pages d’erreurs dans le fichier de
configuration de l’application web.xml.
...
authentification.html
...
Dans ce cas lors de l’accès à l’application : http://localhost:8080/betaboutique/, le serveur renvoie le premier
document trouvé parmi ceux de la liste indiquée dans l’élément .
© ENI Editions - All rigths reserved
- 3-
En résumé
Ce chapitre a présenté le mécanisme de Servlet Java EE. La première partie a présenté le fonctionnement du protocole
HTTP et l’utilisation des Servlets. La partie suivante a introduit le projet BetaBoutique développé tout au long de ce
guide et qui permet de mettre en application toutes les technologies évoquées. Le projet commence par une première
Servlet simple et la mise en place d’un service d’authentification pour les clients du site. Afin de comprendre le
fonctionnement des Servlets, les interfaces ServletConfig et ServletContext ont été présentées ainsi que le traitement
des requêtes et des réponses HTTP avec les méthodes de service doGet(...) et doPost(...). Le chapitre suivant fait un
rappel sur la synchronisation des traitements avec les Servlets. Ensuite, l’étape suivante a permis de gérer l’état des
clients sachant que le protocole HTTP fonctionne en mode déconnecté. Par la suite, les filtres ont été détaillés ainsi que
l’interface RequestDispatcher qui est utilisée pour le routage HTTP et qui est la base du modèle MVC avec les Servlets.
Enfin, l’application a été modifiée dans les deux derniers chapitres pour coller au modèle MVC et pour gérer les erreurs
et exceptions afin d’avoir un service fiable et robuste proche d’une application professionnelle.
© ENI Editions - All rigths reserved
- 1-
Travailler avec une base de données
1. Présentation
La plupart des applications Java EE utilisent une base de données pour la persistance des informations. Les sites de
commerce comme le projet BetaBoutique, stockent les informations concernant les clients, articles ou commandes.
Pour rappel, une base de données est un ensemble de tables organisées pour stocker des données manipulables par
une ou plusieurs applications. Une table est un ensemble d’occurrences d’un objet défini par ses propriétés (champs)
et dont chaque enregistrement (record) représente une instance (valorisation des champs de cet objet).
La plupart des bases de données commercialisées sont de nature clientserveur et recourent au langage SQL
(Structured Query Language) pour manipuler les données qu’elles contiennent. Java possède une API pour travailler
avec les bases de données. Cette technologie nommée JDBC (Java DataBase Connectivity) est une bibliothèque
d’interfaces et de classes, utilisée pour accéder aux SGBDR (Système de Gestion de Base de Données Relationnelles).
JDBC fournit aux développeurs tous les outils nécessaires pour permettre à des programmes clients de se connecter à
des bases de données et de leur envoyer des requêtes. Ces requêtes sont écrites en langage SQL.
Un programme écrit en JDBC envoie à un SGBDR des requêtes écrites en SQL et exploite le résultat retourné en Java.
En effet, ce système crée une abstraction des fonctions d’une base de données sous forme d’ensemble de classes et
de méthodes. Le code spécifique à une base de données particulière est contenu dans une bibliothèque appelée
pilote ou driver. Si nous utilisons une base de données possédant un pilote JDBC, elle peut être employée avec l’API.
Il existe plusieurs inconvénients à l’utilisation de la technologie JDBC :
●
Les instructions sont écrites sous forme de chaînes de caractères et leur exactitude ne peut être vérifiée ni par
Java ni par JDBC, mais uniquement par le SGBD au moment de l’exécution.
●
L’API JDBC est limitée à l’utilisation de bases de données relationnelles. Il n’existe pas d’implémentation pour
des bases de données objets SGBDO (Système de Gestion de Base de Données d’Objets).
●
L’utilisation de l’API JDBC nécessite de connaître un minimum du langage SQL afin de réaliser les requêtes.
Les avantages d’utiliser la technologie JDBC sont :
●
En cas de changement de SGBDR, il suffit de changer de driver en utilisant celui qui est adapté.
●
Une application JDBC peut se connecter à plusieurs SGBDR en même temps.
●
Les bibliothèques JDBC reposent sur SQL, elles bénéficient de toutes ses fonctionnalités (sélections, jointures,
transactions...).
●
La durée d’apprentissage de JDBC est réduite, pour une personne qui connaît le langage SQL.
●
L’API JDBC est portable sur la plupart des systèmes actuels.
Par la suite, nous allons utiliser l’API JDBC et ainsi développer des méthodes de manipulation de données persistantes
sans nous soucier de la base de données utilisée. Nous utiliserons par exemple, une base de données MySQL et le
driver adapté à ce SGBDR. Toutes les requêtes d’interrogation, de lecture, de mise à jour et de suppression seront
indépendantes de la base de données. Si nous souhaitons passer à une base de données PostgreSQL en production
par exemple, il suffira de changer le driver et d’utiliser celui adapté à PostgreSQL sans retoucher notre code.
Ce système portable est beaucoup plus évolué en Java qu’avec les technologies ASP ou PHP.
En effet, avec la technologie PHP par exemple, nous utiliserions les méthodes suivantes mysql_connect(...),
mysql_close(...), mysql_fetch_array(...) qui sont propres au SGBDR MySQL. En cas de passage vers le SGBDR
PostgreSQL ou Oracle, il serait nécessaire de coder de nouveau toute l’application.
2. Connexion aux bases de données
La connexion à une base de données par l’intermédiaire de l’API JDBC repose sur plusieurs étapes :
© ENI Editions - All rigths reserved
- 1-
●
Il est nécessaire de déterminer le pilote à utiliser pour communiquer avec la base de données.
●
Il est nécessaire de réaliser le code Java afin d’établir la connexion avec la base de données.
●
Il est nécessaire d’utiliser un objet spécifique pour insérer, mettre à jour ou effacer des données.
●
Il est nécessaire d’utiliser un objet spécifique pour lire les résultats d’une requête.
La première étape, consiste à établir la connexion entre le programme et la base de données. Un programme
travaillant avec une base de données utilise l’API JDBC pour établir une connexion avec le serveur de base de
données.
Le code spécifique à la base de données utilisée est contenu dans le pilote créé par l’éditeur de la base ou une
société tierce. Le principal intérêt, est qu’un programme peut communiquer avec différentes bases de données
simplement en changeant son pilote. De plus, les programmes sont simples car les détails des procédures de bas
niveau sont entièrement gérés par le pilote.
Les pilotes JDBC
La spécification JDBC propose quatre types de pilotes pouvant être employés pour communiquer avec les bases de
données.
●
Les pilotes de type 1 appelés, pilote middleware ODBC : ce type de pilote établit la correspondance entre
l’API JDBC et une autre API. Le système ODBC a été développé pour les systèmes d’exploitation Windows.
ODBC est une API permettant de communiquer avec les bases de données. Le pilote JDBCODBC de type 1
fournit une interface entre les programmes Java et l’API ODBC. Cette couche d’abstraction est composée de sa
propre API. Les appels JDBC sont convertis en appels ODBC avant d’être passés à la base de données, ce
pilote n’est pas très efficace et nécessite la configuration d’une source de données ODBC qui requiert
généralement uniquement la présence d’un serveur Windows.
●
Les pilotes de type 2 appelés, pilote middleware natif : ce type de pilote est semblable au pilote de type 1
car il communique avec la base de données par l’intermédiaire d’une API native. Un logiciel intermédiaire est
conçu spécialement pour se connecter à un pilote JDBC. Ce logiciel intermédiaire appelé middleware, est écrit
spécialement pour la plateforme utilisée. Ce type de pilote entraîne parfois des baisses de performances dans
la mesure où le middleware se trouve entre la base de données et JDBC. En outre, il n’existe pas toujours la
possibilité de trouver des pilotes correspondant à toutes les platesformes.
●
Les pilotes de type 3 appelés, pilote middleware Java : ce type de pilote est similaire aux pilotes de type 2
mais le logiciel exécuté entre JDBC et la base de données est cette fois une application Java. Le pilote
communique avec la base de données grâce à un composant intermédiaire. Le programme Java communique
avec ce composant par le biais d’un protocole réseau indépendant. Ce pilote est écrit en pur Java, il s’exécute
donc partout où Java peut être installé. Il peut donc être téléchargé et exécuté immédiatement, sans
configuration utilisateur.
●
Les pilotes de type 4 appelés, pilote natif pur Java : ce type de pilote se connecte directement à la base de
données. Il bénéficie donc, comme le pilote de type 3, de la portabilité de Java. Ce type de pilote léger,
communique directement avec la base de données sans qu’une conversion soit nécessaire. Il traduit les
appels JDBC en requête utilisant le protocole de la base de données sans passer par ODBC ou une API native.
Ce type de pilote offre généralement les meilleures performances. La plupart des fournisseurs de bases de
données proposent désormais des pilotes de types 2 adaptés comme Oracle, MySQL, PostgreSQL, Sybase,
InterBase... Si l’application doit pouvoir être installée sur différentes platesformes il est pratiquement
indispensable d’utiliser un pilote de type 4. Il sera ainsi possible de déployer l’application sur différents
systèmes sans modifications.
Le plus souvent, nous utilisons des pilotes de types 3 ou 4. Les pilotes de type 1 et 2 ajoutent une couche de
communication entre la couche JDBC et la base de données, ce qui nuit à l’efficacité. En terme de performances, les
- 2-
© ENI Editions - All rigths reserved
pilotes de type 3 et 4 sont pratiquement équivalents.
Les bases de données
MySQL est supportée par un large éventail d’outils. Elle est soumise à la licence GNU GPL. MySQL est surtout installée
pour les applications Web, elle est solide et utilisée par de grands groupes spécialisés dans l’Internet. Elle reste
cependant parfois limitée en terme de fonctionnalités avancées mais elle est très évoluée en terme de performances.
Plusieurs pilotes natifs de type 4 sont disponibles pour MySQL et sont conseillés pour une utilisation en Java.
PostgreSQL est disponible pour la plupart des systèmes d’exploitation modernes. PostgreSQL a été développé à
l’université de Berkley en Californie sous la direction d’un groupe de développement et divers autres participants dans
le monde entier.
Oracle et DB2 sont les deux leaders sur le marché des bases de données commerciales. Oracle offre de nombreuses
fonctionnalités comme l’intégration de code Java dans les procédures stockées. Ce SGBDR est robuste et très
performant. Cependant, cette base de données possède deux inconvénients majeurs, le prix des licences et la
complexité du système. Oracle possède un pilote JDBC de type 4 utilisable avec les applications Java. DB2 est un
SGBDR qui est développé par la société IBM. Ce système très performant utilise un pilote JDBC de type 4 pour les
applications développées en Java.
3. Utilisation de l’API JDBC
Pour la mise en application de JDBC, nous allons utiliser le SGBDR MySQL disponible à cette adresse : http://www
fr.mysql.com/.
Pour le projet, nous allons installer le paquet EasyPHP (http://www.easyphp.org/) afin de bénéficier de la base de
données MySQL (version 5) mais également de l’outil PhpMyAdmin afin de créer facilement les tables, manipuler les
données, gérer les encodages...
Nous allons commencer par démarrer MySQL et créer la base de données nommée : betaboutique.
Dans cette base de données, nous allons créer la table client, avec pour le moment les données suivantes :
La classe DriverManager est responsable de la gestion des pilotes JDBC. Cette classe permet de fournir les connexions
au code Java. Pour utiliser une base de données, il suffit de passer au gestionnaire de pilotes DriverManager une URL
afin que celuici retourne une connexion. Lorsqu’un programme demande une connexion, le gestionnaire de pilotes
© ENI Editions - All rigths reserved
- 3-
interroge chaque pilote pour savoir s’il est capable de traiter l’URL. Dès qu’un pilote correct est trouvé, il lui demande
d’établir une connexion et la retourne au programme appelant.
Installation du driver de la base de données
Quelle que soit la base de données utilisée avec JDBC, il faut installer son pilote pour qu’elle puisse fonctionner avec la
programmation Java. Chaque driver est spécifique à la base de données utilisée. Pour MySQL, le connecteur utilisé
dans
ce
guide
est
mysqlconnectorjava3.1.11bin.jar.
Il
peut
être
téléchargé
à
cette
adresse :
http://dev.mysql.com/doc/refman/5.0/fr/javaconnector.html
Cette librairie au format JAR contient les classes qui seront utilisées par les applications Java, afin de fonctionner avec
le SGBDR MySQL. Une fois cette bibliothèque téléchargée, nous l’installons dans le répertoire /lib de Tomcat. Ce
répertoire contient les librairies utilisées et partagées par le serveur d’applications. Cette librairie sera sans doute
utilisée par plusieurs projets, il est donc conseillé de l’installer dans le répertoire partagé. Toutefois, cette opération
n’est pas obligatoire, et nous pouvons installer le pilote JDBC comme une autre librairie (installation dans le
répertoire /WEBINF/lib de l’application).
Pour faire fonctionner une application avec JDBC, il faut effectuer les tâches suivantes dans l’ordre indiqué, quelle que
soit la base de données utilisée :
●
Chargement du pilote/driver de la base de données.
●
Obtention de la connexion à la base de données.
●
Préparation de la requête d’accès à la base de données.
●
Accès aux données de la base de données.
●
Libération des ressources/connexions.
Pour mettre en application JDBC avec la table client de la base betaboutique, nous allons développer la Servlet :
ServletListeClientModele.
Chargement du pilote/driver de la base de données
Le chargement du driver est effectué avec l’instruction Class.forName(nomdudriver).
Pour notre projet, nous allons utiliser la configuration suivante :
...
servletlisteclientmodele
betaboutique.servlets.client.ServletListe
ClientModele
servletlisteclientmodele
/listeclient
...
La méthode forName(String) de la classe java.lang.Class permet d’indiquer à la JVM qu’elle doit trouver, charger et
initialiser la classe désignée par le paramètre. Le programme appelant n’a donc pas besoin de créer une instance de la
classe. La classe se charge de créer une instance et s’occupe ellemême de l’enregistrement. Le paramètre est le nom
du driver indiqué par le fournisseur pour la base de données concernée. Ce paramètre correspond au nom de la classe
qui sera chargée en mémoire par Class.forName(...). Pour MySQL ce paramètre est : com.mysql.jdbc.Driver.
L’appel de cette méthode peut provoquer une exception de type ClassNotFoundException que nous devons attraper
avec un bloc d’exception try catch.
Eclipse permet de déclarer automatiquement les blocs d’exceptions. Pour cela, il faut faire un clic sur la croix
rouge qui représente l’erreur et sélectionner : surround.
Le code de chargement du pilote, présent dans la Servlet ServletListeClientModele, est donc le suivant :
package betaboutique.servlets.client;
- 4-
© ENI Editions - All rigths reserved
import
import
import
import
import
java.io.IOException;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try {
Class.forName("com.mysql.jdbc.Driver");
System.out.println("Pilote MySQL JDBC chargé");
} catch (ClassNotFoundException e) {
e.printStackTrace();
System.out.println("Erreur lors du chargmement du pilote");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Obtention de la connexion à la base de données
Une fois le driver chargé avec succès, nous pouvons utiliser l’API JDBC pour obtenir une connexion à la source de
données. La connexion au SGBDR nécessite un nom d’utilisateur et un mot de passe. Les connexions peuvent être
obtenues à partir du pilote. La méthode permettant d’obtenir une connexion est getConnection(...).
Il existe plusieurs formes de cette méthode, les plus utilisées sont : getConnection(String url) et getConnection(String
url, String utilisateur, String motdepasse)
Le paramètre URL est une URI HTTP avec l’adresse IP du serveur contenant la base de données (en local ou à
distance) et son nom.
Pour notre projet l’instruction est de la forme suivante :
package betaboutique.servlets.client;
import java.io.IOException;
import java.sql.*;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
Connection connection=null;
try {
//chargement du driver
Class.forName("com.mysql.jdbc.Driver");
System.out.println("Pilote MySQL JDBC chargé");
} catch (ClassNotFoundException e) {
e.printStackTrace();
System.out.println("Erreur lors du chargmement du pilote");
}
try {
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
© ENI Editions - All rigths reserved
- 5-
System.out.println("Connexion opérationnelle");
} catch (SQLException e) {
e.printStackTrace();
System.out.println("Erreur lors de
l’établissement de la connexion");
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Dans notre exemple, nous avons précisé le protocole jdbc, le serveur de base de données présent sur la machine
locale (localhost), le port MySQL (3306) et la base de données utilisée (betaboutique). Le nom d’utilisateur est root et
cet utilisateur ne possède pas de mot de passe.
Il existe également une troisième et dernière forme de la méthode getConnection(String url, Properties proprietes) avec
une URL et un ensemble de propriétés représentées par un objet instancié à partir de la classe Properties. Cet objet
permet de passer des paramètres supplémentaires comme le type de connexion, le cryptage utilisé, le codage de la
base... La connexion ouverte est utilisable tout le temps, pour toutes les requêtes futures dans le temps, tant que
celleci n’est pas fermée.
Préparation de la requête d’accès à la base de données
Deux cas sont envisageables pour l’accès aux données. Soit la requête est une sélection de données (sélection), soit
une autre action (création, modification ou suppression). Dans le premier cas, la liste des données est renvoyée et la
requête exécutée (executeQuery), dans le second cas, le nombre d’enregistrements affectés est retourné et la
modification de l’état des données (executeUpdate) est exécutée.
SELECT : ResultSet rs = statement.executeQuery(requete);
AUTRE : int nblignes = statement.executeUpdate(requete);
Accès aux données de la base de données
L’accès aux données est réalisé à travers l’objet ResultSet obtenu lors de l’appel à statement.executeQuery(requete).
Nous verrons par la suite un exemple complet d’utilisation.
Libération des ressources/connexions
Lors du développement, il n’est pas rare d’arriver à la saturation de l’application à cause d’un problème de fermeture
de connexion suite à une montée en charge. Il est important de vérifier avec des outils adaptés (fournis avec la base
de données) si le nombre d’ouvertures et le nombre de connexions libérées sont identiques. Si ces nombres divergent,
même lentement, il y a alors un problème de programmation. L’application va finir par se bloquer, dans l’attente de
connexions qui n’arriveront jamais. Il est donc très important en Java EE de libérer correctement les connexions.
La simple invocation de la méthode close() de l’objet connexion permet la fermeture.
Il est également nécessaire de libérer les ressources mémoire occupées par les objets Statement pour la préparation
des requêtes et les objets ResultSet pour le parcours de ces requêtes. Pour pallier à certaines erreurs de
programmation, le ramassemiettes va se charger de fermer correctement certaines ressources mais n’importe quand.
Nous allons montrer un exemple de chargement du driver, de connexion au SGBDR et de fermeture avec notre Servlet.
package betaboutique.servlets.client;
import
import
import
import
import
import
java.io.IOException;
java.sql.*;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
Connection connection=null;
try {
- 6-
© ENI Editions - All rigths reserved
//chargement du driver
Class.forName("com.mysql.jdbc.Driver");
System.out.println("Pilote MySQL JDBC chargé");
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
System.out.println("Erreur lors du chargement du pilote");
}
try {
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
System.out.println("Connexion opérationnelle");
//obtenir des informations sur la base de données
DatabaseMetaData dbmd = connection.getMetaData();
System.out.println("Nom de la base de données :
"+dbmd.getDatabaseProductName());
System.out.println("Version de la base de données :
"+dbmd.getDatabaseProductVersion());
System.out.println("Nom du pilote de la
base de données : "+dbmd.getDriverName());
System.out.println("Version du pilote de la
base de données : "+dbmd.getDriverVersion());
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
System.out.println("Erreur lors de
l’établissement de la connexion");
}
//fermer la connexion
try {
connection.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Ce code est fonctionnel mais il contient une énorme erreur de programmation. Les méthodes JDBC peuvent lancer des
exceptions SQL. Le problème c’est que si une telle exception est lancée, avec la méthode getConnection(), un
Statement ou un ResultSet, l’exception liée à la fermeture de la connexion ne sera pas déclenchée. Dans notre
exemple, si la connexion est réalisée mais qu’une exception est déclenchée à la suite, le code suivant ne sera jamais
déclenché :
...
//fermer la connexion
try {
connection.close();
} catch (SQLException e) {
e.printStackTrace();
}
© ENI Editions - All rigths reserved
- 7-
...
La façon correcte d’utiliser la méthode close(), consiste à placer cette instruction dans le bloc finally d’une structure try,
catch, finally. Cette partie du code sera toujours déclenchée quoi qu’il arrive, qu’une exception soit levée ou pas. La
Servlet doit donc avoir le code suivant :
...
try
{
//obtention de la connexion
connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/
betaboutique","root","");
System.out.println("Connexion opérationnelle");
//obtenir des informations sur la base de données
DatabaseMetaData dbmd = connection.getMetaData();
System.out.println("Nom de la base de données :
"+dbmd.getDatabaseProductName());
System.out.println("Version de la base de données :
"+dbmd.getDatabaseProductVersion());
System.out.println("Nom du pilote de la base de données :
"+dbmd.getDriverName());
System.out.println("Version du pilote de la base de données :
"+dbmd.getDriverVersion());
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement de la connexion");
}
finally
{
//fermer la connexion
try
{
connection.close();
} catch (SQLException e)
{
e.printStackTrace();
}
}
...
L’interface Statement
Nous avons vu dans le code précédent comment établir une connexion avec une base de données. Toutefois, l’objet
connection ne fournit pas de méthodes permettant d’utiliser la base de données. Pour créer, lire, mettre à jour ou
effacer des données, nous utilisons la classe Statement.
Les objets Statement représentent l’interface principale avec la base de données. Un objet de cette classe est créé
par l’appel de la méthode createStatement() de l’objet Connection. Une fois en possession d’un objet Statement, nous
pouvons l’utiliser pour envoyer à la base de données des commandes SQL à l’aide d’une des trois méthodes
suivantes :
●
executeQuery(requête SQL) : exécute la requête SELECT pour interroger la base de données, et retourne un
ResultSet pour parcourir le résultat.
●
executeUpdate(requête SQL) : exécute la requête SQL pour provoquer une modification de l’état de la base de
données (création, modification ou suppression) et retourne le nombre d’enregistrements concernés.
●
executeBatch() : exécute un traitement par lot de commandes SQL en une seule opération.
L’interface ResultSet
Lorsque nous réalisons une requête sur une base de données, les résultats sont retournés dans un objet de type
ResultSet. Cet objet permet de lire les lignes du résultat et de lire les données dans les différentes colonnes. Un objet
de cette classe est créé suite à l’appel de l’une des deux méthodes :
- 8-
© ENI Editions - All rigths reserved
●
Statement.executeQuery(requête SQL) ;
●
PreparedStatement.executeQuery().
Un objet ResultSet contient le résultat de la requête SELECT effectuée vers la base de données. Les méthodes de
l’objet permettent de parcourir les lignes obtenues par la requête et d’extraire les champs de ces lignes.
En supposant qu’il n’y ait pas eu de problème lors de l’exécution de la commande SQL, la méthode executeQuery()
retourne toujours un ResultSet non nul. Au départ, le curseur est positionné avant la première ligne. La méthode next
() permet d’atteindre la première ligne, cette méthode retourne true s’il y a une valeur et false lors de l’accès à la
dernière ligne.
Les méthodes suivantes peuvent être employées avec un ResultSet :
●
next() : pour passer à la ligne suivante du ResultSet.
●
previous() : pour passer à la ligne précédente.
●
first() : pour se positionner à la première ligne.
●
last() : pour se positionner à la dernière ligne.
●
beforeFirst() : pour se positionner avant la première ligne.
●
afterLast() : pour se positionner après la dernière ligne.
●
isFirst() : pour tester si le positionnement est à la première ligne.
●
isLast() : pour tester si le positionnement est à la dernière ligne.
●
isBeforeFirst() : pour tester si le positionnement est avant la première ligne.
●
isAfterLast() : pour tester si le positionnement est après la dernière ligne.
●
absolute(index) : pour se positionner à l’index précisé.
●
close() : pour fermer le ResultSet.
L’interface ResultSet contient de nombreuses méthodes permettant de lire les données retournées par une requête.
Ces méthodes correspondent aux colonnes par leur nom ou par leur position. Il existe deux méthodes getXxx() pour
toutes les primitives Java et pour certains objets. La première méthode prend en argument une valeur entière
correspondant à l’indice du champ de la table, et l’autre une chaîne de caractères correspondant au nom du champ de
la table.
Les numéros de colonnes commencent à 1 et non à 0. Le choix d’un argument de type int est plus rapide qu’un
élément de type String mais également moins souple. En effet, les numéros de colonnes peuvent changer alors que
c’est plus rarement le cas des noms. Nous retrouvons les méthodes suivantes de l’interface ResultSet : getString(...),
getArray(...), getBigDecimal(...), getBoolean(...), getByte(...), getDate(...), getDouble(...), getFloat(...), getInt(...), getLong
(...), getShort(...), getTime(...).
La valeur NULL a une signification particulière en SQL. En effet, NULL n’est pas la même chose que la chaîne de
caractères vide ou la valeur 0 pour un numérique. NULL signifie qu’aucune donnée n’a été définie pour la valeur du
champ. Pour toutes les méthodes retournant un objet, la méthode retourne NULL si la colonne contient NULL et 0 pour
les primitives numériques. Pour les types booléens, la valeur retournée est FALSE.
Si par exemple nous utilisons getFloat() et que la valeur de retour est 0 comment savoir si la colonne contient NULL ou
0 ? L’interface ResultSet propose alors une méthode permettant d’obtenir cette information : public boolean wasNull().
Cette méthode ne prend pas d’indication de colonne pour argument, elle agit sur la dernière colonne lue. Voici un
exemple complet d’utilisation des interfaces Statement et ResultSet pour lire les clients de la base de données.
package betaboutique.servlets.client;
import java.io.IOException;
import java.sql.*;
© ENI Editions - All rigths reserved
- 9-
import
import
import
import
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
Connection connection=null;
Statement st=null;
ResultSet rs=null;
try
{
//chargement du driver
Class.forName("com.mysql.jdbc.Driver");
System.out.println("Pilote MySQL JDBC chargé");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
System.out.println("Erreur lors du chargement du pilote");
}
try
{
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
System.out.println("Connexion opérationnelle");
//lire les données de la table client
st=connection.createStatement();
rs=st.executeQuery("SELECT * FROM client");
//affichage
while(rs.next())
{
System.out.println("Client :
"+rs.getInt("id_client")+"-"+rs.getString("identifiantclient")
+"-"+rs.getString("motdepasseclient"));
}
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
finally
{
//fermer la connexion
try
{
rs.close();
st.close();
connection.close();
} catch (SQLException e)
{
e.printStackTrace();
}
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
- 10 -
© ENI Editions - All rigths reserved
}
}
Il faut noter dans le code précédent que les ressources sont toujours libérées dans l’ordre inverse de leur création (rs,
st, connection). La connexion est ouverte en premier et fermée en dernier, par exemple. Il faut prendre pour habitude
de reprendre le code et de le fermer.
Le code précédent fonctionne mais il n’est pas correct. Si le déclenchement de la fonction rs.close() provoque une
erreur, l’exception est attrapée (SQLException) et les lignes st.close() et connection.close() ne seront pas déclenchées.
Résultat, la connexion ne sera pas fermée. La solution consiste à lancer un bloc try catch pour chaque ouverture de
ressource. Ainsi, une exception lancée dans la méthode n’empêchera pas l’appel de la méthode close() de la
connexion.
Cette erreur de fermeture est très courante en Java même avec d’excellents développeurs. Rares sont les
livres ou cours qui traitent cette erreur et il est très courant de trouver la fermeture des ressources dans le
même bloc try catch.
Pour résoudre ce problème, il faut entourer chaque fermeture d’un bloc try catch. Le code est ainsi exécuté qu’il y ait
une exception ou pas.
...
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
finally
{
if(rs!=null)
{
try
{
rs.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
if(st!=null)
{
try
{
st.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
if(connection!=null)
{
try
{
connection.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
...
Le code est désormais correct, par contre, la programmation est lourde et elle nécessite des enchaînements de blocs
try catch. Pour avoir un code plus lisible et moins verbeux, il faut utiliser une classe statique (c’estàdire que les
instances de cette classe manipulent les mêmes paramètres) qui va correctement fermer les ressources. Cette classe
nommée OutilsBaseDeDonnees est placée dans le paquetage betaboutique.boiteoutils.
© ENI Editions - All rigths reserved
- 11 -
Une classe statique n’a pas besoin d’être instanciée pour pouvoir appeler ses méthodes. Cette classe n’a
d’ailleurs pas besoin de constructeur. Dans ce genre de classe, plusieurs ’’instances’’ manipulent les mêmes
paramètres partagés. Il faut utiliser alors le nom de la classe directement à la place d’une instance. À la différence,
un singleton ne possède qu’une seule instance de la classe. De même, comme toute classe non statique, elle doit
obligatoirement être instanciée.
Voici le code de la classe OutilsBaseDeDonnees avec les méthodes statiques génériques (technique de surcharge des
signatures de méthodes).
package betaboutique.boiteoutils;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
public class OutilsBaseDeDonnees
{
/***********************************************************
* fermer correctement un resultset
***********************************************************/
public static void fermerConnexion(ResultSet rs)
{
if(rs!=null)
{
try
{
rs.close();
}
catch(Exception e)
{
System.out.println("Erreur lors de la fermeture
d’une connexion dans fermerConnexion(ResultSet)");
}
}
}
/***********************************************************
* fermer correctement un statement
***********************************************************/
public static void fermerConnexion(Statement stmt)
{
if(stmt!=null)
{
try
{
stmt.close();
}
catch(Exception e)
{
System.out.println("Erreur lors de la fermeture
d’une connexion dans fermerConnexion(Statement)");
}
}
}
/***********************************************************
* fermer correctement une connection
***********************************************************/
public static void fermerConnexion(Connection con)
{
if(con!=null)
{
try
{
con.close();
}
catch(Exception e)
{
- 12 -
© ENI Editions - All rigths reserved
System.out.println("Erreur lors de la fermeture
d’une connexion dans fermerConnexion(Connection)");
}
}
}
//fin de la classe
}
Le code précédent est modifié avec l’utilisation de la classe statique OutilsBaseDeDonnees afin de fermer correctement
les ressources. Le code est plus léger et plus sûr.
...
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de
l’établissement de la connexion");
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(rs);
OutilsBaseDeDonnees.fermerConnexion(st);
OutilsBaseDeDonnees.fermerConnexion(connection);
}
}
...
Cette Servlet permettant de lister les clients de la boutique fonctionne correctement. Maintenant, nous allons ajouter
les enregistrements suivants dans la table client de la base de données betaboutique.
Nous relançons à nouveau la Servlet afin de vérifier que le parcours du ResultSet est opérationnel.
Nous allons maintenant modifier légèrement notre Servlet afin de réaliser une requête pour simuler par exemple, une
recherche d’un client depuis l’interface d’administration.
...
try
{
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
System.out.println("Connexion opérationnelle");
//client a rechercher
String recherche="mtissot";
//lire les données de la table client
st=connection.createStatement();
rs=st.executeQuery("SELECT * FROM client WHERE
identifiantclient=\""+recherche+"\"");
© ENI Editions - All rigths reserved
- 13 -
//affichage
while(rs.next())
{
System.out.println("Client : "+rs.getInt("id_client")
+"-"+rs.getString("identifiantclient")+"-"+rs.getString
("motdepasseclient"));
}
}
...
La Servlet est exécutée sans problème et produit le résultat souhaité. Nous allons réaliser une recherche sur
l’identifiant ’’avion’’. Dans un cas réel, cela pourrait correspondre à une recherche précise, par exemple une description
d’un article (ex : ’’le choix des armes’’).
...
try
{
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
System.out.println("Connexion opérationnelle");
//client a rechercher (les slashes permettent d’échapper les guillemets)
String recherche="\"avion\"";
//lire les données de la table client
st=connection.createStatement();
rs=st.executeQuery("SELECT * FROM client WHERE
identifiantclient=\""+recherche+"\"");
//affichage
while(rs.next())
{
System.out.println("Client : "+rs.getInt("id_client")
+"-"+rs.getString("identifiantclient")+"-"+rs.getString
("motdepasseclient"));
}
}
...
Cette requête provoque une erreur. Le terme de la recherche contient des guillemets qui empêchent le
fonctionnement de la méthode. L’erreur affichée, de type java.sql.SLQException indique un problème de syntaxe près
de ’avion’’’’’. En effet, JDBC reçoit en fait, la requête incorrecte suivante : SELECT * FROM client WHERE
identifiantclient=’’’’’;.
Une solution serait bien sûr, de développer une méthode qui permette de réaliser des remplacements de caractères,
ajouter des échappements ou remplacer les quotes comme dans d’autres langages (addslashes() de PHP par
exemple), mais il y aura forcément des cas qui ne fonctionneront pas et cela nécessiterait un code lourd à gérer
(échappement des caractères avant chaque insertion et après chaque lecture). En effet, avec ce genre de méthodes,
notre identifiant ’’avion’’ serait alors manipulé sous la forme suivante \’’avion\’’.
Les requêtes SQL sont complexes à écrire sous forme de String du fait du mélange de la syntaxe SQL et des variables
du programme. Pour pallier cet inconvénient, il existe une interface PreparedStatement dérivant de Statement qui
permet de formater les requêtes SQL de façon beaucoup plus simple.
L’interface PreparedStatement
L’interface PreparedStatement hérite de Statement. Toutes les méthodes de cette interface, déclenchent l’exception
SQLException de la classe java.sql. Les méthodes de cette interface permettent de répondre à des problèmes de
portabilité, de compatibilité des bases, de temps d’exécution et de performance.
Par exemple, lors d’un développement sous le SGBD MySQL, les guillemets doubles sont acceptés, mais une base de
données comme Sybase n’accepte que les guillemets simples. D’ailleurs, sur les forums du Web la question des
guillements en SQL figure souvent : ’’Comment puisje insérer le titre ’’l’alpagueur’’ dans ma base de données sans
erreur ?’’.
Une réponse courante de développeur non expérimenté serait de doubler les guillemets ou d’utiliser un antislash.
Nous aurions alors, ’’l\’alpagueur’’ sous MySQL mais cela ne fonctionnerait pas sous Sybase et PostgreSQL.
Par exemple, sous PostgreSQL nous aurions alors ’’l ’’ alpagueur’’ (deux guillemets simples). Il est visible que cette
technique est lourde en terme de développement pour le respect des compatibilités. JDBC offre une couche
d’abstraction supplémentaire pour manipuler les bases de données, chaque constructeur gérant les guillemets et
quotes avec son pilote.
Enfin, la plupart des bases de données évoluées gardent en mémoire cache les commandes SQL récemment
- 14 -
© ENI Editions - All rigths reserved
exécutées. Si une commande qui est en mémoire cache est utilisée, le résultat sera plus rapide car celleci est
compilée et optimisée. Toutefois, il est nécessaire que la commande envoyée corresponde exactement à celle se
trouvant en cache. Supposons l’exemple suivant avec deux commandes :
INSERT INTO client VALUES (’mtissot’,’marc’);
INSERT INTO client VALUES (’adurand’,’alain’);
Ces deux commandes sont presque identiques puisqu’elles ne diffèrent que par les valeurs littérales. Du point de vue
du SGBD, les deux commandes sont quand même totalement distinctes. Si par contre, nous passons à la base de
données des requêtes identiques puis qu’après, nous déclenchons des commandes comportant des variables, alors la
même requête est exécutée dans les deux cas. C’est ce que permet l’interface PreparedStatement.
INSERT INTO client VALUES (?,?);
setString(1,’mtissot’);
setString(2,’marc’);
INSERT INTO client VALUES (?,?);
setString(1,’adurant’);
setString(2,’alain’);
La création d’un PreparedStatement est pratiquement identique à celle d’un objet Statement. La différence se situe au
niveau de la précision de la commande à exécuter par le SGBD. Une fois l’objet PreparedStatement créé, avant que la
commande SQL puisse être exécutée, les marqueurs (?) doivent être remplacés.
Les méthodes cidessous permettent de fournir des valeurs aux différents paramètres. Les paramètres sont
numérotés à partir de 1, dans l’ordre d’apparition des symboles ?. Nous retrouvons alors des méthodes de la forme
setXxx() où Xxx correspond au type de données Java.
●
setString(indice,chaine) : permet d’affecter une chaîne de caractères au paramètre d’indice.
●
setInt(indice,entier) : permet d’affecter un entier au paramètre d’indice.
●
setBoolean(indice,booléen) : permet d’affecter un booléen au paramètre d’indice.
●
setFloat(indice,float) : permet d’affecter un réel au paramètre d’indice.
●
...
Comme dans le cas des Statements, la méthode executeQuery() permet d’exécuter des requêtes SQL de type SELECT
(qui retournent une liste de données) et la méthode executeUpdate() permet d’exécuter des requêtes de modification
de l’état de la base de données (qui retournent le nombre d’enregistrements concernés). Les méthodes getConnection
() et close() permettent respectivement d’accéder à la connexion et de fermer celleci.
Nous allons modifier notre exemple précédent, non fonctionnel, avec un PreparedStatement compilé.
package betaboutique.servlets.client;
import
import
import
import
import
import
import
java.io.IOException;
java.sql.*;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
betaboutique.boiteoutils.OutilsBaseDeDonnees;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
Connection connection=null;
PreparedStatement requete=null;
ResultSet rs=null;
try
{
//chargement du driver
Class.forName("com.mysql.jdbc.Driver");
© ENI Editions - All rigths reserved
- 15 -
System.out.println("Pilote MySQL JDBC chargé");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
System.out.println("Erreur lors du chargmement du pilote");
}
try
{
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
System.out.println("Connexion opérationnelle");
//preparation de la requete
requete=connection.prepareStatement("SELECT * FROM client
WHERE identifiantclient=?");
requete.setString(1, "\"avion\"");
//executer la requete
rs=requete.executeQuery();
//affichage
while(rs.next())
{
System.out.println("Client : "+rs.getInt
("id_client")+"-"+rs.getString("identifiantclient")+"-"+
rs.getString("motdepasseclient"));
}
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(rs);
OutilsBaseDeDonnees.fermerConnexion(requete);
OutilsBaseDeDonnees.fermerConnexion(connection);
}
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
La requête fonctionne maintenant parfaitement avec une chaîne de caractères composée de quotes ou guillemets, il
n’y a plus de soucis de compatibilité entre les SGBD.
L’instruction setString(1,"\’’avion\""); indique de remplacer le premier ’?’ dans la requête, par la chaîne de caractères
’’avion’’. La requête, beaucoup plus lisible, est compilée par le SGBD, d’où un gain de temps d’exécution appréciable.
De plus, la requête suivante est compilée : SELECT * FROM client WHERE identifiantclient=?, c’estàdire que le prochain
appel, avec juste le changement de l’identifiant de l’utilisateur, sera exécuté très rapidement.
En effet, Java toujours soucieux de la portabilité, utilise un pilote pour chaque base mais par contre développe un
code générique qui sera ensuite interprété par le pilote adapté. Ainsi, il n’y aura plus besoin d’utiliser des méthodes
spécifiques à un SGBD et des échappements de chaînes plus ou moins sûrs.
Nous allons modifier notre Servlet afin d’insérer également un nouveau client lors du déclenchement de la Servlet. Cet
- 16 -
© ENI Editions - All rigths reserved
exemple permet de nous montrer que le principe est identique pour une insertion et une lecture, seules les fonctions
executeQuery() et executeUpdate() changent.
...
try
{
//obtention de la connexion
connection =
DriverManager.getConnection("jdbc:mysql://localhost:3306/betaboutique",
"root","");
//on insère un nouvel enregistrement
requetea=connection.prepareStatement("INSERT INTO
client(identifiantclient,motdepasseclient) VALUES (?,?)");
requetea.setString(1, "amartin");
requetea.setString(2, "martin");
int resinstrution=requetea.executeUpdate();
System.out.println("Insertion nbligne : "+resinstrution);
//preparation de la requete
requeteb=connection.prepareStatement("SELECT * FROM client WHERE
identifiantclient=?");
requeteb.setString(1, "amartin");
//executer la requete
rs=requeteb.executeQuery();
//affichage
while(rs.next())
{
System.out.println("Client : "+rs.getInt("id_client")+""+rs.getString("identifiantclient")+"-"+rs.getString("motdepasseclient"));
}
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement de la
connexion");
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(rs);
OutilsBaseDeDonnees.fermerConnexion(requeteb);
OutilsBaseDeDonnees.fermerConnexion(requetea);
OutilsBaseDeDonnees.fermerConnexion(connection);
}
...
Le résultat de l’instruction executeUpdate() est très important, il permet de réaliser des tests. Dans notre cas par
exemple, si la variable resinstruction est égale à 0 cela indique qu’aucune ligne ne sera modifiée dans la base de
données (ici créée), il y aura donc une erreur.
Cette technique d’utilisation d’une connexion, d’un objet Statement ou PreparedStatement et d’un objet ResultSet peut
© ENI Editions - All rigths reserved
- 17 -
paraître complexe, mais elle est en fait très naturelle et permet d’avoir une certaine rigueur dans le code de
l’application.
●
Utilisation en premier d’une connexion pour dialoguer avec la base de données.
●
Utilisation ensuite d’un objet Statement ou PreparedStatement (de préférence celuici) pour dialoguer avec la
base de données et exécuter des requêtes.
●
Déclenchement des requêtes avec les fonctions executeQuery() ou executeUpdate().
●
Parcourir au besoin le résultat de la requête avec un objet ResultSet.
Pour la suite, nous utiliserons de préférence des requêtes compilées avec l’interface PreparedStatement.
Insertion de valeurs nulles
Pour insérer une valeur nulle avec les PreparedStatement, il ne suffit pas de mettre la valeur vide pour ce marqueur,
cela cause le lancement d’une SQLException par le pilote JDBC. Pour l’éviter, nous devons utiliser une des deux
méthodes suivantes :
●
setNull(int,int)
●
setNull(int,int,String)
Le premier paramètre correspond à la position du marqueur. Le second paramètre est défini dans la classe
java.sql.Types. Cette classe contient des constantes pour les types JDBC. Si par exemple, nous souhaitons affecter la
valeur NULL à une colonne de type String, nous utilisons java.sql.Types.STRING. La version de la méthode avec un
troisième paramètre de type String est utilisée pour des types définis par les utilisateurs.
- 18 -
© ENI Editions - All rigths reserved
Partage de connexions
1. Présentation
Les exemples précédents permettent de présenter l’utilisation des bases de données en Java, mais ne sont pas
envisageables dans un projet de grande envergure. En effet, le code n’est pas très clair, une connexion est créée à
chaque appel, les paramètres de connexion sont dans la Servlet et les codes de traitement et d’accès aux données se
chevauchent.
Nous allons donc modifier notre exemple et la table client afin de réaliser des accès partagés, des recherches et des
affichages adaptés.
2. Initialisation d’une connexion
Le code de la Servlet ServletListeClientModele n’est pas conforme. La connexion doit être ouverte dans la méthode init()
et fermée dans la méthode destroy(). Le code conforme au standard Java EE est présenté cidessous :
package betaboutique.servlets.client;
import
import
import
import
import
import
import
java.io.IOException;
java.sql.*;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
betaboutique.boiteoutils.OutilsBaseDeDonnees;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
Connection connection=null;
PreparedStatement requete=null;
ResultSet rs=null;
//initialisation de la connexion
public void init()
{
try
{
//chargement du driver
Class.forName("com.mysql.jdbc.Driver");
System.out.println("Pilote MySQL JDBC chargé");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
System.out.println("Erreur lors du chargement du pilote");
}
try
{
//obtention de la connexion
connection = DriverManager.getConnection
("jdbc:mysql://localhost:3306/betaboutique","root","");
System.out.println("Connexion opérationnelle");
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
}
© ENI Editions - All rigths reserved
- 1-
//traitements
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try
{
//preparation de la requete
requete=connection.prepareStatement("SELECT * FROM
client WHERE identifiantclient=?");
requete.setString(1, "amartin");
//executer la requete
rs=requete.executeQuery();
//affichage
while(rs.next())
{
System.out.println("Client : "+rs.getInt
("id_client")+"-"+rs.getString("identifiantclient")+"-"+
rs.getString("motdepasseclient"));
}
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
}
//traitements
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
//fermeture des ressources
public void destroy(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try
{
//fermeture
System.out.println("Connexion fermée");
}
catch (Exception e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(rs);
OutilsBaseDeDonnees.fermerConnexion(requete);
OutilsBaseDeDonnees.fermerConnexion(connection);
}
}
}
Cette Servlet est opérationnelle, le chargement des ressources est géré dans la méthode init() au démarrage de la
Servlet, et la libération des ressources dans la méthode destroy().
Nous allons légèrement modifier cette Servlet afin de positionner les paramètres de connexion dans le fichier de
configuration de l’application (web.xml). Lors du changement de la base de données ou des paramètres de connexion,
le code ne sera ainsi pas retouché et fonctionnera normalement. Le fichier web.xml est volontairement simplifié pour
ne traiter que les exemples JDBC.
- 2-
© ENI Editions - All rigths reserved
pilotejdbc
com.mysql.jdbc.Driver
urlconnexionjdbc
jdbc:mysql://localhost:3306/betaboutique
/context-param>
utilisateurjdbc
root
motdepassejdbc
servletlisteclientmodele
betaboutique.servlets.client.Servlet
ListeClientModele
servletlisteclientmodele
/listeclient
...
//initialisation de la connexion
public void init()
{
ServletContext servletContext=getServletContext();
pilotejdbc=(String)servletContext.getInitParameter
("pilotejdbc");
urlconnexionjdbc=(String)servletContext.getInit
Parameter("urlconnexionjdbc");
utilisateurjdbc=(String)servletContext.getInit
Parameter("utilisateurjdbc");
motdepassejdbc=(String)servletContext.getInit
Parameter("motdepassejdbc");
try
{
//chargement du driver
Class.forName(pilotejdbc);
System.out.println("Pilote MySQL JDBC chargé");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
System.out.println("Erreur lors du chargmement du pilote");
}
try
{
//obtention de la connexion
connection = DriverManager.getConnection
(urlconnexionjdbc,utilisateurjdbc,motdepassejdbc);
System.out.println("Connexion opérationnelle");
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
© ENI Editions - All rigths reserved
- 3-
}
}
...
Nous allons modifier la table client et ajouter tous les champs nécessaires aux traitements (la structure respecte la
maquette du chapitre : Les Servlets). Pour cela, nous pouvons supprimer la table actuelle et utiliser le code suivant qui
va créer la nouvelle structure et ajouter quelques enregistrements.
--- Structure de la table `client`
-CREATE TABLE `client` (
`id_client` int(10) unsigned NOT NULL auto_increment,
`identifiantclient` varchar(50) NOT NULL default ’’,
`motdepasseclient` varchar(50) NOT NULL default ’’,
`nomclient` varchar(50) NOT NULL default ’’,
`prenomclient` varchar(50) NOT NULL default ’’,
`emailclient` varchar(255) NOT NULL default ’’,
`telephoneclient` varchar(15) NOT NULL default ’’,
`datenaissanceclient` int(8) NOT NULL default ’0’,
`adresseclient` varchar(255) NOT NULL default ’’,
`villeclient` varchar(255) NOT NULL default ’’,
`codepostalclient` varchar(10) NOT NULL default ’’,
`paysclient` varchar(50) NOT NULL default ’’,
PRIMARY KEY (`id_client`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;
--- Contenu de la table `client`
-INSERT INTO `client` VALUES (1, ’amartin’, ’anne2de’, ’martin’,
’anne’, ’anne.martin@betaboutique.com’, ’0384465958’, 19821209,
’4 rue du haut’, ’Poligny’, ’39800’, ’france’);
INSERT INTO `client` VALUES (2, ’pdurand’, ’p8fas’,
’durand’, ’pierre’, ’pierre.durand@betaboutique.com’,
’0348759869’, 19760204, ’2 rue du bas’, ’Lons-le-Saunier’,
’39000’, ’france’);
INSERT INTO `client` VALUES (3, ’dboisson’, ’doia9dz’,
’boisson’, ’didier’, ’didier.boisson@betaboutique.com’,
’0345968574’, 19681212, ’3 rue de la fontaine’, ’L’’étoile’,
’39570’, ’france’);
Nous allons modifier notre Servlet ServletListeClientModele afin d’afficher la liste complète des clients et créer une
nouvelle Servlet nommée ServletListeIdentifiantClientModele, qui va afficher tous les identifiants et mots de passe des
utilisateurs. De même, les Servlets afficheront désormais les résultats dans une page Web grâce au PrintWriter.
...
try
{
//flux de sortie vers le navigateur
PrintWriter out=response.getWriter();
//preparation de la requete
requete=connection.prepareStatement("SELECT * FROM client ORDER BY
client.id_client");
//executer la requete
rs=requete.executeQuery();
//affichage
while(rs.next())
{
out.println("Client : "+rs.getInt("id_client")+""+rs.getString("nomclient")+"-"+rs.getString("prenomclient")+"-"+rs.getString
("emailclient"));
}
- 4-
© ENI Editions - All rigths reserved
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’exécution de la requete");
}
}
...
Le code de la nouvelle Servlet ServletListeIdentifiantClientModele est présenté cidessous. Le fichier web.xml contient la
déclaration de cette Servlet.
...
servletlisteclientmodele
betaboutique.servlets.client.ServletListe
ClientModele
servletlisteidentifiantclientmodele
betaboutique.servlets.client.ServletListe
IdentifiantClientModele
servletlisteclientmodele
/listeclient
servletlisteidentifiantclientmodele
/listeidentifiantclient
...
package betaboutique.servlets.client;
import
import
import
import
import
import
import
import
import
java.io.IOException;
java.io.PrintWriter;
java.sql.*;
javax.servlet.ServletContext;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
betaboutique.boiteoutils.OutilsBaseDeDonnees;
@SuppressWarnings("serial")
public class ServletListeIdentifiantClientModele extends
HttpServlet {
Connection connection=null;
PreparedStatement requete=null;
© ENI Editions - All rigths reserved
- 5-
ResultSet rs=null;
//parametres de connexion
String pilotejdbc=null;
String urlconnexionjdbc=null;
String utilisateurjdbc=null;
String motdepassejdbc=null;
//initialisation de la connexion
public void init()
{
ServletContext servletContext=getServletContext();
pilotejdbc=(String)servletContext.getInitParameter
("pilotejdbc");
urlconnexionjdbc=(String)servletContext.getInit
Parameter("urlconnexionjdbc");
utilisateurjdbc=(String)servletContext.getInit
Parameter("utilisateurjdbc");
motdepassejdbc=(String)servletContext.getInit
Parameter("motdepassejdbc");
try
{
//chargement du driver
Class.forName(pilotejdbc);
System.out.println("Pilote MySQL JDBC chargé");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
System.out.println("Erreur lors du chargmement du pilote");
}
try
{
//obtention de la connexion
connection = DriverManager.getConnection
(urlconnexionjdbc,utilisateurjdbc,motdepassejdbc);
System.out.println("Connexion opérationnelle");
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
}
//traitements
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try
{
//flux de sortie vers le navigateur
PrintWriter out=response.getWriter();
//preparation de la requete
requete=connection.prepareStatement("SELECT
id_client,identifiantclient,motdepasseclient FROM client
ORDER BY client.id_client");
//executer la requete
rs=requete.executeQuery();
//affichage
while(rs.next())
{
out.println("Client : "+rs.getInt
("id_client")+"-"+rs.getString("identifiantclient")+"-"+
- 6-
© ENI Editions - All rigths reserved
rs.getString("motdepasseclient"));
}
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’exécution de la requete");
}
}
//traitements
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
//fermeture des ressources
public void destroy(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
try
{
//fermeture
System.out.println("Connexion fermée");
}
catch (Exception e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(rs);
OutilsBaseDeDonnees.fermerConnexion(requete);
OutilsBaseDeDonnees.fermerConnexion(connection);
}
}
}
Ces deux exemples sont corrects et affichent les résultats souhaités. Par contre, le code est lourd. Il faut déclarer la
méthode init() et la méthode destroy() dans chaque Servlet afin de gérer une connexion à la base de données. Une
solution serait de déclarer la connexion dans une seule des Servlets. Ensuite, il faudrait déclarer une variable de type
objet qui serait insérée dans le descripteur de déploiement (web.xml) pour le partage.
Le code serait alors semblable à celuici :
...
connection = DriverManager.getConnection(urlconnexionjdbc,
utilisateurjdbc,motdepassejdbc);
ServletContext servletContext=servlet.getServletContext();
servletContext.setAttribute("connection",connection);
...
La variable connection est ainsi partagée et pourra être réutilisée par les autres Servlets avec le code suivant :
© ENI Editions - All rigths reserved
- 7-
...
ServletContext servletContext=servlet.getServletContext();
connection = (Connection)servletContext.getAttribute("connection");
...
Cette technique très utile présente un problème. Quelle est la Servlet qui doit lancer la création de la connexion à la
ressource ? Avec cette technique, la Servlet de connexion doit être la première appelée afin d’initialiser la connexion. Il
serait alors possible de déclencher cette Servlet de connexion avec le paramètre du fichier de
configuration de l’application web.xml.
Cette technique bien que fonctionnelle n’est pas très pratique et surtout illogique du point de vue de la
programmation dans le cas où l’utilisateur n’accède pas directement à la page d’accueil du site et ne déclenche donc
pas le fichier déclaré dans la balise .
Nous allons aborder dans le paragraphe suivant une solution à ce problème, les écouteurs.
- 8-
© ENI Editions - All rigths reserved
Écouteurs/listeners et cycle de vie
1. Présentation
Les événements étudiés jusqu’ici affectent tous la Servlet, puisqu’ils appellent des méthodes sur elle. Le conteneur
de Servlets gère plusieurs opérations intéressantes. Si un événement nous intéresse, nous créons une classe qui
implémente l’interface d’écoute de celuici et nous l’enregistrons avec le moteur de Servlets. La spécification 2.3 des
Servlets présente quatre interfaces d’écoute d’événements. Ces interfaces sont relativement simples et aucune ne
requiert l’implémentation de plus de trois méthodes.
2. Utilisation
L’interface javax.servlet.ServletContextListener
L’interface ServletContextListener écoute l’un des deux événements liés au contexte : lors de sa création et lors de sa
destruction. Cette interface sert à gérer l’initialisation et l’arrêt des services sousjacents, tels que les connexions à
des bases de données à partager par toutes les Servlets de l’application.
Voici un exemple d’une classe nommée InitialisationContext présente dans le paquetage boiteoutils qui implémente
cette interface, avec la première méthode contextInitialized(...) qui est déclenchée au chargement de l’application, et
la seconde méthode contextDestroyed(...), déclenchée lors de la suppression ou l’arrêt de l’application.
package betaboutique.boiteoutils;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class InitialisationContext implements ServletContextListener{
//action déclenchée lors du chargement du context
public void contextInitialized(ServletContextEvent event)
{
System.out.println("----------- Context initialisé -----------");
}
//action qui permet de détruire le filtre
public void contextDestroyed(ServletContextEvent event)
{
System.out.println("----------- Context détruit -----------");
}
//fin de la classe
}
Chaque méthode est appelée lorsque l’événement spécifié se produit et un objet d’événement est transmis en
paramètre. La deuxième étape consiste à installer cette classe écouteur dans le descripteur de déploiement. Pour
installer un écouteur au sein de l’application Web, nous déclarons cet écouteur en début de fichier web.xml après les
variables .
Chaque classe d’écoute est simplement déclarée dans un élément
betaboutique.boiteoutils.InitialisationContext
...
© ENI Editions - All rigths reserved
- 1-
Cette technique est donc idéale pour charger des ressources ou déclencher des traces ou fichiers journaux lors du
chargement des applications.
L’interface javax.servlet.ServletContextAttributeListener
Parmi les autres écouteurs, il existe l’interface javax.servlet.ServletContextAttributeListener qui permet de savoir quand
les attributs de contexte sont ajoutés, supprimés ou remplacés. Cette interface déclare trois méthodes qui sont
attributeAdded(), attributeRemoved() et attributeReplaced().
L’interface javax.servlet.http.HttpSessionListener
L’interface javax.servlet.http.HttpSessionListener écoute les événements liés à la création et à la destruction des
sessions. Cette interface déclare deux méthodes qui sont sessionCreated() et sessionDestroyed() et qui correspondent
à la création et destruction des sessions.
L’interface javax.servlet.http.HttpSession.AttributeListener
Enfin, la quatrième et dernière interface est javax.servlet.http.HttpSession.AttributeListener qui écoute les événements
d’ajout, de suppression ou de modification d’attributs de session. Cette interface déclare alors trois méthodes :
attributeAdded(), attributeRemoved() et attributeReplaced(), chacune prend comme paramètre une instance de
l’événement HttpSessionBindingEvent.
3. Mise en place d’une connexion partagée
Notre classe betaboutique.boiteoutils.InitialisationContext sera donc déclenchée au chargement de l’application avant le
premier déclenchement de Servlet, JSP ou pages. Nous allons créer notre connexion au SGBD dans cette classe et
partager cette connexion grâce au descripteur de déploiement. Dans la méthode de destruction du contexte, nous
allons mettre le code de libération des ressources. Nous aurons ainsi une seule connexion proprement partagée par
l’ensemble des pages de l’application.
package betaboutique.boiteoutils;
import
import
import
import
import
import
java.sql.Connection;
java.sql.DriverManager;
java.sql.SQLException;
javax.servlet.ServletContext;
javax.servlet.ServletContextEvent;
javax.servlet.ServletContextListener;
public class InitialisationContext implements ServletContextListener{
//parametres de connexion
Connection connection=null;
String pilotejdbc=null;
String urlconnexionjdbc=null;
String utilisateurjdbc=null;
String motdepassejdbc=null;
//action déclenchée lors du chargement du context
public void contextInitialized(ServletContextEvent event)
{
System.out.println("----------- Contexte initialisé -----------");
//lire le contexte
ServletContext servletContext=event.getServletContext();
pilotejdbc=(String)servletContext.getInitParameter
("pilotejdbc");
- 2-
© ENI Editions - All rigths reserved
urlconnexionjdbc=(String)servletContext.getInit
Parameter("urlconnexionjdbc");
utilisateurjdbc=(String)servletContext.getInit
Parameter("utilisateurjdbc");
motdepassejdbc=(String)servletContext.getInit
Parameter("motdepassejdbc");
try
{
//chargement du driver
Class.forName(pilotejdbc);
System.out.println("Pilote MySQL JDBC chargé");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
System.out.println("Erreur lors du chargmement du pilote");
}
try
{
//obtention de la connexion
connection = DriverManager.getConnection
(urlconnexionjdbc,utilisateurjdbc,motdepassejdbc);
//sauvegarder la connexion dans le context
servletContext.setAttribute("connection",connection);
System.out.println("Connexion opérationnelle");
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’établissement
de la connexion");
}
}
//action qui permet de détruire le filtre
public void contextDestroyed(ServletContextEvent event)
{
System.out.println("----------- Contexte détruit -----------");
try
{
//fermeture
System.out.println("Connexion fermée");
}
catch (Exception e)
{
e.printStackTrace();
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(connection);
}
}
//fin de la classe
}
Au chargement de notre application betaboutique, la connexion est alors déposée dans le contexte. Nous pouvons
désormais l’utiliser avec le code très simple suivant présent dans la méthode init() de la Servlet ServletListeClient.
© ENI Editions - All rigths reserved
- 3-
package betaboutique.servlets.client;
import
import
import
import
import
import
import
import
java.io.IOException;
java.io.PrintWriter;
java.sql.*;
javax.servlet.ServletContext;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
Connection connection=null;
PreparedStatement requete=null;
ResultSet rs=null;
//initialisation de la connexion
public void init()
{
ServletContext servletContext=getServletContext();
connection=(Connection)servletContext.getAttribute("connection");
}
...
}
Il existe une autre solution qui permet de charger une Servlet au démarrage de l’application plutôt que lors du
déclenchement de la première requête (URL). Ce paramètre est placé dans le fichier de configuration de l’application
et se nomme
…
…
1
Les Servlets doivent être chargées en commençant par l’instance dont le numéro est le plus faible. Les instances
sans numéro ou avec valeurs entières positives peuvent être chargées à tout moment lors du démarrage, sur
décision du conteneur.
Cette technique bien que pratique n’est pas très utilisée pour les accès aux bases de données, du fait de cette
notion de priorité, et surtout de l’absence de notion de fin ou destruction. En effet, il est facile de déclencher une
Servlet à la création du contexte qui va instancier une connexion au SGBD mais la fermeture correcte de la connexion
n’est pas certaine avec cette technique.
- 4-
© ENI Editions - All rigths reserved
Sources de données et pools de connexion
1. Présentation
La technique présentée précédemment avec plusieurs connexions, ou une connexion partagée, est fonctionnelle
dans le cadre d’un petit projet, mais n’est pas adaptée à des projets de plus grande envergure. En effet, dans les
premiers exemples, la connexion doit être établie avec chaque Servlet d’où facilement des problèmes en cas de
grande charge. Enfin, la seconde méthode utilise une simple et unique connexion partagée, qui devient très vite non
opérationnelle audelà de cent accès simultanées.
Pour répondre à ces problèmes, la spécification JDBC 2.0 a introduit la notion de sources de données. Désormais,
c’est la méthode recommandée pour établir une connexion à une base de données. L’interface DataSource fournit une
architecture plus souple que DriverManager pour la création et la gestion des connexions. Un objet DataSource permet
d’accéder à différentes bases de données en modifiant le code d’une application en un seul endroit. Cet objet permet
de masquer au programmeur les détails de programmation et d’accès, afin qu’il n’ait plus qu’à se préoccuper de l’URL,
de l’hôte, du port et de l’utilisateur SGBD.
Un point essentiel des pools de connexion et qu’ils permettent de créer à l’avance un certain nombre de connexions.
De cette façon, l’obtention d’une connexion est beaucoup plus rapide. La différence concerne la création et le
recyclage des connexions. La création et la libération d’une connexion pour chaque Servlet supposent un certain
nombre d’opérations peu rapides, à savoir l’allocation des ressources, la négociation de la connexion avec le SGBD,
l’authentification et enfin la libération des ressources. Une source de données est généralement obtenue en
effectuant une recherche dans un contexte. Un moyen d’associer un nom à une ressource est donc défini.
2. JNDI
Java dispose d’une interface neutre de connexion. Cette interface nommée JNDI (Java Naming and Directory Interface)
définit un ensemble de fonctions permettant d’accéder aux services de répertoires (noms). Pour utiliser un tel service,
nos programmes doivent utiliser l’API JNDI. Cette API permet d’accéder à différents services de nommage de façon
uniforme. Elle permet également d’organiser et rechercher des informations avec une technique de nommage. Cette
interface permet de gérer les connexions à des sources de données qui peuvent être des répertoires, des bases de
données mais aussi des annuaires (DNS, systèmes de fichiers, annuaire LDAP, NIS...).
3. Utilisation d’un objet DataSource
Un objet DataSource fournit toutes les méthodes permettant d’obtenir une connexion à une base de données par
l’intermédiaire d’un service de nommage JNDI. La méthode principale de l’objet DataSource est getConnection().
Toutefois, avant qu’un client puisse obtenir une connexion, le serveur doit créer cet objet, le placer dans le contexte
et l’associer à un nom. Pour obtenir une connexion à une source de données, le client JDBC n’a besoin d’aucune
information au niveau de la structure de la base de données.
L’obtention d’une source de données se déroule en deux étapes :
●
Il faut tout d’abord créer un objet InitialContext qui permet de rechercher dans le contexte de l’application.
●
Il faut ensuite appeler la méthode lookup() qui permet de rechercher la connexion dans le contexte JNDI.
La chaîne de caractères passée à la méthode lookup() est le nom associé à la source de données. Une fois la
connexion obtenue, le client peut l’utiliser de la même façon que si elle avait été fournie par un DriverManager.
Nous allons modifier notre classe InitialisationContext afin d’utiliser une source de données. Pour cela, nous allons
créer une instance de la classe InitialContext pour effectuer une recherche de la ressource nommée dans le contexte.
Le préfixe java:comp/env est utilisé pour rechercher une ressource se trouvant sur le même serveur que le
composant.
package betaboutique.boiteoutils;
import
import
import
import
import
import
javax.naming.Context;
javax.naming.InitialContext;
javax.servlet.ServletContext;
javax.servlet.ServletContextEvent;
javax.servlet.ServletContextListener;
javax.sql.DataSource;
© ENI Editions - All rigths reserved
- 1-
public class InitialisationContext implements ServletContextListener{
//action déclenchée lors du chargement du context
public void contextInitialized(ServletContextEvent event)
{
//initaliser le contexte
Context initCtx=null;
try
{
//initaliser le contexte
initCtx=new InitialContext();
if(initCtx==null)
{
throw new Exception ("Il n’y a pas de contexte !");
}
else
{
System.out.println("Contexte chargé !");
}
//se connecter au JNDI
Context envCtx=(Context) initCtx.lookup
("java:comp/env");
DataSource ds=(DataSource) envCtx.lookup
("jdbc_betaboutiquemysql");
if(ds==null)
{
throw new Exception ("Il n’y a pas de DataSource !");
}
else
{
System.out.println("DataSource chargée !");
}
//stocker la DataSource dans un attribut nommé
’’datasource’’ du context
ServletContext servletContext=event.getServletContext();
servletContext.setAttribute("datasource",ds);
}
catch(Exception e)
{
System.out.println(e.getMessage());
}
finally
{
try
{
//fermer le contexte
if(initCtx!=null)
{
initCtx.close();
System.out.println("initCtx correctement déchargé !");
}
}
catch(Exception e)
{
System.out.println("Erreur lors de initCtx !");
}
}
}
//action qui permet de détruire le filtre
public void contextDestroyed(ServletContextEvent event)
{
System.out.println("----------- Contexte détruit -----------");
try
{
//fermeture
System.out.println("DataSource fermée");
}
- 2-
© ENI Editions - All rigths reserved
catch (Exception e)
{
e.printStackTrace();
}
finally
{
}
}
//fin de la classe
}
Pour que cet exemple fonctionne, nous devons créer le descripteur de déploiement adapté. Cette configuration
permet d’associer le nom utilisé pour la recherche et le nom de la ressource JNDI.
Cette opération est réalisée en deux étapes :
●
Tout d’abord, dans le descripteur de déploiement, nous devons indiquer la ressource nommée
jdbc_betaboutiquemysql qui est une instance de javax.sql.DataSource. Cette déclaration est réalisée en fin de
fichier web.xml et possède la structure suivante :
...
DB Connection
jdbc_betaboutiquemysql
javax.sql.DataSource
Container
...
●
Ensuite, il faut paramétrer la connexion à la base de données par le pool de connexion. Pour cela, il faut
préciser au serveur Java EE les informations de connexions. Cette configuration peut être alors déclarée dans
le fichier /conf/server.xml de Tomcat ou mieux, dans le fichier spécifique à l’application. Dans notre cas, nous
insérons le code suivant dans le fichier /conf/Catalina/localhost/betaboutique.xml.
Une ressource JNDI est déclarée avec la partie
Les fichiers de l’application betaboutique.xml (ou server.xml) et web.xml permettent de définir les paramètres
nécessaires afin d’habiliter le serveur Java EE à établir une connexion avec la base de données. Dans le fichier
betaboutique.xml la source de données jdbc_betaboutiquemysql est déclarée et dans le fichier de configuration de
l’application web.xml, le lien avec cette connexion est réalisé.
Les différents paramètres sont présentés dans cette liste :
●
driverClassName : nom qualifié de la classe du pilote JDBC.
●
maxActive : nombre maximal de connexions actives dans le pool.
●
maxIdle : nombre maximal de connexions en attente dans le pool.
●
maxWait : délai maximal, en millisecondes d’attente d’une connexion. Audelà de ce délai, si aucune connexion
n’est disponible, une exception est lancée.
●
user : nom de l’utilisateur pour la base de données.
●
password : mot de passe de l’utilisateur pour l’accès à la base de données.
●
url : URL d’accès à la base de données.
●
validationQuery : requête de test envoyée à la base de données pour s’assurer qu’une connexion est valide.
Lorsque Tomcat démarre, il analyse le fichier server.xml et tous les fichiers de configuration, et crée une source de
données en fonction des paramètres contenus dans l’élément ResourceParams. Il la met ensuite à la disposition des
clients par l’intermédiaire d’une interface JNDI.
4. Mise en place
Nous
allons
maintenant
utiliser
un
pool
de
connexion
pour
fichier /conf/Catalina/host/betaboutique.xml possède la syntaxe suivante :
Le fichier web.xml possède la syntaxe simplifiée suivante :
betaboutique.boiteoutils.Initialisation
Context
servletlisteclientmodele
- 4-
© ENI Editions - All rigths reserved
notre
projet
betaboutique.
Le
betaboutique.servlets.client.Servlet
ListeClientModele
servletlisteidentifiantclientmodele
betaboutique.servlets.client.Servlet
ListeIdentifiantClientModele
servletlisteclientmodele
/listeclient
servletlisteidentifiantclientmodele
/listeidentifiantclient
DB Connection
jdbc_betaboutiquemysql
javax.sql.DataSource
Container
Enfin, la Servlet ServletListeClientModele possède le code cidessous. Désormais une seule ligne est nécessaire pour
obtenir une connexion à la source de données.
package betaboutique.servlets.client;
import java.io.IOException;
import java.io.PrintWriter;
import java.sql.*;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
import betaboutique.boiteoutils.OutilsBaseDeDonnees;
@SuppressWarnings("serial")
public class ServletListeClientModele extends HttpServlet {
//variables de la classe
DataSource ds=null;
Connection connection=null;
PreparedStatement requete=null;
ResultSet rs=null;
//traitements
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer la datasource du plug-in dans un attribut
présent dans le contexte de la servlet
ds=(DataSource)getServletContext().getAttribute("datasource");
try
{
//ouvrir une connexion
connection=ds.getConnection();
//flux de sortie vers le navigateur
PrintWriter out=response.getWriter();
//preparation de la requete
requete=connection.prepareStatement("SELECT * FROM
client ORDER BY client.id_client");
//executer la requete
rs=requete.executeQuery();
© ENI Editions - All rigths reserved
- 5-
//affichage
while(rs.next())
{
out.println("Client : "+rs.getInt
("id_client")+"-"+rs.getString("nomclient")+"-"+
rs.getString("prenomclient")+"-"+rs.getString("emailclient"));
}
}
catch (SQLException e)
{
e.printStackTrace();
System.out.println("Erreur lors de l’exécution de la requete");
}
finally
{
OutilsBaseDeDonnees.fermerConnexion(rs);
OutilsBaseDeDonnees.fermerConnexion(requete);
OutilsBaseDeDonnees.fermerConnexion(connection);
ds=null;
}
}
//traitements
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
Le code JDBC est identique aux exemples précédents. Le client ne sait pas qu’il obtient une connexion provenant d’un
pool. Il continue d’utiliser directement la même interface Connection. La méthode close() de l’objet Connection est
toujours appelée, mais elle ne ferme pas physiquement la connexion, elle la remet à la disposition du pool. Du point
de vue du client, il n’y a pas de différence entre les connexions provenant d’un pool et celles créées directement.
Cette technique peut être employée dans des JSP ou des Servlets.
Cette technique est plus simple, fiable, et adaptée aux projets de grandes tailles. En effet, il faut déclarer la source
de données dans le fichier de configuration de l’application (server.xml ou nomapplication.xml), préciser dans le fichier
de description de l’application (web.xml) le lien vers cette ressource, et enfin réaliser une classe qui gère cette
connexion indépendamment du SGBD utilisé.
Ainsi, il n’y a plus qu’à se soucier de la libération des ressources, toutes les bases de données compatibles JDBC
peuvent être utilisées sans toucher au code source et il est possible d’optimiser les accès de façon très précise avec
les attributs de la balise listearticle=new ArrayList();
/***********************************************************
* constructeur
***********************************************************/
public ArticleModele(DataSource ds)
{
//récupérer la DataSource de la servlet
this.ds=ds;
}
- 4-
© ENI Editions - All rigths reserved
/***********************************************************
* liste complète des articles
***********************************************************/
public ArrayList ListeArticle()
{
PreparedStatement requete=null;
try
{
//ouvrir une connexion
connection=ds.getConnection();
//enregistrements
requete=connection.prepareStatement("SELECT * FROM
article ORDER BY article.nomarticle");
rs=requete.executeQuery();
//exécuter la requête
if(rs!=null)
{
//stocker tous les articles dans une liste
while(rs.next())
{
//créer un objet article
Article article=new Article();
//renseigner l’objet article avec ses accesseurs
if(rs.getString("id_article")==null)
article.setId_article("0");
else article.setId_article(rs.getString
("id_article"));
if(rs.getString("nomarticle")==null)
article.setNomarticle("");
else article.setNomarticle(rs.getString
("nomarticle"));
if(rs.getString("descriptionarticle")==null)
article.setDescriptionarticle("")
else article.setDescriptionarticle(rs.getString
("descriptionarticle"));
if(rs.getString("prixarticle")==null)
article.setPrixarticle("0");
else article.setPrixarticle(rs.getString
("prixarticle"));
if(rs.getString("datearticle")==null)
article.setDatearticle("0");
else article.setDatearticle(rs.getString
("datearticle"));
if(rs.getString("photoarticle")==null)
article.setPhotoarticle("");
else article.setPhotoarticle(rs.getString
("photoarticle"));
if(rs.getString("vignettearticle")==null)
article.setVignettearticle("");
else article.setVignettearticle(rs.getString
("vignettearticle"));
if(rs.getString("etatarticle")==null)
article.setEtatarticle("0");
else article.setEtatarticle(rs.getString
("etatarticle"));
//stocker l’objet article dans la liste desarticles
listearticle.add((Article)article);
}
}
}
catch(Exception e)
{
System.out.println("Erreur dans la classe
ArticleModele.java fonction ListeArticle");
}
© ENI Editions - All rigths reserved
- 5-
finally
{
try
{
//fermer la connexion
if(rs!=null)OutilsBaseDeDonnees.fermerConnexion(rs);
if(requete!=null)OutilsBaseDeDonnees.fermerConnexion(requete);
if(connection!=null)OutilsBaseDeDonnees.fermerConnexion
(connection);
}
catch(Exception ex)
{
System.out.println("Erreur dans la classe
ArticleModele.java fonction ListeArticle");
}
}
//retourner la liste des articles
return listearticle;
}
//fin de la classe
}
Nous allons désormais déclarer notre Servlet contrôleur dans le fichier de configuration de l’application.
urlapplication
http://localhost:8080/betaboutiquemvc/
betaboutique.boiteoutils.Initialisation
Context
servletlistearticles
betaboutique.servlets.ServletListe
Articles
servletlistearticles
/listearticles
DB Connection
jdbc_betaboutiquemysql
javax.sql.DataSource
Container
Nous retrouvons la connexion à la base de données avec le listener pour déclencher la connexion au chargement du
contexte, la déclaration de la Servlet contrôleur et une variable globale utilisée pour référencer l’URL de l’application
(pour les images, chemins divers, feuilles de style et liens).
Il ne reste plus qu’à développer la page listearticles.jsp. Cette page très simple ne gère que l’affichage de la collection
d’objets. Nous remarquons que le principe MVC requiert beaucoup de fichiers mais le code est bien découpé et très
simple (traitement, gestion de la persistance des données et affichage).
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
<%@page import="betaboutique.boiteoutils.Article;"%>
- 6-
© ENI Editions - All rigths reserved
LISTE DES ARTICLES
<%
//context de l’application
String urlapplication=getServletContext().getInitParameter("urlapplication");
//récupérer les articles dans la requête
ArrayList listearticles=(ArrayList)request.getAttribute("listearticles");
%>
Liste des articles de la boutique
Id article Nom Description
Prix Date Vignette ");
out.println(""+article.getId_article()+" ");
out.println(""+article.getNomarticle()+" ");
out.println(""+article.getDescriptionarticle()+" ");
out.println(""+article.getPrixarticle()+" Euros ");
out.println(""+article.getDatearticle()+" ");
out.println("
L’arborescence du projet à cette étape est la suivante :
© ENI Editions - All rigths reserved
- 7-
Nous déclenchons alors l’URL : http://localhost:8080/betaboutiquemvc/listearticles
Le résultat produit est correct. Nous allons cependant apporter quelques améliorations à la classe modèle afin
d’afficher correctement la date, la catégorie associée à l’article et gérer l’état de l’article (en ligne ou pas) et les
recherches sur le nom ou la description de l’article.
3. Optimisations
a. Informations liées et mise en forme
Notre service de liste des articles est désormais fonctionnel mais il manque quelques optimisations qui permettent
de proposer un service professionnel. Dans notre cas, nous devons d’abord développer une fonction pour mettre la
date au format français (aaaammjj devient jj/mm/aaaa).
Il manque également l’affichage de la catégorie de l’article. Cette information est liée à la table categorie par
l’intermédiaire de la clé externe id_categorie. Ces fonctionnalités sont utilisées dans la majorité des projets que ce
soient des catégories associées, des gestions de dates, le découpage de chaînes de caractères...
Ces optimisations sont liées aux données AVANT ou APRES insertion dans la base de données. De même, elles sont
- 8-
© ENI Editions - All rigths reserved
déclenchées par la plupart des classes modèles. Afin d’utiliser un système souple et facilement maintenable, nous
allons développer une classe nommée Modele qui sera placée en haut de l’arbre d’héritage des modèles. Ainsi la
classe modèle ArticleModele hérite de la classe principale Modele qui contient les fonctionnalités générales et
communes (principe d’héritage ).
Nous allons donc ajouter pour le moment deux fonctions à la classe Modele à savoir : miseEnFormeDate() qui permet
de mettre la date au format français et la fonction getNomCategorieArticle() qui permet de retourner le nom d’une
catégorie en fonction de son identifiant. Dans cette classe, nous utilisons un autre nom de connexion (connection1 à
la place de connection) et également un autre nom de ResultSet (rs1) afin d’éviter d’éventuels conflits entre les
objets Connection et ResultSet de la classe fille (fermeture ou accès simultanés) et ceux de la classe mère.
Le déclenchement du constructeur de la classe mère se fera avec la méthode super() dans le constructeur des
classes filles, et l’utilisation des méthodes de la classe mère se fera également avec le mot clé super. Nous allons
modifier le JavaBean Article afin d’ajouter un attribut pour le nom de la catégorie. Une dernière modification est
réalisée dans la requête de liste des articles afin d’afficher uniquement les articles validés en administration
(etatarticle=1).
package betaboutique.boiteoutils;
@SuppressWarnings("serial")
public class Article implements java.io.Serializable {
...
private String nomcategoriearticle=null;
...
package betaboutique.modeles;
import
import
import
import
import
java.sql.Connection;
java.sql.PreparedStatement;
java.sql.ResultSet;
javax.sql.DataSource;
betaboutique.boiteoutils.OutilsBaseDeDonnees;
public class Modele
{
//variables de classe
DataSource ds=null;
Connection connection1=null;
ResultSet rs1=null;
/***********************************************************
* constructeur
***********************************************************/
public Modele(DataSource ds)
{
//récupérer la DataSource de la servlet
this.ds=ds;
}
/***********************************************************
* mise en forme de la date (aaaammjj -> jj/mm/aaaa)
***********************************************************/
© ENI Editions - All rigths reserved
- 9-
public String miseEnFormeDate(String date)
{
if(date.length()>=4)
{
String jour=date.substring((date.length()-2),date.length());
String mois=date.substring((date.length()-4),(date.length()-2));
String annee=date.substring(0,4);
date=jour+"/"+mois+"/"+annee;
}
//retourner la date
return date;
}
/***********************************************************
* récupérer le nom de la catégorie de l’article
***********************************************************/
public String getNomCategorieArticle(String id_categorie)
{
String nomcategorie=null;
//statement
PreparedStatement requete=null;
try
{
//ouvrir une connexion
connection1=ds.getConnection();
requete=connection1.prepareStatement("SELECT * FROM
categorie WHERE categorie.id_categorie=?");
requete.setString(1,(String)id_categorie);
rs1=requete.executeQuery();
//exécuter la requête
if(rs1!=null)
{
//stocker tous les types de médias dans une liste
if(rs1.next())
{
if(rs1.getString("nomcategorie")==null)nomcategorie="";
else nomcategorie=rs1.getString("nomcategorie");
}
}
}
catch(Exception e)
{
System.out.println("Erreur dans la classe Modele.java
fonction getNomCategorieArticle");
}
finally
{
try
{
//fermer la connexion
if(rs1!=null)OutilsBaseDeDonnees.fermerConnexion(rs1);
if(requete!=null)OutilsBaseDeDonnees.fermerConnexion(requete);
if(connection1!=null)OutilsBaseDeDonnees.fermerConnexion
(connection1);
}
catch(Exception ex)
{
System.out.println("Erreur dans la classe
Modele.java fonction getNomCategorieArticle");
}
}
//retourner le nom
return nomcategorie;
}
//fin de la classe
}
- 10 -
© ENI Editions - All rigths reserved
...
public class ArticleModele extends Modele
{
...
if(rs.getString("datearticle")==null)article.setDatearticle("0");
else article.setDatearticle(super.miseEnFormeDate(rs.getString
("datearticle")));
if(rs.getString("id_categorie")==null)article.setNomcategoriearticle("");
else
article.setNomcategoriearticle(super.getNomCategorieArticle(rs.getString
("id_categorie")));
...
//fin de la classe
}
<%@ page language="java" contentType="text/html;
charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
<%@page import="betaboutique.boiteoutils.Article;"%>
LISTE DES ARTICLES
<%
//context de l’application
String urlapplication=getServletContext().getInitParameter
("urlapplication");
//récupérer les articles dans la requête
ArrayList listearticles=(ArrayList)request.getAttribute
("listearticles");
%>
Liste des articles de la boutique
Id article Nom Description
Prix Date Vignette
Catégorie ");
out.println(""+article.getId_article()+" ");
out.println(""+article.getNomarticle()+" ");
out.println(""+article.getDescriptionarticle()+" ");
out.println(""+article.getPrixarticle()+" Euros ");
out.println(""+article.getDatearticle()+" ");
out.println(""+article.getNomcategoriearticle()+" ");
out.println("");
}
%>
© ENI Editions - All rigths reserved
- 11 -
b. Gestion des recherches
Nous allons améliorer le service de liste des articles afin de réaliser des recherches sur le nom du DVD et sur sa
description. Pour cela, nous ajoutons un petit formulaire HTML en début de fichier avec un champ de saisie et un
bouton de validation. La Servlet contrôleur est légèrement modifiée pour lire et renvoyer la recherche effectuée.
Enfin, la requête SQL de la classe modèle est modifiée avec l’instruction SQL LIKE.
...
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%@ page import="java.util.ArrayList" %>
<%@page import="betaboutique.boiteoutils.Article;"%>
LISTE DES ARTICLES
<%
//context de l’application
String urlapplication=getServletContext().getInitParameter
("urlapplication");
//récupérer les articles dans la requête
ArrayList listearticles=(ArrayList)request.getAttribute("listearticles");
//récupérer la recherche de l’utilisateur
String recherche=(String)request.getAttribute("recherche");
%>
...
package betaboutique.servlets;
import
import
import
import
import
import
import
import
java.io.IOException;
java.util.ArrayList;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
javax.sql.DataSource;
betaboutique.modeles.ArticleModele;
@SuppressWarnings("serial")
public class ServletListeArticles extends HttpServlet {
//variables de la classe
DataSource ds=null;
//traitements
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer la datasource du plug-in dans un attribut
présent dans le contexte de la servlet
ds=(DataSource)getServletContext().getAttribute("datasource");
//créer le modèle
- 12 -
© ENI Editions - All rigths reserved
ArticleModele articlemodele=new ArticleModele(ds);
//redonner la datasource
this.ds=null;
//recherche
String recherche=(String)request.getParameter("recherche");
//retourner la liste des articles
ArrayList listearticles=(ArrayList)
articlemodele.ListeArticle(recherche);
request.setAttribute("listearticles",listearticles);
request.setAttribute("recherche",recherche);
//retourner sur la page d’affichage des articles
getServletContext().getRequestDispatcher
("/vues/article/listearticles.jsp").forward(request, response);
}
//traitements
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
doGet(request, response);
}
}
...
//ouvrir une connexion
connection=ds.getConnection();
//enregistrements
String requete="SELECT * FROM article WHERE etatarticle=1";
if(recherche!=null && !recherche.equalsIgnoreCase(""))
{
requete+=" AND (nomarticle LIKE ? OR descriptionarticle LIKE ?)";
}
//preparer la requete
requetea=connection.prepareStatement(requete);
//recherche
if(recherche!=null && !recherche.equalsIgnoreCase(""))
{
requetea.setString(1,(String)"%"+recherche+"%");
requetea.setString(2,(String)"%"+recherche+"%");
}
//exécuter la requete
rs=requetea.executeQuery();
...
La recherche est désormais fonctionnelle. Nous pouvons essayer avec la chaîne ’’balance’’ qui dans ce cas va porter
sur le nom de l’article ou avec la chaîne ’’nathalie baye’’ qui va porter sur la description (acteurs). Cette requête est
opérationnelle mais très lente lors de l’utilisation de nombreux enregistrements et surtout sur des champs de
grande taille comme la description. Nous pouvons optimiser ce système avec l’utilisation d’expressions régulières en
SQL.
...
//ouvrir une connexion
connection=ds.getConnection();
//enregistrements
String requete="SELECT * FROM article WHERE etatarticle=1";
if(recherche!=null && !recherche.equalsIgnoreCase(""))
{
requete+=" AND (nomarticle REGEXP ? OR
descriptionarticle REGEXP ?)";
}
//preparer la requete
requetea=connection.prepareStatement(requete);
//recherche
if(recherche!=null && !recherche.equalsIgnoreCase(""))
{
requetea.setString(1,(String)"("+recherche+")");
© ENI Editions - All rigths reserved
- 13 -
requetea.setString(2,(String)"("+recherche+")");
}
//exécuter la requete
rs=requetea.executeQuery();
...
Il existe une dernière technique de recherche plus poussée qui permet de réaliser des affichages précis à la
manière des moteurs de recherches. Cette instruction SQL nommée MATCH permet de faire des pondérations (ajout
d’opérateurs). Par contre, il est parfois nécessaire de réaliser un index FULLTEXT sur les champs de recherche pour
améliorer le temps d’exécution. Dans notre exemple, nous ne modifions à chaque fois que la classe modèle (d’où
l’intérêt du MVC). Nous pouvons ainsi apporter des améliorations au site sans coder à nouveau l’ensemble d’une
fonctionnalité.
Voici le code modifié de la requête avec la clause MATCH.
...
//ouvrir une connexion
connection=ds.getConnection();
//enregistrements
String requete="SELECT * FROM article WHERE etatarticle=1";
if(recherche!=null && !recherche.equalsIgnoreCase(""))
{
requete+=" AND (MATCH (nomarticle) AGAINST (? IN BOOLEAN MODE)
OR MATCH (descriptionarticle) AGAINST (? INBOOLEAN MODE))";
}
//preparer la requete
requetea=connection.prepareStatement(requete);
//recherche
if(recherche!=null && !recherche.equalsIgnoreCase(""))
{
requetea.setString(1,(String)recherche);
requetea.setString(2,(String)recherche);
}
//exécuter la requete
rs=requetea.executeQuery();
...
Avec cette dernière requête, nos recherches sont très puissantes. Il est possible d’utiliser l’opérateur + pour
indiquer que le mot à la suite du signe doit être présent dans une ligne des enregistrements. L’opérateur indique
que le mot à la suite du signe ne doit pas être présent dans une ligne des enregistrements. L’opérateur * permet
de faire des recherches sur des portions de mots. L’opérateur ’’ (guillemets) permet de faire des recherches exactes
dans un champ (ex : citation entre guillemets).
Nous pouvons tester ces opérateurs avec les recherches suivantes :
●
nathalie baye : tous les articles avec l’actrice Nathalie Baye dans le titre ou la description seront retrouvés.
●
baye : tous les articles avec l’actrice Baye dans le titre ou la description seront retrouvés.
●
baye léotard : les articles contenant Nathalie Baye mais pas Philippe Léotard seront retrouvés.
●
pier* : les articles contenant le terme pier (Pierre Palmade, Pierre Desproges et JeanPierre Melville) seront
retrouvés.
Ces exemples permettent de mettre en évidence l’utilisation d’une classe modèle et de requêtes SQL
évoluées par rapport à un système de persistance (Hibernate ou autre). En effet, le code est parfois plus
long à écrire mais les requêtes sont optimisées et utilisent TOUTES les instructions et la puissance du langage
SQL.
- 14 -
© ENI Editions - All rigths reserved
Classe modèle
1. Présentation
L’affichage des articles et la recherche sont désormais opérationnels. Nous allons maintenant développer une classe
modèle complète qui permet de gérer toutes les opérations d’administration pour un service (gestion des articles) et
qui servira d’exemple pour la construction des autres services de la boutique.
La classe modèle aura donc une fonction pour lister tous les articles avec des recherches, une fonction pour récupérer
toutes les informations d’un article précis, une fonction pour modifier un article, une fonction pour la création et enfin,
une fonction pour la suppression.
Nous allons également gérer la pagination dans les listes et les recherches avec des contraintes sur les types (ex :
recherche sur le nom ou sur la description).
2. Mise en place
Nous commençons par créer une nouvelle Servlet nommée ServletGestionArticles. Cette Servlet permettra de réaliser
toutes les opérations sur les articles en administration. Sa définition dans le fichier web.xml est présentée cidessous.
...
servletgestionarticles
betaboutique.servlets.ServletGestion
Articles
servletgestionarticles
/admin/gestionarticles/*
...
Nous retrouvons la déclaration de la Servlet de gestion des articles en administration (/admin/gestionarticles/*).
Ensuite, il faut réaliser le code du contrôleur (Servlet) afin de préparer la gestion des articles.
package betaboutique.servlets;
import
import
import
import
import
import
import
import
java.io.IOException;
java.util.ArrayList;
javax.servlet.ServletException;
javax.servlet.http.HttpServlet;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
javax.sql.DataSource;
betaboutique.modeles.ArticleModele;
@SuppressWarnings("serial")
public class ServletGestionArticles extends HttpServlet {
//variables de la classe
DataSource ds=null;
//traitements
public void doGet(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
//récupérer la datasource du plug-in dans un attribut
présent dans le contexte de la servlet
ds=(DataSource)getServletContext().getAttribute("datasource");
© ENI Editions - All rigths reserved
- 1-
//créer le modèle
ArticleModele articlemodele=new ArticleModele(ds);
//redonner la datasource
this.ds=null;
//action a réaliser (liste des articles, consultation,
modification, suppression ou création)
String action=(String)request.getParameter("action");
//action par défaut (liste)
if(action==null || action.equalsIgnoreCase(""))
{
action="liste";
}
//liste des articles
if(action.equals("liste"))
{
//recherche
String typerecherche=(String)request.getParameter("typerecherche")
String recherche=(String)request.getParameter("recherche");
//informations pour les tris et l’affichage paginé
String pagecourante=(String)request.getParameter("p");
String nomtri=(String)request.getParameter("s");
String tri=(String)request.getParameter("tri");
//valeurs par défaut
if(pagecourante==null)pagecourante="0";
if(nomtri==null)nomtri="id_article";
if(tri==null)tri="ASC";
String maxparpage="5";
//retourner la liste des articles
ArrayList listearticles=(ArrayList)
articlemodele.ListeArticleAdmin(pagecourante,nomtri,
tri,maxparpage,typerecherche,recherche);
//tri en cours
//changer l’ordre de tri
if(tri.equals("ASC"))tri="DESC";
else if(tri.equals("DESC"))tri="ASC";
request.setAttribute("nomtri",nomtri);
request.setAttribute("tri",tri);
//les recherches
request.setAttribute("typerecherche",typerecherche);
request.setAttribute("recherche",recherche);
//retourner le maximum d’enregistrement par page
request.setAttribute("maxparpage",(String)
articlemodele.getMaxparpage());
//retourner la page courante de l’affichage
request.setAttribute("pageencours",pagecourante);
//retourner le nombre d’enregistrement trouvé
request.setAttribute("compteurenregistrement",
articlemodele.getCompteurenregistrement());
//retourner le nombre total d’enregistrement possibles
request.setAttribute("totalenregistrement",
articlemodele.getTotalenregistrement());
//retourner la liste des articles paginés
request.setAttribute("listearticles",listearticles);
//vider par sécurité
listearticles=null;
//retourner sur la page d’affichage des articles
en administration
getServletContext().getRequestDispatcher("/admin/vues/
article/listearticles.jsp").forward(request, response);
}
}
//traitements
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException
{
- 2-
© ENI Editions - All rigths reserved
doGet(request, response);
}
}
Par défaut, la Servlet réalise un affichage sous forme de liste paginée des articles. Nous retrouvons plusieurs
paramètres qui correspondent à la pagination, aux recherches et aux calculs d’affichage.
Cidessous, la fonction de liste de la classe modèle ArticleModele.
...
public class ArticleModele extends Modele
{
...
/***************************************************************************
* liste complete des articles
****************************************************************************/
public ArrayList ListeArticleAdmin(String pagecourante,String nomtri,
String tri,
String maxparpage,String typerecherche,String recherche)
{
//informations pour la pagination
this.maxparpage=Integer.parseInt(maxparpage);
this.position=this.maxparpage*Integer.parseInt(pagecourante);
this.compteurenregistrement=0;
PreparedStatement requetea=null,requeteb=null;
String requete=null;
try
{
//ouvrir une connexion
connection=ds.getConnection();
//requete de comptage pour la pagination
requete="SELECT COUNT(DISTINCT(article.id_article)) AS
totalenregistrement FROM article WHERE 1";
if((typerecherche!=null && !typerecherche.equalsIgnoreCase("")) &&
(recherche!=null && !recherche.equalsIgnoreCase("")))requete+=" AND
"+typerecherche+" LIKE ? ";
//compter combien on a d’enregistrement sans les conditions de
pagination
requetea=connection.prepareStatement(requete);
if((typerecherche!=null && !typerecherche.equalsIgnoreCase("")) &&
(recherche!=null && !recherche.equalsIgnoreCase("")))requetea.setString(1,
(String)"%"+recherche+"%");
rs=requetea.executeQuery();
//exécuter la requête
if(rs!=null)
{
//total d’enregistrements trouves
if(rs.next())
{
if(rs.getString("totalenregistrement")!=null) this.
totalenregistrement=Integer.parseInt(rs.getString("totalenregistrement"));
}
}
//enregistrements avec pagination
requete="SELECT * FROM article WHERE 1";
if((typerecherche!=null && !typerecherche.equalsIgnoreCase("")) &&
(recherche!=null && !recherche.equalsIgnoreCase("")))requete+=" AND
"+typerecherche+" LIKE ? ";
requete+=" ORDER BY "+nomtri+" "+tri+" LIMIT "+this.position+",
"+this.maxparpage+"";
requeteb=connection.prepareStatement(requete);
if((typerecherche!=null && !typerecherche.equalsIgnoreCase("")) &&
(recherche!=null && !recherche.equalsIgnoreCase("")))requeteb.setString(1,
(String)"%"+recherche+"%");
rs=requeteb.executeQuery();
//executer la requete
if(rs!=null)
© ENI Editions - All rigths reserved
- 3-
{
//stocker tous les articles dans une liste
while(rs.next())
{
//un enregistrement de plus
this.compteurenregistrement++;
//creer un objet article
Article article=new Article();
//renseigner l’objet article avec ses accesseurs
if(rs.getString("id_article")==null)article.setId_article("0");
else article.setId_article(rs.getString("id_article"));
if(rs.getString("nomarticle")==null)article.setNomarticle("");
else article.setNomarticle(rs.getString("nomarticle"));
if(rs.getString("descriptionarticle")==null)article.
setDescriptionarticle("");
else article.setDescriptionarticle(rs.getString
("descriptionarticle"));
if(rs.getString("prixarticle")==null)article.setPrixarticle("0");
else article.setPrixarticle(rs.getString("prixarticle"));
if(rs.getString("datearticle")==null)article.setDatearticle("0");
else article.setDatearticle(super.miseEnFormeDate(rs.getString
("datearticle")));
if(rs.getString("photoarticle")==null)article.setPhotoarticle("");
else article.setPhotoarticle(rs.getString("photoarticle"));
if(rs.getString("vignettearticle")==null)article.
setVignettearticle("");
else article.setVignettearticle(rs.getString("vignettearticle"));
if(rs.getString("etatarticle")==null)article.setEtatarticle("0");
else article.setEtatarticle(rs.getString("etatarticle"));
if(rs.getString("id_categorie")==null)article.
setNomcategoriearticle("");
else article.setNomcategoriearticle(super.getNomCategorieArticle
(rs.getString("id_categorie")));
//stocker l’objet article dans la liste des articles
listearticle.add((Article)article);
}
}
}
catch(Exception e)
{
System.out.println("Erreur dans la classe ArticleModele.java fonction
ListeArticleAdmin");
}
finally
{
try
{
//fermer la connexion
if(rs!=null)OutilsBaseDeDonnees.fermerConnexion(rs);
if(requetea!=null)OutilsBaseDeDonnees.fermerConnexion(requetea);
if(requeteb!=null)OutilsBaseDeDonnees.fermerConnexion(requeteb);
if(connection!=null)OutilsBaseDeDonnees.fermerConnexion(connection);
}
catch(Exception ex)
{
System.out.println("Erreur dans la classe ArticleModele.java
fonction ListeArticleAdmin");
}
}
//retourner la liste des articles
return listearticle;
}
...
//fin de la classe
}
La fonction est plus complexe car elle permet de gérer la pagination complète du système avec le nombre
d’enregistrements, la recherche et les tris. Il ne reste plus qu’à réaliser le codage de la vue listearticles.jsp
(/admin/vues/articles/listearticles.jsp). Cette vue est composée de plusieurs pages JSPF pour la mise en page et la
- 4-
© ENI Editions - All rigths reserved
pagination.
<%@ page import="java.util.ArrayList" %>
<%@ page import="betaboutique.boiteoutils.Article" %>
<%
//url de l’application
String urlapplication=(String)getServletContext().getInit
Parameter("urlapplication");
//liste des articles
ArrayList listearticles=(ArrayList)request.getAttribute
("listearticles");
//action a appeler
String action=urlapplication+"admin/gestionarticles";
%>
<%@ include file="../outils/entete.jspf" %>
<%@ include file="../outils/pagination.jspf" %>
Enregistrements "+positiondebut+""+positionfin+" sur "+totalenregistrement+" (Page :
"+pagesuivante+" sur "+maxdepage+")");
//afficher les boutons précédents que si nécessaire
if(!pageencours.equals("0"))
{
pagination.append(" /admin/gestionarticles/* .
(ex :
/admin/gestionarticles?
action=modifier&id_article=4).
3. Optimisation avec JavaScript
La partie administration commence à être fournie en terme de fonctionnalités. Nous allons utiliser à cette étape du
développement le langage JavaScript pour augmenter l’ergonomie de l’ensemble. Pour commencer, nous allons ajouter
un fichier JavaScript qui servira de boîte à outils tout au long du projet (découpage de chaînes, messages d’alertes...).
Pour cela, nous utilisons le code suivant à enregistrer sous le nom : /javascript/boiteoutils.js.
//supprimer un article en administration
function confirmerSuppressionArticle(id_article)
{
if(confirm("Voulez-vous supprimer cet article ?"))
{
chemin="gestionarticles?action=supprimer&id_article="+id_article;
document.location.href=chemin;
}
else
{
return;
}
}
Le code contient pour le moment uniquement une fonction pour valider les confirmations de suppression. Il reste à
inclure ce fichier dans l’entête JSPF avec la ligne suivante :
Administration - BetaBoutique
.
- 6-
© ENI Editions - All rigths reserved
Une application déployée avec Tomcat est configurée par l’intermédiaire d’un fichier nommé web.xml. Une syntaxe
possible de ce fichier est la suivante :
Panier
Policier et Thriller