Les trois interfaces que l'on peut implémenter sont ServletContextAttributeListener, ServletRequestAttributeListener et HttpSessionAttributeListener. Ces trois interfaces exposent les trois mêmes méthodes : 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 : 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().

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 : 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. L'objet HttpSessionEvent n'expose qu'une unique méthode : getSession(), qui retourne la session concernée.