Attribut de session vidé après une exception non catchée

**danyboy85** · 04/12/2012, 14h10

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** · 04/12/2012, 14h15

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** · 04/12/2012, 14h46

Voici un peu de détails :

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

Code :

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

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 :

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

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 :

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

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** · 04/12/2012, 15h13

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** · 04/12/2012, 15h25

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** · 04/12/2012, 15h27

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** · 04/12/2012, 15h30

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** · 04/12/2012, 15h34

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

Code :

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

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** · 04/12/2012, 15h42

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

Code :

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

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

**thierryler** · 04/12/2012, 15h44

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** · 04/12/2012, 15h45

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** · 04/12/2012, 15h47

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** · 04/12/2012, 15h56

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** · 04/12/2012, 16h08

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** · 04/12/2012, 16h20

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

Voici un extrait de mon web.xml :

Code :

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

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 :

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

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

CQFD.

**thierryler** · 04/12/2012, 16h34

Effectivement...

**danyboy85** · 04/12/2012, 16h36

En tout cas merci de ton aide

**thierryler** · 04/12/2012, 16h52

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

Attribut de session vidé après une exception non catchée

Servlets/JSP Java

Discussions similaires

Partager

Partager