Not starting over when submitting from the first state of a flow

It seems an incorrect user experience to me that if the user is sitting on the first view-state and allows the session to time out, when they they submit from that view-state, they are forced to start the flow over again.

Is there any way to allow the first view submission to behave in a way that hides from the user that a new flow is beginning? This is a pretty glaring deficiency in the Web Flow user experience, in my opinion and in the opinion of my team of developers and testers. I guess I'll open a JIRA if I get no replies here as to what I might be missing (either in technically or philosophically).

(Different but related discussion about proactively detecting this situation to inform the user here and on StackOverflow.)

(Actually, ideally, this wouldn't be only for the first state either. We have some flows where the first and second states are both alternative "login" criteria so in either case, the flow should be able to start out from scratch with no existing session.)

The first view-state of view-state x it doesn't matter... If the session is not there anymore neither is the flow state and that is the reason for starting over. The view-state can contain objects which aren't available anymore after session timeout another reason for starting over...

You get the same behavior with JSF when using a conversation/session/viewscoped bean and the session is destroyed, you run into a ViewExpiredException.

You could create a work around by creating a repository which doesn't rely on the session but stores the state elsewhere (in a database for instance) that way your flow execution isn't (fully) bound to the session lifecycle. Another solution could be to create a controller for submitting the first screen which in turn launches the flow.

Thanks. I certainly don't want to create my own repository.

I've considered starting pages outside the flow, but what a pain to manage (message resources, Spring beans, etc. having to be duplicated both inside and outside).

From an implementation standpoint, I'm not surprised this isn't a trivial thing to do. But from a user experience standpoint, it seems essential to support such behavior. Sigh. I guess I'll try JIRA.

https://jira.springsource.org/browse/SWF-1588