Bon, je vais essayer d'être clair. Voici les faits :
J'ai programmé ma servlet de façon à ce que, si un paramètre "login" est reçu lors de l'appel à ma servlet, on cré une instance "Utilisateur". Et si login n'y est pas, je fais ça:

Cette redirection n'a pas l'air de fonctionner. Il change bien de contexte (n'affiche pas ce que pourrait afficher ma servlet directement), mais au lieu de m'afficher "login.htm", il me met une page HTML vide.
Pourtant, g regardé, forward est bien censé pouvoir se faire sur une page HTML.
Une idée !?

tu peux automatiser ce genre de mécanismes dans ton web.xml, à savoir définir un contexte de ta webapp et si aucune information de login n'est associé au client, rediriger vers une ressource de ton choix.
 
Je n'ai plus le code sous la main mais ca doit se retrouver facilement ... Faut un peu utiliser les features de J2EE aussi hein

DarkLord a écrit a écrit : tu peux automatiser ce genre de mécanismes dans ton web.xml, à savoir définir un contexte de ta webapp et si aucune information de login n'est associé au client, rediriger vers une ressource de ton choix.   Je n'ai plus le code sous la main mais ca doit se retrouver facilement ... Faut un peu utiliser les features de J2EE aussi hein

 
Non, ça me parait un peu compliqué pour que ça soit gérable dans le fichier xml.
En fait, mon fonctionnement, c'est: si une instance Utilisateur n'est pas attachée à la session, et si le paramètre login n'est pas précisé, rediriger vers la page de login.
dans le fichier xml j'pense pas que ça soit possible de tester si un Utilisateur est attaché à la session !

 
bin c'est exactement ce que je suis en train de t'expliquer pourtant ...

 
ha !? ça pourrait être cool...
Et ou est ce que je peux trouver de la doc sur ce style de trucs !? je connais pas le J2EE moi !

http://java.sun.com/j2ee/tutorial/ [...] html#73861
 
et ce qui tourne autour. J'ai un exemple dans mon bouquin J2EE mais je ne l'ai pas ici. Mais bon c'est une fonctions avancées hein
 

DarkLord a écrit a écrit : http://java.sun.com/j2ee/tutorial/ [...] html#73861   et ce qui tourne autour. J'ai un exemple dans mon bouquin J2EE mais je ne l'ai pas ici. Mais bon c'est une fonctions avancées hein

 
g pas besoin de tt ça...
trop compliqué par rapport à une simple redirection... Quand j'arriverai à la faire marcher !

En fait, le problème est plus compliqué que je croyais.
Apparement, mon pb vient de la ligne en gras:

Quand encoreURL est appelé pour le 1ère fois pour un client (un navigateur ouvert), il transforme mon URI de la sorte:

(ou autre id bien sur). Mais, le fait qu'il ajoute ça, ça fait que le forward juste après ne marche pas. C'est une page HTML vierge qui s'affiche. Ensuite, si je reviens en arrière avec le même navigateur, et que je recommence la même action, encodeURL ne semble pas modifier ma String url, et le forward se fait sans pb (ma page jsp s'affiche).
Si j'enlève le encodeURL et que je fais directement le getRequestDispatcher sur ma String url, tout se passe bien. Je peux également récupérer les éléments de ma session dans la page jsp appelée par le forward que vs voyer.
Donc, 2 questions: vous avez une idée d'ou peut venir le pb !?
a quoi sert encodeURL !? (j'croyais que c'était ça qui permettait de conserver la session lors d'un forward !?)

encodeURL permet de faire du session tracking lorque les cookies ne sont pas disponibles chez le client. Sinon faire un forward sur ce genre d'url ne pose aucun problème. La seule différence est que dans un cas la JSP recoit un param appellé jsessionid et dans l'autre pas ...
 
Lorsque ce genre de comportements arrive, regarde TES LOGS !!! toute l'info utile s'y trouve

 
Donc, si je désactive mes cookies et que j'encode pas mon url, d'après toi, la sessions crée dans ma servlet ne sera plus accessible dans la page JSP que j'appelle ?
heu... dans quels LOGS !?

mais enfin d'où tu as pondu ça.
 

 
Ca veut dire que si ton client refuse les cookies, encodeURL va attacher l'id de la session à toutes les URLs que tu vas utiliser. Donc ta JSP va recevoir un argument jsessionid avec une valeur valable et donc l'objet session sera correctement initialisé et tu pourras donc l'utiliser ...
 

 
Je comprends mieux pq tu poses des questions du genre et pq tes problèmes mettent autant de temps à être résolu ...    
 
Donc tu développes au petit bohneur la chance si j'ai bien compris, sans voir où ca plante, quelle est l'éventuelle trace, etc ...  
 
Y a un répertoire logs dans tomcat avec la date du jour si c'est tomcat que tu utilises ...

 
T'as pas compris ce que j'voulais dire... c pas grave !
 

DarkLord a écrit a écrit :   Je comprends mieux pq tu poses des questions du genre et pq tes problèmes mettent autant de temps à être résolu ...       Donc tu développes au petit bohneur la chance si j'ai bien compris, sans voir où ca plante, quelle est l'éventuelle trace, etc ...

 
J'vois parfaitement ou ça plante. Y a un truc, je sais pas si tu connais, ça s'appel un débugger, et ça me permet de voir où ça plante généralement.
Si je suis long, c'est parce que, dans ma boite, mon boulot à la base, c'est pas de faire du Java, ms du C++. J'ai plein de pettis dev en C que j'fais en même temps que cette servlet.
 
Disons que tant que jusqu'a maintenant, le debugger me suffisait. j'avais pas de merde avec tomcat.  
 
Hé bien, sinon, à part que t toujours aussi désagréable, merci pour l'histoire du log.

 
oui
 

 
Débrouille toi

 
Je ne pense pas que tu sois vraiment en mesure de faire le malin sur ce genre de choses et oui, crois moi je sais ce qu'est un débuggeur (et probablement mieux que toi vu ce que tu écris). Ensuite il faudrait peut etre que tu apprennes à faire la différence entre un code qui compile et un code qui fonctionne.  
 
Quel genre de débuggeur utilise tu pour que ca marche dans ton débuger et pas dans tomcat ... Je me le demande

 
c pas : "ça marche ds mon débugger, et pas dans tomcat"
c que j'ai aucune exception, et le résultat du forward me va pas (une page vide, c pas top). Aucune exception n'est lancée, que ça soit depuis ma servlet, ou dans le jsp que j'appel (de tte façon, apparement, ma jsp est même pas lue).
Ms le truc, c que j'utilise netbean, et du coup, j'utilise Tomcat 3.2 qui est ss forme d'un jar, reconstruit à chaque exécution de ma servlet. Du coup, g l'impression qu'il me génère pas de log. Ou alors c un paramètre à fouttre qqe part, ms où !?

Ce qu'essaye de dire DL, c'est que si tu obtiens une page blanche, alors il y a de bonne chance pour que ton erreur/exception soit écrite dans les logs de tomcat.
Tu devrais y jeter un oeil.
 
DL: je lis ce forum depuis qlq semaines et tu pourrais en effet faire un effort pour être moins désagréable.
 
K.

J'ai lu en diagonale...
 
En effet l'écriture de logs est paramétrable dans tomcat. Dans un tomcat standard/config par défaut les logs sont écrits par défaut, mais dans une version intégré dans un ide... faut chercher... ils sont certainement activables.
 

 
Ouais, bien sur, ça j'veux bien l'croire. Maintenant, y me reste à trouver comment on active les logs de ce tomcat intégré. Ou à la limite, si j'y arrive pas, je peux déployer ma web-app sur le tomcat 4.0 (indépendent de mon ide cette fois, et qui génère bien des logs, g vu.
Merci krosso, c agréable desfois une intervention sympathique, sans même une touche de mépris ! (prends en de la graine Dark )