Embed Size (px)
Citation preview
Javascript InternetServlets
Java server Java Bean
Sommaire
1. Introduction ................................................................................................. 1
1.1 Présentation..................................................................................................................1
1.1.1 Pré requis & public:................................................................................................11.1.2 Bibliographie...........................................................................................................1
1.2 Le contexte programmation serveur..........................................................................2
1.2.1 Pourquoi ?...............................................................................................................21.2.2 Comment ?..............................................................................................................31.2.3 Avantages de la technologie Servlets.....................................................................3
1.3 Mise en œuvre..............................................................................................................4
1.3.1 Ce qu’il nous faut....................................................................................................41.3.2 Installations.............................................................................................................4
1.4 TOMCAT.....................................................................................................................5
1.4.1 Démarrage...............................................................................................................51.4.2 Architecture du répertoire Tomcat..........................................................................61.4.3 Le répertoire webapps.............................................................................................61.4.4 Paramétrage de l’invoker de servlet........................................................................71.4.5 Premiers tests..........................................................................................................71.4.6 Le fichier Web.xml de l’application.......................................................................8
1.5 Eclipse : paramétrage et compilation......................................................................10
1.6 Rechargement des servlets........................................................................................12
2. Les servlets ................................................................................................ 13
2.1 Premier pas................................................................................................................13
2.1.1 L’ API Servlet.......................................................................................................132.1.2 Mes premières servlets..........................................................................................14
2.2 Suivi de session...........................................................................................................16
2.2.1 Les cookies............................................................................................................162.2.2 L’API session........................................................................................................182.2.3 Les champs de formulaire cachés.........................................................................182.2.4 La réécriture d’URL..............................................................................................182.2.5 Authentification de l’utilisateur............................................................................19
2.3 Gérer l’authentification avec les realms..................................................................19
2.3.1 Définir les rôles et les utilisateurs.........................................................................19
2.3.2 URL à protéger.....................................................................................................20
2.4 Servlet et variable d’instance....................................................................................21
2.5 Accès aux bases de données......................................................................................23
2.5.1 La méthode Init et les paramètres d’initialisation.................................................232.5.2 La gestion des exceptions et les logs....................................................................242.5.3 Une simple connexion...........................................................................................242.5.4 Gestion des connexions.........................................................................................24
2.6 Communication servlet Applet.................................................................................27
2.7 Autres…......................................................................................................................27
3. Les Java Server Pages .............................................................................. 28
3.1 Introduction et architecture J2EE...........................................................................28
3.1.1 Limites des servlets...............................................................................................283.1.2 Distinction des différents traitements...................................................................283.1.3 Modèle MVC et J2EE...........................................................................................293.1.4 Architecture de J2EE............................................................................................29
3.2 Premiers éléments JSP..............................................................................................30
3.2.1 Structure................................................................................................................303.2.2 Traitement.............................................................................................................323.2.3 Utilisation d’un JavaBean.....................................................................................323.2.4 Structure de contrôle.............................................................................................333.2.5 Variables locales et globale..................................................................................333.2.6 Déclaration de procédure......................................................................................33
3.3 Gestion des paramètres.............................................................................................34
3.3.1 Récupération des paramètres de requête...............................................................343.3.2 Affectation des paramètres de requête à un JavaBean..........................................35
3.4 Gestion des erreurs....................................................................................................36
3.5 Création d’un JavaBean...........................................................................................37
3.6 Les actions personnalisées.........................................................................................38
3.6.1 Présentation...........................................................................................................383.6.2 Principes................................................................................................................383.6.3 Utilisation d’une action de la bibliothèque...........................................................393.6.4 Le fichier TLD......................................................................................................40
Introduction
1.1 Présentation
1.1.1 Pré requis & public:
1.1.1.1 Pré requis
- HTML- programmation objet en Java- JDBC
1.1.1.2 Public :
Ce document est proposé à des stagiaires DI option Services Internet ayant vu 3 semaines de JAVA dans le tronc commun durant 4 semaines HTML, JScript, Asp durant 1 semaine PHP
1.1.1.3 Durée
Tout ça en une semaine de 4.5 jours…
1.1.2 Bibliographie
Ces ouvrages ont été pour moi des références dans la mise en œuvre de ces technologies :
Tomcat par la pratique - EyrollesServlets Java - Guide du programmeur - O’ReillyJava Server Pages - O’Reilly
Et bien sur Internet le site http://java.sun.com/ pour : Tutorial java Tutorial J2EE API Specification J2EE Et bien d’autres..
Le contexte programmation serveur
1.1.3 Pourquoi ?
Utilité : création de pages dynamiques
A l’origine technologie CGI (Common Gateway Interface)
Problème : à chaque requête un processus doit être créé par le serveur , donc problème de performance.
Evolution ensuite Fast – CGI mais guère mieux
Technologie des servlets : un processus par servlet, un thread par client
Problème dans toutes ces technologies il s’agit d’insérer de l’HTML dans du code. Ces pages sont réservées au monde du programmeur.
Sun à donc décider de développer les JSP. Java Server Pages en s’appuyant sur les servlets.
Une JSP est donc une page HTML incluant du code, converti en Servlet par un compilateur.
1.1.4 Comment ?
Pour exécuter des JSP et des servlets il faut un conteneur de servlet le plus connu est TOMCAT de la fondation Apache ASF(ApacheSoftwareFoundation) , projet JAKARTACe conteneur écrit en JAVA fonctionne donc sur toutes les plates-formes et s’intègre à la plupart des serveurs WEB du marché (Apache, IIS).
http://www.apache.org http://jakarta.apache.org/
1.1.5 Avantages de la technologie Servlets
Portabilité : fonctionne sur toutes les plates-formes
Puissance : bénéficie de toutes les API du monde java, plate-forme J2EE
Efficacité et endurance : un seul processus. Une fois chargée par le conteneur, la servlet reste en mémoire et donc est disponible immédiatement.
Sûreté :fort typage du langage JAVA, ramasse miette, gestion des exceptions
Elégance : orienté objet
Intégration : très proche du serveur , possibilité d’utiliser des outils
Limites : excellent pour les grosses applications, peu adapté au petits sites..
1.2 Mise en œuvre
1.2.1 Ce qu’il nous faut
- Le JDK de sun : la version standard suffit Rem : il faudra seulement ajouter dans la bibliothèque du projet le fichier servlet.jar
qui se trouve dans le répertoire du JRE local.A l’adresse http://java.sun.com/
- TOMCAT (qui fait aussi office d’un petit serveur WEB)A l’adresse http://www.apache.org (item Jakarta)
- éventuellement un AGL : ex :eclipseA l’adresse http://www.eclipse.org/
1.2.2 Installations
1.2.2.1 Installation du JDK
Double cliquer sur le fichier
1.2.2.2 TOMCAT
Double cliquer sur le fichier
NB : pour les mots de passe User :admin Pwd :admin (sinon je ne pourrais pas vous aider en cas de problèmes….)
1.2.2.3 Eclipse
Double cliquer sur le fichier
1.3 TOMCAT
1.3.1 Démarrage
Cliquer sur Démarrer / ApacheTomcat /
Lancer votre navigateur et taper l’adresse http://localhost :8080
La page suivante doit apparaître :
Pour se connecter au serveur de votre voisin remplacer localhost par son adresse IP ( winipcfg)
Pour arrêter le serveur passer toujours par
Présentation de la page d’accueil :
Accès aux utilitaires d’administration- administration du serveur- gestionnaire d’application
Remarques : ces outils servent juste d’interface pour modifier les fichiers de configuration accessibles manuellement.
Accès à la documentation
Exemples de JSP et Servlets
Mais nous n’entrerons pas en détail dans le fonctionnement de TOMCAT …
1.3.2 Architecture du répertoire Tomcat
bin : exécutable startup / shutdown
common : classes et librairies communes a toutes les applications
conf : fichiers de configuration server.xml et web.xml ( accessibles via Administration)
logs : fichiers de logs du serveur (trace des événements, et vos propres logs)
server : répertoire des applications administration et management
webapps : répertoire par défaut des applications
work : répertoire de travail du serveur
1.3.3 Le répertoire webapps
Une application = Un répertoire pour stocker les fichiers
Dans ce répertoire (en respectant la hierarchie ci-dessous): La page d’accueil index.html (*) Vos pages JSP ou les répertoires les contenant Un répertoire WEB-INF qui décrit et paramètre votre application
Le fichier web.xml paramétrage de l’application Le répertoire classes contenant les servlets , les beans ou les
packages de votre application Le répertoire lib (*) pour les fichiers jar spécifiques à l’application (sinon voir
common) Le répertoire tlds (*) pour les tag des actions personnalisées des JSP
attention WEB-INF toujours en majuscule, classes, lib en minuscule sinon ça ne fonctionne pas !!! pour toute application il faut un répertoire WEB-INF avec dedans fichier web.xml
1.3.4 Paramétrage de l’invoker de servlet
éditer web.xml dans le répertoire confenlever le commentaire entourant l'élément servlet-mapping relatif à l'invoker de
servlet
<!-- The mapping for the invoker servlet -->
<servlet-mapping> <servlet-name>invoker</servlet-name> <url-pattern>/servlet/*</url-pattern> </servlet-mapping>
Rem : les commentaires XML < !-- -->
1.3.5 Premiers tests
Mise en application 1 : Exécution de la servlet HelloWorld du package tp01
Pour nos expérimentations nous créerons un répertoire workdiRécupérer le package tp01 et le placer au bon endroit…
Mise en application 2 :Exécution de jsp helloWorld
Récupérer la jsp et la placer au bon endroit…Ensuite appeler la page en tapant son chemin http://localhost:8080/workdi/helloWorld.jsp
à vous de jouer…et aller faire un tour dans le répertoire work/standalone/localhost/workdi que trouvez vous ?…. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … …
Mise en application 1 : Exécution de la servlet HelloWorld du package tp01
Pour nos expérimentations nous créerons un répertoire workdiRécupérer le package tp01 et le placer au bon endroit…
1.3.6 Le fichier Web.xml de l’application
1.3.6.1 Nommage des servlets
Etre obligé de saisir la référence complète de la classe de la servlet est un peu lourd (ex : nom de package et sous package..) et puis si vous changez le nom de votre classe vous devrez modifier dans tous vos fichiers y faisant référence…Le fichier web.xml permet de paramétrer le nommage des servlets
Rien n’empêche par la suite de définir que hello fait référence à la servlet tp01.accueil.HelloWorld
Attention à chaque modification du fichier Xml de l’application il faut recharger l’application pour que les modifications soit prises en compte Pour vérifier la syntaxe d’un fichier XML ouvre le avec votre navigateur
1.3.6.2 Recharger le paramétrage de l’application
Lancer le gestionnaire TomcatEt aller dans Tomcat manager
Cliquer sur Recharger (pour l’application workdi !!)Remarque : le fait d’arrêter et redémarrer est équivalent.
1.3.6.3 Mapping des servlets
Obligé de mettre le mots clé servlet… pas forcément , il suffit d’associer une URI à la servlet
Synthèse :Le nommage permet d’appeler directement la servlet sans passer par sa classe et son packageLe mapping évite l’emploi du mot clé servlet, il nécessite le nommage
Mise en application 4 Mapper la servlet hello vers HelloModifier votre fichier web.xml Recharger votre contexte WorkdiEnsuite appeler la page en tapant son chemin http://localhost:8080/workdi/Hello
Mise en application 3 : Nommer la servlet tp01.HelloWorld en helloModifier votre fichier web.xml Recharger votre contexte WorkdiEnsuite appeler la page en tapant son chemin http://localhost:8080/workdi/servlet/hello
1.4 Eclipse : paramétrage et compilation
Nous allons créer un nouveau projet
Ensuite dans les propriétés du projet nous allons rajouter la librairie Servlet.jar (vous la trouverez sur votre machine)
Et nous allons définir comme chemin de sortie pour les fichiers .class le répertoire de notre application workdi/WEB-INF/classes
Sur la même fenêtre cliquer sur Browse
Puis cliquer sur créer un nouveau répertoire
Nommer le répertoire output et le lier au répertoire classes de votre application workdi
Dans votre projet servlet créer un package tp01 .
1.5 Rechargement des servlets
Il souhaitable de vérifier que le contexte WorkDi soit paramètré de façon à recharger automatiquement, lors du prochain appel, une servlet lorsque son fichier class change.
Lancer Tomcat Administration http://localhost:8080/
Mise en application 5 Compiler la servlet Bonjour.javaCopier avec l’explorateur de windows le fichier Bonjour.java dans le répertoire Servlet\tp01 puis sélectionner refresh pour votre projetDans le répertoire workdi/…/ classes vous devez trouver le fichier Bonjour.classInvoquer la servlethttp://localhost:8080/workdi/servlet/tp01.Bonjour
2. Les servlets
2.1 Premier pas
2.1.1 L’ API Servlet
La classe GenericServlet du package javax.servlet permet d’implémenter une servlet indépendante du protocole.
La classe HTTPServlet du package javax.servlet.HttpServlet propose les méthodes doGet et doPost permettant de traiter les requêtes du serveur.
Mise en application 6Affichage d’informationsEn utilisant les objets request et session afficher les informations suivantes en créant une servlet Infos.class dans le package tp01 :DateIdentifiant de sessionRemote adresseUtilisateur Chemin du contexteChemin de la servletChemin réel
2.1.2 Mes premières servlets
package tp01;import java.io.*;import javax.servlet.*;import javax.servlet.http.*;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println( "helloworld this is my servlet" ); }}
Penser à l’aide http://java.sun.com/j2ee/1.4/docs/api/index.html
Dans les méthodes get et post deux paramètres :Entrée : un objet HttpServletRequestSortie : un objet HttpServletResponse
Avec l’objet HttpServletRequest on peut récupérer en utilisant la méthode getSession un objet de type HttpSession
Pour récupérer les champs d’un formulaire utiliser la méthode getParameter(nomduchamp)
Rem : La methode HttpRequest.getParametersNames() renvoie la liste de tous les nom de paramètres d’un formulaire
GET : Utilisé lorsqu’on rentre une URL dans le navigateur Si il y a des paramètres ils sont ajoutés à l’URL La page peut être ajoutée aux signets Ne pas utiliser pour les mises à jour critiques Page rechargeable
POST : Paramètres non visibles Grosse quantité d’information Sécurité : paramètres non journalisés par le serveur
Mise en application 8 Le post et le get
Implémenter doPost de façon à ce qu’il appelle le doGetEt modifier la page html
Que remarquez – vous ?…. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … … …. … …
2.2 Suivi de session
Http est un protocole sans état : il ne fournit aucun moyen à un serveur de reconnaître qu’une séquence de requêtes proviennent toutes du même client. La solution est que le client se présente à chaque requête. Il existe différents moyens de suivre une session :
Les cookies persistants
L’ API suivi de session
Les champs de formulaire cachés
La réécriture d’URL
L’authentification de l’utilisateur
2.2.1 Les cookies
L’API servlet fournit la classe javax.servlet.http.Cookie pour travailler avec les cookies.
Pour créer un cookie il suffit d’appeler le constructeur dont la signature est la suivante: public Cookie(String name,String value)
Et ensuite de l’enregistrer en appelant la methode du paramètre response. public void HttpServletResponse.AddCookie(Cookie cookie) .
Une servlet retrouve les cookies en appelant la methode du paramètre request public Cookies[] HttpServletRequest.getCookies()
Exemple : Affichage des cookiesCookies[] cookies=req.getCookies() ;if (cookies != null) {
for (int i=0;i< cookies.length;i++) {String name=cookies[i].getName();String value=cookies[i].getValue();
}}
Remarques : il est utile dans un package d’avoir une méthode permettant de rechercher un cookie par son nom :
static public String Tools.searchCookie(Cookie[] cookies,String cookieName) (package Tools fourni)
Par défaut le cookie vit durant toute la session. Il est possible de modifier la durée en utilisant la méthode :
Cookies.setMaxAge(int expiry) ou int est la durée en seconde.
La taille d’un cookie est limitée à 4096 ko.
Les cookies sont enregistrés par votre navigateur sur votre machine c:\windows\cookies ( en général)
Rem : pour rediriger vers une page on utilise la méthode HttpResponse.sendRedirect(String url)
exemple : response.sendRedirect(request.getContextPath()+"/servlet/tp03.AffCookie?Err="+error);
2.2.2 L’API session
Les servlets intègrent le suivi de session . Chaque utilisateur d’un site est associé à un objet javax.servlet.http.HttpSession que les servlets utilisent pour stocker ou retrouver les informations sur l’utilisateur.
Pour stocker une information on utilise la méthode setAttribute(String key ,Object value)HttpSession session=request.getSession();session.setAttribute(“Nom”,user);
et HttpSession.getAttribute(String key) pour récupérer la valeur.ou HttpSession.getAttributeNames() pour récupérer les noms des attributs
Mise en application 10 Le suivi de session
Mise en application 9 Les cookiesSoit les servlets tp02.AffCookie et tp02.SetCookie qui permettent d’enregistrer une serie de cookies . La servlet AffCookie permet la saisie et l’affichage
Sur le bouton Deposer on invoque la servlet SetCookie qui permet d’enregistrer les valeurs des champs dans des cookies.Règles :Pour enregistrer un cookie le champ nom et valeur ne peut etre null.
En cas de succès
Continuer envoi vers la page d’accueil
En cas d’erreur , on redirigera la réponse vers la page AffCookie . en passant le message d’erreur via les paramètre Err .
La servlet AffCookie affiche la liste des cookies de la session. Elle affiche ensuite le formulaire et le message d’erreur éventuel.
Avantage : on stocke n’importe quel type d’objet , pas de limitation de taille , technique à privilégier.
2.2.3 Les champs de formulaire cachés
Comme son nom l’indique ces champs sont ajouté au formulaire HTML mais ne sont pas affichés par le navigateur.
Exemple :<FORM ACTION= « …… » METHOD= « POST »><INPUT TYPE=”hidden” NAME=”User” VALUE=”Durand”><INPUT TYPE=”hidden” NAME=”NbVisite” VALUE=”11”></FORM>
2.2.4 La réécriture d’URL
Chaque URL est modifiée de façon à inclure des informations supplémentaires. Ces informations sont gérés comme des paramètres supplémentaires.
La méthode HttpResponse.encodeURL(String url) permet de récrire l’URL en y incluant l’identifiant de session.La méthode java.net.URLEncoder.encode(String value) permet de coder en unicode les caractères spéciaux.
Exemple : "<HREF='"+response.encodeURL("/servlet/help")+"'</HREF>"
Mise en application 10 Le suivi de session
2.2.5 Authentification de l’utilisateur
La méthode request.getRemoteUser() permet de récupérer le paramètre j_username qui contient le nom de l’utilisateur . La contrainte est qu’il faut protéger l’accès aux différentes pages et forcer l’utilisateur à s’identifier.
<form method="POST" action="j_security_check"> <p> Utilisateur <input type=TEXT name="j_username" size="20"></p> <p> Mot de passe <input type=PASSWORD name="j_password" size="20"></p> <p><input type=SUBMIT value="login"></p></form>
Tomcat permet de sécuriser l’accès aux différents éléments de l’application
2.3 Gérer l’authentification avec les realms
Pour gérer l’authentification avec les realms il est nécessaire de - définir des rôles - définir des utilisateurs et les rôles auxquels ils appartiennent- définir les URL à protéger- définir le type de page de login- définir la page d’erreur de login
2.3.1 Définir les rôles et les utilisateurs
Le fichier tomcat-user.xml du répertoire conf.
<?xml version="1.0" encoding="utf-8" ?> - <tomcat-users> <role rolename="tomcat" /> <role rolename="manager" /> <role rolename="admin" /> <role rolename="stduser" description="utilisateur standard" /> <user username="di" password="di" fullName="stagiaire DI" roles="stduser" /> <user username="tomcat" password="tomcat" roles="tomcat" /> <user username="jdc" password="jdc" fullName="Jean DAvid" roles="admin,manager,stduser,tomcat" /> <user username="role1" password="tomcat" roles="role1" /> <user username="both" password="tomcat" roles="tomcat,role1" /> <user username="admin" password="admin" roles="admin,manager" /> </tomcat-users>
Exemple : Ici le fichier initial a été modifié :définition du role stduserdéfinition du username DI avec le role stduserdéfinition du username JDC avec le role stduser,admin,manager,tomcat
On peut également faire ces modifications en utilisant Tomcat Administration :
2.3.2 URL à protéger
Le fichier web.xml de l’application permet de gérer ce paramétrage :
<!-- Security is active on entire directory --> <security-constraint>
<display-name>Working Security Constraint</display-name>
<web-resource-collection><web-resource-name>Work protetected</web-resource-name> <!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/servlet/*</url-pattern> <url-pattern>*.html</url-pattern>
</web-resource-collection>
<auth-constraint><!-- Anyone with one of the listed roles may access this area --> <role-name>stduser</role-name>
</auth-constraint>
</security-constraint><!-- Login configuration uses form-based authentication -->
<login-config><auth-method>FORM</auth-method> <realm-name>Essais de protection</realm-name> <form-login-config>
<form-login-page>/login.html</form-login-page> <form-error-page>/error.html</form-error-page>
</form-login-config></login-config><!-- Security roles referenced by this web application --> <security-role>
<description>Les rôles en jeu pour cette application</description> <role-name>stduser</role-name>
</security-role>
Remarques <auth-method> peut prendre différentes valeurs:BASIC : formulaire par défaut avec info envoyée en clairDIGEST : formulaire par défaut avec information codéeFORM : formulaire défini par le programmeurCLIENT-CERT : formulaire par défaut basé sur les certificats
2.4 Servlet et variable d’instance
Soit la servlet suivante qui permet de compter et d’afficher le nombre de fois que l’on y a accédé.
import java.io.*;import javax.servlet.*;import javax.servlet.http.*;
public class SimpleCounter extends HttpServlet {
int count = 0;
public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/plain"); PrintWriter out = res.getWriter(); count++;
Mise en application 11 Protection d’URL
Créer dans webapps un répertoire workdi_sc (security constraint). Copier une de vos servlets (ex : Infos.class), dans le repertoire WEB-INF/classesCréer les pages error et loginParamétrer le rôle stduser et l’utilisateur DIModifier le fichier WEB-XML afin de définir les contraintes de sécurité à partir du fichier web_sec.txtInvoquer votre servlet : vous devez passer obligatoirement par la page de login
Les rôles mis en jeu
Les FORM de login et d’erreur
Le type d’authentification
Les rôles autorisés
Les URL à protéger
out.println("Since loading, this servlet has been accessed " + count + " times."); }
Deux clients invoquent la servlet selon le principe de base des servlets une seule instance de la servlet et crée mais deux thread sont actifsLorsque nous écrivons notre code nous supposons que les instructions count++ et println ne sont pas dissociés. Or la JVM pourrait exécuter les instructions comme ceci :
count++ //thread 1count++ //thread 2println (.. //thread 1println (.. //thread 2
et ce n’est pas ce que l’on voulait !!!
La solution est d’interdire la dissociation de ces instructions en les synchronisant .
Pour synchroniser ces deux lignes différentes solutions sont possibles
Synchronisation du doGet
public synchronized void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException
Inconvénient : la servlet ne peut traiter qu’une requête à la fois
Synchronisation des deux lignes
synchronized (this) {count++;
out.println("Since loading, this servlet has been accessed " + count + " times.");
}
Inconvénient : si le bloc comprends des instructions dont le temps est non négligeable, les autres blocs ne peuvent pas être exécutés.
Synchronisation de l’accès à la variable critique
synchronized (this) {localCount = ++ count //local count étant une variable de la
procédure}
Attention trop de synchronisation pénalise les performances de votre application
2.5 Accès aux bases de données
2.5.1 La méthode Init et les paramètres d’initialisation
Au chargement de la servlet la méthode init est appelé, c’est le moment de charger les paramètres d’initialisation de la servlets définis dans le fichier web.xml
Exemple :public class DbServlet extends HttpServlet {
public void init (ServletConfig Config) trows ServletException{ super.init(config);
String driver=config.getInitParameter(« database-driver-class »);String jdbcUrl=config.getInitParameter(« database-url »);
}}
et le fichier web.xml
</servlet><servlet-name>bdd</servlet-name><servlet-class>BdServlet</servlet-class>
<init-param><param-name>database-driver-class</param-name><param-value>oracle.jdbc.driver.OracleDriver</param-value >
</init-param><init-param>
<param-name>database-url</param-name><param-value>jdbc:oracle:thin:@linuxser.afpa:1521:fpa1</param-value >
</init-param></servlet>
Rem : pour une base access pont ODBC : sun.jdbc.odbc.JdbcOdbcDriverURL jdbc :odbc :Aliaspont MySQL : org.gjt.mm.mysql.DriverURLjdbc:mySql://localhost:3306/Database
Si on utilise un driver de type 3 (Oracle,MySql) il faut penser à mettre dans common\lib le fichier correspondant (Ex :classe12.jar pour oracle)
2.5.2 La gestion des exceptions et les logs
Il est possible de tracer les erreurs dans un fichier de log, répertoire \logs en utilisant la méthode HttpServlet.log(String text)
Il est possible de générer sa propre page d’erreur sur une exception Http.Response.sendError(int sc,String msg)int sc étant le code d’état HTTP
2.5.3 Une simple connexion
2.5.4 Gestion des connexions
2.5.4.1 Difficultés
La stratégie de gestion des connexions reste quelque chose de délicat :
Le temps d’allocation d’une connexion est long , ouvrir une connexion lors de l’accès à chaque page n’est pas viable.
Lors d’ une transaction commerciale, en général la transaction se fait sur plusieurs pages, d’ou la nécessité de mémoriser la connexion.
Associer une connexion à un utilisateur dés son arrivée sur un site est difficile à gérer si un grand nombre de client est prévisible , un serveur ne pouvant gérer en moyenne que100 connexions maximum.
2.5.4.2 Les pools de connexions
Une solution performante est d’utiliser un pool de connexion, cela consiste à gérer une liste de connexion et de les mettre à disposition des servlets
Mise en œuvre logicielle
Une liste de connexion est mémorisée (ex : comme attribut statique d’une classe)Lors d’un appel à la servlet, le thread demande à la liste une connexion. Si une connexion est disponible il retourne cette dernière sinon il en crée une nouvelle.
Mise en application 12 Listing des tables architecture 3/tiersNous allons nous connecter à une base ORACLE URL (bip-vénissieux): jdbc:oracle:thin:@linuxser.afpa:1521:fpa1User ORAxx Pwd ORAxxExercice idem sur un autre base ex : access sauf driver Odbc
Créer la servlet tp03.ListingBdd avec une variable d’instance con de type Connection.Dans la méthode init charger le driver (les paramètres seront dans le fichier XML) . Tracer une éventuelle erreur dans le log
Dans la méthode doGet instanciation de la connexion (usr et pwd seront des paramètres de la requête) et lister les tables de la base SELECT * FROM ALL_TABLES (uniquement Oracle) en utilisant une objet Statement et un objet ResultSet.Les exceptions générerons une redirection vers une page d’erreur standard
Voir : Annexe 1
Mise en œuvre sous Tomcat
Tomcat permet de gérer les pools de connexion , pour récupérer une connexion il suffit alors d’appeler la méthode public Connection DataSource.getConnection(String usr,String pwd);
2.5.4.3 Association de connexion à la session
Si l’on associe une connexion à la session, la difficulté est que lorsque la session se termine inopinément il faut pouvoir libérer la connexion. L’interface javax.servlet.HttpSessionBindingListenner permet de capturer l’événement de fin et début de session.Pour mettre fin manuellement à une session on utilise la méthode HttpSession.invalidate()
Mise en œuvre : classe container d’une connexion
class ConContainer implements HttpSessionBindingListener {private Connection con =null;public java.util.Date created=new java.util.Date();
public ConnectionHolder(Connection con){this.con=con;try { con.setAutoCommit(false);}catch (SQLException e) {}
}
public Connection getConnection() {return con;}
public void valueUnbound(HttpSessionBindingEvent event) {//lors de la dissociation fermeture de la connexiontry {
if (con != null) {con.rollback();con.close();
}}catch (SQLException e) {}
}public void valueBound(HttpSessionBindingEvent event) {// rien à faire lors de l'association}
}
Utilisation :
Dans la servlet pour récupérer une connexion il suffit de faire :
ConContainer c=(ConContainer)session.getAttribute("servlet.connection");if (c==null) {
try { c=new ConnectionHolder(DriverManager.getConnection(url,usr,pwd));session.setAttribute("servlet.connection",c);con=c.getConnection();
} catch (SQLException e){}} else {
con=c.getConnection();out.println("<PRE> connecté le "+c.created+"</PRE>");
}
Mise en application 13 un livre de messageMise en œuvre initiale : on crée la connexion à chaque appel
Créer une base de donnée Access ( driver ODBC) ou MySQL (driver : org.gjt.mm.mysql.Driver)
Mise en application 13 un livre de messageMise en œuvre initiale : on crée la connexion à chaque appel
Créer une base de donnée Access ( driver ODBC) ou MySQL (driver : org.gjt.mm.mysql.Driver)
2.6 Communication servlet Applet
Une Applet est exécutée par la JVM du client, pour des raisons de sécurité les fonctionnalités d’une Applet au niveau gestion de ressources sont très limitées. Cet inconvénient est inhibé en créant une servlet d’accès au ressources et en faisant communiquer l’Applet avec la servlet.
Ces technologies ne seront pas abordées ici : http,Socket,RMI….
2.7 Autres…
Gestion du multilangue grâce aux possibilités d’internationalisation du JDK1.1
Environnement de développement Tea : un développeur crée les applications écrites en JAVA et installées dans TeaServlet. Un producteur crée et maintient l’apparence des pages WEB dynamiques en écrivant des modèles Tea qui appellent les fonctions fournies par les applications du développeur.
Environnement WebMacro : moteur de template , système remplaçant un texte dans des modèles de page Web. La servlet exécute sa logique métier, crée un objet de réponse contenant le résultat métier puis sélectionne un fichier modèle afin de générer le contenu client.
Et bien d’autres oublis ….
3. Les Java Server Pages
3.1 Introduction et architecture J2EE
3.1.1 Limites des servlets
La solution de développer des composants CGI, servlet est basée sur de la programmation incluant de l’HTML ce qui limite la création de site Web dynamique au monde des programmeurs .
Les JSP partent dans la direction opposée mettre du code dans des pages HTML. C’est pareil ? Non, car les différentes fonctions du traitement sont dissociées et attribuées selon différentes compétences.
JSP est une spécification et non un produit.
JAVA est la langage par défaut des JSP mais la spécification autorise l’utilisation d’autre langage comme JavaScript,Vbscript , Perl
3.1.2 Distinction des différents traitements
Un JavaBean est un composant offrant des services à l’application.
3.1.3 Modèle MVC et J2EE
Modèle , Vue , Contrôleur ( revoir UML)
En fait il s’agit d’une combinaison JSP,Servlet, Java Bean en fonction des rôles attribués :
JSP, HTML : affichage, saisie , c’est l’interfaceServlet : processus , c’est le moteur du systèmeJavaBean : métier , c’est la logique de l’application
3.1.4 Architecture de J2EE
3.2 Premiers éléments JSP
3.2.1 Structure
Une page JSP est composée de : Texte template : HTML, XML, texte en clair Eléments JSP qui sont :
o Des directiveso Des actions (standard, personnalisé )o Des éléments de script (scriptlet, expression, déclaration)
Exemple :
3.2.1.1 Directives
<@ page … > Description des attributs dépendant de la page comme le langage de script, la page d’erreur <@ include > Inclut un fichier pendant la phase de traduction<@taglib ..> Déclare une bibliothèque de balises contenant les actions personnalisées utilisées dans la page
voir Annexe 3
3.2.1.2 Actions standard
<jsp :useBean> Rend un composant JavaBean disponible dans la page<jsp :getProperty> Obtient la valeur d’une propriété d’un composant JavaBean et de l’ajouter à la réponse<jsp :setProperty> Définit la valeur d’une propriétés d’un JavaBean<jsp :include> Inclut la réponse d’une servlet ou d’une page JSP pendant la phases de traitement de la requete<jsp :forward> Redirige le traitement de la requête vers une servlet ou une page JSP<jsp :param> Ajoute la valeur d’un paramètre à une requête traitée par une autre servlet ou une autre page JSP indiqué dans une action include ou forward<jsp :plugin> Génère le code HTML qui contient les éléments dépendants du navigateur adéquats (Object ou Embed) nécessaire à l’exécution d’une applet avec le logiciel JavaPlugIn
<%@ page language="java" contentType="text/html" %><%! int globalCounter = 0; %><html>
<head><title>Page avec un compteur</title>
</head><body bgcolor="white">
<jsp:useBean id="clock" class="java.util.Date" /> <%= clock.toString() %><p>Cette page a été visitée : <%= ++globalCounter %> fois.<p>
</body></html>
3.2.1.3 Actions personnalisés
Voir chapitre à ce sujet 3.6
3.2.1.4 Eléments de script
<% %> Scriptlet, utilisée pour embarquer du code script<%= %> expression, utilisée pour embarquer des expressions quand le résultat doit être ajouté à la réponse. Utilisée aussi à l’exécution comme valeurs d’attribut pour les actions<%! > Déclaration, utilisée pour déclarer des variables d’instance et des méthodes dans la classe d’implémentation de la classe JSP.
Dans éléments de script des objets implicites sont disponibles :
Voici la liste des objets accessibles implicitement depuis toute scriptlet :
Objet Dérivé de Descriptionrequest javax.servlet.ServletRequest Objet contenant la requête du client
response javax.servlet.ServletResponseObjet contenant la réponse de la page JSP. Cet objet utilisé avec les servlets ne l'est généralement pas avec les JSP, puisque le code HTML est directement créé
pageContext javax.servlet.jsp.PageContext Objet contenant des informations sur l'environnement du
serveursession javax.servlet.http.HttpSession Objet contenant la session en coursapplication javax.servlet.ServletContext Objet contenant le contexte de servletout javax.servlet.jsp.JspWriter Objet contenant le flux de sortieconfig javax.servlet.ServletConfig Objet contenant la configuration de la servletpage java.lang.Object Objet désignant la page elle-même (équivalent à this)exception java.lang.Throwable Objet représentant une exception non interceptée© Copyright 2004 Jean-François Pillou -
3.2.1.5 Commenatires
<%-- --%>Tout texte placé entre ces deux marqueurs est ignoré.
3.2.2 Traitement
Les JSP bénéficient de la puissance des servlet car elles sont traités comme des servlets.
Le compilateur s’appelle JASPER
3.2.3 Utilisation d’un JavaBean
En JAVA nous avons vu que nous utilisions tout le temps des objets que nous instancions avec la méthode new .Utiliser un objet c’est utiliser un JavaBean.
<jsp :usebean id= « nom de l’objet » classe= « nom de la classe »/> L’attribut scope de jsp :useBean permet de définir la porté du bean, quatre valeurs sont possibles : page, request, session, application
Pour afficher l’information il faut appeler la méthode ou l’attribut de l’objet<jsp :getProperty name= « nom de l’objet » property= « nom de propriétés »/
on peut directement appeler la méthode ou l’attribut de l’objet
<%= objet.methode() %>
équivallent à <% out.println(objet.method()) %>
seule la première syntaxe est du « vrai »JSP (pas de connaissance de programmation..)
3.2.4 Structure de contrôle
Ce sont les même qu’en Java puisque c’est du Java…
Exemple pour le if :<% if (chiffre==4) { %>
Vous avez trouvé le bon chiffre<% } else { %>
Perdu
Mise en application 1 Affichage de la date
page date1.jsp
Affichage de la date Et du détail.
<% } %>
Le conteneur de JSP combine le code des 3 scriplets et les templates .
3.2.5 Variables locales et globale
Une variable déclarée en début de page après les directives <@ est traduite comme une variable d’instance. <%! int globalCounter >Une variable déclarée dans une scriplet est considérée comme une variable locale <% int localCounter%>
Attention les variables globales sont donc partagées par tous les clients …. A éviter sauf dans des cas bien précis : exemple compteur d’accès
3.2.6 Déclaration de procédure
La déclaration se fait avec une balise <% ! Exemple :
<% ! public void Hello() { out.println(« Hello ») ;} %>
Mise en application 3 Compteur d’accés
page counter.jsp
Créer une variable globale et une variable localeIncrémenter les deux variables et afficher les deux valeursA voir : La locale ne varie pas, la générale est commune à tous les clients
Mise en application 2 Sélection sur la date
page date2.jsp
Affichage de Bonsoir si l’heure est supérieure à 12 sinon Bonjour.
3.3 Gestion des paramètres
3.3.1 Récupération des paramètres de requête
L’objet request propose la méthode getParameter (String paramName) qui retourne la valeur du paramètre spécifié ou getParameterValues(String paramName) pour des listes de valeurs
Exemple :String name = request.getParameter ("name");String[] picked = request.getParameterValues("selection");
getParameterValues renvoie null si le paramètre n’est pas renseigné il faut donc tester le retour de cette méthode
Remarques : Dans vos script, pensez à la syntaxe : =expression1 ? val1 : val2
Mise en application 4 Questionnaire
page quest.jsp
Créer un formulaire comme ci-dessous qui réappelle la même page pour le traitementPour le traitement afficher les infos saisie par l’utilisateur
3.3.2 Affectation des paramètres de requête à un JavaBean
Dans de nombreux cas, il est utile de stocker les paramètres de requête pour les traitements du processus. Passer par un JavaBean simplifie le problème. Soit le JavaBean de classe DataQuest avec comme propriété name et selection. Pour affecter les paramètres name et selection de notre questionnaire (remarquez qu’ils portent le même nom), il suffit lors de l’appel de JavaBean de déclarer :
<jsp :useBean id=monBean class=DataQuest><jsp:setProperty name= “monBean” property=”*”/>
</jsp :useBean >
On initialise la propriété *, c’est à dire toutes les propriétés avec les valeurs des paramètres dont les nom et types correspondent au propriétés.
Remarques : pour forcer l’utilisateur à ressaisir jusqu’à validité voir l’exemple en annexe 4
Mise en application 5 javeBean userInfo
page userInfo.jsp
Créer le formulaire userInfo.html qui appelera pour le traitement la page userInfo.jsp
La page userInfo.jsp stockera les paramètres dans le JavaBean tpBean.UserInfoBean. et restituera les propriétés de ce bean afin d’obtenir l’affichage suivant.
Propriétés du bean :userName, birthDate, emailAddr, sex, luckyNumber, valid, propertyStatusMsg
3.4 Gestion des erreurs
La directive <%@page errorPage= permet de définir la page d’erreur à appeler en cas d’exception non géré.
La page d’erreur contient la directive <%@ page isErrorPage= « true » %> Dans la page d’erreur on peut utiliser la méthode exception.getMessage() pour avoir le message d’erreur.
Pour connaître la page qui à généré l’erreur il faut au préalable avoir enregistré cette information en utilisant request.setAttribute(« sourcePage »,request.getRequestUri()) Puis dans la page d’erreur on récupère l’information request.getAttribute(« sourcePage »)
Mise en application 7 Gestion d’erreur
page division.jsp
Créer la page divion.jsp qui permet d’afficher le résultat de la division de deux entiers.
et page d’erreur errordiv.jsp qui affiche le message d’erreur et l’URI de la page source
3.5 Création d’un JavaBean
Un JavaBean est une classe Java qui respectent certaines directives dont les principales sont les suivantes :
Implémente l’interface Serialisable afin d’assurer la persistance Les propriétés sont accessible via les assesseurs les set et get dont le nom correspond
à la propriété du bean
Exemplepublic class User implements java.io.Serializable {
private string userpublic void setUser(String user)
this.user=user;}public String getUser() {
return this.user;}
}donc dans la JSP
<jsp:getProperty …… property=”user”
3.6 Les actions personnalisées
3.6.1 Présentation
Soit un JavaBean monBean qui possède une méthode non standard (les seules méthodes standard sont les assesseurs)
public int maMethode(int value)
Mise en application 7 Création d’un bean de calcul epargne
JavaBean tpBean.CountBean et pages countInfo.html countInfo.jsp
Propriété du JavaBeandurée durée en moistaux taux d’interétversement versement mensuelmontant montant au bout de la durée en fct du taux
Sans prendre une formule compliquée Montant = Montant * (Taux//12) + Versement ( à répéter durée fois)
Pour utiliser cette méthode on est obligé de passer par les scriplets. Or l’utilisation des JavaBean est là pour éviter le code dans la JSP.
Les actions personnalisées permettent ce type d’action
Les actions personnalisées sont définies dans des librairies appelées bibliothèques de balises.Un bibliothèque de balise contient un fichier descripteur de balise TLD Tag Lib Descriptor
3.6.2 Principes
Un action personnalisée est un JavaBean héritant de l’une des deux classes TagSupport ou BodyTagSupport. Afin d’implémenter l’une des interfaces Tag ou BodyTag
Exemple :import javax.servlet.jsp.tagext.* ;public class monAction extends TagSupport {
private String nom ;public void setNom(String nom){
this.nom=nom ;}public int doEndTag() throws JspException{
try {pageContext.getOut().println(« Bonjour »+nom) ;}catch (IOException) {
throw new JspException(e.toString()) ;}return EVAL_PAGE ;
}}
Pour avoir un traitement dans le corps de l’action il faut implémenter BodyTag
Et ça devient plus délicat.. on ne verra pas cela… mais c’est tout l’interêt des JSP (Annexe 5 )
3.6.3 Utilisation d’une action de la bibliothèque
Pour utiliser une librairie il faut utiliser la directive<@ taglib uri= « uri symbolique » prefixe= « lib » %>
et dans ce cas dans le fichier xml définir vers quel fichier TLD pointe cette uri<taglib>
<taglib-uri>\maLib
</taglib-uri><taglib-location>
/WEB-INF/tlds/mesActions_1_02.tld</taglib-location>
</taglib>
ou<@ taglib uri= « uri du TLD » prefixe= « lib » %>
Remarque : l’intérêt de passer par le fichier xml et que si le nom du fichier TLD change (modification de version ) vous n’avez pas à modifier toutes les pages JSP de votre application !!!)
nous pourrons alors utiliser une action de la bibliothèque :<lib :action ….
Exemple :<lib:monAction name= « Durand » />
3.6.4 Le fichier TLD
Il faut définir à quoi correspond notre uri de bibliothèque.Cela se fait dans le fichier web-xml
<?xml version="1.0" encoding="ISO-8859-1" ?><!DOCTYPE taglibPUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN""http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
<!-- The tag library descriptor --><taglib>
<!-- Basic library information --><tlibversion>1.0</tlibversion><jspversion>1.1</jspversion><shortname>tools</shortname><info>
Déclaration de notre action</info>
<tag> <name>monAction</name> <tagclass>tpBean.monAction</tagclass>
<bodycontent>JSP</bodycontent><attribute>
<name>name</name> <required>true</required>
</attribute> </tag></taglib>
Mise en application 8 Création d’une action personnalisé visu du contenu d’une table d’une base de donnée
JavaBean tpBean.bddInfo et page bddInfoBean.jsp
Idem : Servlet livre d’orCréer une base de donnée Access ( driver ODBC)
ou MySQL (driver : org.gjt.mm.mysql.Driver)Créer une table msgList avec comme champs :
id Long (key), Name char(15),email char(30),cmt char(255)
Propriétés de l’actionAffiche le résultat de SELECT * FROM msgList sous forme soit de :table <table> <tr> <td> liste <li> selon la valeur du paramètre presentation de l’action
Rem : - le nom du driver et l’URL de la base seront des attributs static du bean.d’action.- le driver sera chargé au niveau du constructeur
Annexe1 : pool de connexion logiciel
import java.sql.*;import java.util.*; public class ConnectionPool { private Hashtable connections = new Hashtable(); private Properties props;
public ConnectionPool(Properties props, int initialConnections) throws SQLException, ClassNotFoundException {
this.props = props; initializePool(props, initialConnections); }
public ConnectionPool(String driverClassName, String dbURL, String user, String password, int initialConnections) throws SQLException, ClassNotFoundException { props = new Properties(); props.put("connection.driver", driverClassName); props.put("connection.url", dbURL); props.put("user", user); props.put("password", password); initializePool(props, initialConnections); }
public Connection getConnection() throws SQLException { Connection con = null; Enumeration cons = connections.keys(); synchronized (connections) { while(cons.hasMoreElements()) { con = (Connection)cons.nextElement(); Boolean b = (Boolean)connections.get(con); if (b == Boolean.FALSE) { try { con.setAutoCommit(true); } catch(SQLException e) { // Problem with the connection, replace it. try { con.close(); } catch (SQLException ignored) { } connections.remove(con); con = getNewConnection(); } connections.put(con, Boolean.TRUE); return con; } } // If we get here, there were no free connections. Make one more. con = getNewConnection(); connections.put(con, Boolean.FALSE); return con; } }
public void returnConnection(Connection returned) { if (connections.containsKey(returned)) { connections.put(returned, Boolean.FALSE); } }
private void initializePool(Properties props, int initialConnections) throws SQLException, ClassNotFoundException { Class.forName(props.getProperty("connection.driver")); // Put our pool of Connections in the Hashtable // The FALSE value indicates they're unused for(int i = 0; i < initialConnections; i++) { Connection con = getNewConnection(); connections.put(con, Boolean.FALSE); } }
private Connection getNewConnection() throws SQLException { return DriverManager.getConnection( props.getProperty("connection.url"), props); }}
Utilisationimport java.io.*;import java.sql.*;import javax.servlet.*;import javax.servlet.http.*;
public class OrderHandlerPool extends HttpServlet { private ConnectionPool pool;
public void init() throws ServletException {
try { pool = new ConnectionPool("oracle.jdbc.driver.OracleDriver", "jdbc:oracle:oci7:orders", "user", "passwd", 5); } catch (Exception e) { throw new UnavailableException("Couldn't create connection pool"); } }
public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { Connection con = null; res.setContentType("text/plain"); PrintWriter out = res.getWriter(); try { con = pool.getConnection(); // Turn on transactions con.setAutoCommit(false); Statement stmt = con.createStatement(); stmt.executeUpdate( "UPDATE INVENTORY SET STOCK = (STOCK - 10) WHERE PRODUCTID = 7"); stmt.executeUpdate( "UPDATE SHIPPING SET SHIPPED = (SHIPPED + 10) WHERE PRODUCTID = 7");
//chargeCard(); // method doesn't actually exist... con.commit(); out.println("Order successful! Thanks for your business!"); } catch (Exception e) { // Any error is grounds for rollback try { con.rollback(); } catch (Exception ignored) { } out.println("Order failed. Please contact technical support."); } finally { if (con != null) pool.returnConnection(con); } }}
Annexe 2 : Pool de connexion Tomcat
import javax.naming.InitialContext;import javax.naming.*;import oracle.jdbc.pool.*;
public class PoolTomcat extends HttpServlet {
private static OracleDataSource ds;
public void init(){ //Récupération du DataSourceContext initCtx=new InitialContext();Context envCtx=(Context) initCtx.lookup("java:comp/env");ds=(OracleDataSource) envCtx.lookup("jdbc/testOracle");
}
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
Connection con= ds.getConnection(defaultUser,defaultPwd);}
Paramètrage des fichiers
Fichier s server.xml<Context className="org.apache.catalina.core.StandardContext" cachingAllowed="true"
charsetMapperClass="org.apache.catalina.util.CharsetMapper" cookies="true" crossContext="false" debug="0" displayName="Tomcat Examples" docBase="C:\Program Files\Apache Group\Tomcat 4.1\webapps\workjdc" mapperClass="org.apache.catalina.core.StandardContextMapper" path="/workjdc" privileged="false" reloadable="true" swallowOutput="false" useNaming="true" wrapperClass="org.apache.catalina.core.StandardWrapper">
<Resource auth="Container" name="jdbc/testOracle" scope="Shareable"
type="oracle.jdbc.pool.OracleDataSource" />
<ResourceParams name="jdbc/testOracle"><parameter>
<name>factory</name> <value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter><parameter>
<name>url</name> <value>jdbc:oracle:thin:@linuxser.afpa:1521:fpa1</value>
</parameter><parameter>
<name>maxActive</name> <value>4</value>
</parameter><parameter>
<name>maxWait</name> <value>5000</value>
</parameter><parameter><name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value> </parameter>
<parameter><name>maxIdle</name> <value>2</value>
</parameter></ResourceParams>
</Context>
Annexe 3 : Attributs de la directive page des JSPVoici la liste des attributs de la directive de page
Attribut Valeurs possibles Description
language javaPermet de spécifier le langage à utiliser pour traiter les instructions de la page. Java est le langage utilisé majoritairement, mais on peut imaginer des servlets écrites dans un autre langage
extends package.class Permet de définir une classe à étendre, c'est-à-dire la classe parente de la servlet générée par JSP
import package.class|pakage.* Permet d'importer une liste de classes ou de packages en début de page, au même titre que dans une application Java.
session true|false Permet de définir si la page actuelle peut accèder aux données stockées dans la session. Cet attribut est true par défaut
buffer none|8kb|sizekbPermet de définir si le flot de sortie est placé dans un tampon avant envoi. Par défaut la taille du tampon est de 8kb, mais il est possible de définir la taille en kb. Cet attribut s'utilise avec l'attribut autoflush
autoflush true|false La valeur true (par défaut) indique que le tampon doit être vidé lorsqu'il est plein
isThreadSafe true|false
La valeur true (par défaut) indique que plusieurs clients peuvent utilise simultanément la servlet. Lorsqu'elle vaut false, la servlet passe en mode monothread, ce qui signifie qu'un seul client\ peut accèder à la servlet à la fois. Cela est particulièrement utile si la servlet accède à une ressource qui ne peut être partagée
info Texte Permet de retourner une description grâce à la méthode servlet.getServletInfo()
errorPage URL Permet de spécifier une page JSP chargée de gérer les exceptions non gérées par celle-ci
isErrorPage true|false Permet de spécifier si la page en cours est une page d'erreurcontentType text/html;charset=ISO-
8859-1Indique le type MIME de la page ainsi que le jeu de caractères utilisés
© Copyright 2004 Jean-François Pillou –
Annexe 4 : Exemple userInfo2.jsp
<%@ page language="java" contentType="text/html" %><html> <head><title>Formulaire de saisie des informations de l’utilisateur</title></head> <body bgcolor="white"> <jsp:useBean id="userInfo" class="tpBean.UserInfoBean"> <jsp:setProperty name="userInfo" property="*" /> </jsp:useBean>
<%-- Affichage des valeurs ayant un format invalide, si elles existent --%> <font color="red"> <jsp:getProperty name="userInfo" property="propertyStatusMsg" /> </font>
<%-- Affichage du formulaire avec les valeurs envoyées valides --%> <form action="userinfo2.jsp" method="post"> <table> <tr> <td>Nom :</td> <td><input type="text" name="userName" value="<jsp:getProperty name="userInfo" property="userName" />"> </td> </tr> <tr> <td>Date de naissance :</td> <td><input type="text" name="birthDate" value="<jsp:getProperty name="userInfo" property="birthDate" />"> </td> <td>(Utilisez le format aaaa-mm-jj)</td> </tr> <tr> <td>Adresse e-mail :</td> <td><input type="text" name="emailAddr" value="<jsp:getProperty name="userInfo" property="emailAddr" />"> </td> <td>(Utilisez le format [email protected])</td> </tr> <tr> <td>Sexe :</td> <td><input type="text" name="sex" value="<jsp:getProperty name="userInfo" property="sex" />"> </td> <td>(Male ou female)</td> </tr> <tr> <td colspan=2><input type="submit" value="Envoi"></td> </tr> </table> </form> </body></html>
Annexe 5 : Exemple d’utilisation d’action personnalisées
<%@ page language="java" contentType="text/html" %><%@ page import="java.text.*" %><%@ page import="java.util.*" %><%@ taglib uri="/orataglib" prefix="ora" %><html> <head> <title>Catalogue des produits</title> </head> <body bgcolor="white"> <h1>Catalogue des produits</h1> Choisissez un livre dans notre catalogue pour en voir une description détaillée et décidez si vous voulez en acheter un exemplaire : <jsp:useBean id="catalog" scope="application" class="com.ora.jsp.beans.shopping.CatalogBean" /> <%-- Génère une liste des produits avec des liens vers la page produit. --%> <ul> <ora:loop name="catalog" property="productList" loopId="product" className="com.ora.jsp.beans.shopping.ProductBean"> <li> <a href="<ora:encodeURL url="product.jsp"> <ora:param name="id" value="<%= product.getId() %>"/> </ora:encodeURL>"><%= product.getName() %></a> </ora:loop> </ul>
<jsp:useBean id="cart" scope="session" class="com.ora.jsp.beans.shopping.CartBean" /> <%-- Montre le contenu du caddie, s’il existe (les prix sont donnés en $) --%> <% if (!cart.isEmpty()) { NumberFormat numFormat = NumberFormat.getCurrencyInstance(Locale.US); %> Votre caddie contient les éléments suivants :<p> <table border=0> <ora:loop name="cart" property="products" loopId="product" className="com.ora.jsp.beans.shopping.ProductBean"> <tr> <td><%= product.getName() %></td> <td><%= numFormat.format(product.getPrice()) %></td> </tr> </ora:loop>
<tr><td colspan=2><hr></td></tr> <tr> <td><b>Total :</b></td> <td><%= numFormat.format(cart.getTotal()) %></td></tr> </table> <% } %> </body></html>
Annexe 6 : EJB et architecture distribuée
