wildfly-clustering-spring

wildfly-clustering-spring is a set of Spring modules providing distributed session management for Spring Session and Spring Flux using Infinispan. This brings the same clustering features of WildFly's distributed session managers to the Spring ecosystem, including:

• Servlet 6.0 specification compliance (excluding limitations inherent to Spring Session and Spring Web).
  • Including support for standard session event notifications
• Session attribute replication via an embedded cache or persistence to a remote Infinispan cluster.
• Configurable session replication/persistence strategies, i.e. per session vs per attribute.
• Similar semantics to that of an in-memory session repository, including a high level of consistency under concurrent request access, and support for mutable session attributes.
• Ability to limit the number of active sessions to retain in local memory
• Configurable session attribute marshallers.

Building

1. Clone this repository.

   $ git clone git@github.com:wildfly-clustering/wildfly-clustering-spring.git
   $ cd wildfly-clustering-spring
   

2. Build using Java 17 or higher and Apache Maven 3.8.x or higher.

   $ mvn clean install
   

Modules

• Spring Session, providing traditional HttpSession management for use with Jakarta Servlet applications and Spring MVC.
• Spring Web, providing reactive WebSession management for use with Spring Flux.

Notes

Because Spring Session and Spring Web operate entirely within user/application space (i.e. external to a servlet container's native session manager), its session management behavior will inherently deviate from the Jakarta Servlet specification in several areas. In particular, applications using Spring Session or Spring Web should be aware of the following aberrant behavior that affects every SessionRepository/WebSessionManager implementation:

1. ServletContext methods affecting session behavior, e.g. ServletContext.setSessionTimeout(int), do not propagate to the SessionRepository or WebSessionManager implementation and thus will not affect runtime behavior.

2. Spring Session and Spring Web lack any facility to notify standard listeners (instances of HttpSessionListener declared in web.xml or annotated with @WebListener) of newly created or destroyed sessions. Users must instead rely on Spring's own event mechanism.

3. Spring Session and Spring Web lack any facility to notify standard listeners (instances of HttpSessionAttributeListener declared in web.xml or annotated with @WebListener) of new, replaced and removed session attributes. Spring has no mechanism for triggering these events.

4. Spring Session and Spring Web lack any facility to notify standard listeners (instances of HttpSessionIdListener declared in web.xml or annotated with @WebListener) of session identifier changes resulting from HttpServletRequest.changeSessionId(). Users must instead rely on Spring's own event mechanism.

5. Applications using Spring Session or Spring Web will generally need to rely on Spring Security for authentication and authorization. Many authentication mechanisms store user identity in the HttpSession or will need to change the session ID following authentication - a common practice for preventing session fixation attacks. Since the servlet container has no access to sessions created by Spring, most container managed security mechanisms will not work.