Par défaut, c'est le fichier index.html qui est retourné au client. C'est ici une page statique.

Dans sa version actuelle, ce fichier contient le lien suivant : <a href="servlet/ldv?action=Hello"/a>Hello World, qui fait référence à la servlet (programme java côté serveur), selon les instructions déclarées dans web.xml (voir section suivante).

Par défaut, le nom de l'application est le nom de son répertoire sous webapps, ici donc ce sera ldvSimple (qui est également le nom de l'archive .war).

Lancement de l'application (par défault tomcat écoute sur le port 8080) :

http://localhost:8080/ldvSimple

Figure 4. Test de l'application ldvSimple

Cliquez sur le lien Exemple 1, vous devriez voir :

Figure 5. Résultat de l'appel de la servlet

La page HTML propose deux façons de soliciter le programme java côté serveur (la servlet LdvSimpleServlet) :

Dans les deux cas, le client fait référence au modèle URL (url-pattern) défini dans le fichier web.xml, voir plus loin (Fichier de déploiement web.xml).

L'URL pointe donc indirectement vers un programme java, nommé servlet, que nous étudierons prochainement.

Demander la liste des applications

http://localhost:8080/manager/list

Retour :

OK - Applications listées pour l'hôte virtuel (virtual host) localhost
/admin:running:0:../server/webapps/admin
/examples:running:0:examples
/tomcat-docs:running:0:/home/kpu/tomcat41/webapps/tomcat-docs
/ldvSimple:running:0:/home/kpu/tomcat41/webapps/ldvSimple

Nous constatons que 4 applications sont actives.

Recharger une application

http://localhost:8080/manager/reload?path=/ldvSimple

Retour

OK - Application rechargée au chemin de contexte /ldvSimple

Attention, le fichier web.xml de l'application n'est pas relu dans ce cas là.

D'autre fonctions sont disponibles, et qui s'utilisent avec la même syntaxe que reload, telles que stop, start. Voir la documentation en ligne pour plus d'information.

Une nouvelle interface HTML a vu le jour, pourquoi s'en priver ?

http://localhost:8080/manager/html/list

Figure 6. Gestionnaire d'applications. http://localhost:8080/manager/html/list

Une servlet est une classe Java particulière qui hérite d'une classe spécialisée (HttpServlet) elle même un composant du paquetage livré avec Tomcat : <TOMCAT_HOME>/common/lib/servlet-api.jar.

Les servlets utilisent les classes et interfaces de deux packages :

Javax.servlet      // support de servlets génériques 
Javax.servlet.http // extension avec fonctionnalités spécifiques http

Le x de javax : Une extension standard.

Une servlet n'a pas de main, mais une méthode nommée service qui appelle (automatiquement) une méthode particulière (doGet, doPost, doPut, doDelete,...), selon la nature de la requête (HTTP GET, HTTP POST, HTTP PUT, HTTP DELETE).

Figure 7. Cas d'utilisation système d'une servlet

