MyFaces CODI
  1. MyFaces CODI
  2. EXTCDI-218

defer final deletion of @ViewAccessScoped beans

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Mark Struberg added a comment -

        A few ways to solve this:

        1.) use the ClientSideWindowHandler: This is the only known fully functional solution for windowId handling. The problem is that it leads to slight flickering for the users (because an 'intermediate page' has to be rendered which detects any fresh browser window and loads the real destination via JavaScript)

        2.) Instead of terminating @ViewAccessScoped immediately when a new viewId gets detected we only 'defer' them and clean them up on the following request. If he dropWindowId.js script detects a fresh browser window, it can pass the originalWindowId=123 as parameter so we can 'rollback' the deferring. I know that this is not an optimal solution but it would probably be the easiest way to fix the behaviour.

        3.) Implement a history for @ViewAccessScoped beans. This is something which we thought about since a long time already. This would allow recovering on browser back buttons.

        Show
        Mark Struberg added a comment - A few ways to solve this: 1.) use the ClientSideWindowHandler: This is the only known fully functional solution for windowId handling. The problem is that it leads to slight flickering for the users (because an 'intermediate page' has to be rendered which detects any fresh browser window and loads the real destination via JavaScript) 2.) Instead of terminating @ViewAccessScoped immediately when a new viewId gets detected we only 'defer' them and clean them up on the following request. If he dropWindowId.js script detects a fresh browser window, it can pass the originalWindowId=123 as parameter so we can 'rollback' the deferring. I know that this is not an optimal solution but it would probably be the easiest way to fix the behaviour. 3.) Implement a history for @ViewAccessScoped beans. This is something which we thought about since a long time already. This would allow recovering on browser back buttons.
        Hide
        Gerhard Petracek added a comment -

        1) is already there
        2) not needed (will be solved by 3) ) and adds additional complexity esp. for the manual usage of the WindowContext api - maybe as optional feature if there is a problem with 3)
        3) planned since a long time for all codi scopes - esp. for a better back-button support like the swf repos but it requires a requst-id which might be part of the upcoming window-id prototype for jsf 2.2 (a backport to jsf 2.0 and 2.1 is planned)

        -> +1 for 3) – we shouldn't do 2) for now because it creates new issues and is more like a workaround. if someone needs it, it's possible to impl. it as codi-addon

        Show
        Gerhard Petracek added a comment - 1) is already there 2) not needed (will be solved by 3) ) and adds additional complexity esp. for the manual usage of the WindowContext api - maybe as optional feature if there is a problem with 3) 3) planned since a long time for all codi scopes - esp. for a better back-button support like the swf repos but it requires a requst-id which might be part of the upcoming window-id prototype for jsf 2.2 (a backport to jsf 2.0 and 2.1 is planned) -> +1 for 3) – we shouldn't do 2) for now because it creates new issues and is more like a workaround. if someone needs it, it's possible to impl. it as codi-addon
        Hide
        Mark Struberg added a comment -

        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?

        Show
        Mark Struberg added a comment - 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?
        Hide
        Mark Struberg added a comment -

        I implemented @RestScoped to solve this problem. See EXTCDI-232

        Show
        Mark Struberg added a comment - I implemented @RestScoped to solve this problem. See EXTCDI-232

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Mark Struberg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development