我正在一个使用 Seam 和 JSF 的项目中工作。出于某种原因（不要问我，我不知道），我之前的人决定通过 FacesContext.getExternalContext().redirect() 将用户重定向到响应页面。我看到的问题是，某些页面在重定向到它们自己时，永远不会释放对话（URL 中的 conversationId 始终相同）。有没有人遇到过类似的问题？谢谢

我最近一直在使用 Seam，临时对话仍然让我感到困惑。

在我们的项目中，我们使用ExternalContext.redirect()将用户重定向到响应页面。根据我的阅读，Seam 对话在调用渲染响应阶段时结束。

但后来我在其他地方读到：Seam 在 JSF 回发和重定向之间透明地传播对话上下文（包括临时对话上下文）。

因此，当我重定向到同一页面时会发生什么，commandLinks 始终将相同的 conversationId 附加到其操作 url。正如页面所说，我试图用 结束临时对话 <f:param name="conversationPropagation" value="none"/>，但这会导致在呈现重定向页面时，对话上下文已经是 fred 并且我们使用的 bean 不能再在响应中使用。

所以我想知道的是，是否有办法通过重定向结束对话并保持上下文直到呈现响应？

如果没有，临时对话何时真正结束？因为由于对话上下文是通过重定向和回发传播的，所以对我来说它永远不会结束。

我正在使用 Seam 并收到“并发调用对话”错误。这是什么意思？

我有一个需要 5 分钟才能处理的按钮。我在 2 分钟内收到此错误。将并发请求超时设置为 10 分钟似乎不起作用。有没有办法阻止所有其他请求，直到第一个请求完成？

我有一个非常简单的应用程序，在 WebLogic 10.3.2 (11g)、Seam 2.2.0.GA 上只有 2 个页面。我每个都有一个命令按钮，它可以在发布后重定向到另一个。这很好用，因为我在地址栏中看到了当前页面的 URL。

但是，即使我没有定义长时间运行的对话，在随机点击次数之后，并且 - 我认为 - 在随机数秒（~10s - 60s）之后，我在这篇文章的末尾得到了一个可爱的例外。

现在，如果我理解了重定向时临时对话是如何工作的：

1. 当我第一次看到我的应用程序时，url 是http://localhost:7001/myapp

2. 当我单击 pageA.xhtml 中的按钮时，我最终会出现“pageB.xhtml?cid=26”。这是正常的，因为 Seam 将第一个请求的临时会话延长到重定向的 renderResponse 阶段。因此，它使用扩展临时对话的 cid（对话 ID）来查找任何传播的参数。

3. 当我单击 pageB.xhtml 中的按钮时，我最终进入 pageA.xhtml?cid=26

新的扩展临时对话也使用了相同的 cid。这是正常的，因为对话在上一个重定向后的帖子结束时结束，而不是数字 26 可以免费用作 cid。

这一切都正确吗？如果是，为什么会发生这种情况：如果我重新输入应用程序的家庭地址（显示 pageA）并重新单击，我最终会出现 pageB.xhtml?cid=29，它与 26 不同。但是 26 已经结束在上一个 RenderResponse 阶段之后，我重新输入了 url。为什么不使用它而不是29？

所以，总结，2个问题：

1. 即使我没有开始任何长时间的对话，为什么会出现异常？
2. cid到底发生了什么？它是在什么基础上改变的？

干杯，

更新：

附加信息：我在页面 A 中使用这样的 h:commandButtons：

在页面 B

导航页A.page.xml：

和 pageB 非常相似。

至于对话超时，我已将其设置为 1h。请注意，这无关紧要，因为正如我在这里所读到的，它仅用于后台对话。堆栈跟踪如下：

因为我在对话突然结束时遇到了一些错误，所以我在我的项目中创建了一些重现该问题的测试页面。导航发生在 pageA.xhtml 和 pageB.xhtml 之间。如果我以错误的方式使用某些东西，请告诉我。

我的配置：Seam 2.2.0.GA WebLogic 10.3.2 (11g) Richfaces 3.3.2 JSF 1.2

注意：使用注释开始/结束对话时也会发生同样的情况

=======

页 A

=======

页 B

==========

例外：

这发生在随机数量的重定向之后。

javax.faces.FacesException：

{pagebAction.redirectA()}：java.lang.IllegalStateException：否

