L3 - Default see which parts of the implementation of CAM-3453 and the likes should be pushed further into the PVM and make certain code parts obsolete (e.g. pvm atomic operation that creates concurrent executions)
Further refactorings to consider that are now hacked around in the modification command:
- PvmExecutionImpl#cancelScope should leave the current activity instance when the 'this' execution actually executes an activity
- non-leaf executions should never have a non-null activity id; this is currently not the case for parallel gateway forks; furthermore, code in ScopeUtil relies in part on the activities of executions but appears to not very robust
- ScopeUtil#findScopeExecutionForScope MUST be fixed or else you cannot reliably start activities in a transaction subprocess; cf test case org.camunda.bpm.engine.test.api.runtime.ProcessInstanceModificationEventTest.FAILING_testStartBeforeCancelEndEventConcurrent
Especially for the second idea, we have to ensure backwards compatibility
This is the controller panel for Smart Panels app
[CAM-3580] Consolidate process instance modification implementation and PVM
| Rank | New: Ranked higher |
| Description |
New:
see which parts of the implementation of |
| Description |
Original:
see which parts of the implementation of |
New:
see which parts of the implementation of Further refactorings to consider that are now hacked around in the modification command: * PvmExecutionImpl#cancelScope should leave the current activity instance when the 'this' execution actually executes an activity * non-leaf executions should never have a non-null activity id; this is currently not the case for parallel gateway forks; furthermore, code in ScopeUtil relies in part on the activities of executions but appears to not very robust Especially for the second idea, we have to ensure backwards compatibility |
| Description |
Original:
see which parts of the implementation of Further refactorings to consider that are now hacked around in the modification command: * PvmExecutionImpl#cancelScope should leave the current activity instance when the 'this' execution actually executes an activity * non-leaf executions should never have a non-null activity id; this is currently not the case for parallel gateway forks; furthermore, code in ScopeUtil relies in part on the activities of executions but appears to not very robust Especially for the second idea, we have to ensure backwards compatibility |
New:
see which parts of the implementation of Further refactorings to consider that are now hacked around in the modification command: * PvmExecutionImpl#cancelScope should leave the current activity instance when the 'this' execution actually executes an activity * non-leaf executions should never have a non-null activity id; this is currently not the case for parallel gateway forks; furthermore, code in ScopeUtil relies in part on the activities of executions but appears to not very robust * ScopeUtil#findScopeExecutionForScope MUST be fixed or else you cannot reliably start activities in a transaction subprocess; cf test case org.camunda.bpm.engine.test.api.runtime.ProcessInstanceModificationEventTest.FAILING_testStartBeforeCancelEndEvent Especially for the second idea, we have to ensure backwards compatibility |
| Description |
Original:
see which parts of the implementation of Further refactorings to consider that are now hacked around in the modification command: * PvmExecutionImpl#cancelScope should leave the current activity instance when the 'this' execution actually executes an activity * non-leaf executions should never have a non-null activity id; this is currently not the case for parallel gateway forks; furthermore, code in ScopeUtil relies in part on the activities of executions but appears to not very robust * ScopeUtil#findScopeExecutionForScope MUST be fixed or else you cannot reliably start activities in a transaction subprocess; cf test case org.camunda.bpm.engine.test.api.runtime.ProcessInstanceModificationEventTest.FAILING_testStartBeforeCancelEndEvent Especially for the second idea, we have to ensure backwards compatibility |
New:
see which parts of the implementation of Further refactorings to consider that are now hacked around in the modification command: * PvmExecutionImpl#cancelScope should leave the current activity instance when the 'this' execution actually executes an activity * non-leaf executions should never have a non-null activity id; this is currently not the case for parallel gateway forks; furthermore, code in ScopeUtil relies in part on the activities of executions but appears to not very robust * ScopeUtil#findScopeExecutionForScope MUST be fixed or else you cannot reliably start activities in a transaction subprocess; cf test case org.camunda.bpm.engine.test.api.runtime.ProcessInstanceModificationEventTest.FAILING_testStartBeforeCancelEndEventConcurrent Especially for the second idea, we have to ensure backwards compatibility |