Why not try to get commit access (you don't have that, right), so you can help
fixing them. Try to attach patches to the jira issues and notify Tom. We'd
appreciate that very much.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3941520#3941520
Reply to the p
I also think you should do tok.end(false) and not tok.end() (which seems
dangerous). Will it be fixed? I'm regularly patching/extending the jBpm core.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3941477#3941477
Reply to the post :
http://www.jboss.com/inde
Following up my own post.
I decided to implement michaelholtzman's fix to the Join node.
Essentially:
| if (this.equals(tok.getNode()) tok.end(false);
|
However, I chose to pass in false to the end method, such that the parent token
and associated process instance
I too have been experiencing issues with this particular bug and unsure how to
proceed.
I have a workflow which has an initial wait state which then traverses to a
fork which then concludes in a join, followed by a transition back to the
initial wait state.
My workflow never terminates as such
great thanx
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3938456#3938456
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3938456
---
Using Tomcat but need to do more?
Also posted to JIRA http://jira.jboss.org/jira/browse/JBPM-288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| package com.sample;
|
Michael,
Could you create a unit test and attach both the processdefinition and the unit
test to the bug report? I reopend it and refered it to this topic
Thanks,
Ronald
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3938266#3938266
Reply to the post :
ht
Yes, this looks like the same issue (
http://jira.jboss.org/jira/browse/JBPM-288 ).
My contention is that when a join node reactivates the parent token, all child
tokens at that join node should be ended. The same is probably true for child
tokens that arrive at the join after the parent has be
btw, your question about child tokens could be related to
http://jira.jboss.org/jira/browse/JBPM-288
It is closed due to an incomplete testcase. Maybe your case can help.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3937816#3937816
Reply to the post :
htt
Michael,
With incomming tokens I do not mean incomming transitions.
Suppose a fork splits of two tokens T1 and T2. Each of which goes to a
descision (T1 to D1 and T2 to D2) which in turn have two transitions to tasks
(1A, 1B and 2A, 2B). So either 1A or 1B AND 2A or 2B are taken. Below this i
anonymous wrote : my expectation was that a join needs as many incomming tokens
as there were in the corresponding fork
The revised process definition satisifies that requirement, and the transition
out of the join is taken. I'm just wondering about the fate of the child tokens
after the fork/j
hmm... my expectation was that a join needs as many incomming tokens as there
were in the corresponding fork. (even the same tokens). This would explain the
behaviour I see myself in a model where there are two leaving tokens in a fork
and 4 incomming transitions of which only 2 will be ever tak
Ah ha! I restructured the process definition so that the task and timer
converge at an intermediate node and then proceed to the join:
|
| http://jbpm.org/3/jpdl";
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
| xsi:schemaLocation="http://jbpm.org/3/jpdl
http://jbpm.org/xs
The built-in join node requires a token on all incoming transitions before
proceeding. I see you have two transitions from the task node to the join, one
for the task and the other for the timer. Since they are mutually exclusive,
the join should not proceed.
However, you state the process ins
14 matches
Mail list logo
