J'ai repris l'exemple d'un bouquin sur J2EE. Je le posterai si vous le voulez. Il s'agit d'une JSP qui utilise une classe (de mémoire un JavaBean) pour la partie métier.
 
Voilà ce que j'ai fait :
j'ai créé un répertoire "tests" sous "webapps". Dans "tests" j'ai créé un répertoire "WEB-INF" dans lequel j'ai créé un répertoire "classes", lequel contient la classe appelé par la JSP. La JSP se trouve dans "tests".
 

 
1. Je suis bien embêté avec le fichier web.xml, que je ne sais pas écrire.
 
2. La doc de Tomcat (4.1.24) parle du chapitre 13 de l'API Servlets. Ce chapitre peut parait-il m'aider dans la rédaction du descripteur de déploiement. Mais je ne l'ai pas trouvé.
 
3. Naturellement ça ne marche pas : erreur 500, la JSP ne peut être compilée car elle ne trouve pas la maclasse.class.

Bon, ça marche. Maintenant j'avoue que je ne saisis bien pourquoi, mais voici :
 
J'ai placé maclasse dans un package monpackage. J'ai reproduit cela dans l'arborescence exposée dans mon post ci-dessus.
 
J'ai modifié les références à maclasse en monpackage.maclasse dans majsp.
 
Je ne comprends pas bien s'il s'agit là d'une limitation, et pourquoi dans ce cas, elle existe...

l'utilisation de classes non-packagée a toujours un peu posé problème à tomcat ... demande à dark !
je crois que pour l'utiliser il aurait fallu mettre une close import de la classe dans la JSP  
genre <%@page import="tonBean%">
 
sinon, pour le web.xml, récupère le lien vers la DTD qu'il y a dans les fichiers web.xml et télécharge le fichier DTD : il est très documenté.
 
faux edit : http://java.sun.com/dtd/web-app_2_3.dtd

En l'occurence j'avais tenté l'import, mais je me récupérais une erreur : '.' attendu, c-a-d le caractère de séparation packages-classes.

Tomcat ne peut pas utiliser un bean qui ne fait partie d'aucun package, c'est aussi simple que ça.
Pour le web.xml, google devrait te donner pas mal d'exemples. Tu peux aussi te baser sur le fichier qui vient avec les exemples de Tomcat.

Que dois-je déduire du fait que mon app marche sans aucun web.xml ?

Que si tu as une copine tu ferais bien de la surveiller

Bordel !

Bon, j'ai en gros la même question mais avec une servlet :
 
Je viens de repomper une servlet dont la méthode doGet() sert à imprimer "Coucou" sur la page. ça compile...
 
J'ai placé HelloWorld.class et HelloWorld.java dans WEB-INF/classes, j'ai écrit un web.xml, que j'ai placé dans WEB-INF :
 

 
J'essaie d'accéder à la page par ; http://localhost:8080/tests/hello-world
 
résultat : 404.

J'ajoute que j'ai lu à propos d'invoker, mais je n'ai pas très bien saisi ce dont il s'agit.

sûr ??? je trouve ca bizare ... je veux dire, même si c'est aps propre, c'est correct au niveau Java ...

ha bon ... merci de l'info !

Si tu regardes dans le rep conf de tomcat, tu vas trouver un fichier web.xml. C'est le fichier par défaut de tomcat : les fichiers web.xml de chaque web-app "héritent" de ce fichier. Donc si tu n'en mets pas dans ta web-app, il se sert uniquement de celui par défaut.
 
Dedans, tu trouveras nottament la servlet chargée de gérer les JSP et une autre chargée de retourner les fichiers statiques (fonction de serveur web classique)
 
 
edit : Bordail ! anti-flood !    
 
 

c'est pas terrible de mettre les .java dans la web-app ... c'est pas leur place. Vaut mieux mettre uniquement les .class
 
Et puis, tu devrais vraiment mettre tes classes dans des packages ...
 

 
D'après ce que je comprend, ta web-app est mappé sur le nom "tests" (tu as créé un répertoire tests dans le rep web-apps de tomcat).
 
Si c'est bien ca, l'erreur est à l'endroit que j'ai mit en gras : Tout ce qu'il y a à l'intérieur d'une web-app est relatif à la web-app => tu ne dois pas mettre le rep "tests" dans l'url-pattern : uniquement "/hello-world"
 
Comme ca, si tu changes le mapping de ta web-app (configurable dans le fichier %tomcat_home%/conf/server.xml avec une balise Context), tu n'as pas à modifier le fichier web.xml de ta web-app. C'est un des principes des web-app : elles doivent être complétement indépendantes => pas de références à l'extérieur de la web-app (ici, "tests" est une référence externe)

Bien vu, l'erreur était là. Je relis ce que tu as écrit, histoire de bien comprendre.
 
Pour l'histoire des packages et des .java : j'essaie de comprendre comment ça marche, alors je fais simpliste et sans précautions.
 
Edit : je pense avoir compris. Effectivement j'écrivais en me focalisant sur l'arborescence propre de tomcat : je contruisais l'url à partir du répertoire webapps.

ouais, je me doute bien, mais vu que tomcat aime pas trop quand y a pas de package, tu risques de tomber dans des erreurs bizarres ...

  Clairement. Au moins j'aurai vu des mes yeux les bugs en question.
 
Prochaine étape : faire communiquer plusieurs servlets et JSPs...
 
D'ailleurs, y a t'il des ressources que tu me recommandes chaudement ?

 
si je me souviens, ce doc est assez bien fait : http://www.javaworld.com/javaworld [...] spmvc.html

 

 
cherytree je suis extrêmement déçu  

Moi aussi : tu ne sais pas orthographier correctement mon pseudo .

merde j'avais mis deux R puis j'en ai enlevé un suite à la remarque dans blabla@prog
 
bon ct le contraire je sors

J'ai une question d'ordre "best practice" : dans une appli web classique à base de servlets, de JSPs et de formulaires HTML, comment les pages sont elles organisées ?
 
Les servlets sont dans des packages, dans WEB-INF/classes : OK
Les JSPs et le HTML sont dans le répertoire de la webapp, ou dans des sous répertoires de celui-ci sauf WEB-INF : OK
 
Maintenant, comment lier les pages entre elles : que mettre en href, pour rester aussi indépendant que possible du web container utilisé ?
 
La norme est-elle univoque à ce sujet ?

je me souviens pas avoir lu de règle la dessus ...
 
Logiquement, c'est aux servlets de prendre les requêtes, récupérer les données de la requête ou de la session dont elle a besoin, de faire les traitement métier et de passer les données à un JSP pour faire l'affichage. C'est le shéma MVC classic.
 
moi ce que je fais pour les liens c'est que je fais systématiquement pointer mes liens (formulaire ou les liens a) vers une page html. Si je veux faire un traitement (genre gestion de formulaire ou récupération de donnéeq en base), je mappe (servlet-mapping) une servlet sur la page html en question et elle fera le traitement et délégera l'affichage à une jsp. Si c'est juste de l'affichage dynamique (à partir de données en session, par ex.), je mappe une JSP sur la page html (tu peux déclarer une JSP comme tu le fais avec une servlet et donc lui associer un servlet-mapping).
Si c'est une page statque, bha ca charge la page html du même nom ...
 
en plus, faire comme ca permet de "cacher" l'implémentation sous jacente : pour l'utilisateur, toutes les pages sont des pages html ... (Pour délirer un coup j'avais mappé mes servlet sur des extensions en .php  )
 
C'est un peu chiant à l'utilisation : faut systématiquement déclarer toutes tes JSP qui sont accédées directement ... mais bon, je trouve que c'est pas une mauvaise habitude.

Dis-moi si quelques choses te chagrinent dans ce que j'ai écrit :
 

 
form.html envoie le contenu d'un textfield par GET à l'url /tests/TotoServlet.
 
Le mapping :

 
Moi ce qui me chagrine c'est la référence au répertoire "tests" dans form.html. Tu as un workaround pour ça ?

ben écrit ton lien en relatif : <form action="TotoServlet">
si ton lien commence par un "/", il est en absolu (par rapport à la racine du site).
 
Si tu veux vraiment mettre un lien en absolu, tu peux le construite en te servant de getContextPath() :
 
<form action="<%= request.getContextPath() %>/TotoServlet">

Puissant ! Bon, ben je crois que j'ai fait le tour des questions que je me posais. Je vais pouvoir me faire plaisir maintenant !

si tu as un peu de temps, jette un oeil (sploutch) sur la JSTL : http://www.javaworld.com/javaworld [...] -jstl.html
 
c'est sympa, et ce sera intégré en natif dans les JSP 2.0 => tu appends pas ca pour rien ...

Un nouveau monde apparaît devant moi ! Tant que je te tiens : tu as des informations sur JavaServer Faces ?

ouep, j'en ai eu à Javaone ...
 
en gros c'est du Strust standardisé avec quelques truc en plus. C'est intéressant ... à creuser ...
 
si le sujet t'intéresse : http://servlet.java.sun.com/javaon [...] s/2301.pdf
 
(tu auras besoin de t'enregistrer. c'est gratuit)

 
Le SQL Tag library, une vraie incitation à la débauche...  

c'est sûr ...
y a tout un tas de tags, qui ne sont pas à utiliser dans de vrais gros projets, je pense ...
 
mais pour faire un truc rapide, y a pas mieux !  

 
Ben, là je m'interresse au tags pour l'internationnalisation (utilisation des ResourcesBundle, Local, Encoding, formatage de messages, date, ...). ça m'a l'air pas mal.
Mais, sachant que je préconise Tomcat 4.0 pour ma web-app (donc pas de JSTL incluses), si je l'utilise, je vais devoir livrer le package de JSTL avec ma web-app. C'est assez lourd comme truc, non ?

bha ca fait quelques jars en plus a mettre dans le WEB-INF/lib, ouais ...

 
 
Un dernier truc (après j'arrête de squatter ce topic, promis !:D) :
Pour utiliser des tags en JSP, il faut toujours déclarer un truc de ce gene dans le web.xml :

 
 
Cette Url elle correspond à quoi ? Mon moteur de servlets vas qd même pas chercher des infos sur le site de sun !??

nan, l'url est réutilisée comme "identifiant" lorsque tu déclares la taglib dans la jsp :  

 
Ha, d'accord. J'avais pensé à ça, mais ça me parait vraiment "bizarre" comme identifiant une url...  

ca assure l'unicité puisque le nom de domaine est privé ...

 
Pas con. Donc me voila rassuré. J'vais surement utiliser ce tag pour l'internationnalisation de mes JSP, ça m'a l'air bien.

Question : dans le modèle 2 JSP, une servlet récupère les requêtes et forward vers la bonne JSP.
 
D'après ce que j'ai compris du forward, du point de vue du client, c'est transparent : la barre d'adresse ne change pas.
 
Que se passe t'il lorsqu'on cherche à inclure un objet (une image par exemple) dans le JSP. Le livre que je lis (Core Servlets and JSP - Marty Hall) préconise de ne mettre que des adresses absolues. Cependant, il me semble que cette approche rend la webapp dépendante du web container utilisé.
 
Qu'en pensez-vous et comment faites-vous vous-mêmes ?

 
Tu peut récupérer le contexte de ton application par