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:

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:

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:

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:

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:

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.

This section describes how to use GemFire’s Client-Server topology to back an HttpSession with Java-based 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:

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.

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.

Server 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;
        }
}

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:

This section describes how to use GemFire’s Client-Server topology to back an HttpSession with XML-based 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:

Server 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"/>

@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();
        }
}

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:

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:

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.

This section describes how to use GemFire’s Peer-To-Peer (P2P) topology to back an HttpSession using Java-based 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:

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).

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:

This section describes how to use GemFire’s Peer-To-Peer (P2P) topology to back an HttpSession using XML-based 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:

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:

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:

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.

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:

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

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:

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:

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

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:

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:

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.

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:

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

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

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.

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 MongoJdkSessionConfiguration {

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

@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)
        }

}

public class SecurityInitializer extends AbstractSecurityWebApplicationInitializer {

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

public class Initializer extends AbstractHttpSessionApplicationInitializer {

}

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

HttpSessionManager sessionManager = (HttpSessionManager) httpRequest
        .getAttribute(HttpSessionManager.class.getName());

String addAlias = unauthenticatedAlias == null ? (1)
        sessionManager.getNewSessionAlias(httpRequest)
        : (2)
        unauthenticatedAlias; (3)
String addAccountUrl = sessionManager.encodeURL(contextPath, addAlias); (4)

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

  -->
<c:url value="/link.jsp" var="linkUrl"/>
<a id="navLink" href="