> rallen is correct. The process instance is stale at that point and doesn't reflect the latest state of things.
I agree, but the method name is confusing and made me think it will work this way. I'm not familiar with the internals of the framework, but dummy search for references on method end() of the ExecutionEntity type found two places where it is used: TerminateEndEventActivityBehavior#execute and NoneEndEventActivityBehavior#execute. Again, I may be wrong, but shouldn't this set associated process instance ended value to true when end activity is reached inside a process?
> I'm not sure about the use case. The signal event, as per the spec, is caught by a boundary event (or intermediate) that is waiting for it. Propagating it would be confusing. But I'm not yet following your use case. Could you elaborate on the business use case for it?
In case when you have a complex hierarchy of the process definitions. In those cases it is more appropriate to use CallActivity instead of a SubProcess element in order to make process definitions smaller and easier to read. It also allows you to reuse them as part of the other processes or run them independently. In my particular situation I'm catching the same signal in multiple child processes and react on them. In order to do it, I need to get the execution id of every process instance of that hierarchy which is not a simple task. Passing some unique identifier (like business key or master process instance id) as a variable can be a solution, but it requires some manual intervention. I'm fine with this solution, but I was just wondering could it be little more elegant.