-
1. Re: unstructured joins
tom.baeyens Aug 15, 2007 7:30 AM (in response to mvaldes)must have been a good lunch... if it produces this kind of after-thoughts :)
that seems indeed the best approach.
there should definitely be a getRoot() method on the execution. wether that should be based on a memberField initialized during parsing or wether that is calculated dyncamically going up the parent until it is null, that i don't know yet. -
2. Re: unstructured joins
mvaldes Aug 20, 2007 3:49 AM (in response to mvaldes)Was indeed a good lunch even if some tempranillo was missed :-)
I would like to try doing that in the parsing. This will probably save time during the execution.
regards,
Miguel Valdes -
3. Re: unstructured joins
blachonm Aug 23, 2007 8:14 AM (in response to mvaldes)I added a counter in join type nodes during parsing and initiated with the number of incoming transitions. At execution time the counter is decreased each time an execution enters the join node until it reaches 0. It works well and then avoid the getRoot() method on the execution treatment.
As it implies xpdl parsing it has been put under the xpdl bonita prototype.
http://forge.objectweb.org/plugins/scmsvn/index.php?group_id=56
under bonitaPVM tree.
junit sample test launched : SplitJoinXpdl2Test -
4. Re: unstructured joins
tom.baeyens Aug 23, 2007 8:20 AM (in response to mvaldes)a counter in a join node is wrong.
join node is static process definition information. the same object is used for all executions.
the counter is runtime information. so that is something which should go into an execution scope -
5. Re: unstructured joins
blachonm Aug 23, 2007 8:28 AM (in response to mvaldes)Yes Tom, I was aware of that. I'm going to work introducing runtime classes ..... That was just a simple test.
-