在 org.ajax4jsf.component.AjaxViewRoot.processEvents( AjaxViewRoot.java:324) 在 org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:299) 在 org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:256) 在 org.ajax4jsf.component.AjaxViewRoot.processApplication (AjaxViewRoot.java:469) 在 com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82) 在 com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) 在 com.sun。 faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) 在 javax.faces.webapp.FacesServlet。服务（FacesServlet.java:265）在 weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) 在 weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) 在 weblogic.servlet.internal .ServletStubImpl.execute(ServletStubImpl.java:292) 在 weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) 在 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) 在 org.ajax4jsf。 webapp.BaseFilter.doFilter(BaseFilter.java:530) 在 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) 在 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)在 org.jboss 的 org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)。seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss .seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java :178) org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388）在 org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) 在 org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) 在 org.jboss.seam.servlet.SeamFilter$FilterChainImpl .doFilter(SeamFilter.java:69) 在 org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) 在 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) 在org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) 在 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) 在 weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java: 27) 在 weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction 的 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)。在 weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) 在 weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) 在 weblogic.servlet.internal 运行(WebAppServletContext.java:3592) .WebAppServletContext.securedExecute(WebAppServletContext.java:2202) 在 weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) 在 weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) 在 weblogic.work。 ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) 原因：javax.faces.el.E​​valuationException: java.lang.IllegalStateException: javax.faces 没有对话上下文活动.component.MethodBindingMethodExpressionAdapter。invoke(MethodBindingMethodExpressionAdapter.java:102) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) ... 45 更多原因：java.lang.IllegalStateException：在 org.jboss 上没有活动的对话上下文。 seam.ScopeType.getContext(ScopeType.java:133) at org.jboss.seam.Component.getValueToInject(Component.java:2325) at org.jboss.seam.Component.injectAttributes(Component.java:1736) at org.jboss .seam.Component.inject(Component.java:1554) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68 ) 在 org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:65) 在 org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext. java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185) at org.jboss.seam.intercept .JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103) 在 eu.emea.pim.prs.web.seamsandbox.PagebAction_$$_javassist_seam_8.redirectA(PagebAction_$$_javassist_seam_8.java) 在 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)在 sun.reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl。java:39) 在 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 在 java.lang.reflect.Method.invoke(Method.java:597) 在 org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil .java:335) 在 org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:280) 在 org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59) 在 org.jboss.el。 parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65) at org.jboss.el.parser.AstValue.invoke(AstValue.java:96) at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at com .sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68) 在 javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) ... 46 更多

嗨，我正在构建一个 Seam 应用程序并有一个问题：

我得到了一个带有删除和选择方法的无状态会话 bean（默认接缝范围）。包含数据模型的页面加载并获得用于选择和删除每一行的链接（两个链接都引用 bean 中的操作方法）。

delete 方法从列表中删除选定的行并返回 null（重新加载页面）。select 方法加载一个新页面，可以在其中编辑所选行。

每次单击数据模型中的链接并触发操作时，conversationId 都会增加。这是正常的行为，因为我什至没有在谈话中？如果这不是正常行为，防止这种情况发生的最佳做法是什么？

在 Seam 参考指南中，可以找到以下段落：

我们可以在 components.xml 中为并发请求超时（以毫秒为单位）设置一个合理的默认值：

然而，我们发现 500 毫秒对于我们必须处理的大多数情况来说还不够，尤其是在对话访问受到严格限制的情况下。

在我们的应用程序中，我们结合了页面范围的 ajax 请求（由各种用户操作触发）、一些全局范围的轮询通知逻辑（标题的一部分，因此包含在每个页面中）以及调用操作和/或导航到其他页面的常规链接页。

因此，即使网站上没有任何显着负载，我们也会经常以可怕的方式并发访问对话异常。

在研究了相当多的选项之后，我们最终将这个值提高到了几秒钟（我们正在讨论是否将其提高到 10 秒），因为没有一个推荐的解决方案似乎能够完全解决我们的问题（甚至强制一个全局当我们的一个轮询调用正在进行时，所有 ajax 请求的队列仍然会让我们暴露在用户决定单击链接的情况下）。我们更愿意让用户等待一两秒钟，而不是仅仅因为他们在错误的时刻点击了链接而得到错误页面。

现在的问题是：我们是否缺少一些明显的东西（例如一种允许并发访问对话并处理我们自己所需的锁定的方法，例如:)？人们如何在 seam 中解决这个问题（ajax 请求与用户驱动的交互混合）？在 ajax 请求正在进行时禁用页面上的所有链接（如一个博客页面所建议的那样）实际上不是一个可行的选择。

还有其他建议吗？

TIA，安德烈

Seam 的文档说会话状态（见最后一行的链接）可以配置为存储在客户端浏览器中，而不是 servlet 会话中。谁能告诉我：

1. 这个配置是怎么设置的？
2. Seam 是如何在浏览器内部实际存储会话状态的？

我对 Seam 很陌生，我需要在下面的代码中进行一些说明，我需要知道它是如何工作的，在这段代码中 RESTRICTIONS 的用途是什么......

我对 Seam 中处理会话和对话的方式有疑问。我们有一些相当长的表单，大部分时间你开始填写第一个屏幕，然后在后台执行一些操作，用户离开计算机去做一些工作，然后他们回来并注释工作。

问题是大多数时候会话超时或对话超时。虽然第二个可以通过拆分工作流轻松修复，但第一个更重要，因为用户必须重新登录，导航到右侧屏幕，然后才能输入注释。

有没有一种简单的方法可以让 Ajax 片段在后台触发会话刷新。这将使我们能够无限期地保持会话有效。

还有一种简单的方法可以使对话保持活力吗？