RC4 nightly broke my Portlet JSF integration

amy

It seems that now FlowExecution is now only visible to FlowExecutor so I can't now launch a flow and store that FlowExecution in FlowExecutionHolder as a way to pass flow to continue running to JSF integration.

I was doing this before because there is no way to set renderParameter in a portlet render an thus there was no way to pass in a flowId to jsf to have jsf launch the flow.

Please either come up with an alternate way to have JSF pick up a default flow Id per portlet or allow a mechanisim to retreive the FlowExecution from the flowExecutor FlowExecutionRepository.

Please Advise...

I'm a little confused, as the JSF integration doesn't use a FlowExecutor.

The JSF objects provide access to the FlowExecutionRepository, FlowExecutionFactory, and FlowDefinitionLocator.  You can still get at and set the flow execution in a thread-bound holder using FlowExecutionHolderUtils.  What am I missing? I need more details.

Keith

To launch a flow  JSF integration looks in request parameters to find the flow id of the flow to launch. In JSF Portlet integration flow is launched in a portlet render where setting request parameters isn't possible so before I was getting around that by launching the flow myself and sticking the FlowExecution in FlowExecutionHolder so JSF integration would skip the launch step entirely and use the existing FlowExecution. Now This is not possible since launching flow does not give me access to the flow execution.

But launching a flow does give you access to the flow execution... you have to create the flow execution, don't you...

See:Code:String flowId = argumentExtractor.extractFlowId(context);FlowDefinition flowDefinition = getLocator(context).getFlowDefinition(flowId);FlowExecution flowExecution = getFactory(context).createFlowExecution(flowDefinition);FlowExecutionHolder holder = new FlowExecutionHolder(flowExecution);FlowExecutionHolderUtils.setFlowExecutionHolder(holder, facesContext);ViewSelection selectedView = flowExecution.start(createInput(flowExecution, context), context);if (logger.isDebugEnabled()) {    logger.debug(quot;Started new flow executionquot;);}
It would be helpful for me to see the code that you're having difficulty running under 1.0 RC4 nightly.

Below is the full code that would need to be made compatible..

The section I'm currently concerned with is:
       // need the following lines to create a new flow with the defaultFlowId else there is no way to       // pass flow id to JSF integration since request parameter cannot be set in render method       JsfExternalContext context = new JsfExternalContext(facesContext);
if (startFlow || ! FlowExecutionHolderUtils.isFlowExecutionRestored(f  acesContext)) {
// we'll need a session
request.getPortletSession(true);       FlowExecution flowExecution = getRepository(context).createFlowExecution(default  FlowId);
FlowExecutionHolder holder2 = new FlowExecutionHolder(flowExecution);
FlowExecutionHolderUtils.setFlowExecutionHolder(ho  lder2, facesContext);
ViewSelection selectedView = flowExecution.start(null, context);
holder2.setViewSelection(selectedView);
holder2.markNeedsSave();
}

Now it appears I have to do following but I can't get [FLOW EXECUTION]...ResponseInstruction responseInstruction = flowExecutor.launch(defaultFlowId, context);

FlowExecutionHolder holder2 = new FlowExecutionHolder([FLOWEXECUTION]);
FlowExecutionHolderUtils.setFlowExecutionHolder(ho  lder2, facesContext);

holder2.setViewSelection(responseInstruction.getVi  ewSelection());
holder2.markNeedsSave();

You should not be using the executor there... your original code is better.  Instead of looking up the FlowExecutionRepository, you need to retrieve the FlowExecutionFactory.  In 1.0 RC4 the factory is responsible for execution creation, the repository has been freed from this responsiblity and deals soley with persistence.

Keith