La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Servlets et JSP. Le Web en Java - 1 Le développement Web en Java se base sur plusieurs frameworks standard LAPI Servlets (actuellement version 2.5) JSP.

Présentations similaires


Présentation au sujet: "Servlets et JSP. Le Web en Java - 1 Le développement Web en Java se base sur plusieurs frameworks standard LAPI Servlets (actuellement version 2.5) JSP."— Transcription de la présentation:

1 Servlets et JSP

2 Le Web en Java - 1 Le développement Web en Java se base sur plusieurs frameworks standard LAPI 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

3 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 lutilisateur, via une page html (ou jsp) appelle une servlet en remplissant un formulaire précisant sa demande. La servlet sexé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. Lidéal est de nécrire quune seule servlet qui fait le dispatching (Contrôleur)

4 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 na pas (besoin davoir) 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 lExpression 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 daméliorer la présentation, de valider les données … Il ne peut être utilisé seul mais au dessus de JSP (par exemple).

5 Serveur Vous devez disposer dun servlet container (Tomcat) ou dun serveur dapplication (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 Cliquez sur OK

6 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 dapplication 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.

7 Déploiement Avant dexé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 larchive à 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.

8 LAPI Servlet

9 Les interfaces - 1 Implémentées par le container ServletConfig ServletContext ServletRequest ServletResponse RequestDispatcher FilterChain FilterConfig

10 Les interfaces - 2 A implémenter par le développeur selon nécessité Servlet ServletContextListener ServletContextAttributeListener SingleThreadModel (deprecated) Filter

11 Les classes GenericServlet ServletContextEvent ServletContextAttributeEvent ServletInputStream ServletOutputStream ServletRequestWrapper ServletResponseWrapper

12 Linterface 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

13 Cycle de vie dune servlet 1. 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 na plus besoin de cette servlet, il appelle sa méthode destroy() avant de la mettre à disposition du garbage collector. Cest dans cette méthode quon libèrera les ressources initialisées dans init.

14 Servlet et concurrence Les servlets sont appelées par plusieurs utilisateurs simultanément. Laccès à leurs champs modifiables doit donc être synchronisé Sauf si la servlet implémente SingleThreadModel, mais cest 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 larchive) Appeler

15 Linterface 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.

16 Linterface ServletRequest - 1 Emballe la requête du client et permet davoir accès aux informations qui y sont contenues Récupérer les paramètres : envoyés par le clients (via un formulaire ou dans lurl) public Enumeration getParameterNames() public String getParameter(String name) public String[] getParameterValues(String name) public Map getParameterMap() // renvoie une Map !

17 Linterface 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)

18 Linterface 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 (Latin 1)

19 Linterface 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);

20 Linterface ServletResponse - 1 On peut placer des données et configurer la réponse Indiquer la longueur, le type MIME, lencodage … 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() nappeler quune de ces deux méthodes !

21 Linterface 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 quon a envoyé un buffer

22 Le ServletContext - 1 Cest un objet propre à la servlet, accessible à tous les utilisateurs de celui-ci, de portée « application » On lobtient 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)

23 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 lapplication public String getServerInfo() // le nom du container public int getMajorVersion() // de limplémentation de lAPI Servlet public int getMinorVersion()

24 Le ServletContext - 3 Obtenir des informations sur lenvironnement 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 lapplication public InputStream getResourceAsStream(String path)

25 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 lentête DELETE : demande de supprimer une ressource sur le serveur PUT : upload une ressource sur le serveur

26 Le protocole HTTP – statut - 1 Le statuscode envoyé dans la réponse indique comment sest passé la requête : Catégories de StatusCode : informatif; le client doit répondre par une autre action : succès : le fichier à été déplacé. En général un header Location indique la nouvelle adresse : erreur due au client : erreur coté serveur.

