www.infkoffler.com - Site de cours d'informatique

Accueil

Java Standard Edition

Java EE 5

Visual Basic .Net 2005

Cours Javascript - DOM - DHTML

Nouveautés sur le site

Contacts

Accueil > Java EE 5 > Les applications Web en java

____________________________________________________________________________________________________

Connexion

LES APPLICATIONS WEB EN JAVA

24/12/2007
Ecrit avec JavaEE5 et Eclipse, et Tomcat 4.1 .

I)Les servlets

Une servlet est une entité contenant du code java exécutable sur le serveur( d’où le nom « serv-let »). Sa méthode init( ), par défaut, est sa méthode d’initialisation.
Une servlet est une classe java, c’est donc un fichier .java, qui se trouve dans la partie sources java de l’application( partie « Java Resources : src » du Project Explorer d’eclipse).

N’oubliez pas d’ajouter la librairie servlet.jar aux librairies de votre projet, afin que eclipse ne vous indique pas d’erreurs, et afin qu’il effectue correctement le .war après. Vous trouverez servlet.jar dans le répertoire lib de Tomcat. Pour ajouter cette librairie à votre projet, faites clic droit sur « JRE system library [jdk] » de la partie « Libraries » du Project Explorer. Puis « configure ». Puis cliquer sur le bouton « Installed JREs ». Choisir la JRE. Puis bouton « Edit ». Enfin bouton « Add external JARs ». Donnez alors le chemin vers la librairie servlet.jar de Tomcat. La librairie est ajoutée, dans le project explorer, avec la JRE ( mais n’est pas recopiée en réalité dans la JRE).

I.1) Parallèle avec ASP .net : un conteneur de code java

Une servlet est à peu près l’équivalent des .aspx.cs de ASP .NET, qui contiennent une classe qui hérite de (System.Web.UI.)Page( alors que java hérite de la classe HttpServlet). En ASP .net, une classe Page( héritant de Page, je veux dire) est associée à une web form(c’est-à-dire une page web), donc un .aspx( l’équivalent du .jsp en java). Alors qu’une servlet n’est pas systématiquement reliée à une page web. Remarque : Ceci dit, il est possible en ASP.net(et c# ), de faire une classe c#(dans un fichier .cs) accessible depuis toute l’application web.
Autre remarque : un mapping est possible en java, entre une servlet et une URL. Mais il s’agit d’une URL attribuée à cette servlet, et servant à invoquer la servlet( la philosophie n’est pas la même).

En résumé, en java comme en ASP .net, on a, à chaque fois, une classe qui hérite d’une classe mère particulière, et cette classe sert de « conteneur de code java » .
Un autre point commun, c’est que cette classe « conteneur de code java », est instanciée de façon cachée, sans qu’on ait à faire d’instanciation explicite. On obtient donc un objet servlet( ou un objet Page en ASP .net), qui est un objet conteneur de notre code java, un objet entité de code java( code regroupé selon des caractéristiques communes choisies). Cet objet est instanciée une fois pour toute la durée de vie de l’application web, bien entendu.

I.1.b)Pourquoi ce besoin d’avoir un conteneur de code java ?

Il faut rappeler que l’apport des sites web dynamiques en java, c’est de pouvoir exécuter du code( ici du code Java) sur le serveur. Ce code java, il faut bien le placer quelque part ! La solution de le placer avec le code html, façon PHP, qui est la solution utilisée par les pages .jsp, a ses avantages, mais aussi ses inconvénients( par exemple on ne sépare pas la couche présentation de la couche logique applicative, ou encore l’inconvénient que le code java est exécuté dans « l’ordre » d’affichage du html, c’est-à-dire du haut en bas de la page). La seule solution qui reste était donc de séparer le code java du code html. Or le code java ne peut se trouver que dans des méthodes ; et des méthodes ne peuvent se trouver que dans une classe. D’où le besoin d’une classe conteneur de code java, telle la classe HttpServlet( ou la classe Page de ASP .net).

I.2) Un exemple concret de servlet : un servlet écrit pour sa méthode d’initialisation

Exemple d’une servlet qui sert à l’initialisation. Par exemple, on veut initialiser une collection d’objets.
On crée une classe GestionObjets qui hérite de la classe HttpServlet ( javax. servlet.http.HttpServlet).
Supposons qu’on utilise la classe ArrayList(java.util.ArrayList) pour implémenter notre collection d’objets. ArrayList est efficace pour les accès directs ( contrairement à LinkedList), ArrayList est basé sur un tableau classique, cette classe convient à notre situation. ArrayList est appelée une classe conteneur, car elle sert à contenir d’autres objets. Les classes conteneurs sont implémentées en générique, c'est-à-dire qu’il faut préciser de quel type seront les objets de l’ArrayList, immédiatement après le nom de la classe « ArrayList », entre « < » et « > ». Les ArrayList sont donc des types génériques. Par exemple, ArrayList<String> maListe = new ArrayList<String>( ) ; ArrayList implémente notamment l’interface Collection&th;E>, <E> signifie que le type est générique, c’est la notation de javadoc.

I.3) L’interface (javax.servlet.)Servlet

La classe HttpServlet implémente l’interface (javax.servlet.)Servlet . C’est une interface qui permet de communiquer avec le conteneur d’applets( c'est-à-dire le serveur d’applications, par exemple Tomcat). Cette interface possède cinq méthodes, notamment les 3 méthodes suivantes :

I.3.a) La méthode Init( Javax.Serlvet.ServletConfig conf ) de l’interface Servlet

Javax.Serlvet.ServletConfig est une interface. L’objet ServletConfig est un objet qui est passé à la méthode Init( ) pour permettre au conteneur de Servlet ( autrement dit au serveur d’application, par exemple Tomcat) de passer des informations de configuration à la servlet.

Cette méthode Init de l’interface Servlet, est une méthode qui sert à l’initialisation de la servlet. Cette méthode est appelée une seule fois, et juste après l’instanciation de la servlet.

I.3.ab) La méthode init( ) de la classe (javax.servlet.)GenericServlet

La classe (javax.servlet.)GenericServlet implémente notamment l’interface Servlet.
Cette classe est également la classe mère de la classe HttpServlet( javax. servlet. http.HttpServlet). Par conséquent la classe HttpServlet, qui nous intéresse beaucoup, contient cette méthode init( ) . Nous utiliserons principalement cette méthode init( ) de la classe HttpServlet.

I.3.b) La méthode Destroy( ) de l’interface Servlet

Cette méthode est appelée automatiquement lors de la destruction de la servlet, juste avant sa destruction. Bien entendu, cela permet de libérer des ressources.

I.3.c) La méthode service( ServletRequest req, ServletResponse rep) de l’interface Servlet

Javax.servlet.ServletRequest est une interface
Javax.servlet.ServletResponse est une interface

Cette méthode est appelée lorsque la servlet est appelée. C’est donc la méthode d’action de la servlet, qui nous permet d’agir.

I.3.c.a) Les méthodes doPost( ) et doGet( ) de la classe HttpServlet

Pour nous simplifier la tâche, la méthode service est implémentée dans la classe HttpServlet. Elle appelle soit la méthode doPost( ), soit la méthode doGet( ), suivant la requête du client. Par conséquent, pas besoin d’écrire de méthode service pour HttpServlet, il faut juste écrire le code des méthodes doPost( ) et doGet( ).

- La méthode doGet( )
La méthode doGet( ) est à utiliser lorsque vous voulez faire effectuer un traitement par votre servlet, lorsque celle-ci est invoquée( par exemple invocation par son url, en cas de mapping de la servlet avec une url).
La méthode doGet( ) est donc une méthode particulièrement utile.

-La méthode doPost( )
La méthode doPost( ) est à utiliser lorsque vous avez mis l’URL( mappée) de votre servlet, comme URL réponse d’un formulaire html. C’est donc un cas particulier.

II) Avoir des variables globales à toute l’application Web

   Un problème classique de la programmation web, est de vouloir avoir des variables globales à toute l’application, c'est-à-dire des variables accessibles en-dehors de la page ou du servlet où elles ont été créées.

   « application » est un objet accessible directement dans une page .jsp, et qui est d’une classe qui implémente l’interface javax.servlet.ServletContext . « application » est donc un ServletContext.
D’après javadoc, un ServletContext est un ensemble de méthodes servant à communiquer avec le conteneur de servlet( c’est-à-dire le serveur). Et il y a un ServletContext par application web. C’est donc un objet servant à connaître le contexte de notre application web.

   Pour obtenir le ServletContext dans une servlet( c'est-à-dire dans une classe qui hérite de HttpServlet), il faut faire this.getServletContext( ) ; , qui nous retourne une référence sur un objet ServletContext.

   L’objet ServletContext possède deux méthodes qui vont nous intéresser : la méthode setAttribute( String nomAttribut, Object valeurAttribut), et la méthode getAttribute( String nomAttribut). Lorsque vous voulez, dans une servlet, fixer un attribut de l’application, c'est-à-dire une variable globale à l’application, il faut faire this.getServletContext( ).setAttribute(« monAttribut », monObjet) ;
Pour récupérer cet objet dans une page jsp, faire : monObjet = application. setAttribute( « monAttribut ») ;

III) Le fichier de déploiement web.xml

Le fichier de déploiement web.xml se trouve dans la partie « WebContent » du projet explorer, et dans le répertoire « WEB-INF ».

- Tout se trouve entre les balises <web-app> et </web-app>
- La balise <display-name></display-name> contient le nom de
l’application, mais cela n’a aucune incidence sur le déroulement de l’application.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>NOM_APP</display-name>

</web-app>

- Il contient notamment la déclaration des servlets, entre les balises <servlet ></servlet>. On peut donc choisir les servlets qui seront utilisées dans l’application( et donc initialisées). Car on n’a pas forcément envie d’utiliser toutes les servlets dont on a fournit le code. D’où cette étape indispensable de déclaration des servlets. On peut aussi choisir l’ordre d’exécution des servlets( par rapport à leur méthode d’initialisation), avec la balise <load- on-startup></load-on-startup>.

<servlet>
<servlet-name>nom_servlet</servlet-name> 
<servlet-class>nomPackage.nomClasseServlet</servlet-class>
<load-on-startup>1</load-on-startup> <!—-si >=0, c’est l’ordre d’exécution des init( ) des Servlets -->
</servlet>

- web.xml contient aussi les fichiers de bienvenue:

<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

- On peut effectuer un mapping entre une servlet et une URL :

   Ce mapping a pour effet de pouvoir invoquer la servlet à partir d’une url qui lui est attribuée.

   Pour cela, on utilise la balise <servlet-mapping></servlet-mapping>
   On indique le nom de la servlet à mapper( avec la balise <servlet-name>
</servlet-name>)
   On indique l’URL dans la balise <url-pattern></url-pattern>, par exemple
<url-pattern>http://localhost:8180/appli/nomMapping</url-pattern> Cela a pour effet, à chaque fois que l’URL http://localhost:8180/appli/nomMapping sera demandée, d’appeler la servlet nommée dans la balise servlet-name.

Récapitulatif :

<servlet-mapping>
<servlet-name>nomservlet</servlet-name>
<url-pattern>http://localhost:8180/appli/nomMapping</url-pattern>
</servlet-mapping>

IV) Utilisation des servlets

On a par exemple une HttpServlet, avec une url de mapping.

IV.1) Redirection vers une page web

Pour faire effectuer à la servlet une action de redirection :
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.sendRedirect("mapage.jsp");
}

Lorsque la servlet est appelée par son URL, elle redirige vers la page mapage.jsp

IV.2) Injecter du html

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

   response.setContentType("text/html");
   ServletOutputStream outStream = response.getOutputStream();
   outStream.println("<HTML>\n");
   outStream.println("<HEAD>\n");
   outStream.println("<TITLE>titre</TITLE>\n");
   outStream.println("</HEAD>\n");
   outStream.println("<BODY>\n");
   outStream.println("<P>Ceci est mon texte</P>\n");
   outStream.println("</BODY>\n");
   outStream.println("</HTML>");

}

   La méthode setContentType( provenant de l’interface javax.servlet.ServletResponse) permet de choisir le type de réponse qu’on va renvoyer au client. Pour renvoyer du html, c’est « text/html ».

   Une fois ceci effectué, on a besoin d’un objet de la classe abstraite javax.servlet.ServletOutputStream, qu’on peut obtenir grâce à la méthode getOutputStream( ) de l’objet réponse.

   Il ne reste plus ensuite qu’à utiliser notre objet flux, en envoyant notre code html comme du texte classique, c’est comme si on donnait notre code html tel qu’il se trouve dans un fichier .html, qui est un fichier texte après tout. Il est donc nécessaire de rajouter « \ n » en fin de ligne.

   Remarque : on peut faire exactement la même chose en utilisant Response .getWriter( ). La méthode getWriter est, comme on aurait pu s’en douter, une méthode d’une interface. C’est une méthode de l’interface javax.servlet. ServletResponse. Cette méthode renvoie un objet (java.io.)PrintWriter, qui nous permet d’envoyer un texte sous forme de caractères au client. Il faut également utiliser la méthode setContentType avant.

