I just commited LinkDependencyTest to illustrate (failing). Feel free to tell me what is wrong.
are links scoped ? if yes, you should use a class that inherits from ExecutionScope to maintain the link statusses instead of a static test member.
in that case, you're closer to the real implementation. i don't yet have time to dig into the problem.
probably i will have time this week to implement a flow example.
Links are not yet scoped. But this is not the problem I want to illustrate in LinkDependencyTest. If this test is not executes twice in the same time there would not have any problem with links. The problem is How to wake up the execution sleeping due to the Target statement ?
This execution was passivated (NodeResult.WAITING). Once the source is executed, I want to wake up this execution so I tried to call signal on it but this causes the following problem :
org.jbpm.JbpmException: Execution(f_s_b) is locked
My question is : what is the correct way o wake up a sleeping execution ? I.e. making the execution executing execute method or signal.
I think this feature is very important as it allows to well understand PVM.
In addition this is a blocking issue for me... So maybe I can dig into PVM to understand what is wrong (in my test or in PVM) and find a fix ?
What do you think ?
Can you give me a first direction to help me ?
I just found a solution to make the LinkDependencyTest successful.
I still have a problem : the only way I found to wake up the execution was to call signal.
Is there a way to make the pvm calling once more execute method ? This could be a good feature to avoid duplicating code.
here are some rough guidelines
Check out the current methods on the Execution and ExecutionController
The idea is that NodeBehaviour implementations can/should use the ExecutionController methods.
If you call as an external client, then you need to call the Execution methods.
If a node behaviour is operating on another execution (not the current running execution) then the node behaviour is also allowed to call the external execution methods (as defined in class Execution) on that other execution.
i should be able to have a closer look tomorrow morning. in the meantime. think about how you would make it work and compare it to what is there...
charles, i'm deleting your flow test as i'm restructuring all the concurrency tests.
keep a copy (or fetch from svn) if you want to re-introduce it later.
I want to build up the test suite systematically. One step at a time and get a good coverage over all the techniques that are offered and how they are used for implementing process language features.
The flow as you build it doesn't fit in there at the moment. Since it is a sophisticated case of a flow. I want to start with first doing child node execution, then some variations. And maybe in the end arrive in the kind of complex scenarios of like you have build.
The test suite i'm building out now is not a POC. I want to go step by step. And include as many variations as i can on basic concepts.
In case of your flow, I'm not yet sure wether it belongs in pvm or in bpel codebase. PVM should be for showing all the concepts that process languages need. The process languages themselves will combine all the basic concepts to implement the features. Your test is somewhere in the middle. That is why I want to remove it for now and start from the ground up.
also, tests shouldn't really take into account all the edge cases. e.g. you can assume that there will always be nested nodes present.
it's up to the process languages to define how they want to handle those edge cases.
that makes the tests more readable