Uploaded image for project: 'MyFaces Core'
  1. MyFaces Core
  2. MYFACES-4553

TCK spec/flows/intermediate failure: WELD-001303: No active contexts for scope type jakarta.faces.flow.FlowScoped

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 4.0.0-RC4
    • 4.0.0-RC5
    • None
    • None

    Description

      The WELD-001303 error occurs because we are not yet in a flow officially (but will enter one). This means that the contextual storage for the flow has yet to be created.  This cause the weld error as the FlowScopeContext is not yet active – see isActive call.

       

      So flow scope is not active, but MyFaces starts to look at the nodes, it first checks the switch condition which references the flowScope implicit object: 

      Application Switch Case: 

      [https://github.com/jakartaee/faces/blob/3fae98234692ec16545a6d27cf36fabaeb883f9b/tck/old-tck/source/src/web/jsf/spec/flows/intermediate/maintain-customer-record/maintain-customer-record-flow.xml#L39]

       

      MyFace Switch Case Check: 

      [https://github.com/apache/myfaces/blob/8956fd167f797a4e32511e268a6520715cb132a5/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java#L645]

       

       

      This is a problem because the context for flowScope still needs to be created, as mentioned above. This flow transition, which causes the scope to be activated, doesn't happen until applyFlowTransition (which is much later). 

       

      My only idea is to force a transition call before we check the nodes, which causes myfaces unit test failures. 

      I also believe this is an issue in previous versions – we were lucky since the flowScope implicit object was evaluated to null (since no scope was active), and the "flowScope.customerId == null" check passed.

       

      Unit Test Code:

      spec/flows/intermediate:

      Test: [https://github.com/jakartaee/faces/blob/4.0.1/tck/old-tck/source/src/com/sun/ts/tests/jsf/spec/flows/intermediate/URLClient.java#L59]

             [https://github.com/jakartaee/faces/blob/4.0.1/tck/old-tck/source/src/com/sun/ts/tests/jsf/spec/flows/intermediate/URLClient.java#L91]

       

       

      Attachments

        1. faces_flows_intermediate_web.war
          17 kB
          Volodymyr Siedlecki

        Activity

          I've pushed my draft PR, but I'm at a loss on how to properly address this problem. I keep getting failures in one test suite or another.

          tandraschko, is there any chance you could look into this? I saw you had refactored the flow code a while ago and maybe you have a better idea of addressing this error?  It's one of the last TCK failures left.

          Thanks!

          volosied Volodymyr Siedlecki added a comment - I've pushed my draft PR, but I'm at a loss on how to properly address this problem. I keep getting failures in one test suite or another. tandraschko , is there any chance you could look into this? I saw you had refactored the flow code a while ago and maybe you have a better idea of addressing this error?  It's one of the last TCK failures left. Thanks!

          I've manged to create a fix without creating regressions.  The fix needed a few parts to it:

          • Only applies if we are not in a flow and are about to enter one.
          • Transition Marker since we if transition early, we shouldn't transition into the same flow again
          • Reordering of the flow node checks

          The previous order was SwitchNode, FlowCallNode, MethodCallNode, ReturnNode, and ViewNode.

          However, the spec (section 7.4.2.1in the original JSF 2.2 document), listed: ViewNode, SwitchNode, MethodCallNode, FlowCallNode, ReturnNode.

          I think neither of these are correct. Myfaces encounters this WELD error and spec doesn't mention the flow transitions explicitly in this node algorithm, and this is required since some nodes, such a a switch node, can reference flowscoped beans or the flowScope implicit object. If we don't transition, we will encounter this weld error with the use of CDI.

          The new order is now: ViewNode, ReturnNode, transition if not in a flow, FlowCallNode, SwitchNode, MethodCallNode. The order of the last three don't really matter, in my opinion. 

          The last two can contain EL expressions, which could reference a flow scoped object. View Nodes won't contain EL so it's not necessary to transition at this point. If the node is return node, then you're already in a flow and are trying to exit. 

          FlowCallNode is a bit tricky since we call "navigationContext.addTargetFlow(sourceFlow, currentFlow, null);" when startFlow is true. This would mean we need to skip the second transition, if it's created (ie. second flow references a switch / method node)

          I say skip second transition because applyFlowTransition loops thorough navigationContext.getTargetFlows() and there could be multiple.  Speaking of applyFlowTransition, the spec does say this:

           

          Call transition() on the FlowHandler, passing the current FacesContext, the current flow, the new flow and the facesFlowCallNode corresponding to this faces flow call 

           

          But it only applies once a navigation case has been identified (i.e. after the node algorithm).

          Spec needs a update, in my opinion along with the Abandoned Flows issue.
           

          volosied Volodymyr Siedlecki added a comment - I've manged to create a fix without creating regressions.  The fix needed a few parts to it: Only applies if we are not in a flow and are about to enter one. Transition Marker since we if transition early, we shouldn't transition into the same flow again Reordering of the flow node checks The previous order was SwitchNode, FlowCallNode, MethodCallNode, ReturnNode, and ViewNode. However, the spec (section 7.4.2.1in the original JSF 2.2 document), listed: ViewNode, SwitchNode, MethodCallNode, FlowCallNode, ReturnNode. I think neither of these are correct. Myfaces encounters this WELD error and spec doesn't mention the flow transitions explicitly in this node algorithm, and this is required since some nodes, such a a switch node, can reference flowscoped beans or the flowScope implicit object. If we don't transition, we will encounter this weld error with the use of CDI. The new order is now: ViewNode, ReturnNode, transition if not in a flow, FlowCallNode, SwitchNode, MethodCallNode. The order of the last three don't really matter, in my opinion.  The last two can contain EL expressions, which could reference a flow scoped object. View Nodes won't contain EL so it's not necessary to transition at this point. If the node is return node, then you're already in a flow and are trying to exit.  FlowCallNode is a bit tricky since we call "navigationContext.addTargetFlow(sourceFlow, currentFlow, null);" when startFlow is true. This would mean we need to skip the second transition, if it's created (ie. second flow references a switch / method node) I say skip second transition because applyFlowTransition loops thorough navigationContext.getTargetFlows() and there could be multiple.  Speaking of applyFlowTransition, the spec does say this:   Call transition() on the FlowHandler, passing the current FacesContext, the current flow, the new flow and the facesFlowCallNode corresponding to this faces flow call    But it only applies once a navigation case has been identified (i.e. after the node algorithm). Spec needs a update, in my opinion along with the Abandoned Flows issue.  

          People

            volosied Volodymyr Siedlecki
            volosied Volodymyr Siedlecki
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: