如何使Seam POJO会话无效
我正在玩一个具有会话范围的小接缝应用程序。 最后一种方法是通过邮件发送。 邮件发送后如何使我的会话失效？ 现在，当用户再次调用初始 URL 时，会话仍然存在，并且之前填写的所有表单数据仍然存在。
我找到了如何使用对话和 ejb 实现这一点的示例，但没有找到 POJO 和会话的示例。
谢谢， 罗里
I am playing around with a little seam app that has session scope. The last method is sending as mail. How can I invalidate my session after having the mail sent? Right now, when the user calls the initial url again, the session still lives and all of the previously filled in form data is still there.
I have found examples how to do that with conversations and ejb, but not with POJOs and sessions.
Thanks,
Rory
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Session.instance().invalidate();
Session.instance().invalidate();
根据 ISASI 的回答，您可以使用此代码使会话无效：
回答您的后续“问题”（奇怪的是，您将其添加为答案）。 要在通知用户成功后关闭会话，您可以创建一个“确认”页面并根据与“成功”结果关联的规则重定向到该页面。 然后创建一个页面操作以使会话失效。
从技术上讲，会话将在渲染页面之前关闭，因此这可能会在访问会话数据方面产生计时问题，因此您可能需要修改页面参数来进行补偿。 这是因为您基本上通过对每封电子邮件使用一个会话来“错误”地执行此操作。 使用对话会更好，因为有一个 @End 注释可以在渲染视图后结束对话 - 更容易。
一旦您的应用程序涉及多个任务，您就需要切换到使用对话，因为任务之间保存的任何状态都将丢失。 我想这会很快发生。 这些计时和状态管理问题正是 Seam 对话旨在解决的问题。
Per ISASI's answer you can use this code to invalidate the session:
In answer to your follow up "question" (which you added as an answer, bizarrely). To close the session after informing the user of the sucess then you create a "confirm" page and redirect to it based on a rule associated with the "success" outcome. Then create a page action to invalidate the session.
Technically, the session will be closed beofre rendering the page, so that may create a timing issue with regards accessing session data, so you may need to hack around with page parameters to compensate. This is because you are basically doing it "wrong" by using a session per email. You'll be much better off using a conversation because there is an @End annotation that ends the conversation after rendering the view - much easier.
You'll need to switch to using conversations once your application involves more than one task as any state held between tasks will be lost. I imagine that will happen quite quickly. These timing and state management issues are the problem Seam conversations was designed to solve.