V) Les JSP( Java Server Pages)

   Les JSP sont l’équivalent des pages .aspx de ASP .net 2.0 . Elles permettent notamment de mélanger du code html et du code Java inclus dans des balises <% %> ( appelé un scriplet).
   Les pages JSP se terminent par l’extension .jsp.

   Que peut-t-on trouver dans une page jsp?
- du code html
- du code java dans des balises <% %> : des scriptlets
- des balises JSP

   En réalité, une page JSP, lorsqu’elle est demandée pour la première fois, est transformée en servlet( ce qui est facilement imaginable, sachant qu’on peut mettre du html à partir d’une servlet, avec les méthodes de flux par exemple, et que le code java de la page JSP sera facilement déportable vers une servlet). Après avoir été créée, cette servlet est compilée, puis elle est exécutée( elle est exécutée, car on demande bien l’exécution de la page JSP, lorsqu’on la demande). Le premier appel de la page JSP est donc toujours plus long, ensuite l’appel prend beaucoup moins de temps car la servlet est déjà créée et compilée, il ne reste plus qu’à l’exécuter.

V.1) Les balises JSP

- Les balises de directives

- Les balises de scripting

- Les balises d’action

V.1.a) Les balises de directives <%@ … %>

Ces balises permettent de donner des directives par rapport à la page JSP elle-même.
Elles sont de la forme <%@ … %>

V.1.a.a) <%@ include … %> :

Permet d’inclure un fichier dans le code source de la page JSP. Elle a pour effet d’inclure le fichier voulu, avant le début du travail du moteur de JSP sur notre page JSP. C’est l’équivalent du #include du langage C. Le fichier peut être un fichier de code HTML, de Java, ou JSP.

Syntaxe : <%@ include file= « … » %>

Cette balise est utile notamment quand on a une partie commune à plusieurs pages, par exemple le pied de page en html. Dans ce cas, n’oubliez pas que vous ne devez pas remettre les balises de départ html. Faites comme si vous écriviez directement à l’endroit voulu de votre page JSP. L’inconvénient est donc que vous devez créer un fichier d’inclusion spécial, qu’on ne peut pas réutiliser directement comme page html.

Exemple : <@ include file = « pied.html » %>

V.1.a.b) <%@ page … %>

Permet de définir des directives sur toute la page JSP. Derrière « page », on ajoute un mot-clé, par exemple « import ».

Exemple : <% page import = « java.io.* » >

V.1.a.c) <%@ taglib … %> :

Permet de créer des balises personnalisées. Nous ne le verrons pas pour l’instant.

V.1.b) Les balises de scripting

Ces balises servent à pouvoir insérer du java.

Le meilleur exemple est la balise <% %> qui sert à écrire un scriptlet. On écrit donc, à l’intérieur de cette balise, le code java qu’on veut voir exécuté.

V.1.b.a) Les balises de scriptlet

   Il s’agit de <% … %>. Cela forme ce qu’on appelle un scriptlet(c'est-à-dire un
script java dans une page JSP).
   Le code java est écrit entre <% et %>, comme des lignes java classiques.
   C’est l’équivalent des mêmes balises en asp .net( qui permettent d’introduire du code c# ou vb .net dans une page .aspx).

V.1.b.b) Les balises d’expression

Syntaxe : <%= expression %> . Pas de ; après l’expression. Et = collé au <%.
Existe aussi en asp .net .

Expression est une expression c#, par exemple varA + 3
Le moteur JSP va d’abord convertir en chaîne de caractères l’expression( varA + 3 ici). Puis le résultat est facilement traduisible dans le html!
Les balises d’expression sont pratiques parfois, quand veut par exemple insérer facilement la valeur d’une variable dans une partie html de la page jsp.

V.1.b.c) les balises de déclarations <%! … %>

Permet de déclarer des variables et des méthodes java. Exemple : <% ! int a ; %>
Aucun code html ne résultera de cette balise.

V.1.c) Les balises d’action

Ce sont des balises JSP « pures ». C’est l’équivalent des balises <asp: …> de ASP.NET.

V.1.c.a) la balise de redirection <jsp:forward>

Exemple : <jsp :forward page= « mapage.jsp » />
Redirige vers la page mapage.jsp

V.1.c.b) la balise <jsp :usebean>

