[
https://issues.apache.org/jira/browse/MYFACES-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683097#comment-17683097
]
Volodymyr Siedlecki commented on MYFACES-4553:
----------------------------------------------
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:
{code:java}
Call transition() on the FlowHandler, passing the current FacesContext, the
current flow, the new flow and the facesFlowCallNode corresponding to this
faces flow call {code}
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.
> TCK spec/flows/intermediate failure: WELD-001303: No active contexts for
> scope type jakarta.faces.flow.FlowScoped
> -----------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-4553
> URL: https://issues.apache.org/jira/browse/MYFACES-4553
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 4.0.0-RC4
> Reporter: Volodymyr Siedlecki
> Priority: Major
> Attachments: faces_flows_intermediate_web.war
>
>
> {color:#0e101a}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.|https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/flow/cdi/FlowScopeContext.java#L105]
> {color}
>
> {color:#0e101a}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:
> {color}
> {color:#0e101a}Application Switch Case: {color}
> [{color:#4a6ee0}[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]{color}]
>
> {color:#0e101a}MyFace Switch Case Check: {color}
> [{color:#4a6ee0}[https://github.com/apache/myfaces/blob/8956fd167f797a4e32511e268a6520715cb132a5/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java#L645]{color}]
>
>
> {color:#0e101a}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|https://github.com/apache/myfaces/blob/8956fd167f797a4e32511e268a6520715cb132a5/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java#L368]
> (which is much later). {color}
>
> {color:#0e101a}My only idea is to force a transition call before we check the
> nodes, which causes myfaces unit test failures.
> {color}
> {color:#0e101a}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.{color}
>
> {color:#0e101a}Unit Test Code:{color}
> *{color:#0e101a}spec/flows/intermediate:{color}*
> {color:#0e101a}Test:
> {color}[{color:#4a6ee0}[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]{color}]
> {color:#0e101a}
> {color}[{color:#4a6ee0}[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]{color}]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)