November 2010 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2970) DbSessionImpl.deleteProcessDefinitionHistory causes foreign key constrain violation for FK_HACTI_HPROCI

by Michael Wohlfart (JIRA)

DbSessionImpl.deleteProcessDefinitionHistory causes foreign key constrain violation for FK_HACTI_HPROCI ------------------------------------------------------------------------------------------------------- Key: JBPM-2970 URL: https://jira.jboss.org/browse/JBPM-2970 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Environment: ubuntu 10.10, OpenJDK1.6 Reporter: Michael Wohlfart Priority: Minor DbSessionImpl.deleteProcessDefinitionHistory(String processDefinitionId) needs to remove HistoryActivityInstanceImpl when deleting HistoryProcessInstanceImpl since there is a foreign key constrain FK_HACTI_HPROCI in the hibernate mapping, the following implementation should do the trick: public void deleteProcessDefinitionHistory(String processDefinitionId) { List<HistoryProcessInstanceImpl> historyProcessInstances = session .createCriteria(HistoryProcessInstanceImpl.class) .add(Restrictions.eq("processDefinitionId", processDefinitionId)) .list(); for (HistoryProcessInstanceImpl hpi : historyProcessInstances) { List<HistoryActivityInstanceImpl> historyActivityInstances = session .createCriteria(HistoryActivityInstanceImpl.class) .add(Restrictions.eq("historyProcessInstance", hpi)) .list(); for (HistoryActivityInstanceImpl hai : historyActivityInstances) { session.delete(hai); } session.delete(hpi); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2973) Database constraint violation occurs after fork / join when one branch is a subprocess

by Jon Kranes (JIRA)

Database constraint violation occurs after fork / join when one branch is a subprocess -------------------------------------------------------------------------------------- Key: JBPM-2973 URL: https://jira.jboss.org/browse/JBPM-2973 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Environment: Windows XP, JDK 1.6, PostgreSQL Reporter: Jon Kranes Given a process and subprocess with the following characteristics: * A fork node that splits execution into two parallel paths * A corresponding join node with multiplicity=1, indicating that execution should continue when the node is reached from either of the parallel branches * At least one of the branches invokes a sub-process The expected behavior is that if either branch completes, execution should continue from the join node and all pending activities on the other branch should be deleted. However, in the case where the sub-process branch is waiting for task completion, and the task on the other branch is completed, the task completion call fails with a database constraint violation: ERROR: update or delete on table "jbpm4_execution" violates foreign key constraint "fk_exec_superexec" on table "jbpm4_execution" This works as expected when no sub-processes are involved, i.e. if both branches are just composed of tasks in the main process. It also works as expected if the sub-process branch is the one that completes first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2972) Update jpdl XSD with fork transition conditions

by Mike M (JIRA)

Update jpdl XSD with fork transition conditions ----------------------------------------------- Key: JBPM-2972 URL: https://jira.jboss.org/browse/JBPM-2972 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4, jBPM 4.3 Reporter: Mike M The jpdl xsd needs to be updated to reflect the fact that transitions in fork activities can have nested condition elements. Looking at the code for ForkActivity, it's apparently that <fork> activities do evaluate conditions for outgoing transitions. Example: <fork name="fork1"> <transition to="always_do_this"/> <transition to="sometimes_do_this" > <condition expr="#{my_boolean_expression}"/> </transition> </fork> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2974) HistoryTaskAssignmentImpl is not produced then task reassigned with using TaskService.assignTask

by Alexey Kakunin (JIRA)

HistoryTaskAssignmentImpl is not produced then task reassigned with using TaskService.assignTask ------------------------------------------------------------------------------------------------ Key: JBPM-2974 URL: https://jira.jboss.org/browse/JBPM-2974 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Alexey Kakunin I think it is because HistoryTaskImpl.updated called from TaskUpdated HistoryEvent - and it is called only from SaveTask command, not from AssignTask (or any other what can produce task reassignment) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2975) problem with Fork/Join

by doublehero Xu (JIRA)

problem with Fork/Join ---------------------- Key: JBPM-2975 URL: https://jira.jboss.org/browse/JBPM-2975 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.2 Reporter: doublehero Xu Hi,I have get a problem in using the JBPM framework, the version of JBPM framework is 4.2 . You can copy my junit test files into your project and run the AsyncForkTest class as a junit test application, the test result won't be passed.So what just happen? ps.I have another question,Is it a necessary to use a Fork and Join tag at the same time in the xxx.jpdl.xml? Cause in my junit test , I only use the Fork tag. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-2977) NPE in HistoryActivityInstanceImpl ctor when Activity is null

