Documentation du plugin Tomcat pour Eclipse
Pré-requis |
|||||||||||||||||||||
)
à une perspective (Java, déboguage ou autre),
pour démarrer Tomcat.
,
la console affiche :
| <!-- The mapping for the invoker servlet --> | ||
| A supprimer | <!-- | |
| <servlet-mapping> | ||
| <servlet-name>invoker</servlet-name> | ||
| <url-pattern>/servlet/*</url-pattern> | ||
| </servlet-mapping> | ||
| A supprimer | --> | |
De façon générale, le développeur préférera créer son propre fichier web.xml, notamment pour définir ses propres alias de servlets.
- Le débogage de servlet se fait simplement comme pour toute classe Java : il suffit de mettre un point d'arrêt dans l'éditeur
- Le plugin ne permet pas de mettre un point d'arrêt directement dans le code de la JSP, par contre il est possible de mettre un point d'arrêt dans le servlet généré.
- Après avoir invoqué la JSP, sélectionner le répertoire 'work' et faire un 'Régénérer' dans le menu contextuel.
- La classe du servlet généré par Tomcat pour chaque
JSP sera affichée dans Eclipse, il est possible d'y mettre des points
d'arrêt :
- NB 1 : Problème connu avec Tomcat 4 et les JSP placées
dans des sous-répertoires :
Les servlets générés par Tomcat 4 ne sont pas compilable directement par Eclipse. Le problème vient du fait que Tomcat 4 déclare tous les servlets générés dans le package suivant 'org.apache.jsp', or les fichiers créés ne sont pas placés dans un répertoire respectant cette définition de package. Nous proposons une solution sous forme d'un patch Tomcat. Télécharger le patch correspondant à votre version de Tomcat à partir de la page du plugin : http://www.sysdeo.com/eclipse/tomcatPluginFR.html#tcp
(Il est nécessaire de relancer Tomcat après l'installation de ce patch) - NB 2 : par défaut Tomcat ne compile pas les servlets générés
avec les informations de debug suffisantes, de ce fait plusieurs fonctionnalités
ne sont pas disponibles dans le débogueur (par exemple les variables
locales n'apparaissent pas). La correction de ce problème est simple
: il faut préciser à Tomcat que la compilation doit se faire
en intégrant les informations de débug. Pour cela il faut modifier
le fichier conf/web.xml de Tomcat (ou le fichier web.xml de votre projet).
La modification se fait sur la déclaration du compilateur de JSP en
y ajoutant le paramètre classdebuginfo :
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>classdebuginfo</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Paramétrages avancés
La fenêtre de préférence Tomcat->Paramétrages de la JVM permet de modifier indirectement la ligne de commande utilisée pour lancer Tomcat. Le plugin se charge de produire cette ligne de commande notamment en construisant le classpath nécessaire. Dans cette fenêtre de préférence il est possible :
- de spécifier la JVM à utiliser (1) : si une valeur est indiquée dans ce champs, le JRE par défaut ne sera plus utilisé.
- d'ajouter des paramètres à la ligne de commande (2) : les chaînes de caractères de cette liste seront ajoutées sans transformation à la ligne de commande.
- d'ajouter des librairies au classpath (3) : ces librairies sont ajoutées en début de classpath donc avant les librairie Tomcat. Il possible de les ordonnancer.
- de forcer le bootclasspath (4) : si cette liste est renseignée elle remplace le bootclasspath par défaut c'est pourquoi il est nécessaire qu'elle contienne au moins rt.jar.
NB : dans la fenêtre de préférence pincipale du plugin Tomcat il est possible d'indiquer que le démarrage de Tomcat ne doit pas se faire en mode débug.
Les projets Tomcat ont des paramètres spécifiques qui peuvent
pour certains être renseignés lors de la création du projet
(dans la deuxième page de l'assistant)
Ces paramètres ainsi que plusieurs autres sont accessibles à tout moment en ouvrant la fenêtre de propriété du projet.
1- La case à cocher 'Est un projet Tomcat' permet de transformer un
projet Java en projet Tomcat et vice-versa.
2- Le nom du contexte conditionne l'url à utiliser pour accéder
au servlet et JSP du projet. La case à cocher associée permet
d'autoriser le plugin à modifier le fichier de configuration de Tomcat
(server.xml) en y ajoutant le contexte spécifié. Il est conseillé
d'autoriser cette modification car le contexte sera déclaré et
paramétré automatiquement.
3- Sélectionner un emplacement et un nom de fichier WAR dans lequel sera
exporté le contenu du projet lors de l'utilisation de l'option d'export
(liste des actions sur un projet, cf ci-dessous).
4- Ce champs permet d'indiquer que le projet n'est pas directement une application
web (structure WAR) mais qu'un de ces répertoires contient une application
web, le contexte sera défini dans le fichier server.xml en pointant vers
ce sous-répertoire.
Les projets Tomcat ont une entrée supplémentaire dans leur menu contextuel :
1- Le contenu du projet est exporté vers le fichier WAR indiqué
dans les préférences.
2- Supprime le contexte de server.xml si la mise à jour du fichier server.xml
est autorisé.
3- Met à jour le contexte dans server.xml si la mise à jour du
fichier server.xml est autorisé.
4- Lors de la création du projet Tomcat deux librairies contenues dans
le répertoire Tomcat sont déclarées dans le chemin de compilation
du projet, cette option de menu permet de les redéclarer (ceci peut être
intéressant en cas de changement de version de Tomcat, en effet les développeurs
de Tomcat ont la facheuses habitudes de déplacer les librairies d'une
version à l'autre, avant d'utiliser cette option il est conseillé
de supprimer les anciennes librairies du chemin de compilation du projet).
4 - Problématique des classloaders
Le plugin Tomcat lance Tomcat de façon classique, le fonctionnement de base des classloaders est donc identique. Pour chaque application les classes de l'application sont chargées par un classloader spécifique.Ce classloader cherche les classes soit sous forme de fichiers .class dans l'arborescence WEB-INF/classes, soit sous forme de fichiers .jar dans le répertoire WEB-INF/lib.
Le plugin configure automatiquement le chemin de compilation des projets Tomcat pour que tous les fichiers .java du projet soient compilés dans le répertoire WEB-INF/classes. Il est naturellement fréquent que le code de ces classes fassent appel à des classes externes. Ces classes doivent être à la fois visible lors de la compilation et lors de l'exécution, pour ce faire il existe différents paramétrages :
Les classes utilisées sont dans un fichier jar :
- copier le fichier jar dans le répertoire WEB-INF/lib et ajouter ce
fichier jar au chemin de compilation du projet.
- pour des besoins plus particuliers le fichier.jar peut-être ajouté
au classpath ou au bootclasspath de Tomcat (fenêtre préférence->Tomcat->paramétrage
de le JVM). Il peut aussi être placé dans le répertoire
common/lib de Tomcat. A noter que dans tous ces cas les classes du fichier jar
ne seront pas chargées par le classloader de l'application Web ce qui
posera problème que si ces classes invoquent les classes de l'application
(par exemple en utilisant l'instruction Class.forName). Pour la compilation
le fichier jar doit être ajouté au chemin de compilation du projet.
Les classes utilisées sont sous la forme de fichiers .class :
- créer un fichier jar et suivre les instructions précédentes
;-)
- ne pas copier les classes dans le répertoire WEB-INF/classes du projet
Tomcat. Ce répertoire étant paramétré comme répertoire
de destination des classes compilées du projet, il est régulièrement
effacé par Eclipse.
Les classes utilisées sont sous la forme de fichiers .java contenu
dans un projet Eclipse de type projet Java :
Pour la compilation ajouter le projet Java au chemin de compilation du projet Tomcat.
Pour l'exécution :
- 1ère solution : cocher le projet dans la page préférence
du plugin Tomcat.
Cette solution n'est pas complètement satisfaisante car les classes de
ce projet seront ajoutées au classpath global de Tomcat, elles ne seront
donc pas chargées au même niveau de classloader que les classes
de l'application. Ce qui implique d'une part que les classes du projet Java
ne pourront pas appeler les classes de l'application (problème avec Class.forName
par exemple) et d'autre part que ces classes ne seront pas rechargées
automatiquement par Tomcat si elles sont modifiées (Tomcat est capable
de recharger automatiquement toutes les classes chargées par le classloader
de l'application).
Si le JDK 1.4 est utilisé, le problème de rechargement est partiellement
géré par Eclipse qui sera capable de demander le rechargement
des méthodes modifiées, mais tout ajout de méthode dans
une des classes du projet Java nécessitera l'arrêt et le redémarrage
de Tomcat.
- 2ème solution : utiliser une version étendue du classloader
Tomcat. Le plugin intègre un classloader capable de charger les classes
d'une application Web non seulement à partir de WEB-INF/classes et WEB-INF/lib
mais aussi à partir de tout répertoire ou fichier jar extérieur.
Ce classloader est nommé DevLoader.
Pour l'installer : dézipper le fichier DevLoader.zip dans le répertoire
<%Tomcat%>/server/classes.
Pour l'utiliser : vérifier que le projet Java est dans le chemin de compilation
du projet Tomcat :
dans la section Tomcat des propriétés du projet, activer le DevLoader
pour ce projet et sélectionner les répertoires correspondant au
projet Java:
