c'est possible ou pas ?
car avec HttpSessionListener via sessionDestroyed
mes variables de session ne sont plus accessible (attributes à null) j'en deduis que la session doit deja etre detruite ...
or j'ai besoin d'info stocké dedans pour mon log de l'appli (user en cours dans un objet maison)
 
comment faire ?  

ou autre moyen de faire un traitement à ce moment là

pour moi, tu devrais recevoir l'evenement avant que les attributs soient retirés ... j'ai vérifié, mais c'est pas précisé dans la spec des servlets. mais ca me parait évident.
 
Sinon, essaye avec un HttpSessionAttributeListener. Peut être que l'évenement attributeRemoved est lancé au moment de la destruction de la session ... mais c'est de la bidouille

dans les docs que j'ai consulté ils disent que c'est après
en gros tout est dispo sauf les attributs (breakpoint sous eclipse)
 

liens ?
 
y a quoi d'intéressant dans une session a part les attributs ?

pour attributeRemoved ca marche même si c'est un peu crade

 
date de creation, dernier accès, id et autres joyeusetés ...

http://www.jguru.com/faq/view.jsp?EID=994198
 
When the HttpSessionListener.sessionDestroyed() method is called by the container, the session is already dead (the actual HttpSession object is alive, though). If the browser sends a request just before that moment (session still alive), the session timeout is renewed. If the browser sends a request just after that moment (session already dead), we cannot recognize the relation between "the session that was killed about 48 seconds ago" and the incoming request (which doesn't have an existing session, yet)

je comprend pas pkoi la session est détruite avant l'appel
J'y vois pas de raison, mais plein d'inconvénients ...

 
pas grave on est en train de recoder notre propre serveur à 100%

moi non plus mais cela dit, deux remarques:
- le nom de la methode est correct et laisse entendre que la session à déjà été detruite
- sur l'article jguru en questions ils disent que l'objet HttpSession est tjs là, ce qui sous entend que le seul truc qui a "changé", c''est que la session n'est plus valide donc plus utilisable par l'utilisateur; par contre ça ne dit pas - au contraire, même - que les attributs stockés dans cette meme session sont absents.

 
y a des courageux là où je bosse ...

nan mais .... POURQUOI FAIRE ???  

y'en a bien qui réécrivent un moteur ejb

a l'époque les solutions gratuites n'existaient pas et le coût des licences des produits payants était assez dissuasif
 
mais bon, j'y suis pour rien moi de ce que fait ma boite

 
vu qu'on utilise un spectre faible de tomcat pour l'instant et que l'on a des problemes de perfs c'est dans le but d'avoir de meilleurs perf je crois

problème de perfs ?
vraiment ??
vous avez regardé à quel niveau tomcat bouffait les perfs ?
 
parce que, mis à part l'execution en elle même de la servlet, je pense que l'acheminement d'une requête doit être plutot performant ...

 
Dan ma boîte, on utilise Cocoon pour base de notre soft de publication et on fait tourner dans Tomcat...et ça bouffe un max de resources.
 
On a commencé avec la série 3.x de Tomcat (sans cocoon), et au fil des versions (4.x puis 5.x) on a vu les besoins en mémoire de Tomcat crever le plafond.

prenez resin
et puis bon, cocoon doit pas y etre pour rien non plus....

 
Resin est payant !!! mais on peut pas tout avoir
Cocoon et gourmand même si depuis la série 2.1.x ils ont fait de très gros progrès niveau gestion resources et mémoire

et le soft de machin truc de ta boite c'est du gratuit et libre peut etre?

 
Ben heu...

T'es sûr que c'est tomcat qui bouffe plus de ressources ???? vraiment ???? j'ai un GROS GROS doute là !
 
vous avez profilé pour savoir où elle passait cette mémoire ?
 
edit : ma question initiale reste ouverte

 
Ho que oui. même si Cocoon est très gourmand, Tomcat 5.x en lui-même pompe pas mal.

faudrai que je teste un peu avec jfluid notre appli (generation de poly, site web à partir de plein de fichiers xml)