Discussion :

[Jaxofun]

Salut à tous !

Je bosse sur une application J2EE utilisant entre autre Struts.
A chaque fois qu'un utilisateur se connecte, il s'identifie et l'application genere une instance de la classe "utilisateurBean" qui a pour but de contenir les diverses infos de l'utilisateur. Cette instance est enregistrée dans la session de l'utilisateur.

Maintenant je voudrais pouvoir, via mon application, afficher la liste des utilisateurs connectés. C'est à dire que je voudrais recupérer la liste des sessions en cours pour pouvoir acceder à l'instance d' "utilisateurBean" que chacune contient.

Seulement je n'ai aucune idée de la méthode/classe à employer pour faire cela.

Merci d'avance pout toute l'aide que vous pourrez m'apporter !

[fabszn]

Hello,

Lors de la premiere connexion tu pourrais créer une map static que tu stockerai dans le contexte de l'application.
Et chaque connexion tu pourrais ajouter les informations dont tu as besoin..
Comme le context est commun à l'application.. tu y auras acces sans probleme..

J'espere que cela t'aidera.. si tu as des questions , n'hesite pas!

[Jaxofun]

Ouais, mais si je fait un truc de ce genre (faire une liste des sessions lors de la connexion des utilisateurs), comment je la vide ?

Je m'explique :
Les sessions ce sont des instances de HttpSession qui sont initialisiées lors de la connexion d'un utilisateur (mais ou dans mon appli ?). Et puis cette instance se detruit normalement a la fin du timeout definit dans web.xml.

Mais si je l'enregistre dans une liste que se passera-t-il à la fin du timeout ? J'aurai une valeur null dans ma liste ou alors la session sera-t-elle toujours existante (puisque le garbage collector ne supprime pas une instance referencée) ?

[fabszn]

Hello,

il faut que tu utilises l'interface : HttpSessionListener
Qui te permet de donne la main sur la creation et la destruction de la session.

Aussi je ne pensais à stocker la session dans la map... mais les infos dont tu as besoin par rapport à l'utilisateur!

[Jaxofun]

bon ! c'est pas glorieux !

J'ai mis en place une classe implémentant HttpSessionListener avec les méthodes "SessionCreated" et "SessionDestroyed" contenant chacun une simple ligne de logging.

Pourtant, lorsque j'execute mon application et que je m'y connecte, je n'ai aucun message de log me disant qu'une session à été crée. Donc soit j'ai pas capter le fonctionnement des sessions, soit j'ai oublié de faire quelque chose. En tout cas ce qui est sùr c'est que le listener ne detecte aucune création de session.

voila le code du listener :

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
public class SessionListener implements HttpSessionListener {
 
	private Log logger=AppliBean.getLogger;
 
	/**
	 * Méthode éxecutée lors de la création d'une session
	 */
	public void sessionCreated(HttpSessionEvent ev){
		logger.warn("Nouvelle Session");
	}
 
 
	/**
	 * Méthode executée lors de la destruction d'une session
	 */
	public void sessionDestroyed(HttpSessionEvent ev){
		logger.warn("Session terminée");
	}
 
 
}

et dans mon web.xml :

Code :

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

1
2
3
    <listener>
    	<listener-class>projet.listener.SessionListener</listener-class>
    </listener>

J'aurais besoin qu'on me renseigne parceque j'ai un doute affreux : Y a pas besoin de coder la création d'un objet session, c'est le serveur qui s'en charge dès qu'un utilisateur se connecte ?

[thibaut]

Oui c'est exact.

[fabszn]

Hello,

Il te manque le Filter Mapping dans le web.xml. Sans ce tag le serveur ne sait pas sur quel URL appeler ton filtre.

Par l'intermediaire du filter mapping tu peux maitriser le moment d'appel de ton filtre.

[Jaxofun]

Il te manque le Filter Mapping dans le web.xml.

Par l'intermediaire du filter mapping tu peux maitriser le moment d'appel de ton filtre.

Je comprend pas, c'est pas un filtre mais un listener que tu m'as dit d'utiliser !??

[thibaut]

Oui il y a maiprise c'est bien un SessionListener qu'il faut utiliser !!!

[fabszn]

Hello,

Oooppss!! Excuse moi... je faisais deux choses en meme temps.. et effectivement je te parlais bien de listener..Il ne faut pas tenir compte de mon dernier post...

