[
https://issues.apache.org/jira/browse/EXTCDI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved EXTCDI-218.
----------------------------------
Resolution: Won't Fix
I implemented @RestScoped to solve this problem. See EXTCDI-232
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
