-
1. Re: task-assign event fired before task-create event
icyjamie Sep 30, 2005 2:42 AM (in response to cfau)Actually, it is implemented vice-versa (see sourcecode) and I also think create should occur before assign, otherwise you run into some causality-problem: How could you assign someone to something if it is not been notified to be created?
-
2. Re: task-assign event fired before task-create event
kukeltje Sep 30, 2005 3:35 AM (in response to cfau)you could see it the other way around ;-). IF some task is created, you at least know who to create it for. What is the use of a task that is not assigned... just joking. I agree with you
-
3. Re: task-assign event fired before task-create event
icyjamie Sep 30, 2005 4:39 AM (in response to cfau)Well, the assigned could be deferred. (Resource patterns, you know :-))
-
4. Re: task-assign event fired before task-create event
cfau Sep 30, 2005 11:17 AM (in response to cfau)Thanks folks.
I already changed the code of TaskMgmtInstance.createTaskInstance() to do the create before the assign to have "the hoped" semantics.
carlos -
5. Re: task-assign event fired before task-create event
icyjamie Feb 2, 2006 9:17 AM (in response to cfau)This is still implemented in 3.1b2. Should I report this as a bug?
James -
6. Re: task-assign event fired before task-create event
kukeltje Feb 2, 2006 12:33 PM (in response to cfau)Yes, why not. Seems reasonable to me. If Tom disagrees he'll let you know there. But your 'could be deferred' remark made me think. How should this be used? allowing an empty string as an actorID?
-
7. Re: task-assign event fired before task-create event
tom.baeyens Feb 2, 2006 2:00 PM (in response to cfau)i noticed this today myself and a jira issue is already created for it.
regards, tom. -
8. Re: task-assign event fired before task-create event
icyjamie Feb 3, 2006 1:35 AM (in response to cfau)Look at the resource patterns (on www.workflowpatterns.com .
Initially a work item comes into existence in the created state. This indicates that
the preconditions required for its enablement have been satisfied and it is capable of
being executed. At this point however, the work item has not be allocated to a
resource for execution and there are a number of possible paths through these states for individual work items.
It is not always possible to know the right actor from the beginning (even not the right pool).
Or it could be so computing-intensive that you let another thread or process handle the assignments async-like. This process could even "listen" for the created event, and queue it for pooling/assignment.
"created" should mean: the basic stuff is there, if you want to intervene, go ahead. Maybe it should have another wording in the case of jBpm, like "ready", but then we lack the "created" event, and some implementations will really need it. -
9. Re: task-assign event fired before task-create event
icyjamie Feb 3, 2006 1:36 AM (in response to cfau)damn, I meant http://www.workflowpatterns.com