27 Le protocole HTTP – statut - 2 Quelques codes usuels en HTTP (OK): Tout sest bien passé le document est ci-après. Cest la valeur par défaut pour les servlets. 204 (No Content): Le browser continue à afficher lancienne page. 301 (Moved Permanently): Le document demandé a été déplacé ailleurs définitivement (lendroit est indiqué dans le header Location). Les browsers y vont automatiquement. 302 (Found): Le document demandé a été déplacé ailleurs temporairement (lendroit 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.

28 Le protocole HTTP – statut (Unauthorized): Le browser essaye daccéder à une page protégée par mot de passe et il ny 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 daccéder à une directory et le serveur a été configuré pour le refuser 404 (Not Found): Cette page nexiste pas. Les servlets doivent utiliser sendError et non setStatus pour renvoyer ce code. 408 (Request timeout): La page na pu être obtenue avant le timeout

29 L API HTTPServlet

30 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 ny a aucune raison de redéfinir ces méthodes

31 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

32 HTTPServlet - 3 Normalement on se contente de redéfinir les méthodes dont on a lusage : doGet et doPost et bien souvent, dans doPost, on se contente dappeler doGet. Il est inutile de redéfinir doHead : la méthode héritée fait déjà tout ce quil 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.

33 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)

34 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 quune connexion soit persistante, il faut de plus que le header Content- Length soit placé sur la réponse, ce qui se fait à laide 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 : lURL de la page qui vous a référencé User-Agent : le browser

35 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 à lauthentification : 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()

36 HTTPServletRequest - 4 Méthodes dinformation du chemin hel+Debacker&Employeur=IPL public String getQueryString() Nom=Michel+Debacker&Employeur=IPL public String getContextPath() /MyWeb /MyWeb public String getServletPath() /request/HTTPRequestServlet /request/HTTPRequestServlet public String getPathInfo() /intox.htm (voir web.xml) /intox.htm public String getPathTranslated() public String getRequestURI() /MyWeb/request/HTTPRequestServlet/intox.htm public StringBuffer getRequestURL() ce qui précède le ?

37 Réponse HTTP Format dune réponse HTTP HTTP/ OK Content-Type text/html Le titre Ici on met le texte de la page La ligne vide qui sépare les headers de la page est fondamentale.

38 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 dun 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)

39 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)

40 HTTPServletResponse - 3 Headers de réponse HTTP Allow: méthodes HTTP supportées par le serveur Cache-Control: sil vaut no-cache, la page ne sera pas mise en cache. Voir Pragma pour les browsers qui ne supportent quHTTP 1.0 Content-Encoding: lencodage (supporté par le browser daprè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: lurl 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 dautorisation à fournir lors de la prochaine requête

41 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 (derreur). La servlet na donc plus le droit décrire sur sa sortie. Pour le paramètre statusCode, on utilise les constantes définies dans HTTPServletResponse.

42 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 dabord appliquer String encodeRedirectURL(String url) à lurl 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.

43 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; }

44 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 dapplication 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 dapplication du cookie. Par défaut larbre de la page actuelle. secure : si true, nest envoyé quen SSL, HTTPS value : la valeur du cookie version : la version du protocole de cookie supporté : 0 = Netscape, 1 = RFC 2109

45 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) sil est possible que le serveur doivent employer cette technique (cest le deuxième choix) url : url encodée : en utilisant des champs HIDDEN dans un formulaire stocké dans la réponse et renvoyé dans les requêtes suivantes

46 Gestion de la session - 2 Par URL rewriting : refusez les cookies et entrez =Michel+Debacker&Employeur=IPL =Michel+Debacker&Employeur=IPL récupérez la session et testez : onid=44475A059F1E7865AD55098ECC20289D?Nom=Michel+Deba cker&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. onid=44475A059F1E7865AD55098ECC20289D?Nom=Michel+Deba cker&Employeur=IPL 44475A059F1E7865AD55098ECC20289D

47 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 nexiste : la créer ( create = true ) HTTPSession getSession(boolean create) Si, dans ce cas (pas de session existante), on passe false aucune session nest créée et la méthode renvoie null.

48 Gestion de la session - 4 Linterface 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()

49 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


Télécharger ppt "Servlets et JSP. Le Web en Java - 1 Le développement Web en Java se base sur plusieurs frameworks standard LAPI Servlets (actuellement version 2.5) JSP."

Présentations similaires


Annonces Google