Conversation cleanup does not work for a request that invaldiates the session ----------------------------------------------------------------------------- Key: JBSEAM-686 URL: http://jira.jboss.com/jira/browse/JBSEAM-686 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1.1.GA, 1.1.0.GA, 1.1.0.CR2, 1.1.0.CR1, 1.1.0.BETA2, 1.1.0.BETA1, 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1 Reporter: Chris Rudd Priority: Minor If beans are added to a long running conversation in the same request that Seam.invalidateSession() is called, they will not be destroyed correctly. This is because the conversation is never flushed to the Session object, and therefore ServerConversationContext.getNamesFromSession() cannot see them. <LifeCycle: 308> if ( Contexts.isConversationContextActive() ) { if ( !Manager.instance().isLongRunningConversation() ) { log.debug("destroying conversation context"); Contexts.destroy( Contexts.getConversationContext() ); } if ( !Seam.isSessionInvalid() && !Init.instance().isClientSideConversations() ) { log.debug("flushing server-side conversation context"); Contexts.getConversationContext().flush(); } } This will also happen when a Temporary Conversation is changed to a long running because of a redirect (which is where i found the problem initially) and Seam.InvalidateSession() has been called. It seems that the !Seam.isSessionInvalid() check should be removed. The SeamListener when it sees the sessionDestroyed event will properly clean up the context. NOTE: If the bean was already in the conversation from a previous request (long running conversation only) then the issue does not occur as the object id already part of the sessions attributes from a previous request. -- 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