Attribut de session vidé après une exception non catchée [Résolu]

[danyboy85]

Bonjour,

J'ai une application dont le point d'entrée est une servlet. Dans cette servlet je met un attribut "user" en session. Ensuite, je redirige l'utilisateur vers une JSP.

Dans cette JSP j'ai un appel Ajax vers une autre servlet. Lorsque une exception non catchée se produit côté serveur (erreur 500) à l'appel de cette servlet, l'attribut user de ma session devient null.

Avez-vous une idée pourquoi ? J'avoue ne pas trop voir le rapport, est-ce que le fait d'avoir une exception non catchée flush la session ?

Merci d'avance

Dany

[thierryler]

Faudrait nous donner un peu de code je pense.

Est ce que tu as accès aux autres éléments de ta sessions ? C'est bien la même session ?

[danyboy85]

Voici un peu de détails :

Servlet 1 (point d'entrée de l'application) :

Code :

1
2
3
4
5
6
7
8
9
10
11
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 
	final String idrh = req.getParameter("idrh");
 
	IUtilisateurDao utilisateurDao = new UtilisateurDaoImpl();
	utilisateur = utilisateurDao.getUtilisateur(idrh);
	req.getSession().setAttribute("utilisateur", utilisateur)
 
	System.out.println(utilisateur.getNom()); // Affiche bien le nom de l'utilisateur, donc il n'est pas null
}

Servlet 2 (appelée par une requête Ajax) :

Code :

1
2
3
4
5
6
7
 
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 
	Long a = Long.parseLong("qsdgfqsd"); // Génère volontairement une NumberFormatException
 
}

Servlet 3 (appelée par un bouton submit dans ma JSP) :

Code :

1
2
3
4
5
6
7
 
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 
	final Utilisateur utilisateur = (Utilisateur)req.getSession().getAttribute("utilisateur");
	System.out.println(utilisateur); // Affiche null
 
}

Si je mets en commentaire la ligne provoquant l'exception dans la Servlet 2, l'utilisateur n'est pas null lors de son affichage dans la Servlet 3.

EDIT : pour répondre à ta question thierryler, je n'ai pas accès aux autres éléments de ma session non plus.

[danyboy85]

Ah ah... après avoir investigué, lorsque je passe dans ma "Servlet 3", l'id de session a changé ! Il est donc logique que je ne retrouve pas mes attributs.

Mais alors ma question est la suivante : pourquoi est-ce que ma première session est invalidée après mon exception ?

[thierryler]

Ma question était orientée, comme tu as du le deviner.

Deux pistes :
1) toutes tes appels vont vers des sessions différentes ;
2) ou alors tes appels standards et ajax ont deux sessions différentes.

[danyboy85]

Je pense devoir écarter tes pistes car lorsque je n'ai pas d'exception, l'id de session ne change pas et mes attributs sont toujours dans la session.

[thierryler]

Fais voir la trace avec ton exception. On va peut être découvrir un truc dedans. A mon avis ça doit être tout con.

[danyboy85]

Voici la trace, j'ai remplacé mes noms de package par --------------, simple précaution de confidentialité :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
4 déc. 2012 15:31:38 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: "Servlet.service()" pour la servlet InviteController a généré une exception
java.lang.NumberFormatException: For input string: "qsdgfqsd"
	at java.lang.NumberFormatException.forInputString(Unknown Source)
	at java.lang.Long.parseLong(Unknown Source)
	at java.lang.Long.parseLong(Unknown Source)
	at fr.-------------------.controller.InviteController.doPost(InviteController.java:395)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at fr.-------------------.security.SecurityFilter.doFilter(SecurityFilter.java:129)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at fr.-------------------.security.EncodingFilter.doFilter(EncodingFilter.java:18)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
	at java.lang.Thread.run(Unknown Source)

[thierryler]

Tu peux mettre ça dans ta servlet 2 avant le cast qui fait planter :

Code :

1
2
3
 
final Utilisateur utilisateur = (Utilisateur)req.getSession().getAttribute("utilisateur");
	System.out.println(utilisateur);

[thierryler]

Dans tous les cas, j'aurais tendance à dire que tu devrais avoir un try catch autour de ton cast de Long, comme ça a l'air d'être fonctionnel. Du coup ça résoudrait aussi ton affaire.

[danyboy85]

J'avais déjà fais le test, à ce moment là l'utilisateur est bien présent dans la session.

C'est vraiment l'exception qui provoque le problème

[danyboy85]

Envoyé par thierryler

Dans tous les cas, j'aurais tendance à dire que tu devrais avoir un try catch autour de ton cast de Long, comme ça a l'air d'être fonctionnel. Du coup ça résoudrait aussi ton affaire.

Nan mais tu te doutes bien que pour l'exemple je force une exception pourrie mais ma servlet appel des services qui peuvent potentiellement générer des exceptions techniques de toute sorte.

[thierryler]

Oui mais si tu ne gères pas l'exception au niveau du doPost, tu vas la laisser se propager ?

Attend, je fais le point dans mon esprit.

Ta servlet 1 met le user en session.

Ta servlet 2, appelée en ajax depuis la JSP, fait l'exception. Du coup l'appel Ajax se fini en erreur.

Quand tu vas dans servlet 3, le user a disparu, mais ça reste le même id de session ?

Ca fait longtemps que j'ai pas fais de servlet pure... A tout hasard, ton exception n'a pas flingué ta session ? Je veux dire, toute la session, pas juste tes params.

Dans tous les cas, je persiste, ta servlet 2 devrait gérer l'exception.

[danyboy85]

Alors, mon exception flingue ma session, pas juste les attributs, car l'id de session a changé quand j'appelle la Servlet 3.

Ensuite, au niveau de ta remarque sur le fait de gérer l'exception, ça veut dire que je suis obligé de faire un vieux try catch de java.lang.Exception pour être sûr de pas pommer ma session... Pas sûr que ce soit une bonne pratique. Moi je catch les exceptions que je connais (que j'ai identifié) et pour le reste, la trace renseigne sur l'exception et l'utilisateur est simplement averti d'une erreur 500.

Après si tu me dis qu'une exception non catchée dans une servlet provoque la mort de la session, ok.
Mais en faisant des recherches sur Google, j'ai n'ai rien trouvé en ce sens. C'est pour ça, ça me parait bizarre ce problème...

[danyboy85]

Ah la la j'ai trouvé ! Vicieux...

Voici un extrait de mon web.xml :

Code :

1
2
3
4
5
 
<error-page>
    <error-code>500</error-code>
    <location>/jsp/erreur500.jsp</location>
</error-page>

Lorsque mon exception se produit, elle gènère une erreur 500. Comme je suis dans le cadre d'un appel Ajax, il n'y a pas de redirection vers la page erreur500.jsp, mais celle-ci est tout de même interprétée et envoyée dans l'objet "reponse" de la requête.

Et voici une partie du code de erreur500.jsp :

Code :

1
2
3
4
session.removeAttribute(SecurityFilter.SSO_ID);
session.removeAttribute(SecurityFilter.SSO_INFO);
session.invalidate();

CQFD.

[thierryler]

Effectivement...

[danyboy85]

En tout cas merci de ton aide

[thierryler]

Je t'en prie. Au moins ça a mis sur la bonne piste.