Provide an Actuator endpoint for non-indexed session repositories

[wilkinsona]

Spring Session's reactive support doesn't appear to have an equivalent of FindByIndexNameSessionRepository so the functionality of the current endpoint can't be ported over to a reactive view of the world. We'll need to figure out what to do there.

/cc @rwinch @vpavic

[rwinch]

@wilkinsona Thanks for reaching out. We are currently planning on adding support for finding by username for 2.1. For tracking I created spring-projects/spring-session#914

[wilkinsona]

Thank you @rwinch. I’ll assign this one to our general 2.1 bucket for now on the assumption that our 2.1 schedules will align. We can adjust as needed if that’s not the case.

[wilkinsona]

We've repurposed this to provide an endpoint for an unindexed session repository that will allow sessions to be retrieved and deleted by ID. The ID will have to be found by some other means as listing all sessions will not be possible.

[vpavic]

Could you clarify whether this issue is still focused on reactive stack only or is it a general (meaning, targeting both Servlet and reactive stacks) concern now? If it's a general concern sounds like the session endpoint should probably be refactored in a way to separate functionality that depends on only SessionRepository from bits that depend on FindByIndexNameSessionRepository.

Either way, I'd gladly help out with this one.

Also, is there an example of actuator endpoint (outside of health, but that one's quite complex) that supports both stacks?

[wilkinsona]

Could you clarify whether this issue is still focused on reactive stack only or is it a general (meaning, targeting both Servlet and reactive stacks) concern now?

It's a general concern now.

refactored in a way to separate functionality that depends on only SessionRepository from bits that depend on FindByIndexNameSessionRepository

There are a few different ways this could be implemented. It should be possible for the existing SessionsEndpoint to take a SessionRepository and then do an instanceof check in sessionsForUsername, returning null when the repository isn't a FindByIndexNameSessionRepository.

Either way, I'd gladly help out with this one.

That would be great, thank you. I'll assign the issue to you.

Also, is there an example of actuator endpoint (outside of health, but that one's quite complex) that supports both stacks?

I don't think we'll need to support both WebFlux and Servlet (MVC and Jersey) in the same endpoint. Unlike health, we won't be in a position where there's a mixture of ReactiveSessionRepository and SessionRepository and we need to deal with both from the same endpoint. I think we should be able to auto-configure a SessionsEndpoint if there's a SessionRepository bean or a new ReativeSessionsEndpoint bean if there's a ReativeSessionRepository.

[vpavic]

returning null when the repository isn't a FindByIndexNameSessionRepository

Thanks for confirming this. I missed this paragraph while skimming through the docs yesterday so I was unsure whether null returned from the endpoint operation would be translated to 404.

I think we should be able to auto-configure a SessionsEndpoint if there's a SessionRepository bean or a new ReativeSessionsEndpoint bean if there's a ReativeSessionRepository.

That's how I too saw things initially but the part I'm unsure about is whether it's acceptable for two different endpoint implementations to be annotated with @Endpoint using the same id. I don't think there's an example of that in the codebase.

[wilkinsona]

is whether it's acceptable for two different endpoint implementations to be annotated with @endpoint using the same id

I think it should be fine as long as only one is auto-configured at a time. One uncertainty is the configuration properties annotation processor that generates metadata for each endpoint. I'm not sure what it'll do if it encounters two endpoints with the same ID. It would be fairly quick to try it and see.

[wilkinsona]

Closing in favor of #32046.