[JAVASERVERFACES_SPEC_PUBLIC-1342] Support @Inject of current flow like "@Inject Flow currentFlow" Created: 12/Dec/14  Updated: 10/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI Conversation scope is injectable into @ConversationScoped beans like this:

@Inject
Conversation currentConversation

The same should be true for the current Flow for @FlowScoped beans.






[JAVASERVERFACES_SPEC_PUBLIC-1265] Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow. Created: 07/Feb/14  Updated: 04/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3130 NavigationHandlerImpl differs from sp... Closed

 Description   

Consider this spec text, from section 7.4.2:

If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than ViewNodes".

That text only pertains to navigation within a flow. This restriction must be explicitly called out.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1398] Cleanup for unused Flows Created: 16/Aug/15  Updated: 01/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2, 2.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One thing missing from the faces flow spec that exists with @ConversationScoped are access timeouts after which the current scope is invalidated and destroyed.

Consider the case where a flow is not exited through the flow return, but instead simply abandoned by the user (via the back button, bookmarks or after closing a window). In this case the flow scoped beans will stay in the session, until the session is destroyed. In a web application with flows that is used intensively by its users for a long time it's easily possible that 100s of flow instances stay in the session before they are cleaned up and thus wasting a lot of memory.

To solve this problem either

  • a timeout could be introduced - similar to Conversations. This timeout could be specified for all flow as a web context param or on a flow level in the flow definition.
  • or alternatively a maximum of client window instances per flow could be set globally (implemented like ViewMaps by a LRU Map).


 Comments   
Comment by lu4242 [ 01/Sep/15 ]

Implemented in MyFaces. See: https://issues.apache.org/jira/browse/MYFACES-3938





[JAVASERVERFACES_SPEC_PUBLIC-1374] Disable client window through parameter Created: 18/May/15  Updated: 18/May/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Xavier Dury Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When exiting a flow, I sometimes need to redirect the user to some page where the client window id is not relevant anymore. It would be nice if the jfwid parameter could be dropped by simply adding "disable-client-window=true" in the url.

flowBuilder.returnNode("returnFromFlow").fromOutcome("/index.xhtml?faces-redirect=true&disable-client-window=true");





[JAVASERVERFACES_SPEC_PUBLIC-1373] @FlowScoped should be allowed on method and annotation Created: 14/May/15  Updated: 14/May/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Xavier Dury Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, @FlowScoped annotation can only target types. This makes it impossible to create flowscoped beans through @Produces methods or use @FlowScoped on a @Stereotype annotation.






[JAVASERVERFACES_SPEC_PUBLIC-1375] Faces Flows CDI Bean Defining Annotations Clarification Created: 19/May/15  Updated: 02/Jul/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: wtlucy Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Faces Flow annotation @FlowScoped is clearly defined as a CDI scope. In the CDI spec, however, it's not defined as a "bean defining annotation" http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations

The default bean discovery mode is "annotated", so it seems that with the default CDI configuration @FlowScope beans aren't discovered. The beans are discovered correctly with a bean-discovery-mode="all", which is set via beans.xml

Is it desirable to require this kind of explicit configuration, which can possibly lead to confusion?



 Comments   
Comment by wtlucy [ 02/Jul/15 ]

I've misunderstood the issue here. @FlowScoped is, in fact, a "bean defining annotation" as per the mentioned CDI spec: it falls under the "all other normal scope types" category. From the FlowScoped annotation documentation http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html :

@NormalScope
@Inherited
@Documented
@Target(value=TYPE)
@Retention(value=RUNTIME)
public @interface FlowScoped

So, explicit configuration of the CDI bean-discovery-mode should not be required.





[JAVASERVERFACES_SPEC_PUBLIC-1371] 11.4.3.3 (Packaging Flows in Directories) ambiguity Created: 04/May/15  Updated: 02/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3883 faces flow "containing directory" con... Open

 Description   

SH> The relevant spec is JSF 2.2 11.4.3.3 (Packaging Flows in Directories): there it says "The following conventions apply to
SH> flows defined in this manner. Any flow definition in the
SH> corresponding -flow.xml
SH> file will override any of the conventions in the case of a conflict.
SH> Every vdl file in that directory is a view node of that flow.
SH> The start node of the flow is the view whose name is the same as the name of the flow.
SH> ..."
SH> (note the ambiguity - "Every vdl file in that directory" ... which directory?)

EB> "that directory" is the directory containing the corresponding
EB> -flow.xml file. For example, in the case of the following
EB> convention match, "bounded-task-flow/bounded-task-flow-flow.xml",
EB> "that directory" is "bounded-task-flow/".



 Comments   
Comment by Ed Burns [ 05/May/15 ]