Concernant ton Listener... Je ne vois rien d'incorrecte!
Ton logger ecrit dans la console ou dans un fichier de log?
Est ce que le niveau de log prend en compte les WARNs?

Essaie de mettre des System.out.prinltn('') à la place de ton logger.

Sinon, je ne vois pas d'ou peux venir le problème... J'utilise des Listeners pour justement travailler sur l'objet Session.. et ca fonctionne tres bien.

[Jaxofun]

En effet, c'est mon logger qui *%^$ !!!

C'est ça d'être trop sùr de soi ! Bon bah je vous remercie beaucoup et vous souhaite un bon appetit !

[Jaxofun]

Bon... J'avais marqué "Résolu" sur ce thread mais depuis je me suis rendu compte d'un problème :

Lorsque l'on utilise le listener de Session, lors de la destruction d'une session, la méthode est effectivement appellée mais APRES la destruction de la-dite session (enfin... il me semble) ce qui fait que l'on ne peut plus recuperer les attributs de la session à ce moment-là.

[fabszn]

Hello,

Selon la javadoc :

sessionDestroyed

public void sessionDestroyed(HttpSessionEvent se)

Notification that a session is about to be invalidated.

Parameters:
se - the notification event

Cette methode est appeler lorsque la session va etre detruite ... donc avant.

Donc tu devrais avoir encore acces au attribut.

Est ce que tu as un message d'erreur?

[thibaut]

Exact, à ce niveau là tu as encore ta session non invalidée !!!

[Jaxofun]

Je n'ai aucune erreur, c'est le plus frustrant, car dans la methode je tente de recuperer un attribut, mais j'obtient un "null".
Un mode "debug" m'a permis de visualiser l'etat de l'objet session lorsque j'essaye de recuperer l'attribut et je me suis aperçu qu'il n'avait plus aucun attribut (alors qu'il en avait avant).

[Jaxofun]

L'objet session en soi n'est pas encore détruit, mais j'ai l'impression que les attributs qu'il contenait on été effacés eux.

[Alwin]

En fait, celà me semble normal et conforme aux normes de sécurité J2EE.
Il existait à l'époque une méthode permettant de lister les sessions en cours. Cette méthode a été retirée justement car elle était assimilée à une faille.

[Jaxofun]

Bon, pas grave, je pense avoir trouvé comment palier à ça !

En fait mon application crée un userBean (stocké en session) lors de la connexion d'un utilisateur. Afin de pouvoir obtenir la liste des userBean j'ai definit dans ce même bean une liste statique dans laquelle sont stocké chaque userBean à leur création.

Le problème était donc lors de la deconnexion de l'utilisateur (ou plus precisement de la fin de sa session) comment le reperer pour retirer le userbean correspondant de la liste.

Le listener permet de prendre la main lorsqu'une session va etre supprimée, mais elle ne contient apparement deja plus d'attributs donc impossible de savoir à quel userBean correspond cette session. Or, j'ai toujours accés aux info de la session elle-meme (id, date etc...) donc mon idée est d'enregistrer l'id de session dans mon userBean et lors de la destruction de la session rechercher dans ma liste le userBean contenant cette id pour le retirer.

D'ailleurs, si certain ont d'autre façon de gérer les utilisateurs et les sessions au sein de leurs application, je les invite à m'expliquer leur façon de faire car ça m'interesse beaucoup !

[Jaxofun]

Tient !!! je viens de me souvenir !!
Sur la page général du forum de developpez.com, en bas, y a une rubrique "Qui est en ligne" ou y a le nombre d'utilisateur connectés et meme leurs noms. C'est à peu près ce que je cherche à faire.

[frizby]

L'objet session en soi n'est pas encore détruit, mais j'ai l'impression que les attributs qu'il contenait on été effacés eux.

C'est peut-etre un peu tard mais ça peut servir à quelqu'un d'autre.
Effectivement, quand la session est détruite, les attributs qu'elle contenait n'existent déjà plus. Pour palier à ça, je créais un attribut à la création de ma session et plutot que d'écouter sur la session, j'écoutais sur cette attribut avec un HttpSessionAttributeListener.
Le premier attribut créé est aussi le premier détruit si mes souvenirs sont bons. Donc à sa déstruction tu as encore accès aux autres attributs et à la session.