-
1. Re: current activity of execution
jbarrez Jul 9, 2009 4:45 AM (in response to camunda)Bernd,
An execution can be anywhere in the tree of executions. So for some executions, the getActivityName() makes sense (eg sequential process) but for others (eg root execution with forked child executions), it doesn't (which should it return?).
So that's why the only operation that is exposed is the findActiveActivityNames(), which will give you one value (eg the sequential case) or multiple (eg the forked case where the method is called on the root).
The getActivityName() operation is only used internally, where we can be really sure of its usage. -
2. Re: current activity of execution
camunda Jul 9, 2009 5:31 AM (in response to camunda)and the logic of the root execution ahs changed compared to jbpm 3 tokens (where the root token just remained in the fork) I guess?
-
3. Re: current activity of execution
tom.baeyens Jul 9, 2009 6:18 AM (in response to camunda)this is what i added to the migration docs especially for you :-)
The root execution is now the same object as the
process instance. (In jBPM 3, the ProcessInstance had
a pointer to the root token). Also, unlike in jBPM 3, executions in jBPM 4 might
get inactivated, create a child execution and let the child execution continue, even
when logically this represents only one single path of execution. This happens in
scope activities (or composite activities) that have timers or variables declared. -
4. Re: current activity of execution
camunda Jul 10, 2009 4:39 AM (in response to camunda)Okay, I should RTFM ;-)
But still, this doesn't lead to a problem with the getActivityName, or? If I am in a composite, the root execution may be in the scope/composite state, and the child in the "real" state. -
5. Re: current activity of execution
tom.baeyens Jul 10, 2009 9:28 AM (in response to camunda)for the record: i wasn't spanking you. (at least not this time:-) i added that to the docs because you pointed out a hole in the docs. thanks !
But still, this doesn't lead to a problem with the getActivityName, or? If I am in a composite, the root execution may be in the scope/composite state, and the child in the "real" state.
exactly. the parent execution will have as execution state Execution.STATE_INACTIVE_CONCURRENT_ROOT and it should still point to the scope/composite activity. the leaves point to the real activity.
the difference with before is that each activity that has variables or timers declared on it, will also create a child token. the parent execution will be in state STATE_INACTIVE_SCOPE and the (single) child will be in state STATE_ACTIVE_ROOT
in that case the parent execution will be in state -
6. Re: current activity of execution
camunda Jul 16, 2009 3:59 AM (in response to camunda)Okay, but I want to persist the question: Why it is a problem to query the activity name then? I always can give an answer here (from the PVM/API perspective). It may be not that easy to interpret, but thats a different page...
-
7. Re: current activity of execution
jbarrez Jul 22, 2009 3:13 AM (in response to camunda)You are giving the answer yourselves: it is not undoable, but it may be hard to interpret ... which leads to an api that is more difficult to use by the mainstream ;-)