Spring Session

Spring Session provides an API and implementations for managing a user’s session information.

Introduction

Spring Session provides an API and implementations for managing a user’s session information. It also provides transparent integration with:

  • HttpSession - allows replacing the HttpSession in an application container (i.e. Tomcat) neutral way. Additional features include:

    • Clustered Sessions - Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution.

    • Multiple Browser Sessions - Spring Session supports managing multiple users' sessions in a single browser instance (i.e. multiple authenticated accounts similar to Google).

    • RESTful APIs - Spring Session allows providing session ids in headers to work with RESTful APIs

  • WebSocket - provides the ability to keep the HttpSession alive when receiving WebSocket messages

What’s New in 1.3

Below are the highlights of what is new in Spring Session 1.3. You can find a complete list of what’s new by referring to the changelogs of 1.3.0.M1 , 1.3.0.M2 , 1.3.0.RC1 , and 1.3.0.RELEASE .

Samples and Guides (Start Here)

If you are looking to get started with Spring Session, the best place to start is our Sample Applications.

Table 1. Sample Applications
Source Description Guide

HttpSession

Demonstrates how to use Spring Session to replace the HttpSession with a Redis store.

HttpSession Guide

HttpSession XML

Demonstrates how to use Spring Session to replace the HttpSession with a Redis store using XML based configuration.

HttpSession XML Guide

HttpSession with GemFire using Spring Boot

Demonstrates how to use Spring Session to replace the HttpSession with GemFire using a Client/Server topology in a Spring Boot application.

HttpSession GemFire Boot Guide

HttpSession with GemFire (Client/Server)

Demonstrates how to use Spring Session to replace the HttpSession with GemFire using a Client/Server topology.

HttpSession GemFire Client/Server Guide

HttpSession with GemFire (Client/Server) using XML

Demonstrates how to use Spring Session to replace the HttpSession with GemFire using a Client/Server topology configured with XML.

HttpSession GemFire Client/Server XML Guide

HttpSession with GemFire (P2P)

Demonstrates how to use Spring Session to replace the HttpSession with GemFire using a P2P topology.

HttpSession GemFire P2P Guide

HttpSession with GemFire (P2P) using XML

Demonstrates how to use Spring Session to replace the HttpSession with GemFire using a P2P topology configured with XML.

HttpSession GemFire P2P XML Guide

Custom Cookie

Demonstrates how to use Spring Session and customize the cookie.

Custom Cookie Guide

Spring Boot

Demonstrates how to use Spring Session with Spring Boot.

Spring Boot Guide

Grails 3

Demonstrates how to use Spring Session with Grails 3.

Grails 3 Guide

Spring Security

Demonstrates how to use Spring Session with an existing Spring Security application.

Spring Security Guide

REST

Demonstrates how to use Spring Session in a REST application to support authenticating with a header.

REST Guide

Find by Username

Demonstrates how to use Spring Session to find sessions by username.

Find by Username

Multiple Users

Demonstrates how to use Spring Session to manage multiple simultaneous browser sessions (i.e Google Accounts).

Manage Multiple Users Guide

WebSocket

Demonstrates how to use Spring Session with WebSockets.

WebSocket Guide

Mongo

Demonstrates how to use Spring Session with Mongo.

Mongo Guide

Hazelcast

Demonstrates how to use Spring Session with Hazelcast.

TBD

Hazelcast Spring

Demonstrates how to use Spring Session and Hazelcast with an existing Spring Security application.

Hazelcast Spring Guide

HttpSession JDBC

Demonstrates how to use Spring Session to replace the HttpSession with a relational database store.

HttpSession JDBC Guide

HttpSession JDBC XML

Demonstrates how to use Spring Session to replace the HttpSession with a relational database store using XML based configuration.

HttpSession JDBC XML Guide

HttpSession JDBC Spring Boot

Demonstrates how to use Spring Session to replace the HttpSession with a relational database store when using Spring Boot.

HttpSession JDBC Spring Boot Guide

HttpSession Integration

Spring Session provides transparent integration with HttpSession. This means that developers can switch the HttpSession implementation out with an implementation that is backed by Spring Session.

Why Spring Session & HttpSession?

We have already mentioned that Spring Session provides transparent integration with HttpSession, but what benefits do we get out of this?

  • Clustered Sessions - Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution.

  • Multiple Browser Sessions - Spring Session supports managing multiple users' sessions in a single browser instance (i.e. multiple authenticated accounts similar to Google).

  • RESTful APIs - Spring Session allows providing session ids in headers to work with RESTful APIs

HttpSession with Redis

Using Spring Session with HttpSession is enabled by adding a Servlet Filter before anything that uses the HttpSession. You can choose from enabling this using either:

Redis Java Based Configuration

This section describes how to use Redis to back HttpSession using Java based configuration.

The HttpSession Sample provides a working sample on how to integrate Spring Session and HttpSession using Java configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession Guide when integrating with your own application.
Spring Java Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

@EnableRedisHttpSession (1)
public class Config {

        @Bean
        public LettuceConnectionFactory connectionFactory() {
                return new LettuceConnectionFactory(); (2)
        }
}
1 The @EnableRedisHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by Redis.
2 We create a RedisConnectionFactory that connects Spring Session to the Redis Server. We configure the connection to connect to localhost on the default port (6379) For more information on configuring Spring Data Redis, refer to the reference documentation .
Java Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, Spring needs to load our Config class. Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer both of these steps extremely easy. You can find an example below:

src/main/java/sample/Initializer.java
public class Initializer extends AbstractHttpSessionApplicationInitializer { (1)

        public Initializer() {
                super(Config.class); (2)
        }
}
The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.
1 The first step is to extend AbstractHttpSessionApplicationInitializer. This ensures that the Spring Bean by the name springSessionRepositoryFilter is registered with our Servlet Container for every request.
2 AbstractHttpSessionApplicationInitializer also provides a mechanism to easily ensure Spring loads our Config.

Redis XML Based Configuration

This section describes how to use Redis to back HttpSession using XML based configuration.

The HttpSession XML Sample provides a working sample on how to integrate Spring Session and HttpSession using XML configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession XML Guide when integrating with your own application.
Spring XML Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

src/main/webapp/WEB-INF/spring/session.xml
(1)
<context:annotation-config/>
<bean class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration"/>

(2)
<bean class="org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory"/>
1 We use the combination of <context:annotation-config/> and RedisHttpSessionConfiguration because Spring Session does not yet provide XML Namespace support (see gh-104 ). This creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by Redis.
2 We create a RedisConnectionFactory that connects Spring Session to the Redis Server. We configure the connection to connect to localhost on the default port (6379) For more information on configuring Spring Data Redis, refer to the reference documentation .
XML Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, we need to instruct Spring to load our session.xml configuration. We do this with the following configuration:

