Flow design incorrectly allows re-entrancy for @FlowScoped beans

[eclipse-faces-bot]

Taken from JAVASERVERFACES-3680

Consider having some flows in application, for example PersonListFlow,
PersonDetailFlow, AddressDetailFlow

Example:

1. enter person list - flow PersonListFlow

2. enter person detail - flow PersonDetailFlow

3. enter address detail - flow AddressDetailFlow

4. go to another person living on the same address -> flow
   PersonDetailFlow. Flow stack would be:

PersonListFlow
PersonDetailFlow
AddressDetailFlow
PersonDetailFlow

Problem there is that FlowScoped ManagedBean is created for flow ID
"PersonDetailFlow" and is shared with two instances of PersonDetailFlow
in flow stack. In other words, data would be shared and after returning
to first flow PersonDetailFlow instance they will be corrupted for the
first person.

Affected Versions

[2.2]

[eclipse-faces-bot]

@glassfishrobot Commented
Reported by @edburns

[eclipse-faces-bot]

@glassfishrobot Commented
Issue-Links:
is related to
JAVASERVERFACES-3680

[eclipse-faces-bot]

@glassfishrobot Commented
martin_svihlik said:
Hi Ed,
What an elegant sollution using stack depth.

When I was reading your code I noticed new method getCurrentFlowDepth was created. I tried to do something simmilar about two months ago when I wanted to determine that I am back in the first flow of application (that I returned from all the nested flows back to the "root" flow). I noticed that when going back from nested flow's return node to method call node in calling flow, the method call node was executed with the nested flow still on the stack. The flow was removed from stack after entering VIEW node.

That means that when having stack F1->F2->F3 and going F3->F2->F1->F2 the stack in method call node invoked in F1 when returned from F2 would be still F1, F2, F3.

I know that many improvements were made on FacesFlows lately, I just wanted to point out that observation. Maybe it is not an issue after many fixes that were made on Faces Flows.

With regards,
Martin

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
The spec should be modified to state that transitions of the sort mentioned in this issue are valid and that the @FlowScoped CDI context/extension instance needs to take that into account. Also add to the spec that when replacing (rather than decorating) the FlowHandler, one must also replace the @FlowScoped CDI context/extension. The technique of doing this replacement is still an open question.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Mark Struberg suggests this open question is handled by https://issues.jboss.org/browse/CDI-157.

[eclipse-faces-bot]

@glassfishrobot Commented
File: changebundle.txt
Attached By: @edburns

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:

What an elegant sollution using stack depth.

That was Zhijun's idea, and it is what I recommend for JAVASERVERFACES-3680, but without the API change.

Ed

[eclipse-faces-bot]

@glassfishrobot Commented
Marked as fixed on Thursday, February 12th 2015, 2:54:09 pm

[eclipse-faces-bot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1361

[eclipse-faces-bot]

• Issue Imported From: Flow design incorrectly allows re-entrancy for @FlowScoped beans javaee/javaserverfaces-spec#1361
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @edburns
• Original Issue Closed By:@glassfishrobot