Hello,
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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066009#4066009
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066009
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
