[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-686) Conversation cleanup does not work for a request that invaldiates the session
by Chris Rudd (JIRA)
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
19 years, 2 months
[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-335) NullPointerException if user quikcly decides to click a different link or button before the page renders
by Gavin King (JIRA)
[ http://jira.jboss.com/jira/browse/JBSEAM-335?page=comments#action_12351472 ]
Gavin King commented on JBSEAM-335:
-----------------------------------
Yes, you need Seam 1.1.
> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
> Key: JBSEAM-335
> URL: http://jira.jboss.com/jira/browse/JBSEAM-335
> Project: JBoss Seam
> Issue Type: Bug
> Components: JSF
> Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
> Reporter: Keith Naas
> Assigned To: Gavin King
> Priority: Critical
> Fix For: 1.1.0.BETA1
>
>
> When a user is on one of our screens, they can decide to click a link before the next page loads. Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181. Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.
> Stack Trace
> java.lang.NullPointerException
> at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 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)
> .....
--
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
19 years, 2 months