[JBoss JIRA] Created: (JBPM-2846) Install jBPM 4.3 on Tomcat fails, get.tomcat task tries non-existent 6.0.20 version
by David Oliván Ubieto (JIRA)
Install jBPM 4.3 on Tomcat fails, get.tomcat task tries non-existent 6.0.20 version
-----------------------------------------------------------------------------------
Key: JBPM-2846
URL: https://jira.jboss.org/jira/browse/JBPM-2846
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.3
Environment: Windows XP SP3 x86, SUN Java 1.5.0_10, jBPM 4.3
Reporter: David Oliván Ubieto
Install jbpm-4.3.zip by unzipping to C:\ and perform manual install on Tomcat. The get.tomcat task in the Ant install/build.xml points to 6.0.20 version (line 31: <property name="tomcat.version" value="6.0.20" />) and tries to get that version from apache.org. The problem is that this version, 6.0.20 is currently not available at apache.org, only 6.0.24 and 6.0.26 are available.
Fix: Modify install/build.xml in order to get newer tomcat version or point to another location that holds 6.0.20 version.
Workaround 1: Place manually apache-tomcat-6.0.20.zip in /install/downloads getting it manually from another location
Workaround 2: Modify install/build.xml and put 6.0.24 or 6.0.26 version in line 31, but this version could not be supported for jBPM 4.3
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2641) taskService.addTaskParticipatingUser adds multiple participations for a user
by Robert Moskal (JIRA)
taskService.addTaskParticipatingUser adds multiple participations for a user
----------------------------------------------------------------------------
Key: JBPM-2641
URL: https://jira.jboss.org/jira/browse/JBPM-2641
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JDK 1.6 HSQL
Reporter: Robert Moskal
Perhaps this is the intended behavior, but calling taskService.addTaskParticipatingUser with the same user creates multiple participates:
taskService.addTaskParticipatingUser(_task.getId(), "boss_rigging", Participation.CANDIDATE);
taskService.addTaskParticipatingUser(_task.getId(), "boss_rigging", Participation.CANDIDATE);
assertEquals(1,taskService.createTaskQuery().candidate("boss_rigging").activityName("Investigate").list().size());
The query comes back with two tasks. This is somewhat surprising.
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2836) Process execution terminates with NullPointerException, when there is task with candidate-groups after join node in process definition.
by Jiri Mecner (JIRA)
Process execution terminates with NullPointerException, when there is task with candidate-groups after join node in process definition.
---------------------------------------------------------------------------------------------------------------------------------------
Key: JBPM-2836
URL: https://jira.jboss.org/jira/browse/JBPM-2836
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Environment: Windows 2007, HSQL
Reporter: Jiri Mecner
Process execution terminates with NullPointerException, when there is task with candidate-groups after join node in process definition.
Example test case:
process.jpdl.xml
<?xml version="1.0" encoding="UTF-8"?>
<process name="TaskAfterJoinTest" xmlns="http://jbpm.org/4.3/jpdl">
<start g="16,60,48,48">
<transition to="fork"/>
</start>
<fork g="96,60,48,48" name="fork">
<transition g="120,41:" to="state1"/>
<transition to="state2" g="120,126:"/>
</fork>
<state g="176,16,149,52" name="state1">
<transition g="379,40:" to="join"/>
</state>
<state g="176,100,149,52" name="state2">
<transition to="join" g="382,125:"/>
</state>
<join g="357,60,48,48" name="join">
<transition to="task1"/>
</join>
<end g="561,60,48,48" name="end"/>
<task candidate-groups="sales-dept" g="437,58,92,52" name="task1">
<transition to="end"/>
</task>
</process>
TaskAfterJoinTest.java
public class TaskAfterJoinTest extends JbpmTestCase {
String deploymentId;
protected void setUp() throws Exception {
super.setUp();
deploymentId = repositoryService.createDeployment()
.addResourceFromClasspath("process.jpdl.xml")
.deploy();
}
protected void tearDown() throws Exception {
repositoryService.deleteDeploymentCascade(deploymentId);
super.tearDown();
}
public void test() {
ProcessInstance processInstance = executionService.startProcessInstanceByKey("TaskAfterJoinTest");
String pid = processInstance.getId();
Set<String> expectedActivityNames = new HashSet<String>();
expectedActivityNames.add("state1");
expectedActivityNames.add("state2");
assertEquals(expectedActivityNames, processInstance.findActiveActivityNames());
assertNotNull(processInstance.findActiveExecutionIn("state1"));
assertNotNull(processInstance.findActiveExecutionIn("state2"));
String state1Id = processInstance.findActiveExecutionIn("state1").getId();
processInstance = executionService.signalExecutionById(state1Id);
expectedActivityNames.remove("state1");
assertEquals(expectedActivityNames, processInstance.findActiveActivityNames());
assertNotNull(processInstance.findActiveExecutionIn("state2"));
String state2Id = processInstance.findActiveExecutionIn("state2").getId();
// HERE - it raises NullPointerException
processInstance = executionService.signalExecutionById(state2Id);
expectedActivityNames.remove("state1");
expectedActivityNames.remove("task1");
assertEquals(expectedActivityNames, processInstance.findActiveActivityNames());
assertNotNull(processInstance.findActiveExecutionIn("task1"));
String task1Id = processInstance.findActiveExecutionIn("task1").getId();
processInstance = executionService.signalExecutionById(task1Id);
assertNull("execution "+pid+" should not exist", executionService.findExecutionById(pid));
}
stack trace:
java.lang.NullPointerException
at org.jbpm.pvm.internal.wire.usercode.UserCodeReference.getProcessDefinition(UserCodeReference.java:75)
at org.jbpm.pvm.internal.wire.usercode.UserCodeReference.getObject(UserCodeReference.java:60)
at org.jbpm.pvm.internal.wire.usercode.UserCodeReference.getObject(UserCodeReference.java:51)
at org.jbpm.pvm.internal.model.ExecutionImpl.initializeAssignments(ExecutionImpl.java:759)
at org.jbpm.jpdl.internal.activity.TaskActivity.execute(TaskActivity.java:95)
at org.jbpm.jpdl.internal.activity.TaskActivity.execute(TaskActivity.java:58)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:656)
at org.jbpm.pvm.internal.model.ExecutionImpl.fire(ExecutionImpl.java:566)
at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:472)
at org.jbpm.jpdl.internal.activity.JoinActivity.execute(JoinActivity.java:93)
at org.jbpm.jpdl.internal.activity.JoinActivity.execute(JoinActivity.java:49)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:656)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:616)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:417)
at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:61)
at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:35)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.signalExecutionById(ExecutionServiceImpl.java:84)
at TaskAfterJoinTest.test(TaskAfterJoinTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:164)
at org.jbpm.test.BaseJbpmTestCase.runTest(BaseJbpmTestCase.java:80)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2862) parse condition handler in DecisionActivity wrong
by Huisheng Xu (JIRA)
parse condition handler in DecisionActivity wrong
-------------------------------------------------
Key: JBPM-2862
URL: https://jira.jboss.org/jira/browse/JBPM-2862
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.3
Reporter: Huisheng Xu
Assignee: Huisheng Xu
Priority: Minor
Fix For: jBPM 4.4
Element conditionHandlerElement = XmlUtil.element(conditionElement, "handler");
if (handlerElement!=null) {
UserCodeCondition userCodeCondition = new UserCodeCondition();
UserCodeReference conditionReference = parser.parseUserCodeReference(conditionHandlerElement, parse);
userCodeCondition.setConditionReference(conditionReference);
transition.setCondition(userCodeCondition);
}
should use conditionHandlerElement to change the handlerElement in condition check.
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2835) HistroyDetail not saved in database.
by Arul Kalai (JIRA)
HistroyDetail not saved in database.
------------------------------------
Key: JBPM-2835
URL: https://jira.jboss.org/jira/browse/JBPM-2835
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4
Reporter: Arul Kalai
Fix For: jBPM 4.4
JBPM version : 4.4-SNAPSHOT
org.jbpm.pvm.internal.history.model.HistoryTaskImpl
Newly created HistoryDetail is not added to the collection of the HistoryTaskImpl(Highlighted).
public void updated(TaskImpl task) {
if ( (assignee==null && task.getAssignee()!=null)
|| (assignee!=null) && (!assignee.equals(task.getAssignee()))
) {
addDetail(new HistoryTaskAssignmentImpl(assignee, task.getAssignee()));
this.assignee = task.getAssignee();
}
if (priority!=task.getPriority()) {
addDetail(new HistoryPriorityUpdateImpl(priority, task.getPriority()));
this.priority = task.getPriority();
}
if ( (duedate==null && task.getDuedate()!=null)
|| (duedate!=null) && (!duedate.equals(task.getDuedate()))
) {
addDetail(new HistoryTaskDuedateUpdateImpl(duedate, task.getDuedate()));
this.duedate = task.getDuedate();
}
}
// details //////////////////////////////////////////////////////////////////
public void addDetail(HistoryDetailImpl detail) {
detail.setHistoryTask(this, nextDetailIndex);
details.add(detail);
nextDetailIndex++;
}
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2785) Description tag on activity not parsed
by Sofie Ravyts (JIRA)
Description tag on activity not parsed
--------------------------------------
Key: JBPM-2785
URL: https://jira.jboss.org/jira/browse/JBPM-2785
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.x
Reporter: Sofie Ravyts
Fix For: jBPM 4.x
When adding descriptions to the activities in the jpdl, these are not parsed:
In JpdlParser.java line 308 the description of the process xml element is read instead of the nestedElement (the activity):
Element descriptionElement = XmlUtil.element(documentElement, "description");
if (descriptionElement!=null) {
String description = XmlUtil.getContentText(descriptionElement);
activity.setDescription(description);
}
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2794) Constraint vailoation when moving from wait state using timer that result in looping back to the same wait state
by Maciej Swiderski (JIRA)
Constraint vailoation when moving from wait state using timer that result in looping back to the same wait state
----------------------------------------------------------------------------------------------------------------
Key: JBPM-2794
URL: https://jira.jboss.org/jira/browse/JBPM-2794
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3, jBPM 4.4
Environment: Windows XP, Java 1.6, Test case, JBoss 5.1.0
Reporter: Maciej Swiderski
Attachments: jbpm-testcase.zip
It is impossible to go from one state where transition is made by timer that goes thru java activity and decision point and gets back to the same state for retry.
Problem only exists if timer is assigned to a wait state and all nodes are executed synchnously.
Error that is thrown is:
10:57:13,382 WRN | [JDBCExceptionReporter] SQL Error: -104, SQLState: 23000
10:57:13,382 SEV | [JDBCExceptionReporter] Violation of unique constraint $$: duplicate value(s) for column(s) $$: SYS_CT_50 in statement [update JBPM4_EXECUTION set DBVERSION_=?, ACTIVITYNAME_=?, PROCDEFID_=?, HASVARS_=?, NAME_=?, KEY_=?, ID_=?, STATE_=?, SUSPHISTSTATE_=?, PRIORITY_=?, HISACTINST_=?, PARENT_=?, INSTANCE_=?, SUPEREXEC_=?, SUBPROCINST_=? where DBID_=? and DBVERSION_=?]
### EXCEPTION ###########################################
10:57:13,382 SEV | [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not update: [org.jbpm.pvm.internal.model.ExecutionImpl#15]
Attached is a eclipse project with minimal test case for it that illustrates the problem. The same test project is attached to discussion on forum.
Workaround is to make one on the nodes between states to be async.
--
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, 1 month
[JBoss JIRA] Created: (JBPM-2750) need delete the duplicated field 'state' in TaskImpl
by Huisheng Xu (JIRA)
need delete the duplicated field 'state' in TaskImpl
----------------------------------------------------
Key: JBPM-2750
URL: https://jira.jboss.org/jira/browse/JBPM-2750
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Environment: Windows XP, JDK1.5.0_15, Maven-2.2.1
Reporter: Huisheng Xu
Fix For: jBPM 4.4
How could we find out this bug?
If you invoke repositoryService.suspendDeployment(deploymentDbid), you will find out that the state of relative tasks is still 'open'.
Because there is a duplicated field 'state' in both TaskImpl and ScopeInstanceImpl. when we invoke 'taskImpl.suspend()' method, this method is defined in ScopeInstanceImpl.
in this method, the 'state' of ScopeInstanceImpl field will be changed to 'suspend', but the 'state' of TaskImpl field still be 'open', so in the end, no matter how we invoke the suspend() method, the TaskImpl is still open, it won't be suspended.
So I think we should delete the duplicated field 'state' of TaskImpl.
--
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, 1 month