[ 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