create start task inconsistency

[tom.baeyens]

"Jeff" wrote:

| Start-state taskInstances are not created when the
| start-state is entered.
|
| Instead,
|
| TaskInstance taskInstance =
| taskMgmtInstance.createStartTaskInstance();
|
| must be performed by the client (the jBPM web app does this).
|
| This seems to be inconsistent, in that task-nodes create
| taskInstances if a task is specified in the task-node
| definition (and create-task is not set to false). Also
| problematic for a Seam application, in that there is not easy
| way to tell Seam that this process definition has start tasks
| and must be handled differently.
|
| However it is not clear how to fix this. Start-nodes are not
| "entered" or "executed" like other nodes, so there is no good
| place to hang the invocation to
| taskMgmtInstance.createStartTaskInstance.
|
| Thoughts?

[tom.baeyens]

That is indeed an inconsistency which is not easy to solve in the current architecture. The idea is that in jbpm 4, the architecture will change in a way that makes it easier to fix this.

Now modules are pluggable. The idea is that you can just plug in or rip out the task management module from a jbpm deployment. That is why the plain process instantiation code cannot have a direct reference to the task managment module to see if there needs a task to be created. If we want to fix this in the current architecture, we would have to expand the current event mechanism to span multiple modules. Now, events are generated in the graph and propagate to the process instance. To accomodate auto task instance creation, we would have to dispatch this event over the module instances once it arrives at the process instance level. Also we should dispatch it over the process definition and all module definitions.

This cumborsome and difficult eventing mechanism is one of the reasons why we want to go forward with a different architecture.

Modules will not be pluggable in the way they are now. A ProcessInstance will contain the plain graph execution runtime information (as now) but it will NOT contain any module instances. Instead, to add new module instances, inheritence should be used. That way, we will create a JpdlProcessInstance that contains the jPDL modules in the object model. This will remove the module instance indirection and reduce the navigation in the database, thereby significantly improve performance as well.