Version imprimable
Bonjour,
Si dans la définition de la méthode ValueBound(HttpSessionBindingEvent evt) on n'utilise pas la méthode getName de HttpSessionBindingEvent quel est l'intéret d'utiliser HttpSessionBindingListener plutôt que HttpSessionListener?
La seule différence que je vois est que HttpSessionBindingListener n'est pas déclaré comme listener dans le web xml, puisqu'il est rattaché a une servlet qui elle est mappée
Merci de vos éclaircissements
Le session listener est notifié quand des session son créées ou supprimées. C'est un évenement glboal a la webapp et il faut enregistrer un tel listener dans le web.xml. Ca permet, par exemple, de compter le nombre de users en lignes.
Le session binding est notifié quand un objet précis est inséré ou retiré d'un session. Au cours de la vie d'une session, une certains nombre d'objets peuvent y etre ajouté ou supprimé plusieur fois. C'est un évènement local à l'objet inséré / supprimé. C'est d'ailleurs une interface que doit implémenter un objet qui désirer et informé de son propre ajout à une session.
Merci tchize
, ton explication est très claire, cepandant j'ai du mal à trouver des exemples concrets d'objets souhaitant être notifiés de leur appartenance a une sessionCitation:
Ce qui ce conçoit bien s'enonce clairement...
Si tu as des exemples :oops:
Merci
Ps le seul exemple que j'ai trouvé est celui d'une connexion SQL, bien que pour l'instant son initialisation au lancement de l'application (ServletContextListener) me convient...
les cas d'utilisation sont rare. Il faut un objet qui possède un état devant necessiter, a priori, un nettoyage. Associé au fait que cet objet existe au rythme de 1 par utilisateur (donc session) et au fait qu'il soit stocké dans la session. Quand on considère qu'on demande, en général de ne stocker que des objets léger et sérializable dans la session il y a contradiction sur les contraintes. Personellement, en 5 ans de développement web, je n'ai jamais eu besoin de cette interface!