src/main/webapp/WEB-INF/web.xml
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/*.xml
    </param-value>
</context-param>
<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

The ContextLoaderListener reads the contextConfigLocation and picks up our session.xml configuration.

Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. The following snippet performs this last step for us:

src/main/webapp/WEB-INF/web.xml
<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

The DelegatingFilterProxy will look up a Bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every request that DelegatingFilterProxy is invoked, the springSessionRepositoryFilter will be invoked.

HttpSession with Pivotal GemFire

When Pivotal GemFire is used with Spring Session, a web application’s HttpSession can be replaced with a clustered implementation managed by GemFire and conveniently accessed with Spring Session’s API.

The two most common topologies to manage Spring Sessions using GemFire include:

Additionally, GemFire supports site-to-site replication using WAN functionality . The ability to configure and use GemFire’s WAN support is independent of Spring Session, and is beyond the scope of this document. More details on GemFire WAN functionality can be found here .

GemFire Client-Server

The Client-Server topology will probably be the more common configuration preference for users when using GemFire as a provider in Spring Session since a GemFire server will have significantly different and unique JVM heap requirements when compared to the application. Using a client-server topology enables an application to manage (e.g. replicate) application state independently from other application processes.

In a client-server topology, an application using Spring Session will open a client cache connection to a (remote) GemFire server cluster to manage and provide consistent access to all HttpSession state.

You can configure a Client-Server topology with either:

GemFire Client-Server Java-based Configuration

This section describes how to use GemFire’s Client-Server topology to back an HttpSession with Java-based configuration.

The HttpSession with GemFire (Client-Server) Sample provides a working sample on how to integrate Spring Session and GemFire to replace the HttpSession using Java configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession with GemFire (Client-Server) Guide when integrating with your own application.
Spring Java Configuration

After adding the required dependencies and repository declarations, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession with an implementation backed by Spring Session and GemFire.

Add the following Spring Configuration:

@EnableGemFireHttpSession(maxInactiveIntervalInSeconds = 30, poolName = "DEFAULT") (1)
public class ClientConfig {

        static final long DEFAULT_WAIT_DURATION = TimeUnit.SECONDS.toMillis(20);

        static final CountDownLatch latch = new CountDownLatch(1);

        static final String DEFAULT_GEMFIRE_LOG_LEVEL = "warning";

        @Bean
        static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() {
                return new PropertySourcesPlaceholderConfigurer();
        }

        Properties gemfireProperties() { (2)
                Properties gemfireProperties = new Properties();
                gemfireProperties.setProperty("name", applicationName());
                gemfireProperties.setProperty("log-level", logLevel());
                return gemfireProperties;
        }

        String applicationName() {
                return "samples:httpsession-gemfire-clientserver:"
                        .concat(getClass().getSimpleName());
        }

        String logLevel() {
                return System.getProperty("sample.httpsession.gemfire.log-level",
                        DEFAULT_GEMFIRE_LOG_LEVEL);
        }

        @Bean
        ClientCacheFactoryBean gemfireCache(
                        @Value("${spring.session.data.gemfire.port:" + ServerConfig.SERVER_PORT + "}") int port) { (3)

                ClientCacheFactoryBean clientCacheFactory = new ClientCacheFactoryBean();

                clientCacheFactory.setClose(true);
                clientCacheFactory.setProperties(gemfireProperties());

                // GemFire Pool settings (4)
                clientCacheFactory.setKeepAlive(false);
                clientCacheFactory.setPingInterval(TimeUnit.SECONDS.toMillis(5));
                clientCacheFactory.setReadTimeout(2000); // 2 seconds
                clientCacheFactory.setRetryAttempts(1);
                clientCacheFactory.setSubscriptionEnabled(true);
                clientCacheFactory.setThreadLocalConnections(false);

                clientCacheFactory.setServers(Collections.singletonList(
                        newConnectionEndpoint(ServerConfig.SERVER_HOST, port)));

                return clientCacheFactory;
        }

        ConnectionEndpoint newConnectionEndpoint(String host, int port) {
                return new ConnectionEndpoint(host, port);
        }

        @Bean
        BeanPostProcessor gemfireCacheServerReadyBeanPostProcessor() { (5)
                return new BeanPostProcessor() {

                        public Object postProcessBeforeInitialization(Object bean, String beanName)
                                throws BeansException {

                                if ("gemfirePool".equals(beanName)) {
                                        ClientMembership.registerClientMembershipListener(
                                                new ClientMembershipListenerAdapter() {
                                                        @Override
                                                        public void memberJoined(ClientMembershipEvent event) {
                                                                latch.countDown();
                                                        }
                                                });
                                }

                                return bean;
                        }

                        public Object postProcessAfterInitialization(Object bean, String beanName)
                                throws BeansException {

                                if (bean instanceof Pool && "gemfirePool".equals(beanName)) {
                                        try {
                                                Assert.state(latch.await(DEFAULT_WAIT_DURATION, TimeUnit.MILLISECONDS),
                                                        String.format("GemFire Cache Server failed to start on host [%1$s] and port [%2$d]",
                                                                ServerConfig.SERVER_HOST, ServerConfig.SERVER_PORT));
                                        }
                                        catch (InterruptedException e) {
                                                Thread.currentThread().interrupt();
                                        }
                                }

                                return bean;
                        }
                };
        }
1 The @EnableGemFireHttpSession annotation creates a Spring bean named springSessionRepositoryFilter that implements Filter. The filter is what replaces the HttpSession with an implementation backed by Spring Session and GemFire.
2 Next, we register a Properties bean that allows us to configure certain aspects of the GemFire client cache using GemFire’s System properties .
3 We use the Properties to configure an instance of a GemFire ClientCache.
4 Then, we configure a Pool of client connections to talk to the GemFire Server in our Client/Server topology. In our configuration, we have used sensible settings for timeouts, number of connections and so on. Also, the Pool has been configured to connect directly to a server. Learn more about various Pool configuration settings from the PoolFactory API .
5 Finally, we include a Spring BeanPostProcessor to block the client until our GemFire Server is up and running, listening for and accepting client connections.

The gemfireCacheServerReadyBeanPostProcessor is necessary in order to coordinate the client and server in an automated fashion during testing, but unnecessary in situations where the GemFire cluster is already presently running, such as in production.

The BeanPostProcessor uses a GemFire ClientMembershipListener that will be notified when the client has successfully connected to the server. Once a connection has been established, the listener releases the latch that the BeanPostProcessor will wait on (up to the specified timeout) in the postProcessAfterInitialization callback to block the client.

In typical GemFire deployments, where the cluster includes potentially hundreds of GemFire data nodes (servers), it is more common for clients to connect to one or more GemFire Locators running in the cluster. A Locator passes meta-data to clients about the servers available, load and which servers have the client’s data of interest, which is particularly important for single-hop, direct data access. See more details about the Client/Server Topology in GemFire’s User Guide .
For more information on configuring Spring Data GemFire, refer to the reference guide .

The @EnableGemFireHttpSession annotation enables a developer to configure certain aspects of both Spring Session and GemFire out-of-the-box using the following attributes:

  • maxInactiveIntervalInSeconds - controls HttpSession idle-timeout expiration (defaults to 30 minutes).

  • regionName - specifies the name of the GemFire Region used to store HttpSession state (defaults is "ClusteredSpringSessions").

  • clientRegionShort - specifies GemFire’s data management policy with a GemFire ClientRegionShortcut (default is PROXY). This attribute is only used when configuring client Region.

  • poolName - name of the dedicated GemFire Pool used to connect a client to the cluster of servers. The attribute is only used when the application is a GemFire cache client. Defaults to gemfirePool.

  • serverRegionShort - specifies GemFire’s data management policy using a GemFire RegionShortcut (default is PARTITION). This attribute is only used when configuring server Regions, or when a p2p topology is employed.

It is important to note that the GemFire client Region name must match a server Region by the same name if the client Region is a PROXY or CACHING_PROXY. Names are not required to match if the client Region used to store Spring Sessions is LOCAL, however, keep in mind that your session state will not be propagated to the server and you lose all benefits of using GemFire to store and manage distributed, replicated session state information in a cluster.
serverRegionShort is ignored in a client/server cache configuration and only applies when a peer-to-peer (P2P) topology, and more specifically, a GemFire peer cache is used.
Server Configuration

We have only covered one side of the equation. We also need a GemFire Server for our client to talk to and send session state to the server to manage.

In this sample, we will use the following GemFire Server Java Configuration:

@EnableGemFireHttpSession(maxInactiveIntervalInSeconds = 30) (1)
public class ServerConfig {

        static final int SERVER_PORT = 12480;

        static final String DEFAULT_GEMFIRE_LOG_LEVEL = "warning";
        static final String SERVER_HOST = "localhost";

        @SuppressWarnings("resource")
        public static void main(String[] args) throws IOException { (5)
                new AnnotationConfigApplicationContext(ServerConfig.class)
                        .registerShutdownHook();
        }

        @Bean
        static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
                return new PropertySourcesPlaceholderConfigurer();
        }

        Properties gemfireProperties() { (2)
                Properties gemfireProperties = new Properties();

                gemfireProperties.setProperty("name", applicationName());
                gemfireProperties.setProperty("mcast-port", "0");
                gemfireProperties.setProperty("log-level", logLevel());
                gemfireProperties.setProperty("jmx-manager", "true");
                gemfireProperties.setProperty("jmx-manager-start", "true");

                return gemfireProperties;
        }

        String applicationName() {
                return "samples:httpsession-gemfire-clientserver:"
                        .concat(getClass().getSimpleName());
        }

        String logLevel() {
                return System.getProperty("sample.httpsession.gemfire.log-level",
                        DEFAULT_GEMFIRE_LOG_LEVEL);
        }

        @Bean
        CacheFactoryBean gemfireCache() { (3)
                CacheFactoryBean gemfireCache = new CacheFactoryBean();

                gemfireCache.setClose(true);
                gemfireCache.setProperties(gemfireProperties());

                return gemfireCache;
        }

        @Bean
        CacheServerFactoryBean gemfireCacheServer(Cache gemfireCache,
                        @Value("${spring.session.data.gemfire.port:" + SERVER_PORT + "}") int port) { (4)

                CacheServerFactoryBean gemfireCacheServer = new CacheServerFactoryBean();

                gemfireCacheServer.setAutoStartup(true);
                gemfireCacheServer.setBindAddress(SERVER_HOST);
                gemfireCacheServer.setCache(gemfireCache);
                gemfireCacheServer.setHostNameForClients(SERVER_HOST);
                gemfireCacheServer.setMaxTimeBetweenPings(Long.valueOf(TimeUnit.SECONDS.toMillis(60)).intValue());
                gemfireCacheServer.setPort(port);

                return gemfireCacheServer;
        }
}
1 On the server, we also configure Spring Session using the @EnableGemFireHttpSession annotation. This ensures the Region names on both the client and server match (in this sample, we use the default "ClusteredSpringSessions"). We have also set the session timeout to 30 seconds. Later, we will see how this timeout is used.
2 Next, we configure the GemFire Server using GemFire System Properties very much like our P2P samples. With the mcast-port set to 0 and no locators property specified, our server will be standalone. We also allow a JMX client (e.g. Gfsh) to connect to our server with the use of the GemFire-specific JMX System properties.
3 Then, we create an instance of a GemFire peer Cache initialized with our GemFire System Properties.
4 We also setup a GemFire CacheServer instance running on localhost, listening to port 12480, ready to accept our client connection.
5 Finally, we declare a main method as an entry point for launching and running our GemFire Server from the command-line.
Java Servlet Container Initialization

Our Spring Java Configuration created a Spring bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation backed by Spring Session and GemFire.

In order for our Filter to do its magic, Spring needs to load our ClientConfig class. We also need to ensure our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer to make both of these steps extremely easy.

You can find an example below:

src/main/java/sample/Initializer.java
public class Initializer extends AbstractHttpSessionApplicationInitializer { (1)

        public Initializer() {
                super(ClientConfig.class); (2)
        }
}
The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.
1 The first step is to extend AbstractHttpSessionApplicationInitializer. This ensures that a Spring bean named springSessionRepositoryFilter is registered with our Servlet Container and used for every request.
2 AbstractHttpSessionApplicationInitializer also provides a mechanism to easily allow Spring to load our ClientConfig.
GemFire Client-Server XML-based Configuration

This section describes how to use GemFire’s Client-Server topology to back an HttpSession with XML-based configuration.

The HttpSession with GemFire (Client-Server) using XML Sample provides a working sample on how to integrate Spring Session and GemFire to replace the HttpSession using XML configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession with GemFire (Client-Server) using XML Guide when integrating with your own application.
Spring XML Configuration

After adding the required dependencies and repository declarations, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession with an implementation backed by Spring Session and GemFire.

Add the following Spring Configuration:

        (1)
        <context:annotation-config/>

        (2)
        <context:property-placeholder location="classpath:META-INF/spring/application.properties"/>

        (3)
        <bean class="sample.GemFireCacheServerReadyBeanPostProcessor"/>

        (4)
        <util:properties id="gemfireProperties">
                <prop key="log-level">${sample.httpsession.gemfire.log-level:warning}</prop>
        </util:properties>

        (5)
        <gfe:client-cache properties-ref="gemfireProperties" pool-name="gemfirePool"/>

        (6)
        <gfe:pool keep-alive="false"
              ping-interval="5000"
              read-timeout="5000"
              retry-attempts="1"
              subscription-enabled="true"
              thread-local-connections="false">
                <gfe:server host="${application.gemfire.client-server.host}"
                    port="${spring.session.data.gemfire.port:${application.gemfire.client-server.port}}"/>
        </gfe:pool>

        (7)
        <bean class="org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration"
                  p:maxInactiveIntervalInSeconds="30" p:poolName="DEFAULT"/>
1 Spring annotation configuration support is enabled with <context:annotation-config/> element so that any Spring beans declared in the XML config that are annotated with either Spring or Standard Java annotations supported by Spring will be configured appropriately.
2 The META-INF/spring/application.properties file are used along with the PropertySourcesPlaceholderConfigurer bean to replace placeholders in the Spring XML configuration meta-data with the approrpriate property values.
3 Then the `GemFireCacheSeverReadyBeanPostProcessor`is registered to determine whether a GemFire Server at the designated host/port is running and listening for client connections, blocking client startup until the server is available and ready.
4 Next, we include a Properties bean to configure certain aspects of the GemFire client cache using GemFire’s System Properties . In this case, we are just setting GemFire’s log-level from a application-specific System property, defaulting to warning if unspecified.
5 Then we create a instance of a GemFire ClientCache initialized with our gemfireProperties.
6 We configure a Pool of client connections to talk to the GemFire Server in our Client/Server topology. In our configuration, we use sensible settings for timeouts, number of connections and so on. Also, our Pool has been configured to connect directly to a server.
7 Finally, the GemFireHttpSessionConfiguration is registered to enable Spring Session functionality.
In typical GemFire deployments, where the cluster includes potentially hundreds of GemFire data nodes (servers), it is more common for clients to connect to one or more GemFire Locators running in the cluster. A Locator passes meta-data to clients about the servers available, load and which servers have the client’s data of interest, which is particularly important for single-hop, direct data access. See more details about the Client/Server Topology in GemFire’s User Guide .
For more information on configuring Spring Data GemFire, refer to the reference guide .
Server Configuration

We have only covered one side of the equation. We also need a GemFire Server for our client to talk to and send session state information to the server to manage.

In this sample, we will use the following GemFire Server Java Configuration:

        (1)
        <context:annotation-config/>

        (2)
        <context:property-placeholder location="classpath:META-INF/spring/application.properties"/>

        (3)
        <util:properties id="gemfireProperties">
                <prop key="name">GemFireClientServerHttpSessionXmlSample</prop>
                <prop key="mcast-port">0</prop>
                <prop key="log-level">${sample.httpsession.gemfire.log-level:warning}</prop>
                <prop key="jmx-manager">true</prop>
                <prop key="jmx-manager-start">true</prop>
        </util:properties>

        (4)
        <gfe:cache properties-ref="gemfireProperties"/>

        (5)
        <gfe:cache-server auto-startup="true"
                      bind-address="${application.gemfire.client-server.host}"
                      host-name-for-clients="${application.gemfire.client-server.host}"
                      port="${spring.session.data.gemfire.port:${application.gemfire.client-server.port}}"/>

        (6)
        <bean class="org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration"
                  p:maxInactiveIntervalInSeconds="30"/>
1 First, we enable Spring annotation config support with the <context:annotation-config> element so that any Spring beans declared in the XML config that are annotated with either Spring or Standard Java annotations supported by Spring will be configured appropriately.
2 A PropertySourcesPlaceholderConfigurer is registered to replace placeholders in our Spring XML configuration meta-data with property values in the META-INF/spring/application.properties file.
3 Next, we configure the GemFire Server using GemFire System Properties very much like our P2P samples. With the mcast-port set to 0 and no locators property specified, our server will be standalone. We also allow a JMX client (e.g. Gfsh) to connect to our server with the use of the GemFire-specific JMX System properties.
4 Then we create an instance of a GemFire peer Cache initialized with our GemFire System Properties.
5 We also setup a GemFire CacheServer instance running on localhost, listening to port 11235, ready to accept our client connection.
6 Finally, we enable the same Spring Session functionality we used on the client by registering an instance of GemFireHttpSessionConfiguration, except that we set the session expiration timeout to 30 seconds. We will explain later what this means.

The GemFire Server configuration gets bootstrapped with the following:

@Configuration (1)
@ImportResource("META-INF/spring/session-server.xml") (2)
public class Application {

        public static void main(final String[] args) {
                new AnnotationConfigApplicationContext(Application.class)
                        .registerShutdownHook();
        }
}
Instead of a simple Java class with a main method, you could also use Spring Boot.
1 The @Configuration annotation designates this Java class as a source for Spring configuration meta-data using Spring’s annotation configuration support.
2 Primarily, the configuration comes from the META-INF/spring/session-server.xml file, which is also the reason why Spring Boot was not used in this sample, since using XML seemingly defeats the purpose and benefits of using Spring Boot. However, this sample is about demonstrating how to use Spring XML to configure the GemFire client and server.
XML Servlet Container Initialization

Our Spring XML Configuration created a Spring bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session and GemFire.

In order for our Filter to do its magic, we need to instruct Spring to load our session-client.xml configuration file. We do this with the following configuration:

src/main/webapp/WEB-INF/web.xml
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/spring/session-client.xml</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

The ContextLoaderListener reads the contextConfigLocation context parameter value and picks up our session-client.xml configuration file.

Finally, we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request.

The following snippet performs this last step for us:

src/main/webapp/WEB-INF/web.xml
<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

The DelegatingFilterProxy will look up a bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every request that DelegatingFilterProxy is invoked, the springSessionRepositoryFilter will be invoked.

GemFire Peer-To-Peer (P2P)

Perhaps less common would be to configure the Spring Session application as a peer member in the GemFire cluster using the Peer-To-Peer (P2P) topology. In this configuration, a Spring Session application would be an actual data node (server) in the GemFire cluster, and not a cache client as before.

One advantage to this approach is the proximity of the application to the application’s state (i.e. it’s data). However, there are other effective means of accomplishing similar data dependent computations, such as using GemFire’s Function Execution . Any of GemFire’s other features can be used when GemFire is serving as a provider in Spring Session.

P2P is very useful for both testing purposes as well as smaller, more focused and self-contained applications, such as those found in a microservices architecture, and will most certainly improve on your application’s latency, throughput and consistency needs.

You can configure a Peer-To-Peer (P2P) topology with either:

GemFire Peer-To-Peer (P2P) Java-based Configuration

This section describes how to use GemFire’s Peer-To-Peer (P2P) topology to back an HttpSession using Java-based configuration.

The HttpSession with GemFire (P2P) Sample provides a working sample on how to integrate Spring Session and GemFire to replace the HttpSession using Java configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession with GemFire (P2P) Guide when integrating with your own application.
Spring Java Configuration

After adding the required dependencies and repository declarations, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession with an implementation backed by Spring Session and GemFire.

Add the following Spring Configuration:

@EnableGemFireHttpSession (1)
public class Config {

        @Bean
        Properties gemfireProperties() { (2)
                Properties gemfireProperties = new Properties();

                gemfireProperties.setProperty("name", "GemFireP2PHttpSessionSample");
                gemfireProperties.setProperty("mcast-port", "0");
                gemfireProperties.setProperty("log-level",
                                System.getProperty("sample.httpsession.gemfire.log-level", "warning"));
                gemfireProperties.setProperty("jmx-manager", "true");
                gemfireProperties.setProperty("jmx-manager-start", "true");

                return gemfireProperties;
        }

        @Bean
        CacheFactoryBean gemfireCache() { (3)
                CacheFactoryBean gemfireCache = new CacheFactoryBean();

                gemfireCache.setClose(true);
                gemfireCache.setProperties(gemfireProperties());

                return gemfireCache;
        }
}
1 The @EnableGemFireHttpSession annotation creates a Spring bean named springSessionRepositoryFilter that implements Filter. The filter is what replaces the HttpSession with an implementation backed by Spring Session. In this instance, Spring Session is backed by GemFire.
2 Then, we configure a GemFire peer cache using standard GemFire System properties. We give the GemFire data node a name using the name property and set mcast-port to 0. With the absence of a locators property, this data node will be a standalone server. GemFire’s log-level is set using an application-specific System property (sample.httpsession.gemfire.log-level) that a user can specify on the command-line when running this sample application using either Maven or Gradle (default is "warning").
3 Finally, we create an instance of the GemFire peer cache that embeds GemFire in the same JVM process as the running Spring Session sample application.
Additionally, we have configured this data node (server) as a GemFire Manager as well using GemFire-specific JMX System properties that enable JMX client (e.g. Gfsh) to connect to this running data node.
For more information on configuring Spring Data GemFire, refer to the reference guide .

The @EnableGemFireHttpSession annotation enables a developer to configure certain aspects of Spring Session and GemFire out-of-the-box using the following attributes:

  • maxInactiveIntervalInSeconds - controls HttpSession idle-timeout expiration (defaults to 30 minutes).

  • regionName - specifies the name of the GemFire Region used to store HttpSession state (defaults is "ClusteredSpringSessions").

  • serverRegionShort - specifies GemFire data management policies with a GemFire RegionShortcut (default is PARTITION).

clientRegionShort is ignored in a peer cache configuration and only applies when a client-server topology, and more specifically, a GemFire client cache is used.
Java Servlet Container Initialization

Our Spring Java Configuration created a Spring bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation backed by Spring Session and GemFire.

In order for our Filter to do its magic, Spring needs to load our Config class. We also need to ensure our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer to make both of these steps extremely easy.

You can find an example below:

src/main/java/sample/Initializer.java
public class Initializer extends AbstractHttpSessionApplicationInitializer { (1)

        public Initializer() {
                super(Config.class); (2)
        }
}
The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.
1 The first step is to extend AbstractHttpSessionApplicationInitializer. This ensures that a Spring bean named springSessionRepositoryFilter is registered with our Servlet Container and used for every request.
2 AbstractHttpSessionApplicationInitializer also provides a mechanism to easily allow Spring to load our Config.
GemFire Peer-To-Peer (P2P) XML-based Configuration

This section describes how to use GemFire’s Peer-To-Peer (P2P) topology to back an HttpSession using XML-based configuration.

The HttpSession with GemFire (P2P) using XML Sample provides a working sample on how to integrate Spring Session and GemFire to replace the HttpSession using XML configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession with GemFire (P2P) using XML Guide when integrating with your own application.
Spring XML Configuration

After adding the required dependencies and repository declarations, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession with an implementation backed by Spring Session and GemFire.

Add the following Spring Configuration:

src/main/webapp/WEB-INF/spring/session.xml
(1)
<context:annotation-config/>
<context:property-placeholder/>

<bean class="org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration"/>

(2)
<util:properties id="gemfireProperties">
    <prop key="name">GemFireP2PHttpSessionXmlSample</prop>
    <prop key="mcast-port">0</prop>
    <prop key="log-level">${sample.httpsession.gemfire.log-level:warning}</prop>
    <prop key="jmx-manager">true</prop>
    <prop key="jmx-manager-start">true</prop>
</util:properties>

(3)
<gfe:cache properties-ref="gemfireProperties" use-bean-factory-locator="false"/>
1 We use the combination of <context:annotation-config/> and GemFireHttpSessionConfiguration because Spring Session does not yet provide XML Namespace support (see gh-104 ). This creates a Spring bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what replaces the HttpSession with an implementation backed by Spring Session. In this instance, Spring Session is backed by GemFire.
2 Then, we configure a GemFire peer cache using standard GemFire System properties. We give the GemFire data node a name using the name property and set mcast-port to 0. With the absence of a locators property, this data node will be a standalone server. GemFire’s log-level is set using an application-specific System property (sample.httpsession.gemfire.log-level) that a user can specify on the command-line when running this application using either Maven or Gradle (default is "warning").
3 Finally, we create an instance of the GemFire peer cache that embeds GemFire in the same JVM process as the running Spring Session sample application.
Additionally, we have configured this data node (server) as a GemFire Manager as well using GemFire-specific JMX System properties that enable JMX client (e.g. Gfsh) to connect to this running data node.
For more information on configuring Spring Data GemFire, refer to the reference guide .
XML Servlet Container Initialization

Our Spring XML Configuration created a Spring bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session and GemFire.

In order for our Filter to do its magic, we need to instruct Spring to load our session.xml configuration file. We do this with the following configuration:

src/main/webapp/WEB-INF/web.xml
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/*.xml
    </param-value>
</context-param>
<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

The ContextLoaderListener reads the contextConfigLocation context parameter value and picks up our session.xml configuration file.

Finally, we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request.

The following snippet performs this last step for us:

src/main/webapp/WEB-INF/web.xml
<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

The DelegatingFilterProxy will look up a bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every request that DelegatingFilterProxy is invoked, the springSessionRepositoryFilter will be invoked.

HttpSession with JDBC

Using Spring Session with HttpSession is enabled by adding a Servlet Filter before anything that uses the HttpSession. You can choose from enabling this using either:

JDBC Java Based Configuration

This section describes how to use a relational database to back HttpSession using Java based configuration.

The HttpSession JDBC Sample provides a working sample on how to integrate Spring Session and HttpSession using Java configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession JDBC Guide when integrating with your own application.
Spring Java Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

@EnableJdbcHttpSession (1)
public class Config {

        @Bean
        public EmbeddedDatabase dataSource() {
                return new EmbeddedDatabaseBuilder() (2)
                                .setType(EmbeddedDatabaseType.H2)
                                .addScript("org/springframework/session/jdbc/schema-h2.sql").build();
        }

        @Bean
        public PlatformTransactionManager transactionManager(DataSource dataSource) {
                return new DataSourceTransactionManager(dataSource); (3)
        }

}
1 The @EnableJdbcHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by a relational database.
2 We create a dataSource that connects Spring Session to an embedded instance of H2 database. We configure the H2 database to create database tables using the SQL script which is included in Spring Session.
3 We create a transactionManager that manages transactions for previously configured dataSource.

For additional information on how to configure data access related concerns, please refer to the Spring Framework Reference Documentation .

Java Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, Spring needs to load our Config class. Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer both of these steps extremely easy. You can find an example below:

src/main/java/sample/Initializer.java
public class Initializer extends AbstractHttpSessionApplicationInitializer { (1)

        public Initializer() {
                super(Config.class); (2)
        }
}
The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.
1 The first step is to extend AbstractHttpSessionApplicationInitializer. This ensures that the Spring Bean by the name springSessionRepositoryFilter is registered with our Servlet Container for every request.
2 AbstractHttpSessionApplicationInitializer also provides a mechanism to easily ensure Spring loads our Config.

JDBC XML Based Configuration

This section describes how to use a relational database to back HttpSession using XML based configuration.

The HttpSession JDBC XML Sample provides a working sample on how to integrate Spring Session and HttpSession using XML configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession JDBC XML Guide when integrating with your own application.
Spring XML Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

src/main/webapp/WEB-INF/spring/session.xml
(1)
<context:annotation-config/>
<bean class="org.springframework.session.jdbc.config.annotation.web.http.JdbcHttpSessionConfiguration"/>

(2)
<jdbc:embedded-database id="dataSource" database-name="testdb" type="H2">
    <jdbc:script location="classpath:org/springframework/session/jdbc/schema-h2.sql"/>
</jdbc:embedded-database>

(3)
<bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <constructor-arg ref="dataSource"/>
</bean>
1 We use the combination of <context:annotation-config/> and JdbcHttpSessionConfiguration because Spring Session does not yet provide XML Namespace support (see gh-104 ). This creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by a relational database.
2 We create a dataSource that connects Spring Session to an embedded instance of H2 database. We configure the H2 database to create database tables using the SQL script which is included in Spring Session.
3 We create a transactionManager that manages transactions for previously configured dataSource.

For additional information on how to configure data access related concerns, please refer to the Spring Framework Reference Documentation .

XML Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, we need to instruct Spring to load our session.xml configuration. We do this with the following configuration:

src/main/webapp/WEB-INF/web.xml
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/*.xml
    </param-value>
</context-param>
<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

The ContextLoaderListener reads the contextConfigLocation and picks up our session.xml configuration.

Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. The following snippet performs this last step for us:

src/main/webapp/WEB-INF/web.xml
<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

The DelegatingFilterProxy will look up a Bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every request that DelegatingFilterProxy is invoked, the springSessionRepositoryFilter will be invoked.

JDBC Spring Boot Based Configuration

This section describes how to use a relational database to back HttpSession when using Spring Boot.

The HttpSession JDBC Spring Boot Sample provides a working sample on how to integrate Spring Session and HttpSession using Spring Boot. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession JDBC Spring Boot Guide when integrating with your own application.
Spring Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

@EnableJdbcHttpSession (1)
public class HttpSessionConfig {
}
1 The @EnableJdbcHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by a relational database.
Configuring the DataSource

Spring Boot automatically creates a DataSource that connects Spring Session to an embedded instance of H2 database. In a production environment you need to ensure to update your configuration to point to your relational database. For example, you can include the following in your application.properties

src/main/resources/application.properties
spring.datasource.url=jdbc:postgresql://localhost:5432/myapp
spring.datasource.username=myapp
spring.datasource.password=secret

For more information, refer to Configure a DataSource portion of the Spring Boot documentation.

Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, Spring needs to load our Config class. Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Boot takes care of both of these steps for us.

HttpSession with Mongo

Using Spring Session with HttpSession is enabled by adding a Servlet Filter before anything that uses the HttpSession.

This section describes how to use Mongo to back HttpSession using Java based configuration.

The HttpSession Mongo Sample provides a working sample on how to integrate Spring Session and HttpSession using Java configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed HttpSession Guide when integrating with your own application.

All you have to do is to add the following Spring Configuration:

@EnableMongoHttpSession (1)
public class HttpSessionConfig {

        @Bean
        public JdkMongoSessionConverter jdkMongoSessionConverter() {
                return new JdkMongoSessionConverter(); (2)
        }
}
1 The @EnableMongoHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by Mongo.
2 We explicitly configure JdkMongoSessionConverter since Spring Security’s objects cannot be automatically persisted using Jackson (the default if Jackson is on the classpath).

Session serialization mechanisms

To be able to persist session objects in MongoDB we need to provide the serialization/deserialization mechanism. Depending on your classpath Spring Session will choose one of two build-in converters:

  • JacksonMongoSessionConverter when ObjectMapper class is available, or

  • JdkMongoSessionConverter otherwise.

JacksonMongoSessionConverter

This mechanism uses Jackson to serialize session objects to/from JSON. JacksonMongoSessionConverter will be the default when Jackson is detected on the classpath and the user has not explicitly registered a AbstractMongoSessionConverter Bean.

If you would like to provide custom Jackson modules you can do it by explicitly registering JacksonMongoSessionConverter:

@Configuration
@EnableMongoHttpSession
public class MongoJacksonSessionConfiguration {

        @Bean
        public AbstractMongoSessionConverter mongoSessionConverter() {
                return new JacksonMongoSessionConverter(getJacksonModules());
        }

        public Iterable<Module> getJacksonModules() {
                return Collections.<Module>singletonList(new MyJacksonModule());
        }
}

JdkMongoSessionConverter

JdkMongoSessionConverter uses standard Java serialization to persist session attributes map to MongoDB in a binary form. However, standard session elements like id, access time, etc are still written as a plain Mongo objects and can be read and queried without additional effort. JdkMongoSessionConverter is used if Jackson is not on the classpath and no explicit AbstractMongoSessionConverter Bean has been defined. You can explicitly register JdkMongoSessionConverter by defining it as a Bean.

@Configuration
@EnableMongoHttpSession
public class MongoJdkSessionConfiguration {

        @Bean
        public AbstractMongoSessionConverter mongoSessionConverter() {
                return new JdkMongoSessionConverter();
        }
}

There is also a constructor taking Serializer and Deserializer objects, allowing you to pass custom implementations, which is especially important when you want to use non-default classloader.

Using custom converters

You can create your own session converter by extending AbstractMongoSessionConverter class. The implementation will be used for serializing, deserializing your objects and for providing queries to access the session.

HttpSession with Hazelcast

Using Spring Session with HttpSession is enabled by adding a Servlet Filter before anything that uses the HttpSession.

This section describes how to use Hazelcast to back HttpSession using Java based configuration.

The Hazelcast Spring Sample provides a working sample on how to integrate Spring Session and HttpSession using Java configuration. You can read the basic steps for integration below, but you are encouraged to follow along with the detailed Hazelcast Spring Guide when integrating with your own application.

Spring Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

@EnableHazelcastHttpSession (1)
@Configuration
public class HazelcastHttpSessionConfig {

        @Bean
        public HazelcastInstance hazelcastInstance() {
                MapAttributeConfig attributeConfig = new MapAttributeConfig()
                                .setName(HazelcastSessionRepository.PRINCIPAL_NAME_ATTRIBUTE)
                                .setExtractor(PrincipalNameExtractor.class.getName());

                Config config = new Config();

                config.getMapConfig("spring:session:sessions") (2)
                                .addMapAttributeConfig(attributeConfig)
                                .addMapIndexConfig(new MapIndexConfig(
                                                HazelcastSessionRepository.PRINCIPAL_NAME_ATTRIBUTE, false));

                return Hazelcast.newHazelcastInstance(config); (3)
        }

}
1 The @EnableHazelcastHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by Hazelcast.
2 In order to support retrieval of sessions by principal name index, appropriate ValueExtractor needs to be registered. Spring Session provides PrincipalNameExtractor for this purpose.
3 We create a HazelcastInstance that connects Spring Session to Hazelcast. By default, an embedded instance of Hazelcast is started and connected to by the application. For more information on configuring Hazelcast, refer to the reference documentation .

Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, Spring needs to load our SessionConfig class. Since our application is already loading Spring configuration using our SecurityInitializer class, we can simply add our SessionConfig class to it.

src/main/java/sample/SecurityInitializer.java
public class SecurityInitializer extends AbstractSecurityWebApplicationInitializer {

        public SecurityInitializer() {
                super(SecurityConfig.class, SessionConfig.class);
        }
}

Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. It is extremely important that Spring Session’s springSessionRepositoryFilter is invoked before Spring Security’s springSecurityFilterChain. This ensures that the HttpSession that Spring Security uses is backed by Spring Session. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer that makes this extremely easy. You can find an example below:

src/main/java/sample/Initializer.java
public class Initializer extends AbstractHttpSessionApplicationInitializer {

}
The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.

By extending AbstractHttpSessionApplicationInitializer we ensure that the Spring Bean by the name springSessionRepositoryFilter is registered with our Servlet Container for every request before Spring Security’s springSecurityFilterChain.

How HttpSession Integration Works

Fortunately both HttpSession and HttpServletRequest (the API for obtaining an HttpSession) are both interfaces. This means that we can provide our own implementations for each of these APIs.

This section describes how Spring Session provides transparent integration with HttpSession. The intent is so that user’s can understand what is happening under the covers. This functionality is already integrated and you do NOT need to implement this logic yourself.

First we create a custom HttpServletRequest that returns a custom implementation of HttpSession. It looks something like the following:

public class SessionRepositoryRequestWrapper extends HttpServletRequestWrapper {

        public SessionRepositoryRequestWrapper(HttpServletRequest original) {
                super(original);
        }

        public HttpSession getSession() {
                return getSession(true);
        }

        public HttpSession getSession(boolean createNew) {
                // create an HttpSession implementation from Spring Session
        }

        // ... other methods delegate to the original HttpServletRequest ...
}

Any method that returns an HttpSession is overridden. All other methods are implemented by HttpServletRequestWrapper and simply delegate to the original HttpServletRequest implementation.

We replace the HttpServletRequest implementation using a servlet Filter called SessionRepositoryFilter. The pseudocode can be found below:

public class SessionRepositoryFilter implements Filter {

        public doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
                HttpServletRequest httpRequest = (HttpServletRequest) request;
                SessionRepositoryRequestWrapper customRequest =
                        new SessionRepositoryRequestWrapper(httpRequest);

                chain.doFilter(customRequest, response, chain);
        }

        // ...
}

By passing in a custom HttpServletRequest implementation into the FilterChain we ensure that anything invoked after our Filter uses the custom HttpSession implementation. This highlights why it is important that Spring Session’s SessionRepositoryFilter must be placed before anything that interacts with the HttpSession.

Multiple HttpSessions in Single Browser

Spring Session has the ability to support multiple sessions in a single browser instance. This provides the ability to support authenticating with multiple users in the same browser instance (i.e. Google Accounts).

The Manage Multiple Users Guide provides a complete working example of managing multiple users in the same browser instance. You can follow the basic steps for integration below, but you are encouraged to follow along with the detailed Manage Multiple Users Guide when integrating with your own application.

Let’s take a look at how Spring Session keeps track of multiple sessions.

Managing a Single Session

Spring Session keeps track of the HttpSession by adding a value to a cookie named SESSION. For example, the SESSION cookie might have a value of:

7e8383a4-082c-4ffe-a4bc-c40fd3363c5e

Adding a Session

We can add another session by requesting a URL that contains a special parameter in it. By default the parameter name is _s. For example, the following URL would create a new session:

The parameter value does not indicate the actual session id. This is important because we never want to allow the session id to be determined by a client to avoid session fixation attacks . Additionally, we do not want the session id to be leaked since it is sent as a query parameter. Remember sensitive information should only be transmitted as a header or in the body of the request.

Rather than creating the URL ourselves, we can utilize the HttpSessionManager to do this for us. We can obtain the HttpSessionManager from the HttpServletRequest using the following:

src/main/java/sample/UserAccountsFilter.java
HttpSessionManager sessionManager = (HttpSessionManager) httpRequest
        .getAttribute(HttpSessionManager.class.getName());

We can now use it to create a URL to add another session.

src/main/java/sample/UserAccountsFilter.java
String addAlias = unauthenticatedAlias == null ? (1)
        sessionManager.getNewSessionAlias(httpRequest)
        : (2)
        unauthenticatedAlias; (3)
String addAccountUrl = sessionManager.encodeURL(contextPath, addAlias); (4)
1 We have an existing variable named unauthenticatedAlias. The value is an alias that points to an existing unauthenticated session. If no such session exists, the value is null. This ensures if we have an existing unauthenticated session that we use it instead of creating a new session.
2 If all of our sessions are already associated to a user, we create a new session alias.
3 If there is an existing session that is not associated to a user, we use its session alias.
4 Finally, we create the add account URL. The URL contains a session alias that either points to an existing unauthenticated session or is an alias that is unused thus signaling to create a new session associated to that alias.

Now our SESSION cookie looks something like this:

0 7e8383a4-082c-4ffe-a4bc-c40fd3363c5e 1 1d526d4a-c462-45a4-93d9-84a39b6d44ad

Such that:

  • There is a session with the id 7e8383a4-082c-4ffe-a4bc-c40fd3363c5e

    • The alias for this session is 0. For example, if the URL is http://localhost:8080/?_s=0 this alias would be used.

    • This is the default session. This means that if no session alias is specified, then this session is used. For example, if the URL is http://localhost:8080/ this session would be used.

  • There is a session with the id 1d526d4a-c462-45a4-93d9-84a39b6d44ad

    • The alias for this session is 1. If the session alias is 1, then this session is used. For example, if the URL is http://localhost:8080/?_s=1 this alias would be used.

Automatic Session Alias Inclusion with encodeURL

The nice thing about specifying the session alias in the URL is that we can have multiple tabs open with different active sessions. The bad thing is that we need to include the session alias in every URL of our application. Fortunately, Spring Session will automatically include the session alias in any URL that passes through HttpServletResponse#encodeURL(java.lang.String)

This means that if you are using standard tag libraries the session alias is automatically included in the URL. For example, if we are currently using the session with the alias of 1, then the following:

src/main/webapp/index.jsp
  -->
<c:url value="/link.jsp" var="linkUrl"/>
<a id="navLink" href="${linkUrl}">Link</a>

will output a link of:

<a id="navLink" href="/link.jsp?_s=1">Link</a>

HttpSession & RESTful APIs

Spring Session can work with RESTful APIs by allowing the session to be provided in a header.

The REST Sample provides a working sample on how to use Spring Session in a REST application to support authenticating with a header. You can follow the basic steps for integration below, but you are encouraged to follow along with the detailed REST Guide when integrating with your own application.

Spring Configuration

After adding the required dependencies, we can create our Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession implementation with an implementation backed by Spring Session. Add the following Spring Configuration:

@Configuration
@EnableRedisHttpSession (1)
public class HttpSessionConfig {

        @Bean
        public LettuceConnectionFactory connectionFactory() {
                return new LettuceConnectionFactory(); (2)
        }

        @Bean
        public HttpSessionStrategy httpSessionStrategy() {
                return new HeaderHttpSessionStrategy(); (3)
        }
}
1 The @EnableRedisHttpSession annotation creates a Spring Bean with the name of springSessionRepositoryFilter that implements Filter. The filter is what is in charge of replacing the HttpSession implementation to be backed by Spring Session. In this instance Spring Session is backed by Redis.
2 We create a RedisConnectionFactory that connects Spring Session to the Redis Server. We configure the connection to connect to localhost on the default port (6379) For more information on configuring Spring Data Redis, refer to the reference documentation .
3 We customize Spring Session’s HttpSession integration to use HTTP headers to convey the current session information instead of cookies.

Servlet Container Initialization

Our Spring Configuration created a Spring Bean named springSessionRepositoryFilter that implements Filter. The springSessionRepositoryFilter bean is responsible for replacing the HttpSession with a custom implementation that is backed by Spring Session.

In order for our Filter to do its magic, Spring needs to load our Config class. We provide the configuration in our Spring MvcInitializer as shown below:

src/main/java/sample/mvc/MvcInitializer.java
@Override
protected Class<?>[] getRootConfigClasses() {
    return new Class[] { SecurityConfig.class, HttpSessionConfig.class };
}

Last we need to ensure that our Servlet Container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request. Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer that makes this extremely easy. Simply extend the class with the default constructor as shown below:

src/main/java/sample/Initializer.java
public class Initializer extends AbstractHttpSessionApplicationInitializer {

}
The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.

HttpSessionListener

Spring Session supports HttpSessionListener by translating SessionDestroyedEvent and SessionCreatedEvent into HttpSessionEvent by declaring SessionEventHttpSessionListenerAdapter. To use this support, you need to:

  • Ensure your SessionRepository implementation supports and is configured to fire SessionDestroyedEvent and SessionCreatedEvent.

  • Configure SessionEventHttpSessionListenerAdapter as a Spring bean.

  • Inject every HttpSessionListener into the SessionEventHttpSessionListenerAdapter

If you are using the configuration support documented in HttpSession with Redis, then all you need to do is register every HttpSessionListener as a bean. For example, assume you want to support Spring Security’s concurrency control and need to use HttpSessionEventPublisher you can simply add HttpSessionEventPublisher as a bean. In Java configuration, this might look like:

@Configuration
@EnableRedisHttpSession
public class RedisHttpSessionConfig {

        @Bean
        public HttpSessionEventPublisher httpSessionEventPublisher() {
                return new HttpSessionEventPublisher();
        }

        // ...
}

In XML configuration, this might look like:

<bean class="org.springframework.security.web.session.HttpSessionEventPublisher"/>

WebSocket Integration

Spring Session provides transparent integration with Spring’s WebSocket support.

Spring Session’s WebSocket support only works with Spring’s WebSocket support. Specifically it does not work with using JSR-356 directly. This is due to the fact that JSR-356 does not have a mechanism for intercepting incoming WebSocket messages.

Why Spring Session & WebSockets?

So why do we need Spring Session when using WebSockets?

Consider an email application that does much of its work through HTTP requests. However, there is also a chat application embedded within it that works over WebSocket APIs. If a user is actively chatting with someone, we should not timeout the HttpSession since this would be pretty poor user experience. However, this is exactly what JSR-356 does.

Another issue is that according to JSR-356 if the HttpSession times out any WebSocket that was created with that HttpSession and an authenticated user should be forcibly closed. This means that if we are actively chatting in our application and are not using the HttpSession, then we will also disconnect from our conversation!

WebSocket Usage

The WebSocket Sample provides a working sample on how to integrate Spring Session with WebSockets. You can follow the basic steps for integration below, but you are encouraged to follow along with the detailed WebSocket Guide when integrating with your own application:

HttpSession Integration

Before using WebSocket integration, you should be sure that you have HttpSession Integration working first.

Spring Configuration

In a typical Spring WebSocket application users would extend AbstractWebSocketMessageBrokerConfigurer. For example, the configuration might look something like the following:

@Configuration
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {

        public void registerStompEndpoints(StompEndpointRegistry registry) {
                registry.addEndpoint("/messages").withSockJS();
        }

        @Override
        public void configureMessageBroker(MessageBrokerRegistry registry) {
                registry.enableSimpleBroker("/queue/", "/topic/");
                registry.setApplicationDestinationPrefixes("/app");
        }
}

We can easily update our configuration to use Spring Session’s WebSocket support. For example:

src/main/java/samples/config/WebSocketConfig.java
@Configuration
@EnableScheduling
@EnableWebSocketMessageBroker
public class WebSocketConfig
                extends AbstractSessionWebSocketMessageBrokerConfigurer<ExpiringSession> { (1)

        protected void configureStompEndpoints(StompEndpointRegistry registry) { (2)
                registry.addEndpoint("/messages").withSockJS();
        }

        public void configureMessageBroker(MessageBrokerRegistry registry) {
                registry.enableSimpleBroker("/queue/", "/topic/");
                registry.setApplicationDestinationPrefixes("/app");
        }
}

To hook in the Spring Session support we only need to change two things:

1 Instead of extending AbstractWebSocketMessageBrokerConfigurer we extend AbstractSessionWebSocketMessageBrokerConfigurer
2 We rename the registerStompEndpoints method to configureStompEndpoints

What does AbstractSessionWebSocketMessageBrokerConfigurer do behind the scenes?

  • WebSocketConnectHandlerDecoratorFactory is added as a WebSocketHandlerDecoratorFactory to WebSocketTransportRegistration. This ensures a custom SessionConnectEvent is fired that contains the WebSocketSession. The WebSocketSession is necessary to terminate any WebSocket connections that are still open when a Spring Session is terminated.

  • SessionRepositoryMessageInterceptor is added as a HandshakeInterceptor to every StompWebSocketEndpointRegistration. This ensures that the Session is added to the WebSocket properties to enable updating the last accessed time.

  • SessionRepositoryMessageInterceptor is added as a ChannelInterceptor to our inbound ChannelRegistration. This ensures that every time an inbound message is received, that the last accessed time of our Spring Session is updated.

  • WebSocketRegistryListener is created as a Spring Bean. This ensures that we have a mapping of all of the Session id to the corresponding WebSocket connections. By maintaining this mapping, we can close all the WebSocket connections when a Spring Session (HttpSession) is terminated.

Spring Security Integration

Spring Session provides integration with Spring Security.

Spring Security Remember-Me Support

Spring Session provides integration with Spring Security’s Remember-Me Authentication . The support will:

  • Change the session expiration length

  • Ensure the session cookie expires at Integer.MAX_VALUE. The cookie expiration is set to the largest possible value because the cookie is only set when the session is created. If it were set to the same value as the session expiration, then the session would get renewed when the user used it but the cookie expiration would not be updated causing the expiration to be fixed.

To configure Spring Session with Spring Security in Java Configuration use the following as a guide:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        // ... additional configuration ...
        .rememberMe()
            .rememberMeServices(rememberMeServices());
}

@Bean
public SpringSessionRememberMeServices rememberMeServices() {
    SpringSessionRememberMeServices rememberMeServices =
            new SpringSessionRememberMeServices();
    // optionally customize
    rememberMeServices.setAlwaysRemember(true);
    return rememberMeServices;
}

An XML based configuration would look something like this:

<security:http>
    <!-- ... -->
    <security:form-login />
    <security:remember-me services-ref="rememberMeServices"/>
</security:http>

<bean id="rememberMeServices"
    class="org.springframework.session.security.web.authentication.SpringSessionRememberMeServices"
    p:alwaysRemember="true"/>

Spring Security Concurrent Session Control

Spring Session provides integration with Spring Security to support its concurrent session control. This allows limiting the number of active sessions that a single user can have concurrently, but unlike the default Spring Security support this will also work in a clustered environment. This is done by providing a custom implementation of Spring Security’s SessionRegistry interface.

When using Spring Security’s Java config DSL, you can configure the custom SessionRegistry through the SessionManagementConfigurer like this:

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

        @Autowired
        FindByIndexNameSessionRepository<ExpiringSession> sessionRepository;

        @Override
        protected void configure(HttpSecurity http) throws Exception {
                http
                        // other config goes here...
                        .sessionManagement()
                                .maximumSessions(2)
                                .sessionRegistry(sessionRegistry());
        }

        @Bean
        SpringSessionBackedSessionRegistry sessionRegistry() {
                return new SpringSessionBackedSessionRegistry(this.sessionRepository);
        }
}

This assumes that you’ve also configured Spring Session to provide a FindByIndexNameSessionRepository that returns ExpiringSession instances.

When using XML configuration, it would look something like this:

<security:http>
    <!-- other config goes here... -->
    <security:session-management>
        <security:concurrency-control max-sessions="2" session-registry-ref="sessionRegistry"/>
    </security:session-management>
</security:http>

<bean id="sessionRegistry"
      class="org.springframework.session.security.SpringSessionBackedSessionRegistry">
    <constructor-arg ref="sessionRepository"/>
</bean>

This assumes that your Spring Session SessionRegistry bean is called sessionRegistry, which is the name used by all SpringHttpSessionConfiguration subclasses except for the one for MongoDB: there it’s called mongoSessionRepository.

Limitations

Spring Session’s implementation of Spring Security’s SessionRegistry interface does not support the getAllPrincipals method, as this information cannot be retrieved using Spring Session. This method is never called by Spring Security, so this only affects applications that access the SessionRegistry themselves.

API Documentation

You can browse the complete Javadoc online. The key APIs are described below:

Session

A Session is a simplified Map of name value pairs.

Typical usage might look like the following:

public class RepositoryDemo<S extends Session> {
    private SessionRepository<S> repository; (1)

    public void demo() {
        S toSave = this.repository.createSession(); (2)

        (3)
        User rwinch = new User("rwinch");
        toSave.setAttribute(ATTR_USER, rwinch);

        this.repository.save(toSave); (4)

        S session = this.repository.getSession(toSave.getId()); (5)

        (6)
        User user = session.getAttribute(ATTR_USER);
        assertThat(user).isEqualTo(rwinch);
    }

    // ... setter methods ...
}
1 We create a SessionRepository instance with a generic type, S, that extends Session. The generic type is defined in our class.
2 We create a new Session using our SessionRepository and assign it to a variable of type S.
3 We interact with the Session. In our example, we demonstrate saving a User to the Session.
4 We now save the Session. This is why we needed the generic type S. The SessionRepository only allows saving Session instances that were created or retrieved using the same SessionRepository. This allows for the SessionRepository to make implementation specific optimizations (i.e. only writing attributes that have changed).
5 We retrieve the Session from the SessionRepository.
6 We obtain the persisted User from our Session without the need for explicitly casting our attribute.

ExpiringSession

An ExpiringSession extends a Session by providing attributes related to the Session instance’s expiration. If there is no need to interact with the expiration information, prefer using the more simple Session API.

Typical usage might look like the following:

public class ExpiringRepositoryDemo<S extends ExpiringSession> {
    private SessionRepository<S> repository; (1)

    public void demo() {
        S toSave = this.repository.createSession(); (2)
        // ...
        toSave.setMaxInactiveIntervalInSeconds(30); (3)

        this.repository.save(toSave); (4)

        S session = this.repository.getSession(toSave.getId()); (5)
        // ...
    }

    // ... setter methods ...
}
1 We create a SessionRepository instance with a generic type, S, that extends ExpiringSession. The generic type is defined in our class.
2 We create a new ExpiringSession using our SessionRepository and assign it to a variable of type S.
3 We interact with the ExpiringSession. In our example, we demonstrate updating the amount of time the ExpiringSession can be inactive before it expires.
4 We now save the ExpiringSession. This is why we needed the generic type S. The SessionRepository only allows saving ExpiringSession instances that were created or retrieved using the same SessionRepository. This allows for the SessionRepository to make implementation specific optimizations (i.e. only writing attributes that have changed). The last accessed time is automatically updated when the ExpiringSession is saved.