Debugging JSP : C'est fastidieux?!

**Goupo** · 18/11/2009, 16h52

Salut à tous,

A la lecture du, très fameux, site de jmdoudoux et plus précisément du point 54.1.2. Les JSP et les technologies concurrentes, je vois :

Envoyé par jmdoudoux

JSP : principaux inconvénients : Débogage assez fastidieux

Je n'ai aucune expérience avec les JSP, je suis justement à l'étude pour élire la techno du projet qui s'annonce.

La question : C'est vrai?
Si oui, en quoi les JSP sont "assez fastidieuses" à debuguer?
Si non, est-ce que c'est le site de jmdoudoux qui commence à vieillir?

Merci.

**guigui5931** · 18/11/2009, 19h18

Le problème est si tu utilise un debbuger (par exemple celui d'Eclipse).
Dans le cas d'un clase simple tu peux mettre un point d'arrêt sur une ligne de ton code. Tu vois alors à quel moment tu passe sur ta ligne, tu peux "suivre" le déroulement de ton code, interroger des variable pour avoir leur valeur à un moment donné.
Une JSP n'est elle pas exécutée directement, elle est transformé en une servlet qui est elle la classe JAVA qui sera exécutée. D'une c'est compliqué d'avoir accès à ce code pour y mettre des points d'arrêts, et même quand on y arrive ce n'est pas le code comme on l'a écris directement.

Voila ce que je comprend par sa phrase.

**Goupo** · 19/11/2009, 09h37

Merci pour ta réponse.

**link256** · 19/11/2009, 09h54

Et la plupart du temps la servlet.java générée à partir de la jsp est supprimée après compilation il ne reste que le servlet.class

Et si une erreur est généré la console affiche ligne 450 de la servlet mais il n'y a aucune correspondance avec la ligne de la jsp.

Celon les serveurs d'applications il est possible de conserver le servlet.java pour le local ou la recette mais déconseillé pour la production.

Pour websphère il faut rajouter le fichier ibm-web-ext.xmi dans le WEB-INF

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?>
<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" xmi:id="WebAppExtension_1164726065140" reloadInterval="3" reloadingEnabled="true" additionalClassPath="" fileServingEnabled="true" directoryBrowsingEnabled="false" serveServletsByClassnameEnabled="true">
  <webApp href="WEB-INF/web.xml#WebApp_ID"/>
  <jspAttributes xmi:id="JSPAttribute_1" name="keepgenerated" value="true"/>
</webappext:WebAppExtension>

Ce qui explique les propos de difficulté de debug et qu'il est fortement conseiller de ne faire que de la présentation / affichage de données dans les jsp et non du traitement connexion base de données ect ...

**Goupo** · 19/11/2009, 16h05

Tu me mets le doute sur le fonctionnement des Jsp.

J'écris du code de ce genre, dans un fichier .jsp :

<%-- Ceci est un commentaire JSP --%>
<%@page contentType="text/html"%>
<%@page errorPage="erreur.jsp"%>
<%-- Importation d'un paquetage (package) --%>
<%@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>

Ce code est interpété en servlet, c'est un fichier .java, c'est une classe qui est une servlet :

import javax.servlet.* ;
import java.io.* ;

public class HelloServlet extends GenericServlet
{
public void service (ServletRequest request, ServletResponse response)
{
try
{
PrintWriter out = response.getWriter() ;
out.println ("<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\">") ;
out.println ("<title>Bonjour le monde !</title>") ;
out.println ("<p>Hello world!</p>") ;
}
catch (IOException e)
{
e.printStackTrace() ;
}
}
}

Puis compilé en fichier .class (le .java est supprimé).

Quand un utilisateur demande une page, le serveur exécute les fichiers .class qu'il faut, cela produit un code HTML qui est envoyé au client (qui n'a pas besoin de JVM).

On est d'accord ou j'ai dit n'importe quoi?

**link256** · 19/11/2009, 16h13

Oui on est d'accord

la servlet ou jsp tu peux utiliser l'un ou l'autre même si la jsp est compilé en servlet par la suite.

Le serveur renverra ce que tu décides de renvoyé une page html en l'occurence, cela pourrait être un fichier à enregistrer dans tous les cas c'est le serveur qui gère.

Le seul conseil que je te donnerais vis à vis des JSP c'est de respecter un développement MVC qui plus que fait ses preuves.
L'avantage c'est que la JSP ne représente que la vue et que si tu as une erreur pour le debug c'est d'autant plus simple à gerer et rapide que de devoir debug du code dans un jsp.

**Jidefix** · 23/11/2009, 15h55

Bonjour,
je me pointe juste pour dire qu'avec Tomcat/Eclipse il n'y a pas de soucis, il suffit de faire un refresh sur le dossier pour que le .java rentre dans le projet (et qu'on puisse donc debugguer la jsp, on peut même rajouter des breakpoints)

Je voudrai également préciser qu'une bonne jsp ne contient couasiment pas de traitement java, et en particulier pas de traitement non spécifique à l'affichage.
Donc pas d'algorithme compliqué, pas de boucles à n'en plus finir.
Ca signifie que les erreurs java doivent rester très faciles à pointer du doigt!

**link256** · 23/11/2009, 20h31

C'est ce que je disais un peu plus haut dans la conversation.
Mais qui hélas est loin d'être appliqué ^^

Quand on voit le nombre de personne qui se connecte à une base de données, exécute des requêtes suivis de traitement pour enfin afficher des données

Debugging JSP : C'est fastidieux?!

Servlets/JSP Java

Vue hybride

Discussions similaires

Partager

Partager