If this decision is running synchronously with a JSF request, the contexts are shared with the request, so all those components will be just the same as normal.
in a request, a task-node get's transitioned to decision handler which transitions to this decision handler.
task -> decision handler 1 -> decision handler 2
So specifically, what I am after is what do I know I can use these components for in decision handler 2? Yes, we get to decision 2 from a JSF click. We should know the task id...
A quick test of a few components shows that when DecisionHandler invokes the desired method, we have the following:
16:42:33,228 INFO com.evergreen.accesscontrol.impl.WorkItemManagerBean - jbpmContext -> org.jbpm.JbpmContext@52438 16:42:33,228 INFO com.evergreen.accesscontrol.impl.WorkItemManagerBean - processInstance -> null 16:42:33,228 INFO com.evergreen.accesscontrol.impl.WorkItemManagerBean - businessProcess -> BusinessProcess(processId=null,taskId=null)
I would think it's fair to have the processInstance that a DecisionHandler belongs to be in scope - it's not - so now I have to figure out how to resolve this in the EJB method call - or, again, write a custom DecisionHandler and use the executionContext.getProcessInstance() method to achieve the same, but then this means I'll probably want to move all the logic from the EJB into the DecsionHandler impl and then the expression technique isn't so useful here again.
I don't understand why you don't call BusinessProcess.instance().setProcessId(....) before doing any work with jBPM.
I thought we already discussed this in the previous thread?
I don't understand why you don't call BusinessProcess.instance().setProcessId(....) before doing any work with jBPM
Hey - go easy on me ;-) - BusinessProcess isn't well explained or discussed in the documentation so its taking a while for this stuff to sink in. This is in contrast to, say... conversation state, which is discussed in depth and repeatedly in the docs.
I will try the approach you're suggesting above.