[ http://jira.jboss.com/jira/browse/JBSEAM-1860?page=all ] Jacob Orshalick updated JBSEAM-1860: ------------------------------------ Summary: login-required and no-conversation-view-id causes infinite redirect after session timeout on POST request (was: login-required and no-conversation-view-id causing infinite redirect on POST request after session timeout) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1860?page=comments#action_12373988 ] steve tynor commented on JBSEAM-1860: ------------------------------------- I can reproduce this behavior on our Seam 1.2.1-GA / JBoss 4.2.1-GA based app. Hopefully a solution can be found which fixes the behavior on both versions of Seam -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1860?page=comments#action_12374099 ] Shane Bryzak commented on JBSEAM-1860: -------------------------------------- I couldn't reproduce this behaviour with the latest CVS version of Seam. Could you please try it with the latest CVS or nightly build, and if you still get an error could you please attach a deployable test case to this issue which reproduces it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1860?page=comments#action_12374259 ] Jacob Orshalick commented on JBSEAM-1860: ----------------------------------------- I will try an example this evening at home using the latest CVS source as retrieving the source using cvsgrab at the office is taking an eternity. I will post my results afterward. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1860?page=comments#action_12374705 ] Jacob Orshalick commented on JBSEAM-1860: ----------------------------------------- It turns out that this issue stems from using client side state-saving with JSF. When I change my application to server side state-saving it functions as expected. It appears that with client side state-saving, the FacesPage instance is restored from the context even if the session timed out. If a long-running conversation is in progress this becomes a problem due to the following execution in the SeamPhaseListener: ... protected void afterRestoreView(FacesContext facesContext) { FacesLifecycle.resumePage(); Map parameters = facesContext.getExternalContext().getRequestParameterMap(); /** The next call restores the FacesPage and sets ConversationPropagation.validateLongRunningConversation = true if client side state-saving is turned on and a long-running conversation was in progress before the session timeout */ ConversationPropagation.instance().restoreConversationId(parameters); /** The next call returns a false value because ConversationPropagation.validateLongRunningConversation was set to true but the conversation does not exist (since the session timed out) */ boolean conversationFound = Manager.instance().restoreConversation(); FacesLifecycle.resumeConversation( facesContext.getExternalContext() ); /** postRestorePage now ends up trying to redirect to the no-conversation-view-id since which is not what we really wanted. Once the redirect occurs, if a login is required on the page being redirected to, another redirect to the login page is attempted which results in the IllegalStateException (since 2 redirects cannot occur in the same request) */ postRestorePage(facesContext, parameters, conversationFound); } ... Hope this helps. A work-around is to use server-side state saving if your application allows. Please let me know if you have any other questions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1860?page=all ] Shane Bryzak closed JBSEAM-1860. -------------------------------- Resolution: Done Thanks for the test case Jacob. I've fixed this in CVS by checking if a login-redirect is required before performing a no-conversation-redirect. If you could test these changes against your app it would be great. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira