[JBoss JIRA] Created: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)
10:07 a.m.
Inconsistent behaviour depending on the ordering of events (fork+end state+join)
--------------------------------------------------------------------------------
Key: JBPM-2040
URL: https://jira.jboss.org/jira/browse/JBPM-2040
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.2.3
Reporter: Mauro Molinari
Assignee: Thomas Diesler
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing the
creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:09 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)
[
https://jira.jboss.org/jira/browse/JBPM-2040?page=com.atlassian.jira.plug...
]
Thomas Diesler updated JBPM-2040:
---------------------------------
Fix Version/s: jBPM 4.0.x
Affects Version/s: (was: jBPM 3.2.3)
Description:
Please investigate to see if jBPM4 works as expected. Because of backward compatibility
JBPM-1906 has been rejected for jBPM3.
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing the
creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
was:
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing the
creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
Assignee: (was: Thomas Diesler)
Inconsistent behaviour depending on the ordering of events (fork+end
state+join)
--------------------------------------------------------------------------------
Key: JBPM-2040
URL: https://jira.jboss.org/jira/browse/JBPM-2040
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Core Engine
Reporter: Mauro Molinari
Fix For: jBPM 4.0.x
Please investigate to see if jBPM4 works as expected. Because of backward compatibility
JBPM-1906 has been rejected for jBPM3.
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing
the creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:34 a.m.
New subject: [JBoss JIRA] Assigned: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)
[
https://jira.jboss.org/jira/browse/JBPM-2040?page=com.atlassian.jira.plug...
]
Tom Baeyens reassigned JBPM-2040:
---------------------------------
Assignee: Joram Barrez
Inconsistent behaviour depending on the ordering of events (fork+end
state+join)
--------------------------------------------------------------------------------
Key: JBPM-2040
URL: https://jira.jboss.org/jira/browse/JBPM-2040
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Runtime Engine
Reporter: Mauro Molinari
Assignee: Joram Barrez
Fix For: jBPM 4.1
Please investigate to see if jBPM4 works as expected. Because of backward compatibility
JBPM-1906 has been rejected for jBPM3.
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing
the creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:34 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)
[
https://jira.jboss.org/jira/browse/JBPM-2040?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-2040:
------------------------------
Fix Version/s: jBPM 4.1
(was: jBPM 4.x)
Inconsistent behaviour depending on the ordering of events (fork+end
state+join)
--------------------------------------------------------------------------------
Key: JBPM-2040
URL: https://jira.jboss.org/jira/browse/JBPM-2040
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Runtime Engine
Reporter: Mauro Molinari
Assignee: Joram Barrez
Fix For: jBPM 4.1
Please investigate to see if jBPM4 works as expected. Because of backward compatibility
JBPM-1906 has been rejected for jBPM3.
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing
the creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:09 p.m.
New subject: [JBoss JIRA] Resolved: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)
[
https://jira.jboss.org/jira/browse/JBPM-2040?page=com.atlassian.jira.plug...
]
Joram Barrez resolved JBPM-2040.
--------------------------------
Resolution: Done
Added test case to testsuite, covering the described process.
In jBPM4, the problem is solved by adding "ends='execution'" to the end
state (default end state will cause the process instance to halt, what is the most logical
usage).
Inconsistent behaviour depending on the ordering of events (fork+end
state+join)
--------------------------------------------------------------------------------
Key: JBPM-2040
URL: https://jira.jboss.org/jira/browse/JBPM-2040
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Runtime Engine
Reporter: Mauro Molinari
Assignee: Joram Barrez
Fix For: jBPM 4.1
Please investigate to see if jBPM4 works as expected. Because of backward compatibility
JBPM-1906 has been rejected for jBPM3.
Given the following process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"
name="Complex">
<description>
Complex description
</description>
<start-state name="start-state1">
<transition to="task-node1"></transition>
</start-state>
<task-node name="task-node3">
<task name="Task3_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="end-state1"></transition>
</task-node>
<node name="node1">
<transition to="task-node3"></transition>
</node>
<join name="join1">
<transition to="node1"></transition>
</join>
<fork name="fork1">
<transition to="task-node2"></transition>
<transition to="node2" name="to node2"></transition>
<transition to="state1" name="to state1"></transition>
</fork>
<task-node name="task-node2">
<task name="Task2_1">
<assignment actor-id="1"></assignment>
</task>
<task name="Task2_2">
<assignment actor-id="1"></assignment>
</task>
<transition to="join1"></transition>
</task-node>
<task-node name="task-node1">
<task name="Task1_1">
<assignment actor-id="1"></assignment>
</task>
<transition to="fork1"></transition>
</task-node>
<node name="node2">
<transition to="end-state2"></transition>
</node>
<state name="state1">
<transition to="end-state2"></transition>
</state>
<end-state name="end-state1"></end-state>
<end-state name="end-state2"></end-state>
</process-definition>
Try to do this:
- create a process instance and start it
- a Task1_1 instance is created: end it
- the root token halts at the fork and three children tokens are created
1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance
2) the second halts at the state1 state
3) the third dies at the end-state2 state
Now, there are two cases:
CASE A)
- signal the second token: it then goes on and dies at end-state2 state
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- now, the root token is restored and goes through node1 and task-node3 nodes, causing
the creation of a Task3_1 instance
This is what I would expect!
CASE B)
- end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join
- signal the second token: it then goes on and dies at end-state2 state
- now, the root token is ended, halting the process instance!
This is not the expected behaviour, as I would expect that the root token is restored
because now all the sibling tokens of those that have reached the join node are ended, so
the parent token (= the root token) should be restored and should continue to node1 and
subsequent nodes.
Moreover, I would not expect that the behaviour is different depending on the ordering of
the actions "signal the state1 token" and "signal the task-node2
token".
My suspect is this: in case B) the join node is not "triggered" anymore after
Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the
second children token is signalled, it reaches end-state2: jBPM then realizes that all of
the sibling tokens are also ended, so it wrongly decides that the parent token should also
be ended.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5465
days inactive
5615
days old
4 comments
3 participants
participants (3)
-
Joram Barrez (JIRA) -
Thomas Diesler (JIRA)
-
Tom Baeyens (JIRA)