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.
We have already mentioned that Spring Session provides transparent integration with HttpSession, but what benefits do we get out of this?
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:
This section describes how to use Redis to back HttpSession using Java based configuration.
![]() | Note |
|---|---|
|
The HttpSession Sample provides a working sample on how to integrate Spring Session and |
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:
@EnableRedisHttpSessionpublic class Config { @Bean public LettuceConnectionFactory connectionFactory() { return new LettuceConnectionFactory();
} }
|
The | |
|
We create a |
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 {public Initializer() { super(Config.class);
} }
![]() | Note |
|---|---|
|
The name of our class (Initializer) does not matter. What is important is that we extend |
|
The first step is to extend | |
|
|
This section describes how to use Redis to back HttpSession using XML based configuration.
![]() | Note |
|---|---|
|
The HttpSession XML Sample provides a working sample on how to integrate Spring Session and |
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.
<context:annotation-config/> <bean class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration"/>
<bean class="org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory"/>
|
We use the combination of | |
|
We create a |
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.
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:
This section describes how to use a relational database to back HttpSession using Java based configuration.
![]() | Note |
|---|---|
|
The HttpSession JDBC Sample provides a working sample on how to integrate Spring Session and |
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:
@EnableJdbcHttpSessionpublic class Config { @Bean public EmbeddedDatabase dataSource() { return new EmbeddedDatabaseBuilder()
.setType(EmbeddedDatabaseType.H2) .addScript("org/springframework/session/jdbc/schema-h2.sql").build(); } @Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource);
} }
|
The | |
|
We create a | |
|
We create a |
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:
src/main/java/sample/Initializer.java.
public class Initializer extends AbstractHttpSessionApplicationInitializer {public Initializer() { super(Config.class);
} }
![]() | Note |
|---|---|
|
The name of our class (Initializer) does not matter. What is important is that we extend |
|
The first step is to extend | |
|
|
This section describes how to use a relational database to back HttpSession using XML based configuration.
![]() | Note |
|---|---|
|
The HttpSession JDBC XML Sample provides a working sample on how to integrate Spring Session and |
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.
<context:annotation-config/> <bean class="org.springframework.session.jdbc.config.annotation.web.http.JdbcHttpSessionConfiguration"/>
<jdbc:embedded-database id="dataSource" database-name="testdb" type="H2"> <jdbc:script location="classpath:org/springframework/session/jdbc/schema-h2.sql"/> </jdbc:embedded-database>
<bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <constructor-arg ref="dataSource"/> </bean>
|
We use the combination of | |
|
We create a | |
|
We create a |
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:
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.
This section describes how to use a relational database to back HttpSession when using Spring Boot.
![]() | Note |
|---|---|
|
The HttpSession JDBC Spring Boot Sample provides a working sample on how to integrate Spring Session and |
After adding the required dependencies, we can create our Spring Boot configuration.
Thanks to first-class auto configuration support, setting up Spring Session backed by a relational database is as simple as adding a single configuration property to your application.properties:
src/main/resources/application.properties.
spring.session.store-type=jdbc # Session store type.
Under the hood, Spring Boot will apply configuration that is equivalent to manually adding @EnableJdbcHttpSession annotation.
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.
Further customization is possible using application.properties:
src/main/resources/application.properties.
server.servlet.session.timeout= # Session timeout. If a duration suffix is not specified, seconds will be used. spring.session.jdbc.initialize-schema=embedded # Database schema initialization mode. spring.session.jdbc.schema=classpath:org/springframework/session/jdbc/schema-@@platform@@.sql # Path to the SQL file to use to initialize the database schema. spring.session.jdbc.table-name=SPRING_SESSION # Name of the database table used to store sessions.
For more information, refer to Spring Session portion of the Spring Boot documentation.
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 URL of the database. spring.datasource.username= # Login username of the database. spring.datasource.password= # Login password of the database.
For more information, refer to Configure a DataSource portion of the Spring Boot documentation.
Our Spring Boot 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.
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.
![]() | Note |
|---|---|
|
The Hazelcast Spring Sample provides a working sample on how to integrate Spring Session and |
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@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(HazelcastSessionRepository.DEFAULT_SESSION_MAP_NAME)
.addMapAttributeConfig(attributeConfig) .addMapIndexConfig(new MapIndexConfig( HazelcastSessionRepository.PRINCIPAL_NAME_ATTRIBUTE, false)); return Hazelcast.newHazelcastInstance(config);
} }
|
The | |
|
In order to support retrieval of sessions by principal name index, appropriate | |
|
We create a |
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 { }
![]() | Note |
|---|---|
|
The name of our class (Initializer) does not matter. What is important is that we extend |
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.
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.
![]() | Note |
|---|---|
|
This section describes how Spring Session provides transparent integration with |
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.
Spring Session can work with RESTful APIs by allowing the session to be provided in a header.
![]() | Note |
|---|---|
|
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. |
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 @EnableRedisHttpSessionpublic class HttpSessionConfig { @Bean public LettuceConnectionFactory connectionFactory() { return new LettuceConnectionFactory();
} @Bean public HttpSessionIdResolver httpSessionIdResolver() { return HeaderHttpSessionIdResolver.xAuthToken();
} }
|
The | |
|
We create a | |
|
We customize Spring Session’s HttpSession integration to use HTTP headers to convey the current session information instead of cookies. |
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 { }
![]() | Note |
|---|---|
|
The name of our class (Initializer) does not matter. What is important is that we extend |
Spring Session supports HttpSessionListener by translating SessionDestroyedEvent and SessionCreatedEvent into HttpSessionEvent by declaring SessionEventHttpSessionListenerAdapter.
To use this support, you need to:
SessionRepository implementation supports and is configured to fire SessionDestroyedEvent and SessionCreatedEvent.
SessionEventHttpSessionListenerAdapter as a Spring bean.
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"/>