Norman Richards [06/May/08 02:34 PM]  We can add to the APIs, but I'm curious how the user would signal the process and whether whether or not we need to flush the business process context? Is there any reason you can't simply create the process and just call BusinessProcess.setProcessId()?

Alejandro Guizar [08/May/08 01:16 AM] The user could signal the newly created process by calling BusinessProcess.transition() once any custom initialization activities have been performed. You can certainly create the process by hand as the user did (see the case), but it feels dirty. Instead of the new method I proposed earlier, it'd be good that jBPM and Seam had consistent process creation behaviors. It'd be less surprising for our users who are familiar with both products. We can choose to signal on creation or not, but we should do it consistently. There is one advantage to not signaling. If you do not require initialization, you can always signal immediately: Seam: businessProcess.createProcess("my proc"); businessProcess.transition("go"); jBPM: jbpmContext.newProcessInstance("my proc").signal("go"); With signal on creation, there is no way to perform any initialization.

Norman Richards [08/May/08 11:07 AM] Seam does do initialization. It dumps all the business process scoped data into the process.

Norman Richards [08/May/08 11:12 AM] I think the real sticky point here is in providing functionality on the component that isn't exposed via annotations or any of our other process control mechanisms. I really don't understand the use case well enough to know if we need to expose any of this behavior or to understand the implications in a Seam app of the user manually mucking with the process. Certainly Seam cannot mirror every piece of JBPM functionality and at some point if the user needs to do something really tricky they should probably be doing it themselves. Since you seem to think this is definitely something that needs to happen, I'll add the method in.

Norman Richards [08/May/08 02:39 PM] It would be nice to get some feedback on whether or not the end result is what is expected.

Alejandro Guizar [08/May/08 09:21 PM] I appreciate your quick response to this case. I just took a look at your additions [1]. I believe the user will find the addition useful. On the other hand, you raise a valid point: the new functionality is not exposed via annotations, which will limit the value of the addition for other Seam users. Given this limitation, I thought of a different solution which I'd like you to consider. a) Forget about BusinessProcess.createProcess(String, boolean) b) Have BusinessProcess.createProcess(String) and BusinessProcess.createProcess(String, String) *never* signal. => This would give processes in Seam the option to remain in the start-state, as in vanilla jBPM <= c) Add an optional element "shouldSignal" to @CreateProcess, defaulting to true. BusinessProcessInterceptor.afterInvocation() would incorporate the additional element as follows.             CreateProcess tag = method.getAnnotation(CreateProcess.class);             if ( tag.processKey().equals("") )             {                BusinessProcess.instance().createProcess( tag.definition() );             }             else             {                BusinessProcess.instance().createProcess( tag.definition(), getProcessKey( tag.processKey() ) );             }             if ( tag.shouldSignalProcess() )             {                ProcessInstance().instance().signal();             } What do you think? [1] http://fisheye.jboss.com/changelog/Seam/?cs=8143