[JBoss jBPM] - Re: fork and join childeren
by salaboy21
Ok, you are right.. there is something with your process definition and at first sight i don't find this error...
So when I test it in my IDE i find the problem very quickly:
This is your problem:
"<process-definition>" +
| " <start-state name=\"start\">" +
| " <transition to=\"fork1\"></transition>" +
| " </start-state>" +
| " <fork name=\"fork1\">" +
| " <transition to=\"state1\" name=\"2\"></transition>" +
| " <transition to=\"state2\" name=\"1\"></transition>" +
| " </fork>" +
| " <state name=\"state1\">" +
| " <transition to=\"join1\"></transition>" +
| " </state>" +
| " <state name=\"state2\">" +
| " <transition to=\"join1\"></transition>" +
| " </state>" +
| " <join name=\"join1\">" +
| " <transition to=\"end\"></transition>" +
| " </join>" +
| " <end-state name=\"end\"></end-state>" +
| "</process-definition>"
|
If you look it carefully, you will find that I add the name attribute in the transitions..
This confuse jBPM because have to with null or empty names...
If you correct that you see the right behaviour..
Hope it helps...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189205#4189205
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189205
17 years, 4 months
[JBoss jBPM] - Re: fork and join childeren
by tbeernot
"salaboy21" wrote : The fork node is not a wait state.. so if you signal the start-state, the process will continue passing thru the fork node until reach the S1 and S2 nodes...
|
| So do this test:
|
| 1) signal de root token
| 2) look for childrens.. at this time with only one signal.. you must have 2 children.
| 3) then you can signal one of the child tokens and you see that the root token still in the fork node and the child token go to join node
| 4) then signal the other token and you will see that the root token moves to the end and the child token like the other move to join node...
|
| Can you do that test and post your code?
|
Sure!
| public void test()
| {
| // Declare a process with a fork
| // S
| // |
| // F
| // / \
| // s1 s2
| // \ /
| // J
| // |
| // E
| ProcessDefinition lProcessDefinition = ProcessDefinition.parseXmlString(
| "<process-definition>" +
| " <start-state name=\"start\">" +
| " <transition to=\"fork1\"></transition>" +
| " </start-state>" +
| " <fork name=\"fork1\">" +
| " <transition to=\"state1\"></transition>" +
| " <transition to=\"state2\"></transition>" +
| " </fork>" +
| " <state name=\"state1\">" +
| " <transition to=\"join1\"></transition>" +
| " </state>" +
| " <state name=\"state2\">" +
| " <transition to=\"join1\"></transition>" +
| " </state>" +
| " <join name=\"join1\">" +
| " <transition to=\"end\"></transition>" +
| " </join>" +
| " <end-state name=\"end\"></end-state>" +
| "</process-definition>"
| );
|
| // Start a process
| ProcessInstance lProcessInstance = new ProcessInstance(lProcessDefinition);
|
| // Get the token: we're in the start node
| Token lToken = lProcessInstance.getRootToken();
| System.out.println("1: " + lToken.getNode());
|
| // First signal: goto the fork
| lToken.signal();
| // this should mean that this token gets two childeren
| System.out.println("2a: " + lToken.getChildren().size());
| // this token should still be in the fork
| System.out.println("2b: " + lToken.getNode());
| // this token should still be in the fork
| System.out.println("2c: " + lToken.getChildren());
| Token lChild1 = (Token)lToken.getChildren().values().iterator().next();
| //Token lChild2 = (Token)lToken.getChildren().values().iterator().next();
| // the childeren should be in state1 and state2
| System.out.println("2d: " + lChild1.getNode() );
| //System.out.println("2e: " + lChild2.getNode() );
| }
|
I commented out lines because I do not have two childeren:
1: StartState(start)
2a: 1
2b: Fork(fork1)
2c: {1=Token(/1)}
2d: State(state1)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189200#4189200
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189200
17 years, 4 months
[JBoss jBPM] - Re: fork and join childeren
by salaboy21
No NO NO!.. LOL
anonymous wrote :
|
| 1. The token is in start.
| 2. I do a signal and then the token arrives at the fork. At that time it does not know what to do, they may be transitions with conditions.
| 3. When another signal is done on the token in the fork, THEN it will determine what transitions to follow and thus childeren can be created.
|
the second (2) point is wrong.. when the process enter to de fork node It know how many transition have.. so it create all the child token.. (If you don't belive me.. see the ForkNode.java class)
The fork node is not a wait state.. so if you signal the start-state, the process will continue passing thru the fork node until reach the S1 and S2 nodes...
So do this test:
1) signal de root token
2) look for childrens.. at this time with only one signal.. you must have 2 children.
3) then you can signal one of the child tokens and you see that the root token still in the fork node and the child token go to join node
4) then signal the other token and you will see that the root token moves to the end and the child token like the other move to join node...
Can you do that test and post your code?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189197#4189197
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189197
17 years, 4 months
[JBoss jBPM] - Re: fork and join childeren
by tbeernot
"tbeernot" wrote :
| So I'll see what happens if I refetch the root token every time.
No, the behavior is identical.
So.
Back to the documentation: "The default fork behaviour is to create a child token for each transition that leaves the fork, creating a parent-child relation between the token that arrives in the fork."
1. The token is in start.
2. I do a signal and then the token arrives at the fork. At that time it does not know what to do, they may be transitions with conditions.
3. When another signal is done on the token in the fork, THEN it will determine what transitions to follow and thus childeren can be created.
It still is THE token that arrived in the fork, so after the second signal there should be 2 childeren. Let's verify...
No. If I print the getNode and the getChilderen.size of the same token, it does not match. There is only one child. And the childeren appear at the wrong time.
StartState(start)/null
Fork(fork1)/1
State(state1)/1
Is there a good documentation? This is very confusing.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189181#4189181
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189181
17 years, 4 months
[JBoss jBPM] - Re: fork and join childeren
by tbeernot
"salaboy21" wrote : The code is in some way correct.. you need to understand the behaviour only....
| The two child tokens are created and propagated in the fork node, and the parent token stay in the fork node..
|
| In your code you can look for child tokens in the root token and then signal them and not always signal the parent. Just to clear the concepts...
| Because when you signal the root token.. it propagate the signal to the child tokens..
Ok. So. Ah... I get the initial root token. It moves to the fork and at that time two child tokens are spawned. These become its childeren.
|
| R
| / \
| C1 C2
|
|
So if I do a R.getNode() I actually get the node of C1, because R is in de join and holding for its childeren. Then C1 moves to the join. With another R.getNode() I then should get the node of C2. But that does not match, because I never have a token that has "state2".
So I'll see what happens if I refetch the root token every time.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189176#4189176
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189176
17 years, 4 months
[JBoss jBPM] - Re: jBPM 4 Design Question: Stateful Process Instance
by benhu
"kukeltje" wrote : Stateless EJB and the way the core works are separate things. The statefulness described in the design topics document (which was a discussion document and needs some updating since there were some not totally valid assumptions about current behaviour) is about being able to set runtime properties on a processinstance other then process variables so e.g. a mail node can be runtime configured to use othe smtp host. The option to you jBPM in a non-persistent (fully stateless, e.g. for STP) way will certainly remain or even made better.
Kuketlje, I am just a little bit confused by the last sentence. You say "jbpm in a non-persistent way". Do you mean the way jBPM 4 will do or the way I want to do? From my perspective, the major reason why I can make my service stateless is jBPM 3 is with persistence. So my service does not need to carry the state along and it simply gets from persistence.
Thank you for answering all my questions. You are really warm-hearted! =D
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189168#4189168
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189168
17 years, 4 months