December 2010 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2951) TaskService.completeTask fails when called with variables but no outcome

by Jon Kranes (JIRA)

TaskService.completeTask fails when called with variables but no outcome ------------------------------------------------------------------------ Key: JBPM-2951 URL: https://jira.jboss.org/browse/JBPM-2951 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Reporter: Jon Kranes Given a task 'task1' with a single named transition, if I call the variant of completeTask that takes the taskID and a Map of variables, the result is an error: "No unnamed transitions were found for the task 'task1' According to the user guide (Section 5.7), if a task has one outgoing transition with a name, then calling compeleteTask(id, null) is expected to result in an error. It appears that calling completeTask(id, variables) is being treated as equivalent to calling completeTask(id, null, variables) and thus causing an error. This behavior seems incorrect -- completeTask(id, variables) should, aside from setting variables, follow the behavior of completeTask(id), which according to the user guide will complete the task and take the single outgoing transition regardless of whether it is named or not. -- 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

13 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2956) DispatcherThread integer overflow and make checkForNewJobs volatile

by Michael Wohlfart (JIRA)

DispatcherThread integer overflow and make checkForNewJobs volatile ------------------------------------------------------------------- Key: JBPM-2956 URL: https://jira.jboss.org/browse/JBPM-2956 Project: jBPM Issue Type: Patch Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Reporter: Michael Wohlfart Priority: Trivial Fix For: jBPM 4.5 I experience an integer overflow in DispatcherThread, also i think checkForNewJobs should be volatile since it might be accessed from different threads, the attached thread should resolve this -- 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

13 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-2962) Retrieving variable with null value failed in scripts

by William Ferreira (JIRA)

Retrieving variable with null value failed in scripts ----------------------------------------------------- Key: JBPM-2962 URL: https://jira.jboss.org/browse/JBPM-2962 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Reporter: William Ferreira setting a variable with a null value in context cause the application to fail while trying to retrieve it from a (Groovy) Script : Caused by: groovy.lang.MissingPropertyException: No such property: XXX The bug is related to the EnvironmentBindings class : 'containsKey(Object key)' method makes use of the method 'get(Object key)' to determine if a Variable exists, but 'get(Object key)' returns the value of the key... Regards -- 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

13 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2966) cancel and error end activity throws exception in subprocess

by Philipp Ossler (JIRA)

cancel and error end activity throws exception in subprocess ------------------------------------------------------------ Key: JBPM-2966 URL: https://jira.jboss.org/browse/JBPM-2966 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Environment: jBPM 4.4 Reporter: Philipp Ossler I created a simple process which includes a state and a subprocess with different end activities The subprocess is similar to the example in user guide > http://docs.jboss.com/jbpm/v4/userguide/html_single/#endstate. When I send the signal "end" to the state in the subprocess, the process wait in state "end state". That's correct! But if I send the signal "cancel" or "end", a JbpmException "execution[...] has running subprocess: execution[...] in state cancel/error" throws. This exception throws in method checkActive() of the class ExecutionImpl. {code:java} if (!isActive()) protected void checkActive() { if (!isActive()) { throw new JbpmException(toString() + " is not active: " + state); } else if (this.subProcessInstance != null && !Execution.STATE_ENDED.equals(this.subProcessInstance.getState())) { throw new JbpmException(toString() + " has running subprocess: " + this.subProcessInstance.toString() + " in state " + this.subProcessInstance.getState()); } } {code} The problem is that the methode only check if the subprocess has the state "end". I think the method have to check if the subprocess state is one of {end, cancel, error}. Right? -- 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

13 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2967) jBPM not support Hibernate 3.6 on oracle db

by Mark Li (JIRA)

jBPM not support Hibernate 3.6 on oracle db ------------------------------------------- Key: JBPM-2967 URL: https://jira.jboss.org/browse/JBPM-2967 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Environment: oracle 10g, hibernate 3.6, jBPM 3.6, java 1.6, windows 7 Reporter: Mark Li following code will throw a cant cast to oracle.sql.BLOB exception! ProcessEngine processEngine = new Configuration().setResource("cn/ac/iitcm/cmcollect/jbpm.cfg.xml").buildProcessEngine(); RepositoryService repositoryService = processEngine.getRepositoryService(); NewDeployment deployment = repositoryService.createDeployment(); String id = deployment.addResourceFromClasspath("cn/ac/iitcm/cmcollect/collectprocess.jpdl.xml").deploy(); if I change to setBlob to setBinaryStream, this exception will pass, but other exception appears: It will break constraint for JBPM_DEPLOYMENT. hibernate 3.6 is much more faster than 3.6, I donot want to switch back. please correct this. 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

13 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPM-2969) DST switching not considered for in BusinessCalendarImpl

by Michael Wohlfart (JIRA)

DST switching not considered for in BusinessCalendarImpl -------------------------------------------------------- Key: JBPM-2969 URL: https://jira.jboss.org/browse/JBPM-2969 Project: jBPM Issue Type: Bug Components: Runtime Engine Affects Versions: jBPM 4.4 Environment: ubuntu 10.10, OpenJDK1.6 Reporter: Michael Wohlfart Priority: Minor BusinessCalendarImpl doesn't honor DST switching, in some special cases (less than 5 days before DST switching and 1 hour before midnight) the following test fails: ------------------------------------------------------------------------------- Test set: org.jbpm.test.timer.TimerTest ------------------------------------------------------------------------------- Tests run: 17, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.696 sec <<< FAILURE! testTimerELCalendarSubtract(org.jbpm.test.timer.TimerTest) Time elapsed: 0.071 sec <<< FAILURE! junit.framework.AssertionFailedError: expected:<26> but was:<27> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at junit.framework.Assert.assertEquals(Assert.java:204) at org.jbpm.test.timer.TimerTest.testTimerELCalendarSubtract(TimerTest.java:304) to me it seems like this is cause by the BusinessCalendarImpl and the upcoming DST which leads to a wrong day of month calculation in the test and/or BusinessCalendarImpl class -- 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

13 years, 5 months

2
1
0 / 0

[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

13 years, 5 months

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

13 years, 5 months

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

13 years, 5 months

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

13 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues December 2010