Installation et prise en main d'un environnement

Le schéma ci-dessous présente une architecture 3-tiers (N-tiers). Elle décrit la communication entre un client, un serveur d'application et une base de données.

1. Ouverture d'une page Internet d'une application Java Web par le navigateur (Firefox, Opera, etc.).

• Envoi d'une requête HTTP.

2. Localisation du serveur qui héberge la page Web demandée (Internet, couches TCP/IP, OSI, etc.).

• L'OS envoie la requête par Internet ou le réseau local.

3. Le serveur d'application (application qui fonctionne sur le serveur) traite la demande (ex. : Apache-Tomcat, etc.).

• Localisation de la page ou de la ressource demandée.
• Si la page contient du code Java, le serveur d'application l'exécute.

4. L'application Web peut se connecter à un serveur de données (ex. : MySQL, Pgsql, Oracle, etc.).

• Par exemple en utilisant les classes du JDBC.

5. Réception de la requête issue du SGBD.

• L'application Java traite le résultat de la requête.

6. Retour du résultat des traitements au navigateur client.

• Le serveur d'application renvoie le résultat de la demande au navigateur client.

7. Le navigateur affiche le résultat de la page demandée.

JDK : permet de compiler et d'exécuter des applications Java.

Tomcat : conteneur web pour les applications Java Web (généralement intégré dans un serveur d'application, comme Jboss par exemple).

Ant : logiciel utilisé pour la compilation et le déploiement d'un projet Java Web.

Eclipse : environnement de développement pour les applications Java.

Remarque : le paquetage wtp-all-in-one-sdk-R-1.5.0-200606281455-win32.zip (wtp signifie Web Tools Package) a été choisi pour utiliser Eclipse en environnement J2EE. Il contient Eclipse Platform et les plugins associés pour la programmation Web.

Les logiciels sont disponibles sur Internet :

Le JDK (Java Development Kit) permet de créer des applications Java. Il contient des outils de compilation et une version du JRE.

Le JRE (Java Runtime Environment) permet d'exécuter des applications Java.

Lancer l'exécutable jre-1_5_0_04-windows-i586-p.exe téléchargé sur le site de Sun Microsystems. L'installation personnalisée permet de choisir le répertoire d'installation et d'ajouter des supports de langues, des polices et des fichiers multimédias. Les supports de langues et les fichiers multimédias supplémentaires ne sont pas nécessaires dans les exemples à venir.

Si la variable d'environnement JAVA_HOME n'est pas définie après l'installation, il faut la créer et lui donner comme valeur le chemin du répertoire d'installation du JDK. Cette variable est interrogée par un certain nombre d'applications utilisant Java.

Exemple : %JAVA_HOME% = C:\Program Files\JAVA\ jdk1.5.0_04

Le JRE est accessible via %JAVA_HOME%\jre.

Pour accéder directement aux outils de compilation JAVA, comme javac.exe, il faut ajouter le chemin des binaires du JDK au PATH :

Exemple : %PATH% = %PATH% ; %JAVA_HOME%\bin

Dans une fenêtre DOS, il est désormais possible de taper la commande suivante pour vérifier que la version du runtime utilisée est correcte :

C:\>javac -version
javac 1.5.0_04
[...]

-> À partir de ce moment, il est possible de créer et de compiler des applications Java.

Tomcat est un conteneur web qui permet d'exécuter des applications Java Web. Apache représente de son côté le serveur HTTP qui reçoit les requêtes du navigateur Web (requêtes HTTP).

Lancer l'exécutable apache-tomcat-5.5.17.exe. L'installation ne fournit pas d'exemple de programmes ni d'application pour l'administration du serveur d'application par défaut. Il faut choisir pour cela l'installation personnalisée, qui permet par ailleurs de sélectionner le répertoire d'installation.

Durant l'installation, trois paramètres sont demandés :

• le port de connexion HTTP, c'est-à-dire le port à utiliser pour ce connecter au serveur d'application Tomcat (par défaut 8080) ;
• le nom et le mot de passe de l'administrateur des applications hébergées sur le serveur Tomcat ;
• le chemin du JRE. Exemple : %JAVA_HOME%\jre.

Pour vérifier que l'installation est correcte, il suffit de taper le lien http://127.0.0.1:8080/ dans un navigateur. La page d'accueil de Tomcat doit s'afficher :

Si cette page ne s'affiche pas, il faut vérifier que le service est bien démarré. Dans le sous-répertoire bin du répertoire d'installation de Tomcat, il existe un exécutable tomcat5w.exe qui permet de gérer le lancement du serveur.

La documentation http://127.0.0.1:8080/tomcat-docs contient des informations très intéressantes à parcourir.

• bin : binaires, scripts de démarrage ou d'arrêt de Tomcat.
• common : bibliothèques communes à Tomcat et à toutes les applications Web déployées.
• conf: contient les fichiers de configuration de Tomcat.
• logs : fichiers de logs.
• server : contient les applications non déployées sur le serveur, par exemple l'outil d'administration manager.
• shared : bibliothèques communes à toutes les applications Web uniquement.
• temp : répertoire temporaire.
• webapps : applications Web déployées.
• work : contient le cache d'exécution de chaque application Web démarrée.

Pour la description détaillée des répertoires, cf.http://127.0.0.1:8080/tomcat-docs/introduction.html.

Tous les fichiers de configuration se trouvent dans le répertoire $CATALINA_HOME\conf. On trouve les fichiers de configuration suivants :

• context.xml: paramètres du contexte commun à toutes les applications Web ;
• server.xml: paramètres du serveur (port d'écoute, moteurs, services, etc.) ;
• web.xml: définit des ressources par défaut pour l'ensemble des applications ;
• tomcat-users.xml : définit les rôles, les groupes, et les utilisateurs gérés par Tomcat.

Remarque : $CATALINA_HOME désigne la racine du répertoire d'installation de Tomcat.

DESCRIPTION DU CONTEXTE : CONTEXT.XML

Le fichier de contexte context.xml du serveur ne contient qu'un seul paramètre qui définit le chemin par défaut vers le fichier de ressources interrogé par Tomcat pour chaque application Web. L'exemple suivant indique que le serveur utilise le chemin WEB-INF/web.xml, relatif à la racine de chaque application.

<Context>
    <!-- Default set of monitored resources -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>

CONFIGURATION DU SERVEUR : SERVER.XML

Voici le contenu du fichier server.xml.

• L'élément server est la racine du fichier de configuration, il contient un ensemble de services.
• Un service représente une entité indépendante capable de traiter les demandes d'un client. Il contient un ensemble de connectors et un container principal.
• Un connector représente l'interface entre les requêtes clientes et un service particulier. Chaque connecteur écoute les requêtes entrantes sur un port.
• Un container représente un ensemble de composants dont la fonction est de traiter les requêtes entrantes en les envoyant aux applications Web. L'engine (moteur) est le conteneur principal, il reçoit les requêtes des connecteurs, il les traite et transfère les résultats aux connecteurs pour que ces derniers les retournent aux clients.

Le fichier server.xml définit tout d'abord le port d'écoute d'une commande d'arrêt du serveur. L'attribut shutdown contient la commande à envoyer pour stopper le serveur (ici SHUTDOWN).

<Server port="8005" shutdown="SHUTDOWN">
[&#8230;]
</Server>

La balise <Global JNDI resources> contient la configuration des ressources globales JNDI. Ces ressources stockent des informations accessibles depuis Tomcat et toutes les applications Web déployées.

On trouve par exemple la base des données interne des utilisateurs tomcat-users.xml définie un peu plus loin.

<!-- Global JNDI resources -->
  <GlobalNamingResources>

    <!-- Test entry for demonstration purposes -->
    <Environment name="simpleValue" type="java.lang.Integer" value="30"/>

    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
       description="User database that can be updated and saved"
           factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
          pathname="conf/tomcat-users.xml" />

  </GlobalNamingResources>

Catalina est le service installé par défaut :

<!-- Define the Tomcat Stand-Alone Service -->
  <Service name="Catalina">
  [...]
  </Service>

Dans ce service, on définit un ensemble des connecteurs :

• le connecteur HTTP qui écoute les requêtes clientes sur le port 8080. C'est celui qu'on utilise avec le navigateur Web. Pour changer le port d'écoute, il suffit de modifier le paramètre port :

    <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
    <Connector port="8080" 
               maxHttpHeaderSize="8192"
               maxThreads="150" 
               minSpareThreads="25"                        
               maxSpareThreads="75"
               enableLookups="false" 
               redirectPort="8443" 
               acceptCount="100"
               connectionTimeout="20000" 
               disableUploadTimeout="true" />

• Le connecteur AJP qui fait le lien entre Tomcat et un serveur Web Apache :

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" 
               enableLookups="false" 
               redirectPort="8443" 
               protocol="AJP/1.3" />

Le moteur du serveur d'application chargé de traiter les requêtes issues des connecteurs pour le compte du service Catalina est le suivant :

<!-- Define the top level container in our container hierarchy -->
    <Engine name="Catalina" defaultHost="localhost">
      
      <!-- This Realm uses the UserDatabase configured in the global JNDI
           resources under the key "UserDatabase".  Any edits
           that are performed against this UserDatabase are immediately
           available for use by the Realm.  -->
      <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
             resourceName="UserDatabase"/>

L'attribut defaultHost du moteur est relié à la balise Host dont le nom est localhost. Elle précise la localisation des applications Web gérées par le service Catalina :

<!-- Define the default virtual host
           Note: XML Schema validation will not work with Xerces 2.2. -->
      <Host name="localhost" 
            appBase="webapps"
            unpackWARs="true" 
            autoDeploy="true"
            xmlValidation="false" 
            xmlNamespaceAware="false">
      </Host>

    </Engine>

Pour des informations complémentaires ou supplémentaires, il faut se référer à l'adresse http://127.0.0.1:8080/tomcat-docs/config/server.html.

RESSOURCES D'UNE APPLICATION : WEB.XML

Le fichier web.xml décrit le comportement par défaut des applications Web. Il spécifie tout d'abord la version des spécifications du J2EE utilisée :

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
         version="2.4">

Tomcat contient une servlet default chargée de lister le contenu d'un répertoire. Lorsque l'on accède à un répertoire par une URL qui se termine par l'url-pattern '/' et que cette URL n'est pas mappée (i.e. n'est pas traitée par une application), on invoque la DefaultServlet.

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<!-- The mapping for the default servlet -->
   <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

Pour des infos plus précises, cf. http://127.0.0.1:8080/tomcat-docs/default-servlet.html.

La servlet suivante permet de compiler une page JSP (les pages JSP sont compilées en servlets) :

<servlet>
    <servlet-name>jsp</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
    <init-param>
        <param-name>fork</param-name>
        <param-value>false</param-value>
    </init-param>
    <init-param>
        <param-name>xpoweredBy</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>3</load-on-startup>
</servlet>

Chaque accès à une page dont l'extension est jsp ou jspx invoque la servlet JspServlet.

    <!-- The mapping for the JSP servlet -->
    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jspx</url-pattern>
    </servlet-mapping>

Dans le fichier web.xml, il est possible de modifier la durée d'une session en minutes :

<session-config>
    <session-timeout>30</session-timeout>
</session-config>

Pour configurer la page de démarrage par défaut que Tomcat doit charger, il suffit de procéder de la manière suivante :

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

Ainsi, si l'application contient un tel nom de fichier dans le répertoire racine de l'application, il sera affiché. Sinon, une erreur error 404 (FILE NOT FOUND) sera affichée.

Enfin, une section décrit la liste complète des types MIME supportés et gérés par le serveur Tomcat.

[...]

UTILISATEURS TOMCAT : TOMCAT-USERS.XML

Le fichier tomcat-users.xml contient les utilisateurs, les groupes et les rôles utilisés dans Tomcat :

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <role rolename="manager"/>
  <role rolename="admin"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
  <user username="nom_administrateur" password="mot_de_passe" roles="admin,manager"/>
</tomcat-users>

Les rôles manager et admin sont définis par défaut. Le premier permet d'utiliser l'outil manager de Tomcat, et le second l'outil d'administration admin. Ces deux rôles ont été attribués lors de l'installation de Tomcat.

Pour accéder aux outils d'administration, il faut s'identifier avec le compte d'administrateur. Si ce compte n'a pas été créé lors de l'installation de Tomcat, il faut l'ajouter manuellement dans le fichier des utilisateurs $CATALINA_HOME/conf/tomcat-users.xml.

TOMCAT WEB APPLICATION MANAGER

Manager est l'outil d'administration des applications Web disponibles sur le serveur Tomcat (cf. http://127.0.0.1:8080/tomcat-docs/manager-howto.html). Il est possible de démarrer une application, de l'arrêter, de la suspendre ou de la supprimer. Lorsque l'on utilise l'interaction d'Ant avec Tomcat (cf. chapitre sur Ant), c'est en fait le Manager que l'on utilise, de façon transparente.

Il est possible de déployer un projet qui n'est pas listé dans l'écran précédent en utilisant un fichier WAR ou un fichier de contexte au format XML :

Le Context Path correspond au chemin de déploiement de l'application, par exemple /test1. On pourra ensuite accéder à cette application par le lien http://127.0.0.1:8080/test1/. Si un fichier de configuration XML est indiqué dans le champ XML configuration File URL, le chemin de contexte est déjà indiqué, il n'est donc pas nécessaire de le repréciser.

Voici un exemple de fichier de configuration test1.xml pour l'application test1 (cf. http://127.0.0.1:8080/tomcat-docs/config/context.html pour plus d'information sur le contexte) :

<Context docBase="${catalina.home}/server/webapps/test1"
         privileged="true" 
         antiResourceLocking="false"   
         antiJARLocking="false">
  <!-- Link to the user database we will get roles from -->
  <ResourceLink name="users" 
                global="UserDatabase"
                type="org.apache.catalina.UserDatabase"/>
</Context>

Description des attributs de la balise <Context> :

• docBase : répertoire de travail du projet ('context root') ;
• privileged : autorise l'utilisation de container servlets ;
• antiResourceLocking : gestion des blocages de ressource ;
• antiJARLocking : idem, mais pour les fichier jar.

Description des attributs de la balise <ResourceLink> :

• name : le nom de la ressource ;
• global : le nom de la ressource dans le contexte JNDI . (pour JNDI, cf. http://127.0.0.1:8080/tomcat-docs/jndi-resources-howto.html) ;
• type : la classe utilisée par l'application Web pour interroger cette ressource.

Dans cet exemple, l'unique ressource correspond à la base de données interne des utilisateurs définis dans Tomcat.

TOMCAT WEB SERVER ADMINISTRATION TOOL

Outil d'administration du serveur d'application Tomcat.

Si cette application n'est pas disponible, c'est qu'elle n'est pas lancée. Il faut utiliser le Manager et lancer l'application dont le contexte est /admin. Si l'application n'est pas présente dans la liste du Manager, c'est qu'il est nécessaire de la déployer. L'application doit se trouver dans le répertoire $CATALINA_HOME\server\webapps\admin d'Apache-Tomcat. Elle possède un fichier de contexte admin.xml.

L'application est accessible à l'adresse http://127.0.0.1:8080/admin

Cet outil liste les différents services accessibles et permet de gérer les ressources, les sources de données, les utilisateurs et leur rôle.

ANT est un outil JAVA qui permet entre autres de gérer la compilation et le déploiement d'une application Java Web. Il utilise un fichier build.xml au standard XML à l'image de l'outil make et son fichier Makefile. Il est préférable de commencer par cet outil avant d'utiliser un environnement de développement complet, car il permet d'appréhender plus précisément la structure d'une telle application.

ANT ne nécessite donc que l'installation d'un runtime Java au préalable. Il suffit de décompresser l'archive apache-ant-1.6.5-bin.zip dans un répertoire quelconque.

Aucune configuration particulière n'est nécessaire. La variable d'environnement JAVA_HOME doit être configurée.

La plupart des commentaires et des exemples ont été récupérés dans la documentation d'Apache-Tomcat (http://127.0.0.1:8080/tomcat-docs/appdev/source.html). ANT possède également un manuel très complet.

À l'image de ce que fait un fichier Makefile, le fichier build.xml fournit différentes cibles qui permettent de compiler un projet, de le préparer, de le déployer et de créer un paquetage. Ces cibles sont définies par le programmeur.

Il existe un fichier build.xml.txt de référence dans la documentation d'ANT et dans la documentation de Tomcat (http://127.0.0.1:8080/tomcat-docs/appdev/build.xml.txt). Il est découpé de la manière suivante :

• une racine XML qui indique le nom du projet, la cible par défaut, et le répertoire du projet :

<project name="My Project" default="compile" basedir=".">
[...]
</project>

• les définitions des propriétés (Property Definitions,File and Directory Names, et Compilation Control Options) qui définissent des répertoires, des paramètres de compilation, des liens vers des fichiers de définitions externes, etc. Pour définir une propriété, on écrit la balise suivante :

<property name="app.name" value="myapp"/>
<property name="app.path" value="/${app.name}"/>

Pour récupérer la valeur d'app.name dans un attribut d'une balise XML de ce fichier, il suffit d'écrire ${app.name}.

Pour inclure un fichier de propriétés externe, il est possible d'utiliser le tag <property> avec l'attribut file. L'intérêt d'un tel fichier est de pouvoir définir des propriétés communes à toutes les applications.

<property file="build.properties"/>

Par contre, ce fichier ne respecte pas la syntaxe XML :

# Context path to install this application on
app.path=/chemin_vers_mon_appli

# Manager webapp username and password
manager.username=mon_user
manager.password=mon_mot_de_passe

• Les interactions avec Tomcat (Custom Ant Task Definitions) définissent le lien entre les cibles de compilation et les classes Java de Tomcat. Par exemple la classe du serveur Tomcat utilisée pour déployer un projet est org.apache.catalina.ant.DeployTask. Ces interactions seront reprises dans la définition des cibles.

<taskdef name="deploy"   classname="org.apache.catalina.ant.DeployTask"/>
<taskdef name="list"     classname="org.apache.catalina.ant.ListTask"/>
<taskdef name="reload"   classname="org.apache.catalina.ant.ReloadTask"/>
<taskdef name="undeploy" classname="org.apache.catalina.ant.UndeployTask"/>

• Le CLASSPATH (Compilation Classpath) correspond aux répertoires qui contiennent les bibliothèques Java que l'on doit inclure dans les programmes. Il est possible de construire le classpath de Tomcat dynamiquement en ajoutant ces lignes :

<path id="compile.classpath">
   
    <pathelement location="${catalina.home}/common/classes"/>
    <fileset dir="${catalina.home}/common/endorsed">
      <include name="*.jar"/>
    </fileset>
    <fileset dir="${catalina.home}/common/lib">
      <include name="*.jar"/>
    </fileset>
    
    <pathelement location="${catalina.home}/shared/classes"/>
    <fileset dir="${catalina.home}/shared/lib">
      <include name="*.jar"/>
    </fileset>

</path>

• Les cibles (=targets)
•   all : nettoie le répertoire de compilation et lance la compilation.
•   clean : efface le répertoire de compilation.
•   compile : compilation du projet.
•   dist : création d'un fichier pour distribuer l'application.
•   install : déploiement de l'application sur le serveur Tomcat.
•   javadoc : création de la documentation du projet (Javadoc API documentation).
•   list : liste les applications qui sont démarrées dans Tomcat.
•   prepare : prépare les répertoires nécessaires à la construction du projet.
•   reload : recharge l'application dans Tomcat.
•   remove : supprime l'application de Tomcat (mais ne supprime bien évidemment pas le répertoire de projet).

On peut remarquer dans la cible d'installation qu'une balise <deploy> est utilisée. Cette balise reprend le nom de la tâche personnalisée <taskdef> pour l'interaction d'Ant avec Tomcat :

<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>

<target name="install" depends="compile"
description="Install application to servlet container">

<deploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"
localWar="file://${build.home}"/>

</target>

Pour exécuter cette cible, il suffit d'invoquer la commande suivante en se plaçant dans le même répertoire que celui du fichier build.xml :

C:\Ant compile

Tous ces paramétrages sont définis par défaut, il faudra les configurer en fonction de ses propres exigences.

L'application test1 va permettre d'afficher un tag Hello World ! dans une page jsp. Elle contient :

• un fichier web.xml qui décrit le comportement de l'application au serveur d'application ;
• une bibliothèque de tags taglib.tld ;
• un tag HelloWorld.java qui affiche Hello World ! ;
• une page d'accueil index.jsp.

Pour utiliser l'outil Ant, il faut organiser les répertoires de la manière suivante :

Répertoires créés automatiquement par Ant :

build : répertoire contenant l'application avant déploiement ;

dist : répertoire qui contient le paquetage de l'application.

Répertoires à créer manuellement :

docs : contient les documents pour l'API Java Documentation

=> se répertoire reste vide pour test1 ;

src : contient le fichier HelloWorld.java qui doit être compilé ;

web : contient la page index.jsp ;

web\WEB-INF : contient le fichier web.xml et taglib.tld ;

web\WEB-INF\lib : ne contient rien, car il n'y a pas de bibliothèque java à ajouter au projet.

Le fichier web.xml décrit la version de servlets utilisée, le nom et la description de l'application, ainsi que le chemin vers la bibliothèque de tags pour permettre au serveur d'application d'y accéder.

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

     <description>Application Test1</description>
    <display-name>Test1</display-name>
    <taglib>
        <taglib-uri>/taglib</taglib-uri>
        <taglib-location>/WEB-INF/taglib.tld</taglib-location>
    </taglib>
</web-app>

Le fichier de bibliothèque taglib.tld est le suivant (l'en-tête suit la version de spécifications des servlets, il faut l'adapter suivant sa version) :

<?xml version="1.0" encoding="ISO-8859-1" ?>
<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
    version="2.0">
    
    <description>TagLib de Test1</description>
     <tlib-version>1.0</tlib-version>
    <short-name>taglib</short-name>
    <tag>
        <description>Affichage d'Hello World !</description>
        <name>helloworld</name>
        <tag-class>test1.HelloWorld</tag-class>
        <body-content>empty</body-content>
    </tag>
</taglib>

La balise <short_name> décrit le nom court qui identifie la bibliothèque. Il sera utilisé en tant que préfixe de balise XML pour appeler le tag helloword. La balise <tag> décrit l'accès au tag HelloWorld.java. Le <body-content> indique si cette balise contient du texte, dans ce cas précis il n'en est pas question puisque sa valeur est empty.

On indiquera donc <taglib:helloworld/> pour appeler le tag dans la page jsp.

Il faut noter que la classe possède un préfixe test1 dans la balise <tag-class>, il s'agit du package.

Le tag HelloWorld.java effectue un simple affichage :

package test1;

import java.io.Writer;
import java.io.IOException;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;

public class HelloWorld extends TagSupport
{
    public int doStartTag() throws JspException
    {
        try {
            pageContext.getOut().println("Hello World !");                    
        } catch (IOException e) {
            throw new JspException("I/O Error", e);
        }    
        return SKIP_BODY;
    }
}

La méthode doStartTag est appelée lors de l'appel au tag par la page jsp. Cette méthode renvoie SKIP_BODY pour indiquer que le tag ne contient pas de corps.

La page index.jsp contient du code HTML et un tag. La première ligne déclare la bibliothèque de tags utilisée.

<%@ taglib uri="/taglib" prefix="taglib" %>
<html>
  <head>
    <title>Test1 pour l'affichage d'un tag</title>
  </head>
  <body>
    <h1>Test1 pour l'affichage d'un tag</h1>
    <hr>
    <p>Ce tag affiche "Hello, World!", il ne contient pas de body.</p>
    <br>
    <b><u>Result:</u></b>
      <taglib:helloworld />
  </body>
</html>

Il faut au préalable vérifier que le serveur Tomcat est lancé. Avant de compiler le projet, on se place dans le répertoire de développement de l'application.

Le fichier build.xml utilisé est celui qui est fourni par Tomcat. Il est placé directement dans le répertoire de travail test1. Il y a quelques adaptations à faire pour définir le nom du projet et le nom de l'application.

<project name="Test1" default="compile" basedir=".">
[...]
<property name="app.name" value="test1"/>

Ce fichier fait également référence à un fichier build.properties que l'on définit de la manière suivante :

# Context path to install this application on
app.path=/test1

# Tomcat 5 installation directory
catalina.home=C:/Program Files/Apache Software Foundation/Tomcat 5.5

# Manager webapp username and password
manager.username=mon_user
manager.password=mon_mot_de_passe

Pour compiler le projet, on tape la commande suivante :

C:\PROGRA~1\APACHE~1\TOMCAT~1.5\server\webapps\test1>ant compile
Buildfile: build.xml

prepare:

compile:
    [javac] Compiling 1 source file to C:\PROGRA~1\APACHE~1\TOMCAT~1.5\server\webapps\test1\build\WEB-INF\classes

BUILD SUCCESSFUL
Total time: 10 seconds

À ce stade, Ant a créé un nouveau répertoire build qui contient la version définitive de l'application Web test1 avec les différents fichiers source Java désormais compilés.

C'est le contenu du répertoire build qui va être déployé sur le serveur pour rendre disponible l'application.

C:\PROGRA~1\APACHE~1\TOMCAT~1.5\server\webapps\test1>ant install
Buildfile: build.xml

prepare:

compile:
    [javac] Compiling 1 source file to C:\PROGRA~1\APACHE~1\TOMCAT~1.5\server\webapps\test1\build\WEB-INF\classes

install:
   [deploy] OK - Application déployée pour le chemin de contexte /test1

BUILD SUCCESSFUL
Total time: 10 seconds

Voilà le résultat obtenu en affichant la page http://127.0.0.1:8080/test1/

Eclipse est un environnement de développement écrit en Java. Il fait partie des IDE de références, et possède de nombreux avantages à l'image des plugins de développement. On peut trouver des plugins pour le Javascript, le C/C++, le Java et bien d'autres choses encore.

Le WTP (Web Tools Package) contient tout le nécessaire pour la création d'applications Web selon l'architecture J2EE.

Ce package contient Eclipse dans son intégralité. De la même manière qu'une application Java, il suffit de décompresser l'archive wtp-all-in-one-sdk-R-1.5.0-200606281455-win32.zip dans un répertoire quelconque. La commande eclipse.exe permet de lancer Eclipse.

Voici les étapes à suivre pour installer un environnement de travail J2EE sur Eclipse.

Lorsque Eclipse est lancé, on a la possibilité de créer un Server (menu File/New/Other ) :

L'étape suivante demande de sélectionner le type de serveur :

Après avoir validé ce choix, on retrouve le serveur dans l'explorateur de projets (menu Window/Show View/Project Explorer) et dans l'explorateur de serveurs (menu Window/Show View/Servers ).

La configuration du serveur est contenue dans le projet correspondant, pour un premier serveur créé, il s'appelle Tomcat v5.5 Server @ localhost-config. On y trouve les fichiers de configuration principaux de Tomcat : web.xml, server.xml et tomcat-users.xml.

L'explorateur de serveurs permet de l'administrer, de le configurer, de la lancer ou de l'arrêter. Un menu contextuel s'affiche lorsque l'on clique droit sur la ligne suivante :

Pour configurer le serveur, il faut double-cliquer sur cette ligne, une nouvelle fenêtre doit apparaître. On y trouve entre autres les ports d'écoute des connecteurs.

Il est également possible de dissocier les modules d'un projet Java Web d'Eclipse et les applications installées sur le serveur Tomcat. L'option Run modules directly from the workspace permet de choisir entre :

• lancer ces applications à part, les fichiers de configuration de Tomcat ne sont alors pas modifiés, mais les applications déployées sur le serveur ne sont pas accessibles. Cette option est choisie par défaut ;
• lancer les projets Eclipse au niveau des webapps de Tomcat.

Le serveur Tomcat doit ensuite être démarré. On peut vérifier dans l'explorateur de serveurs :

Remarque : à la création du répertoire du projet, Eclipse met une majuscule en début de nom. Cela a une incidence lorsqu'on lance l'application directement à partir du répertoire de travail :

• si l'option Run modules directly from the workspace est choisie et que le répertoire s'appelle Test2, il faut utiliser l'adresse http://127.0.0.1:8080/Test2 pour y accéder, même si le nom de déploiement de l'application est test2 sans majuscule. En fait, dans cette situation, il n'y a pas de déploiement, on utilise le nom physique du répertoire du projet ;
• si l'option Run modules directly from the workspace n'est pas sélectionné, un déploiement est effectué sur les webapps de Tomcat, on utilisera donc le lien suivant pour accéder à l'application : http://127.0.0.1:8080/test2.

Pour créer un nouveau projet Web dans Eclipse, il faut sélectionner le menu File/New/Other puis choisir une application Web dynamique dans le répertoire Web.

Renseigner ensuite le nom du projet en gardant les paramètres par défaut. Grâce à l'assistant de création, il est possible de changer la racine de déploiement, le répertoire des pages Web et le chemin source Java.

À l'image de ce qui a été fait dans l'exemple test1, les paramètres suivants ont été choisis :

Dans l'explorateur de projet, on trouve cette arborescence :

• Deployment descriptor : décrit le contenu du fichier web.xml.
• src : sources JAVA.

Après compilation, elles sont placées dans le répertoire build\classes, les sous-répertoires correspondent ensuite aux packages. Ex. : pour un package org.apache, on aura un répertoire org, et un sous-répertoire apache.

• build : contient le projet prêt à être déployé.
• build\classes : classes des sources compilées.
• web : contient le contenu statique, les fichiers html, etc.
• web\META-INF : on y place généralement un fichier de contexte spécifique à l'application Web, mais ce n'est pas obligatoire.
• web\WEB-INF : contient la description et la configuration de l'application. On y retrouve le fichier web.xml.
• web\WEB-INF\lib : bibliothèques Java (jar) communes à toute l'application.

Un fichier index.jsp assez simple est ajouté au projet, il faut le placer dans le sous-répertoire web ou WebContents le répertoire par défaut proposé par Eclipse n'a pas été modifié. Pour ajouter un tel fichier, il faut faire un clic droit sur le répertoire web dans l'explorateur et choisir l'option New\JSP.

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Insert title here</title>
</head>
<body><% pageContext.getOut().println("Hello World 2!"); %></body>
</html>

Dans le menu Window\WebBrowser, on indique quel navigateur Web utiliser. Dans l'exemple, c'est le navigateur interne Internal Web Browser qui est choisi.

En faisant un clic droit sur le répertoire du projet Test2, on peut accéder au menu Run As\Run On Server. Par cette action, la page index.jsp est affichée.