Transcript Serveur dapplications JEE (1)

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 :




Un serveur d’application bien connu : TOMCAT


Sun Java server
Glassfich
WebLogic Application Server
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
Tomcat
Serveur JEE complet
Comparaison de serveurs….

Apache

Serveur web simple :



Apache + CGI


Comme un plug-in, permet à apache de rendre ses pages web dynamiques.
Apache + php




Pas de page dynamiques
Fournisseur de fichiers
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 serveur
Représentant la requête http
de l’utilisateur
et la réponse à lui revoyer,
encore vierge.
Crée les objets java Request et
Response .
Web.xml
Lit les fichiers de config généraux
et du contexte d’application, Server.xml
crée
Context.xml
Les objets implicites
Si 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.
Request
Response
Contexte
d’application
Web.xml
Context.xml
Objets implicites
Filter
Listener
Ressources.
Filter
Listener
Ressources.
Rend la réponse de le serlet
et/ou exécute les actions qu’elle
demande.
Servlet
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).
Conteneur de Servlet
Client
Serveur
WEB
Request
Response
Servlet1
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
HttpServlet
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
SERVLET
Accède à des objets
d’informations sur le conteneur
init()
destroy()
service(req, res)
doGet(req, res)
doPost(req, res)
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();
Servlet
package 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
Server.xml
Conteneur de Servlet
Ressources
Web.xml
Context.xml
Client
Serveur
WEB
Contexte
App1
Contexte
App2
Contexte
App3
Web.xml
Web.xml
Web.xml
Context.xml
Context.xml
Context.xml
Servlet
1
Servlet
3
Servlet
2
Interprète JSP
Sénario 1 : Appel d’une servlet

1) Requête du client au serveur




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.






http://serveur/App1/Servlet2
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
Server.xml
Conteneur de Servlet
Web.xml
Context.xml
Client
Serveur
WEB
Ressources
Contexte
App1
Contexte
App2
Contexte
App3
Web.xml
Web.xml
Web.xml
Context.xml
Context.xml
Context.xml
Servlet
1
Servlet
2
Servlet
3
Servlet_
MaPage
MaPage.jsp
Interprète JSP
Sénario 2 : Appel d’une page JSP

1) Requête du client au serveur



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


http://serveur/App3/MaPage.jsp
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éveloppeur
Arborescence NetBean
Arborescence Eclipse
Descripteur de déploiement : web-xml
Un 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-xml
Un 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-xml
Un 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-xml
Un 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 Filter
public 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 Statement
Connection 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.xml
L’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.
Les objets implicites (servlet et jsp)






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 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 :



Pour récupérer l’objet on passe par la clef et on caste en spécifiant le type.



Personne p_roger = new Personne(« roger »);
Request.setAttribute(« roger »,p_roger);
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.


Il accède au différentes ressources en se basant sur le
chemin depuis la racine ou relativement à la servlet qui
l’invoque.


Transmettant les objets request et response.
Methode : forward
Inclure le résultat d’une servlet ou d’une jsp

Methode : include
On s’y retrouve ?
Session utilisateur
parametres
request
attributes
Attributes
response
InitParameters
Web.xml
SERVLET
ServletName
Web.xml
ServletDispatcher
Servletcontext
Servletconfig
Parametres
Web.xml
Attributes
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.
Jsp
formulaire
appelle
Jsp
Réponse
utilise
Objets
Programmeur
Jsp
formulaire
appelle
Servlet
traitement
redirige
Jsp
Réponse
utilise
Objets
Programmeur
Jsp
formulaire
Servlet
aiguillage
1 appelle
utilise
Objets
Programmeur
Vérifie les paramètres
2.1 Erreur de paramètres
Jsp
Erreur
4 réponse
Jsp
Réponse
traitement
Servlet
traitement
Objets
Programmeur
Traitement
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 => Servlet
package 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


Définir le type MIME du contenu retourné par la JSP


<%@ page errorPage="err.jsp"%>
Définir si la JSP est une page invoquée en cas d'erreur


<%@ page contentType="text/html"%>
Fournir l'URL de la JSP à charger en cas d'erreur


<%@ page import="java.io.*"%>
<%@ 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 balises
adresse 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