|
Servlet & JSP - Développement Web
2.2.Fonctionnement
2.2.1.Les requêtes
2.2.1.1.Une requête HTTP de
base
Une requête HTTP est effectuée par un navigateur Web
(appelé aussi client) auprès d’un serveur Web
afin de récupérer le contenu d’une page Web.
Les
différentes étapes du processus sont les suivantes :
- Le
navigateur se connecte au serveur
- Le
navigateur envoie sa requête au serveur
- Le
serveur cherche la page demandée (la réponse)
- Le
serveur commence à envoyer le contenu de la page « réponse »
(ou une page d’erreur)
- Le
navigateur affiche la page au fur et à mesure qu’il la
reçoit
- Une
fois le transfert terminé, le navigateur ferme la connexion
Remarque : Dans le cas d’une requête simple
(vers une page html par exemple) aucun moteur de servlet n’intervient
pour la génération du résultat.
2.2.1.2.Une requête sur un
serveur Java
Le serveur Web doit s’accompagner d’un module
supplémentaire qui gèrera les servlets. Celui-ci est
appelé « moteur de servlets » ou
« conteneur de servlets ». Ce module est soit
intégré directement au serveur Web soit sous forme de
moteur indépendant. Nous expliquerons ci-après la
différence entre ces deux technologies. Dans notre exemple,
nous allons prendre le cas où notre moteur de servlets est
indépendant (afin de mieux comprendre la distribution des
tâches entre les deux composants).
Les différentes étapes du processus sont les
suivantes :
-
Le navigateur se connecte au serveur et envoie sa requête
-
Le serveur détecte que l’on veut un accès à
une servlet et transfert donc la requête au moteur de servlets
-
Le moteur vérifie que la servlet est instanciée
-
Si c’est le premier appel, le moteur crée une instance
de la servlet et appelle la méthode init() de
celle-ci
-
Le moteur appelle ensuite la méthode service()
de la servlet. Cette méthode reçoit deux objets en
paramètres :
-
Le premier représentant la requête du client
-
Le deuxième représentant la réponse à
donner à ce client
-
Le moteur retourne le résultat généré au
serveur web qui le renvoie au client.
-
Le client affiche la page et ferme la connexion
Lors des appels suivants aucune instance ne sera créée
puisque le moteur utilise toujours la même. Dans le cas de
plusieurs appels synchrones (et d’une servlet générique)
le moteur créé pour chaque appel un thread particulier
qui générera le résultat pour l’appel
associé.
2.2.1.3.Moteur de Servlets
Mode Autonome
Un moteur de servlet autonome est un moteur qui est totalement
indépendant, c'est-à-dire qu’il contient
également un serveur Web. Toutes les requêtes passent
par le moteur de servlet, qu’elles appellent une page statique
basique ou une servlet.
Ce mode est surtout utilisé lorsque l’on utilise
uniquement des servlets ou que l’on souhaite les tester (lors
de développement en local par exemple).
2.2.1.4.Mode Lié au serveur
web
Le moteur de servlet est le plus souvent lié au serveur Web.
En effet, dans la majorité des cas, les servlets sont couplées
avec les JSP ou tout autre type de pages accessibles via ce serveur
Web. Le fait que le moteur soit indépendant du serveur Web
permet d’optimiser les temps de réponses car le moteur
n’est sollicité que pour le traitement des servlets (et
non pour toutes les requêtes).
Cependant la plupart des moteurs de servlet peuvent être
utilisés aussi bien en mode autonome qu’en mode lié.
2.2.2.Configuration
2.2.2.1.Apache Tomcat
Pour indiquer quels dossiers sont partagés sur le serveur vous
devez créer un « Context Path » sur le
fichier de configuration du serveur : « server.xml ».
Ce fichier permet de spécifier une multitude d’informations
concernant le paramétrage du serveur, cependant nous nous
attarderons que sur les spécifications de base pour
l’utilisation de servlet et JSP.
Il vous permet notamment de configurer différents noms d’hôtes
(« host ») afin de spécifier différents
paramètres pour chacun d’eux.
Voici le contenu d’une balise host de base pour la
configuration de localhost (hôte par défaut).
<Host
name="localhost" debug="0" appBase="webapps"
unpackWARs="true"
autoDeploy="true"
xmlValidation="false"
xmlNamespaceAware="false">
<Logger
className="org.apache.catalina.logger.FileLogger"
directory="logs"
prefix="localhost_log." suffix=".txt"
timestamp="true"/>
<Context path="/localhost"
reloadable="true"
docBase="C:\www_root\localhost\"
workDir="
C:\www_root\localhost\work" />
<Context path="/localhost2"
reloadable="true"
docBase="C:\www_root\localhost2\"
workDir="C:\www_root\localhost2\work"
/>
</Host>
L’élément principal à retenir ici est la
balise : « Context ». En effet
c’est elle qui va permettre de définir des « Context
Path » et donc de partager des dossiers de votre disque
dur.
Dans l’exemple ci-dessus nous définissons 2 « Context »
qui sont mappés sur des dossiers locaux.
Le premier : localhost est mappé sur :
« C:\www_root\localhost\ ».
Le second : localhost2 est mappé sur :
« C:\www_root\localhost2\ ».
Vous pourrez accéder à ces deux « context »
depuis votre navigateur web via les adresses :
http://localhost:port/localhost/
et http://localhost:port/localhost2/.
Le port est défini dans le fichier de configuration du serveur
(par défault il est égal à : 8080).
2.2.2.2.Sun Application Server
Une fois installé, le serveur vous crée un premier
serveur virtuel. Un dossier de paramétrage est alors créé ;
il porte le nom suivant:
https-[NomDevotreMachine.Utilisateur.com]. Cette structure
peut changer en fonction des paramètres que vous avez choisi
lors de votre installation. Nous utiliserons supinfo.labosun.com
pour nos exemples. Nous allons nous attacher au dossier config.
Dans celui-ci vous avez le fichier : default-web.xml qui
correspond au fichier par défaut utilisé pour les
applications Web de votre serveur virtuel. Vous avez également
un fichier server.xml qui va nous être utile pour
configurer l’équivalent des « context path »
vus précédemment.
Pour indiquer au serveur un mappage de dossier, il faut ajouter la
balise suivante dans la balise <VS …></VS> :
<WEBAPP uri="/pathMap"
path="[Lecteur]:[Chemin]"enabled="true"/>
Voici ce que cela donne pour notre exemple :
<VSCLASS id="vsclass1"
objectfile="obj.conf" rootobject="default"
acceptlanguage="off">
<PROPERTY name="docroot"
value="d:/Sun/WebServer6.1/docs"/>
<VS
id="https-supinfo.labosun.com" connections="ls1"
mime="mime1" aclids="acl1"
urlhosts="supinfo.labosun.com" state="on">
<PROPERTY name="docroot"
value="d:/Sun/WebServer6.1/docs"/>
<USERDB id="default"/>
<SEARCH>
<WEBAPP uri="/search"
path="d:/Sun/WebServer6.1/bin/https/webapps/search"
enabled="true"/>
</SEARCH>
<WEBAPP
uri="/localhost" path="C:\www_root\localhost"
enabled="true"/>
<WEBAPP
uri="/localhost2" path="C:\www_root\localhost2"
enabled="true"/>
</VS>
</VSCLASS>
Nous avons, comme pour l’exemple précédent, mappé
localhost et localhost2 aux deux dossiers respectifs :
« C:\www_root\localhost »
et « C:\www_root\localhost2 ».
2.2.3.Compilation de servlets et
tests
Nous allons dans cette partie utiliser une servlet la plus basique
qui puisse exister. Elle affichera simplement un « Hello
World » lors de son appel par le client.
Voici son
code :
import
java.io.IOException;
import
java.io.PrintWriter;
import
javax.servlet.GenericServlet;
import
javax.servlet.ServletRequest;
import
javax.servlet.ServletResponse;
public
final class
HelloServlet extends GenericServlet
{
public
void service (ServletRequest req,
ServletResponse res)
throws
IOException
{
res.setContentType
(“text/html”);
PrintWriter pageWriter =
res.getWriter();
pageWriter.println(“<html>”);
pageWriter.println(“<body>”);
pageWriter.println(“Hello
World”);
pageWriter.println(“</body>”);
pageWriter.println(“</html>”);
}
}
2.2.3.1.Compilation
Si vous souhaitez exécuter la compilation à partir
d’une ligne de commande et du compilateur javac du JDK vous
devrez vérifier que votre variable d’environnement :
CLASSPATH contient bien un chemin pointant vers les fichiers
JAR des servlets standard (librairies).
Ensuite vous n’avez qu’à exécuter la
commande :
javac HelloServlet.java
Le compilateur vous crée un fichier de classe qu’il
faudra mettre à un endroit précis en fonction du moteur
de servlets que vous utilisez.
2.2.3.2.Déploiement
Pour utiliser votre servlet il faut maintenant la déployer.
Apache Tomcat
et Sun Application Server
Nous allons déployer la servlet basique pour l’exemple.
Tout d’abord, il faut que vous ayez au moins un « context
path » sur votre serveur (nous utiliserons le context :
localhost).
Voici l’arborescence que l’on doit utiliser pour faire
fonctionner les servlets :
/ => Racine du context
/.classpath => Fichier de définissions des chemins
aux librairies
/WEB-INF/classes => Dossier qui contient les packages et
servlets
/WEB-INF/lib => Dossier qui peut contenir des librairies
externes
/WEB-INF/web.xml => Fichier de configuration de
l’application
/work/ => Dossier de travail pour le moteur de servlet
Nous plaçons donc notre fichier : HelloServlet.class
dans le dossier : /WEB-INF/classes/.
Nous devons maintenant indiquer au moteur de servlet que nous
souhaitons utiliser ce context en tant que « web-application ».
Cela se fait via le fichier web.xml.
Voici ce que doit contenir au minimum notre fichier pour que notre
servlet puisse fonctionner :
<?xml version="1.0"
encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun
Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>Web.xml
de base</display-name>
<description>
Fichier xml de définition
d’une application Web-apps de base.
</description>
<!-- Définition des
servlets présentes dans l’application -->
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>HelloServlet</servlet-class>
</servlet>
<!-- Mappage de noms pour
les servlets -->
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/servlet/Hello</url-pattern>
</servlet-mapping>
</web-app>
Nous pouvons remarquer que nous spécifions que c’est une
web-app par le biais de la balise : <web-app></web-app>
Nous indiquons alors que cette web-app contient la servlet
HelloServlet qui correspond à la classe HelloServlet(.class).
Et finalement nous « mappons » le path :
servlet/Hello à la servlet. Cela nous permet alors
d’accéder au résultat de la servlet via
l’adresse : http://localhost:8080/localhost/servlet/Hello
Remarque : il faut bien respecter l’ordre des
balises, cela signifie que vous ne pouvez pas mettre une balise
<servlet> suivie d’une balise <servlet-mapping>
puis à nouveau une balise<servlet>. En effet, il
n’est pas certain que tous les serveurs parsent correctement ce
genre de fichier.
|
|
 |
