no, there isn't, but since the source is open, such thing could be added
i think it might be possible.
first, read the process into memory. then programmatically, you could add events to the process definition that listen for 'transition' or 'node-enter' events.
then you'll get the notifications you're looking for.
there are various ways on how to read the process into memory. so you might have to search to find the right one. also you could consider writing a process parser and configure it as a deployment phase. that would be completely transparant, but to manage the custom configurations for that is probably harder then just programmatically reading and updating the process.
hmmm.... dirty solution.... Wouldn't it be better if we just added a hook in the code where an external event-listener can be attached (configuration), or make it possible to e.g. register a global eventlistener (event='any' on the processdefinition)
Wouldn't it be better if we just added a hook in the code where an external event-listener can be attached (configuration), or make it possible to e.g. register a global eventlistener (event='any' on the processdefinition)
I believe this is all that would be necessary in the engine to also support (remote) debugging, which is a future goal for us. In other words, from a "workflow debugger UI", someone could single-step through a workflow, let it run and watch where it goes, set breakpoints in it, etc.
I always thought that relying on Hibernate to both load and manage a process definition instances was a flawed approach as you cannot do things like this. This is why jBPM is also stuck with the instance-per-request for actions.
I assume with 'process definition instances' you mean an instance of a process definition, so a 'running' one, not the definition itself.
If so can you elaborate a little more on this 'things like this' in relation to your remark about hibernate? I do not fully get what you mean by this. And when you are at it, I also do not grasp the 'instance-per-request for actions'