SEC-2007: Fire HttpSessionActivationListener events from HttpSessionEventPublisher

Adib Saikali (Migrated from SEC-2007) said:

The current HttpSessionEventPublisher fires only session created and destroyed events on the Application Context, it would great if it also fired SessionActivation events. Her is a use case to motivate this feature request.

The application is using an In Memory Cache of computed user profile items, this cache is configured without an upper bound since it is keyed by the user id and eviction from the cache is managed by the application. When a user logs out it is possible to get SessionDestroyedEvent and evict the user items from the Cache.

The SessionActivation Events are fired when the container is kicking out a session to disk because it not being used actively but not yet expired, this happens in response to memory pressure therefore the application should evict the user items from the Cache on sessionWillPassivate event to participate in the efforts to manage memory.

Right now the workaround to is implement an application specific HttpSessionActivationListener and it to web.xml and then explicitly retrieve the security context from the session using code like so event.getSession().getAttribute( HttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY);

This really feels like a hack and for some reason the events fired by the HttpSessionListener return a List of Security Contexts and it not clear why there would be a list of security contexts in a single session.

This should be relatively easy to implement.

Start with HttpSessionEventPublisher and the HttpSessionActivationListener contract, then compare the existing session-created and session-destroyed event handling. The change is done when session activation events, including passivation, are published through the application context so applications no longer need the web.xml listener workaround.