Revise conversation package [SWF-175]

[spring-operator]

Erwin Vervaet opened SWF-175 and commented

The current ConversationManager implementations in the conversation.impl package are a bit strange and should be revised.

• Why does AbstractConversationManager use an elaborate implementation technique with ConversationProxy objects delegating back to the manager which delegates the call on to a ConversationEntry object?
• What use-case is LocalConversationManager serving? It stores all conversations in a local map but keeps the ids of the conversations of a particular client in that client's session map. What about use in a clustered environment?
• Should the conversation (.impl) package be moved to execution.repository.conversation (.impl) since it's not really a conceptual conversation that's defined by the package but just a 'conversation data storage system'?
• How to SessionBindingConversationManager and LocalConversationManager relate to each other? When do I use one, when the other? As a comparison: SessionBindingConversationManager stores ConversationEntry's in the user session map and also stores the list of ids of those conversations in the session map. LocalConversationManager stores all conversation entries for the entire VM in a single local map but holds lists of conversation ids for a particular user in the session (using a UserConversationContext).

As a proof of concept, I've checked in a SimpleConversationManager that seems much simpler implementation wise and sports most of the features of the other two conversation manager implementations.

---

Affects: 1.0

Issue Links:

• Add explicit support for expiring flows and detecting flow expiry [SWF-10] #943 Add explicit support for expiring flows and detecting flow expiry
  ("is depended on by")