javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-2801

Accessing a non-flow page from the flow is broken

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Works as designed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      For the project structure:

      src
      src/main
      src/main/java
      src/main/java/org
      src/main/java/org/glassfish
      src/main/java/org/glassfish/flowmulti
      src/main/java/org/glassfish/flowmulti/Flow1.java
      src/main/java/org/glassfish/flowmulti/Flow1Bean.java
      src/main/webapp
      src/main/webapp/flow1
      src/main/webapp/flow1/flow1.xhtml
      src/main/webapp/flow1/flow1a.xhtml
      src/main/webapp/flow1/flow1b.xhtml
      src/main/webapp/index.xhtml
      src/main/webapp/nonFlow.xhtml
      src/main/webapp/WEB-INF
      src/main/webapp/WEB-INF/beans.xml
      src/main/webapp/WEB-INF/web.xml

      flow1a.xhtml has a fragment as:

      <p><h:commandButton id="index" value="home" action="/index" /></p>

      Clicking on "home" button does not redirect to "/index". This was working with an earlier build of GlassFish but broken with b80.

      This is causing "flows" sample to be broken as well.

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          The fact that such behavior worked before was a bug. The only way to
          exit a flow is through a <flow-call> or a <flow-return> node. Here are
          examples of each, respectively.

          SECTION FLOW_RETURN:

          <flow-definition id="flow3">
          <flow-return id="exit3">
          <navigation-case>
          <from-outcome>exit2</from-outcome>
          </navigation-case>
          </flow-return>
          </flow-definition>
          <flow-definition id="flow2">
          <flow-call id="call_flow3">
          <flow-reference>
          <flow-id>flow3</flow-id>
          </flow-reference>
          </flow-call>
          <flow-return id="exit2">
          <navigation-case>
          <from-outcome>exit1</from-outcome>
          </navigation-case>
          </flow-return>
          </flow-definition>
          <flow-definition id="flow1">
          <flow-call id="call_flow2">
          <flow-reference>
          <flow-id>flow2</flow-id>
          </flow-reference>
          </flow-call>
          <navigation-rule>
          <from-view-id>*</from-view-id>
          <navigation-case>
          <from-outcome>exit1</from-outcome>
          <to-view-id>/flow1/return2.xhtml</to-view-id>
          </navigation-case>
          </navigation-rule>
          </flow-definition>

          with these view nodes (I've left the fully qualified paths so you can
          see the actual source in context in the Mojarra source tree)

          test/web-profile/flow/nested_flows/src/main/webapp/flow1/flow1.xhtml
          test/web-profile/flow/nested_flows/src/main/webapp/flow1/return2.xhtml
          test/web-profile/flow/nested_flows/src/main/webapp/flow2/flow2.xhtml
          test/web-profile/flow/nested_flows/src/main/webapp/flow3/flow3.xhtml
          test/web-profile/flow/nested_flows/src/main/webapp/index.xhtml

          Here is the flow through the nested_flows app.

          Visit index.xhtml, click on "flow1" buton, now you are in flow1. Click
          "flow2" button, now you are in flow2. Click "flow3" button, now you are
          in flow3. Click on "exit3" button. This activates the <flow-return
          id="exit3">. This node returns the value "exit2" to the calling flow
          (flow2). In flow2, exit2 is a <flow-return>. It returns "exit1" to the
          calling flow (flow1). In flow1, we have a navigation rule that says,
          "for any view id with the outcome "exit1" show the view node
          /flow1/return2.xhtml.

          SECTION: FLOW_CALL (excerpted from
          test/web-profile/flow/basic_faces_flow_call).

          <flow-definition id="flow-b">

          <flow-return id="taskFlowReturn1">
          <from-outcome>#

          {flow_b_Bean.returnValue}

          </from-outcome>
          </flow-return>

          <flow-call id="callA">
          <flow-reference>
          <flow-document-id>unique</flow-document-id>
          <flow-id>flow-a</flow-id>
          </flow-reference>
          </flow-call>

          </flow-definition>

          public class FlowA implements Serializable {

          private static final long serialVersionUID = -7623501087369765218L;

          public FlowA() {
          }

          @Produces @FlowDefinition
          public Flow buildMyFlow(@FlowBuilderParameter FlowBuilder flowBuilder)

          { String flowId = "flow-a"; flowBuilder.id("unique", flowId); flowBuilder.flowCallNode("callB").flowReference("", "flow-b"); return flowBuilder.getFlow(); }

          }

          Any component on any page within flow-a that activates the "callB"
          <flow-call> node, calls flow-b. Likewise, any component on any page
          within flow-b that activates the "callA" <flow-call> node calls, flow-a.

          Any other attempts to navigate out of a flow are treated as a normal
          broken JSF navigation: a message is logged but the current view does not
          change.

          Show
          Ed Burns added a comment - The fact that such behavior worked before was a bug. The only way to exit a flow is through a <flow-call> or a <flow-return> node. Here are examples of each, respectively. SECTION FLOW_RETURN: <flow-definition id="flow3"> <flow-return id="exit3"> <navigation-case> <from-outcome>exit2</from-outcome> </navigation-case> </flow-return> </flow-definition> <flow-definition id="flow2"> <flow-call id="call_flow3"> <flow-reference> <flow-id>flow3</flow-id> </flow-reference> </flow-call> <flow-return id="exit2"> <navigation-case> <from-outcome>exit1</from-outcome> </navigation-case> </flow-return> </flow-definition> <flow-definition id="flow1"> <flow-call id="call_flow2"> <flow-reference> <flow-id>flow2</flow-id> </flow-reference> </flow-call> <navigation-rule> <from-view-id>*</from-view-id> <navigation-case> <from-outcome>exit1</from-outcome> <to-view-id>/flow1/return2.xhtml</to-view-id> </navigation-case> </navigation-rule> </flow-definition> with these view nodes (I've left the fully qualified paths so you can see the actual source in context in the Mojarra source tree) test/web-profile/flow/nested_flows/src/main/webapp/flow1/flow1.xhtml test/web-profile/flow/nested_flows/src/main/webapp/flow1/return2.xhtml test/web-profile/flow/nested_flows/src/main/webapp/flow2/flow2.xhtml test/web-profile/flow/nested_flows/src/main/webapp/flow3/flow3.xhtml test/web-profile/flow/nested_flows/src/main/webapp/index.xhtml Here is the flow through the nested_flows app. Visit index.xhtml, click on "flow1" buton, now you are in flow1. Click "flow2" button, now you are in flow2. Click "flow3" button, now you are in flow3. Click on "exit3" button. This activates the <flow-return id="exit3">. This node returns the value "exit2" to the calling flow (flow2). In flow2, exit2 is a <flow-return>. It returns "exit1" to the calling flow (flow1). In flow1, we have a navigation rule that says, "for any view id with the outcome "exit1" show the view node /flow1/return2.xhtml. SECTION: FLOW_CALL (excerpted from test/web-profile/flow/basic_faces_flow_call). <flow-definition id="flow-b"> <flow-return id="taskFlowReturn1"> <from-outcome># {flow_b_Bean.returnValue} </from-outcome> </flow-return> <flow-call id="callA"> <flow-reference> <flow-document-id>unique</flow-document-id> <flow-id>flow-a</flow-id> </flow-reference> </flow-call> </flow-definition> public class FlowA implements Serializable { private static final long serialVersionUID = -7623501087369765218L; public FlowA() { } @Produces @FlowDefinition public Flow buildMyFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = "flow-a"; flowBuilder.id("unique", flowId); flowBuilder.flowCallNode("callB").flowReference("", "flow-b"); return flowBuilder.getFlow(); } } Any component on any page within flow-a that activates the "callB" <flow-call> node, calls flow-b. Likewise, any component on any page within flow-b that activates the "callA" <flow-call> node calls, flow-a. Any other attempts to navigate out of a flow are treated as a normal broken JSF navigation: a message is logged but the current view does not change.

            People

            • Assignee:
              Ed Burns
              Reporter:
              arungupta
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: