Conversation Timeout and Redirect
chubinator Jul 19, 2007 9:26 PMHello,
We are currently using Seam 1.2.1.GA and I have a question regarding the conversation time outs and redirects.
We have a page called listcontacts.xhtml with an s:link that calls a bean method action:
<s:link action="#{contactBean.add}" styleClass="button">Add</s:link>
This method is annotated with the @Begin annotation:
@Begin public void add() { contact = new Contact(); }
The contact is outjected:
@In(required=false) @Out(required=false) private Contact contact;
In our pages.xml, we have:
<page view-id="/secure/*" scheme="https"> <navigation from-action="#{contactBean.add}"> <redirect view-id="/secure/editcontact.xhtml" /> </navigation> ...
When we log into our app and click this link, it works as expected and takes us to our editcontact.xhtml page with the new blank contact.
If we wait 2 minutes (our conversation timeout length), and then click the link, we get the following error:
21:22:37,812 ERROR [STDERR] Jul 19, 2007 9:22:37 PM com.sun.facelets.FaceletViewHandler handleRenderException SEVERE: Error Rendering View[/secure/editcontact.xhtml] javax.faces.el.PropertyNotFoundException: /secure/editcontact.xhtml @28,91 value="#{contact.contactType}": Target Unreachable, i dentifier 'contact' resolved to null at com.sun.facelets.el.LegacyValueBinding.getType(LegacyValueBinding.java:96) at org.jboss.seam.ui.EnumItem.getValue(EnumItem.java:47) at org.apache.myfaces.shared_impl.util.SelectItemsIterator.hasNext(SelectItemsIterator.java:70) at org.apache.myfaces.shared_impl.renderkit.RendererUtils.internalGetSelectItemList(RendererUtils.java:477) at org.apache.myfaces.shared_impl.renderkit.RendererUtils.getSelectItemList(RendererUtils.java:453) at org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:278) at org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:252) at org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:54) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536) at org.jboss.seam.ui.JSF.renderChild(JSF.java:180) at org.jboss.seam.ui.JSF.renderChildren(JSF.java:162) at org.jboss.seam.ui.UIDecorate.encodeChildren(UIDecorate.java:234) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:244) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:573) at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:229) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:63) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595)
Looking at the DEBUG entries, it appears as though a conversation cleanup occurs after the add method exits, but before the @Begin is applied and the conversation is promoted to long running.
If I replace the redirect with render, it works...at least until it hits another redirect.
Why would redirect behave differently after a conversation timeout? Shouldn't the temporary conversation be promoted to a long running before the redirect and thus everything should work?
Why would it work before the timeout but not after.
Any help is greatly appreciated.
Thanks,
Mark