Ok, I looked at the built multipagewebinf WAR and see the following
files:

Archive: ./dist/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/jsf_flows_multipagewebinf_web.war
testing: META-INF/ OK
testing: META-INF/MANIFEST.MF OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/classes/com/ OK
testing: WEB-INF/classes/com/sun/ OK
testing: WEB-INF/classes/com/sun/ts/ OK
testing: WEB-INF/classes/com/sun/ts/tests/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/FlowBean.class OK
testing: WEB-INF/bounded-task-flow/ OK
testing: WEB-INF/bounded-task-flow/bounded-task-flow-flow.xml OK
testing: WEB-INF/beans.xml OK
testing: bounded-task-flow/ OK
testing: bounded-task-flow/bounded-task-flow.xhtml OK
testing: bounded-task-flow/next_a.xhtml OK
testing: bounded-task-flow/next_b.xhtml OK
testing: index.xhtml OK
testing: nonFlow.xhtml OK
testing: return1.xhtml OK
testing: WEB-INF/web.xml OK

This is indeed strange that there is both a

testing: WEB-INF/bounded-task-flow/ OK

and a

testing: bounded-task-flow/ OK

directory. The spec doesn't say what to do in that case, but it is
clear that in this specific case MyFaces is behaving correctly while
Mojarra is not.

Comment by ren.zhijun.oracle [ 02/Sep/15 ]

Hi Ed,

Can you make this more clear to me? you mean the work flow can be defined both under webapp / directory and WEB-INF/ and that defined in the webapp / should take higher priority, right? what's the current behavior of Mojarra?

BR,
Zhijun





[JAVASERVERFACES_SPEC_PUBLIC-1354] Allow specify node-on-return in flow call node Created: 23/Jan/15  Updated: 23/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Martin_Svihlik Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Nested flow has to know where to go (name of node in calling flow) when returning back to calling flow.
To encapsulate nested flow we should allow to specify node where to go after return from nested flow in the flow-call-node.

Conversation from another Jira issue:
Ed>You mean you'd like the "where to go after return" to be specified in
Ed>the flow-call node? That's not a bad idea. I can see adding that,
Ed>making it trump whatever value is returned from the called flow. Would
Ed>that satisfy?

Yes, that would be great. The nested flow would be encapsulated and it wouldn't have to know anything about calling flow's node names. It would be like when calling nested flow - you specify nested flow name, but not node name in nested flow.






[JAVASERVERFACES_SPEC_PUBLIC-1253] Consider enabling abandoning a flow directly for another flow Created: 17/Jan/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    

 Description   

Consider an app with this arrangement.

src/main/webapp/WEB-INF/faces-config.xml
src/main/webapp/flowA/flowA-flow.xml
src/main/webapp/flowA/flowA.xhtml
src/main/webapp/flowB/flowB-flow.xml
src/main/webapp/flowB/flowB.xhtml
src/main/webapp/flowC/flowC-flow.xml
src/main/webapp/flowC/flowC.xhtml
src/main/webapp/index.xhtml
src/main/webapp/site-template.xhtml

All .xhtml pages in this app are template clients of
site-template.xhtml. The site-template.xhtml has a row of buttons along
the top that allow immediate navigation to all of the flows. The intent
is that whatever flow you're in, you want to abandon it and enter the
new flow when the corresponding button is clicked. This is not a flow
call, but rather should be treated as an atomic "abandon/enter".

The current specification does not support this cleanly.



 Comments   
Comment by Ed Burns [ 17/Jan/14 ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 ]

zip of reproducer.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1246] Prevent jumping into a flow without going through the front door. Created: 27/Dec/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

RS> One observation is with regards to access to flow scoped data. When
RS> using the provided buttons, everything works as it should, i.e. flow
RS> scoped data is created at the point of entering the flow and
RS> destroyed when the flow is exited. However, it is easy to bypass the
RS> entry and exit points. For example I can go directly to a page
RS> associated with a flow without entering the flow, and if the page
RS> tries to access flow data, the result would be
RS> ContextNotActiveException.

One could argue that such an exception is the right response. The
context is indeed not active. However, if you are not using any flow
scoped data, such an exception would not be thrown, and it would give
the impression that the navigation is supported.

I think we can add some language to the spec to detect these "jump in"
cases.



 Comments   
Comment by Ed Burns [ 27/Dec/13 ]

Rossen wrote:

When flows are defined under the web application's root, I can easily access
their source from a browser which is a security concern. I can see there is
an example that puts the flow definition under WEB-INF but the pages are
still under the web application root and hence the flow is in two different
places. It would be useful to be able to keep a flow with all its files in a
folder under WEB-INF.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1247] Disable implicit navigation within flows on a per-flow basis. Created: 27/Dec/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The ease of use of implicit navigation can be a boon for quick development, but it can also make it difficult to reason about flows when they get more complex. Consider adding a configuration element that disables implicit navigation in a flow.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1189] Flow identifier in @FlowDefinition Created: 29/Apr/13  Updated: 11/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arungupta Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat

 Description   
@Produces @FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
    String flowId = "flow1";
    flowBuilder.id("unique", flowId);
    flowBuilder.viewNode(flowId, "/" + flowId + "/" + flowId +  ".xhtml").markAsStartNode();
    return flowBuilder.getFlow();
}

can be simplified to:

@Produces @FlowDefinition("flow1")
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
    ...
}


 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1219] Specify behavior in case of abandoned flow. Created: 26/Aug/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 6 hours
Time Spent: Not Specified
Original Estimate: 6 hours

Issue Links:
Dependency
depends on JAVASERVERFACES-2997 None flow command actions navigation ... Closed

 Description   

Currently trying to navigate away from a flow by any means other than a flow-return or flow-call node will cause the navigation to silently fail. This approach has the nice property in that it prevents abandoned flows. Unfortunately, as JAVASERVERFACES-2997 shows, this approach is overly restrictive.

This issue calls for the spec to say what should happen when the flow is abandoned.



 Comments   
Comment by Ed Burns [ 26/Aug/13 ]

The fix for JAVASERVERFACES-2997 did the following.

When looking for a navigation match in the midst of the flow, if no other way of finding a match is found, look for an implicit match outside of the flow. If that's not found, look in the root navigation map using the same three step process in normal JSF navigation.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1232] Support for a Flow to start from direct URL path access Created: 28/Oct/13  Updated: 05/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Support for a flow to start when user directly access the flow path from an URL.

If a user points to http://server/app/flow-folder/ the implementation throws an exception saying it couldn't find an index.xhtml page.

Right now, the only way to start a flow is by having the user accessing another page before, outside of the flow, and then an action to the flow (either by link, button, or some javascript to automatically click on something).



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1173] Handle gracefully the case of a link to flow based page copied to new browser tab Created: 16/Mar/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

> LU> Hi
> LU> I have been checking the proposal for OutcomeTarget navigation in deep. In few
> LU> words, the critical point is what clientWindowTransition() should do and how
> LU> to encode GET links properly.
>
> LU> Let's consider again this use case :
>
> LU> (suppose the flow document id is flowDoc2)
>
> LU> <faces-flow-definition id="flow2">
> LU> <flow-return id="exit2">
> LU> <navigation-case>
> LU> <from-outcome>exit1</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> (suppose the flow document id is flowDoc1)
>
> LU> <faces-flow-definition id="flow1">
> LU> <flow-return id="exit1">
> LU> <navigation-case>
> LU> <from-outcome>mainpage</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> Suppose we are in /flow2/mypage.xhtml and there is a link to exit the flow. How
> LU> it should looks like? according to what I can deduct from the spec it should
> LU> be something like this:
>
> LU> http://localhost:8080/myapp/mainpage.xhtml?jffi=exit2&jftfdi=flowDoc2
>
> LU> In theory the link should work as long as the flow stack is:
>
> LU> flow2
> LU> flow1
> LU> root
>
> LU> But what happen if I copy the link into a new browser tab?
>
> That is not supposed to work because, by definition, the flow system is
> entirely built on ClientWindow, which, by definition is bound to a
> browser view (such as a tab or window).
>

Yes, I know it does not work, it should not work, but the problem is how faces
flow fails under such circumstance.

When this could happen? a session expiration is a good example. Since there
is no ViewState, there will not be ViewExpiredException, and the link will be
sent by the user without notice.

The point is if that scenario happens (which is probably), faces flow should be
able to recognize the situation with a simple check and do something like
throw an exception or exit the flow.

Other situation when this is relevant is what happen if you hit the same link
twice. The first time it gets out of the flow, but the second time you
are already
out. Again it is up to the user detect that kind of failure doing its
own logic to
check if the request is valid, but faces flow could do it for you just checking
one query param.

In a previous conversation, it was mentioned that "... a flow has a single front
door ..." and that it has "... well defined entry and exit points
...". My concern
here is that theorically it is possible to enter into a flow without go through
the start node, and there are simple exit cases with "unknown" results.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1188] Specify what should happen if the same flow is defined both in XML and via @FlowDefinition Created: 29/Apr/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The spec for FlowHandler.addFlow() requires an IllegalStateException be thrown if there is already a flow with the same identification as the one trying to be added.

The spec does not say the ordering in which flows should be added

XML then Java
Java then XML

This needs to be clarified.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





Generated at Fri Dec 09 23:42:56 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.