[Jsp/Servlet] Problème lors du premier forward depuis ma servlet

Problème lors du premier forward depuis ma servlet [Jsp/Servlet] - Java - Programmation

Marsh Posté le 09-07-2002 à 10:33:46    

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:

Code :
  1. // Redirection vers la page de login
  2.             String url = JLdsProperties.getProperties().getProperty ("htm.loginfilepath", "/interface/login.htm" );
  3.             String encodedUrl = response.encodeURL(url);
  4.             RequestDispatcher dispatcher = this.getServletContext().getRequestDispatcher(encodedUrl); 
  5.             dispatcher.forward(request, response);


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 !?

Reply

Marsh Posté le 09-07-2002 à 10:33:46   

Reply

Marsh Posté le 09-07-2002 à 10:59:28    

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 :)


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 09-07-2002 à 11:06:40    

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 !

Reply

Marsh Posté le 09-07-2002 à 11:50:13    

el_gringo a écrit a écrit :

 
 
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 ...


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 09-07-2002 à 11:59:15    

DarkLord a écrit a écrit :

 
 
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 !

Reply

Marsh Posté le 09-07-2002 à 12:10:54    

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 ;)
 


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 09-07-2002 à 14:07:00    

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 !

Reply

Marsh Posté le 10-07-2002 à 09:57:39    

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

Code :
  1. // Appel d'une page jsp pour affichage des résultats
  2.         url = path + fileName;
  3.         String encodedUrl = response.encodeURL(url);
  4.         RequestDispatcher dispatcher = this.getServletContext().getRequestDispatcher(encodedUrl);
  5.         dispatcher.forward(request, response);
  6.         out.close ();


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

Code :
  1. monURI;jsessionid=9cnsege5x9

(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 !?)

Reply

Marsh Posté le 10-07-2002 à 10:12:21    

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


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 10-07-2002 à 10:18:45    

DarkLord a écrit a écrit :

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 !? :D

Reply

Marsh Posté le 10-07-2002 à 10:18:45   

Reply

Marsh Posté le 10-07-2002 à 10:23:37    

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

Citation :


encodeURL permet de faire du session tracking lorque les cookies ne sont pas disponibles chez le client


 
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 ...
 

Citation :


heu... dans quels LOGS !? :D


 
Je comprends mieux pq tu poses des questions du genre et pq tes problèmes mettent autant de temps à être résolu ...  :sarcastic:  
 
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 ...


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 10-07-2002 à 11:31:54    

DarkLord a écrit a écrit :

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 ...




 
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 ...  :sarcastic:  
 
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.

Reply

Marsh Posté le 10-07-2002 à 11:35:04    

Citation :


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 .


 
oui
 

Citation :


Hé bien, sinon, à part que t toujours aussi désagréable


 
Débrouille toi


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 10-07-2002 à 11:36:42    

el_gringo a écrit a écrit :

 
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.
 
Disons que tant que jusqu'a maintenant, le debugger me suffisait. j'avais pas de merde avec tomcat.  




 
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


Message édité par darklord le 10-07-2002 à 11:37:12

---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 10-07-2002 à 11:57:43    

DarkLord a écrit a écrit :

 
 
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ù !?

Reply

Marsh Posté le 10-07-2002 à 13:47:39    

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.

Reply

Marsh Posté le 10-07-2002 à 13:50:20    

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.
 

Reply

Marsh Posté le 10-07-2002 à 14:17:06    

krosso a écrit a écrit :

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.




 
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 :D)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed