serveur d’applications jee
Post on 09-Jan-2016
51 Views
Preview:
DESCRIPTION
TRANSCRIPT
Serveur d’applications JEE
F.Renault
Introduction Java à la maison, java au boulot, java sur le chemin
Le «Java Framework» (Java 2 Platform) est composé de trois éditions, destinées à des usages différents :
J2ME : Java 2 Micro Edition est prévu pour le développement d'applications embarquées, notamment sur des assistants personnels et terminaux mobiles ;
J2SE : Java 2 Standard Edition est destiné au développement d'applications pour ordinateurs personnels ;
J2EE : Java 2 Enterprise Edition, destiné à un usage professionnel avec la mise en oeuvre de serveurs.
Chaque édition propose un environnement complet pour le développement et l'exécution d'applications basées sur Java et comprend notamment une machine virtuelle Java (Java virtual machine) ainsi qu'un ensemble de classes.
Définition de J2EE J2EE (Java 2 Enterprise Edition) est une norme proposée par la société Sun, portée par un consortium de
sociétés internationales, visant à définir un standard de développement d'applications d'entreprises multi-niveaux, basées sur des composants. Cela concerne l’architecture des logiciels
On parle généralement de «plate-forme J2EE» pour désigner l'ensemble constitué des services (API) offerts et de l'infrastructure d'exécution. J2EE comprend notamment : Les spécifications du serveur d'application, c'est-à-dire de l'environnement d'exécution : J2EE définit
finement les rôles et les interfaces pour les applications ainsi que l'environnement dans lequel elles seront exécutées. Ces recommandations permettent ainsi à des entreprises tierces de développer des serveurs d'applications conformes aux spécifications ainsi définies, sans avoir à redévelopper les principaux services.
Exemple de serveur d’application : Sun Java server Glassfich WebLogic Application Server
Un serveur d’application bien connu : TOMCAT Ce n’est finalement qu’un serveur JEE partiel comme on pourra le voir plus tard, il n’implémente qu’une
partie des spécifications J2EE .
Des services, au travers d'API, c'est-à-dire des extensions Java indépendantes permettant d'offrir en standard un certain nombre de fonctionnalités. Sun fournit une implémentation minimale de ces API appelée J2EE SDK (J2EE Software Development Kit).
Ainsi des bibliothèques de classes supplémentaires sont disponibles pour créer des logiciels aux fonctionnalités adaptées aux serveurs d’applications.
Les Api de J2EE
Les API de J2EE peuvent se répartir en trois grandes catégories :
Les composants. On distingue habituellement deux familles de composants :
Les composants web : Servlet et JSP (Java Server Pages). Il s'agit de la partie chargée de l'interface avec l'utilisateur (on parle
de logique de présentation).
Les composants métier : EJB (Enterprise Java Beans). Il s'agit de composants spécifiques chargés des traitements des données
propres à un secteur d'activité (on parle de logique métier ou de logique applicative) et de l'interfaçage avec les bases de données.
Ces deux types de composant sont mis en place par le biais de conteneurs.On parle de conteneur de servlets ou de conteneur EJB
Les Api de J2EE Les services, pouvant être classés par catégories :
Les services d'infrastructures : il en existe un grand nombre, définis ci-dessous : JDBC (Java DataBase Connectivity) est une API d'accès aux bases de données
relationnelles. JNDI (Java Naming and Directory Interface) est une API d'accès aux services de nommage
et aux annuaires d'entreprises tels que DNS, NIS, LDAP, etc. JTA/JTS (Java Transaction API/Java Transaction Services) est un API définissant des
interfaces standard avec un gestionnaire de transactions. JCA (J2EE Connector Architecture) est une API de connexion au système d'information de
l'entreprise, notamment aux systèmes dits «Legacy» tels que les ERP. JMX (Java Management Extension) fournit des extensions permettant de développer des
applications web de supervision d'applications. Les services de communication :
JAAS (Java Authentication and Authorization Service) est une API de gestion de l'authentification et des droits d'accès.
JavaMail est une API permettant l'envoi de courrier électronique. JMS (Java Message Service) fournit des fonctionnalités de communication asynchrone
(appelées MOM pour Middleware Object Message) entre applications. RMI-IIOP est une API permettant la communication synchrone entre objets.
Tous ces services sont donnés par des librairies de classes à partir desquelles on pourra créer facilement des objets utiles aux applications. Le cas typique JavaMail
L'architecture J2EE permet ainsi de séparer la couche présentation, correspondant à l'interface homme-machine (IHM), la couche métier contenant l'essentiel des traitements de données en se basant dans la mesure du possible sur des API existantes, et enfin la couche de données correspondant aux informations de l'entreprise stockées dans des fichiers, dans des bases de données relationnelles ou XML, dans des annuaires d'entreprise ou encore dans des systèmes d'informations complexes.
Schema
Serveur JEE complet
Tomcat
Comparaison de serveurs…. Apache
Serveur web simple : Pas de page dynamiques Fournisseur de fichiers
Apache + CGI Comme un plug-in, permet à apache de rendre ses pages web dynamiques.
Apache + php Plus connu aujourd’hui, et plus simple à mettre en œuvre que cgi, php et son
interpréteur mais il suis le même schéma. C’est sa bibliothèque d’objets qui le rend souple et la possibilité depuis php5 d’avoir
une programmation objet plus normalisée permet des développements de bonnes envergures.
Cependant…quelques limites…
Apache + java …. TOMCAT Tomcat est un serveur d’application plus évolué car cette fois, il ne se contente pas de
rediriger les requêtes utilisateurs vers un programme simple ou comme php vers un interpréteur.
Au lancement de tomcat, qui est écrit en java d’ailleurs, un conteneur de servlets est mis en place. C’est lui qui va gérer les redirections et créer un contexte pour les applications java. Il met aussi en place l’interprèteur JSP…
Conteneur de servlet Logiciel démarré au lancement du serveur et actif à plein temps : Fait le pont entre
le monde web(requêtes utilisateur http) et le monde java Possède son propre contexte
Paramétrable par des fichiers xml (dans ses répertoires) ou un logiciel adapté : Serveur.xml Context.xml Web.xml
Crée un contexte pour chaque application web Paramétrable par des fichiers xml dans le répertoire de chaque application :Le serveur cumul les informations globales et locales, les fichiers ont d’ailleurs les mêmes noms.
Serveur.xml Context.xml Web.xml
Nous travailleront essentiellement sur ces fichiers locaux. On peut voir un contexte comme une bulle dans laquelle vit l’application, le
serveur en définit les limites. Un espace mémoire réservé Un système de fichier dont une structure minimale est imposée et dont la racine définit le contexte. On
parle aussi de chemin de contexte. Des ressources générales misent à disposition :
Accès à une base de données (Datasources) Accès à des objets partagés entre les applications
Des ressources spécifiques à une application. Gestionnaire des servlets et pages jsp, il peut filtrer des requêtes destinées à l’un ou
l’une en particulier ou pour toute l ’application(Pour des statistiques par exemple) Gestionnaire des espaces mémoires, il peut écouter les modifications associées à des
objets fabriqués par pour l’application, les objets de contexte (modification d’une session utilisateur par exemple)
Gestionnaire des requêtes entrantes, il peut définir des droits d’accès pour certaines ressources en fonction de l’utilisateur, en fonction de l’adresse ip du client ect…
Schéma : pour se faire une idée
Contexte serveurContexte d’application
Web.xml
Context.xml
Listener
Filter
Ressources.
Listener
Filter
Ressources.
Crée les objets java Request et Response .Lit les fichiers de config généraux et du contexte d’application, crée
Les objets implicitesSi des filtres ou écouteurs généraux sont définit, ils sont appelés et ont accès aux objets créés ci-dessus.
Ensuite idem pour les filtres et écouteurs de l’application.Enfin passe le relai à le serlet.
Rend la réponse de le serlet et/ou exécute les actions qu’elle demande.
Request
Response
Objets implicites
Web.xml
Server.xml
Context.xml
Servlet
Représentant la requête http de l’utilisateur et la réponse à lui revoyer, encore vierge.
Servlet : Principe de base On demande une ressource http à un serveur web Le serveur passe la requête à un programme relai (le conteneur web, actif dès le
démarrage du serveur) qui va instancier une classe java capable de gérer la requête et générer une réponse (c’est la boucle de l’appel). Le conteneur donne aussi au passage, un ensemble d’informations sur lui-même Une fois instanciée, cette classe reste en attente de sollicitations.
La réponse est ‘rendue’ au conteneur puis au client( fin de la boucle).
ClientServeur
WEB
Conteneur de Servlet
Servlet1
Request
Response
Servlet : en pratique Une classe java pur qui herite de GenericServlet ou HttpServlet
On ne l’intancie pas (pas de new MaServlet), c’est le conteneur de servlet qui se charge de tout le cycle de vie de l’objet.
Création Initialisation Appel de ses méthodes Mise à disposition d’objet implicites Destruction
On pense environnement comme en développement windows avec c++ et les fonctions de callback, en java avec les listeners et la machine virtuelle, cette fois, c’est au conteneur qu’il faut penser.
Servlet : Anatomie
SERVLET
Accède à des objets d’informations sur le conteneur
init()
destroy()
service(req, res)
doGet(req, res)doPost(req, res)
Conteneur
-Crée les objets Req et Resp-Appel init() à l’instanciation de le servlet
-Appel à service() avec les objets req et resp Si une requête est destinée à la servlet :Service défini si la requête est de type post ou get et appel doGet() ou doPost en fonction.
-Appel à destroy() lorsque le conteneur s’arrête par exemple
HttpServlet GenericServlet
Du code !import javax.servlet.*;import javax.servlet.http.*; import java.io.*;
public class PremiereServlet extends HttpServlet {
public void init() { } public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html"); PrintWriter out = res.getWriter(); out.println("<HTML>"); out.println("<HEAD><TITLE> Titre </TITLE></HEAD>"); out.println("<BODY>"); out.println("Ma première servlet"); out.println("</BODY>"); out.println("</HTML>"); out.close();
} }
Servletpackage servlets;import java.io.IOException; import java.io.PrintWriter;import javax.servlet.ServletException; import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;
public class NewServlet extends HttpServlet { protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException { response.setContentType("text/html;charset=UTF-8"); PrintWriter out = response.getWriter();} @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); }@Override public String getServletInfo() { return "Short description"; }}
JSP Dans sa forme une page jsp est un fichier texte qui comporte du
code HTML que l’on peut enrichir de code java à travers des balises (tags) spécifiques.
La page jsp s’apparente à une page php mais cache beaucoup plus de ressources.
La page est prise en charge par le conteneur de servlet, en effet, au premier appel de celle-ci, le conteneur va construire une servlet à partir du fichier jsp à l’aide d’un interpréteur. Mécanisme :
Le fichier page.jsp est parser par l’interpreteur qui construit un nouveau fichier texte page_servlet.java.
Le fichier page_servlet.java est compilé, rendant une servlet transparente au développeur accessible par le chemin de la page jsp.
JSP : Phase de traduction
Du code !<%-- Ceci est un commentaire JSP --%> <%@page contentType="text/html"%> <%@page import="java.util.*"%> <html> <head><title>Page JSP</title></head> <body>
<%-- Déclaration d'une variable globale à la classe --%> <%! int nombreVisites = 0; %> <%-- Définition de code Java --%> <%
//Il est possible d'écrire du code Java ici Date date = new Date();
// On peut incrémenter une variable globale pour compter le nombre // d'affichage, par exemple.
nombreVisites++; %>
<h1>Exemple de page JSP</h1>
<%-- Impression de variables --%> <p>Au moment de l'exécution de ce script, nous sommes le <%= date %>.</p> <p>Cette page a été affichée <%= nombreVisites %> fois!</p>
</body> </html>
Schémas
Client Serveur WEB
Conteneur de Servlet
Contexte App1
Contexte App2
Contexte App3
Web.xml
Server.xml
Context.xml
Web.xml
Context.xml
Web.xml
Context.xml
Web.xml
Context.xml
Servlet1
Servlet2
Servlet3
Interprète JSP
Ressources
Sénario 1 : Appel d’une servlet 1) Requête du client au serveur
http://serveur/App1/Servlet2 2) Le serveur oriente la requête vers le conteneur 3) Le conteneur créer ici des objets java qui seront utilisables par la servlet (objets
implicites) 4) Le conteneur recherche la Servlet2 dans le contexte App1.
C’est le fichier web.xml de App1 qui va lui donner les informations necessaires 5) Le conteneur passe les objets implicites à la servlet 6) La servlet utilise les objets implicites (ou pas), créer une réponse 7) La réponse est remise au serveur web (par le conteneur en fait) qui se charge de
la renvoyer au client.
Le conteneur englobe toutes les servlets et gère le cycle de vie, leur création, initialisation, destruction.
Nous verrons qu’il peut aussi mettre à disposition de celles-ci des ressources supplémentaires, intercepter des requêtes destinées à une application ou une servlet précise…
Schémas
ClientServeur
WEB
Conteneur de Servlet
Contexte App1
Contexte App2
Contexte App3
Web.xml
Server.xml
Context.xml
Web.xml
Context.xml
Web.xml
Context.xml
Web.xml
Context.xml
Servlet1
Servlet2
Servlet3
Interprète JSPMaPage.jsp
Servlet_MaPage
Ressources
Sénario 2 : Appel d’une page JSP 1) Requête du client au serveur
http://serveur/App3/MaPage.jsp 2) Le serveur oriente la requête vers le conteneur 3) Le conteneur créer ici des objets java qui seront utilisables par la serlet (objets implicites)…mais
quel servlet ??? Les pages jsp sont en réalité transformées en servlet et le traitement est exécuté par cette dernière lorqu’elle est
disponible. À la première demande d’une page jsp, la serlet qui lui correspond n’existe pas ! Le conteneur sait qu’il faut alors la créer et passe la demande à l’interpreteur JSP pour maPage.jsp
4) Pas de servlet pour cette requête jsp, l’interprèteur le crée et le met à disposition pour le contexte d’App3
Attention, ceci est transparent pour le programmeur. Il ne verra pas se créer la serlet, celle-ci se cache dans l’arborescence de tomcat (cf TD)
5) Le conteneur passe les objets implicites à la serlet 6) Le servlet utilise les objets implicites (ou pas), créer une réponse 7) La réponse est remise au serveur web (par le conteneur en fait) qui se charge de la renvoyer au
client. Remarque : attention aux abus de language… passez l’objet c’est lui donner une référence.
En réalité les choses se partagent et ne se transfert pas.La machine java est derrière tout ces méchanismes.
La Page JSP est transformée une seule fois en servlet au premier appel, l’execution est donc plus lente à ce moment, mais les requêtes suivantes seront rapides car le conteneur utilisera directement la serlet produite.
Application web : structure
Application web : structure Une structure minimale d’une application web est imposée par
les spécifications J2EE. Assembly Root : Répertoire racine de l’application. META-INF : Répertoire méta informations sur l’application
On y trouvera des fichiers de configuration utilisés par l’application directement ou des ressources spécifiques (persistence.xml, struts-config.xml etc...)
WEB-INF : Répertoire informations web contient 3 sous répertoires : lib : Répertoires des jars utilisés par l’application.
Il complète les bibliothèques misent à disposition par le serveur. classes : Répertoire des class compilées du projet tags : Répertoire des librairies de tags personnalisés (ou pas) pour l’application. Fichier web.xml : Descripteur de déploiement de l’application.
Fichier très important pour le développeur il recense toutes servlets, pages jsp et d’autres ressources auxquelles fait appel l’application (source de donnée, filtres, écouteurs etc..)
Vue de développeurArborescence NetBean Arborescence Eclipse
Descripteur de déploiement : web-xmlUn aiguilleur
Un aiguilleur pour les requêtes Le serveur doit pouvoir retrouver les servlets qu’il doit atteindre
à partir de la requête du client. Pour cela le fichier web.xml décrit un mapping de
correspondance en deux étapes: 1) La servlet est nommée
<servlet><description>Servlet exemple</description><display-name>Hello</display-name><servlet-name>Hello</servlet-name><servlet-class>com.test.servlets.Hello</servlet-class>
</servlet>
2)La servlet est associée à une url<servlet-mapping>
<servlet-name>Hello</servlet-name><url-pattern>com.test.servlets.Hello</url-pattern>
</servlet-mapping >
Descripteur de déploiement : web-xmlUn paramètreur Ajouter des paramètres pour l’application
On peut définir des constantes textuelles accessibles dans tout le contexte de l’application<context-param>
<param-name> MON_PARAM </param-name><param-value>valeurDe MON_PARAM </param-value>
</context-param> Il seront accessibles aux servlets par le biais de l’objet implicite servletConfig
getServletContext().getInitParameter("MON_PARAM"); Ajouter des paramètres pour une servlet
Sur le même schéma que précédemment, on définit cette fois des paramètres d’initialisation entre les balises de le serlet concernée:
<servlet> <servlet-name>maServlet</servlet-name> <display-name>Ma Servlet</display-name> <description>Ma Servlet</description> <servlet-class>com.servlet.MaServlet</servlet-class> <init-param> <param-name>MON_PARAM</param-name>
<param-value>Bonjour</param-value> </init-param> </servlet> Accessible par : getInitParameter("MON_PARAM");
Descripteur de déploiement : web-xmlUn surveillant Il peut aussi mettre en place un Listener pour le contexte.
Cette classe particulière réagit quand le contexte de l’application est initialisé ou détruit.
Pour la créer, il suffit d’écrire une classe qui implémente l’interface ServletContextListener
public class MyHttpServletContextListener implements ServletContextListener {
/** Cette méthode appelée lors du démarrage de l'application*/ public void contextInitialized(ServletContextEvent sce)
{System.out.println("L'application vient de démarrer"); }
/** Cette méthode appelée lors de l'arret de l'application*/ public void contextDestroyed(ServletContextEvent sce) { System.out.println("L'application vient de s'arreter"); }
}Ensuite pour la mettre en œuvre, on place sa définition dans le fichier web.xml :<listener>
<listener-class>com.test.MonListenerDeContexte</listener-class></listener>
Ces fichiers java sont écrit dans l’EDI, répertoire de fichiers sources qui se charge généralement de la compilation et place automatiquement les fichiers .class générés dans le répertoire adéquat.
Nous verrons plus loin comment déployer l’application sur le serveur.
Descripteur de déploiement : web-xmlUn gardien Des filtres peuvent aussi être placés en fonction de la ressource à atteindre.
Cela agît comme un aiguillage en boucle, on passe par le filtre avant d’atteindre la ou les urls designées dans un mapping.
Pour créer un filtre on implémente cette fois l’interface Filterpublic void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
Implements Filter throws IOException, ServletException
{//Actions du filtre…… chain.doFilter(request, wrapper);
} La mise en place se fait en agrémentant le fichier web.xml
<FILTER> <FILTER-NAME>monFiltre</FILTER-NAME> <FILTER-CLASS>my.package.doFilter</FILTER-CLASS> </FILTER><filter-mapping> <filter-name>monFiltre</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Le mapping permet de définir quelles requêtes seront dirigées vers le filtre.
REMARQUE : Depuis la version 3.0 des servlets, il est possible de zapper le fichier web.xml en utilisant des annotations directement dans le code qui seront comprises par le serveur ou à la compilation.
Descripteur de contexte : Context.xml• Des ressources supplémentaires et gérées par le serveur peuvent être
misent à disposition d’une application.• Le fichier context.xml décrit ces ressources, ici une DataSource :
<?xml version="1.0" encoding="UTF-8"?> <Context> <!-- Specify a JDBC datasource -->
<Resource name="jdbc/mydatabase" auth="Container" type="javax.sql.DataSource"
username="YOUR_USERNAME" password="YOUR_PASSWORD" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://mysql.metawerx.net:3306/YOUR_DATABASE_NAME? />
<!-- Specify the security realm and location of the users file <Realm className="org.apache.catalina.realm.MemoryRealm" pathname="/tomcat/webapps/ROOT/WEB-INF/users.xml" /> -->
</Context>
Descripteur de contexte : Context.xml La DataSource précédemment décrite sera accessible ensuite aux servlets de
l’application :
// Get DataSource Context ctx = new InitialContext(); DataSource ds =DataSource)ctx.lookup("java:comp/env/jdbc/mydatabase"); // Get Connection and StatementConnection c = ds.getConnection(); Statement s = c.createStatement();
Le serveur gère un espace de noms qui permet de stocker des objets hiérarchisés en arborescence (Comme des répertoires)
La racine pour chaque application sera java:comp/env
Le descripteur de contexte y place au chargement de l’application une source de donnée, Objet DataSource qu’il sait instancier automatiquement.
Il le place pour nous en « jdbc/mydatabase » relativement à la racine
Lorsque l’on veut utiliser cette ressource, il faut récupérer le contexte puis la datasource.
Descripteur de contexte : Context.xmlL’intérêt de la DataSource :
-Déclarée dans Contexte.xml, elle est à disposition de toute l’application et c’est le serveur qui va gérer l’unicité ou un pool de connexions avec la base.
-Il existe un autre fichier Context.xml qui lui est associé au serveur lui-même et non pas à l’application et travailant de paire avec un fichier Server.xml.
- Une DataSource déclarée dans ces fichiers pourra donc être mise à disposition de toutes les applications situées sur le serveur. Un seul chemin vers la base de données complètement géré par le serveur.
Servlet en pratique Accès à la requête utilisateur Accès au contexte de l’application Accès à la réponse Création de beans Redirection
Les objets implicites
Response : Paramètre de la méthode service C’est un lien avec la réponse envoyée au client qui est accessible par un buffer texte.
On y trouve un ensemble de propriétés qui vont définir le format et les caractéristiques de renvoyées.
Sa principale utilité est un accès direct au buffer pour y écrire : On écrit une réponse c’est-à-dire du code HTLM par exemple.
Il est possible de définir un autre format qui indiquera au client que l’on envoie un fichier texte simple, pdf ou tout autre en définissant la propriété ContentType . Les méthodes de l’objet parlent d’elles même :
Par exemple setHeader : redéfinit l’entête de réponse La date du fichier, un code d’erreur etc… Ajout d’un cookie (Class cookie puis response.setCookie)
Request : Paramètre de la méthode service Accès aux propriétés de la requête émise par l’utilisateur
Récupération des paramètres de la requête Accès aux attributs de requêtes, se sont des objets java stockés dans une Map en
mémoire et disponibles tant qu’une réponse définitive n’est pas renvoyée.
Accès à la l’objet session qui lui stocke de la même manière que précédemment des objets java qui eux seront gardés en mémoire pour toute la session utilisateur. C’est l’objet idéal pour créer un panier pour un site d’achats en ligne par
exemple ou encore stocker les caractéristiques d’un client pour une interface personnalisée.
Accès aux cookies de l’utilisateurs.
session: Instance de la classe javax.servlet.http.HttpSession, cet objet est par défaut disponible à toutes les pages qui participe à une session(jsp : sauf si l'attribut session de la directive page est positionné à faux.) Il permet d'accéder aux objets dont la portée est session via la méthode getAttribute.
out: Instance de la classe javax.servlet.jsp.JspWriter , cet objet représente le canal de sortie utilisé pour communiquer la réponse au client (navigateur).Buffer texte
application: Instance de la classe javax.servlet.ServletContext, cet objet contient le contexte de la servlet.
context: Instance de la classe javax.servlet.jsp.PageContext, cet objet permet d'accéder à différentes informations sur l'environnement du serveur.
config: Instance de la classe javax.servlet.ServletConfig, cet objet permet d'accéder à la configuration de la servlet.
Pour les pages jsp nous verrons des objets ajoutés. page: instance de la classe java.lang.Object, cet objet désignant la page JSP elle même,
c'est l'équivalent à this de Java. Prévu initialement pour permettre l'accès des objets Java lorsqu'un autre langage de script était utilisé.
exception: instance de la classe java.lang.Throwable, cet objet représentant un exception non interceptée par le code Java, très utile dans les pages d'erreur.
Les objets implicites (servlet et jsp)
Les Attributs, objets de communication. Le serveur met à disposition du programmeur des espaces mémoires afin de
stocker des objets de toutes sortes nommés attributs. Un attribut est caractérisé par un nom unique auquel est associé l’objet stocké
comme dans une map. Exemple :
Personne p_roger = new Personne(« roger »); Request.setAttribute(« roger »,p_roger);
Pour récupérer l’objet on passe par la clef et on caste en spécifiant le type. Personne untel = (Personne)request.getAttribute(« roger ») La méthode renvoi soit null, soit une instance de la classe java Object qu’il faut donc caster.
Qui peut stocker des attributs : request, session, application : ce qui définit la portée de l’attribut, appelé aussi le scope. Suivant l’objet qui stocke l’attribut et donc suivant son cycle de vie dans le serveur,
l’attribut sera disponible plus ou moins longtemps. Sur une requête, une session, ou sur l’application entière.
Scope : request Un objet disponible au fil de la requête :
Request.setAttribute
Scope : Session Objet disponible sur la session utilisateur:
Request.getSession().setAttribute
Scope : Application Objet disponible pour dans toute l’application, pour tout les
utilisateurs.
getServletContext().setAttribute(« nom »,objet);
Application.setAttribute(« nom »,objet);
RequestDispatcher Aiguiller et transmettre la requête utilisateur.
Cet objet très important permet à une servlet de passer le relais à une autre ou vers une jsp. Transmettant les objets request et response.
Il accède au différentes ressources en se basant sur le chemin depuis la racine ou relativement à la servlet qui l’invoque. Methode : forward
Inclure le résultat d’une servlet ou d’une jsp Methode : include
On s’y retrouve ?
SERVLETresponse
Session utilisateur
Attributes
request
attributes
parametres
Servletconfig
ServletcontextInitParametersWeb.xml
ServletNameWeb.xml
AttributesParametresWeb.xml
ServletDispatcher
Les objets du développeur Les servlets forment l’interface avec le serveur. Elles sont
sollicités par des requêtes externes (utilisateur, liens, formulaires) ou internes (autres servlet requestDispatcher).
Lorsqu’on développe une application, on a bien sur besoin d’objets spécifiques : Objets réalisants des traitements Objets représentants des entités (personne ou autres) Objets de connections à une base de données Objet de communication entre objets de l’application, etc.
Ces types d’objets se créent dans le répertoire source de l’application et sont à disposition des servlets Suivant leurs fonctions, certains auront de multiples instances et il est
judicieux pour d’autres d’être uniques dans une session ou une application.
Design d’application : définitions des rôles de nos objets. Servlets :
Objets capables de manipuler les requêtes et les réponses, d’utiliser les ressources de l’application (objets du développeur) comme celles du serveur. Request, response Objets des packages sources Objets des packages java standards Objets des packages d’entreprise JDK Objets des librairies du serveur Objets des librairies du répertoire WEB-INF/lib
Mais il est pénible de coder une réponse HTML dans une servlet. JSP :
On sait qu’elles sont en réalité des servlets, mais gérées par le conteneur, elles peuvent donc réaliser tout ce que les servlets peuvent faire mais ce n’est pas leur but principal.
Leur fonctionnalité première et de simplifier le codage des réponses HTML et donc d’être orientées WEB. Elles seront donc la base des interfaces avec le client.
Jspformulaire
JspRéponse
ObjetsProgrammeur
appelle utilise
Jspformulaire
JspRéponse
ObjetsProgrammeur
Servlettraitement
appelle utilise
redirige
Jspformulaire
JspErreur
Servletaiguillage
1 appelle utilise
2.1 Erreur de paramètres
JspRéponse
traitement
3.1 redirigeServlet
traitement
ObjetsProgrammeur
Vérifie les paramètres
ObjetsProgrammeur
Traitement
3.2 réponse
4 réponse
Pause
JSP en pratique Une JSP est un fichier texte
Il contient du code html (appelé template) et des balises spécifiques permettant de coder en java les scriptlets.
Transformée par le serveur en servlet Tout ce qu’une servlet peut faire, une jsp peut le faire Il est utile d’aller voir le fichier java correspondant à la
servlet générée afin de bien comprendre et situer ce que les balises de tags jsp produisent. Répertoire work pour tomcat
Transition : JSP => Servlet<%@page contentType="text/html" pageEncoding="UTF-8"%><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html> <head> <meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"> <title>JSP Page</title> </head> <body> <h1>Hello JSP World!</h1> </body></html>
Transition : JSP => Servletpackage org.apache.jsp;
import javax.servlet.*;import javax.servlet.http.*;import javax.servlet.jsp.*;
public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent {
private static final JspFactory _jspxFactory = JspFactory.getDefaultFactory();
private static java.util.List _jspx_dependants;
private javax.el.ExpressionFactory _el_expressionfactory; private org.apache.AnnotationProcessor _jsp_annotationprocessor;
public Object getDependants() { return _jspx_dependants; }
public void _jspInit() { _el_expressionfactory = _jspxFactory.getJspApplicationContext(getServletConfig().getServletContext()).getExpressionFactory(); _jsp_annotationprocessor = (org.apache.AnnotationProcessor)
getServletConfig().getServletContext().getAttribute(org.apache.AnnotationProcessor.class.getName()); }
public void _jspDestroy() { }
public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException {
PageContext pageContext = null; HttpSession session = null; ServletContext application = null; ServletConfig config = null; JspWriter out = null; Object page = this; JspWriter _jspx_out = null; PageContext _jspx_page_context = null;
try { response.setContentType("text/html;charset=UTF-8"); pageContext = _jspxFactory.getPageContext(this, request, response,null, true, 8192, true); _jspx_page_context = pageContext;
application = pageContext.getServletContext(); config = pageContext.getServletConfig(); session = pageContext.getSession(); out = pageContext.getOut(); _jspx_out = out;
out.write("\n"); out.write("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\"\n"); out.write(" \"http://www.w3.org/TR/html4/loose.dtd\">\n"); out.write("\n"); out.write("<html>\n"); out.write(" <head>\n"); out.write(" <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n"); out.write(" <title>JSP Page</title>\n"); out.write(" </head>\n"); out.write(" <body>\n"); out.write(" <h1>Hello JSP World!</h1>\n"); out.write(" </body>\n"); out.write("</html>\n"); } catch (Throwable t) { if (!(t instanceof SkipPageException)){ out = _jspx_out; if (out != null && out.getBufferSize() != 0) try { out.clearBuffer(); } catch (java.io.IOException e) {} if (_jspx_page_context != null) _jspx_page_context.handlePageException(t); } } finally { _jspxFactory.releasePageContext(_jspx_page_context); } }}
Cycle de vie Identique aux servlet
jspInit() _jspService() jspDestroy()
Ces méthodes sont utilisées comme celles des servlets et sont redéfinissables On pourrait imaginer modifier init() tout court mais le server
l’utilise pour la génération de servlet de manière plus complexe, il est donc mis a disposition ces fonctions pour éviter des « collisions »
Eléments de script Quatres types d’éléments de script :
Les directives : indiquent à la pages les informations globales (par exemple les instruction d’importations)
Les déclarations : destinées à la déclaration de méthodes et de variables à l’échelle d’une page
Les scriplets : code Java intégré dans la page Les expressions : sous forme de chaîne, en vue de
leur insertion dans la sortie de la page
JSP : les directives de page Page : informations relatives à la page Include : fichiers à inclure littéralement Taglib : URI d’une bibliothèque de balises utilisée dans la page
<%@ page [language="java"] [extends="package.class"][import="{package.class|package.*}, ..."] [session="true|false"][buffer="none|8kb|sizekb"] [autoflush="true|false"][contentType="mimeType [charset=characterSet]" |
"text/html;charset=ISO-8859-17"][iserrorPage="true|false"]
%>
JSP : les directives de page Définir les "import" nécessaires au code Java de la JSP
<%@ page import="java.io.*"%> Définir le type MIME du contenu retourné par la JSP
<%@ page contentType="text/html"%> Fournir l'URL de la JSP à charger en cas d'erreur
<%@ page errorPage="err.jsp"%> Définir si la JSP est une page invoquée en cas d'erreur
<%@ page isErrorPage="true" %> Déclarer si la JSP peut être exécutée par plusieurs clients
à la fois <%@ page isThreadSafe="false" %>
JSP : les directives de page
JSP : les directives d’inclusion <%@ include ……%>
– Permettent d’inclure le contenu d’un autre fichier dans la page JSP courante
– Inclusion effectuée avant la compilation de la jsp
JSP : les directives d’inclusion
JSP : les balises personnalisées <%@ taglib ……%>
– Permettent d’indiquer une bibliothèque de balisesadresse et préfixe, pouvant être utilisées dans la page
<%@ taglib prefix="pref" uri="taglib.tld" %>
JSP : les déclarations <%! ……%>
– Permettent de déclarer des méthodes et des variables d’instance connus dans toute la page JSP
Les scriplets
Les scriplets
Les expressions
Les commentaires
JSP : éléments de script-objets implicites
JSP : les éléments d’action
JSP : les éléments d’action
JSP : include/param
JSP : include/param
JSP : forward
JSP : useBean
JSP : useBean-Java Bean
JSP : useBean-Java Bean
JSP : useBean-Java Bean
JSP : useBean
JSP : get/setproperty
JSP : get/setproperty
JSP : get/setproperty
Combinaison Servlet et JSP
top related