[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-4351) Setting Conversation Timeout Gets Overwritten by FacesManager

[ https://jira.jboss.org/jira/browse/JBSEAM-4351?page=com.atlassian.jira.pl... ] arin saghatelian updated JBSEAM-4351: ------------------------------------- JBoss Forum Reference: http://seamframework.org/Community/SettingConversationTimeoutDynamicallyV... Description: Referring to the documentation on setting conversation timeouts, there are two obvious ways of setting the timeout. The first is in the components configuration: <core:manager concurrent-request-timeout="500" conversation-timeout="600000" conversation-id-parameter="cid"/> And if we want to set it for a specific page, we can use the page configuration: <page view-id="/page.xhtml" timeout="120000"/> This will override the conversation timeout for that page. There is a third way to set the background conversation timeout dynamically as described on page 300 of Seam in Action is to call the setTimeout() method in the built-in conversation component. Conversation.instance().setTimeout(Integer.valueOf((720000)); This works and sets the timeout for the conversation dynamically in the action, but I believe there is a bug in the prepareBackswitch() function in the FacesManager class that resets the conversation timeout back to whatever the timeout is set in the pages configuration and if no timeout is set there, defaults back to the timeout set in the components configuration. This renders the setTimeout() function useless. public void prepareBackswitch(FacesContext facesContext) { Conversation conversation = Conversation.instance(); //stuff from jPDL takes precedence org.jboss.seam.pageflow.Page page = Manager.instance().isLongRunningConversation() && Init.instance().isJbpmInstalled() && Pageflow.instance().isInProcess() && Pageflow.instance().isStarted() ? Pageflow.instance().getPage() : null; if (page==null) { //handle stuff defined in pages.xml Pages pages = Pages.instance(); if (pages!=null) //for tests { String viewId = Pages.getViewId(facesContext); org.jboss.seam.navigation.Page pageEntry = pages.getPage(viewId); if ( pageEntry.isSwitchEnabled() ) { conversation.setViewId(viewId); } if ( pageEntry.hasDescription() ) { conversation.setDescription( pageEntry.renderDescription() ); } else if(pages.hasDescription(viewId)) { conversation.setDescription( pages.renderDescription(viewId) ); } conversation.setTimeout( pages.getTimeout(viewId) ); conversation.setConcurrentRequestTimeout( pages.getConcurrentRequestTimeout(viewId) ); } } else { //use stuff from the pageflow definition if ( page.isSwitchEnabled() ) { conversation.setViewId( Pageflow.instance().getPageViewId() ); } if ( page.hasDescription() ) { conversation.setDescription( page.getDescription() ); } conversation.setTimeout( page.getTimeout() ); } flushConversationMetadata(); } Referring also to the reference on the conversation, the function setTimeout() should work in setting the timeout dynamically. Conversation API I think being forced to use the pages configuration for setting a timeout for a specific page is not very intuitive and there should be a way to set the timeout from the conversation component without having it be overwritten by the page timeout or the components configuration. I am not sure if I am doing something wrong in the way I am using the setTimeout() function but I think prepareBackswitch should check to see if the timeout has already been set before trying to set the conversation timeout from the pages configuration. was:When I try to extend the conversation timeout from the Conversation class, it is overwritten when the prepareBackswitch class is called in the FacesManager class. It sets the timeout to the page timeout value without checking to see if the timeout was already set. This seems to be a bug and so it prevents us from extending the conversation timeout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira