Comme son nom le laisse supposer, un objet listener est un objet qui écoute certains événements dans une application. Lorsque l'événement qu'il écoute se déclenche, alors ce listener s'active : en général, une de ses méthodes particulière est invoquée, avec en paramètre un objet portant les informations sur cet événement.
Le principe de fonctionnement est donc celui du callback : en tant que développeur d'application web,
on enregistre des listeners auprès du serveur d'application. Ces objets
doivent implémenter des interfaces standard, fournies par l'API Servlet, et être déclarés dans le
descripteur d'une application web : le fichier web.xml
.
Les événements définis par l'API Servlet sont au nombre de sept :
Trois événements concernent l'ajout ou le retrait d'un attribut sur le contexte, la session ou une
requête : ServletContextEvent
, HttpSessionEvent
et
ServletRequestEvent
.
Deux événements sont associés à la création ou à la destruction du contexte, ou
d'une requête : ServletContextEvent
et ServletRequestEvent
.
Un événement est associé au cycle de vie d'une session : HttpSessionEvent
. Cet
événement est utilisé par deux listeners : HttpSessionListener
et HttpSessionActivationListener
. Ces deux listeners sont associés
au cycle de vie particulier des sessions, que nous allons voir dans la suite.
Un dernier événement permet de signaler à un objet qu'il a été ajouté à une session, ou qu'il
va en être retiré : HttpSessionBindingEvent
.
Les trois interfaces que l'on peut implémenter sont ServletContextAttributeListener
,
ServletRequestAttributeListener
et HttpSessionAttributeListener
.
Ces trois interfaces exposent les trois mêmes méthodes :
attributeAdded()
: appelée lorsqu'un attribut est ajouté au contexte considéré ;
attributeRemoved()
: appelé lorsqu'un attribut est retiré du contexte
considéré ;
attributeReplaced()
: appelé lorsqu'un attribut a été remplacé par un autre.
Ces trois méthodes callback sont appelées une fois que l'événement d'ajout, de retrait, ou de remplacement a été effectué.
Ces trois méthodes prennent des paramètres différents en fonction du contexte, qui sont les événements que nous avons vus. Ces objets exposent tous les trois les même méthodes :
getName()
: le nom de l'attribut concerné ;
getValue()
: la valeur de l'attribut concerné.
L'objet HttpSessionBindingEvent
, utilisé pour signaler à un objet qu'il a été ajouté
ou retiré d'une session expose en plus une méthode getSession()
.
Chaque contexte possède son interface listener.
Le listener de création et destruction de l'application web doit implémenter l'interface
ServletContextListener
. Cette interface expose deux méthodes :
contextInitialized()
et contextDestroyed()
.
Ces deux méthodes sont invoquées avant toute invoquation de filtre ou de servlet, et après
l'appel à toutes les méthodes destroy()
des filtres et servlets de cette application,
respectivement.
Elles prennent en paramètre le même objet, de type ServletContextEvent
. Cet objet
expose une unique méthode : getServletContext()
, qui retourne l'objet
ServletContext
. Cet objet modèlise l'application web proprement dite.
Le listener de ce contexte implémente l'interface ServletRequestListener
. Elle
expose deux méthodes : requestInitialized()
et requestDestroyed()
.
Ces deux méthodes prennent en paramètre le même objet, instance de ServletRequestEvent
.
Cet objet permet d'accèder au contexte de l'application web par la méthode
getServletContext()
, et à l'objet requête par la méthode getServletRequest()
.
La session a un cycle de vie un peu particulier, du fait de sa nature. Rappelons tout d'abord qu'une application web n'a pas nécessairement besoin de la notion de session. Une session devient nécessaire lorsque l'on a besoin de reconnaître un client donné d'une requête à l'autre.
Dans ce cas, une session est créée lors de la première requête de ce client. Cette session a une durée de vie, au-delà de laquelle elle est détruite. Cette durée de vie peut être plus ou moins longue : de quelques heures à plusieurs mois.
Si les requêtes d'une même session se succèdent rapidement, alors cette session sera probablement conservée en mémoire. Si le client reste plusieurs heures sans revenir sur le site, et que le site choisit de conserver tout de même sa session, celle-ci sera probablement déchargée de la mémoire, et conservée sur un support persistant, probablement une base de données.
On voit que quatre types d'événements peuvent alors exister pour une session :
La création : elle intervient lors de la première requête.
La destruction : elle peut ne jamais arriver, ou au bout d'un temps très long.
La passivation : c'est ce qui se passe lorsqu'une session est déplacée de la mémoire vers un espace de stockage persistant. La session n'est pas détruite, elle passe dans un état de type "inactif".
L'activation : ce qui se passe lorsqu'un client revient après une longue période d'absence. Sa session est rechargée de l'espace de stockage persistant vers la mémoire.
Notons que la passivation d'une session peu intervenir en environnement clusterisé, lorsqu'une session doit passer d'un nœud du cluster à un autre.
Ces quatre événements sont gérés par deux interfaces.
HttpSessionListener
: expose les méthodes sessionCreated()
et
sessionDestroyed()
, qui prennent en paramètre un objet HttpSessionEvent
.
HttpSessionActivationListener
: expose les méthodes sessionDidActivate()
et sessionWillPassivate()
. Ces deux méthodes prennent en paramètre le même objet
HttpSessionEvent
.
L'objet HttpSessionEvent
n'expose qu'une unique méthode : getSession()
,
qui retourne la session concernée.
Enfin, un objet peut être notifié du fait qu'il a été ajouté à une session. Il doit pour cela
implémenter l'interface HttpSessionBindingListener
. Cette interface expose deux
méthodes :
valueBound(HttpSessionBindingEvent)
: appelée lorsque l'objet est attaché
à une session ;
valueUnbound(HttpSessionBindingEvent)
: appelée lorsque l'objet est détachée
de la session.
Ces deux méthodes reçoivent en paramètre un objet de type HttpSessionBindingEvent
.
Cet événement expose les deux méthodes classiques getName()
et getValue()
.
Il expose également getSession()
, qui retourne la session à laquelle cet objet
est attaché, ou de laquelle il est détaché.
Tous les listeners que nous avons vu doivent être déclarés dans le fichier web.xml
.