by Mike M (JIRA)

NPE in HistoryActivityInstanceImpl ctor when Activity is null ------------------------------------------------------------- Key: JBPM-2977 URL: https://jira.jboss.org/browse/JBPM-2977 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Reporter: Mike M In 4.4, automatic history recording was added for custom activities (JBPM-2495). In order to work around (JBPM-2976), we had to create a custom activity that was basically the ForkActivity with slight modification. In the jbpm implementation of the ForkActivity (on which ours was based), it sets the Activity of the root execution to null before launching child executions. When the process engine later executes the history code, the constructor for HistoryActivityInstanceImpl fails with an NPE because the activity is null. Our workaround is to comment out the line in our Fork implementation that sets the Activity to null. Not sure if this has any side effects, but we haven't seen any so far. Now granted, it is a rather odd case to have a custom activity setting the activity to null. But nonetheless, it seems that a generic history mechanism should handle this case gracefully, rather than just throwing an NPE. Our -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2976) Order of child executions for fork is non-deterministic

by Mike M (JIRA)

Order of child executions for fork is non-deterministic ------------------------------------------------------- Key: JBPM-2976 URL: https://jira.jboss.org/browse/JBPM-2976 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Reporter: Mike M In 4.4, the implementation of the ForkActivity was changed such that a map (Transition -> Child Execution) is now built. Because this is just a generic map without any ordering, the actual order in which the child executions get executed is now non-deterministic. In 4.3, the order was always the same as the order in which the outgoing transitions were listed in the process definition. Now, I'm not sure if this side-effect (making the order non-deterministic) was intentional or not but it definitely break things when other parts of the workflow rely upon a specific ordering. There are definite, real use cases where it is necessary and desirable to specify an explicit order for things. Our workaround was to create a custom activity that is basically exactly the same as ForkActivity, but orders the taking of transitions on child executions so that it is the same as defined in the process definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-1170) Multiple Timers with same name on Node end prematurely

by David Roberts (JIRA)

Multiple Timers with same name on Node end prematurely ------------------------------------------------------ Key: JBPM-1170 URL: http://jira.jboss.com/jira/browse/JBPM-1170 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.2 Environment: Jbpm 3.2.2, Tomcat 5.028, MySQL 5.0 Reporter: David Roberts Assigned To: Tom Baeyens When you have multiple Tasks on a Node, and each task has a Timer called, for example, "Reminder". Lets say each timer is set to repeat every 24 hours. If you complete one of the Tasks on the node, the Timer called "Reminder" on that task instance ends, but so does every other timer for all other tasks on that node with the name "Reminder". Surely this should not happen? You could avoid this by naming each Timer differenty, example "Reminder 1", "Reminder 2". But the problem may still happen if you have multiple task instances of the SAME task. Then the name of the Reminders will still be the same, so they will all end when completing one of the task instances. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBPM-1166) fix SEAM timer transaction integration

by Tom Baeyens (JIRA)

fix SEAM timer transaction integration -------------------------------------- Key: JBPM-1166 URL: http://jira.jboss.com/jira/browse/JBPM-1166 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

4
19
0 / 0

[JBoss JIRA] Created: (JBPM-1140) Empty <handler> element in <decision> cause org.jbpm.graph.def.DelegationException

by Rafa? ?ukowski (JIRA)

Empty <handler> element in <decision> cause org.jbpm.graph.def.DelegationException ---------------------------------------------------------------------------------- Key: JBPM-1140 URL: http://jira.jboss.com/jira/browse/JBPM-1140 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Rafa? ?ukowski Assigned To: Tom Baeyens Priority: Trivial That is my first issue, forgive me any mistakes and possible redundancy or duplication;) Using graphical designer I've created process file with empty <handler> : <decision name="decision1"> <handler></handler> <transition to="optional" name="to optional"></transition><transition to="first" name="to optional"></transition> </decision> And this is not working (org.jbpm.graph.def.DelegationException). After deleting <handler></handler> process is running correctly. Don't know if this is error in engine or in designer. Maby this kind of decision node is incorrect, and then designer should avoid this situation. My opinion is that engine should ignore empty handlers and go on without errors... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues November 2010