Conversations are just state persisted over a session. They could be used for long transactions, wizards, etc. The issue that you may lose track of that state for a user if another user hijacks the session is not a use case for a feature but a description of a bug.
Creating a separate subsystem on the server to partition a single HTTP session for multiple users and maintain the conversation is classic overengineering. Seems like Seam has gone to a lot of trouble to provide just another way to persist state. RajibJana wrote: > > Dave , you read my concern correctly, and my app needs the feature you > have mentioned ( I guess many of such), Its not the login issue alone, the > app needs multiple user sessions/conversations independent of http > session, I will check how SEAM is providing such feature. > > Thanks > > Rajib > > > newton.dave wrote: >> >> Wes Wannemacher wrote: >>> Two users are not going to share the same session. Each user will get a >>> new >>> session. That's how app servers work. >> >> Check out the Seam conversation stuff. >> >> It allows the same user (or, I suppose, two different users, but that's >> not its primary purpose) to have multiple "session" states. >> >> I could, say, have two tabs open, but each has a "conversation" scope. >> So where most frameworks would drop stuff into session and the tabs >> would overwrite each others data, Seam doesn't. (It may still use >> session tied to a tab-specific key; I don't know the mechanism yet.) >> >> Dave >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> >> > > -- View this message in context: http://www.nabble.com/Struts-2-session-problem-tp21513305p21537201.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
