Announcement Announcement Module
No announcement yet.
flowExecutionUrl and manually handled view-states Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • flowExecutionUrl and manually handled view-states

    Hello everyone,

    I've got an issue using the ${flowExecutionUrl} variable. It seems that I can't use it to resume a view-state which have been "manually handled" (by writing directly to the HttpServletResponse object).

    My setup is as follow: I have two flow: a root flow, and a subflow. A plain execution path will be:
    Root flow:
     Action State 1
     Intro view state
     Action State 2
     Subflow-state -> Call to our subflow
     Action state 3
     View state -> Not a plain view: we directly write to the HttpServletResponse, notifying the ExternalContext when we're done.
          | -> The client is redirected to an external website, and he's coming back using the ${flowExecutionUrl} with a custom _eventId.
     Action State -> PROBLEM: the client never reach this state. Instead, he's landing again on the "Intro View state" of the root flow.
    This is how the view-state writing to the HttpServletResponse looks like:
    <view-state id="MySubflow">
    <!-- NB: we can't use on-render here since we don't have any facelet associated -->
      <!-- Writing to the HttpServletResponse occurs here. -->
      <evaluate expression=", flowExecutionUrl)"" />
     <transition on="userReturn" to="resumeFlow" />
    public String run(RequestContext reqCtx,  String flowExecutionUrl){
    	ExternalContext extCtx = reqCtx.getExternalContext();	
    	HttpServletResponse res = (HttpServletResponse) extCtx.getNativeResponse();	
        // [...] Do something with res
        return "success";
    The flowExecutionUrl is unchanged since the start of the root flow, it's always: "/webapp/RootFlow?execution=e1s1", and bring the client back at the beginning of the process, even if he was already in the subflow.

    On the other hand, if the subflow does not write to the request directly, but use a facelet instead... then the flowExecutionUrl is updated (changed to "e1s2"), and bring the client back into the subflow, as expected.

    I hope this is clear enough... Does someone know if there is a way to do what I'm attempting here? Or it is some kind of natural limitation of the flowExecutionUrl? Do I have to create a dummy view-state with a facelet associated to force SWF to resume in the subflow?

    Any feedback much appreciated.

    P. M.

  • #2
    More input...

    I've figured out part of the problem...

    As stated in this old thread, the _eventId is not used with spring-faces, but only with the plain jsf-spring integration. The same thread is giving a custom phase listener in order to re-recreate this behavior... but it don't seems to work.

    The Phase listener is called, the eventId retrieved from the request and queued, but the view transition does not occurs for some reason...


    • #3
      Hi everyone,

      i am having the same problem. the _event paramter is ignored when not sent from a jsf form....
      Why is that? and will there be a patch for this problem? And if not, could anyone provide an example on how to include a working custom phase listener that provides a workaround for this problem?
      As the solution proposed here does not work for me. i am using SWF 2.2.0


      Last edited by cmon; Dec 7th, 2010, 06:47 AM. Reason: additional info