V.1.c.b.1) Qu’est-ce qu’un bean ?

C’est tout simplement un objet classique. Mais qui répond à certaines conditions : il doit posséder ses accesseurs pour tous ses attributs. De plus, ces accesseurs doivent respecter certaines normes :

getPrenom( ) : get, suivi du nom de l'attribut, avec la première lettre en majuscule.
setAge( ) : set, suivi du nom de l'attribut, avec la première lettre en majuscule.
isOccupe( ) : is, suivi du nom de l'attribut booléen, avec la première lettre en majuscule.

Enfin, le bean doit posséder un constructeur par défaut. Ce qui présente des intérêts, par exemple c’est une garantie qu’on peut toujours créer un objet de cette classe, et aussi cette création peut être faite avec un code généré automatiquement.

L’intérêt est d’obtenir une garantie sur la structure de la classe, de façon à permettre à Java d’effectuer des traitements intelligents sur l’objet. Donc un bean, c’est pour aider Java, quand il peut avoir besoin d’aide. Ces garanties du bean permettent d’effectuer facilement un mapping en ayant uniquement les noms des attributs. Car on est sûr de pouvoir retrouver les accesseurs à partir du nom de l’attribut, grâce aux normes de nommage respectées, et grâce au fait qu’on est certain que tous les accesseurs sont présents.

V.1.c.b.2) Revenons à la balise <jsp :usebean>

< jsp :usebean id = « monObjet » scope = « session » class = « monPackage.maClasseBean » >

L’attribut id est le nom de l’objet.

scope est la portée de l’objet. Ici l’objet existe pour toute la durée de la session, et pour toutes les pages jsp.

Class est le nom de la classe du bean.

VI) Utiliser Tomcat( essayé avec Tomcat 4.1)

On doit mettre, d’après mon expérience, le .war et le .war décompacté( qui forme un seul répertoire) dans le répertoire webapps de Tomcat. Si on met seulement le .war, ou si on met seulement le répertoire décompacté de l’application web, ca ne marche pas.

Possibilité de travail avec Eclipse : on peut importer un .war avec Eclipse. Il va créer un dossier correspondant à l’application, et on travaillera avec ce dossier. C’est-à-dire que les modifications que vous allez faire dans Eclipse pour ce projet, auront pour effet de modifier les fichiers de ce répertoire, et bien entendu ne modifieront pas le .war.

Quand on veut essayer l’application, on peut exporter en .war, vers le dossier webapps de Tomcat. On est alors obligé de décompresser nous-même le .war ( souvent il suffit d’un clic droit, si vous avez un logiciel de compression comme Izarc).

Remarque : parfois le simple fait de placer un .war dans le dossier webapps de Tomcat, le décompresse automatiquement, comme s’il y avait une sorte de ‘trigger’ comme il en existe en base de données, qui fait déclencher la décompression automatiquement, pour nous rendre service. Je présume que c’est le logiciel Tomcat qui rend ce service. Mais ce déclenchement de décompression n’est pas systématique, je n’en ai pas bien compris la règle !

Personnellement, quand je veux sauvegarder pour moi mon projet web, j’exporte en .zip( Export -> General -> Archive File), ou alors je sauvegarde le répertoire du projet directement( en dehors d’eclipse).
Puis, pour importer, je n’importe pas le zip dans eclipse, car je n’ai pas bien compris comment ca marche ! Je décompresse le .zip en dehors d’eclipse( par exemple avec Izarc). Puis je fais « import », et on peut importer un projet qui n’est pas zipé ! Il suffit de faire File -> Import -> General -> Existing project into workspace, et d’indiquer le chemin du répertoire du projet (dézippé).
Ou bien je peux importer directement le projet que j’avais gardé non zipé, par la même manipulation(il suffit de faire File -> Import -> General -> Existing project into workspace, et d’indiquer le chemin du répertoire du projet).

Personnellement je réserve les .war uniquement pour Tomcat, pour pouvoir essayer ; dans ce cas là, j’exporte en .war. Ou alors, je fais un import d’un .war uniquement si quelqu’un m’a donné une appli sous forme de .war, et donc je n’ai pas le choix, la première fois, que de l’importer en .war.
Il m’est arrivé quelques soucis en travaillant avec les .war et eclipse, et je n’avais pas trouvé d’explications à ces problèmes. Donc j’évite au maximum de travailler en .war avec eclipse.

RETOUR HAUT