Servlets et JSP

Le Web en Java - 1 Le développement Web en Java se base sur

plusieurs frameworks standard L’API Servlets (actuellement version 2.5) JSP ou JavaServer Pages (actuellement version 2.1) JSF ou JavaServer Faces (actuellement version 1.2)

Nous étudierons les deux premiers dans ce cours

Les servlets permettent de construire des pages Web dynamiques en emboîtant la présentation HTML dans le code.

Inversement, les pages JSP emboîtent le code dans la présentation HTML

Le Web en Java - 2 Généralement on utilise les deux techniques

simultanément pour implémenter le pattern MVC2 (aussi appelé Modèle 2) :

Le browser de l’utilisateur, via une page html (ou jsp) appelle une servlet en remplissant un formulaire précisant sa demande. La servlet s’exécute sur le serveur, effectue le travail logique demandé, stocke le ou les résultats dans la requête ou la session puis forwarde vers une page jsp (les Views).

Celle-ci récupère les résultats stockés et se charge de leur présentation en HTML/CSS. Cette page html est envoyée au browser.

L’idéal est de n’écrire qu’une seule servlet qui fait le dispatching (Contrôleur)

Le Web en Java - 3 Ces techniques ont évolué afin de permettre une

séparation des tâches entre le développeur Java et le Webmaster. Ce dernier n’a pas (besoin d’avoir) de connaissances en Java;

Aussi, on va faire disparaître toute trace de code Java dans les pages JSP. Ceci se fait grâce à des possibilités de scripting via l’Expression Language (EL) et en utilisant des tags de contrôle logique via JSTL (JSP Standard Tag Library).

JSF fournit un tel contrôleur et de nombreux tags qui permettent d’améliorer la présentation, de valider les données … Il ne peut être utilisé seul mais au dessus de JSP (par exemple).

Serveur Vous devez disposer d’un servlet container (Tomcat) ou

d’un serveur d’application (JBoss). Créez une configuration dans Eclipse.

dans Eclipse : ouvrez l'onglet Servers (Windows – Show View – Other – Server – Servers)

dans cet onglet cliquez à droite : New – Server choisissez JBoss v 4.2, cliquez Next, entrez l'adresse où est installé JBoss via le bouton Browse et cliquez sur Finish

dans l'onglet Servers apparaît maintenant JBoss 4.2; double cliquez dessus; dans la fenêtre qui s'ouvre, suivez le lien "Open launch configuration"

Ouvrez l'onglet Arguments; dans Program arguments vous devez mettre-c default –b 0.0.0.0

Cliquez sur OK

Installation Dans Eclipse, vous créez un Dynamic Web

Project : New – Project – Web – Dynamic Web Project.

Si votre projet utilise aussi des EJB 3.0, un serveur d’application est obligatoire et dans ce cas dans Eclipse, créez un Enterprise Application Project (New – Project – J2EE – Enterprise Application Project, donnez un nom, faites Next, puis Next, cochez Generate deployment descriptor, cliquez sur New Module et selectionnez EJB Module et Web Module)

Quelle que soit la technique utilisée, vérifiez que les jar pour les servlets et JSP (servlet-api.jar et jsp-api.jar) soient dans votre classpath.

Déploiement Avant d’exécuter une servlet ou une page JSP, vous devez

déployer votre application. Pour cela il vous faut créer un fichier war (web archive) si

vous travaillez avec un Dynamic Web Project seul. Si vous développez un Enterprise Application Project, il faut

créer un fichier ear (entreprise archive, qui contient le fichier war et le fichier jar où sont placés les EJB).

Pour déployer, il suffit de copier ce fichier war ou ce fichier ear dans la directory webapps de Tomcat ou deploy de JBoss.

La création de l’archive à déployer et le déploiement peut se faire en une seule étape dans Eclipse en exportant le projet concerné sous forme de WAR ou EAR dans la directory voulue.

L’API Servlet

Les interfaces - 1 Implémentées par le container

ServletConfig ServletContext ServletRequest ServletResponse RequestDispatcher FilterChain FilterConfig

Les interfaces - 2 A implémenter par le développeur selon

nécessité Servlet ServletContextListener ServletContextAttributeListener SingleThreadModel (deprecated) Filter

