Add smoke test with Spring Session and Hazelcast

[pmverma]

With SB 2.4.7 and spring (session+hazelcast) 2.5.2, I was expecting the sessions endpoint to work properly.
In trace log there is,

   SessionsEndpointAutoConfiguration#sessionEndpoint:
      Did not match:
         - @ConditionalOnBean (types: org.springframework.session.FindByIndexNameSessionRepository; SearchStrategy: all) did not find any beans of type org.springframework.session.FindByIndexNameSessionRepository (OnBeanCondition)

But Hazelcast4IndexedSessionRepository is already there implementing FindByIndexNameSessionRepository

The endpoints docs mention only the following which is already set up in my case.

Allows retrieval and deletion of user sessions from a Spring Session-backed session store. Requires a Servlet-based web application using Spring Session.

[snicoll]

@pmverma can you please share a small minimal sample that showcases the problem you've described. You can do so by attaching a zip to this issue or pushing the project on a GitHub repository.

[vpavic]

@snicoll I was able to reproduce this using my Spring Session samples repo - use sample-httpsession-hazelcast subproject.

I think this is actually a bug in Spring Session that was introduced together with the support for Hazelcast 4, when the return type of @Bean factory method in HazelcastHttpSessionConfiguration was changed to return SessionRepository<?> (see here). I can look into this from Spring Session side tomorrow.

[snicoll]

@vpavic Thanks. Should we move this one to Spring Session then?

[vpavic]

Hey @snicoll, I've taken care of this from Spring Session side - see the timeline just above.

I thought this issue could be used to consider adding smoke tests to prevent something like this from happening again. I added some from the Spring Session side, but since Spring Boot is the side that owns the integration it seems reasonable to have the smoke tests in here.

[snicoll]

see the timeline just above.

Thanks but it's far from obvious from the timeline that it has been fixed. Have I missed a reference to an issue in Spring Session?

Edit: looks like I did 🤦

Sure, we can reuse this issue to add a smoke test.

[vpavic]

Sorry, I probably should have referenced the issue in my comment as that would make it more clear.

Anyway, I think it would be a good idea to do this for all the session stores that Spring Boot's auto-configuration supports as a regression like this one can happen anywhere.

Looking at the existing spring-boot-smoke-test-session, are the profiles defined in the build of this smoke test actually leveraged anywhere in the project's build?

spring-boot/spring-boot-tests/spring-boot-smoke-tests/spring-boot-smoke-test-session/build.gradle

Line 33 in 2095991

sessionStores[project.findProperty("sessionStore") ?: "jdbc"].each { runtimeOnly it }

[wilkinsona]

They are not. IIRC, the profiles are a fairly direct translation of what we used to have with Maven. They need to be enabled as part of a manual build.

[vpavic]

I see, so in reality those profiles don't add much value having in mind these are smoke tests. But I understand that historically they've been samples (or at least were named as such) so in that context profiles would be of more use.

Either way, what's your take on ensuring that Actuator integration for Spring Session gets smoke tested across all the session stores Spring Boot provides auto-config for? Even though there are some tests on Spring Session side now, the integration is owned by Spring Boot so it makes sense that things primarily get smoke tested here.

[kandulsh]

Would like to work on this issue.

[mbhave]

Closing in favor of PR #28173.

[vpavic]

I think this should be reopened (and a bit repurposed) because the my previous comment raised some concerns that weren't addressed. I really think it would be valuable to have smoke tests that verify actuator integration for all the supported session stores.

[mbhave]

I've added a new issue for MongoDB and Redis.