Le développeur doit donc redéfinir ces méthodes. Typiquement, il peut se contenter de redéfinir les méthodes doGet et doPost (comme dans l'exemple ci-dessous).

Figure 8. Graphe d'héritage d'une servlet (diagramme de classes UML)

La méthode service transmet aux méthodes doXXXX deux paramètres : un objet de type HttpServletRequest qui détient des informations précieuses sur le client émetteur de la requête, et un objet de type HttpServletResponse qui lui permet de construire dynamiquement une réponse (HTML ou autres) qui sera retournée au client.

Ci-dessous, la servlet récupère la donnée transmise par le client à l'aide de l'objet HttpServletRequest et une de ses méthodes (getParameter) :

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
 
public class LdvSimpleServlet extends HttpServlet {
 
 public void doGet(HttpServletRequest request,
      HttpServletResponse response)
      throws IOException, ServletException
 {
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();

    String action = request.getParameter("action");
      // récupère la valeur du paramètre
      // nommé "action" transmise par le client
    if (action == null) action = "";                                                                                                                          
    if (action.equals("Hello")) {
      String title = "Lycee Leonard de Vinci - 77 Melun ";
      String hello = "Hello world !";
      out.println("<html>");
      out.println("<head> <title>" + title + "</title> </head>");
      out.println("<body><center>");
      out.println("<h1>" + hello + "</h1><br>");
      out.println("<h2>Vous me sollicitez via un " 
            + request.getMethod()+"</h2>");
      out.println("</center></body>");
      out.println("</html>");
    } else {
      out.println("<html><head></head><body>ERREUR action : >"
        +action+"< </body></html>");
    }
   }
  public void doPost(HttpServletRequest request,
          HttpServletResponse response)
      throws IOException, ServletException
  {
    doGet(request, response);
  }

Une servlet est similaire à une extension du serveur Web, et s'exécute dans machine virtuelle Java (JVM). Elle est donc sûre et portable. Généralement les serveurs Web ont un moteur (conteneur) de servlets qui exécute toutes les servlets dans la même JVM.

Un moteur gère le cycle de vie d'une servlet :

1       Crée et Initialise la servlet - méthode init()
n fois  Lui fait traiter les services demandés par les clients, 
        par exemple  doGet( ) et doPost( )
n+1     Détruit la servlet et la passe au ramasse-miettes   destroy ( )

Une servlet persiste entre les requêtes (les threads éventuellement crées par la servlet aussi).

Tomcat peut créer plusieurs instances d'une servlet. Dans ce cas, si des données doivent être partagées entre les différentes requêtes, elles devront être logées dans un contexte particulier appelé ServletContext, un contexte unique pour une application Web.

L'objet ServletContext est accessible via la methode getServletConfig(), ou via le paramètre config de la méthode init.

Le contexte de servlet se comporte comme un dictionnaire (setAttribute, getAttribute, removeAttribute...) et permet à l'application de communiquer avec son conteneur, par exemple Tomcat (getRealPath, log...), voir l'API pour plus de détails (tomcat est supposé lancé) : http://localhost:8080/docs/api/index.html.

Nous allons intervenir sur le code source de la servlet (LdvSimpleServlet.java) afin qu'elle affiche le contenu des cookies gérés par l'application.

Nous éditons le fichier <TOMCAT_HOME>/webapps/ldvSimple/WEB-INF/src/LdvSimpleServlet.java:

 
    ...
    out.println("<body><center>"); 
    out.println("<h1>" + hello + "</h1><br/>"); 
    out.println("<h2>Vous me sollicitez via un " 
            + request.getMethod()+"</h2>");
    out.println("Votre adresse IP : ");
    out.println("<h2>" + request.getRemoteAddr()+"</h2>");
    out.println("</center></body>"); 
    ...

Après l'avoir enregistré, nous le compilons. Voici ce que cela donnerait en ligne de commande :

$ javac LdvSimpleServlet.java
LdvSimpleServlet.java:2: package javax.servlet does not exist
import javax.servlet.*;
^

Le paquetage servlet.jar n'est pas inclus dans JSE (java standard edition). Il est livré avec Tomcat, et disponible ici : <TOMCAT_HOME>/common/lib.

Nous informons le classpath à la compilation, par un chemin relatif :

$ javac -classpath ../../../../lib/servlet-api.jar
     LdvSimpleServlet.java
     -d ../classes/
$

Malheureusement, Tomcat a gardé en mémoire la précédente version de la servlet. Pour que soit prise en compte la nouvelle version nous devons demander à tomcat de recharger notre application. Si on arrête Tomcat pour le relancer ensuite cela fonctionnerait, mais nous arrêterions alors toutes les applications à la charge de Tomcat :-(.

Pour recharger votre application, aller sur l'interface d'administration : http://localhost:8080/manager/html/list.

Figure 9. ldvSimple nouvelle version

L'adresse identifie la machine locale. Demander à un de vos collègues de se connecter à votre application. Votre adresse IP réseau est consultable par la commande ifconfig, exemple :

$ /sbin/ifconfig
eth0      Lien encap:Ethernet  HWaddr 00:09:6B:5F:B5:A8
          inet adr:192.168.0.120  Bcast:192.168.0.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

A partir d'un autre poste, votre collègue entrera comme adresse dans son navigateur :

http://192.168.0.120:8080/ldvSimple

Et recevra en retour un message "Hello World" et son adresse IP.

Il se peut que vous ayez commis une faute dans votre programme qui ne se révellera qu'à l'exécution. Tomcat renvoie alors au client un message d'erreur signalant une erreur interne. Dans ce cas, pour en savoir plus, vous (le développeur) devez consulter le fichier catalina.out. Son adresse exacte est : [TOMCAT_HOME]/logs/catalina.out. A titre d'exemple, en voici un extrait :

[user@localhost logs]$ less catalina.out
3 oct. 2003 14:16:27 org.apache.commons.modeler.Registry loadRegistry
INFO: Loading registry information
3 oct. 2003 14:16:27 org.apache.commons.modeler.Registry getRegistry
INFO: Creating new Registry instance
3 oct. 2003 14:16:28 org.apache.commons.modeler.Registry getServer
INFO: Creating MBeanServer
3 oct. 2003 14:16:29 org.apache.coyote.http11.Http11Protocol init
INFO: Initialisation de Coyote HTTP/1.1 sur le port 8080
Démarrage du service Tomcat-Standalone
Apache Tomcat/4.1.27-LE-jdk14
...

Les 10 dernières lignes de ce fichier sont accessibles directement par la commande tail. Exemple :

[user@localhost logs]$ tail catalina.out
3 oct. 2003 14:16:32 org.apache.struts.util.PropertyMessageResources <init>
INFO: Initializing, config='org.apache.struts.action.ActionResources',
       returnNull=true
3 oct. 2003 14:16:33 org.apache.struts.util.PropertyMessageResources <init>
INFO: Initializing, config='org.apache.webapp.admin.ApplicationResources', 
      returnNull=true
3 oct. 2003 14:16:39 org.apache.coyote.http11.Http11Protocol start
INFO: Démarrage de Coyote HTTP/1.1 sur le port 8080
3 oct. 2003 14:16:39 org.apache.jk.common.ChannelSocket init
INFO: JK2: ajp13 listening on /0.0.0.0:8009
3 oct. 2003 14:16:39 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=1/47  config=/home/kpu/tomcat41/conf/jk2.properties
[user@localhost logs]$

Ici tout va bien, les services sont montés. Si votre application provoque une erreur à l'exécution, vous trouverez alors les explications ici. Il se peut également que Tomcat ne puisse démarrer votre application parce que le fichier web.xml est mal formé ou non valide (ne correspondant pas à la DTD référencée). Vous trouverez alors, dans catalina.out, le numéro de la ligne erronée rendu par le parser xml utilisé par Tomcat.

Les données transmises par le client sont de type String. L'interface ServletRequest expose les méthodes getParameter et getParameterValues :

Exemple :

  String nom = request.getParameter("nom");
  String[] choix = request.getParameterValues("choix");

Installer, si ce n'est déjà fait, ce projet dans Eclipse : ldvSimple.zip. Une façon simple de procéder consiste à copier ce fichier compressé (inutile de le décompresser) dans votre espace de travail d'Eclipse, puis, sous Eclipse, vous l'importez (import->existing project into workspace->archive), et le tour est joué.

Voici une illustration de la procédure : video d'importation du projet ldvSimple sous Eclipse

JSP (JavaServer Pages) est une technologie introduite par Sun (http://java.sun.com/products/jsp/ pour simplifier la conception de contenu web en java.

Dit simplement, peut être vu comme un fichier HTML pouvant contenir des instructions Java ou EL (Expression Language).

Ce type de fichier n'est pas communiqué tel quel au client. Il est d'abord interprété par le serveur Tomcat.

C'est le résultat de l'interprétation qui est communiqué au client.

Les exemples ci-dessous, vous montre "ce qu'il ne faut pas faire".

Il n'y a plus de servlet contrôleur, la logique de présentation est reine, elle contrôle toute la logique :-(.

Ce n'est plus la logique de l'application qui embarque la logique de présentation, mais la logique de présentation qui embarque la logique de l'application : Finalement le problème a été déplacé, mais n'est pas résolu pour autant ! Un infographiste n'est pas un professionnel du développement, nous devrions lui cacher le plus possible toute logique de traitement, ce que nous ferons très prochainement, mais avant présentons quelques contre-exemples.

<html>
<body>
<% String visiteur = request.getParameter("nom");
   if (visitor == null) {
     out.println("<center><h1>Hello inconnu</h1></center>");
   }
   else
     out.println("<cener><h1>Hello " + visiteur + "</h1></center>");
%>
</body>
<html>
}
  

<html>
<body>
<% String visiteur = request.getParameter("nom");
   if (visiteur == null) visiteur = "inconnu";
%>
<center><h1>Hello <%= visiteur %> </h1></center>
</body>
<html>
  

<html>
<body>
<% String idclient = request.getParameter("idClient");
   int qte       = Integer.parseInt(request.getParameter("qte"));
   double pu     = Double.parseDouble(request.getParameter("pu"));
   double pht    = qte*pu;
   Client client = db.getClient(idclient);

   if (client.getProfile().getPayeur() == Client.MAUVAISPAYEUR))
   ...
   // détermination ou non d'une ristourne...
   ...
%>
<center><h1>Montant HT à payer <%= (pht - ristourne) %> </h1></center>
</body>
<html>

  

Nous proposons de réaliser une séparation des responsabilité : La servlet se charge de contrôler les requêtes entrantes, et sous-traite le traitement à une méthode ou à un autre objet, puis la réponse à un fichier JSP.

Pour pour de petites applications, une décomposition par méthodes peut suffire, comme présenté dans l'exemple des Trucs à la fin de cette série.

Figure 10. Exemple de mis en oeuvre d'une séparation fonctionnelle des responsabilités

Dans le cas d'une séparation des responsabilités par classe d'objets, on introduit une classe tierce qui sera chargé de construire (factory) ces fameux objets.

Cette façon de faire a été popularisée par le framework struts.

Figure 11. Exemple de mis en oeuvre d'une séparation objet des responsabilités

Le but de ce design est de séparer le traitement de la réponse. Cette façon de concevoir est connue sous le terme de paradigme MVC (model view controller). Pour cela, l'interface de IFCommnad présente une opération nommée traiter() qui sera chargée du traitement (par exemple détermination d'une ristourne) et qui retournera le nom de la vue à appliquer (une chaîne de caractères).

Dans tous les cas, l'objectif est de distinguer la logique métier côté serveur, par exemple calcul de ristournes, logique de persistance (accès au SGBDR) et logique de présentation qui pourra être sous-traiter à un infographiste, professionnel du look and feel. En effet ces professionnels du design ont des préocupations très éloignées des problèmes de syntaxe d'un langage de programmation comme Java par exemple.

Exemple de servlet contrôleur se chargeant « d'aiguiller la réponse » vers un fichier JSP. Extrait :

public class LdvSimpleServlet extends HttpServlet {
 ...
 public void doGet(HttpServletRequest request,
      HttpServletResponse response)
      throws IOException, ServletException
 {

   ...
    Traitement de la logique métier
    //
    //  IFCommand cmd = CommandFactory.getInstance(action);
    //  String vueJSP = cmd.traiter(request, response);
    // ou 
    //  String vueJSP = traiterFacture(request, response);
    
    appliquerLaVue(request, response, vueJSP);
   ...

 }
 ...

 private void appliquerLaVue(HttpServletRequest request,
      HttpServletResponse response, String laVue) {
   getServletConfig().getServletContext()
     .getRequestDispatcher("/jsp/"+laVue).forward(request, response);
 }
}
  

Les fichier JSP sont supposés être localisés dans un dossier nommé /jsp

Exemple de logique de présentation d'une facteur avec le langage EL (Expression Language) qui simplifie l'utilisation des objets accessibles par une page JSP.

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<html>
<body bgcolor="white">
<h1>
 <table bgcolor="tan" border=1 align="center" cellpadding="10">
 <tr><th colspan="2">FACTURE</th></tr>
 <tr><td> <c:out value="${facture.nom}"/> </td>
     <td> <c:out value="${facture.prenom}"/> </td>
 </tr>
 <tr><td> MONTANT </td>
     <td><c:out value="${facture.montant}"/> </td>
 </tr>
 </table>
</h1>
</body>
</html>

Avec JSP 2.0, pris en compte par Tomcat 5, c'est encore plus simple.

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<html>
<body bgcolor="white">
<h1>
 <table bgcolor="tan" border=1 align="center" cellpadding="10">
 <tr><th colspan="2">FACTURE</th></tr>
 <tr><td> ${facture.nom} </td>
     <td> ${facture.prenom} </td>
 </tr>
 <tr><td> MONTANT </td>
     <td>${facture.montant}</td>
 </tr>
 </table>
</h1>
</body>
</html>

Pour bénéficier de ce langage d'expression nous devons placer dans WEB-INF/lib les fichiers jstl.jar, standard.jar. Vous trouverez ces fichiers dans le répertoire [CATALINA_HOME]/webapps/jsp-examples/WEB-INF/lib/.

Le code source de l'exemple : premiermvc.war

Remarque : Afin de limiter (?) la mise en cache du navigateur, vous pouvez insérer dans les vues les méta données suivantes :

<meta HTTP-EQUIV="Pragma" content="no-cahe">
<meta HTTP-EQUIV="Expires" content="-1">

Bonne programmation !

Une présentation en français de EL et JSTL chez developpez.com

Vous devez prendre connaissance des spécifications JSTL 1.0

Pour bien démarrer : http://www-106.ibm.com/developerworks/java/library/j-jstl0211.html

De multiples ressources sur JSTL chez Sun : Sun's official JSTL

Cette autorisation se fait en premier lieu au niveau du serveur Web. C'est un service proposé par presque tous les serveurs. Le client, la première fois qu'il se connecte, doit fournir son nom et mot de passe. Le nom de l'utilisateur peut être récupéré par la méthode :

classe : HttpServletRequest
public String getRemoteUser()

Le type d'autorisation est connu par :

classe : HttpServletRequest
public String getAuthType()

La valeur de getAuthtype() est la valeur de la variable CGI AUTH_TYPE, soit une valeur parmi {null, "BASIC", "DIGEST"}.

Une servlet peut utiliser le nom de l'utilisateur pour suivre les sessions en enregistrant les données en mémoire (classe partagée) ou dans une base de données. Exemple :

String nomUser = req.getRemoteUser(); 
if (nomUser==null) { 
  // erreur protection attendue
} 
else {
  String[] items = BigCaddie.getItemsOf(nomUser);
  if (items != null) { 
    for (int i=0; i < items.length; i++) { 
      // faire quelque chose avec les items
    }
  }
}

L'utilisation de champs cachés de formulaire permet au serveur de transmettre des informations au client qu'il retransmet au serveur de façon transparente. Exemple.

<form name="formCaddie1" onSubmit="return checkData()">
  <input type="hidden" name="code" value=3> 
  <input type="hidden" name="niveau" vamlue=expert> 
   ...
  <input type="text" name="quantiteProdA" size=3> 
  <p><input type="submit" value="Valider " name="Valider"> 
</form>

Deux types d'informations peuvent être placés dans les champs cachés.

L'idée consiste à placer des paramètres dans l'URL construite et renvoyée à l'utilisateur dans la balise <form>.

Par exemple, ici nous plaçons en paramètre (id) l'identifiant de la session sessionid obtenu par le serveur en invoquant la méthode generateSessionID().

  out.println("<form action='/Shopping?id=sessionid' method='post'>");

Les informations sont ensuite retrouvées par une méthode genre :

   private static String[] getItemsFromCaddie(String sessionId) {  }

Un cookie, invention de Netscape, est un fichier sur le poste client qui contient des informations transmises à un navigateur par un serveur web.

Lorsqu'un navigateur reçoit un cookie, il le sauve sur disque et le renvoie au serveur en principe chaque fois que l'utilisateur se connecte au site à l'origine du cookie.

Pour utiliser les cookies l'API Servlet propose la classe javax.servlet.http.Cookie.

// Constructeur : 
  public Cookie(String name, String value);
// crée un cookie portant les infos nom=valeur

Pour communiquer un cookie au client :

// classe HttpServletResponse
public void addCookie(Cookie cookie)

Limitations côté navigateur: Pas plus de 20 cookies par site, pas plus de 300 cookies par utilisateur. La taille d'un cookie peut être limitée à 4096 octets (4ko).

Il existe un sous-ensemble de l'API Servlet dédié au suivi de session : API Session Tracking.

L'API Session Tracking devrait être supportée par tout serveur Web qui supporte les servlets. L'implémentation minimale de cette API s'appuie sur les cookies persistants.

Principe de l'API : A un utilisateur du site correspond un objet de session. Un objet de session est de type javax.servlet.http.HttpSession.

Il fait office de conteneur d'objets. On peut y stocker toute sorte d'information utile. Pour obtenir l'objet de la session courante, on utilise la méthode :

// classe HttpServletRequest
 public HttpSession getSession()
//ou
 public HttpSession getSession(boolean create)

L'objet HttpSession dispose de deux méthodes bien pratiques :

setAttribute(un nom, une valeur)
// et
getAttribute(un nom)
 // rend la valeur associée à un nom, ou null

Exemple :

HttpSession session = request.getSession(); 
...
Integer niveau = new Integer(3); 
session.setAttribute("niveau", niveau); 
 // si niveau était précédemment lié à un autre objet, 
 // par exemple ("niveau", 2)
 // alors l'association est remplacée par la nouvelle ("niveau", 3)
 // sinon il y a création du couple ("niveau", 3)


... quelques méthodes de Session ...

// Pour retrouver un objet associé à un nom 
public Object getValue(String name) 

// Pour retrouver tous les objets de la session courante 
// Il faut obtenir la liste (peut-être vide) des noms
public String[] getValueNames() 
// puis appeler getValues() pour chaque poste 

// Pour supprimer une association 
public void removeValue(String name) 
// il ne se passe rien si l'association n'existe pas

// Pour connaître l'identifiant d'une session
java.lang.String getId() 
// Retourne une String contenant l'identifiant 
// unique attribué à la session.

La durée de vie est déterminée par le serveur Web (30 mn sur Java Web Server de Sun).

La date de création est accessible par la méthode getCreationTime().

La date du dernier accès est connu par la méthode getLastAccessTime().

Est-ce une nouvelle session ? : isNew()

Suppression d'une session : invalidate()

Exemple, un programme qui termine et réinitialise une session d'utilisateur au bout d'une (!) minute d'inactivité :

 ...
 HttpSession session = request.getSession();
 if (!session.isNew()) { 
    Date minutePrecedente = new Date(System.currentTimeMillis() - 60*1000); 
    Date dernierAcces = new Date(session.getLastAccessedTime()); 
    if (dernierAcces.before(minutePrecedente)) { 
      //plus d'une minute d'inactivité 
      session.invalidate(); 
      session = request.getSession(true);
    }
 } 
 out.println("<br>session id : " + session.getId() + "<br>");
 ...

Notez que d'ordinaire, on laisse au serveur Web le soin de régler le problème de durée d'une session. La durée maximale d'une session est paramétrable via un fichier de configuration situé sur le serveur (par exemple conf/web.xml pour tomcat. Exemple de valeur par défaut :

 
    <!-- temps en minutes -->
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>

L'API JDBC se trouve dans java.sql et les pilotes doivent implémenter l'interface java.sql.Driver.

L'interaction à un système de gestion de base de données réquiert en général au moins quatre étapes :

Les étapes 1 et 2 le sont pour un ensemble d'opérations (étapes 3 et 4). Nous présentons ci-dessous chacune de ces étapes.

On charge généralement le pilote par son nom. Ci-dessous, un exemple de programme chargeant un des deux pilotes définis sous forme de chaînes de caractères.

  final String driverPostgreSql = "jdbc.postgresql.Driver"; 
         // driver PostgreSql
  final String driverOdbc       = "sun.jdbc.odbc.JdbcOdbcDriver"; 
         // driver odbc inclus dans le jdk (pratique sous Windows pour SQL Server, Access...)
  final String driverHsql       = "org.hsqldb.jdbcDriver"; 
         // driver Hypersonic SQL

  String driver = driverHsql;

  Class.forName(driver).newInstance();                     // Autochargement du driver

Une fois le driver chargé en mémoire, nous pouvons obtenir une connexion via la méthode de classe getConnection() de la classe DriverManager

   Connection con = DriverManager.getConnection(URL, "user", "passwd");
   //  URL : url de connexion de la forme jdbc:sous-protocole:sous-nom
   //     sous-protocole:identification du pilote
   //     sous-nom      :informations nécessaire au pilote pour la connexion (chemin, port, nom) 
   // "passwd" : Mot de passe 
   // "user"   : Nom de l'utilisateur référencé par la base 

Exemple

   final String driver = "org.hsqldb.jdbcDriver";
   final String url = "jdbc:hsqldb:file:/home/kpu/java/hsql/refuge/refuge";
   final String user="sa";
   final String password="";
        
   Connection con = null;
   try {
       Class.forName(driver).newInstance();
       con = DriverManager.getConnection(url, user, password);
   ...

L'exécution d'une requête SQL s'effectue via un objet de la classe java.sql.Statement. C'est l'objet Connection qui nous fournira une référence d'objet Statement (à ne pas instancier directement). Exemple :

   Statement stat = con.createStatement();

On distingue deux types de requêtes : requête d'interrogation et de mise à jour.

Le programme ci-dessous utilise une base nommée Refugedb.

Cette base de données contient une table nommée ANIMAL; voici un script de création :

  CREATE TABLE ANIMAL (
    id INTEGER PRIMARY KEY, 
    categorie VARCHAR NOT NULL, 
    nom VARCHAR, race VARCHAR, 
    sexe CHAR, 
    date_nais DATE, 
    id_proprio INTEGER, 
    present BIT
  )
  INSERT INTO ANIMAL VALUES (1,'CRM', 'kiki','berger','M','2000-2-21',21,false)
  INSERT INTO ANIMAL VALUES (2,'CRM','rex','caniche','M','1996-12-2',11,true)
  ...
  

Lorsque l'on accède à une base de données, une gestion des exceptions s'avère nécessaire car de multiples problèmes peuvent survenir : le pilote ne peut être chargé (introuvable ?), connexion refusée, requête SQL mal formée... Voici l'exemple complet.

 1	import javax.servlet.*;
 2	import javax.servlet.http.*;
 3	import java.util.*;
 4	import java.sql.*;
 5	import java.io.*;
 6	
 7	public class TestDBAnimalServlet extends HttpServlet {
 8	 static final String driver   = "org.hsqldb.jdbcDriver";
 9	 static final String url      = "jdbc:hsqldb:hsql://localhost/dbTest";
10	     // connexion au serveur HypersonicSql lancé préalablement
11	 static final String user     = "sa";
12	 static final String password ="";
13	 private Connection con = null;
14     // une solution plus efficace consiste	a utiliser
15     // un pool de connexion 
       // voir tomcat-docs/jndi-datasource-examples-howto.html
16	/**
17	* Initialisation de la servlet. <br>
18	*
19	* @throws ServletException si une erreur intervient
20	*/
21	  public void init() throws ServletException {
22	   try {
23	      Class.forName(driver).newInstance();
24	      con = DriverManager.getConnection(url, user, password); 
25	   }
26	   catch (Exception e) {
27	      throw new ServletException(e);
28	   }
29	  }
30	
31	/**
32	* Destruction de la servlet. <br>
33	*/
34	public void destroy() {
35	  super.destroy(); 
36	  try { 
37	    if (con != null) {
38	      con.close(); 
39	    }
40	  }
41	  catch (Exception e) { /* muet */ }
42	}
43	
44	/**
45	*  méthode répondant aux requêtes GET HTTP
46	*/
47	 public void doGet(HttpServletRequest request,
48	      HttpServletResponse response)
49	      throws IOException, ServletException
50	 {
51	    response.setContentType("text/html");
52	    PrintWriter out = response.getWriter();
53	    Statement  st  = null;
54	    ResultSet  rs  = null;
55	    String    sql  = "";
56	    try {
57	       st  = con.createStatement();
58	       sql = "SELECT * FROM ANIMAL";
59	       rs  = st.executeQuery(sql);
60	       out.println("<html><head></head><body>");
61	       out.println("ID ---  TYPE ---  NOM ---- RACE<br/>");
62	       while (rs.next()) {
63	         out.print(rs.getInt(1)+" -- ");
64	            // ATTENTION, les indices commencent à 1.
65	         out.print(rs.getString(2)+" -- ");
66	         out.print(rs.getString("nom")+" ---- ");
67	         out.println(rs.getString("race") + "<br/>");
68	       }//while
69	       out.println("</body></html>");
70	    }
71	    catch (SQLException e) {
72	       out.println("SQL erreur : "+ sql + "  " + e.getMessage());
73	    }
74	    catch (Exception e) {
75	       out.println("Erreur : "+ e);
76	    } 
77	  }
78	}
	

Pour l'utilisation d'un pool de connexions, on consultera avec attention la partie consacrée à JDBC dans la doc de Tomcat.

Présentation de techniques permettant de contrôler la validité des données avant de transmettre leur valeur au serveur.

Exemple 1 : Utilisation du gestionnaire d'événement onSubmit de l'objet Form avec un input type submit standard.

<html> <head>
 <title> L'objet Form et son gestionnaire d'événement onSubmit </title>
 </head>
 <script>
  var dataOK=false
   function checkData (){
     if (document.form1.threeChar.value.length == 3){
        return true
     } 
     else {
       alert("Enter exactly three characters. " + 
              document.form1.threeChar.value +
               " is not valid.");
       return false;
     }
   }
  </script>
 <body>
   <form name="form1" onSubmit="return checkData()">
   <b>Enter 3 characters:</b> <input type="text" name="threeChar" size=3>
   <p><input type="submit" value="done" name="submit1" 
     onClick="document.form1.threeChar.value=
     document.form1.threeChar.value.toUpperCase()">
   </form>
 </body>
 </html>

Exemple 2 : Similaire au précédent mais utilise la méthode submit de l'objet Form au lieu de l'objet submit. Le formulaire n'a pas de bouton submit, mais se sert de l'evénement onClick d'un simple bouton pour contrôler l'envoi des données.

<html> <head>
 <title> Exemple de méthode submit de l'objet Form </title>
 </head>
 <script>
   function checkData (){
     if (document.form1.threeChar.value.length == 3){
        document.form1.submit();
     } 
     else {
       alert("Enter exactly three characters. " + 
              document.form1.threeChar.value +
               " is not valid.");
       return false;
     }
   }
  </script>
 <body>
   <form name="form1" onSubmit="alert('Le formulaire est en train d'être validé.')">
   <b>Enter 3 characters:</b> <input type="text" name="threeChar" size=3>
   <p><input type="button" value="done" name="bouton" 
     onClick="checkData()">
   </form>
 </body>
 </html>

Boîtes de dialogue :

La plupart des composants ECMAScript sont sensibles aux événements. Voici la liste globale des évenenemts :

Exemple 3 : Gestion d'événements avec l'objet Select :

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <script type="text/javascript" language="JavaScript">
function test(){
  var age = prompt("Quel est votre âge ?", 17);
  document.myForm.myText.value = age;
}
function testChoix() {
  var i = document.myForm.choix.selectedIndex;
  document.myForm.myText.value =
     document.myForm.choix.options[i].value;
}
  </script>
</head>
<body>
Exemple d'une gestion d'&eacute;v&eacute;nements :
<form action="" method="post" name="myForm">
  <select name="choix" onchange="testChoix()">
  <option value="choix1">A</option>
  <option value="choix2">B</option>
  <option value="choix3" selected="selected">C</option>
  <option value="choix4">D</option>
  </select>
  <br>
  <input type="text" name="myText" onselect="test()" value="coucou"/>
 </form>
</body>
</html>