Les classes GenericServlet ServletContextEvent ServletContextAttributeEvent ServletInputStream ServletOutputStream ServletRequestWrapper ServletResponseWrapper

L’interface Servlet Il déclare les méthodes

public void init(ServletConfig config) throws ServletException

public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException

public void destroy() public ServletConfig getServletConfig()

Les trois premières méthodes font partie du cycle de vie de la servlet

Cycle de vie d’une servlet1. Le container charge et instancie la servlet. Ne faites

rien dans le constructeur. N'en écrivez même pas !2. Le container appelle sa méthode init(…) en lui

passant son ServletConfig. La méthode init doit stocker ce ServletConfig et effectuer toute autre initialisation nécessaire (connexion à une DB, …). Si on étend GenericServlet, on le fait en redéfinissant init() sans paramètre.

3. La servlet est prête à recevoir des requêtes et à les traiter via sa méthode service().

4. Quand le container n’a plus besoin de cette servlet, il appelle sa méthode destroy() avant de la mettre à disposition du garbage collector. C’est dans cette méthode qu’on libèrera les ressources initialisées dans init.

Servlet et concurrence Les servlets sont appelées par plusieurs

utilisateurs simultanément. L’accès à leurs champs modifiables doit donc

être synchronisé Sauf si la servlet implémente SingleThreadModel, mais c’est déconseillé.

Exemple : la servlet Compteur Ecrire la classe Compteur.java Déclarer la servlet dans web.xml Archiver et déployer (regarder la structure de

l’archive) Appeler http://localhost:8080/MyWeb/Compteur

L’interface ServletConfig On peut obtenir sa ServletConfig via la

méthode getServletConfig (que le développeur écrit ou dont il hérite)

Elle déclare les méthodes String getInitParameter(String name) Enumeration getInitParameterNames() ServletContext getServletContext() String getServletName()

Comme GenericServlet implémente aussi ServletConfig, elle fournit ces méthodes.   

L’interface ServletRequest - 1 Emballe la requête du client et permet d’avoir

accès aux informations qui y sont contenues Récupérer les paramètres : envoyés par le

clients (via un formulaire ou dans l’url) public Enumeration getParameterNames() public String getParameter(String name) public String[] getParameterValues(String name)

public Map getParameterMap() // renvoie une Map<String, String[]> !

L’interface ServletRequest - 2 Récupérer les headers de la requête

public int getContentLength() public String getContentType() public String getProtocol()

Gérer les attributs placés dans la requête par le container ou une autre servlet

public Enumeration getAttributeNames() public Object getAttribute(String name) public void setAttribute(String name, Object value)

public void removeAttribute(String name)

L’interface ServletRequest - 3 Divers

public String getScheme() // http, ftp… public String getServerName() public int getServerPort() public boolean isSecure() // https public Locale getLocale() public Enumeration getLocales() public String getCharacterEncoding() public void setCharacterEncoding(String enc)

//défaut ISO-8859-1 (Latin 1)

L’interface ServletRequest - 4 Lire des données (fichier, objet sérialisé,…)

placées dans la requête public ServletInputStream getInputStream() public BufferedReader getReader()

Forwarder la requête à une autre servlet/page JSP…

public RequestDispatcher getRequestDispatcher(String path)ex: RequestDispatcher rd = req.

getRequestDispatcher(/resultat.jsp);

rd.forward(req, resp);

L’interface ServletResponse - 1 On peut placer des données et configurer la réponse Indiquer la longueur, le type MIME, l’encodage …

public void setContentLenght(int len) public void setContentType(String mime) public void setCharacterEncoding(String enc) public void setLocale(Locale l)

Les getters correspondant aux méthodes ci-dessus Récupérer un stream ou writer pour écrire la réponse

public ServletOutputStream getOutputStream() public PrintWriter getWriter()

n’appeler qu’une de ces deux méthodes !

L’interface ServletResponse - 2 Gérer le buffer de sortie

public void setBufferSize(int size) public int getBufferSize() public int flushBuffer() public void resetBuffer() public void reset() // aussi les headers public boolean isCommitted() // dès qu’on a envoyé un buffer

Le ServletContext - 1 C’est un objet propre à la servlet, accessible à

