Spring Session - HttpSession with GemFire P2P using XML (Quick Start)

This guide describes how to configure Pivotal GemFire as a provider in Spring Session to transparently back a web application’s HttpSession using XML Configuration.

The completed guide can be found in the HttpSession with GemFire (P2P) using XML Sample Application.

Updating Dependencies

Before using Spring Session, you must ensure that the required dependencies are included. If you are using Maven, include the following dependencies in your pom.xml:

pom.xml

<dependencies>
        <!-- ... -->

        <dependency>
                <groupId>org.springframework.session</groupId>
                <artifactId>spring-session-data-gemfire</artifactId>
                <version>1.2.0.RC2</version>
                <type>pom</type>
        </dependency>
        <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-web</artifactId>
                <version>4.2.5.RELEASE</version>
        </dependency>
</dependencies>

Since we are using a Milestone version, we need to add the Spring Milestone Maven Repository. If you are using Maven, include the following repository declaration in your pom.xml:

pom.xml

<repositories>
        <!-- ... -->

        <repository>
                <id>spring-milestone</id>
                <url>https://repo.spring.io/libs-milestone</url>
        </repository>
</repositories>

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>
            <dispatcher>ASYNC</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 GemFire (P2P) using XML Sample Application

Running the httpsession-gemfire-p2p-xml Sample Application

You can run the sample by obtaining the source code and invoking the following command:

$ ./gradlew :samples:httpsession-gemfire-p2p-xml:tomcatRun [-Dsample.httpsession.gemfire.log-level=info]

You should now be able to access the application at http://localhost:8080/

Exploring the httpsession-gemfire-p2p-xml Sample Application

Try using the application. Fill out the form with the following information:

Attribute Name: username
Attribute Value: john

Now click the Set Attribute button. You should now see the values displayed in the table.

How does it work?

We interact with the standard HttpSession in the SessionServlet shown below:

src/main/java/sample/SessionServlet.java

public class SessionServlet extends HttpServlet {

        @Override
        protected void doPost(HttpServletRequest request, HttpServletResponse response)
                        throws ServletException, IOException {
                String attributeName = request.getParameter("attributeName");
                String attributeValue = request.getParameter("attributeValue");
                request.getSession().setAttribute(attributeName, attributeValue);
                response.sendRedirect(request.getContextPath() + "/");
        }

        private static final long serialVersionUID = 2878267318695777395L;
}

Instead of using Tomcat’s HttpSession, we are actually persisting the values in GemFire. Spring Session creates a cookie named SESSION in your browser that contains the id of your session. Go ahead and view the cookies (click for help with Chrome or Firefox).

The following instructions assume you have a local GemFire installation. For more information on installation, see Installing Pivotal GemFire.

If you like, you can easily remove the session using gfsh. For example, on a Linux-based system type the following at the command-line:

$ gfsh

Then, enter the following into Gfsh ensuring to replace 70002719-3c54-4c20-82c3-e7faa6b718f3 with the value of your SESSION cookie, or the session ID returned by the GemFire OQL query (which should match):

gfsh>connect --jmx-manager=localhost[1099]

gfsh>query --query='SELECT * FROM /ClusteredSpringSessions.keySet'

Result     : true
startCount : 0
endCount   : 20
Rows       : 1

Result
------------------------------------
70002719-3c54-4c20-82c3-e7faa6b718f3

NEXT_STEP_NAME : END

gfsh>remove --region=/ClusteredSpringSessions --key="70002719-3c54-4c20-82c3-e7faa6b718f3"

The GemFire User Guide has more detailed instructions on using gfsh.

Now visit the application at http://localhost:8080/ and observe that the attribute we added is no longer displayed.