Beehive
  1. Beehive
  2. BEEHIVE-912

The method removeSharedFlow( String sharedFlowClassName, HttpServletRequest request ) in org.apache.beehive.netui.pageflow.PageFlowUtils no longer removes a sharedflow from the session

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Invalid
    • Affects Version/s: 1.0
    • Fix Version/s: 1.0
    • Component/s: NetUI
    • Labels:
      None

      Description

      1.- Unzip the attached pageflow into a beehive enabled webapp.
      2.- Build and deploy your webapp and access the pageflow (e.g. http://localhost:<port>/<webapp_context>/sharedFlowApi/Controller.jpf

      In that page, hit the "verify" link and then the "Remove sharedFlowApi.SharedFlowApiTest from the Seession using PageFlowUtils.removeSharedFlow(String sharedFlowClassName, HttpServletRequest request)" link

      Expected: The page should display a message that confirms the fact that you have removed a sharedflow from the session.
      Actual: The sharedflow is still in the session. The method removeSharedFlow( String sharedFlowClassName, HttpServletRequest request ) in org.apache.beehive.netui.pageflow.PageFlowUtils no longer removes a sharedflow from the session

      The structure of the sharedFlowApi.Controller.jpf pageflow is as follows:
      sharedFlowApi.Controller.jpf contains a sharedflow reference "sharedFlow2":
      sharedFlowRefs=

      { @Jpf.SharedFlowRef(name="sharedFlow2", type=sharedFlowApi.pageFlowUtilApi.removeSharedFlow.AnotherSharedFlowApi.class) }

      Then, I have an action method to remove the sharedflow as follows:
      @Jpf.Action(
      forwards=

      { @Jpf.Forward( name="success", navigateTo=Jpf.NavigateTo.currentPage ) }

      )
      public Forward pageFlowUtilRemoveSharedFlow()
      {
      UseSharedFlowApi example = new UseSharedFlowApi(this.getRequest());
      example.removeSharedFlow();
      String objectsInSession = null;
      for(Enumeration sessionObjects = this.getSession().getAttributeNames(); sessionObjects.hasMoreElements()

      { if (SHAREDFLOW_TOREMOVE.equals(sessionObjects.nextElement())) objectsInSession = SHAREDFLOW_TOREMOVE + " is STILL in the session" + "\n"; }

      if (objectsInSession == null)
      objectsInSession = SHAREDFLOW_TOREMOVE + " has been REMOVED from the session" + "\n";
      return new Forward( "success", "message", objectsInSession);
      }

      The removeSharedFlow() method of sharedFlowApi.UseSharedFlowApi looks as follows:
      public void removeSharedFlow()

      { PageFlowUtils.removeSharedFlow(REMOVE_SHAREDFLOW, this.request); }
      1. sharedFlowApi-modified.zip
        8 kB
        Rich Feit
      2. sharedFlowApi.zip
        6 kB
        Alejandro Ramirez

        Activity

        Hide
        Alejandro Ramirez added a comment -

        pageflows to repro the problem.

        Show
        Alejandro Ramirez added a comment - pageflows to repro the problem.
        Hide
        Rich Feit added a comment -

        This is working as expected. We don't support crawling through our internal session attributes... in this case, you're seeing behavior which was added for v1m1 which leaves session attributes in place until the end of the request, at which point they are removed. We do this so that two concurrent requests will not conflict with each other – in essence, they each have their own "copy" of the session to operate on.

        I'm attaching a modified test that verifies:

        • If you call our official API (PageFlowUtils.getSharedFlow()) after calling PageFlowUtils.removeSharedFlow(), the shared flow is "officially" gone.
        • If you forward to another page flow (to avoid re-creating the same shared flow), you can crawl through session attributes on another request to ensure that that the shared flow instance is truly gone. It may actually be worth having tests that do crawl through the session, but they will break from time to time as our internal functionality changes.

        Let me know if you have any questions about this...

        Show
        Rich Feit added a comment - This is working as expected. We don't support crawling through our internal session attributes... in this case, you're seeing behavior which was added for v1m1 which leaves session attributes in place until the end of the request, at which point they are removed. We do this so that two concurrent requests will not conflict with each other – in essence, they each have their own "copy" of the session to operate on. I'm attaching a modified test that verifies: If you call our official API (PageFlowUtils.getSharedFlow()) after calling PageFlowUtils.removeSharedFlow(), the shared flow is "officially" gone. If you forward to another page flow (to avoid re-creating the same shared flow), you can crawl through session attributes on another request to ensure that that the shared flow instance is truly gone. It may actually be worth having tests that do crawl through the session, but they will break from time to time as our internal functionality changes. Let me know if you have any questions about this...
        Hide
        Rich Feit added a comment -

        Modified test case.

        Show
        Rich Feit added a comment - Modified test case.
        Hide
        Alejandro Ramirez added a comment -

        Verified invalid. I executed the test with the new attached repro app and it works as expected. Thanks Rich.

        Show
        Alejandro Ramirez added a comment - Verified invalid. I executed the test with the new attached repro app and it works as expected. Thanks Rich.

          People

          • Assignee:
            Alejandro Ramirez
            Reporter:
            Alejandro Ramirez
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development