[
https://issues.apache.org/jira/browse/EXTCDI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093704#comment-13093704
]
Mark Struberg commented on EXTCDI-218:
--------------------------------------
folks, I cannot find where we call Contextual#destroy() for the bean which gets
dropped in DefaultConversation#removeBean()
I remember that we had this. Did we loose this while refactoring?
> defer final deletion of @ViewAccessScoped beans
> -----------------------------------------------
>
> Key: EXTCDI-218
> URL: https://issues.apache.org/jira/browse/EXTCDI-218
> Project: MyFaces CODI
> Issue Type: New Feature
> Components: JEE-JSF12-Module, JEE-JSF20-Module
> Affects Versions: 1.0.1
> Reporter: Mark Struberg
> Assignee: Mark Struberg
>
> I have a tricky problem in production with @ViewAccessScoped beans in
> conjunction with the lazy windowId dropping script
> http://wiki.apache.org/myfaces/Drafts/WindowId
> The problem arises if the user is on the browsers tabA (windowId=123) which
> has a @ViewAccessScoped bean and opens a link from this window in a new tabB.
> In this case a request with the old windowId=123 (*) will be sent to the
> server and the response will be rendered to tabB. When the dropWindowId
> script detects that tabB is a fresh browser tab, it will issue a new request
> and drops the windowId to get a new one (windowId=124 now for tabB)
> The problem is that in step (*) we get a request with the _old_ windowId onto
> a new view, thus we drop the @ViewAccessScoped bean used in tabA.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
