[seam-issues] [JBoss JIRA] Commented: (JBSEAM-4375) ManagedEntityInterceptor destroys components in parent nested conversation, when ending a nested conversation

[Peter Brewer (JIRA)]

    [ https://jira.jboss.org/browse/JBSEAM-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12548319#action_12548319 ] 

Peter Brewer commented on JBSEAM-4375:
--------------------------------------

I am experiencing this with only a single nested conversation (e.g. from the example above create cid1 and nest cid2 then end cid2). I have a component in the parent and it gets evicted when ending the nested conversation. It is not only limited to page parameters though: if you manually call conversation.end() for a nested and then access a component the same thing happens.

I can add more specific detail (e.g. method call traces and logs) and also I should be able to create a test case too, if anyone wants to look at the issue?

> ManagedEntityInterceptor destroys components in parent nested conversation, when ending a nested conversation
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-4375
>                 URL: https://jira.jboss.org/browse/JBSEAM-4375
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.2.0.GA
>            Reporter: Darryl Smith
>
> setup: 
> Parent (cid1)
>  -> First Nested (cid2) 
>  ----> Second Nested (cid3)
> cid3: conversation.endAndRedirect(true); which calls setLongRunningConversation(false); 
> FacesManager's redirect method tries to encode the page parameters of the parent view, which accesses a component
> created in cid2 the conversation we are returning to.
> This triggers ManagedEntityWrapper's switchToConversationContextOfComponent which switches the current conversation to cid2
> after ManagedEntityWrapper wraps the component ManagedEntityWrapper's restorePreviousConversationContextIfNecessary method is called with oldCid = cid3
> which triggers Contexts.getConversationContext().flush(); 
> When flush is invoke the conversation (cid2) isn't long running, so flush removes all components created in cid2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira