kukeltje wrote : anonymous wrote : Is there any way to attach a (zip) file to
a post here? When I get a working example I'd be happy to share the code.
|
| Sorry, no... but you can post it on the wiki and put the link here. Just
make sure you give the page a meaningful name.
I added an
kukeltje wrote : In most of the situations the states (not to be confused
with the state nodes) are either signalled by a human, or async after the
execution of some action.
Please, can you clarify what the difference is between 'the states' and 'the
state nodes'? I am taking a token being at a
anonymous wrote : Please, can you clarify what the difference is between 'the
states' and 'the state nodes'?
I probably should have said 'wait-states' and state-nodes. task-nodes are
generally also wait-states, and the generic 'node' can be made into a wait
state or auto-transitioning node by
kukeltje wrote : I probably should have said 'wait-states' and state-nodes.
OK - I understand all that :)
kukeltje wrote : Your 'solution' seems ok, but I wonder what the advantage is
in doing it this way.
My 'solution' is just an illustration that shows how to signal the tokens and
how to
anonymous wrote : Is there any way to attach a (zip) file to a post here? When
I get a working example I'd be happy to share the code.
Sorry, no... but you can post it on the wiki and put the link here. Just make
sure you give the page a meaningful name.
View the original post :
please make a unit test so we can see the problem and what you specifically do.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4131019#4131019
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4131019
Correction. In the process defintion the actions should be defined as follows:
action name=EnterNode class=forktest.EnterStateHandler/action
|
| action name=LeaveNode class=forktest.ExitStateHandler/action
View the original post :
I do not see strange things in here. The only thing that surprises me is that
token.getName() is null for the root token
What version of jBPM are you using? I'll try to reproduce tonight... btw
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4131065#4131065
IMO, you shouldn't signal the root token once it has arrived in the fork:
| Token root = processInstance.getRootToken();
| // root token is already on the fork, signal children instead
| // root.signal();
|
I've found a (rejected) feature request to prevent the
kukeltje wrote : I do not see strange things in here. There may be nothing
'strange', but I wasn't expecting multiple tokens to pass through any node.
I'm looking to use 'client base assignment' (see
http://www.jboss.com/products/jbpm/docs/jpdl) and use jBPM as the execution
engine. Since I
mputz wrote : IMO, you shouldn't signal the root token once it has arrived in
the fork:
|
|
| | Token root = processInstance.getRootToken();
| | // root token is already on the fork, signal children
instead
| | // root.signal();
| |
OK,
mputz wrote : I've found a (rejected) feature request to prevent the root
token from being signaled on a fork node:
http://jira.jboss.com/jira/browse/JBPM-642
That seems to be exactly what I've found.
So if this behaviour is 'normal', how is it possibly to use jBPM as the
execution engine in
Good catch Martin so there was something 'strange' in the code, I just
missed it... shame one me.
A full client based assignment is (afaik) seldomly fount. In most of the
situations the states (not to be confused with the state nodes) are either
signalled by a human, or async after the
In a similar scenario, I find that following the fork, two new tokens proceed
along each of the (2) transitions leaving the fork to their respective nodes -
however, the 'root' token then 'follows' one of the other tokens and also
enters the same node, and generates a node-enter event.
thx :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125509#4125509
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4125509
___
jboss-user mailing list
jboss-user@lists.jboss.org
I mean, i move my token to the fork.
Then again token.signal()
Then i check with
| Collection c =
jbpmContext.getTaskMgmtSession().findTaskInstancesByToken(token.getId());
| log.info( Number of TaskInstances for Token: + c.size());
|
the number of available TaskInstances
Don't 'expect', be sure. So probably there is more than one token. Look at the
unit tests in cvs to see how the internals of jbpm work for forks. Unit tests
are so great...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125316#4125316
Reply to the post :
I should not have kept you in the dark there are 2 tokens...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125326#4125326
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4125326
18 matches
Mail list logo