tous les utilisateurs de celui-ci, de portée « application »

On l’obtient via la méthode getServletContext() de la ServletConfig ou héritée de GenericServlet

On peut y placer des attributs accessibles à tous les utilisateurs

public Enumeration getAttributeNames() public Object getAttribute(String name) public void setAttribute(String name, Object value)

public void removeAttribute(String name)

Le ServletContext - 2 Obtenir des informations générales

public java.util.Enumeration getInitParameterNames()

public String getInitParameter(String name) public String getServletContextName() // le nom de l’application

public String getServerInfo() // le nom du container

public int getMajorVersion() // de l’implémentation de l’API Servlet

public int getMinorVersion()

Le ServletContext - 3 Obtenir des informations sur l’environnement

public ServletContext getContext(String uri) public String getRealPath(String path) public String getContextPath() // /MyWeb public String getMimeType(String file) public RequestDispatcher getNamedDispatcher(String name) // nom de la servlet où on va

public RequestDispatcher getRequestDispatcher(String path)

public URL getResource(String path) // path dans l’application

public InputStream getResourceAsStream(String path)

Le protocole HTTP - Méthodes GET : ne change pas les données sur le

serveur POST : pour les changer ou envoyer une

grande quantité de données HEAD : demande seulement l’entête DELETE : demande de supprimer une

ressource sur le serveur PUT : upload une ressource sur le serveur

Le protocole HTTP – statut - 1 Le statuscode envoyé dans la réponse indique

comment s’est passé la requête : Catégories de StatusCode

• 100-199: informatif; le client doit répondre par une autre action.

• 200-299: succès. • 300-399: le fichier à été déplacé. En général un

header Location indique la nouvelle adresse. • 400-499: erreur due au client. • 500-599: erreur coté serveur.

Le protocole HTTP – statut - 2 Quelques codes usuels en HTTP 1.1

• 200 (OK): Tout s’est bien passé le document est ci-après. C’est la valeur par défaut pour les servlets.

• 204 (No Content): Le browser continue à afficher l’ancienne page.

• 301 (Moved Permanently): Le document demandé a été déplacé ailleurs définitivement (l’endroit est indiqué dans le header Location). Les browsers y vont automatiquement.

• 302 (Found): Le document demandé a été déplacé ailleurs temporairement (l’endroit est indiqué dans le header Location). Les browsers y vont automatiquement.

Les servlets doivent utiliser sendRedirect et non setStatus pour renvoyer ce code et mettre une valeur dans le header Location.

Le protocole HTTP – statut - 3

401 (Unauthorized): Le browser essaye d’accéder à une page protégée par mot de passe et il n’y a pas de header Authorization dans la requête. Le Serveur Web ouvre une fenêtre de login dans le browser et réitère la demande avec le Header Authorization mis aux valeurs entrées

403 (Forbidden): Le browser essaie d’accéder à une directory et le serveur a été configuré pour le refuser

404 (Not Found): Cette page n’existe pas. Les servlets doivent utiliser sendError et non setStatus pour renvoyer ce code.

408 (Request timeout): La page n’a pu être obtenue avant le timeout

L’API HTTPServlet

HTTPServlet - 1 La classe abstraite HTTPServlet hérite de GenericServlet.

Il est toujours possible de redéfinir init() (sans paramètre) et destroy() en cas de besoin.

Elle possède deux méthodes service() : la première héritée est redéfinie pour appeler la seconde en castant ses paramètres :

void service(ServletRequest rq, ServletResponse rp) appelle

void service(HTTPServletRequest req, HTTPServletResponse resp)

Il n’y a aucune raison de redéfinir ces méthodes

HTTPServlet - 2 Cette deuxième méthode service() se contente de

dispatcher à des méthodes spécialisées pour chaque méthode du protocole HTTP :

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException

protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException

protected void doHead(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException

protected void doPut(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException

HTTPServlet - 3 Normalement on se contente de redéfinir les

méthodes dont on a l’usage : doGet et doPost et bien souvent, dans doPost, on se contente d’appeler doGet.

Il est inutile de redéfinir doHead : la méthode héritée fait déjà tout ce qu’il y a à faire.

Si on est certain que le protocole est HTTP1.1, on peut aussi utiliser les méthodes doTrace et doOptions. Il est inutile de les redéfinir.

HTTPServletRequest - 1 Cette interface étends ServletRequest Elle ajoute des méthodes pour traiter les

headers HTTP public String getMethod() // GET, POST public Enumeration getHeaderNames() public String getHeader(String name) public Enumeration getHeaders(String name) public long getDateHeader(String name) public int getIntHeader(String name)

HTTPServletRequest - 2 Headers HTTP

Accept : les types MIME supportés par le browser. Accept-Encoding : les encodages supportés. Authorization : à envoyer pour une page protégée HTTP. Connection : en HTTP 1.0 doit valoir keep-alive pour une connexion

persistante. En HTTP1.1 les connexions sont persistantes par défaut. Pour qu’une connexion soit persistante, il faut de plus que le header Content-Length soit placé sur la réponse, ce qui se fait à l’aide de setContentLength.

Cookie : les cookies envoyés, utiliser getCookies plutôt que getHeaders.

Host : le host demandé, obligatoire en HTTP1.1. If-Modified-Since : le client ne veut la page que si modifiée depuis

une certaine date. utiliser la méthode getLastModified de HTTPServlet et non getHeader.

Referer : l’URL de la page qui vous a référencé User-Agent : le browser

HTTPServletRequest - 3 Méthodes spécialisées à utiliser au lieu de getHeader

public int getContentLength() public String getContentType()

Ces deux méthodes sont héritées de ServletRequest public Cookie[] getCookies()

Méthodes relatives à l’authentification : public String getAuthType() : renvoie BASIC_AUTH,

DIGEST_AUTH, CLIENT_CERT_AUTH ou FORM_AUTH public String getUserName() public Principal getUserPrincipal() à utiliser

avec le package java.security public boolean isUserInRole()

HTTPServletRequest - 4 Méthodes d’information du chemin

http://localhost:8080/MyWeb/request/HTTPRequestServlet/intox.htm?Nom=Michel+Debacker&Employeur=IPL

public String getQueryString()Nom=Michel+Debacker&Employeur=IPL

public String getContextPath() /MyWeb public String

getServletPath()/request/HTTPRequestServlet public String getPathInfo() /intox.htm (voir web.xml) public String getPathTranslated() public String getRequestURI()

/MyWeb/request/HTTPRequestServlet/intox.htm public StringBuffer getRequestURL() ce qui précède le ?

Réponse HTTP Format d’une réponse HTTP

HTTP/1.1 200 OK

Content-Type text/html

<html><head><title>Le titre</title></head>

<body>Ici on met le texte de la page</body>

</html>

La ligne vide qui sépare les headers de la page est fondamentale.

HTTPServletResponse - 1 Gestion des Headers de réponse HTTP

on utilise les méthodes set pour installer la seule valeur ou la première valeur d’un header. Elles réinitialisent le header.

on utilise les méthodes add pour ajouter une seconde, … valeur à un header

public void setHeader(String name, String value)

public void addHeader(String name, String

value)

HTTPServletResponse - 2 Méthodes de convenances

public void setIntHeader(String name, int value)

public void addIntHeader(String name, int value)

public void setDateHeader(String name, long date)

public void addDateHeader(String name, long date)

public boolean containsHeader(String name) public void setContentType(String type) public void setContentLength(int length)

HTTPServletResponse - 3 Headers de réponse HTTP

Allow: méthodes HTTP supportées par le serveur Cache-Control: s’il vaut no-cache, la page ne sera pas mise en cache.

Voir Pragma pour les browsers qui ne supportent qu’HTTP 1.0 Content-Encoding: l’encodage (supporté par le browser d’après la

requête) Content-Length: longueur (calculée par programme) de la page Content-Type: type MIME de la page Expires: la date à laquelle la page ne doit plus être gardée en cache Last-Modified: dernière modification Location: l’url où rediriger la requête Pragma: comme Cache-Control, mais pour HTTP 1.0 Refresh: nombre de secondes avant de rafraîchir la page

automatiquement Set-Cookie: donne une valeur à une clé à mettre en cookie (addCookie) WWW-Authenticate: le type d’autorisation à fournir lors de la prochaine

requête

HTTPServletResponse - 4 Gestion des codes de statut

public void setStatus(int statusCode) public void sendError(int statusCode) public void sendError(int stCode, String msg)

Les deux dernières effacent aussi le buffer et envoient la réponse

(d’erreur). La servlet n’a donc plus le droit d’écrire sur sa sortie.

Pour le paramètre statusCode, on utilise les constantes définies

dans HTTPServletResponse.

HTTPServletResponse - 5 Rediriger la requête

public void sendRedirect(String url) La réponse ne peut pas avoir été envoyée au client

(committed) Si le serveur doit (ou peut) garder la session par URL

rewriting, il faut d’abord appliquer String encodeRedirectURL(String url) à l’url de destination.

La redirection est différente du forwarding : en redirection, la requête est perdue, la page est envoyée au client et le browser réitère la requête avec la nouvelle location. En forwarding, tout se passe coté serveur, on peut avoir commencer à écrire la réponse et la requête est transmise à la nouvelle location. Après le forward, la réponse est committed.

Gestion des cookies - 1 Envoyer un cookie dans la réponse :

Cookie cookie = new Cookie("nom", "valeur");

response.addCookie(cookie); Lire les cookies envoyés avec la requête :

Cookie[] cookies = request.getCookies();

for (Cookie c: cookies)

if (c.getName().equals("nom")) {

traiterLeCookie(c);

break;

}

Gestion des cookies - 2 La classe Cookie possède des getters getProp et des

setters setProp pour les propriétés prop suivantes : comment : commentaire, guère supporté domain : le domaine d’application du cookie. Le host actuel

doit en faire partie. maxAge : durée de vie en secondes name : nom du cookie. Pas de setter (propriété read-only) path : le chemin d’application du cookie. Par défaut l’arbre

de la page actuelle. secure : si true, n’est envoyé qu’en SSL, HTTPS value : la valeur du cookie version : la version du protocole de cookie supporté : 0 =

Netscape, 1 = RFC 2109

Gestion de la session - 1 Il y a trois manières de gérer la session

par cookie : méthode préférée quand le browser accepte les cookies

par URL rewriting : utiliser String encodeURL(String url) s’il est possible que le serveur doivent employer cette technique (c’est le deuxième choix)url : http:/www.ipl.be/index.htmlurl encodée : http:/www.ipl.be/index.html;jsessionid=A03E…

en utilisant des champs HIDDEN dans un formulaire stocké dans la réponse et renvoyé dans les requêtes suivantes

Gestion de la session - 2 Par URL rewriting :

refusez les cookies et entrez http://localhost:8080/MyWeb/HTTPRequestServlet/

intox.htm?Nom=Michel+Debacker&Employeur=IPL récupérez la session et testez : http://localhost:8080/MyWeb/HTTPRequestServlet/

intox.htm;jsessionid=44475A059F1E7865AD55098ECC20289D?Nom=Michel+Debacker&Employeur=IPL où vous replacez 44475A059F1E7865AD55098ECC20289D par le numéro de session récupéré : le numéro de session ne change pas. Sans le jsessionid ou avec un mauvais numéro de session, on a une session différente à chaque requête.

Gestion de la session - 3 Java EE utilise 3 manières de gérer la session :

URL Rewriting Cookies Session SSL en HTTPS

Obtenir sa session : la demander à la requête Si une session existe :HTTPSession session = request.getSession();

Si aucune session n’existe : la créer (create = true)HTTPSession getSession(boolean create)

Si, dans ce cas (pas de session existante), on passe false aucune session n’est créée et la méthode renvoie null.

Gestion de la session - 4 L’interface HTTPSession : usage

Y stocker des attributs de portée session : public Enumeration getAttributeNames() public Object getAttribute(String name) public void setAttribute(String name, Object value)

public void removeAttribute(String name) Obtenir le Servlet Context

public void getServletContext()

Gestion de la session - 5 Gérer la session elle-même

public void getId() public long getCreationTime() public boolean isNew() public long getLastAccessedTime() public int getMaxInactiveInterval() public void setMaxInactiveInterval(int intrvl) public void invalidate() // libère aussi les attributs