October 2010 - jbpm-issues - Jboss List Archives

[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

2
2
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

2
1
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

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

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

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

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-1118) Unexpected behavier of LoggingConfigDbTest

by Jan-Philipp Bolle (JIRA)

Unexpected behavier of LoggingConfigDbTest ------------------------------------------ Key: JBPM-1118 URL: http://jira.jboss.com/jira/browse/JBPM-1118 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Jan-Philipp Bolle Assigned To: Tom Baeyens Priority: Trivial It looks like that the LoggingConfigDbTest is not working. I added in nologging.jbpm.cfg.xml the org.jbpm.logging.db.DbLoggingServiceFactory. Now I assume that the test must fail because jBPM is configured to use the loggingservice. But the test still work (is green). -- 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

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-2696) Timers should be read after node-enter actions

by Bernd Ruecker (JIRA)

Timers should be read after node-enter actions ---------------------------------------------- Key: JBPM-2696 URL: https://jira.jboss.org/jira/browse/JBPM-2696 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.8 Reporter: Bernd Ruecker Priority: Minor Fix For: jBPM 3.2.x When parsing the processdefinition, timers are read before all events are read. This leads to "create-timer" actions being added to the node-enter events BEFORE your own actions. This doesn't make a lot of sense, normally you want your own actions being executed first and the timer created afterwards. From the runtime perspective, it doesn't make any difference (since the timer is started not before the transaciton commits), but with that behavior you could e.g. calculate due dates on the node-enter event (before the time is created). This is located in the JpdlXmlReader, method "readNode", these two lines: readNodeTimers(nodeElement, node); readEvents(nodeElement, node); See Forum on the discussion how to solve it. -- 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

14 years

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2001) DbLoggingService -> Protected Session Rather than Package Private

by Brad Davis (JIRA)

DbLoggingService -> Protected Session Rather than Package Private ----------------------------------------------------------------- Key: JBPM-2001 URL: https://jira.jboss.org/jira/browse/JBPM-2001 Project: JBoss jBPM Issue Type: Patch Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.2.x Reporter: Brad Davis Priority: Minor Fix For: jBPM 3.2.x DBLoggingService should have a protected Hibernate session to allow extension. See patch below. ### Eclipse Workspace Patch 1.0 #P jbpm Index: modules/core/src/main/java/org/jbpm/logging/db/DbLoggingService.java =================================================================== --- modules/core/src/main/java/org/jbpm/logging/db/DbLoggingService.java (revision 3699) +++ modules/core/src/main/java/org/jbpm/logging/db/DbLoggingService.java (working copy) @@ -31,7 +31,7 @@ private static final long serialVersionUID = 1L; - Session session = null; + protected Session session = null; public DbLoggingService() { JbpmContext currentJbpmContext = JbpmContext.getCurrentJbpmContext(); -- 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

14 years

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-1159) Update missing suggested alternatives in deprecated JbpmSessionFactory

by Julien Kronegg (JIRA)

Update missing suggested alternatives in deprecated JbpmSessionFactory ---------------------------------------------------------------------- Key: JBPM-1159 URL: http://jira.jboss.com/jira/browse/JBPM-1159 Project: JBoss jBPM Issue Type: Bug Components: Documentation Affects Versions: jBPM jPDL 3.2.2 Environment: source code downloaded from CVS :pserver:anonymous@anoncvs.forge.jboss.com:/cvsroot/jbpm (jbpm.3) Reporter: Julien Kronegg Assigned To: Tom Baeyens Priority: Minor The class org.jbpm.db.JbpmSessionFactory is deprecated and the deprecation comment states: @deprecated use {@link org.jbpm.tc.ContextBuilder} and {@link org.jbpm.tc.db.JbpmSessionContext} instead. However, the org.jbpm.tc package is no more in the code. Thus, another suggested replacement should be provided. Contrarily of as specified in http://jira.jboss.com/jira/browse/JBPM-624 this issue is not fixed in CVS (as the code was downloaded from CVS). -- 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

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues October 2010